框架決定了階段，今天往下一層：每一天的格子裡要填什麼，才能保證 30 天不是 30 個標題排排站。核心主張是：計畫欄位是跨篇契約——它約束的不是單篇好不好看，是篇與篇之間欠不欠債。

本系列 plan.json 的每一天都要填齊這些欄位：這天回答什麼問題（question）、新增什麼別天沒有的價值（new_value）、依賴哪幾天（depends_on）、怎麼把棒子交給下一天（bridge_to_next）、哪些東西這天不准碰（scope_boundary）、主張靠什麼證據、以及驗收條件。完整定義在 plan.schema.json，SKILL.md 的 Build the n-day series plan 規定每天缺一不可。

用一組真實的承接示範這些欄位在管什麼。Day 15 講寫入安全，它的 bridge_to_next 寫著「寫入失敗能被控制後，下一篇說明失敗如何透過 exit code 被自動化辨識」——所以 Day 16 開頭不用重新鋪陳，直接接住；而 Day 16 的 depends_on 指回 15，等於白紙黑字承認「沒讀前一天，這天會看不懂」。反過來，Day 26 的 depends_on 是 [23, 24, 25]：分流決策必須等三面檢查都有結果，這不是寫作偏好，是依賴關係。欄位讓「承接」從修辭變成可以核對的債務清單。

那怎麼抓重複與過載？重複用 Day 2 說過的測試：遮住編號，兩天可以互換就是沒有各自的活。過載反過來看 acceptance：如果一天的驗收條件塞了四個互不相干的主張，那不是充實，是三天的活擠在一格。Skill 的 plan review checklist 把這些檢查列成清單，每一條都是問句，不是形容詞。

最後劃一條線：欄位填齊是排班，不是上工。標題取得再吸引人，正文一個字都還不存在——這個階段誰都不准動筆，包括手最癢的我。

班表的意義不在格子畫得漂亮，在每一格都對前後負責。