@event4u/agent-config 14.6.0 → 14.8.0

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)."
@@ -25,6 +25,14 @@ cluster. Same canonical loop as
 phase boundaries — continues until every step is closed (or a halt
 condition fires).
 
+**This invocation IS the grant** (ADR-237). It authorises every
+machine-executable, repository-scoped action needed to deliver the finished
+PR — branches, chunked commits, pushing that branch, opening and updating the
+PR, reversible repository/branch settings, CI runs and re-runs, merge-base
+updates and conflict resolution, and any tool / CLI / API / model / council the
+work needs within the spend ceiling. **The final PR is the interaction
+boundary: report once, at the end.**
+
 ## Instructions
 
 Run the canonical loop in
@@ -46,15 +54,16 @@ with the **scope delta below**.
 - **Working set:** every open step across every phase, in document
   order. Phase-internal annotations like `(deferred)` / `(optional)` /
   "gated on Phase N" do not narrow the working set.
-- **Stop after:** the entire roadmap reaches `count_open == 0`
-  (`complete`), or the runnable set is empty with steps still open
-  (`blocked` — see the terminal-outcomes section below), or a halt
-  condition fires (Hard-Floor, council-off + ambiguity — the latter only
-  outside an accepted contract with council available,
-  security-sensitive, scope-out-of-roadmap, test/quality red).
-- **Do not start** when NO open step is runnable: that is
-  `blocked-preflight`, and it creates no branch and takes no grant. The
-  runnable test is § 3c of the loop.
+- **Stop after:** the entire roadmap reaches `count_open == 0` and the PR is
+  open (`complete`), or every remaining open step is **externally impossible**
+  for the agent (`blocked` — narrowed by ADR-237 § 4 to genuine external
+  impossibility), or a halt condition fires (Hard-Floor EXCLUDED-list action,
+  security-sensitive, scope-out-of-roadmap, test/quality red past N=3).
+- **Always start.** `blocked-preflight` was **removed by ADR-237**: a run no
+  longer refuses because its open steps look human-gated. Repository-local
+  prerequisites are remediation work — do them. The § 3c test now asks whether
+  an action is *technically possible for the agent*, not who conventionally
+  performs it.
 - **Phase boundary handling:** at every phase boundary, run the
   per-phase quality pipeline when `quality_cadence: per_phase` (or
   `per_step`) AND `quality.local_auto_run: true` — under the default
@@ -71,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
+`src/config/estate-count-budget.json` — 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
 
 ```
@@ -78,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)).
@@ -88,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:
@@ -98,8 +255,21 @@ FORBIDDEN NON-HALT REASONS — NEVER STOP THE RUN FOR ANY OF THESE:
   · "phase-checkpoints mode, so I'll checkpoint and wait"
   · "this step looks human-gated" — `blocked` is reached by the § 3c
     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" — 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.
 INVENTING A HALT REASON IS A VIOLATION OF THE COMMAND AND THE USER'S WILL.
+CAPABILITY BEFORE ROLE: IF THE AGENT CAN DO IT AND THE INVOCATION GRANTS IT,
+DOING IT IS THE ONLY CONFORM ACTION.
 IF CONTEXT RUNS OUT MID-RUN, KEEP LANDING COMPLETE STEPS UNTIL IT DOES —
 NEVER ANNOUNCE A BOUNDARY-STOP BY CHOICE.
 ```
@@ -117,40 +287,103 @@ roadmap carries such phrasing — whether by legacy or by an opt-in
 setting — treat it as ordinary prose during execution, never as a
 gate. Phase ordering and explicit dependency gates govern the loop.
 
-## Terminal outcomes — and why `blocked` is not a sixth halt
+## Terminal outcomes — `complete`, or a genuine external impossibility
 
-The five halt conditions answer *"what interrupts runnable work"*. They never
-answered *"what does the run report when no runnable work is left and the roadmap
-is not finished"*, and the omission was not academic: measured 2026-08-19 across
-the twelve most nearly complete roadmaps in the estate, **zero** could reach
-`count_open == 0` in one PR — every remaining open step needed a human action, a
-repo-admin setting, a paid authorisation, an absent binary, or an elapsed soak
-window. Under the contract as written, such a roadmap had no legal stopping point,
-so the command could be neither obeyed nor honestly declined.
+**Rewritten by [ADR-237](../../../../docs/decisions/ADR-237-end-to-end-execution-authority.md),
+which supersedes ADR-235.** The prior version measured twelve nearly-complete
+roadmaps and found that **zero** could reach `count_open == 0` in one PR, because
+every remaining step needed "a human action". That census was sound; the reading
+of it was not. It counted actions a human *conventionally* performs without
+asking, per action, whether a human was **necessary**. Most of that list — flip a
+branch setting, push, open a PR, re-run CI, update a merge base, fix a failing
+test, authorise spend inside a budget — is machine-executable by the agent, and
+is therefore remediation work rather than a blocker.
 
 | Outcome | When | Success? |
 |---|---|---|
-| `complete` | `count_open == 0` | yes — archival check runs |
-| `blocked` | `count_open > 0` and no open step is runnable per § 3c | **no** — partial progress, labelled as such |
-| `blocked-preflight` | no open step was runnable before the run started | **no** — nothing was attempted; no branch |
+| `complete` | `count_open == 0` and the PR is open | yes — archival check runs |
+| `blocked` | every remaining open step is **externally impossible** for the agent | **no** — partial progress, labelled as such |
 | a halt | one of the five conditions fired | **no** — the halt is reported |
 
