Problem
PR #99 (#96, cluster mode override doc + bash) was 6-AI verified across 2 rounds and merged-eligible under Option A (maintain forced PR for cluster mode, with explicit override notice). Two non-blocking findings from the verify rounds were explicitly deferred to this follow-up.
Finding 1 — feature-branch cluster direct-commit tension (Devil's Advocate, R1 + R2)
The diagnosis of #96 itself observed that the "force PR" rationale (batch-and-cluster.md: "cluster on direct-commit = stacked half-isolated changes on default branch") only holds when the user starts from the default branch. idd-implement direct-commit path's contract is "stay on current branch" — if the user is already on a feature branch, cluster direct-commit just stacks N Refs #N commits on that feature branch, which is a legitimate workflow (one local feature branch tracking N issues, shipped as one PR later).
Option A forces PR regardless of branch context. Devil's Advocate (both rounds) flagged this as Option A "cementing rather than resolving" the design tension — non-blocking, but a candidate for revisiting Option B (cluster accepts --no-pr, degrades to shared branch + N commits, no PR) gated on a branch-context check (only force PR when on default branch; allow direct-commit when on a non-default feature branch).
Finding 2 — cluster-detection glob looseness (Logic + Codex, R2 LOW)
PR #99's idd-implement Step 0.5 cluster detection uses shell case glob \#[0-9]*:
#42abc matches (anything after the first digit is *-absorbed) — counts a malformed token as a cluster issue#34 #34 (duplicate arg) counts as 2 → trips CLUSTER_MODE when only 1 distinct issue was named
This diverges from batch-and-cluster.md's stricter documented form ^#\d+$. Both reviewers (Logic, Codex) rated it LOW / deferrable. Realistic blast radius is small (malformed invocations), but tightening would make cluster detection match the documented contract.
Type
enhancement (Finding 1 — design revisit) + refactor (Finding 2 — hardening)
Expected
- Finding 1: a decision on whether cluster + direct-commit should be allowed when the user is on a non-default feature branch. Either (a) confirm Option A is final and document the rejected feature-branch case, or (b) implement the branch-context-gated Option B.
- Finding 2:
idd-implement Step 0.5 cluster detection counts only well-formed, distinct #<digits> tokens — #42abc rejected, #34 #34 counts as 1.
Actual (after PR #99)
- Cluster mode unconditionally forces PR path even on a non-default feature branch (override notice prints, but no opt-out).
\#[0-9]* glob over-counts malformed / duplicate #N tokens.
Impact
- Files:
references/pr-flow.md, references/batch-and-cluster.md, skills/idd-implement/SKILL.md
- Users: those who prefer direct-commit and work on feature branches, running cluster invocations
Notes
Surfaced during /idd-verify --pr 99 (#96 implementation). Devil's Advocate verify comments:
Codex R2 LOW (glob): #99 (comment)
Problem
PR #99 (#96, cluster mode override doc + bash) was 6-AI verified across 2 rounds and merged-eligible under Option A (maintain forced PR for cluster mode, with explicit override notice). Two non-blocking findings from the verify rounds were explicitly deferred to this follow-up.
Finding 1 — feature-branch cluster direct-commit tension (Devil's Advocate, R1 + R2)
The diagnosis of #96 itself observed that the "force PR" rationale (
batch-and-cluster.md: "cluster on direct-commit = stacked half-isolated changes on default branch") only holds when the user starts from the default branch.idd-implementdirect-commit path's contract is "stay on current branch" — if the user is already on a feature branch, cluster direct-commit just stacks NRefs #Ncommits on that feature branch, which is a legitimate workflow (one local feature branch tracking N issues, shipped as one PR later).Option A forces PR regardless of branch context. Devil's Advocate (both rounds) flagged this as Option A "cementing rather than resolving" the design tension — non-blocking, but a candidate for revisiting Option B (cluster accepts
--no-pr, degrades to shared branch + N commits, no PR) gated on a branch-context check (only force PR when on default branch; allow direct-commit when on a non-default feature branch).Finding 2 — cluster-detection glob looseness (Logic + Codex, R2 LOW)
PR #99's
idd-implementStep 0.5 cluster detection uses shellcaseglob\#[0-9]*:#42abcmatches (anything after the first digit is*-absorbed) — counts a malformed token as a cluster issue#34 #34(duplicate arg) counts as 2 → tripsCLUSTER_MODEwhen only 1 distinct issue was namedThis diverges from
batch-and-cluster.md's stricter documented form^#\d+$. Both reviewers (Logic, Codex) rated it LOW / deferrable. Realistic blast radius is small (malformed invocations), but tightening would make cluster detection match the documented contract.Type
enhancement (Finding 1 — design revisit) + refactor (Finding 2 — hardening)
Expected
idd-implementStep 0.5 cluster detection counts only well-formed, distinct#<digits>tokens —#42abcrejected,#34 #34counts as 1.Actual (after PR #99)
\#[0-9]*glob over-counts malformed / duplicate#Ntokens.Impact
references/pr-flow.md,references/batch-and-cluster.md,skills/idd-implement/SKILL.mdNotes
Surfaced during
/idd-verify --pr 99(#96 implementation). Devil's Advocate verify comments:Codex R2 LOW (glob): #99 (comment)