@event4u/agent-config 14.7.0 → 14.9.0

package/dist/agent-src/commands/review/changes.md

@@ -9,7 +9,7 @@ visibility: internal
 sub: changes
 cluster: review
 skills: [code-review, subagent-orchestration, judge-bug-hunter, judge-security-auditor, judge-test-coverage, judge-code-quality, architecture-review-lens, judge-synthesis, git-workflow]
-description: Self-review local changes before creating a PR — dispatches to five specialized judges (bug, security, tests, quality, architecture) and consolidates verdicts
+description: Self-review local changes before creating a PR — dispatches to six specialized judges (bug, security, tests, quality, architecture, spec) and consolidates verdicts
 suggestion:
   eligible: false
   rationale: "Cluster sub-command — reached via its cluster head's routing or its explicit /cluster:sub name; not independently suggested (surface-consolidation)."
@@ -24,7 +24,7 @@ packs:
 ## Instructions
 
 Review all uncommitted and committed-but-not-pushed changes against
-the default branch (`main`) by dispatching to four specialized judge
+the default branch (`main`) by dispatching to six specialized judge
 sub-skills and consolidating their verdicts.
 
 ### 1. Update the current branch
@@ -51,6 +51,18 @@ to make sure the current branch is up to date with its base chain:
 
 ### 2. Gather the diff
 
+**Verify the base ref before diffing against it.** The commands below assume
+`origin/main` exists and is the right base, and nothing checked. This step
+already knows how to ask git a question — `git rev-parse --abbrev-ref HEAD`
+above — so the shape was present and simply not applied to the base:
+
+- `git rev-parse --verify origin/main` — the base ref resolves.
+  - **Does not resolve → stop here and say so.** Do not fall back to a
+    different base, and do not diff against `HEAD` alone. A review whose scope
+    silently became "the whole branch" or "the last commit" reports findings
+    against a diff nobody asked about, and the reader has no way to see that the
+    scope moved. Name the ref that failed.
+
 - `git diff origin/main..HEAD --stat` — overview of changed files
 - `git diff origin/main..HEAD` — full committed-but-not-pushed diff
 - `git diff --stat` + `git diff` — unstaged changes on top
@@ -65,7 +77,39 @@ Read `.agent-settings.yml`:
 
 Unknown alias → stop. Never silently fall back.
 
-### 4. Dispatch to the five judges
+### 3b. Bind the criteria source before dispatching
+
+The spec judge below is only as good as the criteria it reads, so where they
+came from is recorded **before** the dispatch, not reconstructed after it.
+Exactly one of three states, and the state is written into the review report:
+
+| `criteria_source` | When | What the report says |
+|---|---|---|
+| `supplied` | a roadmap, ticket, issue or AC block was explicitly handed in — name it by path or id | the criteria, verbatim, and where they came from |
+| `not_provided` | an ad-hoc branch review with no criteria anywhere | "no acceptance criteria supplied — requirement compliance NOT verified" |
+| `supplied_unparseable` | criteria were handed over and could not be read in a recognised shape | an **error**: the review skipped a dimension it was asked to check |
+
+```
+CRITERIA ARE READ ONLY WHEN SUPPLIED. NEVER DERIVED FROM THE BRANCH,
+THE COMMIT MESSAGES, OR THE PR BODY — AND NEVER FROM THE DIFF.
+A JUDGE THAT INFERS THE REQUIREMENT FROM THE CHANGE IT IS JUDGING
+ALWAYS FINDS THE CHANGE COMPLIANT. SILENCE IS `not_provided`, NEVER A PASS.
+```
+
+There is deliberately **no `derived` state**. Deriving criteria from the branch
+was the alternative considered and rejected: the `derived` label would have to
+be honoured by every consumer of the report to be worth anything, and a label
+that is requested rather than enforced degrades to silence exactly when it
+matters. Decided by AI council on 2026-08-22 (degraded, 1 of 2 seats — the
+second returned an empty response), and the alternative is recorded here rather
+than only in the decision so a later reader can see it was weighed.
+
+`supplied_unparseable` is separated from `not_provided` for the same reason:
+folded together, a handover the reviewer could not parse would report as "there
+was nothing to check", which is the one outcome that hides a real failure
+behind a benign one.
+
+### 4. Dispatch to the six judges
 
 Each judge receives **the same diff plus the task context** (ticket,
 PR body, commit messages) and runs independently. The judges are:
