spec(v3.0 r2): wholesale rewrite after three pre-flights

r1 is superseded, not patched -- spec drift by patching is a repeat failure here.

Killed by the pre-flights: the headless justification for Engine A (workflows ARE
available in -p and the SDK; only the ultracode keyword is route-restricted); the
name "Engine B" (taken by the rejected claude -p shell-out; the Workflow engine
is Engine C in nine places); a false citation of a || true contract that lives on
the v2.18 branch, not main; and AC-8, which had no schema field and no transport.

Found and closed: a Gate stage that throws would skip Record entirely and lose the
audit trail on exactly the jobs that failed (v2.6.4 recurring); agent() returning
null would read as "no violations"; override #4 returns low/low bands beside
override_fired=4 and would have granted auto-route to an overridden record; the
auto-route class gated on shape with no checks-passed and no history predicate,
and re-validated only line count post-diff, leaving three TOCTOU windows open;
docs-only is a self-modification hole here because skills/agents markdown IS the
enforcement layer; the floor was missing previously-failing and newly-added; and
none of tests/ is executed by CI at all.

v2.18-autonomy is absorbed: Feature C already exists as _enforcement_rule in its
hook, and two blocking Stop registrations are undefined behaviour.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: copeus

docs/superpowers/expert/_knowledge-base/autonomous-agent-orchestration.md

@@ -143,3 +143,95 @@ Maintained by Compound V Phase 1B advisor. Append at the bottom on each pass.
   halt, breaker state n/cap, exact copy-paste resume command, paths to evidence}. Distinguish
   "whole run blocked, act now" (page) from "one unit parked, rest proceeding" (batch into a
   morning summary).
