idd-close 的 checklist gate 對 Spectra path 永遠 fallback 掃 Strategy——那些 checkbox 沒有任何一步會勾

[kiki830621]

Type

bug

Problem

idd-close Step 0 的 checklist gate 用 authoritative-source 優先序決定掃哪些 checkbox：

authoritative_source = first_exists([
  "## Implementation Complete > ### Checklist",   # idd-implement Step 5 寫回
  "

---

### Clarity Surface（idd-clarify run 2026-08-05T02:30:00Z）

| Type | Source | Suggested canonical | Status |
|---|---|---|---|
| missing-context | 「`authoritative_source = first_exists([...])`」 | **`exists` 的判準未定義**。canonical rule（`rules/append-vs-modify.md`）零次提及 `len` / non-empty；四個消費端只有 `idd-close` Step 0 寫出 `len(impl_complete.items) > 0`，且**只對 priority 1**。`idd-verify` / `idd-update` 只引 `first_exists([...])` 無條件。實作前必須先定義：`exists` ＝「heading 在」還是「heading 在且 ≥1 個可解析項目」 | **resolved @ 2026-08-05T02:32:00Z**（裁決：採「heading 在且 ≥1 個可解析項目」，並寫進 canonical rule 使三個 consumer 一致。依據：`idd-close` 既有實作已如此、且是唯一既有實作——這是讓文件追上程式碼，不是新決定）|
| ambiguity | 「無來源時 `### Tasks` 該省略還是寫**空節**」（診斷的未決點 2） | 「空節」有兩種且對 `first_exists` 意義不同：(a) 只有 heading 無任何 row；(b) heading ＋ `(none)` marker row。**且若沿用 `idd-close` 的 `len > 0`，兩者都不會 resolve** → 診斷裡寫的「gate 什麼都不掃」風險**不存在**。該未決點很可能是我沒查判準就下的判斷，而非真的分岔 | **dismissed @ 2026-08-05T02:32:00Z**（已由 `idd-close` 的 `len(items) > 0` 與其 edge-case 表「存在但 0 items → 視同不存在 → Legacy fallback」回答。原診斷寫的放寬風險不存在——那是我未查判準的誤判）|
| terminology | 「四個 gate site（`idd-close` / `idd-verify` / `idd-update` / `idd-implement`）」 | `idd-implement` 實際是 **producer 不是 consumer**——它 Step 5a 只**寫** priority 1，不執行 resolution（該檔內 `authoritative_source` 僅出現在說明散文）。用詞不精確會讓人以為修 producer 需同步改四處 gate 邏輯；實際是「1 producer ＋ 3 consumer」 | **resolved @ 2026-08-05T02:32:00Z**（裁決：canonical rule 改稱「1 producer（`idd-implement` Step 5a）＋ 3 consumer（`idd-close` / `idd-verify` / `idd-update`）」。依據：`idd-implement` 檔內 `authoritative_source` 僅出現於說明散文，不執行 resolution）|

---

## Current Status

**Phase**: closed
**Last updated**: 2026-08-05 by /idd-close

### Key Decisions
- **結案**：PR #291 已 merge（merge commit `dc2601f`）。全套件 43 suite / 0 失敗。
- 根因比 issue 描述更根本：priority 2 **沒有任何 producer**，chain 實務上塌縮成「只有 priority 1」，而它只有 `idd-implement` 產生。
- 裁決 A/B/C′/D 由使用者授權判斷；C 經 discuss 修正為「向 CLI **查**路徑而非組路徑」，並加 **toplevel 圍籬**（實測 registry 會回傳 sibling worktree 路徑）。
- cross-model verify 抓到兩個嚴重缺陷：修法**在自己的 pipeline 裡活不過一步**（整段替換會抹掉剛寫入的 `### Tasks`）、圍籬 **fail-open**（`TOP=""` → pattern `/*`）。

### Scope Changes
- 從「修 idd-close 的 gate」擴成「補上契約 priority 2 的 producer」——修法位置移到 `idd-update`，影響面從一個 gate 變成整個 resolution。

### Blocking
- (none) — 已結案。

### Tasks

*本小節由 `idd-update --tasks-file openspec/changes/add-authoritative-source-producer/tasks.md` 產生——**這是本次新增機制的第一次實際使用**。圍籬已套用（路徑在當前 toplevel 內），14 個可解析項目 > 0 故 resolve，Strategy 依 canonical 規則視為 superseded snapshot。*

- [x] 1.1 寫出**會失敗**的 fixture 測試（`plugins/issue-driven-dev/scripts/tests/authoritative-source-pr
- [x] 1.2 同檔加 drift-lock：斷言 `rules/append-vs-modify.md` 含 `exists` 的判準文字與「1 producer ＋ 3 consum
- [x] 1.3 同檔加**圍籬測試**：用 `git worktree add` 建**真的**第二個工作樹（不是只換字串的假 fixture——實際遇到的情形正是同 repo 跨 wo
- [x] 2.1 `idd-update/SKILL.md` 新增 `--tasks-file <path>` 的參數說明與 Step 4 模板的 `### Tasks` 小節：內容為來源
- [x] 2.2 同檔寫入圍籬規範：路徑解析為絕對路徑後必須以 `git -C "$CWD" rev-parse --show-toplevel` 為前綴，否則**拒絕**、印出兩個路徑、
- [x] 2.3 同檔寫明三種不 emit 的情形：flag 缺席、檔案不存在（警告不中止）、檔案零個 checkbox 行。並說明「不 emit」而非「emit 空節」的理由（不製造需要
- [x] 2.4 `idd-all/SKILL.md` 的 Spectra 分支在收尾呼叫 `idd-update` 時附上 `--tasks-file`，路徑取自對外部工具 CLI 的*
- [x] 3.1 `rules/append-vs-modify.md` 的 resolution 段落定義 `exists` ＝ heading 在**且**至少一個可解析項目，並註明此
- [x] 3.2 同檔把「4 個 gate site」改為具名的「1 producer（`idd-implement` Step 5a）＋ 3 consumer（`idd-close` S
- [x] 3.3 同檔新增不變式：**優先序的每一層都必須指名 producer**；沒有 producer 的層無法 resolve，會讓優先序靜默塌縮。註明本不變式無法被測試強制（它約
- [x] 3.4 `idd-close/SKILL.md` Step 0 的 `exists` 敘述與新的 canonical 定義對齊（它原本只對第一層寫 `len(items) > 0
- [x] 4.1 確認第一層行為**逐字未變**：以 `git diff` 確認 `idd-implement/SKILL.md` 的 Step 5a 敘述未被修改，且 `rules/ap
- [x] 4.2 確認**未硬編外部佈局**：`grep -rn 'openspec/changes' plugins/issue-driven-dev/skills/ plugins/i
- [x] 4.3 跑既有測試 runner，全數通過；記錄變更前後的測試數量。驗證目標：runner 全綠，新測試出現在清單中。

### Commits
- PR **#291**（merge commit `dc2601f`）：`b692d9d` producer ＋ exists 判準 · `58a51b9` cross-model verify round 1
- 另含兩個與本 issue 無關的清理 commit（`7e3c87a` / `d1041f3`），成因與更正見 PR pointer comment

[kiki830621]

Diagnosis

Type

bug

Root Cause / Analysis

Issue 的敘述正確，但根因比它描述的更根本——而且不只影響 Spectra path。

rules/append-vs-modify.md:169-174 是 canonical 契約，被四個 gate site 共用（idd-close Step 0 / idd-verify checklist scan / idd-update body sync / idd-implement Step 5）：

authoritative_source = first_exists([
  "## Implementation Complete > ### Checklist",
  "## Current Status > ### Tasks",
  "## Todo" | "## Tasks" | "## Checklist"
])

逐條追誰產生它：

優先序	來源	Producer
1	## Implementation Complete > ### Checklist	idd-implement Step 5
2	## Current Status > ### Tasks	無
3	## Todo / ## Tasks / ## Checklist	無（只有人手寫）

priority 2 沒有任何 producer。 idd-update Step 4 的 Current Status 模板實際只 emit 四個小節：

### Key Decisions   ### Scope Changes   ### Blocking   ### Commits

沒有 ### Tasks。全 repo grep '### Tasks' 的結果只剩讀取端那一行（idd-update/SKILL.md:131）——這個來源被四個 gate 讀，但沒有任何 skill 寫它。

推論

resolution chain 在實務上退化成「只有 priority 1」。於是：

任何不經過 idd-implement 的路徑，都沒有 authoritative source → fallback 掃 Strategy → 撞上那些「沒有任何一步會勾」的 checkbox。

Spectra path 只是第一個被撞到的實例，不是唯一的：外部 agent 委派（idd-verify --pr）、手動 direct-commit 修復、idd-all-chain 的 cluster 路徑，同樣不產生 ## Implementation Complete。

所以這不是「Spectra 沒接上 IDD」，是契約的第二層從來沒被實作。

Impact

• plugins/issue-driven-dev/skills/idd-update/SKILL.md — Step 4 模板（producer 端）
• plugins/issue-driven-dev/rules/append-vs-modify.md — 契約文件需說明 priority 2 由誰產生
• 連帶修好四個 gate（它們共用同一份 resolution），而非只有 idd-close
• 影響所有非 idd-implement 路徑的 close gate，不限 Spectra

Strategy

• 決定 ### Tasks 的內容來源與偵測方式（見下方三個未決點）
• idd-update Step 4 模板新增 ### Tasks 小節，並定義「無可用來源時」的行為（省略 vs 空節——兩者對 first_exists 意義不同）
• rules/append-vs-modify.md 標明 priority 2 的 producer，補上「每一層都必須有 producer」的不變式
• 回歸測試：Spectra path 的 issue 走到 idd-close 不再被 Strategy 擋
• 確認 idd-implement 路徑行為逐字不變（priority 1 仍先命中）

三個未決點（實作前需裁決）

1. ### Tasks 從哪裡讀？ Spectra 的進度在 openspec/changes/<name>/tasks.md，但 <name> 無法從 issue 編號推導。候選：spectra list --json 取唯一 active change／掃 openspec/changes/*/proposal.md 找引用 #N 者／要求 idd-update 收 --change flag。
2. 非 Spectra、非 idd-implement 的路徑呢？（手動修復、外部 agent）那些既沒有 tasks.md 也沒有 Implementation Complete。### Tasks 該省略（維持現行 fallback）還是寫「無 checklist」？後者會讓 gate 從「掃 Strategy」變成「什麼都不掃」——那是放寬，需明確裁決。
3. 耦合方向。方向 3 只需讀一個檔案路徑（file-layout 耦合），比方向 1（spectra 產生 IDD 格式的 comment，protocol 耦合）輕得多；但仍是 IDD 認得 Spectra 的佈局。可接受與否要拍板。

Conflict Class

C_shared_module_coord — 共享資源具名：plugins/issue-driven-dev/rules/append-vs-modify.md 的 authoritative_source resolution 契約，被 idd-close / idd-verify / idd-update / idd-implement 四個 skill 共同消費。動 producer 端會同時改變四者的 gate 行為，不可與其他觸碰同契約的工作交錯。

Complexity

Spectra

• Layer 2 ✓：authoritative_source resolution 是 rules/append-vs-modify.md 裡的 normative 契約，被四個 skill 消費；## Current Status 的區塊格式也是其他 skill 讀取的已發布 surface。改變「誰產生 priority 2」就是改變該契約對 future callers 的行為。
• Layer 3 ✓（兩項）：
  • 影響 2+ 既有 spec 需要 consistency-checking —— 四個 gate site ＋ 契約文件本身。
  • Architectural decision with long-term maintenance implications —— 「IDD 如何得知工作已完成」在非 idd-implement 路徑上的答案，是後人繼承的結構性決定。
• 硬閘（若未落 Spectra 也會評）：預估觸及 idd-update / append-vs-modify.md ＋ 四個 gate 的說明同步 ≥ 5 檔，且動的正是被 ≥ 2 檔引用的 shared abstraction。

Hard-gate: not evaluated — routing 序列上 Spectra（Layer 2+3）先命中即停。

→ 建議 pre-implementation staging: superpowers:brainstorming（非綁定）

Risks

• 放寬 gate 的風險：若 ### Tasks 在無來源時寫成空節，first_exists 會命中一個空清單 → gate 什麼都不掃 → 從「過度攔截」翻轉成「完全不攔截」。未決點 2 必須明確裁決，不能靠實作時順手決定。
• priority 1 的行為必須逐字不變：idd-implement 路徑是既有的 happy path，任何改動都是 regression 面。
• 偵測 change dir 的脆弱性：靠「唯一 active change」在多 change 並行時會挑錯；靠掃 proposal 找 #N 依賴人有寫 issue ref。
• 跨 plugin：idd-update 讀 openspec/ 佈局，等於 IDD 認得 Spectra 的檔案結構。Spectra 若改佈局會靜默失效——需要一個「找不到就退回現行行為」的 fail-safe。

Residue

Issue 的 horizon 是「一個每次都得繞過的 gate，會養成它想防止的肌肉記憶」。這個變更能讓 Spectra path 不再撞牆，但回答不了「還有哪些路徑沒有 producer」——今天知道的是 Spectra、外部 agent、手動修復三類，明天可能有第四類。

真正治本的是在契約層加一條不變式：resolution chain 的每一層都必須指名 producer，缺 producer 的層要嘛補上、要嘛從 chain 移除。那條不變式本身無法被測試強制（它是關於「未來新增的層」的約束），只能寫進契約文件並靠 review 維持——這是誠實的縮減，不是完整解。---

Vagueness Pre-check

• V1（vague WHAT）: 2 — issue 精確描述機制（引 resolution 優先序原文）、列出三個 Spectra path 都不具備的來源、附下游實例。診斷只是把根因再往下推了一層（priority 2 無 producer）。
• V4（vague ACCEPTANCE）: 4 — issue 明列三個候選方向但未裁決，且未定義「修好」的可測判準。診斷已把它具體化為三個未決點 ＋ 五條 Strategy。
• Triggered: yes（max=4）
• Unattended 處置: [Layer V: V1=2 V4=4, clarify-default skipped under unattended mode, defaulting to proceed]

Layer V Deferred Record

• Reason: unattended-auto-Step-3.4-layerV-deferred
• V1: 2 — 機制描述精確、附原文與下游實例
• V4: 4 — 三個候選方向未裁決，無可測的完成判準
• Catch-up: /idd-clarify idd-close 的 checklist gate 對 Spectra path 永遠 fallback 掃 Strategy——那些 checkbox 沒有任何一步會勾 #290 —— 人回場後就上方「三個未決點」拍板（尤其未決點 2：無來源時 ### Tasks 該省略還是寫空節。後者會讓 gate 從過度攔截翻轉成完全不攔截，是放寬，必須明確決定而非實作時順手）

Sister Concerns Filed (mid-diagnose)

未開新 issue。 診斷浮出一項比本 issue 更廣的觀察：resolution chain 的每一層都應該有指名的 producer，而 priority 2 沒有、priority 3 只有人手寫。這不只是「補一個 producer」，是契約層缺一條不變式。

依 skip taxonomy 屬 (a) 尚不可行動——那條不變式的正確形狀取決於上方三個未決點怎麼裁決（尤其未決點 2 決定了「無來源」是合法狀態還是缺陷）。裁決之後若仍成立，屆時再開。已寫入本 Diagnosis 的 ### Residue，不會遺失。

Source: surfaced during /idd-diagnose #290 sister concern surfacing (Step 3.6)

[kiki830621]

設計裁決（未決點 1 ＋ 3）

使用者於 2026-08-05 授權由本次判斷拍板。三個未決點的處置：未決點 2 已 dismiss（見 Clarity Surface row 2——它是未查判準的誤判），1 與 3 併成同一個答案。

裁決：idd-update 收 --tasks-file <path>，而非 change name

原本三個候選都預設「IDD 要找到 Spectra 的 change 目錄」：

原候選	問題
spectra list --json 取唯一 active	多個 active change 時挑錯（本 session 當下就有 2 parked ＋ 1 active）
掃 openspec/changes/*/proposal.md 找 #N	依賴人有寫 issue ref，且格式無保證
收 --change <name>	較穩，但 IDD 仍須知道 openspec/changes/<name>/tasks.md 這個佈局

改為收路徑，三個問題一起消失：

/idd-update #N --tasks-file openspec/changes/add-person-died/tasks.md

• IDD 對 Spectra 的知識降為零 —— 它只是「讀一個含 checkbox 的 markdown 檔」。樹內不出現 openspec/ 字串，Spectra 改佈局不會靜默失效。
• 重用既有機制 —— idd-close Step 0 已有 checkbox regex ^\s*-\s*\[(.)\]\s*(.+)$，不新增解析器。
• 由知道的人傳 —— idd-all Phase 3b.3 已經捕捉 Change: <name> 並 thread 給 spectra-apply（見 idd-all SKILL.md:692/705），再 thread 一層到收尾的 idd-update 是既有資料流的延伸。
• 泛化 —— 任何外部工具只要有 checkbox 檔都能餵進來，不限 Spectra。

缺席時的行為

flag 未給 → 不 emit ### Tasks（不是 emit 空節）。理由：配合 Clarity Surface row 1 的裁決（exists ＝ heading 在且 ≥1 個可解析項目），空節本來就不會 resolve；但「不寫」比「寫了不算」少一層需要解釋的東西。

行為退回現行 fallback ——idd-implement Step 5a 早已把這個情形寫成已知行為：

若本 Step 跳過（無 Implementation Complete > Checklist），downstream gate fall back legacy scan all sources（保留 backward compat，但 Strategy/Plan checkbox 會被視為「未完成」可能 refuse close）

也就是說：standalone spectra-apply（無 orchestrator 傳 flag）仍會撞牆。這是本裁決明知接受的殘留——修好的是 idd-all 驅動的 Spectra path（主要場景），不是所有場景。要全覆蓋需要 Spectra 端主動告知，那就回到方向 1 的 protocol 耦合，成本高於收益。

依據強度（誠實標示）

決定	依據
exists ＝ heading 在且 ≥1 項	強 —— idd-close 既有實作已如此、且是唯一既有實作。文件追上程式碼。
1 producer ＋ 3 consumer 的用詞	強 —— idd-implement 檔內該詞僅出現於散文，不執行 resolution。
收路徑而非 change name	中強 —— 兩個前提已查證（idd-all 握有 change name、IDD 已有 checkbox regex）；但「收路徑比收名字好」是設計判斷，非事實推導。可被更好的方案取代。
flag 缺席時不 emit	中 —— 與 row 1 裁決自洽，但「不寫 vs 寫空節」兩者行為等價，選前者是可讀性偏好。

[kiki830621]

Verify: #290

Engine

Codex（gpt-5.6-sol / effort xhigh，1 輪）＋ coordinator self-review

⚠️ 同 #67 / #84：session 有 standing instruction 禁止未經請求呼叫 AgentTool / Workflow，故走純 Bash codex engine。2 個視角而非 6 個，DA 由 coordinator 自己扮演。

要求覆蓋率

14/14 tasks 完成。三條 spec requirement 全數有對應實作與測試。

Findings（合併後）

#	Severity	Finding	Source	Action
1	HIGH	修法在自己的 pipeline 裡活不過一步——managed zone 是整段替換，「未給 flag ＝ 不輸出」使得 Phase 4 的 Auto-Update 會抹掉 Phase 3b.5 剛寫入的 ### Tasks	codex	✅ 改為「未給 flag 時逐字保留既有」；路徑壞掉視同未給
2	HIGH	圍籬 fail-open——TOP="" 時 pattern 變 /*，任何絕對路徑都通過	codex	✅ 三道檢查，toplevel 解析失敗 fail-closed
3	MEDIUM	最後一段的 symlink 可繞過圍籬（只解析 dirname）。我先前的探測測了 symlink 目錄，漏了 symlink 檔案	codex	✅ 改用 readlink -f 解析整條路徑
4	MEDIUM	Step 4 模板無條件列出 ### Tasks ＋ 可解析的 placeholder checkbox → 照模板輸出會製造假的 authoritative source	codex	✅ 改為條件註記
5	MEDIUM	自相矛盾：標題「1 producer ＋ 3 consumer」，表卻列兩個 producer，且 idd-update 同時是兩者	codex	✅ 改為角色矩陣，明說非互斥
6	MEDIUM	不變式自相矛盾：「每層都必須指名 producer」vs priority 3「無（僅人手寫）」	codex	✅ 改為「具名或明示無」
7	LOW	query 未在 $CWD 下執行；路徑未加引號	codex	✅ 兩者已修
8	LOW	「零 backward-compat 破壞」過度宣稱——另兩個 consumer 的舊契約未定義 emptiness，無相容性保證；且新增 producer 本來就刻意改變 gate 結果	codex	✅ 見下方誠實邊界
9	LOW	「樹內零硬編外部目錄名」字面不成立（design/tasks 的散文與驗證指令含之，change 本身也住在那）	codex	✅ 宣稱限縮為「新增的 skills/ 與 rules/ 敘述不依目錄慣例組路徑」——該範圍已驗證 0 命中
10	INFO	測試沒有執行 skill 本身，只驗測試檔內重實作的邏輯 ＋ drift-lock	codex ＋ self	不修——這是本 repo markdown-skill 測試的既有形狀（doc-sync-sweep 同構）。誠實記在下方，不宣稱測試證明了行為
11	INFO	containment 只證明「同一工作樹」，不證明「屬於本次 change」	codex	不修——同一工作樹內指錯 change 仍可能假陽性，但那需要呼叫端傳錯，屬另一層問題

我自己在本輪犯的

• 探測不完整：測 symlink 時只建了 symlink 目錄（被 pwd -P 擋住），沒測 symlink 檔案（會繞過）。結論「symlink 逃逸被擋住」因此是錯的，由 Codex 指出。
• 兩條 drift-lock needle 寫錯：一條被 markdown 粗體 **或** 切斷、一條用 \| 但 assert_grep 是字面比對。兩條都是「測試抓不到東西」，在專門修這類缺陷的 change 裡。
• 更早一輪還有 assert_grep "name" -- "needle" 的 -- 讓 needle 變成 -- 的假通過。

同一類錯誤在本 change 內出現三次。 共同結構：宣稱測試證明了什麼，而沒有讀輸出確認它真的會失敗。

誠實邊界

• exists 變更不是零 backward-compat 影響。 對 idd-close priority 1 相容（舊文已要求 len > 0）；對另兩個 consumer 與其餘候選，舊契約未定義 emptiness，故無相容性保證。且新增 priority-2 producer 本來就刻意改變 gate 結果——這是本 change 的目的，不是副作用。
• 測試不證明 skill 行為。 drift-lock 只證明「文字在檔案裡」；fixture 驗的是測試檔內重實作的邏輯。SKILL.md 的條件若被反轉、刪除或仍 fail-open，drift-lock 仍可通過。這是本 repo markdown-skill 測試的固有限制，非本 change 引入。
• 三條路徑仍未覆蓋：standalone spectra apply（無 orchestrator 傳 flag）、外部 agent 委派、手動 direct-commit。已寫進 proposal 的 Non-Goals。

Scope Check

• idd-implement/SKILL.md diff 0 行（第一層行為逐字未變）
• 新增敘述中 openspec/changes 0 命中（限 skills/ 與 rules/）
• 全套件 43 suite / 0 失敗；本 change 新增 24 個斷言

Verdict

PASS — 0 blocking，2 commits（b692d9d / 58a51b9）。

[kiki830621]

PR 已開：#291

分支 idd/290-authoritative-source-priority2-producer。停在 verified——merge 後請跑 /idd-close。

已確認未被連結為 auto-close，commit message 通過 trap 掃描（零命中）。

---

更正（本 comment 原文有誤）

原文寫「兩個清理 commit 與本 issue 無關、未混進本 PR」——那是錯的。PR #291 實際含 4 個 commit：

commit	屬於
7e3c87a 補 21 個 attachment manifest	清理，與本 issue 無關
d1041f3 ignore 機器本地暫存	清理，與本 issue 無關
b692d9d producer ＋ exists 判準	#290
58a51b9 cross-model verify round 1	#290

原因：清理 commit 打在本地 main，分支從 main 開出，於是繼承了它們；origin/main 沒有 → 出現在 PR diff。先前說「未 push」在當時為真，說「未混進本 PR」在推分支後為假。

兩個清理 commit 本來就需要落地（執行 repo 自己 .gitignore 註解宣告的政策），內容是 21 個 "files": [] 的空 manifest ＋ 兩條 ignore 規則，無第三方內容。要拆成獨立 PR 也可以，但 review 成本可能高於收益。

[kiki830621]

Closing Summary

Problem

authoritative_source 的三層優先序被 consumer 讀，用來決定「哪一份 checklist 才算數」。任何繞過 idd-implement 的路徑走到 idd-close 時都會被擋——fallback 去掃 diagnosis 當初寫的 pre-implementation checkbox，而那些在該流程裡沒有任何一步會勾。

下游實證：一個走完 19/19 tasks、跨模型驗證 0 blocking、PR 已開的 issue，被 7 個 - [ ] 擋在門外，唯一解法是人工 PATCH diagnosis comment。

Root Cause

第二層（## Current Status > ### Tasks）沒有任何 producer。

idd-update 的 Current Status 模板只 emit Key Decisions / Scope Changes / Blocking / Commits；全 repo 搜 ### Tasks 只剩讀取端那一行。三個 consumer 讀它，沒有一個 skill 寫它。

於是 chain 實務上退化成「只有第一層」，而它只有 idd-implement Step 5a 產生。idd-implement 自己甚至把這個情形寫成已知行為（「Strategy/Plan checkbox 會被視為未完成可能 refuse close」），只是框成 backward compat 而非缺口。

第二個缺口：first_exists 的 exists 判準未定義——canonical rule 零次提及 non-empty，三個 consumer 只有 idd-close 寫出 len > 0 且只對第一層。

Solution

項	內容
producer	idd-update 收 --tasks-file <path>，據以 emit 第二層
路徑來源	由呼叫端查詢外部工具取得（contextFiles.tasks），不由任何一方從「名稱＋目錄慣例」組出——組路徑只是把佈局知識換個位置，對方改佈局會靜默失效
圍籬	三道：toplevel 解析失敗 fail-closed、必須是可讀的一般檔案、整條路徑 realpath 解析
保留語意	未給 flag 時逐字保留既有 ### Tasks；路徑壞掉視同未給——拒絕一個壞路徑不得順帶刪掉一份好的既有 checklist
exists	升為 canonical：heading 在且 ≥1 個可解析項目，三個 consumer 一致
角色	「4 個 gate site」→ 角色矩陣（idd-update 同時是 producer 與 consumer）
不變式	每層必須具名 producer 或明示無自動 producer——不得留白（留白正是本 bug 的成因）

圍籬為何必要：實測某工作目錄下查詢，回傳路徑指向同一 repo 的另一個 git worktree（registry 不是 cwd-scoped）。若原樣採用，gate 會讀另一工作樹的完成狀態——那份若全 [x]，一個沒做完的 issue 會通過 close gate。修一個假陰性卻引入假陽性，後者嚴重得多：前者會被人擋下並抱怨，後者沒人會發現。

Verification

跨模型盲驗（Codex gpt-5.6-sol / xhigh）一輪，六項成立、兩項嚴重、全部修完：

1. 修法在自己的 pipeline 裡活不過一步——managed zone 是整段替換，「未給 flag ＝ 不輸出」使 Phase 4 的 Auto-Update 會抹掉 Phase 3b.5 剛寫入的 ### Tasks。我測了「寫得進去」，沒測「留得住」。
2. 圍籬 fail-open——TOP="" 時 pattern 變 /*，任何絕對路徑都通過。
3. 最後一段的 symlink 可繞過（我的探測只測了 symlink 目錄，漏了 symlink 檔案）。
4. Step 4 模板無條件列出 ### Tasks ＋ 可解析 placeholder → 會製造假的 authoritative source。
5. 「1 producer ＋ 3 consumer」與底下列兩個 producer 的表自相矛盾。
6. 不變式「每層都必須指名 producer」與 priority 3「無」自相矛盾。

24 個斷言（12 機制 ＋ 12 drift-lock），全套件 43 suite / 0 失敗。idd-implement/SKILL.md diff 0 行。

本 issue 的 close 是機制的第一次實際使用：body 的 ### Tasks 由 --tasks-file 產生（圍籬已套用、14 個項目 > 0 故 resolve），Strategy 依 canonical 規則視為 superseded——gate 從 priority 2 合法通過，不需人工勾 Strategy。

Changes

PR #291（merge commit dc2601f）：b692d9d producer ＋ exists 判準 · 58a51b9 cross-model verify round 1。另含兩個與本 issue 無關的清理 commit（7e3c87a / d1041f3）。

Residue

本 issue 的 horizon 是「一個每次都得繞過的 gate，會養成它想防止的肌肉記憶」。修好的是「有 checklist 檔案可指」的路徑，三條路徑仍未覆蓋：standalone spectra apply（無 orchestrator 傳 flag）、外部 agent 委派（工作在別處，無檔案）、手動 direct-commit 修復（根本沒有 checklist）。

第三條在本次 merge 後的第一分鐘就自我驗證了：PsychQuant/Akashic-Library#84 走 Simple tier、未經 idd-implement、無 tasks.md，close 時仍需人工勾 Strategy。Non-Goals 寫的不是託辭，是真的。

另一項殘留：新增的不變式（每層必須具名 producer 或明示無）無法被測試強制——它約束的是未來新增的層，而未來的層尚不存在。只能靠 review 維持。

還有：drift-lock 只證明「文字在檔案裡」，不證明行為；fixture 驗的是測試檔內重實作的邏輯。SKILL.md 的條件若被反轉、刪除或仍 fail-open，drift-lock 仍可通過。這是本 repo markdown-skill 測試的固有限制，非本 change 引入，但也因此不能宣稱測試擋得住回歸。