@@ -77,20 +121,37 @@ PR body, commit messages) and runs independently. The judges are:
 | [`judge-test-coverage`](../../skills/judge-test-coverage/SKILL.md) | Missing assertions, uncovered branches, over-mocking, regression-test gaps |
 | [`judge-code-quality`](../../skills/judge-code-quality/SKILL.md) | Naming, SRP, DRY, dead code, consistency with codebase conventions |
 | [`architecture-review-lens`](../../skills/architecture-review-lens/SKILL.md) | Layer violations, dependency direction, leaky abstractions, cross-service contract drift |
+| [`judge-spec-compliance`](../../skills/judge-spec-compliance/SKILL.md) | Does the diff satisfy every acceptance criterion **as stated**? Reads the criteria before the diff, and never infers them from it |
 
-The five judges weight equally in the consolidated verdict — none
+The six judges weight equally in the consolidated verdict — none
 overrides another.
 
+**Why the sixth exists, and why it is not a severity.** The other five all ask a
+craft-or-correctness question, so a change that is correct, clean, well-tested
+and architecturally sound — and **does not do what was asked** — used to pass
+this path with five green verdicts. Its finding does **not** enter the shared
+severity axis: `judge-synthesis` carries it on its own dimension, because "this
+does not do what was asked" is not comparable to "this variable is badly named",
+and on one scale the second can outrank the first whenever three judges raise
+nits and one raises the spec gap.
+
+**When no criteria were supplied** — an ad-hoc branch review — this judge
+returns a no-criteria verdict, never `SATISFIED`. That is not an abstention the
+consolidated verdict may drop: it changes what "done" is allowed to claim to
+*"craft quality verified; requirement compliance NOT verified"*. If that reads as
+most reviews, the honest reading is that most reviews were previously reporting a
+confidence they had not earned.
+
 Pick dispatch mode based on diff size and environment:
 
 - **Sequential** (default, simplest) — run bug-hunter → security-auditor
-  → test-coverage → code-quality → architecture-review-lens, collect
-  each verdict
+  → test-coverage → code-quality → architecture-review-lens →
+  spec-compliance, collect each verdict
 - **Parallel** — if `subagents.max_parallel` in `.agent-settings.yml` is
-  ≥ 5 and subagent dispatch is available, run all five concurrently
+  ≥ 5 and subagent dispatch is available, run all six concurrently
   following the `do-in-parallel` pattern in
   [`subagent-orchestration`](../../skills/subagent-orchestration/SKILL.md);