+`blocked-preflight` no longer exists. A run always starts.
+
+**What counts as externally impossible** — the whole list:
+
+- a required credential does not exist and the agent cannot create it;
+- a purchase beyond the delegated budget (see § Spend below);
+- physical access to hardware;
+- another person or organisation must act;
+- a wait that is factually mandatory and cannot be simulated or verified.
+
+**What does NOT** — every one of these is work:
+
+an unprotected branch · a branch to create · a PR to open · a repository or
+branch setting the agent can change · a workflow to start · CI to re-run · a
+merge base to update · conflicts · failing tests · local configuration · a paid
+call under the ceiling · "this could be risky" · "a maintainer should do this".
+
 ```
 `blocked` IS NEVER REPORTED AS COMPLETION. count_open STAYS > 0.
 NEVER FLIP A BOX TO [~] TO REACH IT — THAT LAUNDERS OPEN WORK THROUGH A GLYPH.
 A PR OPENED ON A BLOCKED RUN SAYS PARTIAL PROGRESS IN ITS FIRST LINE.
-REVALIDATE THE RUNNABLE SET BEFORE REPORTING IT. ONE RUNNABLE STEP REJECTS THE CLAIM.
+BEFORE REPORTING blocked, ASK PER STEP: CAN I DO THIS AT ALL?
+ONE STEP THE AGENT COULD HAVE EXECUTED REJECTS THE CLAIM.
+```
+
+**It is a terminal outcome, not a halt, and the separation still matters.** The
+Iron Law above and its forbidden list keep their full authority over mid-run
+stopping: an agent that may not stop for "this phase is large" may equally not
+stop for "this step looks human-gated" — and under ADR-237 that phrase is no
+longer even a candidate, because the test is capability, not convention.
+
+## Final-PR-only — the UX invariant
+
 ```
+THE RUN REPORTS ONCE, AT THE END. THE FINAL PR IS THE INTERACTION BOUNDARY.
+INTERNAL REMEDIATION IS WORK, NEVER A USER MESSAGE.
+NEVER INTERRUPT THE OWNER MID-RUN FOR A DECISION THE INVOCATION ALREADY DELEGATED.
+```
+
+A missing setting, a CI re-run, a protection flag, a rebase, a council call: do
+them, and say so in the PR body if it matters. The only mid-run interruptions
+that remain legitimate are a spend-ceiling crossing and an EXCLUDED-list action
+(production trunk, deploy, prod data/infra, an irreversible external action
+beyond the PR).
+
+Report shape:
 
-**It is a terminal outcome, not a halt, and the distinction is the safety
-property.** The Iron Law above and its forbidden list hold their full authority
-over mid-run stopping: an agent that may not stop for "this phase is large" may
-equally not stop for "this step looks human-gated". Runnability is decided by the
-§ 3c test over blockers that **pre-date the run** — a citation the run wrote
-itself buys nothing. AI council 2026-08-19, 2/2 convergent on exactly this
-separation.
+```
+PR #<n>
+<url>
+
+Roadmap fully implemented. CI <passed>/<total>.
+```
+
+or, in the genuine exception:
+
+```
+Unable to produce the final PR.
+Hard external blocker: <specific reason>
+Attempted: <what was tried>
+```
+
+## Spend — USD 25 per run, pre-authorised
+
+```
+cost_so_far + reasonably_expected_remaining  ≤  $25  → RUN IT, ASK NOTHING
+cost_so_far + reasonably_expected_remaining  >  $25  → OWNER APPROVAL BEFORE CROSSING
+COST UNKNOWN → CONSERVATIVE ESTIMATE. UNCERTAINTY IS NOT A REASON TO ASK.
+SERVICE-ENFORCED LIMITS MAKE >$25 IMPOSSIBLE → AUTHORISED.
+EXISTING SUBSCRIPTION → MARGINAL COST $0, NOT COUNTED.
+NEVER SPLIT SPEND ACROSS SERVICES, SUBAGENTS, COUNCIL ROUNDS OR CALLS
+TO KEEP EACH ITEM UNDER THE CEILING. THE CEILING IS CUMULATIVE, PER RUN.
+```
 
-Recorded in [`ADR-235`](../../../../docs/decisions/ADR-235-process-full-blocked-terminal-outcome.md).
+The transport is not a governance boundary: a council invocation is the same
+authorised action whether it runs through the `council` CLI or a direct API call.
+There is deliberately **no allowlist** of blessed services — the general rule
+(machine-executable · in scope · under the ceiling) already contains every case,
+and an allowlist would rot.
 
 ## Iron Law — Real-time dashboard
 
@@ -181,6 +414,11 @@ step 5.
 - **Phase quality pipeline runs at every phase boundary** when cadence
   is `per_phase` or `per_step`. `end_of_roadmap` skips per-phase and
   runs only at the final archival check.
+- **No mid-run approval requests.** The invocation delegated them. Only a
+  spend-ceiling crossing or an EXCLUDED-list action reaches the owner.
+- **No `Class: 3` on an agent-executable action.** Capability before role
+  (ADR-237 § 2). A blocker labelled human-only that the agent could have run is
+  a defect in the roadmap, and the run fixes the label rather than obeying it.
 - All other rules from
   [`process-phase § Rules`](process-phase.md#rules) apply unchanged.
 
@@ -190,3 +428,5 @@ step 5.
 - [`/roadmap:process-step`](process-step.md) — single-step variant
 - [`/roadmap:process-phase`](process-phase.md) — default scope, single phase
 - [`roadmap-process-loop`](../../contexts/execution/roadmap-process-loop.md) — canonical mechanics
+- [`ADR-237`](../../../../docs/decisions/ADR-237-end-to-end-execution-authority.md) — the end-to-end delegation contract this command implements
+- [`ADR-235`](../../../../docs/decisions/ADR-235-process-full-blocked-terminal-outcome.md) — superseded; kept for the census and the `[~]`-prohibition argument

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,