feat: parked issue 無回訪機制 — ic-r011 宣稱的 periodic backlog grooming 不存在，且它 grep 的 blocker:* label 零使用

[kiki830621]

Problem

原始脈絡（逐字）：
「順便說 ，有沒有issue說遇到剩下的問題太容易residual而不是開後續issue了」

— Source: /spectra-discuss（#298 actionability gate），2026-08-14。該提問指向 #304；本 issue 是同場自審中從一段 ### Residue 拆出來的可執行部分。

IDD 有兩個機制會把 issue 移出視線，但沒有任何機制會把它移回來：

機制	把 issue 移出視線	誰負責移回來
parking-lot label（6 個 open issue 在用）	✓	無人
### Blocking 區塊（#84 Blocked 分組）	✓	無人
### Complexity 的 when triggered 限定詞	✓	無人

parked issue 的 trigger 條件全是關於未來世界狀態的散文命題（「等 ≥3 instances」「首次 trace-stale 實害事故」「≥1 個 plugin 要求 terminology extension」）。這類條件成立時不會發出事件 —— 沒有 webhook、沒有 CI 訊號、沒有任何東西會通知 repo。唯一能發現「trigger 已成立」的路徑是人主動回頭讀，而目前沒有任何機制促成這件事。

既有文件已假設這個機制存在，但它不存在

references/ic-r011-checkpoint.md:74 逐字：

Net effect: only (a) avoids filing. (b) and (c) preserve the parking lot — periodic backlog grooming can grep blocker:infeasible or blocker:waiting to revisit when conditions change.

這句話有兩個問題：

1. periodic backlog grooming 沒有任何實作 —— 沒有 skill、沒有 script、沒有 cron。整份 IC_R011 設計把「parking lot 不會爛掉」的責任外包給一個不存在的機制。
2. 它 grep 的 label 沒人用 —— blocker:infeasible / blocker:waiting 目前各 0 個 issue；實際在用的是 parking-lot（6 個）。即使 grooming 存在，也會掃到空集合。

這是本 repo 第三次出現同一個形狀：規格寫下來、從未接上（前兩次：parking-lot label 的 description 寫「/idd-list filter candidate」但 idd-list 不讀它，見 #298；blocker:* 慣例寫在文件但 0 使用）。

與 #298 的關係（配套，非額外功能）

#298 會讓 gate 正確地把 parked issue 從 Suggested-next 藏起來。藏得越乾淨，越沒人回頭看 —— 若沒有配套的回訪機制，#298 會讓這個問題變嚴重而不是變好。兩者應一併考慮。

Type

feature

Expected

一個把 parked issue 帶回視線的機制。形狀待 diagnose，候選：

• A. /idd-list 顯示 parked 時長 —— ⏸ parked 47d，超過門檻加視覺標記。零新指令，成本最低。
• B. /idd-list --parked 專用檢視 —— 列出全部 parked + 各自 trigger 條件 + 停留時長，供人定期掃。
• C. 週期性 grooming skill（/idd-groom 或併入既有 skill）—— 逐一提示「這個 parked 47 天了，trigger 成立了嗎？」，回答 yes → unpark。
• D. 只把 ic-r011-checkpoint.md:74 那句改成誠實敘述 —— 明說「目前無自動 grooming，靠人主動」，不做任何實作。

D 是誠實下限（至少不再宣稱有一個不存在的機制）；A 是成本最低的實質改善。

Actual

• 無任何機制回訪 parked issue
• ic-r011-checkpoint.md:74 宣稱有 periodic backlog grooming，實際不存在
• 該句 grep 的 blocker:* label 各 0 使用，與實際在用的 parking-lot 不符（vocabulary drift，見 idd-list / idd-all routing 讀不到「現在可不可以動」— Complexity 的 when-triggered 限定詞被截斷、parking-lot label 無 consumer（22-issue backlog 實測 8/9 誤路由） #298）
• parked issue 的停留時長在任何介面都看不到

Impact

面向	影響
references/ic-r011-checkpoint.md	:74 的宣稱與現實不符，需改為誠實敘述或補上實作
skills/idd-list/SKILL.md	候選 A / B 的落點；與 #298 同檔
#298	配套關係 —— #298 把 parked 藏得更乾淨，會放大本問題
6 個現有 parked issue	目前無人知道它們各自停了多久、trigger 是否已成立

Acceptance criteria

• ic-r011-checkpoint.md:74 的 periodic backlog grooming 宣稱與現實一致（補實作或改敘述，二擇一）
• 若選實作路徑：parked issue 的停留時長可見
• blocker:* vs parking-lot 的 vocabulary drift 與 idd-list / idd-all routing 讀不到「現在可不可以動」— Complexity 的 when-triggered 限定詞被截斷、parking-lot label 無 consumer（22-issue backlog 實測 8/9 誤路由） #298 一併收斂（不重複決定）
• 不新增「自動判定 trigger 是否成立」的企圖 —— 那是 idd-list / idd-all routing 讀不到「現在可不可以動」— Complexity 的 when-triggered 限定詞被截斷、parking-lot label 無 consumer（22-issue backlog 實測 8/9 誤路由） #298 已認定的認識論邊界，本 issue 只做「提示人去看」