-  the five judges operate on the same diff but produce independent
+  the six judges operate on the same diff but produce independent
   reports, so no shared-state risk
 
 Each judge returns its own `Judge / Model / Target / Verdict /
@@ -108,14 +169,14 @@ Read `verbosity.offer_council_in_delivery` from `.agent-settings.yml`
 - `true`: when `ai_council.enabled: true` **and** at least one member
   enabled, ask (in the user's language):
 
-  > 1. Add an external council review alongside the four internal judges? (billable)
+  > 1. Add an external council review alongside the six internal judges? (billable)
   > 2. Skip — internal judges only
 
   Also suppress when `personal.autonomy: on` (council is billable).
 
 If picked **1**:
 
-- Run `/council diff:<base>..<head>` in parallel with the four
+- Run `/council diff:<base>..<head>` in parallel with the six
   internal judges (or sequentially after them — whichever the
   dispatch mode picked in step 4 supports).
 - Treat each council member as one extra "judge" in the consolidated
@@ -140,7 +201,7 @@ Read `subagents.adversarial_council` from `.agent-settings.yml` (default
   which supplies the four slots, the one-question budget, and the storage line
   (not persisted: `subagents.adversarial_council` is class C). What only this
   command knows is *why now*: the diff is high-risk, and the offer is a paid
-  distinct-model red-team for finding coverage against the five internal judges.
+  distinct-model red-team for finding coverage against the six internal judges.
 - `on`: run it automatically on a high-risk diff.
 
 When run, dispatch the
@@ -164,16 +225,36 @@ step 4 (plus any external council blocks from 4b) and produces one report:
 - A **must-fix / should-fix / advisory** split, each entry tagged with the
   judge(s) that raised it
 
+- A **spec-compliance block**, kept apart from that split — the
+  `criteria_source` state from step 3b, the per-criterion verdicts, and the
+  count of `MISSING` plus `PARTIAL`. See
+  [`judge-synthesis` § 4c](../../skills/judge-synthesis/SKILL.md); a spec
+  finding never becomes a craft finding.
+
 `judge-synthesis` emits no single quality score and never auto-gates — it
 structures the verdicts so the next step's decision is informed.
 
+**The report names its criteria source, always.** A reader six months later
+cannot otherwise tell "we checked the requirements and they were met" from
+"nobody checked" — and those are the two readings a bare `proceed` collapses.
+Where the state is `not_provided`, the overall sentence says *craft quality
+verified; requirement compliance NOT verified*, never a plain pass.
+
+**One telemetry line per review** records the structural outcome: which judges
+ran, whether the spec axis was reachable, and whether it changed the
+recommendation. Built and validated by
+`src/scripts/_lib/review_telemetry.ts::buildReviewLine`, which carries no field
+able to hold free-form content and **rejects** an input that adds one. Read the
+window back with `./scripts-run src/scripts/review_axis_report`; it reports
+"nothing observed" and "the axis changed nothing" as two different answers.
+
 ### 6. Decide next steps
 
 - If **any** judge returned `reject` → stop; the approach must change
   before proceeding
 - If **any** judge returned `revise` → fix 🔴 findings automatically,
   ask before fixing 🟡 findings, report 🟢 as suggestions
-- If all five returned `apply` → the diff is ready; report and stop
+- If all six returned `apply` → the diff is ready; report and stop
 
 **Opt-in (never auto-on):** when the `revise` findings are *test-driven*
 (failing checks, not subjective craft) and you want bounded auto-repair
@@ -218,7 +299,7 @@ Per `verbosity.routine_confirmations` (default `false`):
 ## Use this command when
 
 - Preparing a self-review before opening a PR
-- Stress-testing a local branch with the same five lenses a reviewer
+- Stress-testing a local branch with the same six lenses a reviewer
   would apply
 - Sanity-checking a diff before handing it to `/create-pr`
 
@@ -247,6 +328,6 @@ Per `verbosity.routine_confirmations` (default `false`):
 
 - **LLM-as-a-Judge** — [arxiv.org/abs/2306.05685](https://arxiv.org/abs/2306.05685)
   MT-Bench and Chatbot Arena — judging LLM outputs with LLM judges.
-  This command adapts the pattern by dispatching to four specialized
+  This command adapts the pattern by dispatching to six specialized
   judges (bug, security, tests, quality) instead of a single generic
   judge, and consolidating their verdicts.

package/dist/agent-src/commands/roadmap/process-full.md

@@ -7,7 +7,7 @@ cluster: roadmap
 sub: process-full
 skills: [agent-docs-writing, ai-council, roadmap-management]
 description: Autonomously process every open step across every phase of a roadmap until the file is fully closed. Largest execution scope of the /roadmap cluster — runs continuously across phase boundaries.
-argument-hint: "[roadmap]"
+argument-hint: "[roadmap] [--all] [--worktree]"
 suggestion:
   eligible: false
   rationale: "Cluster sub-command — reached via its cluster head's routing or its explicit /cluster:sub name; not independently suggested (surface-consolidation)."
@@ -80,6 +80,116 @@ with the **scope delta below**.
   archival check from
   [`roadmap-process-loop § 6`](../../contexts/execution/roadmap-process-loop.md#6-final-report-and-archival).
 
+## The three flags
+
+### `--all` — the estate, one roadmap at a time
+
+`--all` changes **cardinality, not lifecycle**: the same single-roadmap loop,
+iterated over the whole active estate. It is a flag rather than a
+`/roadmap:process-all` command because
+[`command-clusters`](../../../../../docs/contracts/command-clusters.md) says
+sibling variants become a flag, and a drain is a count of the thing this
+command already does.
+
+1. **Recompute the inventory live.** Never from memory, never from the
+   dashboard count — the same live-screen rule
+   [`/roadmap:next` § 1](../next/command.md) already carries. The corpus is the
+   non-draft roadmaps directly under `agents/roadmaps/`; `later/`, `skipped/`,
+   `archive/` and `stubs/` are out of scope.
+2. **Order the queue.** Roadmaps at or above 10 % checkbox progress first, in
+   **descending** progress — nearly-done first, because they convert soonest.
+   Roadmaps below 10 % are appended after, ascending by declared `complexity:`
+   tier (lightweight → bounded → structural), tiebreak ascending total
+   checkbox count. Both buckets need a **total** order or two runs over the
+   same estate disagree: within the first, ties on progress break by ascending
+   total checkbox count and then by ascending filename; within the second, by
+   ascending filename after the checkbox count.
+3. **Loop.** Per roadmap: branch from the updated default, run this command's
+   normal single-roadmap loop, deliver per § Delivery, then take the next
+   roadmap against the default **as it stands at that moment** — re-fetched,
+   never assumed. One roadmap = one branch = one PR, the existing invariant
+   iterated, not a new one.
+
+**What `--all` can and cannot promise, stated plainly because the honest
+version is weaker than the obvious one.** Nothing in the run
+merges, so the default does not advance because of this run, and every PR after
+the first is mergeable *against the base recorded when it was prepared* rather
+than against the base after its predecessors land. In a repository where every
+roadmap PR touches the same generated files, that means an `--all` hand-off is
+**one immediately-mergeable PR plus N−1 prepared ones**, each needing a
+re-sync at merge time. That is still the expensive half — conflicts classified,
+CI green once, superseded PRs closed — but it is not "N mergeable PRs", and the
+run reports it in those words.
+
+**A blocked roadmap never stalls the estate queue.** Inside a roadmap the five
+halt conditions and the terminal outcomes keep full authority. Between
+roadmaps, the § Halt-conditions table below is the single statement of what
+ends the roadmap and what ends the loop — including the two halts that are
+safety floors and therefore end the run. A `blocked` roadmap is recorded and
+the loop continues to the next one.
+
+### Delivery — every run, flag or not
+
+On outcome `complete`, open the PR as today, then run
+[`/pr:merge <N> --no-merge`](../../../git/pr/merge/command.md) on it: sync the
+base in, resolve conflicts by that command's four enumerated classes, drive the
+required checks green on the pushed head. **This is unconditional** — a bare
+`/roadmap:process-full` delivers a mergeable PR, not merely an open one, and
+waiting on that remote CI is part of the run per the Iron Law below. It is
+the whole of what this command delivers: there is no flag that carries it
+further, and § Merging below says why.
+
+### Merging — out of scope, cancelled rather than deferred
+
+```
+THIS COMMAND NEVER MERGES. THERE IS NO FLAG THAT MAKES IT MERGE.
+THE RUN ENDS AT MERGEABLE-AND-OPEN, ALWAYS, AND SAYS SO.
+A FUTURE MERGE CAPABILITY NEEDS A NEW ROADMAP AND AN OWNER RULING —
+NOT A COMMAND EDIT, AND NOT A FLAG THAT ALREADY SITS HERE INERT.
+```
+
+A `--merge` flag was specified here and has been **removed**. The
+`merge-authority` blocker of `road-to-drain-commands` closed as *not authorized
+in this roadmap*: activating the flag would have lowered
+[`non-destructive-by-default`](../../../../rules/non-destructive-by-default.md)'s
+per-turn confirmation floor for a production-branch merge, which
+[`decision-revisit-gate`](../../../../rules/decision-revisit-gate.md)'s
+owner-reserved table reserves to the owner. No owner ruling was available to the
+run that closed the roadmap, and an AI-council pass (2/2 convergent, 2026-08-22)
+ruled that a council may cancel an unauthorized implementation but may not
+manufacture the owner decision. The policy question is therefore **undecided,
+not rejected** — see
+[ADR-239](../../../../../docs/decisions/ADR-239-drain-command-surface-and-merge-authority.md)
+§ Disposition.
+
+The flag was removed rather than left inert deliberately: an archived roadmap
+must not leave latent executable authority behind a documented switch.
+
+Three independent findings stand behind the safety requirement, and any future
+attempt starts from them rather than re-deriving them: the AI council's Q1
+verdict (2026-08-21 — mergeability-only until authorization is target-bound and
+tamper-resistant), the committed `road-to-gate-preauth-authorization` stub (an
+authorization the agent can write is not an authorization), and the runtime
+guard that refused this roadmap's own attempt to edit the canonical loop
+contract.
+
+**Mergeability is per-PR against a recorded base, never a queue property.**
+When every PR in the estate touches the same generated files — in this
+repository `agents/roadmaps-progress.md` and the archive index — making PR *n*
+mergeable against base
+SHA `M` says nothing about its state once PR *n−1* advances the base to `M1`.
+Report "mergeable against base `<SHA>`", never "the queue is mergeable".
+
+### `--worktree` — isolate the workspace
+
+Route workspace creation through [`/worktree:create`](../../../engineering-base/worktree/create/command.md)
+in full, including its
+[§ 4b seeding allow/deny list](../../../../skills/using-git-worktrees/SKILL.md#4b-seed-the-worktree--allow--deny-list),
+which is the authority on what may be copied and what must never be — not
+restated here, because a second copy of a safety list is a copy that can
+drift. Under `--all` the worktree is created
+once and re-branched per roadmap; `/worktree:cleanup` runs at end of run.
+
 ## Iron Law — Full is Full
 
 ```
