@alphazede/bearing-lite 0.1.10 → 0.2.0

package/skills/bearing-lite/SKILL.md

@@ -3,51 +3,44 @@ name: bearing-lite
 description: Bearing Lite Router for Journeys. Not for ordinary work, assigned packets, implementation, or publication.
 ---
 
-The Router alone writes Journey planning state and owns owner conversation;
-planning nodes return owner questions. No second start confirmation, `.bearing`,
-or hidden ledger. plugin hosts are partial; skill-copy is skills-only.
+The Router alone writes Journey planning state, owns owner conversation, and owns Expedition sequencing;
+planning nodes return owner questions. Plugin hosts are partial; skill-copy is skills-only.
 
-1. Say `Preparing this Journey.` Inventory visible nonterminal Journeys; acquire or
-   resume a generation-bound checkout lease before any planning write or dispatch.
-   A live same-checkout competitor returns `WAITING_ON` with sanitized competing identity;
-   Distinct explicitly approved compatible worktrees may proceed.
-2. New Journey: recommend Explorer Journey or Expedition with reason; say when
-   the other fits. Ask exactly: `What Journey shall
-   we Embark on—an Explorer Journey or an Expedition?`
-3. On resume, keep the same lease generation and next incomplete stage. Parent-proven
-   same-Journey progress refreshes `candidate_revision` on that generation.
-   Never replay accepted stages or duplicate a dispatch.
-4. If `~/.agents/bearing-lite/default-role-lineup.md` is absent, create a
-   proposed copy from `templates/default-role-lineup.md`; confirm one role at a
-   time. Never infer identity values.
-5. Run one missing stage in order: Repository Fit → Set Bearings → Gather
-   Supplies. The Router holds every owner conversation inline; Gather Supplies
-   is a Router-led interview, never dispatched. Dispatch a fresh session only
-   for bounded mechanical legwork (mapping, drafting) after stage intent is
-   clear, on a cheaper lower-reasoning model than the Router; integrate returns.
-6. Before Map the Route, display each role's primary/fallback, model, reasoning,
-   and active/standby/unused state. Ask `Is this a
-   good lineup for the roles on this Journey?`; never choose. Recommend cadence
-   with a reason plus one cheaper and one more expensive alternative stating
-   what each gives up or buys. Ask `Where should the single independent
-   review run—after a slice, after an integrated round, or at the end?`
-7. Record route, lineup, and cadence before task mapping; if declined, record the named default explicitly.
-   The recorded snapshot is authoritative for this Journey. Later edits to
-   `~/.agents/bearing-lite/default-role-lineup.md` have no effect on it. Replace
-   only through an explicit owner-confirmed dated visible amendment. Invoke Map the Route with the snapshot.
-8. Every ready node gets a fresh session with lineup identity from the recorded snapshot.
+1. Say `Preparing this Journey.` Acquire or resume a generation-bound checkout lease before
+   planning or dispatch. A live same-checkout competitor returns `WAITING_ON` with sanitized identity.
+2. Resume the next incomplete stage in the same generation; refresh `candidate_revision`.
+   Never replay accepted stages or duplicate dispatch. Invalid leases fail closed.
+3. If `~/.agents/bearing-lite/default-role-lineup.md` is absent, create a
+   proposed copy; never infer identity values. The recorded snapshot is authoritative for this Journey.
+   Later edits to
+   `~/.agents/bearing-lite/default-role-lineup.md` have no effect on it except through an
+   explicit owner-confirmed dated visible amendment. Dispatch uses lineup identity from the recorded snapshot.
+4. Run Repository Fit → Set Bearings → Gather Supplies; unresolved material intent blocks Map the Route.
+5. Invoke Map the Route after settled intent. Do not ask for lineup or route
+   before it; carry owner-supplied lineup and `review_cadence: at-end` as proposals.
+   Follow `references/lineups.md` for catalog selection and save.
+6. Enforce `references/review-policy.md`. Show one integrated
+   approval-or-change gate for outcome, design, route, lineup, role states,
+   reasoning, cadence, and plan. Record the approved Journey type and snapshot; regenerate changes.
+   Never add a staged lineup or route-review gate.
+   Dispatch only after approval.
+7. Crewmate and Explorer may continue in-wave.
+   Use the visible wave receipt and update implementation and review once per wave.
 
