octopus-workflow/core/rules/auto-approve.md

Core 中立版（Increment 2 改写）。术语对照见 core/adapters/TERMINOLOGY.md；本组织实例表述见 dogfood 对应文件。

Auto-approve stages

The auto_approve block in the instance config controls which pipeline gates the agent passes without asking the user. Stage identifiers are matched against the stage registry (harness 内建的阶段注册模块). Unknown or retired identifiers fall back to manual confirmation (fail-closed) with a one-time auto_approve.unknown_stage warning — copy ids verbatim from the table below.

Scope boundary: auto_approve vs permission

Two independent mechanisms — confusing them is the most common "auto-approve isn't working" report:

• auto_approve gates only the question tool (pipeline decision questions; the harness 内建的自动批准判定模块); no effect on tool execution.
• permission gates tool / file-system operations (bash, read, write, external_directory, …) and never consults auto_approve. external_directory defaults to ask, so outside-project prompts are expected even with every stage enabled.

auto_approve does NOT suppress permission prompts — intentionally so. To stop a permission prompt, change the matching permission rule or use the UI's "auto-accept permissions" toggle (browser-local, not the project auto_approve config).

Stage	Gate	Risk
review-dag	DAG single-gate review	Medium — sets direction
review-code	Code review	Medium — gates what reaches main
verify	Iteration verification	Medium — runs tests / DoD matrix
audit-process	Process infrastructure audit	Medium — read-only but gates process changes
merge-pr	Create PR + merge to main	High — irreversible landing

Risk values mirror the stage registry's BUILTIN_STAGES[].risk — the registry is the runtime authority; if this table and the registry disagree, fix this table. merge-pr is excluded from default/preset stages arrays (not structurally blocked; explicitly adding it is not recommended). Legacy stage retirement (12 → 5): the phase-3 retirement ruling doc (Tier-2 reference, reachable via the ticket backend).

Config shape: "auto_approve": { "stages": ["review-code", "verify"], "stageless": false } — stages empty ([]) = all manual; stageless: true also auto-approves questions called without a stage. Absent block defaults to { stages: ["review-code", "verify", "audit-process"], stageless: false }; the removed enabled field migrates on load (mapping: Tier-2 reference page rules/auto-approve-detail). Presets (safe/full/off/show): same reference page — full never includes merge-pr.

Stage matching behavior

• Question has a stage → auto-approved iff that stage is in stages.
• Stageless question → auto-approved iff stageless: true; otherwise prompts.
• destructive: true → ALWAYS prompts, regardless of config — the safety net for irreversible actions; business-decision questions are never covered by a stage whitelist (§"Mandatory destructive list").

Check logic: the harness 内建的问询与自动批准判定模块 (resolveAutoApproveDecision).

Live-gate degradation chain ([org-internal #3531])

An auto-approved question is NOT consumed instantly: L1 — a live human watching the session (SSE declaration / fresh presence ping) answers within question_live_gate.timeout_sec (default 600) and overrides the default; L2 — blocking questions with a #<ticket> title and a ticket-backend token fall back to a ticket comment answered as **answer <question-id>** <label> (default 3600s); L3 — auto default (first option, annotated live-gate … → auto default). timeout_sec: 0 disables the whole gate (legacy instant default); l2_timeout_sec: 0 disables only L2. nonblocking: true questions never reach L2/L3 — no live human → parked in the pending-answer queue, answered later from the console. Every final decision publishes a question.degradation.routed event. destructive: true is untouched by the chain: decide() rejects it before the gate runs (iron law).

Mandatory destructive list (业务决策类问询强制清单)

Origin: [org-internal #3223] — a stage whitelist auto-answered two irreversible production data changes because nothing marked them destructive. A stage whitelist grants "execution gates may proceed uninterrupted"; it must NEVER grant "business decisions may be self-answered". stage names the pipeline phase, destructive names the business risk.

Iron Law: a question whose recommended/executed action falls in ANY category below MUST be called with destructive: true. The auto-approve stage whitelist is never a substitute for human confirmation of these categories.

1. Merge / release landing — merging a PR to main, cutting a tag or release, deploying/promoting to production (server-side auto-merge is a human-configured policy robot, never agent self-answer latitude; kill switch: the auto-merge-low-risk runbook, Tier-2 reference via the ticket backend).
2. Production database writes — upsert/update/delete against production data stores, production data migrations, live-data backfills.
3. Billing / plan changes — plan or tier migration, pricing/concurrency changes, anything touching billing state.
4. Org / tenant structure changes — org or workspace migration, tenant topology changes, moving resources between orgs.
5. Deletion of durable resources — deleting data, branches, worktrees, deployments, or any resource outside /tmp and session-scratch space.
6. Persistent config writes — config changes that outlive the session (writing to the instance config file, the instance process-config area, deploy/systemd units, or other on-disk configuration consumed by other sessions/services).

This list is the floor, not the ceiling: any other irreversible business-visible decision also carries destructive. When in doubt, mark it — a redundant prompt costs one round-trip; an auto-approved production write can cost the data. Mirrored in the question tool's self-description for paths without L1 injection.