@@ -87,9 +197,15 @@ with the **scope delta below**.
 TO COMPLETION, ACROSS EVERY PHASE. ONLY THE FIVE HALT CONDITIONS STOP IT.
 PHASE-INTERNAL "(DEFERRED)" / "(OPTIONAL)" / "GATED ON PHASE X" NOTES DO
 NOT NARROW THE WORKING SET. A PHASE BOUNDARY IS NOT A STOP.
+UNDER `--all`, A ROADMAP BOUNDARY IS NOT A STOP EITHER — BUT A HARD-FLOOR OR
+SECURITY-SENSITIVE HALT ENDS THE WHOLE RUN, NOT JUST THE ROADMAP. THE TABLE
+UNDER THE HALT CONDITIONS IS THE ONLY STATEMENT OF WHICH ENDS WHICH.
+WAITING ON REMOTE CI FOR THE DELIVERY LOOP IS PART OF THE RUN. "CI IS
+RUNNING" IS NOT A BOUNDARY, NOT A HALT, AND NOT A REPORT — THE RUN ENDS
+AT A MERGEABLE PR, NEVER AT AN OFFER TO GO CHECK ON ONE.
 ```
 
-The **five — and only five — halt conditions** (exhaustive; nothing else
+The **six — and only six — halt conditions** (exhaustive; nothing else
 stops the run):
 
 1. **Hard-Floor** trigger ([`non-destructive-by-default`](../../rules/non-destructive-by-default.md)).
@@ -97,6 +213,38 @@ stops the run):
 3. **Security-sensitive** surface reached.
 4. **Scope-out-of-roadmap** work discovered.
 5. **Test / quality red** that cannot be cleared within the N=3 budget.
+6. **A merge conflict outside the four enumerated classes** of
+   [`/pr:merge` § 3](../../../git/pr/merge/command.md), during the delivery
+   loop. Added when delivery became unconditional: the loop runs on every
+   completed run, `--all` or not, so its stop is a stop of this command and
+   calling it "a kill switch rather than a halt reason" would not change that —
+   a run that stops has stopped. It fires only where a run reaches delivery,
+   which is the one thing that distinguishes it from the five above.
+
+**Under `--all`, which of these end the roadmap and which end the loop.** Two
+of the five are safety floors and they end the **whole run**, not the current
+roadmap:
+
+| Halt | Under `--all` |
+|---|---|
+| 1. Hard-Floor trigger | **Ends the run.** Stop and obtain this-turn confirmation. [`non-destructive-by-default`](../../rules/non-destructive-by-default.md) states that no roadmap authorization lifts the floor, and "record it and take the next roadmap" is exactly the roadmap-as-authorization bypass it names. |
+| 3. Security-sensitive surface | **Ends the run**, same reasoning. |
+| 2. Council-off + genuine ambiguity | Ends the roadmap; the loop records it and continues. |
+| 4. Scope-out-of-roadmap work | Ends the roadmap; the loop records it and continues. |
+| 5. Test / quality red past N=3 | Ends the roadmap; the loop records it and continues. |
+| 6. Unenumerated merge conflict in delivery | Ends the roadmap; the loop records it and continues. |
+
+**And the conditions that end the loop without ending a roadmap:**
+estate-queue exhaustion (always), a
+[`/pr:merge` § 8](../../../git/pr/merge/command.md) kill switch (always — that
+section arms its checks during **preparation**, not only before a merge, which
+is what keeps them reachable while the merge step is gated), and
+authorization-window expiry — which is **unreachable in this command**,
+because it never performs a `BLOCK_OPS` operation for the window to govern. Three conditions, one of them currently inert, and this
+table is the only place the set is stated.
+
+Nothing here widens a run without `--all`: it still has exactly the six
+above, all of them ending the run because there is no loop to continue.
 
 ```
 FORBIDDEN NON-HALT REASONS — NEVER STOP THE RUN FOR ANY OF THESE:
@@ -109,7 +257,13 @@ FORBIDDEN NON-HALT REASONS — NEVER STOP THE RUN FOR ANY OF THESE:
     runnable test over PRE-EXISTING blockers, never by how a step feels
   · "the branch is not protected" / "a branch must be created"
   · "a PR must be opened" / "a GitHub setting must change"
-  · "CI must be re-run" / "the merge base needs updating" / "there are conflicts"
+  · "CI must be re-run" / "the merge base needs updating" / "there are
+    conflicts" — resolving these IS the work. The one exception, and it is a
+    kill switch rather than a halt reason: a conflict **outside** the four
+    enumerated classes of [`/pr:merge` § 3](../../../git/pr/merge/command.md)
+    stops the delivery loop, because that is a case nobody has decided yet and
+    deciding it silently is how work disappears. An enumerated conflict is
+    never a stop.
   · "a paid service is needed" — authorised under the ceiling below
   · "a maintainer should do this" when the agent can perform the same action
   · any agent-invented caution not in the five halt conditions above.

package/dist/agent-src/commands/roadmap.md

@@ -38,7 +38,7 @@ paused for confirmation before every step) was removed —
 | `/roadmap:materialize` | `commands/roadmap/materialize.md` | Turn an accepted roadmap into the concrete artefacts it plans |
 | `/roadmap:process-step` | `commands/roadmap/process-step.md` | Autonomously process the next open step, then stop |
 | `/roadmap:process-phase` (**default execution scope**) | `commands/roadmap/process-phase.md` | Autonomously process every open step in the current phase |
