一個大型工作項目終於被標成 Done。

週報也跟著更新：

Parent task: Done
Progress: 100%

主管看了一眼，準備把這個項目從追蹤清單拿掉。

隔天，另一位工程師在看個人 Queue 時發現兩張 Sub-task 還是：

Open
Open

其中一張甚至還沒有 Owner。

大家第一個反應是：

「Parent 都 Done 了，Child 為什麼沒一起關？」

有人以為是 Automation 漏跑。

後來才發現，根本沒有任何規則保證 Parent Transition 會同步改 Child。

Parent 的 State 是真的。

Child 的 State 也是真的。

只是大家把上層完成，當成了下層狀態的證明。

Hierarchy 很容易讓人產生「應該會一起變」的直覺

當一個系統有：

Parent
└─ Child A
└─ Child B
└─ Child C

人會自然把它理解成一個整體。

所以 Parent Close，看起來就像整組工作結束。

但在實際 Workflow 裡，Parent 和 Child 可能各自是獨立 Object。

各自有：

• Status
• Owner
• Transition
• Verification

Package 裡的 Action Rule 因此明確禁止假設：

Parent transition 會自動同步 Sub-task。

Affected Child 必須各自查詢、執行與 Verify。

Parent State 是一份 Evidence，但它只證明 Parent

這個問題跟前面的 Source Responsibility 很像，只是現在 Evidence 變成了 State。

當你看到：

Parent = Done

它真正能證明的是：

Parent Object 目前是 Done。

如果要說：

所有 Child 都完成。

還需要 Child 自己的 State。

不能因為它們有結構關係，就把上層 State 自動投射到下層。

這在 Agent 自動化中特別重要。

因為 Agent 很容易根據 Parent Result 產生一句很自然的 Summary：

All related work has been completed.

如果它沒有實際 Query Child，這句話其實已經超過 Evidence。

不一定要阻止 Parent 先 Done

有人提議：

「那以後 Parent 只要有任何 Child Open，就不准 Close。」

這可能適合某些 Workflow。

但不是這個 Source 已經證明的唯一正確規則。

有些流程允許 Parent 和 Child 有不同 Lifecycle。

真正穩定的做法不是替所有系統發明同一個 Parent/Child Policy。

而是：

不要假設 State 會傳遞；如果這次工作宣稱影響 Child，就逐一確認。

例如使用者說：

把整組工作全部結束。

那 Action Scope 就包含 Parent + Child。

系統應該逐一 Execute / Verify。

如果使用者只說：

Close Parent。

就不能順手推論 Child 也應該一起改。

他們把「全部完成」改成可驗證的句子

後來週報不再只從 Parent State 產生百分比。

當報告需要說「整組工作完成」時，Agent 會先讀受影響的 Child。

結果可能是：

Parent: Done
Child A: Done
Child B: Open
Child C: Done

Overall: Not fully completed

這看起來沒有原本的 100% 漂亮。

但至少它不再用一個 Object 的 State 替其他 Object 作證。

幾天後，另一組 Parent 被關閉。

Agent 重新查 Child。

三張都 Done。

這一次它才寫：

All related items completed.

同樣一句話。

只是這次，每一個 Child 都真的被看過。