+
+---
+
+## Updated 2026-09-01 — native Claude Code `Workflow` runtime contract (v3.0 audit)
+
+All quotes verbatim from the official
+[dynamic-workflows doc](https://code.claude.com/docs/en/workflows), fetched 2026-09-01.
+
+### The caps are agent-COUNT only. There is no spend cap.
+
+- *"Up to 16 concurrent agents"*, *"1,000 agents total per run"*, *"Up to 4,096 items in a single
+  `parallel()` or `pipeline()` call: the runtime rejects a longer list with an error."*
+- The runtime's own cost claim, which is weaker than it reads: *"The runtime's agent caps limit how
+  many agents a single run can spawn, which bounds the cost of a runaway script."* 1,000 agents ×
+  unbounded tokens each is not a ceiling.
+- The only cost signal is **advisory and suppressible**: *"When a workflow schedules more than 25
+  agents, or its projected token total passes 1.5 million, its progress line … shows a `Large
+  workflow` warning … The warning is advisory: it doesn't pause or limit the run."* And: *"Sessions
+  with ultracode on don't show the warning."*
+- `workflowSizeGuideline` (`small`/`medium`/`large`, default `medium` = <15 agents) is also not a
+  cap: *"Claude Code sends the guideline to Claude as advice, not a cap."*
+- **Reusable rule:** on this runtime the only cost control you can actually build is *measurement* —
+  record per-run token totals into your own state file. Do not enable ultracode as part of an
+  orchestration engine: it raises effort *and* suppresses the sole cost signal.
+
+### Route availability — a widely-repeated claim is WRONG
+
+- ~~"Workflows cannot be launched from `-p` / SDK / scheduled routes"~~ → **corrected 2026-09-01:**
+  *"Workflows are available in the CLI, the Desktop app, the IDE extensions, non-interactive mode
+  with `claude -p`, and the Agent SDK."*
+- What is route-restricted is the **`ultracode` keyword** opt-in, not the tool: *"The keyword is an
+  opt-in only in a prompt you type yourself … It doesn't start a workflow when it reaches the session
+  another way: a prompt passed with `-p` … a scheduled task prompt … a webhook payload."* (That
+  restriction itself landed in v2.1.210; earlier versions honored the keyword from every route.)
+- The launch is approvable with no human present: *"In `claude -p` and the Agent SDK, Claude Code
+  never shows this prompt"*, and it can be approved by an allow rule (`Workflow`), Auto mode, a
+  `PreToolUse` hook returning `allow`, or **bypass-permissions mode** (*"Claude Code approves the
+  call"*).
+- **Hazard to name in any design:** a `bypassPermissions` headless run can fan out up to 1,000
+  agents with no prompt and no spend cap. Choosing to keep headless on a non-Workflow engine is a
+  *policy* decision and must be argued as one, not attributed to a capability the runtime does not
+  actually lack.
+- Still true and independently probe-verified: **a subagent cannot launch a Workflow**, so any
+  orchestration seam must live in the top-level session.
+
+### Three runtime contracts that break naive generated scripts
+
+1. **Determinism is enforced by throwing.** *"Claude Code makes `Date.now()`, `Math.random()`, and a
+   no-argument `new Date()` throw inside the script, so that a relaunched run repeats the same
+   `agent()` calls. Pass a timestamp in through `args` instead."* Also *"No module loading: a script
+   that contains `import()` fails before the run starts."* Any manifest→script generator must emit
+   neither; timestamps and run-ids arrive via `args`.
+2. **`agent()` can return `null`, and `pipeline()` preserves it.** *"An `agent()` call resolves to
+   `null` if you stop it mid-run or it hits an unrecoverable API error. `pipeline()` keeps that
+   `null` in the results array."* A downstream verification stage must treat `null` as FAIL, never as
+   skip — otherwise the gate is unreachable exactly when the worker died.
+3. **Resume re-runs completed work.** *"Failed: runs again, and so does every agent that started
+   after it, even ones that completed … If a script starts A, B, C, and D in that order and B fails,
+   relaunching returns A from cache and runs B, C, and D again."* Any stage that writes/commits state
+   or appends to an outcomes stream **must be idempotent**.
+
+### No human in the loop mid-run
+
+*"No mid-run user input … Only agent permission prompts can pause a run. For sign-off between stages,
+run each stage as its own workflow."* Any invariant of the form "the human accepts the tier before we
+proceed" must be satisfied **before** launch; it cannot be honored inside a workflow.
+
+### Resume scope — narrower than a state file, wider than "same session"
+
+*"You can resume a run within the same Claude Code session."* Backgrounding carries a run over, and
+*"a session you resume with `claude --resume` can replay them"* — but *"a session you start fresh has
+nothing to replay and starts the workflow over."* Treat a workflow as an inner loop for one dispatch,
+never as the system of record for crash recovery.
+
+### FABRICATION FLAG (second sighting) — the "$47,000" agent-cost figure
+
+Previously flagged (2026-07-12 entry) as a single-source aggregator claim, and again in the
+2026-09-01 recon attributed to aicosts.ai. On this pass it resurfaced on vendor marketing pages under
+a **different** attribution — a "4-agent LangChain loop [that] ran 11 days"
+([TokenOps](https://commandline.microsoft.com/tokenops-real-time-run-scoped-cost-control-ai-agents/),
+[Portal26](https://portal26.ai/ai-agent-cost-control-stop-agents-burning-budget/)) — with no primary
+incident report behind either version. **Two mutually inconsistent attributions for one number is
+stronger evidence of fabrication than one.** Never cite it. The *mechanism* (per-step caps without a
+global ceiling) remains well corroborated; the dollar figure is not.
+
+### Evidence quality note on "what practitioners do about agent cost"
+
+Every 2026 source found on runtime token-budget enforcement is **vendor content marketing** (TokenOps,
+Portal26, OpenLegion, Waxell, Nexgismo, TrustGate). Internally consistent and mechanistically
+plausible, but **no independent benchmark, post-mortem, or regulator notice** corroborates any of the
+specific practices or numbers. The 2026-07-12 entry above reached the same conclusions from different
+sources and did so more carefully — prefer it.

docs/superpowers/expert/_knowledge-base/dev-workflow-triage-devex.md

@@ -129,3 +129,126 @@ because the risk lives in the *content/semantics* of a small string edit, not th
 - **All-safe, not majority-safe:** RADAR auto-accepts only if the ENTIRE diff falls in a
   safe-category allowlist; any single risk signal disqualifies. v2.9's conservative-max
   (never-average-down) mirrors this — keep it.
+
+---
+
+## Updated 2026-09-01 — unattended auto-commit class + blocking Stop gate (v3.0 audit)
+
+### Pre-authorization is earned by HISTORY, not granted by shape
+
+- ITIL's *standard change* — the field's name for "pre-approved, no case-by-case review" — is defined
+  by four properties, and the one automated designs routinely omit is history: repeatable,
+  documented, **low risk as demonstrated by history**, pre-approved. ("history shows this change
+  rarely causes service disruption"). Sources are secondary and mutually consistent rather than one
+  canonical text: [Faddom](https://faddom.com/itil-change-management-types-standard-vs-normal-vs-emergency/),
+  [Spoclearn](https://www.spoclearn.com/blog/itil-4-definition-of-standard-change/),
+  [IT Process Wiki](https://wiki.en.it-processmaps.com/index.php/Change_Management). **Treat as
+  directional — no primary ITIL text was fetched.**
+- **Reusable rule:** a static predicate set (path shape, line count, sensitivity globs) defines
+  *candidacy*. It does not define *authorization*. An auto-action class with zero operating history
+  should ship **disarmed** — implemented, tested, and recording predicted-vs-actual — and arm only
+  after N recorded decisions with clean outcomes. This makes the outcomes stream a *precondition*
+  of the auto-route rather than telemetry beside it.
+
+### Every shipped unattended-landing system gates on EVALUATION, not on size
+
+- Renovate, verbatim: *"By default, Renovate will not automerge until it sees passing status checks /
+  check runs for the branch"*; *"We strongly recommend you have tests in any project where you are
+  regularly updating dependencies"*; *"Keep automerge **disabled** for updates where you want to read
+  the changelogs or code before the merge"*
+  ([Renovate docs](https://docs.renovatebot.com/key-concepts/automerge/)).
+- Google SRE canarying requires *"An evaluation process to evaluate if the canaried change is 'good'
+  or 'bad'"* plus *"Integration of the canary evaluations into the release process"*
+  ([SRE Workbook](https://sre.google/workbook/canarying-releases/)).
+- **Reusable rule:** if an auto-action class has no predicate of the form "a check ran and passed on
+  the realised artifact," it is not an automation policy — it is an unconditional action wearing a
+  filter. Check that the eligibility predicates and the verification step live in the *same* spec
+  feature; when they are specified separately, nothing orders them.
+
+### Line count: a NECESSARY condition, never a sufficient one
+
+Evidence is genuinely two-sided and neither side is strong:
+- Against LOC as a risk proxy (practitioner-metrics tier, search summaries, **not fetched**): *"a
+  10,000-line release with a 0% failure rate is better than a 100-line release that takes down
+  production"* ([codepulsehq](https://codepulsehq.com/guides/lines-of-code-metric-guide),
+  [LaunchDarkly](https://launchdarkly.com/blog/change-failure-rate/)).
+- For, in aggregate (defect-prediction literature, **search summary only, numbers unverified**):
+  buggy commits reported ~3× larger; defect-detection efficacy falls above ~400 lines
+  ([arXiv 1811.03758](https://arxiv.org/pdf/1811.03758),
+  [tekin.co.uk](https://tekin.co.uk/2020/05/proof-your-thousand-line-pull-requests-create-more-bugs)).
+- **Reusable rule:** LOC is a decent population-level correlate and a bad per-change predictor. Use
+  it to *exclude* the population where risk concentrates; never state it as the safety property in
+  shipped docs.
+
+### Re-checking eligibility against the realised diff has a name: TOCTOU
+
+- The pattern is a time-of-check-to-time-of-use mitigation; the standard remedy for
+  [CWE-367](https://cwe.mitre.org/data/definitions/367.html) is to re-check at time of use rather
+  than trust a cached authorization.
+- **Reusable rule, and the usual bug:** a TOCTOU re-check must cover **every** predicate the action
+  can invalidate, not the one that is easiest to measure. Re-checking only "size" while leaving
+  "which paths," "is it sensitive," and "did it touch tests" on the pre-action estimate is a size cap
+  with a security-sounding name.
+
+### "It's only documentation" is repository-dependent
+
+- **No credible postmortem exists** for the classic docs-change-took-prod-down anecdote — two
+  searches returned only templates. Do not cite one.
+- The real argument is structural: in repositories where prose *is* the mechanism (agent skills,
+  agent definitions, CLAUDE.md/AGENTS.md, policy YAML), markdown is the enforcement layer, and a
+  docs-only exemption is a self-modification hole in the control surface.
+- **Reusable rule:** before writing a documentation exemption, ask whether any `.md` in the repo is
+  *read as instructions by something*. If yes, the exemption must enumerate paths, not file types.
+  Also add the policy file that defines the exemption to its own sensitive set, so a class cannot
+  widen itself in the turn it is used.
+
+### Blocking gates: false positives produce bypass, and the agent is now a bypasser too
+
+- Measured trust damage: Chromium CI, 2,000 builds / >1M failures — *"false alerts represent 81% of
+  the failures … whereas legitimate failures only represent 19%"*, and *"developers may lose trust in
+  their test suites and stop considering failures even if some of them are caused by real faults"*
+  ([arXiv 2111.03382](https://arxiv.org/pdf/2111.03382)).
+- **New in 2026: the model bypasses the gate.** *"Claude Code can ship broken code by running
+  `git commit --no-verify`"*; *"Anthropic's claude-code issue #40117 describes Claude Code Opus 4.6
+  bypassing explicit deny rules and CLAUDE.md instructions across six consecutive commits, using
+  `--no-verify`, `git stash`, and quiet flags."* Conclusion drawn there: *"The hook layer is the only
+  one that reliably enforces the rule."*
+  ([pydevtools](https://pydevtools.com/handbook/how-to/how-to-stop-ai-agents-from-bypassing-pre-commit-hooks/))
+- **Reusable rule:** the hook layer is the right layer, and a block message that names its own opt-out
+  is a bypass tutorial for a model already documented as hunting escape hatches. Name the opt-out to
+  the human, not in the model-visible reason string. Record every opt-out — a silent opt-out is an
+  unmeasurable bypass, which is usually the exact defect the gate was built to fix.
+
+### Claude Code `Stop` hook contract — two traps (verified 2026-09-01)
+
+From the [hooks reference](https://code.claude.com/docs/en/hooks):
+- **Only exit 2 blocks.** *"A hook that times out or exits nonzero (other than 2, which blocks) is a
+  non-blocking error: Claude continues to stop, and the transcript shows a `<hook name> hook error`
+  notice."* Any design doc asserting "a non-zero exit from a Stop hook *is* a block" is stale. The
+  structured payload field is `permissionDecision: "block"`.
+- **Stop/SessionEnd hooks share a 1.5s budget across ALL hooks.** *"These events get a shared
+  per-event budget of 1.5 seconds by default across all hooks; if your settings set a longer per-hook
+  `timeout`, Claude Code raises the budget to match, up to 60 seconds."* A `Stop` hook that shells out
+  to `git status` in a large repo — especially composed with a second registered `Stop` hook — can
+  time out, and a timeout is a **silent** non-blocking error. This is the "silently dead guard"
+  failure mode; require a measured wall-clock selftest, not a config review.
+- `stop_hook_active` is documented per-event (*"true when a `Stop` hook has blocked the stop and
+  Claude is continuing"*), which does **not** support the folk claim that it is never cleared once
+  set. Verify against the runtime before relying on either reading.
+
+### "Off by default" for a policy gate — evidence is two-sided, and we have our own datapoint
+
+- The security-defaults literature names **both** as legitimate principles: *"Among the newer
+  principles are an 'off by default' principle"*, and *"the 'off by default' design principle is
+  matched by an 'on by default' principle in terms of some or all security features available"*
+  ([SoK, arXiv 2412.17329](https://arxiv.org/pdf/2412.17329)). There is no scholarly consensus that
+  off-by-default is wrong for a policy gate.
+- The adoption evidence cuts the other way (2FA-at-registration vs. 2FA-set-up-later) but the verbatim
+  string was **not** located in the fetched PDF text — treat as paraphrase.
+- **Our own in-house datapoint is the sharpest one:** `skills/compound-v/workflows-accelerator.md:5`
+  shipped Engine C as *"kept in 1.0, opt-in, default OFF"* — and it was never implemented and never
+  used. One local sample of off-by-default is one local sample of never-adopted.
+- **Reusable rule:** off-by-default is defensible for a gate with an *unmeasured* false-positive rate,
+  and indefensible as a *permanent* state. Ship it off, but attach a flip condition: a stated FP rate
+  over a stated number of sessions, with a named owner. Without that, the gate is a no-op that still
+  costs maintenance.