@sabaiway/agent-workflow-engine 4.2.0 → 4.4.0

package/CHANGELOG.md

@@ -4,6 +4,37 @@ All notable changes to the methodology engine. Versions are this **package's** n
 they are distinct from the **deployment-lineage** stamp written into a project's `docs/ai/`
 (which tracks the shared `agent-workflow` lineage, head `3.0.0`).
 
+## 4.4.0 — the plan cap counts rows, the readers sweep opens self-review, the consult order and the round render are canon (AD-125)
+
+`references/planning.md`: the cap is 100 lines AND ≤25 ledger rows, 200 UTF-8 bytes per row counted
+without the path and anchor fields (the 8000-byte cap is deleted); an extension phase rides only
+before Cleanup; the two checker commands (`plan-shape-cli.mjs --check` before the first review,
+`--verify` at Cleanup) are named at the point of use. `references/procedures.md`: `plan-authoring`
+carries `Slots: author, fold, review`; step 3 opens with the readers sweep (one literal search per
+changed key, symbol, receipt field or canon sentence — every reader becomes a row, a non-goal or a
+pinned "unchanged"); step 5 of BOTH activities carries the consult-before-fold order (ASK the review
+member that raised the finding, WAIT, READ, fold only as accepted or corrected; a self-review finding
+folds directly); plan-authoring's step 5 additionally names the round render as the source of the
+per-round emission's verdict half — the crossover stop is a computed signal, the origin tally the
+orchestrator's judgment. The canon tests
+pin every sentence (spec `plan-review-loop` S13, S18); the procedures-to-planning size pin is a 1.2
+ratio, declared.
+
+## 4.3.0 — the fifth recipe, the third activity, and a carrier that is never the one who commits (AD-124)
+
+`references/orchestration.md` admits the CARRIER wherever it said backend: the orchestrator, a bridge
+backend, or a full-tool frontier subagent dispatched from the placed executor vehicle; §2 lists
+**Subagent** as the fifth recipe (a bounded, file-disjoint slice; degrades to Solo when the vehicle is
+missing or unusable); §5 states the honest limit (a Claude Code lane — readiness is the vehicle FILE,
+never the host; it spends no bridge quota but the host model's); §6 now reads "no recipe lets a
+carrier commit or perform a git write … the orchestrator alone stages and commits".
+`references/procedures.md`: `Slots: author, review` (the author carrier drafts from the orchestrator's
+brief), the Subagent branch beside Delegated, and a new `## routine` activity (`Slots: carrier,
+parallel`; a read-only slice rides a placed read-only vehicle, a write-capable one the executor; a
+read-only chore has no commit boundary). Both injected pointer fragments name the fifth recipe and the
+third activity; the prior texts are appended to the kit's known-prior stores, so a deployed slot
+refreshes on the next reconcile.
+
 ## 4.2.0 — a zero governing-spec citation names the adoption state it relies on (AD-123)
 
 `references/agent-rules-lens.md`'s **Spec-first** bullet, `references/planning.md`'s *Goal and boundary*

package/README.md

@@ -4,7 +4,7 @@
 methodology *text* — the capped plan shape (goal and boundary, module ledger, verification), the plan-file lifecycle
 (`docs/plans/*.md`, ephemeral, never committed), the `queue.md` series index, the mandatory
 final **Phase: Cleanup**, the **orchestration-recipe** vocabulary (Solo / Reviewed / Council /
-Delegated), the bounded slot fragments the family kit injects into a deployed project's
+Delegated / Subagent), the bounded slot fragments the family kit injects into a deployed project's
 `AGENTS.md`, and the canonical agent-rules lens block the kit renders into a deployed
 `docs/ai/agent_rules.md`.
 
