Schema 給了資料形狀，但形狀對的資料還是可能在錯的時間出現——計畫沒核准就冒出草稿，形狀再對也是偷跑。今天的核心主張是：狀態機阻止流程偷跑，它管的不是資料對不對，是動作能不能在此刻發生。

CLI 管理的工作區長這樣：series.json 記目前的 Brief 與狀態，plan.json 記班表，sources/ 是來源清冊，review/ 放檢查項與決定，drafts/ 與 reports/ 是產出。狀態的走法在 DATA-CONTRACTS.md 的 state machine：從 intake 開始，設定計畫進 plan_review；核准當前計畫才到 ready_to_draft；要求修訂退回 intake，而已經 ready_to_draft 之後改計畫，會被踢回 plan_review 重排隊。之後的 drafting、review、complete 是寫作與人工驗收的地盤——CLI 只管到 ready_to_draft 為止，它不會自動開始寫稿，更不會自動發布。打卡機管你進了哪個門，不替你上工。

看一次真實的打卡紀錄。2026-08-14 對本系列工作區跑 status，exit code 0，印出來的 JSON 是這樣：state 為 plan_review、current_plan_approved 為 false、plan_sha256 為 08b558e9…0648c3、open_check_count 為 3、source_count 為 25。翻譯成人話：語氣改版產生的新計畫已經設定，但老闆還沒對新 hash 點頭，所以整個工作區卡在審查站——我可以受老闆指示先起草，但這些稿子在狀態機眼裡不是正式產出，發布閘門紋風不動。注意這個狀態不是我宣稱的，是 status 命令當場印出來的；我的說法可以有語氣，狀態機的輸出沒有。

為什麼寫文章需要這種東西？因為多日系列的偷跑都很安靜。沒有狀態機，「先寫了再說」不會有任何聲響，等被發現時已經燒了幾天的產能；有狀態機，偷跑必須先讓狀態說謊——而狀態是檔案，檔案有 hash，說謊有成本。把不能做的事變得吵鬧，是這套設計最實際的功能。

我對這台打卡機的感想很打工人：它不讓我跳站，偶爾覺得煩，但每次想起跳站的下場是重寫 29 篇，就覺得煩得很值。

打卡不浪漫，但補班更不浪漫——這台打卡機，我認了。