-| `/roadmap:process-full` | `commands/roadmap/process-full.md` | Autonomously process every open step across every phase |
+| `/roadmap:process-full` | `commands/roadmap/process-full.md` | Autonomously process every open step across every phase; `--all` iterates the whole active estate, `--worktree` isolates the workspace |
 | `/roadmap:next` | `commands/roadmap/next.md` | Screen for the next executable roadmap, then carry it to a reviewable PR (selection + `process-full` + delivery) |
 
 Sub-command names match the locked contract in

package/dist/agent-src/contexts/execution/auto-dispatch-classification.md

@@ -89,14 +89,11 @@ evaluation-order accident.
 
 **Recursive-dispatch guard (2.3) — honest scope.** No verified host
 discriminator exists for "is this classification running inside a
-subagent/teammate session" — this roadmap's own `point-of-action-carrier`
-blocker records the upstream PreToolUse agent-identity request as closed
-NOT_PLANNED, and no field in this repo's hook envelope carries session
-lineage. The guard is therefore a CALLER-SUPPLIED fact
+subagent/teammate session", and no field in this repo's hook envelope carries
+session lineage. The guard is therefore a CALLER-SUPPLIED fact
 (`insideSubagentSession`), never a `process.env` probe for an unverified
-variable name — the same "no discriminator is publishable" null the
-`point-of-action-carrier` blocker already names. When set, it resolves ∅
-(in-session) for rungs 1-4; rung 0 is exempt (it never spawns).
+variable name. When set, it resolves ∅ (in-session) for rungs 1-4; rung 0 is
+exempt (it never spawns).
 
 **Relationship to the council's own necessity gate.** Rung 4's three
 signals (design decision / security downgrade / release-gate escalation)
@@ -127,6 +124,32 @@ Criteria are independent and additive in the obvious way (a slice matching
 two rows takes the higher of the two tiers); this table never lowers a
 tier `inferSliceTier` (§ below) already raised.
 
+## Cross-vendor worker direction (declared, not implemented)
+
+Deny-by-default — a direction not listed here is denied. Direction rules,
+payload allow/deny lists, the report-only boundary, the no-recursion clause and
+the human egress gate:
+[`cross-vendor-worker-direction`](../../../../docs/contracts/cross-vendor-worker-direction.md).
+Role pairs, never vendor names — `classifyLadder` carries no vendor identity
+([`subagent-routing`](subagent-routing.md) § Why vendor-neutral).
+
+Rung-1/2 slices only.
+
+| # | Direction (role pair) | Resolves to |
+|---|---|---|
+| CV-1 | a worker on the **non-authoring** vendor reviews the **authoring** vendor's output | report-only worker |
+| CV-2 | the mirror of CV-1 | report-only worker |
+
+```
+DIRECTION PERMITTED + PAYLOAD ALLOWED + HUMAN APPROVED = MAY SEND.
+ANY ONE MISSING = MAY NOT.
+A CROSS-VENDOR WORKER NEVER IMPLEMENTS, WRITES, COMMITS, ACTS,
+OR DISPATCHES ONWARD.
+```
+
+Nothing reads CV-1/CV-2 at runtime: a contract surface a future implementation
+must satisfy, replacing the phantom artefact the original survey cited.
+
 ## Per-slice tier inference (v1.5 — deterministic, task-TYPE-keyed)
 
 Once a slice is classified **delegable**, a second deterministic table infers
