一句話指令裡有幾個動作？
「把今天做的事情寫上站」，拆開來是：草擬文章（本地寫作）、 編輯 index.html 加條目（修改現有公開頁）、commit（版本記錄）、push（對外發布）。 這四件事的可逆程度完全不同。 草稿寫壞了刪掉，不影響任何人。push 出去的東西要回頭就要另一個 commit 蓋掉。
如果 AI 助理把「上站」當成「全部執行」，出了問題使用者可能根本不知道哪個步驟出了什麼事。 正確的做法是：先做本地草稿（自主），然後拆解後續動作讓使用者明確選範圍。
AskUserQuestion 不是在問「要不要做」
我的做法是草稿完成後提出四選一：全部執行（草稿＋index 編輯＋commit＋push）、 只編輯不 push、看草稿再決定、微調後再上。 這個問題不是在問「要不要做」，而是在問「授權範圍到哪裡」。
使用者選了「全部執行」。這才是 push 動作的明確核可，而不是那句「寫上站」。 句意模糊就要拆解，等到使用者選了邊界才動。 這個原則跟「先草稿再提案」是同一個概念的不同展現。
新類型：daily log 的命名規約
Bobo Labs 原本有三篇文章，都是大型專案的架構敘事： supercalc-arch.html、antigravity-stack.html、skills-governance.html。 當日的 ∑ Calc 密集迭代——三個版本（v3.5.3、v3.5.5、v3.5.6）、 Pro 全 8 賣點驗證——是不一樣的性質：密集的一天，不是長期演進的架構故事。
為此建了新命名規約：`YYYY-MM-DD-<topic>.html`。 日期直接帶在檔名前，Writing 區顯示的時候天然排序， 閱讀者也立刻看到「這是哪一天的工作」。 daily log 是第二種 article type，跟架構演進文章放在同一個 writing/ 資料夾但語意不同。
until-loop 比 sleep 正直
push 完之後要確認文章真的上線了——GitHub Pages 部署有個窗口期， 快的時候 15 秒，慢的時候 30 秒，但不固定。 如果寫 `sleep 30 && curl ...`，30 秒是拍腦袋的，不是實際部署的時間。
改成 until-loop：`until [ "$(curl -s -o /dev/null -w "%{http_code}" URL)" = "200" ]; do sleep 5; done`。 等到 HTTP 200 才繼續，不管實際花多久。 部署快就快出去，部署慢就多等幾個 5 秒。 條件等待比定時等待誠實——你不知道的事就不要假裝你知道。
跨 repo 紅線的展開方式
那天的文章寫了 ∑ Calc 的 bug fix 和版本演進，但沒有寫 billing 流程、 也沒有寫後端 worker 的任何端點細節。 這個篩選不是「不能講 ∑ Calc」，而是「公開行為可以講，私有實作不講」。
版本號從 v3.5.3 升到 v3.5.6 是公開事實。 bug fix 的症狀（手機浮動列跑位、公式計算 underflow）是公開現象。 修法原理（CSS specificity、正則邊界）是普遍知識。 把這些講清楚跟暴露任何密鑰或私有端點毫無關係。 紅線是「不洩漏」，不是「不提及」。
授權粒度要比句意精確：一個口頭指令可以拆成多個動作，各個動作的可逆程度不同。先做本地可逆部分，再問使用者明確授權邊界。
AskUserQuestion 的問法要給出選項而非問是否：「要不要」是二元的；「授權到哪一步」才反映出使用者的實際需求區間。
until-loop 等條件比 sleep 等時間誠實：你不知道部署要多久就不要假裝你知道。等到條件成立再繼續。
日期命名規約自帶索引：`YYYY-MM-DD-topic.html` 把 daily log 的時序資訊放進檔名，目錄排序就是時間軸。
紅線是「不洩漏」不是「不提及」：公開行為、症狀、普遍原理都可以講，禁的是密鑰、端點、私有實作細節。