MSSP 開發區

這一頁記錄方法本身的狀態。前四個模組講怎麼用 MSSP；這一頁講 MSSP 自己還缺什麼、以及下一版要往哪走。

版本：MSSP 1.x。條目會隨著範例與考古累積增減，每一條都盡量指得出是哪個實作得到的。

設計優點

1. 判斷準則可以在寫程式的當下使用

「移除它之後系統還是不是它」和「能不能在最小核心下單獨測試」是兩個可以在編輯器裡當場回答的問題。它們不需要先畫架構圖、不需要開會、不需要理解整套理論。

這是 MSSP 跟多數架構方法最實際的差別：多數方法給你一組名詞，MSSP 給你兩個可以立刻執行的動作。

2. 結構主張可以被機器驗證

「沒有任何 TMS 引用兄弟 TMS」不是一句期許，它是一個 grep。這個網站的 build 會執行它，違規時指出確切檔案並拒絕發佈。

大部分架構規範只存在於文件裡，於是它們在第三個月就開始漂移。能被機械檢查的規則才會活過交接。

3. 知識與權限分離的效益比預期大

原本以為這只是安全性設計。考古 001 顯示它同時解決了三個看起來無關的問題：可測試性（不會被受測對象殺掉行程）、可嵌入性（能放進長時間執行的宿主）、可在地化（錯誤訊息不再寫死在效果發生的那一行）。

一條界線同時解掉三個問題，通常代表這條界線本來就在那裡。

4. 孤島測試把「模組獨立」變成會失敗的斷言

宣稱一個模組獨立很容易。載入最小核心與恰好一個模組、stub 掉所有工具、然後跑它的代表任務——這個做不到就是做不到。

它抓到的通常不是設計錯誤，而是幾層之下透過共用 import 抵達的依賴，那種東西讀程式碼看不出來。

5. 「度」讓方法可以被部分採用

FMS + SMS + TMS 就是一個完整的中型 MSSP 專案。不需要五個集合、不需要 Router、不需要一次到位。

這一點降低了採用門檻，也降低了過度設計的風險——判準是「這個集合有沒有讓某件原本做不到的事變得可以做」。

已知缺點

1. 依賴檢查只認得靜態 import

目前的檢查是文字比對 import ... from。動態 import()、執行期組出來的路徑、以及非 JS 語言的模組系統都會漏掉。

影響： 一個刻意繞過的人可以繞過。對誠實的錯誤有效，對決心不誠實的程式碼無效。

緩解： 現階段接受這個限制，並在每個範例裡明說。真正的解法是在有實模組邊界的語言上做同樣的事——見改良點 2。

2. SMS 沒有防止自己長大的機制

身份測試判斷單一能力該放哪，但沒有任何東西阻止 SMS 逐條累積。每一條加入時都通過了測試，加完三十條之後 SMS 就是新的單體。

影響： 這是 MSSP 最可能失敗的方式，而且失敗得很慢、很難察覺。

緩解： 目前只有「定期重問身份測試」這種紀律性做法，不夠。改良點 1 要處理它。

3. Router 只有定義，沒有實作模式

論文定義了 $R(q,u,\tau,p) \rightarrow (S_q, T_q, C_q, D_q)$ ，但沒有說規則式路由在什麼規模上會不夠用、換成模型式路由的判準是什麼、以及路由本身要怎麼測。

影響： 大型 Skill System 最需要 Router，而這正是目前指引最薄的地方。

緩解： 排在範例路線的第一位。

4. 上下文效用密度目前不可量測

$\rho_q = I_{\text{task relevant}} / I_{\text{loaded}}$ 是一個乾淨的定義，但「task relevant」在真實專案裡沒有可操作的量測方式。分母好算，分子不好算。

影響： 「按需載入更有效率」目前是一個合理推論，不是一個有數字支撐的結論。

緩解： 改良點 3 提出一個可能的代理指標。

5. 小規模上的成本是真的

在門檻以下使用完整 MSSP 會讓程式更難讀。這一點方法自己承認，但目前只用文字描述「度」，沒有量化的判斷工具。

影響： 新使用者最容易在這裡做錯決定——要嘛全套上，要嘛因為看到成本就整個放棄。

緩解： 改良點 4。

6. 五個集合的名字有學習成本

FMS／SMS／TMS 這組命名來自母集與子集的數學隱喻，但對第一次接觸的人來說，「第二主母集」不會自我解釋。

影響： 提高了第一小時的門檻。