@@ -52,8 +52,9 @@ the canonical methodology reference on disk:
   methodology fragment the composition root injects into a deployed `AGENTS.md` (a short summary +
   pointer, kept under the entry point's line cap).
 - [`references/orchestration.md`](references/orchestration.md) — the canonical **orchestration-recipe**
-  reference: the four recipes (Solo / Reviewed / Council / Delegated) over the bridges' role
-  vocabulary, the when/why, the graceful-degradation lattice, and the quota/health guard.
+  reference: the five recipes (Solo / Reviewed / Council / Delegated / Subagent) over the bridges'
+  role vocabulary and the executor vehicle's `carry` role, the when/why, the graceful-degradation
+  lattice, and the quota/health guard.
 - [`references/orchestration-slot.md`](references/orchestration-slot.md) — the **bounded** one-line
   orchestration fragment the composition root injects into a deployed `AGENTS.md`, routing to the
   in-project recipes surface.
@@ -62,7 +63,7 @@ the canonical methodology reference on disk:
   for `docs/ai/autonomy.json` (read at session start; the canonical default floor when absent; STOP
   on malformed), routing to the in-project `set-autonomy` / `autonomy-doctor` surfaces.
 - [`references/procedures.md`](references/procedures.md) — the canonical **activity-procedures** canon:
-  the named activities (`plan-authoring`, `plan-execution`) as ordered steps with typed recipe slots,
+  the named activities (`plan-authoring`, `plan-execution`, `routine`) as ordered steps with typed recipe slots,
   read live and rendered by the read-only `/agent-workflow-kit procedures <activity>`.
 - [`references/agent-rules-lens.md`](references/agent-rules-lens.md) — the canonical **agent-rules
   lens** block (the planning/review/process-fidelity invariants) the kit renders into a deployed

package/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: agent-workflow-engine
-description: Canonical home of the agent-workflow planning methodology — the capped plan shape (goal and boundary, module ledger, verification), plan lifecycle, queue.md series index, mandatory Cleanup phase, the feature-spec canon (the durable per-feature contract layer with its frozen schema and Out-of-scope discipline), the bounded methodology slot fragment, the orchestration-recipe vocabulary (Solo / Reviewed / Council / Delegated), and the activity-procedures canon (plan-authoring / plan-execution, with typed recipe slots). A published, installable npm package (available:true) that *provides* the methodology text; it mutates nothing. The composition root (agent-workflow-kit) reads this canon LIVE from the installed engine and injects the bounded slots from it — one source of truth, no bundled mirror; `npx @sabaiway/agent-workflow-kit@latest init` installs the engine.
+description: Canonical home of the agent-workflow planning methodology — the capped plan shape (goal and boundary, module ledger, verification), plan lifecycle, queue.md series index, mandatory Cleanup phase, the feature-spec canon (the durable per-feature contract layer with its frozen schema and Out-of-scope discipline), the bounded methodology slot fragment, the orchestration-recipe vocabulary (Solo / Reviewed / Council / Delegated / Subagent), and the activity-procedures canon (plan-authoring / plan-execution / routine, with typed recipe slots). A published, installable npm package (available:true) that *provides* the methodology text; it mutates nothing. The composition root (agent-workflow-kit) reads this canon LIVE from the installed engine and injects the bounded slots from it — one source of truth, no bundled mirror; `npx @sabaiway/agent-workflow-kit@latest init` installs the engine.
 disable-model-invocation: true
 metadata:
-  version: '4.2.0'
+  version: '4.4.0'
 ---
 
 # agent-workflow-engine
@@ -34,13 +34,13 @@ slot fill is needed but the engine is absent, the kit's reconcile **fails loudly
   `<!-- workflow:methodology:start -->` / `<!-- workflow:methodology:end -->` markers. A short
   summary + pointer, not the full reference, so the entry point stays under its line cap.
 - [`references/orchestration.md`](references/orchestration.md) — the canonical **orchestration-recipe**
-  reference: the four recipes (Solo / Reviewed / Council / Delegated) defined over the bridges' role
-  vocabulary, the when/why decision guidance, the graceful-degradation lattice, and the quota/health
-  guard. The kit owns the executable dispatch and surfaces it as `/agent-workflow-kit recipes`.
+  reference: the five recipes (Solo / Reviewed / Council / Delegated / Subagent) defined over the
+  bridges' role vocabulary and the executor vehicle's `carry` role, the when/why decision guidance,
+  the graceful-degradation lattice, and the quota/health guard. The kit owns the executable dispatch and surfaces it as `/agent-workflow-kit recipes`.
 - [`references/orchestration-slot.md`](references/orchestration-slot.md) — the **bounded** one-line
   orchestration fragment the composition root injects into a deployed `AGENTS.md`, between the
   `<!-- workflow:orchestration:start -->` / `<!-- workflow:orchestration:end -->` markers. It names the
-  four recipes and routes to `/agent-workflow-kit recipes`, never to this engine-internal reference.
+  five recipes and routes to `/agent-workflow-kit recipes`, never to this engine-internal reference.
 - [`references/autonomy-slot.md`](references/autonomy-slot.md) — the **bounded** one-line autonomy
   fragment the composition root injects into a deployed `AGENTS.md`, between the
   `<!-- workflow:autonomy:start -->` / `<!-- workflow:autonomy:end -->` markers. It carries the
@@ -50,7 +50,7 @@ slot fill is needed but the engine is absent, the kit's reconcile **fails loudly
   sandbox + the orchestrator). It routes to the kit's `set-autonomy` / `autonomy-doctor` surfaces,
   never to any engine-internal reference.
 - [`references/procedures.md`](references/procedures.md) — the canonical **activity-procedures** canon:
