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
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
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
Open questions
--override-user-content --reason="..."在 batch mode 是否套用所有 targets?還是 per-target override(複雜)?--yes-to-all)— R5 refuse 是否走「per-comment refuse + 繼續 batch」flow,類比現有 confirm flow?Impact
#154 fixture 13 已涵蓋
/idd-commenterrata 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
/idd-editbatch 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.shfixture 14)post-#154 ship,或在 #154 EnterPlanMode revision 階段加進 plan。 本 issue 紀錄此 design question 不流失。Refs #154 #150