現況： 不打算改名——重新命名會讓既有論文與這個網站的所有內容失去對應。改善方式是入口文件把角色講清楚，而不是換詞。

未來改良點

改良點 1：SMS 預算

給 SMS 一個明確上限——模組數、或核心介面數。超過就強制重問每一條的身份測試，而不是等到有人察覺。

具體形式可能是 FMS/03_CAPABILITY_INDEX.yaml 裡的一個 sms_budget 欄位，由 build 檢查。這會把「SMS 不該長大」從紀律變成約束。

驗證方式： 對一個既有專案套用預算，看它逼出哪些條目降級到 TMS，以及降級之後有沒有東西壞掉。

改良點 2：在有實模組邊界的語言上重做依賴檢查

Rust 的 crate、Go 的 package、Java 的 module system 都在語言層強制模組邊界。在那些語言上，「TMS 不引用兄弟 TMS」可以由編譯器保證，而不是 grep。

驗證方式： 用其中一種語言寫一個等價於 001 號的範例，比較檢查的強度與寫起來的代價。

改良點 3：用「載入但未被讀取」當作污染的代理指標

$\rho_q$ 的分子難算，但反過來可測：載入的規則裡，有多少在這次任務中從未被引用。

對 Agent 系統，這可以用工具呼叫紀錄與載入清單做交集。這不是 $\rho_q$ ，是它的一個保守下界，但下界是可以量的，定義不是。

驗證方式： 在同一組任務上比較全量載入與按需載入的未讀取比例。

改良點 4：把「度」變成一個可以跑的問卷

目前的規模門檻是一張表格，要人自己判斷。它可以變成一個小工具：回答八到十個是非題，輸出建議的集合組合與理由。

這聽起來很小，但它處理的是新使用者最容易做錯的決定，而且輸出的理由本身就是教學。

驗證方式： 對三個已知規模的專案跑一次，看建議是否符合實際上划算的組合。

改良點 5：讓考古累積成統計

每天一個開源專案，累積之後這一頁應該能回答：哪些邊界問題是普遍的，哪些只是個案。

目前 1 筆，還不足以說任何事。到二十筆左右應該開始有形狀。

驗證方式： 統計本身就是產出——如果二十筆之後看不出任何模式，那也是一個結論。

改良點 6：檢查本身要被證明會失敗

方法目前說：結構主張要能被機器驗證（見上方設計優點 2）。它沒有說那個驗證要先被看著失敗一次。

這條從開發日誌升上來，因為它不是一次意外，是同一個形狀反覆出現：

日期	檢查	為什麼它不會失敗
08-01	架構透視器的 25 個測試	全部斷言「事件」，而事件不需要被展示輸入就能存在——把整層 `observed:` 刪掉，25 個全過
08-02	範例 002 的節流示範	時鐘間隔永遠大於門檻，節流一次都沒觸發，而輸出完全看不出來
08-02	考古 002 的邊界斷言	寫成「不可以有 200」，而被檢查的處理器根本沒被分派到

三次的共同形狀是同一句：斷言寫成「壞事沒發生」，而壞事沒發生最常見的原因是那段路徑沒被走到。

具體提案是在範例契約裡加一條必要條件：每個範例必須包含一段刻意違反自身結構規則的程式碼，並要求檢查擋下它。 002 的孤島測試第 4 節已經是這個形狀——它蓋出錯誤的節流形狀，要求 SCL 規則拒絕。那一節應該從「這個範例剛好有做」變成「每個範例都要有」。

代價要說清楚：這會讓每個範例變長，而且寫反例比寫正例難——你得先知道它會怎麼壞。

驗證方式： 對現有兩個範例與兩則考古回頭補這一節。如果四個裡有任何一個補不出來（想不到一個會讓檢查失敗的改動），那不是這條規則太嚴，是那個檢查本來就沒有在檢查東西。

2026-08-03 更新：這條加進來的隔天就付了。 拿它去問一條既有的檢查——「沒有任何 TMS 引用兄弟 TMS」對 Python 範例有沒有跑——答案是沒有。那段的檔案過濾是 /\.(js|mjs|ts)$/，而範例 002 是 Python。在它的一個 TMS 裡加上真正的違規 import，建置綠燈通過；考古的建置有自己一份同樣的檢查，也一樣沒跑。兩邊都已修並在四個方向驗過。發現方式值得記：不是測試變紅，是拿一條新規則去問一條舊檢查。