-Return `READY`, `WAITING_ON`, `OWNER_DECISION_REQUIRED`, or `COMPLETE`. Fallback
-requires primary unavailability; both failing returns to owner. Allow three
-evidence-changing corrections outside assurance. `max_assurance_rounds` is 1
-per Journey; the sole review may authorize one repair. Direct route checks
-`assurance_rounds`; Navigator is not required. After repair, run deterministic
-coordinator verification and close the gate without another review. Failed repair
-or scope change returns `OWNER_DECISION_REQUIRED` naming the candidate and count.
-Only a separately scoped new Journey resets the review allowance.
-`COMPLETE` ends Bearing assurance: authorized deployment keeps deployment checks
-and rollback readiness without reopening review. Candidate-changing deployment
-work starts a new Journey. release the checkout lease exactly once on `COMPLETE`
-or `CANCELLED`. Recover by explicit recorded generation increment; it cannot steal a live lease.
-Process discovery cannot replace the lease. Never implement,
-self-assure, select models, or publish.
+Return `READY`, `WAITING_ON`, `OWNER_DECISION_REQUIRED`, or `COMPLETE`.
+`max_assurance_rounds` is 1 per declared phase or wave-end, not per Journey;
+Direct route checks `assurance_rounds`, never
+dispatch Navigator, and one review may authorize one repair. Verify repair
+deterministically without another review; failed repair/scope change returns
+`OWNER_DECISION_REQUIRED` naming the candidate and count. `COMPLETE` ends Bearing assurance.
+Authorized deployment without reopening review.
+Planning review is a separate pre-dispatch gate; it never consumes implementation
+`required_assurance`, `assurance_rounds`, or `max_assurance_rounds`.
+Release the lease once: release the checkout lease exactly once on `COMPLETE` or `CANCELLED`;
+recovery needs explicit recorded generation increment.
+Recovery cannot steal a live lease.
+Selected or required capabilities activate. Unavailability of selected-or-required
+capability is a typed capability gap, not success and not invented behavior.
+Selected-only missing and required-only missing are typed gaps. Unselected
+and unrequired absence remains inactive, not a global failure.
+Never implement, self-assure, select models, or publish.

package/skills/bearing-lite/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Bearing Lite"
   short_description: "Route a stateful repository Journey"
-  default_prompt: "Use $bearing-lite to start or resume this Journey, resolve planning one stage at a time, confirm the lineup and review cadence, then dispatch fresh bounded sessions."
+  default_prompt: "Use $bearing-lite to start or resume this Journey, resolve planning one stage at a time, confirm the lineup, record at-end review, then dispatch bounded sessions."
 
 policy:
   allow_implicit_invocation: false

package/skills/bearing-lite/references/assurance-policy.md

@@ -0,0 +1,66 @@
+# Assurance budget policy
+
+Decision source: `OWNER-EMV-REVIEW-CADENCE-UNIFICATION-001` through
+`ROUTER-EMV-CADENCE-IMPLEMENTATION-001`.
+
+The implementation assurance budget is scoped to each **declared phase or
+wave**, not to the Journey and not to a slice. Automatic review is dispatched
+at the end of each declared phase or wave. `hooks/assurance-budget.cjs` is the
+exact runtime mirror of the block below; the block is authoritative.
+
+```json
+{
+  "budget_scope": "per_declared_phase_or_wave",
+  "review_rounds": 1,
+  "aggregated_repairs_max": 1,
+  "post_repair_gate": "deterministic_PASS",
+  "automatic_phase_or_wave_end_review": "required",
+  "automatic_per_slice_review": "prohibited",
+  "post_repair_rereview": "prohibited",
+  "automatic_rereview_of_same_unit": "prohibited",
+  "budget_reset_on_candidate_change": false,
+  "budget_reset_on_model_change": false,
+  "budget_reset_on_harness_change": false,
+  "budget_reset_on_role_change": false,
+  "budget_reset_on_session_change": false,
+  "budget_reset_on_resume": false,
+  "budget_reset_on_alias_or_rename": false,
+  "budget_reset_condition": "next_distinct_declared_phase_or_wave_present_in_the_frozen_declaration"
+}
+```
+
+## Unit identity
+
+Budget identity is `journey + unit_kind + unit_id`. The unit id is resolved
+from the frozen declaration: `waves[].id`, else `phases[].phaseId`, else the
+single `direct` sentinel when neither is declared. A unit id absent from the
+frozen declaration fails closed as `undeclared_review_unit`; renaming a
+declared unit's display name never mints a fresh budget.
+
+The budget key
+records no route, provider, model, harness, account, or agent identity.
+Candidate revision, lease generation, assigned role, session, and
+slice id are likewise never key components, and none of them lowers a spent
+count.
+
+## Spending the budget
+
+- One review round per declared phase or wave. A second round on the same unit
+  halts with `assurance_round_limit`.
+- A repairable verdict permits at most one aggregate repair. A second repair
+  halts with `assurance_repair_limit`.
+- After that repair the coordinator closes the unit on a deterministic `PASS`
+  gate; a missing or non-`PASS` gate halts with
+  `deterministic_post_repair_gate_required`.
+- The repaired unit is never reviewed again. `automatic_rereview_requested` and
+  `review_after_repair` both require an owner amendment.
+- A transport receipt of `WAITING_ON` or `UNAVAILABLE` is not a spent round; it
+  returns `NEEDS_MORE_EVIDENCE`.
+- The next distinct declared phase or wave carries its own budget.
+
+## Planning review stays separate
+
+Planning review is a separate pre-dispatch gate with its own 1/1 allowance in
+`references/review-policy.md`. It never consumes implementation
+`required_assurance`, `assurance_rounds`, or `max_assurance_rounds`, and this
+budget never consumes the planning gate.

