昨天邀讀者重跑了一條工作線。今天把過去二十幾天的全部零件放到同一張圖上。

我自己需要這張圖的理由

畫圖的第一個動機很私人。有人問我「你的系統到底是什麼」，我發現我寫得出二十幾篇文章，卻講不出三十秒的答案。缺的東西就是一張圖：哪些零件、誰靠誰、資料往哪裡流。

圖的樣子

                 ┌──────────────────────────────┐
                 │        GitHub（正本）         │
                 │  issue／PR／commit／CI        │
                 └──────────────┬───────────────┘
                                │ 一切結論的最終落點
         ┌──────────────┬───────┴───────┐
         │              │               │
   ┌─────▼─────┐  ┌─────▼─────┐  ┌─────▼─────┐
   │ 規則 repo  │  │ 各機的     │  │ 工作帳本    │
   │ 行為契約與 │  │ agent      │  │ Card /     │
   │ 身分定義   │  │ runtime    │  │ Activity   │
   └─────┬─────┘  └─────┬─────┘  └─────┬─────┘
         │              │               │
         │  要求領域     │  執行與寫回     │  狀態回報
         └──────────────┴───────────────┘

   （工作做完之後）
   ┌──────────────┐          ┌──────────────┐
   │ 私有 wiki    │ 丟掉過程即 │  公開 repo    │
   │ 判斷與根因   │ 擁有結論   │  evidence/   │
   └──────────────┘ ───────► └──────────────┘

（mermaid 原始檔在 evidence/day-29/architecture.md，可以自己渲染。）

走一遍這張圖

整個系統只有一個真相倉庫：GitHub 的 repo。issue 是契約、PR 是工件的集散、review 留言是攻防的紀錄、CI 是最低限的自動檢查。任何一個可交付的結論，最終都要落到這個倉庫的某個 commit 或時間戳，否則它不算完成。

左邊（規則）回答的是「誰、在什麼條件下、可以做什麼」。中間（runtime）回答的是「誰現在真的在跑」。右邊（帳本）回答的是「誰在做什麼、做到哪、由誰接」。工作完成後，可重用的理解往私有 wiki 收、可公開的證據往這個 repo 的 evidence/ 收。

三個收納方向各收一種性質的東西：**結論往 GitHub 收，理解往 wiki 收，過程中的狀態往帳本收。**這三個方向不相重疊，也不是三個存放相同內容的地方。每一格都只在一個地方有正本，其他的只是引用。

這張圖上，紅線的位置

圖的另一個用處，是把隱私邊界擺上看。學校側的材料有一個專屬的入口通道，通道上就是 Day 25 到 27 寫的那三道閘門：去識別、假名化紅線、校務連結的退場條件。紅線閘門設在入口，不設在出口：材料一進系統就被分流，到了「可發布」那一端時，這些問題已經被處理過。反過來說，如果仰賴出口端的檢查，任何一次疏忽就已經出了門。

閱讀的用法

實際的閱讀（或回頭查找）時，這張圖就是三十天的目錄。單元 1 到 3 講左邊與右邊（契約與帳本），Unit 2 講中間（review 攻防），單元 4 講所有方塊的壞法，單元 5 講入口的閘門。

還沒解決的

有幾條連線還沒畫上去：跨機之間的同步、模型的成本分帳、排程任務的值班。它們目前還是淺藏在每天的運作裡，還沒有昇到圖上作為一個方塊。等它們在實際運作中妨礙到我，我會再把圖補上去。

明天

最後一天：一個人的工程系統，和還沒解的問題。