架構與模式

這一頁收錄的是已經被實作驗證過的結構。每一條都指得出是哪個範例做出來的，沒有做過的東西不會出現在這裡。

模式 1：共享契約取代兄弟引用

問題。 兩個 TMS 需要同一份衍生資料。先寫的那個自然長出一個計算函式，後寫的直接 import 它。

// TMS/reporters/json.js
import { summarise } from "./text.js";

這行會動。它同時做了兩件當天看不見的事：json 再也無法在沒有 text 的情況下載入，而刪掉 text 會弄壞一個跟它無關的模組。

解法不是把函式複製兩份——那會產生兩個逐漸漂移的版本。解法是注意到那份計算從來就不屬於任何一個報表：它是「執行結果」的性質。

TMS/reporters/text  ──┐
                      ├──▶  SMS/model.js  (runReport)
TMS/reporters/json  ──┘

代價。 SMS 會長大，而且長大的部分是所有人都依賴的部分。所以每次往 SMS 加東西之前，要重問一次身份測試。

實作：001 號範例。

模式 2：註冊表，讓「只載入一個」成為可能

沒有註冊表，入口檔案必須直接 import 每一個模組。這會讓「建立一個只有一個 TMS 的系統」在物理上不可能——於是孤島測試也不可能。

註冊表的價值不在於它做了什麼，而在於它讓一件事變得可以被構造。這是 SMS 的典型長相：本身很小，但拿掉之後某一整類驗證會消失。

同一型別註冊兩次應該直接拋錯，而不是後者覆蓋前者。重複註冊是接線錯誤，不是一個需要決定優先順序的情境。

模式 3：權限檢查排在能力檢查之前

這條是在寫 001 號範例時發現的，而且第一版寫反了。

直覺的順序是先看有沒有處理器，再看准不准。畢竟不能做的事，何必查政策？結果是這樣：

skipped wipe-data  no handler loaded for this type

這句話當天是實話。file.delete 在政策上是 deny_all，但因為沒有載入對應的處理器，回報的是「載入狀態」而不是「政策判定」。等到有人註冊了一個 delete 處理器，這句話的意思會在沒有人改動政策的情況下改變。

正確順序下：

skipped wipe-data  denied: irreversible; no handler is loaded for it and policy denies it regardless

一般形式：

一個答案如果取決於當下載入了哪些模組，那它就不是政策答案。

模式 4：孤島測試寫成可執行檔案，不是宣稱

MSSP 的核心主張是一個 TMS 可以被單獨理解與執行。如果這件事沒有被執行過，它就只是一個說法。

孤島測試的形狀：

1. 只載入該模組宣告的最小 SMS
2. 恰好載入一個 TMS
3. 把每個外部工具換成 stub
4. 執行這個模組的代表任務
5. 檢查輸入、輸出、以及被拒絕的權限
6. 確認沒有其他 TMS 被載入

第 6 步是最常失敗的一步，而且從閱讀模組本身看不出來——依賴通常是透過某個共用 import 在好幾層之下抵達的。

模式 5：DMS 記錄「執行」，報表呈現「結果」

兩者分開是有理由的。報表渲染結果；追蹤記錄的是這次執行，包含那些從來沒有變成結果的部分——因為沒有載入處理器而跳過的任務、因為權限而被拒絕的操作。

「4 個跳過」是一個數字。人類視圖是說出哪四個、為什麼的那一層。

反模式

以下六種來自論文第十五章，加上實作時遇到的形態。

巨型 SKILL.md／單一檔案。 所有能力、平台、角色與例外塞進同一份文件。結果是無法導航、全量載入、任何修改都有風險、規則互相污染。

偽模組化。 分成很多資料夾，但所有 TMS 彼此直接引用，或必須一起載入才能工作。這只是把單體拆成多個檔案。

所有能力都是 SMS。 如果任何能力都被視為核心，就無法按需載入，也無法安全替換。SMS 悄悄變回了單體。

FMS 可執行化。 把具體流程、工具參數與領域細節塞進 FMS，最後讓總導航層失去簡潔性——變成另一份大型文件，只是換了檔名。

權限只靠自然語言提醒。 「請不要刪除正式資料」如果工具仍然允許任意刪除，這不是契約，是期望。

Agent 自我提出、自我修改、自我批准。 同一個 Agent 發現問題、提出修正、執行修正、宣稱成功、批准發布。這形成自我驗證閉環。破解方式是角色與權限分離——這個網站的做法是把 build 的檢查列為 L3、部署列為 L4，作者無法為自己開路。

一條額外的紀律：守衛必須被證明會失敗

這一條不在論文裡，是實作這個專區時付出代價學到的。

build-mssp.mjs 有一項檢查禁止 TMS 引用兄弟 TMS。第一版的邏輯把「同一個目錄內」視為模組內部，所以放行。但 TMS/reporters/ 裡放的是兩個不同的 TMS——同目錄恰好就是最該擋的情況。

發現方式是故意加上那行違規 import，然後看著 build 保持綠燈。

一個從來沒有被證明會失敗的守衛，還不構成任何證據。

現在單元邊界是明確的：一個 TMS 單元 = 帶有 index 檔的目錄，否則就是單一檔案。而且檢查在兩個方向都測過：違規時擋下並指出確切檔案，乾淨時通過。

路線

以下是這個系列接下來要補的結構，按預期價值排序：

• Router 的實作模式。 這是最快會用到的一個。001 號沒有 Router，因為一個型別對一個處理器時路由就是一次查表，另設一層會是空模組——這本身就是「度」的一個示範：等它需要存在的時候再建。
• 跨語言的依賴檢查。 目前是文字比對靜態 import，動態 import() 會漏掉。一個有真正模組邊界的語言不需要這道檢查。
• 上下文污染的量測。 目前 $\rho_q$ 是一個定義，還不是一個可以在專案上跑出數字的量測。
• 形式化驗證隱藏依賴。 孤島測試能抓到大部分，但它是動態的；靜態證明會更強。

每一項補上之後都會回到這一頁，並附上做出它的範例編號。