package/skills/bearing-lite/references/lineups.md

@@ -0,0 +1,81 @@
+# Named lineup catalog
+
+Candidate procedure for the user-owned JSON catalog. It is not a staged
+lineup or route-review gate. Selection is not an authority grant.
+
+## Location
+
+The live user catalog is exactly one file:
+
+`<absolute home>/.agents/bearing-lite/lineups.json`
+
+Resolve `<absolute home>` as a nonempty absolute `HOME`, else a nonempty
+absolute `USERPROFILE` on its platform; otherwise fail closed with
+`home_unresolved`. Do not use cwd, the package root, XDG, a relative
+`lineups.json`, or a second search root.
+
+The packaged catalog is package-root `lineups.json`. Never read it as user
+data. Never write the packaged catalog, including resolved symlink aliases
+of that file.
+
+Missing user file means no named profiles. Do not auto-create the live
+catalog. An empty `lineups` object is valid and is not an error. A
+malformed unused catalog cannot override explicit inline owner choices.
+
+## Validity
+
+Named selection and save require a valid catalog. Bind
+`schemas/lineups.schema.json` Draft 2020-12 validation before named
+selection or save. That schema is the validation document, not a second
+search root for user data. Do not add a runtime catalog library.
+
+On load and on save, inspect raw object members first. Reject duplicate
+raw JSON keys; do not silently collapse. Then parse and apply Draft 2020-12
+validation against package-root `schemas/lineups.schema.json`. Fail closed
+as follows even when the schema cannot express the check:
+
+- Reject duplicate role assignments within each phase.
+- Reject ASCII case-fold collisions on both load and save. Do not trim
+  or case-fold names.
+- Defaults keys must resolve exactly. Unresolved defaults fail closed.
+- Invalid structure or name fails closed on both load and save.
+
+Refuse named selection or save on any of those failures. Do not invent a
+fallback profile and do not read packaged bytes as user data.
+
+## Selection
+
+Explicit inline owner choices require no catalog lookup and no extra
+confirmation. Consume them as already explicit.
+
+A named choice needs a valid catalog and an exact selected key. Do not trim
+or case-fold the name. Independent planning and implementation selections
+remain separate; the owner may pick two names, one name twice, or inline on
+either side.
+
+Optional user `defaults.planning` and `defaults.implementation` are
+recommendations requiring selection or confirmation. They are never a silent
+grant and not an authority grant. Do not apply them without that
+confirmation. Do not invent a packaged default.
+
+Copy selected entries into the Journey snapshot as a frozen snapshot copy.
+Preserve fallback array order. Bind a SHA-256 configuration digest of that
+frozen snapshot copy. Digest that copy only: selected entries with fallback
+order and selection sources. Exclude N/K/C, review cadence, route, and
+authority. Canonical JSON: UTF-8, sort_keys, compact separators.
+Later catalog edits do not mutate the frozen snapshot copy or its digest.
+
+## Save
+
+Save only on explicit owner request. Never save this Journey as a side
+effect of selection, freeze, or routing.
+
+Create versus replace: if replace is already explicit, do not ask again;
+otherwise preview the selected-entry replacement and confirm. Create must
+not overwrite an existing exact key. Replace updates only that key.
+
+Preserve unrelated valid keys and defaults. Refuse changed-input overwrite.
+Use a safe atomic update (sibling temp file, then rename).
+
+Do not write N/K/C, review cadence, route, or authority into catalog
+entries.

