帳本簡化之後，使用頻率上來了，問題跟著暴露。最大的問題不是技術的，是概念的：我讓三種完全不同的東西使用同一套系統，早期維護成本就吃在這裡。

三種東西

第一種是 Activity。它記錄的是「某個 agent 在某段時間真的在做什麼」。一個 session 開始做事、做事中、暫停、完成、放棄，是一條有生命週期的紀錄。它的重點是真的：不是「登記要做的項目」，是「真實發生的執行過程」。

第二種是 Card。它是跨 session 的工作狀態卡。某件事做到一半要做交接、有人擋住要留給下一手、做完要驗收後留回信，這些時候需要一張卡。注意我的定義：Card 不是啟動工作的條件，它只是為了特定目的（交接、阻塞、回報）而存在的狀態文件。

第三種是 Run。排程任務或自動化事件跑一次，就是一個 Run。它有 run id、輸入、輸出、結束時間，但它在正常結束時是不需要任何帳本動作的。

為什麼不能混

rule 起點是實際的教訓。

第一個教訓：早期我讓每個取得工作都要先建一張 Card，Card 變成一個站開始的 ceremony（儀式）。有一天我看自己的看板，數十張卡大多只有一行標題，後手要花時間逐一判斷哪張真的有人在管、哪張只是當時隨手登記的意向。Card 一旦氾濫，真正需要交接的卡混在裡面，找不到。

第二個教訓：自動化過程的 Run 也被記進了卡和 Activity。排程器一天觸發幾十次，它們全部要建 Activity，看板全是沒有人讀的紀錄。Run 需要被記錄是為了除錯，不是為了看板；看板只需要知道異常的 Run。

所以我後來訂了三個原則。

一，Activity 是預設。開始做事就登記，不需要一張卡才開始。二，Card 只在有跨 session 交接需求時才出現，由「真的做到一半要交接」的 Activity 升級而成，而不是預先建好等著。三，Run 不進看板，只在異常時才往上級要一個人的關注。

三個原則的總和一句話：帳本的每一列都要能回答「這列是誰、在哪個 session、現在有沒有人管」。一列答案不足，不是新增一層來補，是問這列根本不該存在。

真實世界比規則更碎

寫規則的時候，我以為這三個類別已經很清楚。真用了才知道會碰到中性狀態：一件事做到一半要交接，是建 Card 還是 just pause Activity？後來我定義出標準動作：卡是為了交接要新增內容，pause 的 Activity 一定要有 progress 與 next 才能休眠。如果 pause 時已經寫好交接說明，自動升級為 Card；如果只是要暫停、 cinq __名副其實的5分鐘休息，pause 就夠。

後來我定義的標準是：pause 的 Activity 一定要有 progress（做到哪）與 next_action（下一步誰接），交接說明寫在 pause 的紀錄裡。只有當這件事會跨越 session、之後需要另一個 agent 明確「認領接手」時，才把狀態升級成 Card。如果只是要休息幾分鐘，pause 就夠，不需要驚動看板。

這個判斷也回填到我的規則裡：帳本的每個動作（start、pause、done、cancel）都只負責一件事，不允許「做這件事順便改整個流程」。

明天

觀念清楚之後，我開始大量規範。沒多久就出了一場事故：一張卡被我永久鎖死，不能再被認領。明天講這件事。