runward 0.14.2 → 0.16.0

package/templates/mission/execution-topology.md

@@ -40,6 +40,8 @@ Risk is classed **by deployment, not by platform** (§15): the same platform hos
 ## Rule conformance
 
 > Account for every CRITICAL/HIGH craft rule mapped to the topology phase (`runward/rules/`, frontmatter `phases: [topology]`). `applied` needs a pointer; `deviated` needs an ADR; `n/a` needs a reason. `runward check --strict` verifies this table is complete — it checks a traced placement decision, not where you should run.
+>
+> Evidence can be **typed**, and typed pointers are verified deterministically at the gate: `file:PATH[:LINE][#SYMBOL]` · `test:PATH[::NAME]` · `adr:NNNN` — several per cell, separated by `;`. The gate checks resolution, non-emptiness, line count, symbol/test-name presence, and the rule's `signature:` when it declares one (ADR-0019/0020). Free prose stays valid — it is your judgment; a path it cites must simply not point at an empty file.
 
 | Rule | Status | Evidence |
 |---|---|---|

package/templates/mission/floor.md

@@ -20,6 +20,8 @@
 ## Rule conformance
 
 > Account for every CRITICAL/HIGH craft rule mapped to the floor phase (`runward/rules/`, frontmatter `phases: [floor]`). Status: `applied` needs an evidence pointer (a `file:line` or a test); `deviated` needs an ADR reference; `n/a` needs a one-line reason. `runward check --strict` verifies this table is complete and well-formed — it does not judge your implementation; you do, at the gate.
+>
+> Evidence can be **typed**, and typed pointers are verified deterministically at the gate: `file:PATH[:LINE][#SYMBOL]` · `test:PATH[::NAME]` · `adr:NNNN` — several per cell, separated by `;`. The gate checks resolution, non-emptiness, line count, symbol/test-name presence, and the rule's `signature:` when it declares one (ADR-0019/0020). Free prose stays valid — it is your judgment; a path it cites must simply not point at an empty file.
 
 | Rule | Status | Evidence |
 |---|---|---|

package/templates/mission/handover.md

