Scrum 任務的完整性定義

Review round 現在不會順手替 board 開任務，只留一條明文裁定的例外。Finding 在被審的那個任務裡修掉；要不要開新工作，是 review loop 之外的規劃決定。

先交代背景：我用一個 task board 追蹤工作，再小的 commit 都要過 review round。預設的 reader 是 session 自己的 subagent，拿到這次變更的範圍去讀；diff 夠大，或同一個問題兩輪都沒收斂，就換 Codex 來讀。Reader 讀完會提出 candidate issue。

同一個 commit，四個任務

2026-09-06，一個任務的 review rounds 在同一個 board commit 裡開了四個任務。

• 三個來自一次 digest pin 的盤點。
• 第四個來自一個無關的缺口，出在規則對 CI 的描述上。

單看每個都說得通。問題是，沒有任何一個是有人做過的規劃決定。它們會上 board，只是因為 round 剛好看到。

為什麼這是問題

這裡有兩種失敗，方向相反：一種是把該做的工作推出去，一種是把不該現在決定的工作塞進來。

往外推。 變更自己造成或暴露出來的 finding，有時會被開成 follow up task。結果是任務關了，它該負責的工作還開著；defect 被移到一個沒有人負責的 queue。定規則時的紀錄裡舉了一個例子，說這是最尖銳的版本：第四輪的修補引入了 regression，那是第四輪自己的工作，就算是第五輪才找到它，也不會因此變成別人的事。

往 board 塞。 Round 看到無關的東西就當場開任務。這樣 backlog 長大靠的是發現，不是決定。

這條規則的歷史紀錄裡有句話，我覺得講得最準：Discovery is not authority。看到了，不等於有權決定這件事要做。

規則怎麼寫

定規則時的紀錄寫得很直接：review 的每一輪是完成任務的方式，不是任務的來源。規則本身是這樣寫的。

先講 ownership：

• Finding 屬於被審的任務。
• Review 問的是目前這個任務對不對、完不完整，不是用來製造工作的。
• Follow up task 從來不是未完成工作離開任務的方式。

再講 board：

• Review 不往 board 加任務，只有一條明文裁定的例外。例外存在，細節不在這篇的範圍。
• 開任務，不管走 board_add.py 還是 /scrum add，都是規劃或 triage 決定，要刻意做，而且在 review loop 之外做。
• 「actionable」「重要」「值得改進」都不是判準。

Board 規則裡另外有條通用的 scope 判準，我覺得比上面那些都好用：如果這個變更不做，這個任務還能誠實地說它完成了嗎？ 不能，就留在任務裡做完。新任務只開給真正獨立的東西。

先分類，再處理

「finding 屬於被審的任務」和「review 不往 board 加任務」這兩條，是 2026-09-06 定的。隔天 2026-09-07 又補了一步：review 改成五個有名字的 stage，第一步由人先凍結任務的 intent 和 scope，寫成 contract，之後才讓 AI reader 看 diff。contract 寫明哪些可以改、哪些必須維持，以及後面的 finding 要違反什麼才算數。

每個 candidate issue 先問它是不是 finding。Finding 要指出它違反的 architecture contract 條款，或者證明已經授權的行為在具體路徑上失敗，並附上 evidence。

其他的一律是 observation：不同的設計、更寬的介面、contract 沒要求的功能，都算。Observation：

• 不擋任何 stage 結束；
• 本身不授權任何變更；
• 不會被提出它的那個 round 開成新的 board 任務；
• 記到 task register 上的 observation ledger。

這個分類不是憑感覺加的，證據來自另一個任務的 review 紀錄。沒有 finding / observation 區分之前，round 2 到 round 4 分別回了 4、4、6 個 candidate issue，其中五個其實是 design proposal，卻被當成 defect 處理。有條規則為了追這些東西，從 17 行長到 31 行，後來才縮回去。套上分類問題之後，留下來的 candidate issue 每個都是可以用指令檢查的違規，design proposal 全部記錄下來，不擋流程。

前後差在哪

以前，有兩種情況會讓 board 多出任務：變更自己造成或暴露出來的 finding，有時被開成 follow up task，推出這個任務；跟變更無關的東西，round 一看到就當場開任務。

現在，round 提出問題，先問它有沒有指出違反的條款，或證明行為在具體路徑上失敗：是 finding，就在這個任務裡修掉；是 observation，就進 task ledger，交給人決定。要不要開新任務，發生在 loop 外面。

寫「finding 屬於被審任務」這條規則的任務，自己先照著跑了。它跑了七輪 review，最後一輪乾淨收尾。它拒絕替自己 rounds 找到的 finding 開任務，理由很單純：每個 finding 都是這次變更造成的，也都在任務裡修掉了。順帶看到、跟變更無關的兩個問題，則照新規則只回報，不開任務。

收在哪，還沒解決的

收在這裡：review 只回答「這個任務做完了沒有」，不負責決定接下來要做什麼。

那兩個只回報、沒開任務的問題，我回頭查了：失敗的那個測試，board 上有它自己的任務；過時的 review 描述出現在兩個地方，一處當時就已經有別的任務在管，另一處也有自己的任務。這幾個任務現在都已經關閉。

還沒解決的部分，照寫：

• 寫這條規則的那個任務關閉時，還帶著最後一輪留下的幾條 observation，當時不擋流程，也沒修。
• 這次兩個問題剛好都有任務接得住。規則說這類問題可以回報，值得保留的話，記成任務上的 observation；但沒有說回報給誰、由誰接手。

除了開頭提到的那條例外，開不開任務不是 review 的事，而是 loop 之外的規劃或 triage 決定。隔天加上的分類也一樣：observation 的預設狀態是 recorded，只有人能改。規則把「發現」和「決定」拆開了，但「決定」這一端，現在還是只靠人。