design: /idd-all-chain should auto-enqueue --bundle-mode children when root is bundle epic (bundle + chain mental-model unification)

[kiki830621]

Problem

Original observation (user, session 2026-05-12):
「bundle 處理到最後理論上是 idd-all-chain 的事情，chain 其實只是代表衍生的 issue 都要解玩 [解完]」

— Source: conversation in psychophysic_representations workspace after filing 4 pre-known issues (#19/#20/#21/#22) and being told to use /idd-all #19 #20 #21 #22 --pr cluster mode instead of /idd-all-chain #19.

當 user 用 idd-issue --bundle-mode ordered "...; ...; ..." 建出 epic + N children 後,自然的 follow-up 是「把這個 bundle 全部解掉」。目前 user 必須:

1. 知道 --bundle-mode 的 children 不是 chain 的 spawn(雖然概念上同等 — 都是「為了主任務而衍生的 sub-issue」)
2. 切換 mental model 到 /idd-all #epic #child1 #child2 ... --pr cluster mode

這個 mental switch 是不必要的:bundle children 跟 chain spawns 在 user POV 沒差,「都是衍生 issue 等著被解」。

Proposal

/idd-all-chain #ROOT 在 root issue 是 bundle epic(label epic + body 有 ## Children task list)時,自動把 task list 中的 children 加進 chain queue。等同於 chain 把 bundle children 視為已 file 的 spawn。

Seed source 從目前的「auto-emergent only(sister sweep / verify follow-up / mid-plan tangentials)」擴大為:

chain queue seed = root + auto-emergent spawn ∪ bundle.children (if root is epic)

Detection 機制

當 root issue:

• 有 label="epic" AND
• body 含 ## Children(或同等 anchor)區段下的 - [ ] #N task list

→ Parse task list 中的 #N reference,把這些 children 加進 chain queue(作 depth 1)。Eligibility check 沿用既有規則(same_file / same_skill / sister-bug),但因為 bundle children 是 user explicit creation,default 視為 eligible(可考慮加新 spawn_kind: "bundle-child" 分類)。

Semantic

新 invocation case:

# 假設 #100 是 bundle epic, task list 有 #101, #102, #103
/idd-all-chain #100
# → enqueue [#100, #101, #102, #103]
# → process #100 first(epic 本身可能也有 spec 要動,例如 README/docs)
# → 然後 process #101 / #102 / #103
# → 全部 verified 後開 1 個 cluster PR,Refs 全部 ID

與 --pr cluster mode 的差別(why not just keep cluster mode)

	cluster mode /idd-all #N #M --pr	proposed chain seed from bundle
Issue seed	user 手列每個 #	chain 從 bundle epic body 自動 parse
Order	user 手指定順序	chain 用 task list 順序(若 bundle 是 ordered 還可 honour Blocked-by)
Mental model	「我有 N 個 issue,湊一起解」	「我有一個 bundle,把它做完」
Discovery	不會撈 auto-emergent spawn(verify follow-up 等另開)	同時撈 bundle children + auto-emergent spawn

兩個 mode 可以共存,但 chain 從 bundle seed 更貼近實際 workflow(bundle 建好 → 自然想全做完)。

Relation to existing issues

• feat(idd-issue): bundle flags — --parent / --blocked-by / --bundle-mode for ordered/unordered issue bundles #21(closed)— 新增 --bundle-mode 把 epic + children 建立自動化。建好之後解的 path 沒明示
• feature: /idd-all chain-solve mode — 自動接續解 spawned issues + 單 review PR #44(closed)— 引入 /idd-all-chain 解「root + auto-emergent」。提的時候沒考慮 bundle source
• feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46(open)— /idd-all-chain accept multiple root issues with DFS/BFS。相關但正交:feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46 是多 root(平行多棵樹),本 issue 是單 root + bundle children(一棵樹的所有 node 一次解)
• idd-issue: 加入 multi-finding source 的 triage 機制（避免每筆 finding 手動分 create/update/comment/edit） #48 / [enhancement] idd-issue multi-finding: Stage 1 reproducibility heuristics + score formula + N<3 picker #80(multi-finding routing)— 另一個 multi-issue source-driven 分流,跟本 issue 不直接相關但同屬「IDD multi-issue orchestration 怎麼收斂」議題

Type

enhancement / design

Expected

Single seamless invocation chain:

idd-issue --bundle-mode ordered "build X: step1; step2; step3"  → creates epic #100 + children #101/#102/#103
/idd-all-chain #100                                                → solves #100/#101/#102/#103 + auto-emergent spawn → 1 cluster PR

User 不用知道 --pr cluster mode 存在(it becomes an implementation detail of chain mode,not a separate decision tree)。

Actual

User 跑完 --bundle-mode 後 invoke /idd-all-chain #100,chain shell 只看到 root #100 + 等 auto-emergent。Bundle children #101/#102/#103 對 chain 透明,不會被 enqueue。User 必須切到 /idd-all #100 #101 #102 #103 --pr(完全不同的 invocation pattern)。

Impact

• UX coherence:bundle creation 和 bundle solving 用同一個 verb(chain),不需要 user 學兩套 mental model
• Compose:chain seed = pre-known bundle ∪ auto-emergent spawn,兩者可共存(bundle child 在 implementation 中又 sweep 出 sister bug → 也加進 chain queue,depth 累加)
• Existing chain caps 不變:chain_max_depth=2 / chain_max_issues=5 仍適用;bundle children 超過 cap 的 fall back 跟 spawn cap-out 同邏輯(filed but not chained)
• Backward compat:既有 chain invocation(non-bundle root)行為完全不變;只有 root 是 bundle epic 時才觸發新邏輯
• Cluster mode 仍保留:--pr cluster 是 user explicit「我選這 N 個 file 一個 PR」的清楚意圖,不該移除。但 chain 從 bundle seed 後,default flow 從 cluster 轉向 chain(cluster 變 explicit override)

Acceptance criteria

• /idd-all-chain #N 偵測 root issue 為 bundle epic(label + task list pattern)時,parse children 加進 queue
• Spawn manifest 新增 spawn_kind: "bundle-child" 分類(同 sister-bug / same-file / same-skill)
• Ordered bundle:honour Blocked-by 關係(child[i] 等 child[i-1] verified 再跑)
• Unordered bundle:children 之間無 dependency,可 sequential 跑(chain 本就 sequential)
• Mix mode:bundle child 在 implementation sister sweep 中又 file 出 sister issue → 加進 queue(depth + 1)
• Chain caps(chain_max_depth=2 / chain_max_issues=5)對 bundle children 同樣 enforce
• Failure mode:bundle child verify FAIL → halt queue,preserve commits,提示 recovery options
• Cluster PR body 區分 bundle children vs auto-emergent spawn(audit clarity)
• Update docs/design-patterns/default-dilemma.md:bundle creation 跟 bundle solving 用同一 chain 不違反「default ambiguity」(都是 explicit invocation)
• Backward compat:既有 non-bundle root 的 chain 行為不變

Out of scope

• Multi-root chain(已 tracked by feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46)— 本 issue 限定單 root,只是該 root 是 bundle epic 而非 atomic
• --pr cluster mode 行為改動 — cluster mode 保留為 explicit「我選這 N 個 file」的 path
• Retrofit:把已存在的散落 issue 變 bundle 後再 chain — 那是 bundle creation 問題(idd-issue 自己的 scope),不該由 chain 處理