@@ -0,0 +1,52 @@
+# Hand-over Note
+
+> **Usage.** Fill this note in phase 6 (`workflows/handover.md`), as the succession happens — not after. It is the kit made legible in one place: what is handed over, the proof that the receiving side can operate alone, and who owns the system now. `runward check --strict` verifies its conformance manifest; you transfer autonomy, not documents.
+
+## 1. The kit
+
+One row per leave-behind. State is honest: a document nobody has exercised is `untested`, not `ready`.
+
+| Artifact | Where | State | Exercised by the receiving side? |
+|---|---|---|---|
+| Recovery runbook | `runbook.md` | [ready \| untested] | [when / by whom, or not yet] |
+| Agent charter (finalized) | `AGENTS.md` | [finalized at hand-over \| still the scaffold] | [—] |
+| Architecture note + decision journal | `architecture.md` · `adr/` | [current \| stale] | [—] |
+| Evaluation bench | [where it runs] | [ready \| untested] | [—] |
+| Evidence pack | `compliance/` (regenerate on demand) | [—] | [—] |
+
+## 2. The redone task (the proof)
+
+The hand-over is proven by a real task redone end to end **without the departing builder**. Record it here; point the manifest at this section.
+
+- **Task**: [a real one from the mission's backlog — which change, run, fix or evaluation]
+- **Date / doer**: [when, and who — explicitly without the builder in the loop]
+- **Evidence**: [the artifact produced — a merged change, a report, a closed approval; a pointer the gate can verify]
+- **Gaps found**: [every step the doer had to guess — each folded back into the runbook or charter before the gate is crossed]
+
+## 3. Succession
+
+- **Owner after departure**: [named person or standing role — incidents, cost, keys, open ADR triggers]
+- **Escalation path**: [who is called when the owner is not enough — security contact, sponsor, provider support]
+- **Review cadence**: [when the usage registry, the ADR triggers and the evidence seal are re-read, and in which forum]
+- **Credentials boundary**: [where the keys live, who rotates them; the builder's accesses revoked on — date]
+
+## 4. Provider-swap drill
+
+The model is a replaceable adapter behind a port — proven, not assumed. Record the last drill: [date, from → to, what was re-run afterwards (the bench), result]. If never drilled, say so here and name the trigger that will force it.
+
+## Rule conformance
+
+> Account for every CRITICAL/HIGH craft rule mapped to the handover phase (`runward/rules/`, frontmatter `phases: [handover]`). `applied` needs a pointer; `deviated` needs an ADR; `n/a` needs a reason. `runward check --strict` verifies this table is complete — it checks a traced succession, not whether the hand-over went well.
+>
+> Evidence can be **typed**, and typed pointers are verified deterministically at the gate: `file:PATH[:LINE][#SYMBOL]` · `test:PATH[::NAME]` · `adr:NNNN` — several per cell, separated by `;`. The gate checks resolution, non-emptiness, line count, symbol/test-name presence, and the rule's `signature:` when it declares one (ADR-0019/0020). Free prose stays valid — it is your judgment; a path it cites must simply not point at an empty file.
+
+| Rule | Status | Evidence |
+|---|---|---|
+| [rule-slug] | applied \| deviated \| n/a | [pointer, ADR-id, or reason] |
+
+## Cross-references
+
+- `workflows/handover.md` — the phase this note closes.
+- `runbook.md` — the operational half of the kit; this note indexes, the runbook operates.
+- `AGENTS.md` — the charter the next agent inherits.
+- `adr/` — the open re-evaluation triggers the new owner now watches.

package/templates/mission/threat-model.md

@@ -51,6 +51,8 @@
 ## Rule conformance
 
 > Account for every CRITICAL/HIGH craft rule mapped to the govern phase (`runward/rules/`, frontmatter `phases: [govern]`). `applied` needs a pointer; `deviated` needs an ADR; `n/a` needs a reason. `runward check --strict` verifies this table is complete — it checks a traced decision, not the quality of your governance.
+>
+> Evidence can be **typed**, and typed pointers are verified deterministically at the gate: `file:PATH[:LINE][#SYMBOL]` · `test:PATH[::NAME]` · `adr:NNNN` — several per cell, separated by `;`. The gate checks resolution, non-emptiness, line count, symbol/test-name presence, and the rule's `signature:` when it declares one (ADR-0019/0020). Free prose stays valid — it is your judgment; a path it cites must simply not point at an empty file.
 
 | Rule | Status | Evidence |
 |---|---|---|

package/templates/rules/frontier-deterministic-boundary.md

@@ -3,6 +3,7 @@ title: Deterministic Boundary of the Model
 impact: CRITICAL
 asi: [ASI01]
 phases: [floor]
+signature: assertGrounded|GroundingError|fail[-\s]?closed
 impactDescription: Keeps every fact, figure and decision that can be checked out of the model, so the system is verifiable and cannot hallucinate load-bearing values
 tags: [architecture, llm, frontier, grounding, safety, determinism]
 ---

package/templates/rules/handover-agents-charter-final.md

@@ -0,0 +1,45 @@
+---
+title: The Agent Charter Is Finalized as the Leave-Behind
+impact: HIGH
+asi: [ASI10]
+phases: [handover]
+impactDescription: AGENTS.md leaves the mission as the standing constraint on every future agent — verification commands, judgment boundaries, never/PR rules — so the next agent inherits the discipline, not just the code
+tags: [handover, agents-md, charter, governance, succession]
+---
+
+## The Agent Charter Is Finalized as the Leave-Behind
+
+> **The next agent was not in the room.**
+> Everything the mission learned about where agents must stop, ask, or prove is worthless if it leaves with the builder. `AGENTS.md` is where that judgment survives the succession — finalized, specific, and pointing at the gate.
+
+During the mission, the charter accumulated defaults. At hand-over it must be **rewritten as the leave-behind**: the document a receiving team's agent reads on day one, with no builder nearby to fill the gaps. An inherited agent operating without a finalized charter is the quiet path to a rogue one (ASI10) — not through malice, but through inherited ambiguity: nothing says what it may touch, what proves its work, or when it must stop and ask a human.
+
+**What "finalized" means, concretely:**
+
+- **Verification commands, exact.** The charter names how work is proven here — `runward check --strict` at minimum, the behavioral proof command, the evaluation bench. An agent that cannot verify will assert.
+- **Judgment boundaries, mission-specific.** Not the scaffold's generic five: the boundaries this mission actually discovered — which data classes are untouchable, which actions are approval-gated, which files no agent edits.
+- **Never / PR rules.** What is never done autonomously, and what always goes through a reviewed change — stated as rules, not anecdotes.
+- **The pointers resolve.** The workflows, rules and deliverables the charter cites still exist where it says — typed evidence in the manifest lets the gate verify that.
+
+**Incorrect:**
+
+```markdown
+| handover-agents-charter-final | applied | AGENTS.md exists since init |
+```
+
+Existing since `init` is the opposite of the point: the scaffold is the starting text, the leave-behind is the mission's learned judgment.
+
+**Correct:**
+
+```markdown
+| handover-agents-charter-final | applied | file:AGENTS.md#Non-negotiable — finalized at hand-over: verification commands (check --strict + npm test + bench), the two mission-specific boundaries (registry data read-only; compliance-flagged routing always approval-gated), never/PR rules |
+```
+
+**Checklist:**
+
+- [ ] The charter was re-edited at hand-over, not merely left as scaffolded.
+- [ ] Verification commands are exact and were run by the receiving side (see the redone task).
+- [ ] Mission-specific boundaries and never/PR rules are present and dated.
+- [ ] Every path the charter cites resolves — the manifest points at the charter with typed evidence.
+
+**Where this sits in the Runward method:** ADR-0010 made `AGENTS.md` a first-class hand-over deliverable; ADR-0026 makes its finalization a gated fact. The charter is how the mission's judgment outlives the mission.

package/templates/rules/handover-redone-task-proof.md

@@ -0,0 +1,46 @@
+---
+title: The Redone-Task Proof
+impact: CRITICAL
+asi: [ASI09]
+phases: [handover]
+impactDescription: A hand-over is proven by a real task redone end to end without the departing builder — recorded, dated, pointed at — so autonomy is a fact, not a farewell promise
+tags: [handover, succession, autonomy, proof, transmission]
+---
+
+## The Redone-Task Proof
+
+> **You transfer autonomy, not documents.**
+> The hand-over is proven the day the receiving side redoes a real task, end to end, without the person who built the system. Until that has happened and been recorded, the succession is a hope with a runbook attached.
+
+A kit can be complete and dead: every document present, nobody able to act. The only observable that distinguishes a live succession from a paper one is the **redone task** — a real change, run, fix or evaluation executed by the receiving team alone, from the leave-behinds, with the builder unavailable by agreement.
+
+**What the record must carry** (in `handover.md`, the proof record):
+
+- **The task** — a real one from the mission's actual work, not a rehearsed demo. Fixing a routing rule, re-running the evaluation bench after a model swap, processing a suspended approval, resuming from a checkpoint: something that exercises the runbook, the code and a decision.
+- **The date and the doer** — who redid it, when, explicitly without the builder in the loop.
+- **The evidence** — a pointer the gate can verify (`file:`, `test:`, or the artifact the task produced). "It went fine" is not evidence; the merged change, the produced report, the closed approval is.
+- **What broke, honestly** — every step where the doer had to guess is a defect in the kit. Route each one back into the runbook or the charter before the gate is crossed.
+
+**Incorrect:**
+
+```markdown
+| handover-redone-task-proof | applied | the team is confident and has been walked through everything twice |
+```
+
+A walkthrough is the builder performing; the proof is the builder absent.
+
+**Correct:**
+
+```markdown
+| handover-redone-task-proof | applied | file:runward/handover.md#Redone-task — 2026-06-28, ops engineer re-ran the eval bench after the provider swap, alone, from runbook §4; report at code/eval/reports/2026-06-28.md; two runbook gaps found and fixed |
+```
+
+**Checklist:**
+
+- [ ] The task was real mission work, chosen from the backlog, not staged.
+- [ ] The builder was genuinely out of the loop (agreed beforehand, verifiable).
+- [ ] The record names task, date, doer, and points at the produced artifact.
+- [ ] Every gap the doer hit was folded back into the runbook or charter.
+- [ ] The record lives in `handover.md` where `runward check --strict` reads it.
+
+**Where this sits in the Runward method:** phase 6 is where every other scaffold has already stopped. This rule is the difference between handing over a repository and handing over a running responsibility — and it is why the hand-over claim is gated, not narrated (ADR-0026).

package/templates/rules/handover-runbook-executable.md

@@ -0,0 +1,50 @@
+---
+title: The Runbook Is Executable, Not Descriptive
+impact: HIGH
+asi: [ASI08]
+phases: [handover]
+impactDescription: The recovery runbook carries real commands for the gestures that matter at 3 a.m. — start, observe, debug, resume, swap the provider, rerun the bench, process a suspended approval — so an incident meets procedures, not prose
+tags: [handover, runbook, operations, recovery, resilience]
+---
+
+## The Runbook Is Executable, Not Descriptive
+
+> **A runbook is judged at 3 a.m., by someone who was not there when the system was built.**
+> Every gesture it promises must be a command that runs, a path that exists, a signal that can actually be read — not a paragraph explaining that such things are possible.
+
+Agentic systems fail in cascades (ASI08): a provider degrades, a queue backs up, an approval hangs, and the operator's margin is measured in minutes. The runbook is the artifact that converts a cascade into a sequence of known gestures. A descriptive runbook — "the system can be restarted; logs are available" — is a cascade accelerant: it costs the reader the minutes it pretends to save.
+
+**The seven gestures the runbook must carry, each with its real command or path:**
+
+1. **Start / stop** — the exact commands, including the safe-stop that drains instead of kills.
+2. **Observe** — where the structured logs and metrics are, and the one query that answers "is it healthy?".
+3. **Debug a trajectory** — how to reconstruct a full run from one request ID.
+4. **Resume from a checkpoint** — where suspended state lives and the command that rehydrates it.
+5. **Swap the model provider** — the adapter switch, the config to change, and what to re-run afterwards.
+6. **Rerun the evaluation bench** — the command, and where the report lands.
+7. **Process a suspended approval** — where it queues, who may approve, the command or UI path that releases it.
+
+**Incorrect:**
+
+```markdown
+## Recovery
+The system is resilient and can be restarted. Observability is in place.
+```
+
+**Correct:**
+
+```markdown
+## 4. Resume from a checkpoint
+Suspended runs live in var/journal/ (one file per request ID).
+    npm run resume -- --request <id>
+Verify: the trajectory for <id> continues in the structured log within 30 s.
+```
+
+**Checklist:**
+
+- [ ] All seven gestures present, each with a command or concrete path — no gesture "described" without one.
+- [ ] Commands were executed at least once by someone other than their author (the redone task is the natural occasion).
+- [ ] The runbook names its own verification: how the reader confirms each gesture worked.
+- [ ] Paths and commands are pointed at from the manifest with typed evidence, so the gate catches drift when they move.
+
+**Where this sits in the Runward method:** the runbook is scaffolded at `init` and demanded by the hand-over workflow since day one; this rule makes its *executability* a gated fact (ADR-0026) instead of a review opinion.

package/templates/rules/handover-succession-named.md

@@ -0,0 +1,46 @@
+---
+title: The Succession Is Named
+impact: HIGH
+asi: []
+phases: [handover]
+impactDescription: The system leaves the mission with a named owner, an escalation path and a review cadence — an unowned agentic system in production is an incident with a start date
+tags: [handover, ownership, succession, governance, operations]
+---
+
+## The Succession Is Named
+
+> **Systems do not stay owned by default; they become orphans by default.**
+> The day the builder leaves, either a named person owns the system — its budget, its keys, its incidents, its re-evaluation triggers — or nobody does, and every ADR trigger, every drift signal, every suspended approval now fires into a void.
+
+runward's whole discipline rests on someone reading the signals: re-evaluation triggers are *watched*, drift is *re-verified*, approvals are *processed*, the usage registry is *reviewed*. Those are verbs with a subject. Hand-over is the moment the subject changes — and the moment it silently becomes no one, unless the succession is written down where the gate can see it.
+
+**What the record must carry** (in `handover.md`):
+
+- **The owner** — a named person or standing role (not "the team") who owns the system after the departure: incidents, cost, keys, and the decision journal's open triggers.
+- **The escalation path** — who is called when the owner is not enough: security contact, sponsor, provider support entry points.
+- **The review cadence** — when the usage registry, the ADR triggers and the evidence seal are re-read (the iterate-gate rhythm surviving the builder), and in which forum.
+- **The credentials boundary** — where the keys live and who may rotate them; the departing builder's accesses are revoked as part of the hand-over, and the record says so.
+
+**Incorrect:**
+
+```markdown
+| handover-succession-named | applied | the team owns it going forward |
+```
+
+A team is not a subject; "going forward" is not a cadence.
+
+**Correct:**
+
+```markdown
+| handover-succession-named | applied | file:runward/handover.md#Succession — owner: ops lead (named); escalation: security officer, then sponsor; registry + ADR triggers reviewed monthly in the ops review; builder's accesses revoked 2026-06-30 |
+```
+
+**Checklist:**
+
+- [ ] One named owner (person or standing role) — for incidents, cost, keys and open ADR triggers.
+- [ ] An escalation path with real names or roles, reachable.
+- [ ] A written cadence for re-reading the registry, the triggers and the seal.
+- [ ] The builder's credentials revoked, and the revocation recorded.
+- [ ] The record lives in `handover.md`, verified by `runward check --strict`.
+
+**Where this sits in the Runward method:** governance from day zero only matters if it survives day last. This rule is the difference between transmitting a system and abandoning it politely (ADR-0026).

package/templates/targets/AGENTS.md

@@ -12,7 +12,7 @@ This project is delivered with the Runward method: floor first, evolution on evi
 
 ## How to work
 
-- Apply the craft rules in `runward/rules/` while building — and confront them at the point of action, not from memory. Each rule declares where it applies (`phases:`); a build phase surfaces its CRITICAL/HIGH rules to open and account for in the deliverable's `Rule conformance` manifest: `applied` with a `file:line` or test, `deviated` with an ADR, `n/a` with a reason. When a rule and a habit conflict, the rule wins; deviating requires an ADR. `runward check --strict` verifies the manifest is complete — it checks that a decision was traced, never the quality of the code; you judge that at the gate. When the gate is green, run `runward/workflows/verify.md` before crossing: an advisory, adversarial cite-vs-apply pass (ideally on a different model) that judges whether the code an `applied` row points at actually applies the rule or merely cites it. It is advisory — it never blocks the gate (ADR-0007).
+- Apply the craft rules in `runward/rules/` while building — and confront them at the point of action, not from memory (`runward explain <rule>` prints a rule's why and full text). Each rule declares where it applies (`phases:`); a build phase surfaces its CRITICAL/HIGH rules to open and account for in the deliverable's `Rule conformance` manifest. `runward manifest --sync` scaffolds the missing rows; you fill the decision: `applied` with a **typed pointer the gate verifies** — `file:PATH[:LINE][#SYMBOL]`, `test:PATH[::NAME]`, `adr:NNNN` (or prose, which stays the operator's judgment) — `deviated` with an ADR, `n/a` with a real reason. A signed rule (frontmatter `signature:`) needs evidence whose content matches its signature; a pointer at an empty or vanished file fails the gate. When a rule and a habit conflict, the rule wins; deviating requires an ADR. `runward check --strict` verifies the manifest and the evidence's shape — never the quality of the code; you judge that at the gate. When the gate is green, run `runward/workflows/verify.md` before crossing: an advisory, adversarial cite-vs-apply pass (ideally on a different model) that judges whether the code an `applied` row points at actually applies the rule or merely cites it, and records its findings in `runward/governance/verify-findings.md`. It is advisory — it never blocks the gate (ADR-0007). Once the operator crosses, they may seal the evidence with `runward check --freeze` (ADR-0021).
 - Consult `runward/decision-matrix.md` before adding any capability: 22 arbitrations, each with a sober default and an explicit trigger. No trigger, no change.
 - Before any structural decision, run `runward/workflows/decision-loop.md`: verify in the real code, check the sourced state of the art, challenge the source, take a durable position, lock it in an ADR — only then edit.
 - One ADR per structural decision, in `runward/adr/`, with a dated re-evaluation trigger. Use the template `runward/adr/ADR-0000-template.md`.
@@ -31,3 +31,4 @@ This project is delivered with the Runward method: floor first, evolution on evi
 | `runward/adr/` | Decision journal |
 | `runward/governance/` | Threat model, evaluation rubric, observability schema |
 | `runward/runbook.md` | Recovery runbook for the receiving team |
+| `runward/handover.md` | The succession record: kit index, redone-task proof, named owner — gated at phase 6 |

package/templates/workflows/floor.md

@@ -21,7 +21,7 @@ Use this workflow once the architecture is fixed and building must start: "what
 
 **Start from the reference floor, not a blank page.** The starting point is the reference floor (`floor-ts/` in the Runward repository): a clonable hexagonal scaffold that already carries the pure domain, the ports, the adapters, and the middleware chain, with a principle-to-code table mapping each principle to where it lives in the code. Clone it, implement the project's concrete adapters behind the ports fixed in `architect`, and leave intact the structure that keeps the domain testable without the model. Do not reinvent the skeleton; populate it.
 
-**Confront the floor's craft rules at the point of building.** Before writing each piece, open the CRITICAL/HIGH rules mapped to the floor phase — `runward/rules/`, frontmatter `phases: [floor]`: the deterministic frontier guard, the model port and its keyless fallback, provider auto-detection, secrets boundary, prompt-injection defense, the hexagonal architecture and adapter pattern, the event-sourced journal, tool-scope atomicity. Do not work from their names — read them. Account for each in the `Rule conformance` manifest of the floor note: `applied` with a `file:line` or test, `deviated` with an ADR, or `n/a` with a reason. `runward check --strict` verifies that manifest is complete and well-formed (it checks that a decision was traced, never the quality of the code — you judge that at the gate).
+**Confront the floor's craft rules at the point of building.** Before writing each piece, open the CRITICAL/HIGH rules mapped to the floor phase — `runward/rules/`, frontmatter `phases: [floor]`: the deterministic frontier guard, the model port and its keyless fallback, provider auto-detection, secrets boundary, prompt-injection defense, the hexagonal architecture and adapter pattern, the event-sourced journal, tool-scope atomicity. Do not work from their names — read them. Account for each in the `Rule conformance` manifest of the floor note: `applied` with a `file:line` or test, `deviated` with an ADR, or `n/a` with a reason. Prefer **typed pointers** — `file:PATH[:LINE][#SYMBOL]`, `test:PATH[::NAME]`, `adr:NNNN`, several per cell separated by `;` — the gate verifies them deterministically: resolution, non-empty content, symbol/test-name presence, and the rule's `signature:` when it declares one (ADR-0019/0020). `runward check --strict` verifies that manifest is complete and well-formed (it checks that a decision was traced and points at something real, never the quality of the code — you judge that at the gate).
 
 **Build exactly these six pieces, and nothing more.**
 

package/templates/workflows/handover.md

@@ -8,12 +8,13 @@ Use this workflow when a delivery approaches its end or a team must become self-
 
 - The artifacts of prior phases: architecture note, floor, ADR journal, threat model, evaluation rubric, observability schema.
 - A receiving team with time allocated for transfer sessions.
-- The `mission/runbook.md` template.
+- The `mission/runbook.md` and `mission/handover.md` templates.
 
 ## Outputs
 
 - A handover kit (below).
 - A demonstrated proof of autonomy.
+- The hand-over note (`mission/handover.md`): the kit indexed, the redone-task proof recorded, the succession named, the provider-swap drill logged — the gated deliverable of this phase.
 
 ## Procedure
 
@@ -36,11 +37,15 @@ Use this workflow when a delivery approaches its end or a team must become self-
 
 **Capitalize upward.** What repeats deserves standardizing. Escalate recurring patterns to whoever can industrialize them: an evolution trigger observed several times, an adapter rewritten identically across missions, a recurring guardrail. Feed proven arbitrations back into the decision matrix and the workflow files — the corpus hardens mission after mission. What gets capitalized is never the prototype (replaceable); it is the architecture and the method (owned).
 
-**Verify the Definition of Done explicitly.** The phase is done when the receiving team redoes a task alone, end to end, demonstrated — a sign-off or a training session does not count. The team, without you: starts the system, observes it, debugs an incident, adds an evaluation scenario, and decides a switch by leaning on the ADRs. All of it demonstrated, not promised.
+**Record the succession in the hand-over note.** Fill `mission/handover.md` as the succession happens: the kit index with honest states, the redone-task proof (task, date, doer, evidence, gaps folded back), the named owner with escalation path and review cadence, the provider-swap drill. Confront the CRITICAL/HIGH rules mapped to the handover phase (`runward/rules/`, `phases: [handover]`) and account for each in the note's `Rule conformance` manifest — `runward check --strict` verifies it, down to the typed evidence pointers.
+
+**Verify the Definition of Done explicitly.** The phase is done when the receiving team redoes a task alone, end to end, demonstrated — a sign-off or a training session does not count. The team, without you: starts the system, observes it, debugs an incident, adds an evaluation scenario, and decides a switch by leaning on the ADRs. All of it demonstrated, not promised — and recorded in the hand-over note, where the gate reads it.
 
 ## Definition of Done
 
 - Handover kit complete: assets, architecture note, ADR journal, runbook, proof in code, and the finalized `AGENTS.md` charter (the harness-neutral leave-behind).
+- Hand-over note produced (`mission/handover.md`): kit indexed, redone-task proof recorded, succession named, provider-swap drill logged.
+- Every handover CRITICAL/HIGH rule accounted for in the note's conformance manifest (`runward check --strict`).
 - Transfer sessions held with the team operating, not observing.
 - The team has repeated at least one real task end to end, alone — demonstrated, witnessed, recorded.
 - Recurring patterns escalated and fed back into the framework's templates.

package/templates/workflows/verify.md

@@ -17,12 +17,12 @@ It is **advisory**. It produces findings, never a verdict that gates. `runward c
 
 **Return a finding per row**: `confirmed` (the code applies the rule), `cited-not-applied` (the row claims applied but the code does not carry the rule), or `uncertain` (needs a human look). Deduplicate overlapping findings; group them by severity.
 
-**Hand the findings to the operator.** They are input to the operator's gate decision, not a gate of their own. A `cited-not-applied` finding is a prompt to fix the code (or downgrade the row to `deviated`/`n/a`) and re-run `check --strict` — never a silent override of the deterministic gate.
+**Write the findings, then hand them to the operator.** Record the pass in `runward/governance/verify-findings.md`: a dated header (date, model used, manifests reviewed) and one line per `applied` row — `rule · finding · pointer · one-line reason`. A green `check --strict` surfaces this artifact's presence and freshness (stale once a gated manifest changes); it never reads a verdict out of it. The findings are input to the operator's gate decision, not a gate of their own. A `cited-not-applied` finding is a prompt to fix the code (or downgrade the row to `deviated`/`n/a`) and re-run `check --strict` — never a silent override of the deterministic gate.
 
 ## Definition of Done
 
 - Every `applied` row reviewed, with a confirmed / cited-not-applied / uncertain finding.
-- Findings handed to the operator; no exit code produced, no gate blocked.
+- Findings written to `runward/governance/verify-findings.md` (dated) and handed to the operator; no exit code produced, no gate blocked.
 - Any `cited-not-applied` finding routed back to the code and re-checked deterministically.
 
 ## Anti-patterns