immune-brain 5.3.0 → 5.5.1

package/plugins/immune-brain/dist/imm-run.md

@@ -10,7 +10,10 @@ This skill adheres to the **[BASELINE.md](BASELINE.md)**.
 ## Kernel Canary Routing and Authority
 
 Only explicit `imm-run` entry starts or resumes this loop. Ordinary host input
-stays host-native; it never resumes a Managed owner implicitly. While a
+stays host-native; it never creates an execution binding. An already-bound run
+keeps its binding across status questions and in-scope clarification. Explicit
+cancel, planning entry or session replacement releases response continuation;
+Kernel ownership changes only through its own operations. While a
 non-terminal TaskRecord holds the workspace, both Hosts add a read-only notice
 to ordinary input (Pi `before_agent_start`, Claude Code `UserPromptSubmit`)
 naming the task, its next obligation and its scope: before committing or
@@ -18,9 +21,12 @@ modifying files inside that scope, read `status` and tell the user the task is
 active and what it waits for. The notice resumes nothing. Read the current
 Host's `status` projection first and verify the exact active backend claim,
 TaskIntent, and TaskRecord. Invalid or contradictory projections fail closed. A
-candidate TaskIntent is not Enrollment authority.
+candidate TaskIntent is not Enrollment authority. For a Parent Issue, route to
+[Unattended Batch Opt-In](imm-run-batch.md#unattended-batch-opt-in) after this authority
+read. A Child entry verifies prerequisite settlement and integration before its
+single-task native gate; it starts no other Slice.
 
-Enrollment is the first step of an explicit `imm-run` entry and belongs to no
+Enrollment is the first step of a single-task explicit `imm-run` entry and belongs to no
 other Skill. When the entry finds no active claim, resolve the validated
 candidate the user named (or the Planner's recommended first Task when the entry
 names none and exactly one candidate fits), then invoke the current Host's
@@ -31,6 +37,18 @@ candidate and reports its stable reason plus exactly one same-Host recovery
 action; never recommend another Host, worktree, Direct Path, unmanaged
 implementation, or automatic retry.
 
+The Enrollment gate lists every in-scope path that is already staged, modified
+or untracked. Confirming the gate claims exactly the listed paths as task work,
+so a task may start from work the user already began; no clean scope is
+required. An in-scope path that changed after the gate text was built was not
+shown, so it refuses the Enrollment: enroll again to review it. Changes outside
+the scope stay the user's and are never claimed.
+
+`status` is a read, not a freeze. It stays readable while the scope holds
+unstaged or untracked paths and returns them as a `warnings` entry beside the
+projection. Freezing a snapshot still refuses those paths, and an in-scope path
+carrying a skip-worktree or assume-unchanged index flag still refuses both.
+
 Before the first Enrollment of a candidate TaskIntent, confirm the Planner
 returned `tracker_associated` — but only when the candidate belongs to an
 identified GitHub-carried Initiative. Standalone TaskIntents and Local
@@ -70,14 +88,23 @@ read-only boundary remains prompt text; the Pi dispatch rules are unchanged.
 Before a child dispatch, read the [Subagent Dispatch Protocol](docs/reference/subagent-dispatch-protocol.md#authorization-authority).
 Never load an internal role as a public Skill or spawn another loop process;
 the only exception is a Lane's Executor Host under
-[Lane Executor Supervision](#lane-executor-supervision).
+[Lane Executor Supervision](imm-run-batch.md#lane-executor-supervision).
 The standalone `imm-pr-fix`, `imm-doc-prune`, `imm-doc-slim`, and `imm-test-prune`
 are host-native maintenance entries, never dispatched as the Loop role. Internal
 `test-fixer` and `pr-fix` repairs remain bounded by the enrolled TaskIntent.
 
 ## Execution Loop
 
-Continue while the current projection has a valid action:
+Continue while the current projection has a valid action. Pi's response boundary
+and Claude's Stop Hook re-read facts for the active session binding. A valid action
+returns to this Loop; waiting Review/Executor invocations keep their existing call
+identity. Submit a returned verdict before editing; use projected recovery after
+a rejected submission. Only changed task/delivery facts or scoped source bytes
+reset substantive progress. Three unchanged observations stop with one recovery
+action; status, formatting and repeated failed commands do not reset the count.
+Host native-gate failures pause with same-Host recovery and never auto-retry.
+A single Slice ends at its own terminal proof; a Parent uses whole-plan completion
+from the [batch contract](imm-run-batch.md#unattended-batch-opt-in).
 
 1. For active artifacts, implement only the enrolled acceptance within the
    `scope_hint` envelope in the current conversation. New helpers or tests
@@ -87,15 +114,20 @@ Continue while the current projection has a valid action:
    to the user. If a file mixes pre-existing user changes with task changes and
    the task-owned hunks cannot be isolated reliably, stop with that ownership
    conflict instead of staging the whole file. Staging grants no commit or push
-   authority. Complete the [Executor Delivery Evidence](role-prompts/executor.md#delivery-evidence)
-   table before the first Assurance attempt and update affected rows after repair.
+   authority. The runtime commits an Enrollment precondition's committable set
+   itself; never commit those paths by hand and never ask the user to. Complete the [Executor Delivery Evidence](role-prompts/executor.md#delivery-evidence)
+   table for rework only; a first delivery needs no table.
    Executor checks are diagnostic evidence, not a QA or Review approval.
 2. Call `advance_assurance` in the foreground and consume its direct terminal
    result. The Kernel freezes the artifacts itself before QA: it binds Git
    content identity in place without relocating source paths. A simple task has
    TaskIntent only; a complex task may bind one active Spec. Deterministic QA
-   runs all descriptors in a disposable delivery materialization, never against
-   unchecked live worktree source. Do not dispatch a separate per-Step QA Agent.
+   runs all descriptors in the task's working directory. Before the first
+   command and after every command, the tracked content inside the task's scope
+   must equal the frozen snapshot; a difference fails as
+   `protected_input_or_output_drift`. Content outside the scope, and untracked
+   or ignored files, are the user's environment and are not compared. Do not
+   dispatch a separate per-Step QA Agent.
 3. On `review_ready`, invoke the returned `agent_params` as one exact foreground
    Agent call, then pass its structured verdict to `submit_review`. Do not
    replace this snapshot-bound reviewer with a generic role dispatch. The Parent
@@ -135,333 +167,6 @@ suspected external changes. Never repeat a mutation merely to obtain its result.
 Kernel CAS and freshness checks remain mandatory; reducing Parent reads does
 not bypass them. Do not poll or create detached jobs.
 
-## Unattended Batch Opt-In
-
-The only unattended batch entry is the privileged Host tool `start_unattended_batch`
-with its `initiative_slug` parameter. That parameter is the opt-in (lane mode adds an optional `max_parallel`, see [Parallel Batch Opt-In](#parallel-batch-opt-in)): absent the call,
-`imm-run` behavior is byte-identical to per-task Enrollment, and no batch state,
-branch, or Batch Authorization exists. The Standalone Hosts expose the same tool
-name and the same required parameter; it is never a batch of tasks the Host chose.
-When an Initiative is referenced by its tracker Issue (e.g. `github #<number>`),
-extract `initiative_slug` from the Issue body `<!-- immune-brain:initiative-id=<slug> -->`
-marker or title prefix before invoking the tool.
-
-The Initiative's carrier decides where the children are read from. When
-`docs/initiatives/<initiative_slug>.md` exists, the Host reads that Local carrier
-and performs no GitHub operation for the plan; otherwise it reads the GitHub
-Parent Issue's native Sub-issues. A Local carrier yields one child per Slice:
-each `## <slice-id>: <result>` section names exactly one Task under `Tasks:` and
-may add one `Blocked by: <task-id>, <task-id>` line. A Slice that names no Task or
-several, or a dependency outside the Initiative, refuses the plan before any
-confirmation.
-
-Invoking it authorizes only a user-confirmed batch of already-planned child
-TaskIntents. The Host projects the batch plan from the Initiative's published
-children, excludes every `critical` child, renders the ordered child list, budget,
-and plan digest through its native confirmation, and issues one Kernel Batch
-Authorization for that exact plan. The extension mints no capability and owns no
-batch state transition: the shared `startBatch` driver in
-`runtime/unattended/` owns every batch transition, and each child is still
-enrolled, assured, and settled by the Kernel under an ordinary TaskRecord.
-
-A successful child Enrollment returns a `running` report with `handoff.role`
-`executor`; the child remains `enrolled`. The Parent implements that TaskIntent
-in the current foreground conversation, stages only its scoped changes, and
-runs focused diagnostics before Kernel Assurance. Re-entering the batch before
-implementation returns the same handoff without QA or another confirmation.
-The runtime owns no model invocation and adds no persisted execution lifecycle.
-
-After diagnostics pass, the Parent advances Kernel QA and dispatches any reserved
-foreground Review once using the exact returned `agent_params`, then submits its
-structured verdict. An open Review reservation stays with that Host invocation;
-batch re-entry waits for it rather than redispatching. When a batch child's
-foreground terminal mutation reaches Kernel `done`, the same tool call stages
-only that child's generated terminal audit evidence and re-enters the batch under
-the still-valid authorization, opening no gate. The driver reconciles settlement,
-adopts or creates the one scope-bound commit, then enrolls the next ready child
-or settles the batch as `completed`; the result carries the batch report as
-`batch`. A reserved Review, a parked child and a stopped child end where they do
-today and are never committed automatically. If the re-entry fails, the Kernel
-result is unchanged and `batch` carries one recovery action: call
-`start_unattended_batch` with the same slug, which is also how to continue by
-hand. A commit that fast-forwards the batch branch outside the runner is adopted,
-not attributed to a child; any other HEAD movement still fails closed. Ordinary Executor handoff and below-limit
-QA repair do not park the batch; genuine budget/authority stops remain fail-closed.
-
-Batch execution never pushes a ref, opens or updates a pull request, resolves a
-user decision, or creates, switches, or deletes a Git worktree. Its sole Git
-effect is the batch branch `imm/<initiative-slug>` plus one scope-bounded commit
-per completed child.
-
-### Parallel Batch Opt-In
-
-Lane mode is opt-in through the optional `max_parallel` parameter of
-`start_unattended_batch`; absent it, everything above is the whole contract and the
-run stays serial and byte-identical. `max_parallel` is a positive integer; the
-Standalone Hosts expose the same optional `lane_offers` list, each entry naming a
-`task_id` and an absolute `path` of an already existing Git worktree. The runner
-admits an offered Lane only when it shares the coordinator repository, is not the
-coordinator worktree, is on the branch `imm-lane/<initiative-slug>/<task-id>` at the
-named base, is clean and has no active run; otherwise it refuses the offer with a
-stable reason and writes nothing. A call that passes `lane_offers` without
-`max_parallel` resumes the recorded lane batch with its recorded `max_parallel`;
-without a recorded active lane batch it is refused before any gate opens. The runner still never creates, switches or
-deletes a Git worktree: when a child needs a Lane the report carries a
-`lane-steward` handoff and the Lane is provisioned outside the runner.
-
-In a Lane the child is enrolled, assured and settled exactly as in a serial batch.
-The runner then commits the settled delivery on the Lane branch and fast-forwards
-the batch branch only to a candidate whose changed paths and per-path content equal
-that commit; a mismatch or conflict moves nothing and parks the child.
-With `max_parallel` above 1 the reconcile tick keeps up to that many Lanes in
-flight and reports one `provision` or `executor` handoff per child in `handoffs[]`.
-Only children whose scopes are provably disjoint run together; a child whose scope
-overlaps an in-flight Lane waits until that Lane is integrated. Settled children
-integrate serially, and a parked child ends only itself and its dependents while a
-disjoint sibling keeps moving. A lost Lane parks as `batch_lane_lost`, and
-`qa_failure_limit` counts each child separately. A completed settlement inside a
-Lane changes Kernel state only and writes nothing to the tracker: the coordinator
-closes the child's Issue after it integrates that child's commit, exactly once,
-and reports the attempt in `tracker_observations`. A parked or lost child is
-never integrated, so its Issue stays open; an explicit stop inside a Lane still
-projects `not planned` at once.
-
-The lane batch confirmation offers one opt-in choice, off by default: delegate
-to the coordinator the approval of each Lane child's breaking Intent revisions
-that stay inside that child's TaskIntent as authorized for the batch (ADR 0018).
-The answer is recorded on the batch record as `revision_delegation`; a batch
-confirmed without it behaves exactly as before, and the grant ends with that
-batch — a terminal, retired or later batch never uses it. When an integrated
-child's TaskIntent equals the last revision applied under that grant, the runner
-reseals `plan_digest` and records both digests in `reseals`, so later children
-continue without retiring the batch. Any other Intent change still fails closed
-as `plan_changed` and takes the ADR 0016 retirement path.
-
-Before a new lane batch provisions any Lane, the runner compares the Kernel
-contract identifiers (TaskRecord, tombstone, projection, store schema) of the
-coordinator's runtime with those of the runtime a Lane Executor loads — never the
-plugin version number — and refuses with `batch_runtime_contract_mismatch`,
-naming both sources, when they differ; a match adds no confirmation. A Lane whose
-state exists but whose contract the coordinator refuses to read parks as
-`batch_lane_contract_mismatch` with the original parse error, distinct from a
-missing Lane's `batch_lane_lost`.
-
-Inside a Lane, the Pi extension and the Claude Code `PreToolUse` hook refuse an
-`edit`/`write` (Claude: `Edit`, `Write`, `MultiEdit`, `NotebookEdit`) whose
-resolved target lies outside the Lane, naming the Lane path. A shell command is
-not intercepted; this is no bash sandbox. When a lane batch is re-entered with a
-dirty coordinator checkout, each dirty path is restored to HEAD only if every one
-of them is an unstaged modification or untracked file that a Lane of this batch
-changed (its bytes differ from that Lane's base) and whose bytes equal the Lane's,
-in its worktree or a Lane-branch commit. The read-only preflight only attributes;
-the runner restores after the batch is authorized. The bytes are
-backed up first under `.imm/state/batches/restores/`, and the backup is recorded
-in the batch record and report as `restores`. If any change has another origin,
-or is staged or deleted, no file is touched and the refusal names it; never
-stage such changes to get past the refusal. A resume with a different
-`max_parallel` is refused with `batch_parallel_mismatch`. A Lane holds no batch
-state and its Host session never re-enters the batch.
-
-#### Lane Preferences
-
-A repository can keep standing lane-mode choices next to its other Immune-Brain
-preferences. Before the first `start_unattended_batch` call for an Initiative,
-the Parent resolves each of the four directives below in this order, reading the
-source directly rather than assuming the Host injected it into context:
-
-1. a literal user instruction for the current request;
-2. the directive in the repository root agent instruction file, whichever this
-   repository tracks: `AGENTS.md` or `CLAUDE.md`;
-3. the same directive in the Host's user-level agent instruction file; or
-4. the behavior without a directive, given in the table.
-
-| Directive | Value | Effect | Without it |
-| --- | --- | --- | --- |
-| `Lane max parallel: <n>` | positive integer | The Parent passes it as `max_parallel` when it starts a batch, which selects lane mode. The native confirmation still shows it. | No `max_parallel`: the batch is serial unless the user asks otherwise |
-| `Lane Executor Host: <host>` | `claude-code` or `pi` | Every Lane's Executor Host is that Host. When the `lane-steward` did not report it available in a Lane, that Lane has no Executor Host; the Parent does not fall back to the other one. | The Parent's own Host type, else the other allowlisted Host |
-| `Lane Executor model: <model>` | a model identifier of the configured Executor Host | Passed to the Executor Host as `--model <model>` | The Executor Host's own default |
-| `Lane Executor effort: <level>` | a level the configured Executor Host accepts | Passed as `--effort <level>` to `claude-code` and as `--thinking <level>` to `pi` | The Executor Host's own default |
-| `Batch final verification: <command>; <command>` | plain commands without shell syntax or quoting, at most 8 | Passed as `final_verification` when a new lane batch starts and shown in its native confirmation; the runner runs them on the batch branch once every child is integrated and writes each command's exit status and timing into the completion report as `final_verification`. A failing command reports the batch as not passed; integrated commits are never rolled back | The commands the repository instruction file names for its full test suite and type check, else none and the completion report says nothing was run |
-
-A model identifier and an effort level mean something only to one Host, so
-`Lane Executor model` and `Lane Executor effort` apply only together with
-`Lane Executor Host` from the same or a higher source; without it they are
-reported and not applied. A repository directive overrides the user-level one.
-Report an invalid value and ask instead of guessing or clamping. After resolving
-them, display one non-blocking line with each selected value and its source. On
-a resume the recorded `max_parallel` stands and the directive is not passed
-again. The directives configure how the Parent starts sessions; the runner reads
-none of them, and they grant no permission or trust option.
-
-A repository that names its full test and type-check commands in prose (for
-example "uses `bun test`; type checking is `bun run typecheck`") supplies them as
-the final verification without a directive; the Parent never invents a command
-the repository does not name.
-
-#### Lane Executor Supervision
-
-The Parent launches and supervises every Lane's Executor Host; no other role
-starts one. This is the one case in which the Parent starts another Loop
-process, and it starts it only in an admitted Lane. For each `executor` handoff
-whose Lane has no live session of its own, the Parent starts exactly one
-**supervised session** and keeps its handle. Handoffs of one report start
-together; a Lane never has two sessions.
-
-A supervised session is defined by what it guarantees, not by a Host's name:
-
-- It is a separate Host process whose working directory is the Lane, so its
-  Kernel root is the Lane's own Authority Store. A subagent that runs inside the
-  Parent's process shares the Parent's root and is never a Lane Executor.
-- It is given one explicit `imm-run` entry for that `task_id`, and nothing else.
-- When it stops working — it exits, or it settles waiting for input — control
-  returns to the Parent without the Parent polling or sleeping.
-- The Parent can stop it.
-
-The Parent Host and the Executor Host are chosen independently. The Executor
-Host is any allowlisted Host (`claude-code` or `pi`) that the `lane-steward`
-reported available in that Lane. A `Lane Executor Host` directive under
-[Lane Preferences](#lane-preferences) decides it; without one, prefer the
-Parent's own Host type, and use the other when only it is available. The child's QA and Review then run under that
-Executor Host's own Assurance adapter in the Lane. The Executor Host loads the
-same Immune-Brain plugin or package the Parent runs: a Parent started from a
-local plugin directory passes that same directory to the Executor Host. The
-Parent adds no permission or trust option of its own; the Executor Host runs
-under the user's own settings, with the model and effort of its own defaults
-unless Lane Preferences name them. How the Parent obtains a supervised session
-depends on where the Parent runs; the first matching row applies, and the user
-is not asked to choose:
-
-| Parent Host | Supervised session | Stop |
-| --- | --- | --- |
-| Either Host, inside Herdr (`HERDR_ENV=1`) | One Herdr tab per Lane holding an interactive Executor Host, under [Herdr Lane Tabs](#herdr-lane-tabs) | Close the tab the Parent created |
-| Claude Code | The Host's background command execution, running the Executor Host's non-interactive entry in the Lane; its completion notice re-invokes the Parent. The `Agent` tool does not qualify. | The Host's own stop for that background task |
-| Pi | A background process facility from the Pi user's own configuration that notifies the Parent on exit. Pi ships none that Immune-Brain may assume. | That facility's own stop |
-| Any Host without one | None. The Parent launches nothing. | — |
-
-When the Parent Host offers no supervised session, or no allowlisted Executor
-Host is available in the Lane, the Parent does not substitute a detached job, an
-in-process subagent or serial in-place work. It reports each `executor` handoff
-to the user with the Lane path, `task_id` and the `imm-run` entry to start
-there, and calls `start_unattended_batch` again when the user says a Lane has
-finished. Supervision is per Lane: Lanes that can be supervised are, and the
-rest are reported.
-
-##### Herdr Lane Tabs
-
-Inside Herdr the Parent drives the `herdr` CLI itself; the runtime and the
-`lane-steward` never do. Each Lane gets a tab of its own, so its Executor Host
-has a full-size terminal the user can read. For each `executor` handoff without
-a live tab:
-
-1. Take the Lane from the handoff's `lane_path`. Pick the Executor Host as above;
-   `claude-code` is Herdr kind `claude` and `pi` is kind `pi`.
-2. Create the tab without taking focus, in the Parent's own workspace and rooted
-   in the Lane:
-   `herdr tab create --workspace "$HERDR_WORKSPACE_ID" --cwd <lane_path> --label <name> --no-focus`.
-   Without `--workspace` the tab lands in whichever workspace has focus. `<name>`
-   is a label of at most 32 characters such as the Slice ID; a `task_id` is
-   usually too long. Read `tab.tab_id` and `root_pane.pane_id` from the JSON
-   result and keep `task_id → tab_id, pane_id`: the pane ID addresses the
-   session, the tab ID closes it.
-3. Start the Host in that tab's root pane:
-   `herdr agent start <name> --kind <kind> --pane <pane_id> -- <host arguments>`.
-   Host arguments are only those that load the Parent's plugin and those that
-   [Lane Preferences](#lane-preferences) resolved for model and effort.
-4. Submit the entry and nothing else (later text follows only the instruction
-   rule below), and confirm the turn began:
-   `herdr agent prompt <pane_id> "<imm-run entry> <task_id>" --wait --until working --until blocked --timeout 30000`.
-   The entry is the Executor Host's own `imm-run` invocation as that Host names
-   it: a Claude Code Host that loaded the plugin from a directory names it
-   `/immune-brain:imm-run`.
-5. Supervise with `herdr agent wait <pane_id>` as a Host background command, so
-   its return re-invokes the Parent. Start it only after step 4 reported
-   `working`: a wait attached to a still-`idle` session returns at once. Do not
-   loop on `herdr agent get` or read the pane to judge progress.
-
-`agent_not_ready` from step 3, or a `blocked` state at any time, means the tab
-shows a dialog only the user may answer: workspace trust, sign-in, a permission
-request, a question, or a native confirmation such as an Intent revision gate.
-The Parent sends that tab no keys and no prompt, and never answers such a dialog
-for the user. As soon as the wait returns `blocked` it tells the user which tab
-and `task_id` is waiting and what the dialog asks, without waiting to be asked,
-leaves the tab open, and continues the other Lanes; once the user has answered, step 3's tab is resumed
-from step 4 if the entry was never submitted, otherwise from step 5. `idle` or
-`done` is a session end for the rules below, although the tab stays open: the
-Parent calls `start_unattended_batch`, and a relaunch submits the entry again in
-the same tab instead of creating another. When that report shows the child
-neither settled nor waiting on a user decision, the Parent tells the user which
-tab and `task_id` went idle and what the Kernel projection still requires.
-
-The Parent may send one text instruction to a Lane session, and only while it is
-`idle` and its child is still running in the Lane: a correction to the
-Executor's approach, never an answer to a dialog. It first calls
-`start_unattended_batch` with `lane_instruction` (`task_id`, `text`, `kind`
-`instruction` or `correction`, and the `session_state` it just observed with
-`herdr agent get`). The runner records the text in the batch record and report
-as `interventions` and answers `lane_instruction.accepted`; only when accepted
-does the Parent submit it with `herdr agent prompt <pane_id> "<text>" --wait
---until working --until blocked --timeout 30000` and re-arm step 5. A `blocked`
-or `working` session is refused and receives nothing. Every instruction the
-coordinator sent is therefore in the report, so Executor-initiated behavior and
-coordinator intervention can be told apart afterwards. This never applies to a
-Review agent: a dispatched reviewer is still never continued or re-prompted.
-
-When a Lane child exhausts its rework budget (the per-child `qa_failure_limit`)
-it does not park for the user at once: the report carries a
-`{ role: "coordinator", action: "correct" }` handoff and the runner makes no
-further attempt for that child. The Parent reads the findings of every round
-from that Lane's Kernel state, decides whether they point at one root cause, and
-writes one design-level correction — the invariant to hold and the shared seam to
-fix — never a patch of its own. It starts a new Executor session in the Lane
-(the old context is not reused; the new session resumes from the Kernel
-projection and the Lane workspace alone) and sends the correction as
-`lane_instruction` kind `correction`; the runner counts it. At most two
-corrections are spent per child: the third exhaustion parks the child as
-`batch_correction_limit_reached`, its dependents are skipped, siblings that do not
-depend on it keep executing and integrating, and the batch reports it at the end.
-Single tasks outside a batch keep their existing budget behavior, and Review
-independence is unchanged. A Review rework budget that the Kernel turns into a
-`replan_required` decision still needs the user's own native decision.
-
-Every live Lane session keeps exactly one `herdr agent wait` armed, so `blocked`
-and idle-without-settlement wake the Parent on their own; a Parent that has
-nothing else to do still ends its turn with those waits armed. A failed or timed-out `herdr` command
-proves nothing about delivery; inspect the session's state before repeating it.
-
-The Parent only creates: it closes no tab, including the tabs it created, and
-every tab stays open for the user to read and close. It splits no pane and
-creates no workspace. Outside Herdr the Parent never invokes `herdr`.
-
-Supervision is event-driven. Each session end is the cue to call
-`start_unattended_batch` again with the same Initiative, and that report is the
-only progress signal: a child's state and `next_obligation` come from its Lane's
-Kernel projection, never from the session's output or exit status. When the
-report still carries an `executor` handoff for a child whose session has ended,
-the Parent starts it once more; after a second end without Kernel progress, or
-when the report shows the child waiting on a user decision or an open Review
-reservation, it stops relaunching and reports that child to the user while its
-siblings continue. The Parent stops no session: when the report shows a child
-parked or settled while its session is still working, the Parent tells the user
-which tab and `task_id` to close. A session that stays open changes no Kernel
-or batch state, so the next report states what remains. Handles are not
-authority: after an interruption
-the Parent calls `start_unattended_batch` first and launches only for the
-handoffs it returns.
-
-After a child is integrated, its Lane is clean and its `.imm/audit/<task-id>/`
-pair is reachable from the batch branch, the report carries a
-`{ role: "lane-steward", action: "release" }` handoff for that Lane. A parked,
-failed, dirty or unintegrated Lane, or one whose audit pair is not on the batch
-branch, is never offered for release. The runner removes no worktree and deletes
-no branch: it records the child `released` only when a later tick observes the
-Lane path gone, and a Lane that is still present stays `integrated` while the
-batch still completes. The `lane-steward` internal role handles a `provision`
-handoff; it follows the project's own instructions to prepare a Lane, starts no
-Host session, and reports "cannot supply" rather than improvising. A `release`
-handoff is the user's to carry out: the Parent removes no Lane and dispatches no
-one to remove it. It reports each such Lane once, with its `task_id`, Lane path
-and tab, as ready for the user to close and remove.
-
 ## Decisions and Recovery
 
 - Resume from authority facts, not prose. After an uncertain interruption, bind
@@ -492,6 +197,24 @@ is recorded as a separate follow-up rather than resolved here.
   reasons in one request. Do not edit outside scope while waiting or widen it
   piecemeal without new evidence. Bounded test or PR repair stays inside the same
   TaskIntent.
+- Exception to the bullet above, the Loop owner's own call: a same-directory
+  addition. When the new entry is a concrete file in a directory where the scope
+  already names a concrete file, and it is not a path the project's risk floor
+  names in `.imm/risk-floor.json`,
+  submit `revise_intent` with the complete next intent. It classifies
+  `compatible`, applies without a native gate, and the next Review prompt names
+  the added paths as self-served (ADR 0021). A revision that only removes
+  entries is `compatible` as well: narrowing removes authority, so it applies
+  through `revise_intent` without a gate, provided at least one entry remains.
+  A glob, new directory or floor path is breaking, and so is an addition
+  combined with a removed entry; a directory written without a trailing
+  slash is refused by the Host before submission, so name concrete files or
+  widen with a glob entry through `approve_breaking_intent_revision`. The envelope check for a revision is judged against the next
+  scope, so a worktree that already holds the added files no longer blocks it.
+- Revision ownership: the Loop owner prepares a scope or acceptance revision in
+  the executing session. Planner's route is for a change of goal, bound Spec
+  design, or decomposition, and returns any other proposal to the executing
+  session. No Host refuses a file edit because of the session's entry.
 - Effects are separate grants. A stage-only recovery restores staging and grants
   no commit, push, or publication; an existing exact approval, including a valid
   batch capability bounded to one child, stays usable without another chat gate.
@@ -501,14 +224,16 @@ is recorded as a separate follow-up rather than resolved here.
 - Text instructions are contracts, not a hard bash sandbox. They guide and are
   reviewed; the Kernel authority gates remain the real boundary.
 - In a Lane whose batch confirmation delegated in-envelope revisions
-  (ADR 0018), the Executor does not open the gate for a revision that only
-  changes acceptance or narrows `scope_hint`: it stops and returns the complete
-  next intent to the Parent, which submits it as `lane_revision` on
-  `start_unattended_batch`. The runner applies it as a delegated approval
+  (ADR 0018), the Executor does not open the gate for a breaking revision that
+  changes acceptance, alone or with a narrowed `scope_hint`: it stops and
+  returns the complete next intent to the Parent, which submits it as
+  `lane_revision` on `start_unattended_batch`. The runner applies it as a delegated approval
   (actor `batch-coordinator`, confirmation `delegated-batch:<batch_id>@<time>`)
   or refuses it with `batch_delegation_refused` and a `fallback`; on refusal the
   Executor uses its own native gate below. Widening scope, changing risk, goal
-  or the bound Spec is never delegated, and nobody answers a dialog in a tab.
+  or the bound Spec is never delegated, and nobody answers a dialog in a tab. A
+  revision that only narrows `scope_hint` is compatible and is not delegated:
+  the Executor applies it with `revise_intent`.
 - Invoke `approve_breaking_intent_revision` with the complete next intent
   directly; the native Host gate is the single user decision. Do not overwrite
   enrolled intent sidecars or ask for chat pre-confirmation. A breaking revision
@@ -544,14 +269,30 @@ is recorded as a separate follow-up rather than resolved here.
   Use its canonical descriptor reference/digest, phase/outcome, timing and byte
   counts to diagnose; QA diagnostic metadata is capped at 16 KiB and contains no
   stdout/stderr, argv, environment values or arbitrary executor error text.
+  The stage decides what else a failed result carries. A `prepare` stage ending
+  in timeout, nonzero exit or output limit adds `prepare_observation` to the
+  direct Tool result only: the execution conditions (the task's working
+  directory), the declared timeout, and at most 2048 bytes of
+  the end of stderr with control characters other than newline and tab removed. It is never persisted. A failing `check`
+  stage returns no output text at all. A `protected_input_or_output_drift`
+  failure adds `prepare_observation.drift_paths`, at most 64 in-scope paths that
+  differ from the frozen snapshot, to the direct Tool result only; restore or
+  stage those paths before a fresh attempt. The Lane batch integration recheck
+  is the one run that still uses an isolated copy with no worktree
+  `node_modules`, because its merge candidate is never checked out; a
+  reproduction in the live worktree is not equivalent to that run.
   A frozen child with `run_qa` pending returns to Parent; batch re-entry does not
   blindly retry an unchanged failure. Fix the environment before a fresh attempt.
   Scope/authority exceptions still use their existing native gates. A committed
   QA result is honored; an interrupted precommit QA run produces no approval.
   Do not rerun fresh QA simply because Review was interrupted.
-- Malformed or stale reviewer output is not a verdict. Keep the existing
-  reservation only if the Host reports it valid; use its exact recovery action.
-  Do not fabricate a pass or blindly redispatch Review.
+- Provider quota or interruption is not Review budget exhaustion. Preserve
+  fresh QA and follow the Host's exact `recovery_action`; an unchanged envelope
+  returned by `advance_assurance` alone does not authorize redispatch of an
+  already-dispatched reservation. Malformed or stale reviewer output is not a
+  verdict. Keep a reservation only if the Host reports it valid; obtain a new
+  one only through its supported recovery. If the returned action cannot clear
+  the observed fault, report that concrete Host blocker rather than loop.
 - Missing tools, credentials, invalid projections, or repeated unchanged failures
   stop with a concrete cause. Cancellation performs no decision write and is not
   task termination. Explicit task stop uses its native authority gate.
@@ -562,6 +303,10 @@ Reviewers are read-only and bound to the frozen snapshot. They cannot edit files
 write planning artifacts, mutate Kernel state, or settle decisions. Report all
 substantiated blockers in one round, tied to acceptance or a concrete regression;
 separate optional advice from blockers. Suggestions alone do not justify rework.
+Inspect archived pass advice in `attestations[].advisory_findings`, not only
+record-level `findings`. Cite its record/attestation before claiming it is
+archived; session-only notes are not durable evidence. Reuse this storage rather
+than creating another advisory archive.
 Use the returned verdict schema exactly, including omission of unsupported fields.
 A Review pass verdict's approval must carry `inspected_paths`: an array of
 unique repository-relative path strings listing every path of the reviewed

package/plugins/immune-brain/dist/role-prompts/code-review.md

@@ -46,6 +46,27 @@ cite the acceptance whose principle it violates as `acceptance_id` and
 to be written into the acceptance text; a missing literal clause is not itself a
 finding and does not call for an Intent revision.
 
+## Trigger and Threat Model
+
+`evidence.trigger` must read "concrete input or state → observable wrong
+result". A finding that cannot name the wrong result is not blocking. Judge
+against the threat model and supported environment declared in the Spec or
+TaskIntent goal: a defect that needs an attacker, input source, repository
+format, encoding, or platform outside that declaration is advisory. When
+nothing is declared, assume inputs come from the repository's own tooling and
+the user's trusted workspace. `security_boundary` means a security, data-loss,
+or authority boundary the change actually crosses.
+
+From Review round 3 the manifest carries `prior_review_commit` and
+`delta_paths`: the paths the latest rework changed. Review that delta and its
+direct interactions. A blocking finding is admitted only when at least one
+`caller_chain` entry names a path in `delta_paths`, or `violated.kind` is
+`security_boundary`; an edge case that already existed in round 1 is advisory
+unless it crosses a security, data-loss, or authority boundary. A verdict that
+blocks outside the delta is rejected for resubmission. When the manifest carries
+`delta_skipped` instead, no delta exists for the round and this rule does not
+apply.
+
 ## Invariant and Evidence Coverage
 
 Judge whether the change actually closes the invariant its acceptance names,
@@ -95,7 +116,7 @@ contract: `contract`, `role`, `task_id`, `snapshot_digest`, `decision` (`pass`
 or `rework`), and for `pass` include `approval` (`kind`, `authority_role`,
 `summary`), for `rework` include `findings` (`id`, `kind`, `acceptance_id`,
 `summary`, `evidence`). Every rework finding's `evidence` must carry
-`trigger` (the concrete inputs or state that reach the defect), a non-empty
+`trigger` (the concrete input or state that reaches the defect and the observable wrong result it produces), a non-empty
 `caller_chain` (ordered repository paths or symbols), and `violated`
 (`kind`: `acceptance` or `security_boundary`, `ref`: the acceptance id or
 boundary name). Do not invent fields, and never send an anchor yourself: the
@@ -104,6 +125,9 @@ violated.ref, caller_chain}`, so an identical claim keeps one stable identity
 across review rounds while a different call chain is a different claim. A
 passing review carries no blocking findings; non-blocking notes may ride along as
 `kind: "advisory"` findings, and every finding, advisory included, needs the
-same machine-checkable evidence. If the
+same machine-checkable evidence. Advisory notes are archived on a pass and never
+become Executor work. A rework carries only `kind: "blocking"` findings, at
+least one: the coordinator rejects a rework with an advisory finding or without
+a blocking one, so submit `pass` with `inspected_paths` when nothing blocks. If the
 checkpoint is `awaiting_user_successor_decision`, stop without dispatch; only
 a literal user may invoke `--approve-successor`.