改良點 7：DMS 需要契約，不只是一句描述

FMS、SCL、SMS、TMS 在模組 01 與模組 02 裡都有判準——身分測試、孤島測試、依賴規則、權限與知識分離。DMS 只有一句話：「人可以看到實際發生了什麼」。

那句話不夠，因為它沒有說 DMS 欠讀者什麼。範例 003 是拿一個具體案例去逼出那個缺口的：5 records migrated, 0 errors 這句話，對一次正確的執行為真，對一次什麼都沒改的執行為真，對一次跑到第二筆就返回的執行也為真。符合現行 DMS 描述的報告，可以完全無法分辨這三者。

提案是給 DMS 三條可檢查的最低要求：

收支要平。 輸入的每個單位都必須在輸出的分類裡剛好出現一次。這條要放在 SMS——一份自己計算自己正確性的報告是在改自己的考卷。
要有見證。 每一類結果至少一筆具體的前後對照，包含「沒有改變」那一類。計數是主張，前後對照是讀者可以不同意的東西。
沒被執行到的能力要自己說出來。 載入了、正確、從未被呼叫——那不是錯誤也不是成功，是證據的缺席，而且它是「相信某個東西能用、但它一次都沒跑過」最常見的來源。

第三條跟改良點 6 是同一件事的兩個方向：改良點 6 說檢查要能失敗，這一條說報告要能說出它沒看到什麼。

代價：三條都會讓 DMS 變大，而 DMS 是最容易被砍掉的集合。第三條尤其麻煩——它要求 SMS 記錄「呼叫了幾次」，而一個從未被呼叫的能力不產生任何輸出可以統計，所以計數必須在迴圈裡做，不能事後從結果推。

驗證方式： 對考古累積的每一則問同一個問題——上游的 DMS 過得了這三條嗎。logging（考古 003）過不了第三條：basicConfig 在已設定時靜靜返回 None，而那正是第三條要抓的東西。如果二十則考古下來，第三條抓到的都是同一種東西，那它就該從改良點升成判準。

開發路線：四個 MVP 與回饋迴圈

程式研究區的四份研究不會停在論文。每一份要先做出 MVP，而 MVP 本身用 MSSP 蓋——於是它同時是產品，也是這個方法在中等規模上的證據。

方向	MVP	目前狀態
架構可視化	GitHub 架構透視器	已接手；宣告／觀察兩層並存＋治理事件（2026-08-01）
FPL 專案形式化語言	EveMiss FPL（MSSP-Lang + 編譯器）	v0.1.0，八條規則、22 個測試（2026-08-01）
動態 MSSP	規模感知的結構建議器	待開始；迭代授權 §31 已給出 MVP 的六件事
AI 管理	靜態記憶體邊界推斷	待開始

每天的進展記在開發日誌；這一頁只收沉澱下來的結論。

迴圈

研究草案  →  MVP（用 MSSP 蓋）  →  實作打回來的問題  →  開發區  →  MSSP 1.x
    ↑                                                              │
    └──────────────────────────────────────────────────────────────┘

三條線同時跑，互相餵料：

每日範例與每日考古持續累積，處理的是方法在小規模與別人程式碼上的行為。
四個 MVP處理的是方法在中等規模、真實產品上的行為——這正是目前最缺的一段，因為現有範例都刻意小於門檻。
這一頁收兩邊打回來的東西，然後決定哪些進下一個小版本。

為什麼 MVP 要用 MSSP 蓋

如果 MVP 用別的方式蓋，它們就只是四個產品；用 MSSP 蓋，它們同時回答一個現在還沒有答案的問題：這個方法在真正需要它的規模上，實際感覺如何。

範例證明結構可行，考古證明邊界問題普遍存在，但兩者都不能證明「在門檻上的專案用了會比較好」。四個 MVP 是目前唯一能產生那個證據的東西。

代價是誠實的：如果某個 MVP 用 MSSP 蓋起來明顯更費力而沒有換到東西，那個結果也會寫在這一頁。能產生反面證據的計畫，才有資格宣稱正面證據。

版本策略

MSSP 目前是 1.x。以上缺點被解決的方式是進入下一個小版本，不是重寫方法。

論文（v0.1，2026-07-12）定義了架構；這個網站在做的是把它推到實作，並把實作打回來的東西記在這一頁。方法與實作互相修正是預期中的流程，不是計畫外的事故。

改良點被實作之後會標上做出它的範例、考古或 MVP 編號，並從缺點清單移到優點清單。