@@ -206,15 +229,11 @@ NEVER A SILENTLY DEGRADED ANSWER. NO LLM CLASSIFIER FALLBACK (CUT C3).
 | "does string Y exist" / "probe candidate strings" | `string-existence` | FTS one-shot (`memory_lookup` for the knowledge corpus) or capped `rg -n --max-count` for the codebase |
 | "run report Z" / "run check_*" | `report-run` | direct script run, wrapped per the **measured** rtk allowlist (`internal/bench/rtk-savings/RESULTS.md` — wrap only the ~55%-savings class) |
 
-**Why rg-first for definition/references** (council debate 2026-07-28,
-claude-sonnet-4-5 + gpt-4o, 2 rounds): the pre-registered benchmark behind the
-`code-graph-retrieval-null` claim (`docs/CLAIMS.md`) measured native-graph
-recall 0.365 vs grep 0.797 on graph-shaped questions, root cause an **indexing
-gap** (TS arrow-function exports produce no symbol nodes) that hits structured
-lookups exactly as it hits NL retrieval — and the recorded consequence bound
-keeps `code_graph.enabled` false permanently. The accelerant clause is the
-escape hatch that bound names ("unless external evidence appears"); today it
-is inert.
+**Why rg-first** (council 2026-07-28, 2 rounds): the pre-registered benchmark
+behind the `code-graph-retrieval-null` claim (`docs/CLAIMS.md`) measured
+native-graph recall 0.365 vs grep 0.797 on graph-shaped questions — an
+indexing gap that keeps `code_graph.enabled` false permanently. The accelerant
+clause in the table above is that bound's escape hatch and is inert today.
 
 **Escalation, not degradation:** a primitive that returns nothing (index miss,
 pattern too ambiguous, report script absent) — **or an unusable result**
@@ -238,26 +257,17 @@ budgeted (consume part of the N=3 autonomous budget) and opt-in. Not in v1.
 
 ## Reference implementation
 
-The deterministic rules are encoded in
-[`src/scripts/_lib/auto_dispatch.ts`](../../../../src/scripts/_lib/auto_dispatch.ts)
-(`classifyTask`, `classifyLookup` for the lookup-class rung), covered by
-[`tests/scripts/_lib_auto_dispatch.test.ts`](../../../../tests/scripts/_lib_auto_dispatch.test.ts)
-and the lookup corpus in
-[`src/scripts/_lib/auto_dispatch.corpus.test.ts`](../../../../src/scripts/_lib/auto_dispatch.corpus.test.ts)
-(`LOOKUP_CORPUS` — the four live-observed shapes + negative controls).
-
-The judgment ladder (§ above) is encoded in
-[`src/scripts/_lib/judgment_ladder.ts`](../../../../src/scripts/_lib/judgment_ladder.ts)
-(`classifyLadder`, plus the rung-0/1/3/4 signal-detection functions), covered
-by
-[`tests/scripts/_lib_judgment_ladder.test.ts`](../../../../tests/scripts/_lib_judgment_ladder.test.ts)
-(every rung, the rung-3 degrade path, the recursive-dispatch guard, and every
-∅ case). The delegation-nudge hook
-([`delegation_nudge_hook.ts`](../../../../src/scripts/hooks/delegation_nudge_hook.ts))
-is its first production caller — its injected line cites the resolved rung
-(`rung-2: dispatch do-in-parallel …`), scoped to the subagent dispatch rungs
-(1/2); a rung-0/3/4 verdict stays silent on this carrier until Phase 3/4 give
-team/council their own.
+- `classifyTask` / `classifyLookup` —
+  [`auto_dispatch.ts`](../../../../src/scripts/_lib/auto_dispatch.ts)
+- `classifyLadder` + the rung-0/1/3/4 signal detectors —
+  [`judgment_ladder.ts`](../../../../src/scripts/_lib/judgment_ladder.ts)
+- First production caller —
+  [`delegation_nudge_hook.ts`](../../../../src/scripts/hooks/delegation_nudge_hook.ts):
+  its injected line cites the resolved rung, scoped to the dispatch rungs
+  (1/2); a rung-0/3/4 verdict stays silent on this carrier.
+
+Each has a sibling `*.test.ts` under `tests/scripts/` covering every rung, the
+rung-3 degrade path, the recursive-dispatch guard and every ∅ case.
 
 ## Related
 