-  the ordered steps of the named activities (`plan-authoring`, `plan-execution`) with **typed recipe
+  the ordered steps of the named activities (`plan-authoring`, `plan-execution`, `routine`) with **typed recipe
   slots** that bind to the orchestration recipes, composing with `planning.md` without restating it. It
   stays generic (no project-specific stages baked in). The kit reads it live and renders the steps +
   the resolved effective recipe per slot via the read-only `/agent-workflow-kit procedures <activity>`.

package/capability.json

@@ -3,7 +3,7 @@
   "schema": 1,
   "name": "agent-workflow-engine",
   "kind": "methodology-engine",
-  "version": "4.2.0",
+  "version": "4.4.0",
   "available": true,
   "provides": ["plan"],
   "roles": {},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sabaiway/agent-workflow-engine",
-  "version": "4.2.0",
+  "version": "4.4.0",
   "description": "Canonical home of the agent-workflow planning methodology — the capped plan shape (goal and boundary, module ledger, verification), plan lifecycle, queue.md series index, and mandatory Cleanup phase, consumed by the kit (composition root). The methodology engine of the agent-workflow family.",
   "keywords": [
     "ai-agents",

package/references/methodology-slot.md

@@ -1 +1 @@
-> **Workflow methodology** — plan → execute → review. Plans are ephemeral `docs/plans/*.md` (gitignored, **never committed**); every Plan ends with a mandatory **Phase: Cleanup**; series order lives in `docs/plans/queue.md`. The plan shape, its caps and lifecycle live in the project's **planning skill** (it overrides the generic `writing-plans`); summary in `docs/ai/agent_rules.md` §5. Named activities (plan-authoring, plan-execution) have procedures — see `/agent-workflow-kit procedures <activity>` for the steps + resolved recipe. **Communication:** user-facing messages deliver the artifact inline (paste the prompt / diff / command — never "see §X" as a substitute), lead with the result, show exactly what was asked, and never read as mockery (a large artifact: a real summary inline + a link).
+> **Workflow methodology** — plan → execute → review. Plans are ephemeral `docs/plans/*.md` (gitignored, **never committed**); every Plan ends with a mandatory **Phase: Cleanup**; series order lives in `docs/plans/queue.md`. The plan shape, its caps and lifecycle live in the project's **planning skill** (it overrides the generic `writing-plans`); summary in `docs/ai/agent_rules.md` §5. Named activities (plan-authoring, plan-execution, routine) have procedures — see `/agent-workflow-kit procedures <activity>` for the steps + resolved recipe. **Communication:** user-facing messages deliver the artifact inline (paste the prompt / diff / command — never "see §X" as a substitute), lead with the result, show exactly what was asked, and never read as mockery (a large artifact: a real summary inline + a link).

package/references/orchestration-slot.md

@@ -1 +1 @@
-> **Orchestration recipes** — compose plan → execute → review with a named recipe: **Solo** (no backend), **Reviewed** (one backend reviews), **Council** (both review, you synthesize), **Delegated** (a backend executes a bounded sub-task); the orchestrator always commits, a backend is never autonomous. Pick + plan one for this environment with `/agent-workflow-kit recipes` (read-only); the deployed how/why lives in your `docs/ai/` workflow docs. At the start of a planning/execution session, read your standing recipe preference in `docs/ai/orchestration.json` — set it in plain language with `/agent-workflow-kit set-recipe` (previews first; hand-edit stays supported).
+> **Orchestration recipes** — compose plan → execute → review with a named recipe: **Solo** (no backend), **Reviewed** (one backend reviews), **Council** (both review, you synthesize), **Delegated** (a backend executes a bounded sub-task), **Subagent** (a full-tool frontier subagent carries a bounded slice); the orchestrator always commits, a carrier is never autonomous. Pick + plan one for this environment with `/agent-workflow-kit recipes` (read-only); the deployed how/why lives in your `docs/ai/` workflow docs. At the start of a planning/execution session, read your standing recipe preference in `docs/ai/orchestration.json` — set it in plain language with `/agent-workflow-kit set-recipe` (previews first; hand-edit stays supported).

package/references/orchestration.md

@@ -1,9 +1,10 @@
 # Orchestration Recipes
 
-Canonical, on-demand reference for **how an orchestrating agent composes the optional
-execution-backends** (the family's subscription-CLI bridges) into the `plan → execute → review`
+Canonical, on-demand reference for **how an orchestrating agent composes the carriers of a step** —
+itself, the optional execution-backends (the family's subscription-CLI bridges) and a full-tool
+frontier subagent — into the `plan → execute → review`
 flow. This is the *narrative* source of truth — the **vocabulary** (what each recipe is), the
-**when/why** (which to reach for), the **graceful-degradation lattice** (what happens when a backend
+**when/why** (which to reach for), the **graceful-degradation lattice** (what happens when a carrier
 is unavailable), and the **quota/health guard**. The kit (`agent-workflow-kit`) owns the *executable*
 dispatch (`tools/recipes.mjs` — `planRecipe` / `recommendRecipe`) and surfaces it read-only as
 `/agent-workflow-kit recipes`; the two representations are kept in lockstep by a recipe-name parity
@@ -13,9 +14,12 @@ guard. For the plan lifecycle this composes with, see [`planning.md`](planning.m
 
 ## 1. The role vocabulary recipes are built over
 
-A recipe is an **orchestration pattern**, not a runnable script. The **orchestrator** (the main
-agent) always owns the decisions, the edits it accepts, verification, and the **single commit** — a
-backend is **advisory or delegated, never autonomous, and never commits**.
+A recipe is an **orchestration pattern**, not a runnable script. It names **who carries a step** —
+the **orchestrator** itself (Solo), a **bridge backend** (Reviewed / Council / Delegated), or a
+**full-tool frontier subagent** dispatched from the placed executor vehicle (Subagent). The
+orchestrator (the main agent) always owns the decisions, the edits it accepts, verification, and the
+**single commit** — every other carrier is **advisory or delegated, never autonomous, and never
+commits**.
 
 Each backend declares what it can do in its `capability.json` `provides` / `roles`:
 
@@ -27,14 +31,26 @@ Each backend declares what it can do in its `capability.json` `provides` / `role
 
 Both are **subscription** backends with a **finite quota** — spend deliberately.
 
-## 2. The four recipes
+The third carrier is neither: the **executor vehicle** — a full-tool frontier subagent the
+orchestrator dispatches from the placed `.claude/agents/executor.md`. It declares no
+`capability.json` and spends no bridge quota (it runs on the host's own model and consumes that
+model's quota and cost); it carries the `carry` role only — never
+`review`, never `probe` — and its availability is the vehicle FILE, not a detector (§4, §5).
 
-| Recipe (id) | Pattern | Roles needed | Backends that satisfy it |
+## 2. The five recipes
+
+| Recipe (id) | Pattern | Roles needed | Carriers that satisfy it |
 |-------------|---------|--------------|--------------------------|
 | **Solo** (`solo`) | The orchestrator plans, executes, and self-reviews. No backend. | none | — (always available; the floor) |
 | **Reviewed** (`reviewed`) | The orchestrator executes; **one** backend reviews the result (advisory). | ≥1 backend providing `review` | `codex` and/or `agy` |
 | **Council** (`council`) | **Both** backends review independently; the orchestrator synthesizes the two opinions. | ≥2 backends providing `review` | `codex` **and** `agy` |
 | **Delegated** (`delegated`) | The orchestrator hands a **bounded** execution sub-task to a backend, then reviews the returned diff and commits. | ≥1 backend providing `execute` | `codex` only |
+| **Subagent** (`subagent`) | The orchestrator hands a **bounded, file-disjoint** slice — of execution, of plan/contract authoring, or of routine work — to a **full-tool frontier subagent**, then verifies the returned slice by running its suites. A routine slice is classified first: a read-only one rides a placed read-only vehicle (or is carried Solo with a stated reason when that vehicle is absent); a write-capable one rides the executor. | the `carry` role | the placed executor vehicle |
+
+The orchestrator keeps the folds, the gates, the release documents, the asks and the **one commit**
+whatever the recipe resolves to. A subagent is **never a review backend**, **never a bridge
+substitute**, and is **never told to commit**; it **degrades to Solo** when the executor vehicle is
+missing or unusable.
 
 ## 3. When / why to reach for each (the decision vocabulary)
 
@@ -51,6 +67,12 @@ Both are **subscription** backends with a **finite quota** — spend deliberatel
 - **Delegated** — when a bounded, well-specified sub-task can be handed off (parallelism, or to keep
   the orchestrator's own context focused). Only `codex` provides `execute`. The orchestrator still
   reviews the returned diff and owns the commit — delegation never bypasses the review or the gate.
+- **Subagent** — when the work is **bounded and file-disjoint** and the orchestrator's own context is
+  the scarce resource: execution slices, a plan or a contract drafted from a brief the orchestrator
+  writes, or routine chores (gate triage, sweeps, doc regeneration, fixture builds). It spends no
+  bridge quota; it runs on the host's own model and consumes that model's quota and cost. The orchestrator still writes the brief, verifies every returned slice by running
+  its suites itself, and owns the commit — a subagent never stands in for the bridge a `review`
+  recipe names.
 
 ## 4. Graceful degradation (never silent)
 
@@ -61,6 +83,12 @@ Availability is **pure file-presence**: a backend is dispatchable **iff its dete
 the wrapper is not on `PATH`). This is a claim about **set-up state only** — never about whether a
 backend's *service* is actually responsive.
 
+The subagent carrier makes the same kind of claim from a different file: its availability is the
+**executor vehicle** at `.claude/agents/executor.md` — `placed` or `customized` is dispatchable,
+`unusable` or `missing` is not, and the state is the human reason (the writer's apply command
+places a missing vehicle; a customized file is kept; an unusable path must be fixed or removed
+first, then placed). Never a claim about the host that would run it (§5).
+
 When a recipe's roles can't be satisfied, it **degrades to a weaker recipe with a stated reason** —
 always reported, never silently dropped:
 
@@ -68,6 +96,7 @@ always reported, never silently dropped:
   neither is `ready` → Solo.
 - **Delegated → Solo.** No backend provides `execute` and is `ready` → Solo, with the reason.
 - **Reviewed → Solo.** No backend provides `review` and is `ready` → Solo, with the reason.
+- **Subagent → Solo.** The executor vehicle is `missing` or `unusable` → Solo, with the reason.
 
 **Recipe fidelity — the converse: every ready backend, every round.** Degradation is the *only*
 licence to run fewer backends than the recipe names. When the resolved recipe is `council` and BOTH
@@ -152,6 +181,11 @@ task that genuinely needs to run or write keeps a full-tool subagent. **Honest l
 no deterministic gate classifies a dispatch — enforcement is this canon at the point of use,
 the placed vehicles, and the retro loop.
 
+**The Subagent carrier is a Claude Code lane**, exactly like the placed vehicles above: its
+readiness is the vehicle FILE, never the host. On a host that cannot dispatch the vehicle, the
+rendered dispatch form is an **instruction the orchestrator follows by hand** and reports as such —
+never reported as a subagent dispatch.
+
 **Sandbox lanes.** Under an OS sandbox the lanes split once more by **surface class**: the L0
 surfaces are **sandbox-safe** (gate/state/coverage checks, git reads, plain no-network tests);
 the bridge wrappers are **genuinely unsandboxed** (they need network); npm-cache-touching commands
@@ -184,10 +218,13 @@ stays read-only.
 
 ## 6. The orchestrator always commits
 
-No recipe makes a backend write to the repo or create a commit. The kit's `recipes` surface is
+No recipe lets a carrier commit or perform a git write: a review backend reads and returns findings;
+a delegated backend edits inside its own sandbox and returns a diff the orchestrator reviews; a
+subagent edits only the files its brief names — and the orchestrator alone stages and commits. The kit's `recipes` surface is
 **read-only** — it lists the recipes, plans one for the current environment, and recommends a
 default; it **never executes** a recipe and **never runs a subscription CLI**. The orchestrator
-executes the chosen recipe through the bridge skills, accepts or rejects every edit, runs the
+executes the chosen recipe through the bridge skills or the executor vehicle, accepts or rejects
+every returned edit, runs the
 verification gate, and makes the **one** commit — exactly as the plan lifecycle (`planning.md`)
 requires.
 

package/references/planning.md

@@ -8,8 +8,9 @@ plan tells it which files to open, what each one may become, and how the result
 
 ## Shape
 
-The whole file is capped at **100 lines and 8000 bytes** — both, because a line cap alone is paid off
-with longer lines. The headings are LITERAL, copied bare: tooling extracts sections by exact match.
+The whole file is capped at **100 lines and at most 25 ledger rows**. Before its first review and
+after every authoring fold, run `node <kit>/tools/plan-shape-cli.mjs --check <plan>`. The headings are
+LITERAL, copied bare: tooling extracts sections by exact match.
 
 ```
 # Plan: <title>
@@ -20,6 +21,9 @@ with longer lines. The headings are LITERAL, copied bare: tooling extracts secti
 ## Next steps
 ```
 
+A project-declared `## Phase: <name>` may ride between Verification and Cleanup; it is bounded by
+the whole-file line cap and may not reuse the Cleanup name.
+
 A plan that does not fit is not under-described. Either the TASK is too big — split it along
 independently verifiable boundaries, never by document size — or it is a SWEEP (below).
 
@@ -34,7 +38,8 @@ independently verifiable boundaries, never by document size — or it is a SWEEP
 
 ## Module ledger
 
-One row per path, ≤200 bytes per row, six fields:
+One row per path, six fields. A row is capped at **200 UTF-8 bytes counted without its path and
+anchor**: id, verb, responsibility and budget after trimming, including their three ` | ` separators.
 
 ```
 <check-id> | create|modify|delete | <path> | <responsibility, one sentence> | <max lines | n/a> | <anchor>
@@ -71,9 +76,9 @@ the sweep, and breaks the intermediate states.
 ## Verification
 
 Exact existing commands plus the acceptance check for the goal. The ledger is validated by ONE
-command over its `check-id`s — existence and budget for create/modify, absence for delete, the count
-for a sweep, and the total line. Per-row assertions in prose are the repetition this section exists
-to avoid.
+command: `node <kit>/tools/plan-shape-cli.mjs --verify <plan>` — existence and budget for
+create/modify, absence for delete, the count for a sweep, and the total line. Per-row assertions in
+prose are the repetition this section exists to avoid.
 
 **The acceptance criteria ARE the `- ` bullets.** Every top-level `- ` bullet in this section is one
 acceptance criterion, and they are the whole list — nothing outside a bullet is one. That makes the

package/references/procedures.md

@@ -2,15 +2,16 @@
 
 The ordered steps of each named activity, with **typed recipe slots** bound to the
 [orchestration recipes](orchestration.md). It composes with — never restates —
-[`planning.md`](planning.md), naming that canon's sections by *heading*. The kit reads this file
-LIVE and parses ONLY each section's `Slots:` line, never the steps.
+[`planning.md`](planning.md), naming its sections by *heading*. The kit reads this file
+live and parses only each section's `Slots:` line.
 
 A **recipe slot**: `review` accepts `solo | reviewed | council`; `execute` accepts
-`solo | delegated`. The per-project default lives in `docs/ai/orchestration.json`, resolved against
-backend readiness by the kit.
+`solo | delegated | subagent`; a carrier slot (`author`, `fold`, `carrier`) accepts `solo | subagent`;
+`parallel` is a switch (`on | off`), not a recipe. The per-project default lives in
+`docs/ai/orchestration.json`.
 
-**When an activity has a commit boundary, the orchestrator owns that commit; a backend is advisory
-or delegated, never autonomous, and never commits** (`orchestration.md` §6). `plan-authoring` ends
+**When an activity has a commit boundary, the orchestrator owns that commit; every other carrier is
+advisory or delegated, never autonomous, and never commits** (`orchestration.md` §6). `plan-authoring` ends
 at **approval** with no commit (plans are ephemeral, never committed); `plan-execution` commits per
 ledger row.
 
@@ -29,36 +30,53 @@ inline plus the link.
 
 ## plan-authoring
 
-Slots: review
+Slots: author, fold, review
 
 1. **Research** — the exact files, contracts and constraints touched.
 2. **Draft** — write to the shape [`planning.md`](planning.md) fixes; its *Module ledger* decides
    the layout and every budget before any file exists — a size gate is only the backstop. Name the
    governing spec(s) in *Goal and boundary* ([`specs.md`](specs.md)); a new feature's draft spec is
    a `create` row and a revision of a governed contract a `modify` row, both written here so they
-   exist AT review.
-3. **Self-review** — apply *What gets cut*; fold by code (read and cite the `file:line`); update
-   `queue.md` for a series, to the shape *The queue* fixes.
+   exist AT review. The resolved `author` carrier drafts — Solo: the orchestrator writes it;
+   Subagent: the orchestrator writes a BRIEF (goal, governing specs, ledger
+   constraints, files) and the subagent drafts the plan and any `create` / `modify`
+   spec row from it, and the orchestrator reviews the draft as its own before step 3.
+3. **Self-review** — run the **readers sweep before the first review**: for every config key,
+   registry entry, exported constant, receipt field or canon sentence the plan changes, use one
+   literal repository search to list its readers (validators, renders, seeds, docs and the tests
+   that pin the text). Every reader becomes a ledger row, a stated non-goal, or unchanged with
+   the test or fixture that proves it. Then apply *What gets cut*; fold by code
+   (read and cite the `file:line`); update `queue.md` for a series, to the shape *The queue* fixes.
 4. **review {recipe}** — Solo (self-review only) / Reviewed (one backend) / Council (both; you
    synthesize), as the resolved `review` recipe selects.
-5. **Fold + loop** — fold every finding and re-review; CLEAN is **0 blockers + 0 majors** from every
-   backend the recipe names — folding ≠ convergence. Fold a code-touching finding **test-as-spec**,
-   with **no code-mechanics** in the plan: only **checked syntax** its Verification runs; un-run,
+5. **Fold + loop** — before folding a finding raised by a **review member**, **ASK** that member whether the
+   proposed fold solves it without a new problem; **WAIT**, **READ**, then hand the accepted or
+   corrected fold to the resolved `fold` carrier. Self-review findings, or findings with no review
+   member, are folded directly. Forms: `agy-review --continue --decided @f` for agy, a
+   fresh `codex-review plan <consult-brief>` for
+   codex, or a fresh re-dispatch of the same lens vehicle for a lens member; write the finding and
+   fold before the tree changes. Solo: orchestrator edits. Subagent: the round's findings with their
+   dispositions are the slice; it edits the plan or contract and returns; orchestrator runs the
+   self-consistency read.
+   Fold and re-review every finding; CLEAN is **0 blockers + 0 majors** from each named backend;
+   folding ≠ convergence. Fold code findings **test-as-spec**, with **no code-mechanics** in the
+   plan: only **checked syntax** its Verification runs; un-run,
    **logic-bearing** syntax never enters prose (*Un-run syntax never ships in prose*). Council runs
    every named backend **every round** (recipe fidelity, `orchestration.md` §4). Cap architecture
    review at **≤2 rounds**; **backend divergence** (one ships, one keeps revising mechanics) IS the
-   **crossover** — resolve the surviving major at altitude, never by exhausting the strictest
-   backend; a **self-consistency** read precedes each re-review; an all-mechanics or prose-only
-   artifact takes a thin plan + **diff-review** (*The plan must read cold*). Each round MUST emit
-   **{round N · finding-origin tally · per-backend verdict}**. At the cap, classify each surviving
-   blocker or major: **fixable-bug** (fold ONCE as a red→green test, re-review) /
+   **crossover** — resolve the major at altitude, not by exhausting that backend.
+   A **self-consistency** read precedes each re-review; all-mechanics or prose-only takes a thin plan
+   + **diff-review** (*The plan must read cold*). Each round MUST emit
+   **{round N · finding-origin tally · per-backend verdict}**: READ its verdict half from the round
+   render (`review-rounds`, the kit's table over the review receipts); append the orchestrator's finding-origin tally
+   judgment. At the cap, classify surviving blockers/majors: **fixable-bug** (fold ONCE as a red→green test, re-review) /
    **inherent-layer-residual** (raise to an acceptance criterion) / **escalate**.
 6. **Present for approval** — never execute here: a harness "approved — start coding" prompt
    (**ExitPlanMode**) authorizes the PLAN only; `plan-execution` is a deliberate transition once
    the plan and its cold-start prompt exist.
 
 **Definition of Done:** a plan in `docs/plans/` ending with **Phase: Cleanup** **and** a cold-start
-execution prompt to begin the next session — both produced without the user asking.
+execution prompt to begin the next session — both without the user asking.
 
 ## plan-execution
 
@@ -67,23 +85,36 @@ Slots: execute, review
 Each ledger row is one logical commit.
 
 1. **Resolve the recipe per row** — `execute` and `review` from `docs/ai/orchestration.json` +
-   readiness (`--override <slot>=<recipe>` per run).
+   readiness (`--override <slot>=<value>` per run).
 2. **If `execute` resolved to Delegated, dispatch execution FIRST** — the backend returns a diff
-   (codex-exec) *before* you integrate; otherwise implement directly.
+   (codex-exec) *before* you integrate. **If `execute` resolved to Subagent**, split the ledger into
+   file-disjoint slices, exact wording where wording is a red line, dispatch each slice to
+   the executor vehicle in the background, and verify
+   every returned slice by running its suites yourself before step 3. Otherwise implement directly.
 3. **Implement / integrate** — your own edits or the reviewed delegated diff; a spec row lands its
    approved draft or revision WITH the code ([`specs.md`](specs.md)).
 4. **Self-review** — the change against its [`planning.md`](planning.md) ledger row and the plan's
    Verification, under the project's reuse and clean-code rules; fold by code (cite the
    `file:line`); **characterize-first**: pin uncovered code's behaviour in a green test before
    editing it; fold each finding test-as-spec (red→green); atomic, reversible edits.
-5. **review {recipe}** — the **heavy review at the diff** (*The plan must read cold*): real code and
-   the full suite. The plan-authoring loop applies unchanged — every named backend every round,
-   **0 blockers + 0 majors**, the **{round N · finding-origin tally · per-backend verdict}**
-   emission, **fixable-bug / inherent-layer-residual / escalate** at the cap. Its instruments:
+5. **review {recipe}** — the **heavy review at the diff** (*The plan must read cold*): real code +
+   full suite. Authoring loop applies unchanged: every named backend every round; a finding raised
+   by a **review member**: **ASK**, **WAIT**, **READ**, fold only as accepted or corrected; a
+   self-review finding is folded directly (forms: its step 5). CLEAN:
+   **0 blockers + 0 majors**; the **{round N · finding-origin tally · per-backend verdict}**
+   emission; **fixable-bug / inherent-layer-residual / escalate** at the cap. Its instruments:
    `core-evidence red-proof` declares each bugfix red BEFORE the fix; `core-evidence
    degrade` records an unavailable backend; reviews run on the STAGED tree; `run-gates --final`
    mints the ONE receipt `commit-guard --check` gates the commit against.
 
+   On an **ARMED flow**, a **bridge-raised** finding uses this order: the round is open; dispatch
+   its consult with a nonce; WAIT and READ; accept or correct the fold; run
+   `flow-writer consult-attestation <planId> --backend <id> --nonce <n> --proposed-fix-digest
+   <the-sha256-of-the-fold-text>`; then edit. The attestation records the manifest and fold digest,
+   never the run or answer. A **lens-raised** finding instead re-dispatches the lens without a nonce
+   (WAIT and READ, edit as accepted or corrected); it mints no manifest and no attestation; only its
+   per-round participation rides `internal-attestation`.
+
    **Finding scope** — every finding NAMES the invariant its fix enforces, BEFORE the edit, every
    round. Already an acceptance criterion (*Verification*'s `- ` bullets) → **fold here**. It would
    have to be ADDED → the **narrow fix** for the found site ships now (red first) and ONLY the
@@ -93,8 +124,24 @@ Each ledger row is one logical commit.
    finding counts only if it changes a WRITE/REMOVE decision or is a false statement in shipped
    text; a repeat finding in one subarea routes to SUBTRACTION, not a fourth patch.
 6. **Gates** — the project's verification gate to green.
-7. **Commit boundary** — the orchestrator makes the single commit; a backend never commits; the
+7. **Commit boundary** — the orchestrator makes the single commit; every other carrier never commits; the
    commit-approval policy lives in the project's own rules.
 8. **After the last row** — the project-declared release or extra stages (the `workflow:methodology`
    slot; this canon bakes in none) and then `## Phase: Cleanup` (*Cleanup, and the plan's own
    life*) run as rows of their own, each through steps 1–7.
+
+## routine
+
+Slots: carrier, parallel
+
+1. **Name the chore and its slices** — gate triage, sweeps, regeneration, fixture builds; never
+   the changelog; each slice bounded and file-disjoint.
+2. **Resolve the recipe** — `carrier` and `parallel` from `docs/ai/orchestration.json` + readiness
+   (`--override <slot>=<value>` per run).
+3. **Carry it** — Solo: the orchestrator does it. Subagent classifies each slice: read-only (a
+   sweep, gate triage) rides its placed read-only vehicle, or is carried Solo with a stated reason
+   when that vehicle is absent; write-capable (a regeneration, a fixture build) rides the executor.
+   Dispatch in the background, concurrently when `parallel` is on.
+4. **Verify** — every returned slice, by running its suites yourself.
+5. **The commit boundary is unchanged** — when an accepted slice changed the tree, the orchestrator
+   alone commits; a read-only chore has no commit boundary; a carrier never commits.