開源專案考古
節奏
每天一個開源專案，從 2026-08-01 開始。優先挑授權寬鬆的（MIT、Apache-2.0、BSD），因為那類專案允許引用原始碼、允許做對照版本、也允許把結果公開出來——考古要能拿出證據，證據就得能被複製。
目前完成數：0。這個數字每天會往上加一。
為什麼要看別人的程式碼
自己寫的範例有一個結構性的弱點：邊界是我畫的，所以它們當然對得上方法。
別人寫的程式碼不會配合你的方法，這正是它的價值。一個在真實壓力下長出來的結構，會把方法論沒預期到的情況直接攤在你面前——而那些情況才是方法接下來要吸收的東西。
每一次考古保留三種視圖
- 原專案的結構地圖。 它現在是什麼樣子，以及為什麼會長成這樣。歷史條件通常比設計品味更能解釋一個結構。
- MSSP 視角的對照。 用兩個判斷問題重畫一次邊界，並說明每條邊界是依據哪個判準畫的。
- 不適合拆的部分。 拒絕被乾淨拆解的地方，以及為什麼。
第三項是最有價值的產出。如果每一次考古都得出「拆完更好」，這個系列就不是研究。一個耦合往往有它存在的理由，找出那個理由，比證明它應該被重寫有用得多——而且那通常就是「度」在真實專案裡的樣子。
判準
一個目標值得做，是因為它能回答這些問題：
- 它的核心任務閉環是什麼？拿掉哪些部分之後它就不再是它？
- 哪些能力宣稱獨立，實際上必須一起載入？
- 有沒有兩個模組互相引用，而它們都自認是插件？
- 知識與權限有沒有混在一起？
- 觀測層能不能讓使用者知道剛才發生了什麼？
- 不動核心的情況下，能不能新增一個能力？
最後一項是最快的體檢，通常十分鐘內就有答案。
選題
挑中等規模的。 大到無法在一次閱讀裡看完，對照版本就沒有人驗證得了。
不要挑已經是 MSSP 形狀的。 那不叫考古，叫確認偏誤。
優先挑「明顯有邊界問題但活得很好」的。 一個結構混亂卻被大量使用的專案，通常代表那個混亂在某個維度上是正確的權衡。找出那個維度，是這個系列最想要的結果。
產出格式
與參考實作共用同一份契約：對照版本要能跑、要被機械檢查、要寫出「這次沒有解決什麼」。額外要標明來源、授權、以及檢視的 commit——不標版本的考古在原專案下一次改動之後就失效了。
不修改原專案，不發 issue，不宣稱原作者應該怎麼做。這是閱讀筆記，不是建議書。
這一頁會怎麼變
每一篇考古完成後會出現在下方清單，並帶著它的日期、專案、授權與一句話結論。累積之後，這一頁本身就會變成一份資料：哪些邊界問題是普遍的，哪些只是個案。
那份統計是這個系列真正想要的東西，而它只能靠每天一個累積出來。