package/dist/agent-src/contexts/execution/autonomy-mechanics.md

@@ -86,18 +86,53 @@ In `auto` mode, flip to `on` for the rest of the conversation when the user expr
 
 Algorithm and speech-act heuristic: [`autonomy-detection.md`](autonomy-detection.md). Anchor phrases (DE+EN), no-flip patterns, counter-examples, trivial-vs-blocking taxonomy, commit-policy summary, and named failure modes: this file + [`autonomy-examples.md`](autonomy-examples.md).
 
-## Task-scope — two autonomy shapes
+## Task-scope — three autonomy shapes
 
 Depth for the rule's task-scope Iron Law (`NEW TASK → FRESH CONFIRMATION`).
-Two distinct autonomy shapes — keep them apart:
+Three distinct autonomy shapes — keep them apart:
 
 | Shape | Trigger | Scope |
 |---|---|---|
 | **Conversation-wide trivial-question suppression** | "stop asking on trivial steps, just work" — no deliverable named. | Sticky for the rest of the conversation. Suppresses trivial workflow questions only; never lifts blocking, Hard Floor, or [`scope-control`](../../rules/scope-control.md) gates. |
 | **Task-scoped autonomous execution** | "work autonomously on X", "arbeite die Roadmap Y komplett ab", "do PROJ-123 end-to-end" — a deliverable / artifact / ticket is named. | Bound to **that** task. Ends when the task ends. Does **not** authorize starting a new, distinct task autonomously. |
+| **Set-scoped autonomous execution** | An accepted execution contract whose pre-scan **enumerated** a closed, ordered set of deliverables — the set members are named on the contract screen before the single Accept. | Bound to **that enumerated set**. The loop may move from one listed member to the next without a new contact. A member not on the accepted list is a new task and needs fresh confirmation. |
 
 Litmus test: does the directive name (or unambiguously point to) a single concrete deliverable? Yes → task-scoped, scope ends with the deliverable. No → conversation-wide, trivial-question suppression only.
 
+Set-scoped is the same litmus applied to a **list** instead of a single item, and
+it is deliberately the narrowest thing that makes a set run possible:
+
+```
+SET-SCOPED AUTONOMY IS BOUNDED BY THE ENUMERATION THE USER SAW.
+A MEMBER ON THE ACCEPTED LIST IS CONTINUATION. ANYTHING ELSE IS A NEW TASK,
+AND `NEW TASK → FRESH CONFIRMATION` APPLIES TO IT VERBATIM.
+THE SET IS CLOSED AT ACCEPT TIME AND NEVER GROWS DURING THE RUN.
+```
+
+Four conditions, all of which must hold before a run may claim set scope. They
+exist because "a set" is exactly the phrasing under which an unbounded backlog
+could be smuggled in as one authorization:
+
+1. **Enumerated before Accept.** Every member is printed on the contract screen
+   — name, branch, and its own artifact count. A set the user did not read is
+   not a set they authorized.
+2. **Closed.** The list cannot grow after Accept. A roadmap discovered mid-run
+   is a new task, not a late set member; it waits.
+3. **Ordered, with independence declared.** The contract states the order and
+   which members carry no declared dependency, because that is what decides
+   whether the loop may continue past a failure (see
+   [`roadmap-process-loop § 3d`](roadmap-process-loop.md)).
+4. **One contract, one Accept.** Set scope is granted by the same single Accept
+   as any other mode. It is never inferred from the fact that several roadmaps
+   happen to be open.
+
+What set scope does **not** touch: the Hard Floor, the locked decision classes,
+the kernel-edit soak, and every
+[`scope-control`](../../rules/scope-control.md) gate. It removes the *re-ask
+between listed members* and nothing else — a set run that reaches a Hard-Floor
+action stops there exactly as a single-task run would.
+
+
 When the user later issues a **new** request — different ticket, different roadmap, different artifact, different feature — treat it as a fresh task. Re-confirm autonomy for the new scope before:
 
 - creating a branch / worktree / PR / tag for the new work,