[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: diagnosed

Complexity

Spectra — Layer 2 (modifies the published (path, interaction) mode contract in pr-flow.md, consumed by all IDD skills) + Layer 3 (architectural decision, normative-behavior change, cross-cuts 4+ skills).

Next

/spectra-discuss — topic "acceptance-review as an IDD mode dimension". Open questions: direction A/B/C, axis-value naming, the AI-delegated-review independence question.

History

• 2026-05-19 — filed via /idd-issue (acceptance-review design gap surfaced in cluster-PR mode 強制 PR 與 direct-commit path 衝突：override 未文件化且 --no-pr 行為未定義 #96-backlog triage session)
• 2026-05-19 — diagnosed (Spectra): comment-4485759337

[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.