[enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法

[kiki830621]

Problem

Original text (使用者於 2026-05-19 #96-backlog triage session 提出,反思剛把 PR #101 的 review 委派給 AI 之後):
「其實我現在都不 review,人不 review 是不是也要有人不 review 的做法」

IDD 的 mode model 目前是一個 2-tuple:(path, interaction) — PR / direct-commit × attended / unattended(見 references/pr-flow.md、idd-all Phase 0.5)。但這個 tuple 沒有涵蓋一個獨立的維度:acceptance review —— merge 前「誰簽核接受這個改動」。

IDD 裡其實有兩層 review,只 model 了一層:

1. idd-verify = AI correctness 驗證(6-AI ensemble)。強制、機械式、可證偽。回答「code 有沒有滿足 issue 的要求」。
2. merge-time acceptance review = owner 的「我們要不要這個 / 現在 / 這樣做」判斷。目前完全沒 model —— idd-all / idd-all-chain 「停在 verified」,然後 informally 提示「human review → merge → close」。

實務上使用者回報:他根本不做 human acceptance review。所以 (PR, unattended) mode 產出一個 idd-verify 通過的 PR,然後……就直接 merge 了。IDD 設計上假設存在的「human review」那一步被無聲跳過。

核心問題:如果「人不 review」是實際的運作模式,IDD 應該對它有一個設計過的做法 —— 命名它、明確化它、決定(若有)什麼東西替代那個 acceptance 判斷 —— 而不是留成一個 informal gap 讓使用者默默繞過。

三個已觀察到的 acceptance-review 值

同一個 backlog-triage session 內,acceptance review 實際出現了 3 種不同行為:

值	session 內何處	獨立性
human review	#96 → PR #99,使用者自己看、自己 merge	✅ 獨立
AI-delegated review	PR #101「你可以幫我 review」→ 實作 AI 做 mergeable / auto-close-trap-scan / verify-history 檢查後 merge	⚠️ 弱
no review	idd-verify PASS 即 merge(使用者自述的常態)	❌ 無

關鍵風險:委派回實作 AI 會塌掉獨立性

idd-verify 的 6-AI 之所以有效,是因為「Claude 修、獨立 AI 群驗」—— reviewer ≠ implementer。當 acceptance review 委派回實作的 AI 本身(PR #101 的情況),那層獨立性就消失了 —— 變成實作者審自己的 acceptance。PR #101 還算安全(純 docs、6-AI 已驗、做的是機械檢查),但當預設就危險。

所以更精準的問題不是「要不要人 review」,而是 「acceptance 的獨立判斷從哪來」:idd-verify 給獨立的 correctness;merge review 本該再加一層獨立的 acceptance;委派回實作 AI = 省事但獨立性沒了。

Type

enhancement(IDD methodology / mode model 設計)

Expected

IDD 對「acceptance review」這個維度有明確的設計立場。候選方向(待 idd-diagnose 決定,此處僅列出不預判):

• A. 升級為 3-tuple (path, interaction, acceptance) —— acceptance ∈ {human-required, AI-delegated, none},在 pr-flow.md / idd-all Phase 0.5 明文解析,跟現有兩軸從同一 source 推導。
• B. 不擴 tuple,但讓 verified→merge 的收尾明確問一次「這個 merge 誰簽?」—— 把隱性步驟升成 explicit checkpoint(類似 idd-close 的 human-checkpoint 哲學)。
• C. 維持現狀但文件化 —— 承認 idd-all 停在 verified 之後的 acceptance 是 informal,明文寫「IDD 不負責 acceptance gate,使用者自負」,至少讓缺口從隱性變顯性。
• 不論哪個方向,都要處理「AI-delegated review 會塌掉獨立性」這個 risk —— 例如若允許 AI 代理 acceptance,是否應由非實作的獨立 AI 做(借 idd-verify 既有的獨立性設計),而不是實作 AI 自審。

Actual

• IDD mode model 只有 (path, interaction) 2-tuple;acceptance review 不是 first-class 概念。
• idd-all / idd-all-chain 「停在 verified」+ informally 提示 human review —— 沒有 enforce、沒有 model、沒有紀錄「這個 merge 由誰 accept」。
• 使用者實務上跳過 human acceptance review;IDD 沒攔、也沒提供替代設計。
• PR cluster: 6 Simple docs/pattern follow-ups (#96-backlog triage) #101 出現了第三種未命名的 mode(AI 代理 acceptance review),IDD 完全沒有它的契約。

Impact

• 影響的檔案:references/pr-flow.md(mode resolution canonical 演算法)、skills/idd-all/SKILL.md + skills/idd-all-chain/SKILL.md(Phase 0.5 mode tuple、收尾 stop-at-verified)、skills/idd-verify/SKILL.md(verify 是 correctness 層,需與 acceptance 層明確區分)、skills/idd-close/SKILL.md(close 的 human-checkpoint 哲學與 acceptance review 高度相關)、CLAUDE.md(mode 文件)、可能 MANIFESTO.md(IDD 的 closure axis 論述應納入 acceptance 維度)。
• 影響的使用者流程:所有走 PR path 的 IDD 工作 —— verified 之後的 acceptance 目前是 undefined behavior。

Notes

由 2026-05-19 的 #96-backlog triage session 浮現 —— 使用者在該 session 把 cluster-PR #101 的 review 委派給 AI,事後反思「人不 review」其實是常態,於是發現 IDD 的 mode model 缺了 acceptance 這個維度。屬於「用 IDD 的過程中浮現的 IDD 設計缺口」,本身就值得一個 issue。

相關脈絡:同 session 的 #96(cluster-PR vs direct-commit path 衝突)也是 mode model 的設計議題 —— 兩者都指向 pr-flow.md 的 mode resolution 需要更完整的維度模型。---

Current Status

Phase: planning
Last updated: 2026-05-20 by idd-plan

Key Decisions

• Plan tier approval gate passed (EnterPlanMode → ExitPlanMode approved 2026-05-20). Implementation Plan posted at issue-comment-4493125984.
• Branch idd/102-acceptance-review-doctrine cut from main at db25514. PR path. Chain to /idd-implement #102.
• Plan-tier scope = MANIFESTO doctrine + idd-all/idd-all-chain Phase 6/4 messaging swap + per-invocation --review flag. 6 files (5 plugin + branch). Plugin will bump 2.64.0 → 2.65.0.
• Mid-plan tangential filed: Sync 4-template PR-body checklist wording to match #102 NSQL doctrine #108 (4-template PR-body checklist consistency family — idd-implement Step 5.5 / idd-all Phase 5 / pr-flow.md canonical stale wording; sync post-merge).
• Plan re-routed Spectra → Plan via /spectra-discuss (2026-05-19 conclusion at issue-comment-4486107094).
• Direction A (3-tuple (path, interaction, acceptance)) and most of Direction B (merge-time gate) killed by discuss; what ships is doctrine + thin flag.
• IDD's human-in-the-loop is the NSQL Confirmation Protocol; verify-gated is the terminal default disposition; --review is opt-in re-open, NOT a quality gate.

Scope Changes

• (none — Plan tier ships exactly what the discuss conclusion specified)

Blocking

• (none — Implementation Plan approved, ready for /idd-implement #102)

Commits

• (none yet — Implementation Plan approved, awaiting /idd-implement #102)---

Current Status

Phase: implemented
Last updated: 2026-05-20 by idd-implement

Key Decisions

• Implementation complete on branch idd/102-acceptance-review-doctrine → PR #109 (4 commits, +123/−12 across 5 files); plugin bumped to v2.65.0
• Implementation Plan approved via EnterPlanMode 2026-05-20; (Implementation Complete)
• Step 5.7 sister sweep extended Sync 4-template PR-body checklist wording to match #102 NSQL doctrine #108 to 5-template family — surfaced references/chain-flow.md:254 carrying the same stale Pending: human review of cluster PR wording (not in original 4-template list)
• 4 commits land: 4aef425 MANIFESTO doctrine · 1fdcba0 idd-all --review + Phase 6 swap · 11a99e0 idd-all-chain --review propagation + PR-body conditional · 8a41ee7 v2.65.0 bump
• Mid-plan tangential Sync 4-template PR-body checklist wording to match #102 NSQL doctrine #108 filed (4→5-template PR-body checklist consistency family — idd-implement Step 5.5 / idd-all Phase 5 / pr-flow.md:135 / chain-flow.md:254 stale wording; sync post-merge)
• Plan re-routed Spectra → Plan via /spectra-discuss (2026-05-19 conclusion at issue-comment-4486107094)
• Direction A (3-tuple (path, interaction, acceptance)) and most of Direction B (merge-time gate) killed by discuss; what ships is doctrine + thin flag
• IDD's human-in-the-loop is the NSQL Confirmation Protocol; verify-gated is the terminal default disposition; --review is opt-in re-open, NOT a quality gate

Scope Changes

• (none — implementation ships exactly what the discuss conclusion + Implementation Plan specified)

Blocking

• (none — PR [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #109 ready for /idd-verify --pr 109)

Commits

• 8a41ee7 chore: bump issue-driven-dev to v2.65.0 (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)
• 11a99e0 feat(idd-all-chain): add --review flag propagation + Phase 4/PR body conditional wording (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)
• 1fdcba0 feat(idd-all): add --review flag + Phase 6 verify-gated terminal wording (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)
• 4aef425 feat(MANIFESTO): add Human-in-the-loop / NSQL Confirmation Protocol doctrine (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)

[kiki830621]

Diagnosis

Type

feature — IDD methodology / mode-model design.

Analysis (requirements breakdown)

The issue asks one design question: should IDD model "acceptance review" as a first-class concept, and if so, how?

Requirement decomposition:

1. Name the two review layers explicitly. IDD conflates them today. They answer different questions:

   • correctness review — idd-verify's 6-AI ensemble. "Does the code meet the issue's requirements?" Mechanical, falsifiable, mandatory. Modeled.
   • acceptance review — the merge-time "do we want this / now / this way?" judgment. Taste, timing, strategy. Not modeled — idd-all/idd-all-chain "stop at verified" and informally suggest "human review → merge → close".

2. Decide whether acceptance review is a mode dimension. Today the mode model is the (path, interaction) 2-tuple (pr-flow.md resolution algorithm + idd-all Phase 0.5). Acceptance is orthogonal to both axes — it's not "where commits land" and not "does the sub-skill ask questions"; it's "who signs the merge". The issue body's 3 candidate directions:

   • A — 3-tuple (path, interaction, acceptance), acceptance ∈ {human-required, AI-delegated, none}, resolved in pr-flow.md / Phase 0.5.
   • B — no tuple change; make verified→merge an explicit checkpoint ("who signs this merge?").
   • C — document the gap; IDD declares it doesn't own the acceptance gate.

3. Handle the independence-collapse risk. idd-verify's value rests on reviewer ≠ implementer ("Claude 修、獨立 AI 群驗"). If acceptance review is delegated to the implementing AI (PR cluster: 6 Simple docs/pattern follow-ups (#96-backlog triage) #101's pattern), that independence collapses for the acceptance layer. Any direction that permits AI-delegated acceptance must address whether it should be done by a non-implementing AI.

Not a bug — a genuine design gap. The 2-tuple was never wrong; it just never named the third concern. PR #101 exercised an un-named mode (AI-delegated acceptance) with zero contract — that's the concrete evidence the gap is real.

Impact

Surface	Why affected
references/pr-flow.md	canonical mode-resolution algorithm — direction A adds a 3rd axis to it
skills/idd-all/SKILL.md + skills/idd-all-chain/SKILL.md	Phase 0.5 mode resolution + the "stop at verified" terminal step
skills/idd-verify/SKILL.md	verify is the correctness layer — must be explicitly distinguished from acceptance
skills/idd-close/SKILL.md	idd-close's "human checkpoint" philosophy IS a partial acceptance-gate already — needs reconciling
CLAUDE.md	mode-model documentation
MANIFESTO.md	the IDD closure-axis thesis should incorporate acceptance

Strategy

This is a design-alignment issue with genuine open questions — exactly what spectra-discuss exists for. The discuss agenda:

• Decide direction A / B / C (or hybrid) — does acceptance become a tuple axis, a checkpoint, or documented-as-out-of-scope?
• If A: name the acceptance axis values precisely; decide resolution precedence vs path/interaction; backward-compat for existing (path, interaction) invocations
• Resolve the independence question — if AI-delegated acceptance is allowed, must it be a non-implementing AI? Does it reuse idd-verify's independence machinery?
• Reconcile with idd-close's existing "human checkpoint" philosophy — is acceptance review just a rename/formalization of what idd-close already gestures at?
• Decide whether MANIFESTO.md's closure-axis thesis needs the acceptance concept

Complexity

Spectra

• Layer 2 (necessary condition) — (path, interaction) is a published contract in pr-flow.md, consumed by every IDD skill (idd-all / idd-implement / idd-verify / idd-close / idd-all-chain). Adding / formalizing an acceptance dimension modifies that contract for all those callers — its behavior must be a documented spec.
• Layer 3 (confirmation) — (a) modifies normative behavior of the canonical mode-resolution doc; (b) cross-cuts 4+ skills needing consistency-checking; (c) an architectural decision with long-term maintenance implications (a 3rd mode axis is inherited by every future IDD skill).

Not Plan: this isn't an internal refactor — it's a frozen-contract change to IDD's mode model. (Contrast #96, diagnosed Plan: #96 documented an existing behavior + small bash impl, no new axis.)

Risks

• Scope balloon — direction A (3-tuple) touches the canonical doc + 4 skills + MANIFESTO; the discuss must scope tightly.
• C is the cheap escape — "just document the gap" is legitimate and may be the right MVP; discuss should not over-engineer toward A by default.
• Backward compat — any tuple change must keep existing (path, interaction) invocations valid (additive 3rd axis with a safe default).
• Blocks feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37 — /idd-all bulk-solve cannot autonomously merge until this is resolved; feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37's spec depends on the direction chosen here.

Vagueness Pre-check (Step 3.4)

Axis	Score	Reasoning
V1 (vague WHAT)	3 (mostly clear)	The WHAT — "model acceptance review" — is clear; the issue body names the two layers, 3 candidate directions, the independence risk. The open part ("which direction") is decision-heavy, not vague — handled by Spectra routing, not Layer V.
V4 (vague ACCEPTANCE)	3 (mostly clear)	Expected spells out "IDD has an explicit design stance on acceptance review" + 3 concrete outcomes. Completion = a direction is decided + spec'd. Not crisp-testable (it's a design decision) but not vague.

• Triggered: no — both axes ≤ 3.

Next Step

Complexity = Spectra → /spectra-discuss (the A/B/C direction + naming + independence question are genuine open questions; opt-out to spectra-propose is not available). Topic: "acceptance-review as an IDD mode dimension".

[kiki830621]

Discuss Conclusion — acceptance-review as an IDD mode dimension

/spectra-discuss (2026-05-19). This comment is the conclusion + audit trail.

TL;DR

IDD does not add an "acceptance" dimension to the mode model. Directions A (3-tuple (path, interaction, acceptance)) and most of B (a new merge-time gate) are dropped — the discussion found there is no gap to plug. #102 instead produces a doctrine + a thin flag + a messaging fix. Re-routed Spectra → Plan.

How the discussion converged

1. "AI verify PASS is itself a review." Starting reframe: idd-verify's 6-AI ensemble passing is not "no review" — it is a review (independent, multi-lens, falsifiable).

2. verify exceeds a human reviewer — on correctness. 5 specialized adversarial agents + an independent model out-thoroughness any human merge-review. Clinging to "human review" as a quality gate is backwards — the AI gate is the higher bar.

3. The residue: verify cannot question the issue. idd-verify's entire frame is code vs issue. If the issue is wrong, verify passes a wrong thing flawlessly. So the human is replaceable as the correctness reviewer, irreplaceable as the intent authority — and intent authorship is an upstream job.

4. NSQL gives the frame. NSQL — the Human-AI Confirmation Protocol — formalizes human-in-the-loop as: AI detects ambiguity → shows structured understanding → human confirms/corrects intent → then execute. "Clarify before execute, never guess." IDD is an instance of that protocol:

NSQL confirmation loop	IDD pipeline
AI parses & identifies ambiguity	idd-diagnose + Layer V / Plan / Spectra (the ambiguity detector)
AI shows structured understanding	Diagnosis comment / EnterPlanMode plan
Human confirms 對 / 不對改成…	issue authored / clarified / plan approved
execute	idd-implement
—	idd-verify = execution-fidelity check, not a confirmation loop

The human's loop closes before execution. idd-verify checks fidelity to already-confirmed intent. Post-execution there is nothing left for the human to confirm — which is why a merge-time acceptance gate was never missing: it would be a loop with no input.

Decision

Doctrine (the deliverable):

IDD's human-in-the-loop is the NSQL confirmation loop. The human confirms intent before execution — at issue + idd-diagnose, with Layer V / Plan / Spectra as the ambiguity detector. idd-verify is an execution-fidelity check, not a confirmation loop. verify-gated is the terminal default disposition: a clean 6/6 verify PASS is sufficient to merge — the issue was the acceptance contract, verify confirmed delivery. --review is an opt-in that re-opens the confirmation loop for the rare "I doubt my own issue" case — not a quality gate.

auto-merge on a clean verify-gated PASS is legitimate — justified by "verify is the gate" (the independent ensemble did the catching), not by "merges are reversible" (a revert is asymmetric: a reviewed change + two history scars + distribution already shipped). Guardrails are mandatory, not skipped: clean 6/6 PASS only (never CONDITIONAL / FAIL), Step 0.8 auto-close-trap scan, clean squash message. auto-merge ≠ auto-close — idd-close still runs (the closing summary is the audit artifact). Autopilot auto-merge mechanics, and the auto-merge → auto-close sequencing, belong to #37, not here.

Deliverables (Plan-tier)

1. MANIFESTO.md — the doctrine above, explicitly citing NSQL as the protocol IDD conforms to.
2. idd-all / idd-all-chain Phase 6 — honest terminal messaging: verified — verify-gated, ready to merge; drop "suggest human review" (it implies a second human gate IDD's design does not require).
3. --review flag (per-invocation) — re-open-confirmation opt-in; Phase 6 then marks "awaiting human acceptance".

A standing acceptance_policy config field is deferred — an exception does not need a standing policy; revisit only if #37 bulk-solve wants it.

Re-route: Spectra → Plan

The original diagnosis was Spectra because it assumed direction A (a 3rd mode-tuple axis = a frozen-contract change). Discuss killed direction A. What remains — a MANIFESTO doctrine + Phase 6 messaging in 2 skills + one per-invocation flag — is Plan-tier: decision-heavy (resolved here), touches a risk-sensitive boundary (terminal merge behavior), no new published contract. Next step: /idd-plan #102.

Already captured

• CLAUDE.md — NSQL added as a Reference Project (the doctrine's durable pointer).

Unblocks #37

verify-gated is now a named, sanctioned terminal disposition — the precondition #37 (bulk-solve) needs to autonomously merge on verify PASS. #37's discuss can now proceed.

[kiki830621]

Implementation Plan (Plan tier)

Context: /spectra-discuss (2026-05-19) re-routed #102 from Spectra → Plan. The discussion killed Direction A (no new mode-tuple axis) and most of Direction B (no new merge-time gate). What remains is a MANIFESTO doctrine + thin per-invocation --review flag + Phase 6/4 terminal messaging swap — Plan-tier, no published contract change. See Discuss Conclusion.

Branch: idd/102-acceptance-review-doctrine (PR path, branched from main at db25514).

Files & Changes

• plugins/issue-driven-dev/MANIFESTO.md — NEW section between ## 兩個正交的維度：Verification 與 Closure (line 50–92) and ## TDD/SDD 是 IDD 的 special case (line 95). Heading: ## Human-in-the-loop: IDD 即 NSQL Confirmation Protocol. Contains:

  • Mapping table (NSQL confirmation loop ⇆ IDD pipeline) showing idd-diagnose/Layer V/Plan/Spectra = ambiguity detector, Diagnosis comment/EnterPlanMode = structured understanding render, issue authoring/clarify/plan approval = human confirms intent, idd-implement = execute, idd-verify = execution-fidelity check, NOT a confirmation loop.
  • Doctrine paragraph: human's confirmation loop closes before execution; verify-gated is the terminal default disposition; one clean 6/6 verify PASS is sufficient to merge — issue was the acceptance contract, verify confirmed delivery.
  • Verify-as-review reframe: 5 specialized adversarial agents + an independent model (Codex) on correctness exceed a single human merge reviewer's thoroughness; "AI verify PASS = no review" is a backwards read.
  • --review flag: opt-in to re-open the confirmation loop for the rare "I doubt my own issue" case. Not a quality gate.
  • auto-merge clarification: legitimate under verify-gated PASS, justified by "verify is the gate" (not "merges are reversible" — revert is asymmetric: reviewed change + 2 history scars + distribution already shipped). Guardrails mandatory (clean 6/6 only, Step 0.8 trap scan, clean squash). auto-merge ≠ auto-close — idd-close still runs. Autopilot mechanics belong to feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37, not [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102.
  • Cites NSQL via the CLAUDE.md Reference Projects entry (added in fd2f21c during IDD human-in-the-loop should conform to the NSQL confirmation protocol (v4.1.0) #103 work).

• plugins/issue-driven-dev/skills/idd-all/SKILL.md — three changes:

  • (a) argument-hint (line 7) — add --review to the hint string.
  • (b) Phase 0 args parsing (around line 93) — recognize --review flag; record into $REVIEW_FLAG="--review" | "". Mutex with nothing (it's orthogonal to --pr/--no-pr and --cwd).
  • (c) Step 0 Bootstrap (around line 56) — add parse_review_flag TaskCreate entry alongside the existing preflight task.
  • (d) Phase 6 PR mode report (line 770–783) — swap messaging:
    • $REVIEW_FLAG="": Verify: verify-gated PASS + Next: merge ${PR_URL}, then /idd-close #${N}
    • $REVIEW_FLAG="--review": Verify: verify-gated PASS — awaiting human acceptance (re-opened confirmation loop per --review) + Next: review PR ${PR_URL}, merge after acceptance, then /idd-close #${N}
  • (e) Phase 6 direct-commit mode report (line 785–797) — analogous swap for the direct-commit terminal message.
  • (f) 鐵律 line 834 (永遠不 auto-merge PR) — stays unchanged. The doctrine permits auto-merge but idd-all default does not perform it; autopilot mechanics are feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37's deliverable.

• plugins/issue-driven-dev/skills/idd-all-chain/SKILL.md — three changes:

  • (a) Phase 0 args parsing — recognize --review flag.
  • (b) Phase 2 chain loop — propagate --review to chained /idd-all #M --in-chain invocations (so per-issue terminal state also reflects).
  • (c) Phase 4 final report (line 571+) — swap STOP — user 接手 review → merge → /idd-close to:
    • Default: STOP — verify-gated PASS across cluster, ready to merge → /idd-close #ROOT #SPAWN_1 ...
    • --review: STOP — verify-gated PASS, awaiting human acceptance (per --review) → review PR → merge → /idd-close ...
  • (d) PR body checklist (line 553) — conditional on $REVIEW_FLAG:
    • Default: - [x] **Verify-gated**: cluster verify PASS — ready to merge
    • --review: - [ ] **Pending: human acceptance review** (per --review flag) + /idd-close $REFS_LIST after merge

• plugins/issue-driven-dev/CHANGELOG.md — [2.65.0] - 2026-05-20 entry under [Unreleased]. One paragraph describing the doctrine + Phase 6/4 messaging swap + --review flag. Cites [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102 and credits IDD human-in-the-loop should conform to the NSQL confirmation protocol (v4.1.0) #103 NSQL conformance for the framing.

• plugins/issue-driven-dev/.claude-plugin/plugin.json — version bump 2.64.0 → 2.65.0 (minor: behavioral change to idd-all + idd-all-chain terminal messaging; --review flag is additive; MANIFESTO doctrine is documentation).

Sequencing & Dependencies

1. MANIFESTO.md doctrine FIRST — establishes the framing the skill messaging refers to. The Phase 6/4 message wording can then reference "verify-gated PASS" / "re-opened confirmation loop per --review" with the doctrine as the authoritative definition.
2. skills/idd-all/SKILL.md + skills/idd-all-chain/SKILL.md — independent files, can land in any order, but easier to dogfood by doing idd-all first (more commonly invoked) then chain.
3. CHANGELOG + plugin.json — last, after all substantive changes settle (so the v2.65.0 description chain accurately reflects the final shape).

Decision Points

• --review as flag, not config field — Per Discuss Conclusion: a standing acceptance_policy config field is deferred. An exception does not need a standing policy. Revisit only if feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37 bulk-solve needs a session-wide default. For now: per-invocation flag only.

• --review semantics — opt-in re-open, not opt-out gate — The flag adds the acceptance review back; it does NOT disable verify-gated PASS being terminal by default. Wording in Phase 6/4 must reflect this asymmetry: verify-gated PASS — awaiting human acceptance (re-opened confirmation loop per --review), NOT verify-gated PASS — pending second gate.

• MANIFESTO insertion point — NEW section AFTER 兩個正交的維度: Verification 與 Closure (which already discusses verification + closure axes) and BEFORE TDD/SDD 是 IDD 的 special case. This places the human-in-the-loop doctrine as a natural extension of the existing axis discussion, not a separate concept.

• Phase 6/4 messaging avoids "second gate" language — Per doctrine, verify IS the gate (the 6-AI ensemble is the falsifiable correctness check). --review re-opens the confirmation loop (an upstream concept from NSQL), not adds a downstream gate.

• PR body checklist swap (idd-all-chain) — Default behavior changes from Pending: human review to verify-gated PASS — ready to merge. This is a deliberate doctrine-aligned shift, not a regression. Existing callers that grep the PR body for "Pending: human review" will see the new wording; the audit value is unchanged.

Risks & Mitigations

#	Risk	Mitigation
R1	Doctrine misread as "auto-merge is now allowed by default"	MANIFESTO doctrine explicitly says auto-merge ≠ auto-close + autopilot mechanics belong to #37. idd-all 鐵律 line 834 (永遠不 auto-merge PR) stays unchanged — the default behavior of idd-all is unchanged.
R2	Phase 6/4 messaging swap breaks /loop callers grepping for "human review" / "Pending: human review" keywords	No known grepper. Terminal output is cosmetic, not a contract. If one surfaces, it becomes a v2.66+ follow-up.
R3	--review flag swallowed silently in unattended mode	Per-invocation explicit. If user passes --review, the flag IS the signal of human intent. The flag's effect is messaging-only — it doesn't make idd-all wait, it just labels the terminal state.
R4	idd-all-chain --review propagation to sub-idd-all calls broken	Step 2 chain loop must thread $REVIEW_FLAG into each /idd-all #M --in-chain arg list. Dogfood by inspecting Phase 4 forest report after a multi-issue chain run.
R5	MANIFESTO new section gets stale (referring to "v2.64.0+" hardcoded)	Use v2.65.0+ markers only where strictly needed (### Residue precedent in idd-diagnose). Doctrine prose itself avoids hardcoded versions.

Test Plan

Doctrine + messaging swap + new flag — no automated harness (prose skills, idd-all is a markdown skill, terminal output is part of Phase 6 prose).

Verification = consistency + dogfood:

1. MANIFESTO consistency check — new section doesn't contradict existing 兩個正交的維度 or 5 個 Skill = 5 個 Checkpoint sections. RED check: grep the new MANIFESTO file for auto-merge / verify-gated / --review; ensure each appears in the new section's own definitional context, not in conflict with other sections.

2. idd-all messaging additive — git diff plugins/issue-driven-dev/skills/idd-all/SKILL.md shows only:

   • argument-hint addition of --review
   • Phase 0 args parsing addition for $REVIEW_FLAG
   • Step 0 Bootstrap parse_review_flag task
   • Phase 6 PR/direct-commit message swap (conditional on $REVIEW_FLAG)
     No removed idd-implement / idd-verify / idd-close logic.

3. --review flag dogfood (manual trace) — trace through both /idd-all #N --review (expect awaiting human acceptance in Phase 6 report) and /idd-all #N (expect verify-gated PASS, ready to merge in Phase 6 report). No actual TDD test (it's prose), but trace the markdown logic.

4. idd-all-chain --in-chain propagation — read the chain Phase 2 loop pseudocode and confirm $REVIEW_FLAG is appended to the sub-idd-all invocation. Step 4 forest report should reflect the flag.

5. PR-path 6-AI idd-verify ensemble is the real gate. The 6 reviewers should converge on PASS for a doctrine + messaging swap PR; if they don't, the polish-in-PR pattern from IDD human-in-the-loop should conform to the NSQL confirmation protocol (v4.1.0) #103 applies.

Out-of-scope (will NOT be touched)

• Standing acceptance_policy config field — deferred per Discuss Conclusion. Revisit only if feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37 bulk-solve needs it.

• Autopilot auto-merge mechanics — that's feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37's deliverable, including the auto-merge → auto-close sequencing, clean 6/6 PASS detection, Step 0.8 trap scan integration, and squash message hygiene. [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102 only adds the MANIFESTO framing that makes verify-gated a named, sanctioned terminal disposition; the actual autopilot mechanic is feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37's job.

• references/pr-flow.md mode resolution algorithm — [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102 does not modify the (path, interaction) tuple. The --review flag is per-invocation only; it is not a third axis. pr-flow.md stays as-is.

• idd-verify / idd-implement / idd-close skill internals — no changes to verification logic, TDD loop, scope guard, or close gate. The doctrine merely interprets what these skills already do; it doesn't change them.

• idd-list / idd-update / idd-issue / idd-diagnose / idd-comment / idd-edit / idd-report / idd-config — none of these read the --review flag or display terminal-state messaging.

• README.md — the v2.65.0 entry will be added via /plugin-tools:plugin-update Phase 2.5 README freshness check at close time (same pattern as IDD human-in-the-loop should conform to the NSQL confirmation protocol (v4.1.0) #103 → db25514). Not in this PR's scope.

• MANIFESTO.md other sections — only the NEW section between lines 92 and 95 is added. The existing 11 sections are untouched.

Tangential Observations (filed mid-plan, v2.42.0+ #524)

Tangential Observations: filed #108 (4-template PR-body checklist consistency family — sync idd-implement Step 5.5 + idd-all Phase 5 + pr-flow.md canonical to match the #102 doctrine after this PR ships)

[kiki830621]

Implementation Complete

PR: TBD (Phase 5.5 next) · branch idd/102-acceptance-review-doctrine

Checklist (synced from TaskList)

• plugins/issue-driven-dev/MANIFESTO.md — Human-in-the-loop / NSQL Confirmation Protocol section → 4aef425
• plugins/issue-driven-dev/skills/idd-all/SKILL.md — argument-hint + Phase 0 args parsing + Step 0 bootstrap task + Phase 6 PR-mode + direct-commit-mode reports swap; 鐵律 line 834 unchanged → 1fdcba0
• plugins/issue-driven-dev/skills/idd-all-chain/SKILL.md — argument-hint + Phase 0 args parsing + Phase 2 --review propagation to sub-/idd-all + Phase 5 PR body conditional checklist → 11a99e0
• plugins/issue-driven-dev/CHANGELOG.md — [2.65.0] - 2026-05-20 entry → 8a41ee7
• plugins/issue-driven-dev/.claude-plugin/plugin.json — version 2.64.0 → 2.65.0 → 8a41ee7

Legend: - [x] done. idd-close will refuse to close if any - [ ] remains.

Changes

• 4aef425 feat(MANIFESTO): add Human-in-the-loop / NSQL Confirmation Protocol doctrine (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)
• 1fdcba0 feat(idd-all): add --review flag + Phase 6 verify-gated terminal wording (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)
• 11a99e0 feat(idd-all-chain): add --review flag propagation + Phase 4/PR body conditional wording (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)
• 8a41ee7 chore: bump issue-driven-dev to v2.65.0 (Refs [enhancement] acceptance-review 缺在 IDD mode model — 「人不 review」需要 first-class 做法 #102)

Files Changed

 plugins/issue-driven-dev/.claude-plugin/plugin.json    |  2 +-
 plugins/issue-driven-dev/CHANGELOG.md                  | 12 +++++
 plugins/issue-driven-dev/MANIFESTO.md                  | 42 +++++++++++++
 plugins/issue-driven-dev/skills/idd-all-chain/SKILL.md | 23 +++++++--
 plugins/issue-driven-dev/skills/idd-all/SKILL.md       | 56 +++++++++++++++---
 5 files changed, 123 insertions(+), 12 deletions(-)

Scope Compliance

On-plan — exactly the 5 enumerated files. MANIFESTO.md updated as the doctrine artifact (#102's deliverable, NOT #103's per the discuss boundary). idd-implement / idd-verify / idd-close skill internals untouched — doctrine interprets what they already do.

Out-of-scope items intentionally left:

• pr-flow.md mode resolution algorithm — --review is per-invocation, not a third axis
• idd-implement Step 5.5 / idd-all Phase 5 / pr-flow.md canonical PR-body checklist wording — filed as Sync 4-template PR-body checklist wording to match #102 NSQL doctrine #108 (4-template consistency family follow-up) per Step 2.5 tangential
• Autopilot auto-merge mechanics — feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37 territory
• README.md Version History — handled at /idd-close Step 6.5 via /plugin-tools:plugin-update Phase 2.5 (per IDD human-in-the-loop should conform to the NSQL confirmation protocol (v4.1.0) #103 precedent db25514)
• Standing acceptance_policy config field — deferred per Discuss Conclusion

Sister Bugs Filed (mid-impl, Step 5.7)

Sister Bugs Filed: #108 scope extended (#108 originally 4-template; sweep found references/chain-flow.md:254 has the same Pending: human review of cluster PR wording → updated #108 to 5-template consistency family). Source link: #108

Next: verification pending

/idd-verify --pr <N> after PR open (Phase 5.5)