[design] /idd-edit batch mode + R5 refuse interaction — semantic decision needed (tangential from #154 plan)

[kiki830621]

Problem

Source: surfaced during /idd-plan #154 tangential sweep (Step 2.5)

/idd-edit 支援 batch mode (comment:NNN comment:MMM ... --replace --scope ...)。 #154 將加入 R5 runtime gate (refuse modifications to non-OWNER comments unless --override-user-content)。 #154 Plan fixture 11 只測 single-comment R5 refuse case,未涵蓋 batch mode + R5 partial-refuse 交互。

Scenarios needing design decision

# Scenario A: All targets OWNER → all proceed (clear)
/idd-edit comment:111 comment:222 --replace --scope whole-comment --body "..."

# Scenario B: All targets non-OWNER, no override → all refuse (clear)
/idd-edit comment:111 comment:222 --replace --scope whole-comment --body "..."

# Scenario C: MIXED — comment:111=OWNER, comment:222=non-OWNER → ?
# - (i) Per-comment refuse: 111 proceeds, 222 refused, batch reports partial outcome
# - (ii) First-refuse-abort-batch: 222 refuses → 111 also not touched (transactional)
# - (iii) Pre-flight scan: scan all N comments first, refuse entire batch if ANY non-OWNER without override

Open questions

• 哪個語意正確?(i) per-comment 對 idempotent skill 合理,(ii) transactional 對「all-or-nothing」期望符合,(iii) pre-flight 失敗最快但需 N gh API calls 前置
• --override-user-content --reason="..." 在 batch mode 是否套用所有 targets?還是 per-target override(複雜)?
• batch mode 既有 "per-comment confirm" UX(不允許 --yes-to-all)— R5 refuse 是否走「per-comment refuse + 繼續 batch」flow,類比現有 confirm flow?

Impact

#154 fixture 13 已涵蓋 /idd-comment errata flow auto-call to /idd-edit --prepend-note(single-target context)。 但 batch mode + R5 是另一 dimension,#154 implementation 階段一定會撞到。

Type

enhancement / edge case — semantic decision needed for batch R5 interaction

Trigger conditions

• Immediate:[feature] /idd-edit runtime enforcement — proper proposal after 3-iteration bash failure (R1/R2/R3 on #153) #154 implementation Block B3 (R5 runtime gate) 開工時必撞 batch-mode design question
• 或:首個 user issue 報 /idd-edit batch mode 對 mixed-OWNER targets 行為不如預期

Type

enhancement / edge case design

Priority

P2 — higher than typical parking-lot (#154 implementation 必撞),但 can be deferred to #154 follow-up if Block B3 ships with single-target enforcement only + batch raises non-blocking warning

Open recommendation

Plan B3 implement single-target R5 enforcement first。 Batch + R5 interaction add fixture(tests/idd-edit/test_parser.sh fixture 14)post-#154 ship,或在 #154 EnterPlanMode revision 階段加進 plan。 本 issue 紀錄此 design question 不流失。

Refs #154 #150

---

Current Status

Phase: closed
Last updated: 2026-07-13 by /idd-close

Key Decisions

• Complexity = Plan（batch × R5 語意需使用者拍板；建議 (i) per-comment refuse）→ next /idd-plan #158
• 已拍板（2026-07-11）：語意 (i) per-comment refuse + 繼續 — next /idd-plan [design] /idd-edit batch mode + R5 refuse interaction — semantic decision needed (tangential from #154 plan) #158

[kiki830621]

Diagnosis

Type

enhancement / edge-case design（idd-edit batch mode × R5 refuse 交互語意）

Root Cause / Analysis

#154（已於 2026-07-06 結案，PR #159）ship 了 R5 runtime gate 的 single-target enforcement；batch mode + R5 的 mixed-OWNER 語意（scenario C）當時明列 out-of-scope。trigger 現已成立（#154 落地 = batch 交互是既存行為面的未定義區）。三個候選語意：(i) per-comment refuse + 繼續 batch（部分結果回報）、(ii) transactional first-refuse-abort、(iii) pre-flight 全掃 + 整批拒絕。傾向 (i)：與既有 batch「per-comment confirm、不允許 --yes-to-all」的 UX 同構（refuse 視為 confirm 的否定路徑），idempotent per-target 語意也與 idd-edit 的 batch 契約一致；(iii) 的 N 次前置 API call 在 ownership check 本就要做，可作 (i) 的實作細節而非獨立語意。惟此為使用者拍板的語意決策 — unattended 不代決。

Impact

• skills/idd-edit/SKILL.md batch 段 + R5 gate 段
• tests/idd-edit/test_parser.sh fixture 14（mixed-OWNER batch）
• --override-user-content 在 batch 的作用域（all-targets vs per-target）需一併定案

Strategy

• 使用者拍板 scenario C 語意（建議 (i) per-comment refuse + 繼續；--override-user-content 建議 all-targets + reason 共用，複雜度最低）
• SKILL.md 寫入定案語意（batch × R5 × override 三方交互表）
• fixture 14：mixed-OWNER batch 的 refuse/proceed/report 斷言

Conflict Class

A_parallel_safe — skills/idd-edit/SKILL.md + idd-edit tests；本 queue 無他案共享。

Complexity

Plan

Layer P 命中：decision-heavy（3 個 valid 語意，選哪個改變 batch 行為面）。Hard-gate: not triggered — 2 檔、無 shared abstraction。Unattended 處置：語意決策留給使用者（EnterPlanMode approval gate），本輪停在 diagnosed — AI 單方拍板 batch 語意違反 #158 成案本意（「紀錄此 design question 不流失」）。

Risks

• 語意 (i) 的部分成功回報若不醒目，使用者誤以為整批完成 → 定案時要求 refuse 行在 report 顯著標記

Residue

(none)

Vagueness Pre-check

• V1: 2 — 三候選語意由 issue 完整列舉
• V4: 2 — 完成 = 定案語意入 SKILL + fixture 14 綠
• Triggered: no

[Layer V: V1=2 V4=2, not triggered; unattended mode]

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

(none)

---

Source: /idd-all focused batch drain (unattended), 2026-07-11 — next: /idd-plan #158（語意拍板 → fixture）

[kiki830621]

決策：scenario C 採語意 (i) per-comment refuse + 繼續 batch — OWNER 照做、非 OWNER 逐條 refuse（report 顯著標記）、batch 不中止；--override-user-content 作用 all-targets + reason 共用。

使用者裁決 2026-07-11（focused batch drain 決策檢查點）。與既有 batch per-comment confirm UX 同構。Next: /idd-plan #158（定案語意入 SKILL + fixture 14）。

[kiki830621]

Implementation Plan (Plan tier)

Scenario C（mixed-OWNER batch × R5）語意已拍板（2026-07-11）：(i) per-comment refuse + 繼續 batch。現行缺陷：per-target outer loop 內 Step 1.5 的 R5 refuse 直接 exit 4 — 第一個 non-OWNER target 殺整批（已處理的不回滾、之後的全不碰），正是三個候選語意中最模糊的中間態。

Files & Changes

• plugins/issue-driven-dev/skills/idd-edit/SKILL.md — (a) Step 1.5 R5 refuse 在 batch 中改 record + continue（REFUSED_TARGETS+= + continue，不 exit）；(b) 批次結束加 batch outcome report：edited: N / refused: M，refused 行顯著標記（✗ REFUSED comment:<id> — non-OWNER）+ 各附 override hint；(c) exit code：M=0 → 0，M>0 → 4（單 target refuse 退化為現行行為 — refuse 記錄、loop 結束、exit 4，可觀察行為不變）；(d) --override-user-content --reason 語意明文：all-targets + reason 共用；(e) 撤下 line 31 的「[design] /idd-edit batch mode + R5 refuse interaction — semantic decision needed (tangential from #154 plan) #158 deferred」註記，換成定案語意
• plugins/issue-driven-dev/scripts/tests/idd-edit/test.sh — fixture 14（SKILL 契約 drift-guard 段）：assert per-comment-continue 語意 token、outcome report 格式、all-targets override 語意、deferred 註記已撤；RED-first
• references/batch-and-cluster.md — idd-edit batch 段補一句定案語意（若該檔有對應段落；無則略）

Sequencing & Dependencies

fixture 14（RED）→ SKILL prose（GREEN）→ references 補句。單檔為主，無互依。

Decision Points

已全數拍板：(i) per-comment refuse；override all-targets + shared reason；exit 4 on any-refused（保留 idd-edit 自身碼空間 — 不套 #227 的 gh-egress 碼帶，那是 wrapper 專屬）。

Risks & Mitigations

• 部分成功被誤讀為全成功 → outcome report 強制列 refused 行 + 顯著標記（拍板時已附帶要求）
• 單 target 行為回歸 → 語意設計上退化等價（見上），fixture 14 含單 target refuse 不變 assertion

Test Plan

fixture 14：(1) prose 含 per-comment-continue tokens；(2) outcome report 格式 tokens；(3) refuse-highlight token；(4) deferred 註記 refuted；(5) 單 target 語意不變 assertion。既有 23 個 helper adversarial fixtures 不動（helper.py 無改動 — R5 判定本身不變，變的是 batch 層對 refuse 的處置）。

Out-of-scope (will NOT be touched)

• idd-edit-helper.py（R5 判定邏輯不變）
• (ii) transactional / (iii) pre-flight 語意（已否決）
• --yes-to-all（維持禁止）

Tangential Observations (filed mid-plan)

none surfaced

[kiki830621]

Implementation Complete

Checklist (synced from approved Plan)

• Step 1.5 R5 refuse：batch 中 record + continue（不殺批；errata hint 逐 target 保留）→ commit d8a1e4f
• Step 7.5 batch outcome report（edited/refused + ✗ REFUSED 顯著行 + override hint）→ commit d8a1e4f
• exit contract：M=0 → 0；M>0 → 4（單 target 退化等價；沿用 idd-edit 自身碼空間）→ commit d8a1e4f
• --override-user-content 明文 all-targets + shared reason；deferred 註記撤下換定案語意 → commit d8a1e4f
• fixture 14（8 prose-contract checks 併入 suite）RED→GREEN；helper 23 fixtures 不動 → 31/31
• [~] references/batch-and-cluster.md 補句 — skipped: 該檔僅一行 table row 提及 idd-edit batch，無可錨定的敘述段（plan 已預留此分支）

Changes

• d8a1e4f — via PR feat: idd-edit batch × R5 — per-comment refuse + continue (scenario C semantics) #257

Next: verify pending — PR #257 review 後 merge

[kiki830621]

Closing Summary

Problem

/idd-edit batch mode × R5 author gate 的 mixed-OWNER 語意未定義 — 現行行為是最模糊的中間態：per-target loop 裡 R5 refuse 直接 exit 4，第一個 non-OWNER 殺整批（已處理的不回滾、之後的全不碰）。#154 落地 single-target 時明文 defer 此設計題至本案。

Root Cause

R5 gate 從 single-target 邏輯直接搬進 batch loop，refuse 分支的 exit 語意從未針對批次重新設計。

Solution

（拍板 2026-07-11：語意 (i) per-comment refuse + 繼續）commit dda0cfc（via PR #257）：

• Step 1.5 R5 refuse → REFUSED_TARGETS+= + continue（errata hint 逐 target 保留），不再殺批
• 新 Step 7.5 batch outcome report：edited: N / refused: M，每個 refused 一行 ✗ REFUSED comment:<id> 顯著標記 + override hint — 部分成功絕不偽裝全成功
• Exit contract：M=0 → 0；M>0 → 4（單 target 退化等價 — 行為不變；沿用 idd-edit 自身碼空間，不套 [followup] gh-egress gate refusal 專屬 exit-code band — 與 gh 原生碼空間解耦 (follow-up finding from #117 verify) #227 的 gh-egress 帶）
• --override-user-content 明文 all-targets + shared reason；deferred 註記撤下換定案語意
• idd-edit-helper.py 零改動（R5 判定不變，變的是批次層處置）

Verification

• fixture 14（8 個 prose-contract checks 併入 suite 計數器）RED→GREEN；helper 既有 23 adversarial fixtures 不動 — idd-edit suite 31/31；全 sweep 0 fail；CI pass
• Plan tier：EnterPlanMode approved 2026-07-11；PR review 替代 ensemble verify 後 merge

Residue Acknowledgement

references/batch-and-cluster.md 補句 skipped（該檔僅 table row 提及、無可錨段落）— 已於 IC checklist 以 [~] + reason 記錄。無 follow-up。

Changes

• dda0cfc feat: idd-edit batch x R5 — per-comment refuse + continue semantics — via PR feat: idd-edit batch × R5 — per-comment refuse + continue (scenario C semantics) #257