package/skills/bearing-lite/references/peer-synthesis.md

@@ -10,10 +10,14 @@ copy peer text, runtimes, state stores, or authority assumptions.
 | Repository Fit | [Kiro steering](https://kiro.dev/docs/steering/) | verified workspace and explicit global/workspace scope |
 | Set Bearings | [Kiro steering](https://kiro.dev/docs/steering/) | durable human-readable workspace context |
 | Gather Supplies | [Matt Pocock grilling](https://github.com/mattpocock/skills/blob/main/skills/productivity/grilling/SKILL.md) | relentless dependency-ordered interview, one recommended question at a time |
-| Map the Route | [Kiro Quick Spec](https://kiro.dev/docs/specs/quick-spec/) and [GitHub Spec Kit](https://github.com/github/spec-kit/blob/main/workflows/speckit/workflow.yml) | staged requirements/design/tasks and explicit gates |
-| Navigator | LangChain subagents | central sequencing, context isolation, and conflict-aware wave integration |
+| Map the Route | [Kiro Quick Spec](https://kiro.dev/docs/specs/quick-spec/) and [GitHub Spec Kit](https://github.com/github/spec-kit/blob/main/workflows/speckit/workflow.yml) | technical-plan, design.md, seit.json, implementation.json, two-state review.html |
+| Navigator | compatibility diagnostic | unused on new Journeys; Router owns sequencing |
 | Explorer | LangChain subagents | bounded worker dispatch, proven-independent lane coordination, and result integration |
-| Crewmate | Spec Kit implement step | bounded execution after approved planning |
-| Validator | Spec Kit gate | evidence gate on a stable candidate |
+| Crewmate | Spec Kit implement step | bounded execution after approved planning; split test-writing versus product |
+| Scribe | event side lane | transcribes; cannot activate authority |
+| Plan Integrator | Spec Kit tasks gate | reconciles five artifacts; generates implementation.json and review.html |
+| Systems Modeler | MBSE view selection | after requirements; before design finalization |
+| Integration Engineer | assembly method | dual planning and execution sessions |
+| Test Engineer | Spec Kit gate | Planning and Assurance sessions; Validator absent from active roles |
 | Park Ranger | LangChain reviewer subagent | independent defect review with a typed return |
 | Surveyor | Spec Kit review gate | outcome comparison before completion |

package/skills/bearing-lite/references/review-policy.md

@@ -0,0 +1,37 @@
+# Planning review policy
+
+This machine-readable block is the single declarative authority for
+planning-review constraints. `hooks/planning-review.cjs` exports its runtime
+mirror; focused tests require an exact match. Changing these bounds needs
+an explicit owner amendment. This policy records no route, provider, model,
+harness, account, or agent identity.
+
+```json
+{
+  "reviewer_slots_min": 2,
+  "reviewer_slots_max": 2,
+  "independence_required": true,
+  "isolated_findings_until_aggregation": true,
+  "candidate_fields": ["candidate_ref", "candidate_revision", "candidate_digest"],
+  "shared_candidate_required": true,
+  "review_rounds": 1,
+  "aggregated_repairs_max": 1,
+  "post_repair_gate": "deterministic_PASS",
+  "automatic_rereview": "prohibited",
+  "slot_exhaustion_outcome": "FAIL_ROUND",
+  "terminal_outcomes": ["HALT", "OWNER_AMENDMENT_REQUIRED"]
+}
+```
+
+Map the Route writes the separate Journey binding in the approved lineup
+snapshot. It lists unique abstract `slot_id` values, each slot's owner-selected
+`primary_route_ref`, and ordered `fallback_route_refs`. Each receipt records a
+distinct selected route from its slot. All receipts bind to the same non-empty
+candidate ref, revision, and digest. Exhausting any slot
+returns `FAIL_ROUND`. Candidate or independence mismatch, a second round or
+repair, or a missing deterministic PASS after repair returns `HALT`. Automatic
+confirmation or rereview returns `OWNER_AMENDMENT_REQUIRED`.
+
+This gate reviews planning artifacts before dispatch. It never invokes a
+reviewer. Implementation assurance remains governed separately by
+`max_assurance_rounds` and task `required_assurance` / `assurance_rounds`.

package/skills/bearing-lite/references/role-routing.mmd

@@ -1,21 +1,21 @@
 flowchart TD
     O[Owner Authority] <--> R[Stateful Bearing Lite Router]
-    R --> J{Explorer Journey or Expedition?}
     R --> P{Next missing planning stage?}
     P -->|Repository Fit| PF[Fresh Repository Fit]
     P -->|Set Bearings| SB[Fresh Set Bearings]
     P -->|Gather Supplies| GS[Fresh Gather Supplies]
     P -->|Map the Route| MR[Fresh Map the Route]
-    PF & SB & GS & MR -->|typed return| R
-    R --> L[Owner confirms lineup and review cadence]
-    J -->|Explorer Journey: one packet| C[Fresh Crewmate]
-    J -->|Explorer Journey: one wave| E[Fresh Explorer]
-    J -->|Expedition| N[Fresh Navigator]
-    N --> E
+    PF & SB & GS -->|typed return| R
+    R --> MR
+    MR -->|five artifacts with proposed route, lineup, role states, reasoning, cadence| I{One integrated owner review}
+    I -->|change| MR
+    I -->|approve Explorer Journey: one packet| C[Crewmate may continue in-wave]
+    I -->|approve Explorer Journey: one wave| E[Explorer may continue in-wave]
+    I -->|approve Expedition: Router sequences waves| E
     E --> C
-    C --> A{Selected cadence boundary?}
-    A -->|Validator declared| V[Fresh Validator]
+    C --> A{Declared phase or wave end candidate?}
+    A -->|Assurance Test Engineer declared| V[Fresh Assurance Test Engineer]
     A -->|Park Ranger declared| PK[Fresh Park Ranger]
     A -->|Surveyor declared| S[Fresh Surveyor]
     A -->|not yet| E
-    V & PK & S -->|typed verdict| R
+    V & PK & S -->|compact receipt| R

package/skills/bearing-lite/references/task-state.md

@@ -11,10 +11,10 @@ The project's human-readable plan is the only task-state record. Diagrams explai
 | `WAITING_ON` | Parent coordinator | Named prerequisite, checkout-lease conflict, or independent-assurance dispatch unavailable |
 | `IN_PROGRESS` | Assigned worker or coordinator | Assigned action is being performed |
 | `EVIDENCE_READY` | Parent coordinator | Candidate and evidence ready for next missing assurance |
-| `VALIDATING` | Validator | Evidence sufficiency under validation |
+| `VALIDATING` | Assurance Test Engineer | Evidence sufficiency under validation |
 | `REVIEWING` | Park Ranger when required | Independent defect review active |
 | `ACCEPTANCE` | Surveyor, Owner Authority, or parent coordinator when `required_assurance` is `none` | User-facing acceptance or coordinator completion confirmation is active |
-| `CORRECTION_REQUIRED` | Navigator or nearest parent coordinator | Agent-owned in-authority correction required |
+| `CORRECTION_REQUIRED` | Router or nearest parent coordinator | Agent-owned in-authority correction required |
 | `OWNER_DECISION_REQUIRED` | Owner Authority | Authority, scope, security, or replacement-path judgment required |
 | `COMPLETE` | Parent coordinator after assurance | Outcome and required assurance satisfied |
 | `CANCELLED` | Owner Authority or authorized parent | Task will not proceed |
@@ -27,7 +27,7 @@ The project's human-readable plan is the only task-state record. Diagrams explai
 - `IN_PROGRESS` → `EVIDENCE_READY` with candidate and handoff; → `CORRECTION_REQUIRED` on correctable failure; → `OWNER_DECISION_REQUIRED` on security, authority, or integrity guard.
 - `CORRECTION_REQUIRED` → `READY` on attempt 1 or 2 with a new hypothesis and evidence; → `OWNER_DECISION_REQUIRED` on the third failed correction or out-of-contract amendment.
 - `EVIDENCE_READY` → `VALIDATING` | `REVIEWING` | `ACCEPTANCE` for the next missing required role; → `WAITING_ON` if assurance dispatch is unavailable.
-- During the single assurance round, an accepted Validator or Park Ranger handoff returns to `EVIDENCE_READY` to select the next missing assurance role in declared order.
+- During the single assurance round, an accepted Assurance Test Engineer or Park Ranger handoff returns to `EVIDENCE_READY` to select the next missing assurance role in declared order.
 - `VALIDATING` → `CORRECTION_REQUIRED` when more evidence or repair is needed; otherwise back through `EVIDENCE_READY` for remaining assurance.
 - `REVIEWING` → `CORRECTION_REQUIRED` | `EVIDENCE_READY` | `OWNER_DECISION_REQUIRED` by verdict.
 - `ACCEPTANCE` → `COMPLETE` when every required assurance accepted the same candidate; when `required_assurance` is `none`, parent-coordinator confirmation satisfies the assurance requirement; → `CORRECTION_REQUIRED` on acceptance gap.
@@ -36,11 +36,11 @@ The project's human-readable plan is the only task-state record. Diagrams explai
 ## Ownership rules
 
 - One parent coordinator writes each task block and its transitions.
-- Navigator alone writes cross-wave dependencies and Expedition-wide sequencing.
+- Router alone writes cross-wave dependencies and Expedition-wide sequencing.
 - Workers and assurance roles return handoffs; they do not race plan edits.
-- Candidate authors never provide their own Validator, Park Ranger, or Surveyor verdict.
+- Candidate authors never provide their own Assurance Test Engineer, Park Ranger, or Surveyor verdict.
 - Waiting on a prerequisite consumes no correction attempt. Each task has its own three-attempt correction counter; identical retries without new evidence are invalid.
-- One Journey receives at most one assurance round and one review-directed repair. Replacement candidates do not reset the count. The coordinator verifies that repair deterministically and does not dispatch assurance again.
+- Each declared phase or wave receives at most one assurance round and one review-directed repair. Replacement candidates do not reset the count within that declared unit; the next distinct declared phase or wave carries its own 1/1 budget. The coordinator verifies that repair deterministically and does not dispatch assurance again.
 - `COMPLETE` is terminal for Bearing assurance. An already authorized deployment keeps operational verification and rollback readiness but does not reopen review; candidate-changing deployment work requires separate scope.
 
 ## Checkout lease

package/skills/bearing-lite/references/task-state.mmd

@@ -12,7 +12,7 @@ stateDiagram-v2
     IN_PROGRESS --> OWNER_DECISION_REQUIRED
     CORRECTION_REQUIRED --> READY
     CORRECTION_REQUIRED --> OWNER_DECISION_REQUIRED: third failed correction
-    EVIDENCE_READY --> VALIDATING: Validator required
+    EVIDENCE_READY --> VALIDATING: Assurance Test Engineer required
     EVIDENCE_READY --> REVIEWING: Park Ranger required
     EVIDENCE_READY --> ACCEPTANCE: Surveyor, owner, or coordinator when required_assurance is none
     EVIDENCE_READY --> WAITING_ON: assurance dispatch unavailable

package/skills/bearing-lite/templates/default-role-lineup.md

@@ -6,19 +6,27 @@ implementation and asks whether it is good for the current Journey. Never fill
 agent, model, or reasoning values on the user's behalf.
 
 ```markdown
-review_cadence: <per-slice | per-round | at-end>
+review_cadence: at-end
 
 | Role | Primary agent/harness | Primary model | Primary reasoning | Fallback agent/harness | Fallback model | Fallback reasoning |
 | --- | --- | --- | --- | --- | --- | --- |
 | Router | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
-| Navigator | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
 | Explorer | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
 | Crewmate | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
-| Validator | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
+| Test Engineer | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
+| Scribe | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
+| Plan Integrator | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
+| Systems Modeler | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
+| Integration Engineer | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
 | Park Ranger | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
 | Surveyor | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
 ```
 
+Navigator is not a normal lineup role. Existing plans that still assign it use
+the Navigator compatibility diagnostic; treat the assignment as unused.
+Validator is not a normal lineup role. Existing plans that still assign it use
+the Validator compatibility diagnostic; treat the assignment as unused.
+
 Journey artifacts copy the confirmed values and mark named instances active,
 standby, or unused. Only verified primary unavailability activates its approved
 fallback. If both are unavailable, return `OWNER_DECISION_REQUIRED`.

package/skills/bearing-lite/templates/task.md

@@ -2,29 +2,54 @@
 
 Use one compact Markdown block per task in the project's existing plan or progress document. Omit unused conditional fields. Prefer the project's format; add only missing fields. Do not create a Bearing-owned state file or hidden ledger.
 
-## Journey settings (record before task mapping)
+## Journey settings
 
-Record these plan-level choices once, above the task blocks:
+Map the Route records these plan-level proposals above the task blocks in the
+complete five-artifact package. The integrated owner review approves or changes
+the journey, lineup, role states, reasoning, cadence, and plan together; no
+pre-Map lineup or route-review gate is allowed.
 
 ```markdown
 - journey: <Explorer Journey | Expedition>
-- review_cadence: <per-slice | per-round | at-end>
-- choice_basis: <owner-confirmed recommendation and reason>
-- lineup_snapshot: <named active, standby, and unused role instances>
+- review_cadence: at-end
+- choice_basis: <proposed recommendation and reason; owner-approved at integrated review>
+- lineup_snapshot: <named implementation/assurance instances plus the planning_review binding below>
+- planning_review:
+  - policy_ref: skills/bearing-lite/references/review-policy.md
+  - candidate_ref: <shared planning-package reference>
+  - candidate_revision: <shared planning-package revision>
+  - candidate_digest: <shared planning-package digest>
+  - reviewer_slots:
+    - slot_id: <abstract unique slot>
+      primary_route_ref: <owner-selected lineup route reference>
+      fallback_route_refs: [<ordered owner-selected route references>]
+  - round_number: 1
+  - completed_rounds: <0-1>
+  - receipts: <one isolated receipt per slot, including the distinct selected_route_ref>
+  - aggregated_repairs: <0-1>
+  - deterministic_gate: <PASS after repair; otherwise omitted>
 ```
 
-`review_cadence` selects where the Journey's single independent review runs,
-not task-level tests or author self-checks. Never infer it from
-`required_assurance` on an individual task. `per-slice` and `per-round` select
-one declared boundary; `at-end` selects the final integrated candidate. The
-Router asks the owner to confirm both the applicable lineup and boundary before
-implementation.
-`lineup_snapshot` is authoritative for this Journey after recording. Later
+`review_cadence` is `at-end` for each declared phase or wave. The single
+independent review runs on that unit's integrated candidate at its end, not at
+a slice or round boundary, and not as
+task-level tests or author self-checks. Never infer it from
+`required_assurance` on an individual task. The proposal is visible in
+`implementation.json` and `review.html`, then becomes authoritative only after
+the integrated owner approval; do not offer `per-slice` or `per-round`.
+`journey` stays a proposal until the mapped implementation graph exists and the
+integrated owner review approves it. `lineup_snapshot` is authoritative after
+that approval. Later
 edits to `~/.agents/bearing-lite/default-role-lineup.md` have no effect.
 Replace it only through an explicit owner-confirmed dated visible amendment.
 Record the amendment date beside the replacement values. Dispatch identities
 come from this snapshot, not from the current global defaults file.
 
+Every configured planning-review slot uses the same candidate ref, revision,
+and digest. Findings stay isolated until one aggregation. Slot exhaustion is
+`FAIL_ROUND`; policy violations halt or require an owner amendment. The binding
+does not populate `required_assurance` and does not dispatch reviewers.
+
 ## Checkout lease (record before any planning write)
 
 The Router's first write is this visible lease. Inventory nonterminal Journeys
@@ -53,6 +78,26 @@ same generation. `COMPLETE` or `CANCELLED` releases the lease exactly
 once. Stale recovery is explicit, recorded, increments generation, and cannot
 steal a live lease. Process discovery cannot replace this durable lease.
 
+## Wave receipt (record at wave start)
+
+Continuations reuse this visible record beside the checkout lease. Validate at
+wave start, after detected drift, and before commit — not before every
+mutation. Resume from it; do not reread every accepted artifact or redispatch
+completed slices.
+
+```markdown
+- wave_receipt:
+  - wave: <wave id>
+  - lease_generation: <generation>
+  - branch: <branch>
+  - candidate_revision: <revision at last check>
+  - authority: <envelope>
+  - checked_at: <wave_start | external_change | commit>
+```
+
+Stale, forged, or drifted receipts fail closed. Changed HEAD, authority,
+generation, route, or writer overlap forces revalidation or a fresh session.
+
 ## Always present
 
 ```markdown
@@ -67,7 +112,7 @@ steal a live lease. Process discovery cannot replace this durable lease.
 Field rules:
 
 - `task_id` — stable identifier unique within the plan.
-- `outcome` — approved intent for this task only.
+- `outcome` — approved intent for this task only. Never a role-return token and never copied into `verdict`.
 - `status` — one of `PROPOSED`, `READY`, `WAITING_ON`, `IN_PROGRESS`, `EVIDENCE_READY`, `VALIDATING`, `REVIEWING`, `ACCEPTANCE`, `CORRECTION_REQUIRED`, `OWNER_DECISION_REQUIRED`, `COMPLETE`, `CANCELLED`.
 - `assigned_role` — current role contract for the active step, or unassigned while proposing.
 - `depends_on` — list of other `task_id` values only, never prose.
@@ -78,23 +123,32 @@ Field rules:
 ```markdown
 - scope: <allowed paths, systems, and boundaries>
 - authority: <approved envelope; protected actions remain owner-only>
-- required_assurance: [Validator]
+- required_assurance: [Assurance Test Engineer]
 ```
 
-`required_assurance` lists only roles that must accept the same candidate (for example `Validator`, and `Park Ranger` or `Surveyor` when their triggers apply).
+`required_assurance` lists only roles that must accept the same candidate (for example `Assurance Test Engineer`, and `Park Ranger` or `Surveyor` when their triggers apply).
+
+test-writing Crewmate write set is tests and approved fixtures only. Product
+write set excludes tests and must not weaken independently authored tests.
+Neither self-certifies.
 
 ## After candidate work (add when evidence exists)
 
 ```markdown
 - candidate_ref: <strongest native revision or changed-path reference available>
-- evidence: <commands run, results observed, and inferences labeled separately>
-- assurance_rounds: <0-1 completed assurance rounds for this Journey>
+- changed_paths: <paths changed in this candidate>
+- tests: <commands run and observed results>
+- findings: <labeled inferences and gaps>
+- verdict: <closed role-return token>
+- assurance_rounds: <0-1 completed assurance rounds for this declared phase or wave>
 ```
 
+`verdict` is one of `ACCEPT`, `ACCEPT_WITH_FINDINGS`, `BLOCK`, `CANDIDATE_READY`, `FAIL`, `GAPS`, `NEEDS_MORE_EVIDENCE`, `OWNER_DECISION_REQUIRED`, `PARTIAL`, `PASS`, `READY`, `REPAIR_REQUIRED`, `REROUTED`, `WAITING_ON`. Do not copy task `outcome` into `verdict`.
 `candidate_ref` must not claim stronger provenance than the client can prove.
-`assurance_rounds` counts the Journey's single submission to required assurance
-against Bearing Lite `max_assurance_rounds`. A repair or replacement candidate
-does not reset it; only a separately scoped new Journey starts at 0. The parent
+`assurance_rounds` counts this declared phase or wave's single submission to
+required assurance against Bearing Lite `max_assurance_rounds`. A repair or
+replacement candidate does not reset it; the next distinct declared phase or
+wave carries its own budget. The parent
 coordinator writes the count before dispatch. If the review permits correction, spend at
 most one remaining `attempts` repair, run deterministic coordinator verification,
 and close the gate without another review. A failed repair or scope change
@@ -115,4 +169,4 @@ review. Any source or candidate change during deployment is separately scoped.
 
 ## Single-writer reminder
 
-Only the parent coordinator updates this block after rereading it. Crewmate, Validator, Park Ranger, and Surveyor return handoffs; the coordinator records transitions. Navigator alone changes cross-wave dependencies or global sequencing.
+Only the parent coordinator updates this block after rereading it. Crewmate, Test Engineer, Park Ranger, and Surveyor return compact receipts (`verdict`, `candidate_ref`, `changed_paths`, `tests`, `findings`, `blocker`); the coordinator records transitions. Router alone changes cross-wave dependencies or global sequencing. Update `implementation.json` and `review.html` once per wave, plus owner-decision or blocker changes.