Source

Carved out from a ### Residue I wrote in #298 的 diagnosis（2026-08-14）。原文把兩件事混在一起：

• 「無法機械判定 trigger 是否成立」—— 真 residue，認識論邊界，工程無解，留在 idd-list / idd-all routing 讀不到「現在可不可以動」— Complexity 的 when-triggered 限定詞被截斷、parking-lot label 無 consumer（22-issue backlog 實測 8/9 誤路由） #298
• 「沒有機制回頭問 parked issue 還算不算數」—— 可 operationalize，即本 issue

自審動機來自 #304（residue 的預設應為 file-as-follow-up）。本 issue 即是對該問題的一次實地應用：Residue 因為便宜，會把旁邊真的能做的東西一起吸進去。

Refs #298, #304, #84

---

Clarity Surface（idd-clarify run 2026-08-13T21:26:08Z）

Type	Source	Suggested canonical	Status
missing-context	「parked issue 的停留時長可見」（Acceptance criteria）	「停留時長」的起算點與資料來源未指定。 parking-lot label 的貼上時間不在 gh issue view --json 的任何欄位裡 —— 需查 issue timeline events API（gh api repos/:o/:r/issues/N/timeline 找 labeled event）。候選起算點：(a) label 貼上時間（需 timeline API，每 issue 一次額外請求）、(b) 最後一則 Diagnosis comment 時間（現成，但與 park 動作不同時）、(c) updatedAt（現成但會被任何編輯重置，語意錯）	surfaced
ambiguity	「停留時長可見」（同上）	呈現位置未定，且依候選 A/B/C 而異：A = 併進 /idd-list 既有列；B = 專用 --parked 檢視；C = grooming skill 的互動提示。三者對 idd-list 的改動幅度差很多	surfaced
ambiguity	「超過門檻加視覺標記」（候選 A）	門檻值未定。且門檻本身可能不該是固定天數 —— 不同 trigger 條件的合理等待期差異極大（「等 ≥3 instances」可能合理等一年；「等 PR #247 merge」等一週就該問）	surfaced

[kiki830621]

Closing Summary

Problem

IDD 有三個機制會把 issue 移出視線（parking-lot label、### Blocking 區塊、### Complexity 的 when triggered 限定詞），但沒有任何機制會把它移回來。而 references/ic-r011-checkpoint.md 逐字宣稱 grooming 可以做到：

periodic backlog grooming can grep blocker:infeasible or blocker:waiting to revisit when conditions change

Root Cause

那句話的兩個部分都不成立，實測本 repo：

• gh label list 裡 blocker:infeasible 與 blocker:waiting 一次都沒有被建立過 —— 要 grep 的東西沒有實體。
• 沒有任何 periodic grooming 存在 —— 沒有排程、沒有 CI、沒有任何 skill 會主動回頭看。

而這件事之所以要緊，在於 parked issue 的 trigger 條件全是關於未來世界狀態的散文命題（「等 ≥3 instances」「首次 trace-stale 實害事故」「≥1 個 plugin 要求 terminology extension」）。這類條件成立時不會發出事件 —— 沒有 webhook、沒有 CI 訊號、沒有任何東西會通知 repo。唯一能發現「trigger 已成立」的路徑是人主動回頭讀。

本次 session 正是它的實證：2026-08-14 的 backlog 清理回訪了 6 張 parked issue（#143 #145 #146 #157 #136 #131），全部是人工、一次性、且只因為使用者下了明確指令才發生。那就是這個 repo 至今唯一存在過的「grooming」。

Solution

兩件事：

1. /idd-list --parked —— 列出所有 parked issue，並把各自的 trigger 條件原文一併印出（不摘要、不改寫 —— 判斷 trigger 是否成立必須看原話）。找不到 trigger 記錄時印 (no trigger recorded)，因為那本身就是要修的東西。
2. 更正 ic-r011 的宣稱 —— 改成實話：沒有自動化的 grooming，--parked 只是把回訪從「要先想起有這回事、再自己拼出清單」降成「跑一個指令」。

鐵律：--parked 絕不自動 unpark、也絕不自動關閉。判斷「那個未來狀態是否已經發生」需要 repo 之外的知識；工具負責攤開條件，人負責判斷。

Verification

45/45 suites 綠。blocker:* label 不存在這一點是用 gh label list 實查的，不是推測。

未做的部分：這不是自動化。要真的自動判斷 trigger 是否成立，得先讓那些散文命題變成機器可判定的東西 —— 那是另一個題目，本張不做也不假裝做了。

Changes

已合併進 main（PR #312）。