Brief 簽好了，說清楚要做什麼；下一個問題是這 30 天用什麼骨架撐起來。今天的核心主張是：框架依問題形狀選擇，不是依天數整除選擇。

先講最誘人的錯誤示範。STAR（Situation、Task、Action、Result）四段，30 除以 4 等於 7.5——所以 Situation 寫七天半？為了湊整還得把 Result 拉長成八天，然後我就得在證據還沒發生的日子裡預寫「成果」，這正是 Day 2 說過的偷跑結論。Skill 的 frameworks.md 把這條寫成明文：不要求 n 能被階段數整除，該用擴張階段、重複循環或首尾包夾去對應天數。STAR 本身沒有錯，錯的是把敘事模板當成切蛋糕的刀。

本系列實際採用的是七階段自訂生命週期：問題界定、契約設計、工具實作、自己使用、結果檢驗、回饋演進、公開交付——這是照著「一個模糊需求如何變成可驗證的公開交付」的天然順序排的，不是照哪個管理學縮寫。外層再套一圈 PDCA：Day 1 到 10 是 Plan，11 到 22 是 Do，23 到 25 是 Check，26 到 30 是 Act。一句話交代外層與局部的關係：PDCA 管整個系列的節奏，其餘框架只在適合的地方客串——SMART 只用來寫驗收條件，STAR 只用來整理真實發生的事件，ADR 只記錄有替代方案與後果的決策。誰都不准搶主場。

注意一件事：frameworks.md 也提醒，不得宣稱自訂框架是既有標準。這七個階段是為這個題目設計的，不是什麼業界方法論——我不會給它取縮寫，免得它聽起來比實際上偉大。分配也故意不平均：工具實作吃七天、結果檢驗只有三天，因為材料量本來就不平均。班表要貼著活排，不是貼著格子排。

框架是為題目服務的；題目不是為了讓框架看起來整齊而存在的。