@alphazede/bearing-lite 0.1.11 → 0.2.0

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 |
+| 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/role-routing.mmd

@@ -13,8 +13,8 @@ flowchart TD
     I -->|approve Explorer Journey: one wave| E[Explorer may continue in-wave]
     I -->|approve Expedition: Router sequences waves| E
     E --> C
-    C --> A{Final integrated candidate at-end?}
-    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

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

@@ -11,7 +11,7 @@ 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` | Router or nearest parent coordinator | Agent-owned in-authority correction required |
@@ -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.
@@ -38,9 +38,9 @@ The project's human-readable plan is the only task-state record. Diagrams explai
 - One parent coordinator writes each task block and its transitions.
 - 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

@@ -13,13 +13,19 @@ review_cadence: at-end
 | Router | 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

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

@@ -30,11 +30,12 @@ pre-Map lineup or route-review gate is allowed.
   - deterministic_gate: <PASS after repair; otherwise omitted>
 ```
 
-`review_cadence` is `at-end` only. The single independent review runs on the
-final integrated candidate, not at a slice or round boundary, and not as
+`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.md` and `review.html`, then becomes authoritative only after
+`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
@@ -122,10 +123,14 @@ 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)
 
@@ -135,14 +140,15 @@ Field rules:
 - 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 Journey>
+- 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, materially changed new Journey starts at 0, and a new Journey is not a way around the bound. 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
@@ -163,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 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.md` and `review.html` once per wave, plus owner-decision or blocker changes.
+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.

package/skills/crewmate/SKILL.md

@@ -20,6 +20,9 @@ Lowest mutation authority and highest hands-on work in the Bearing ladder.
 - **Match:** one packet is `READY` and every input is fixed.
 - **Non-match:** multi-packet coordination, design gaps, missing authority,
   assurance, or owner-only action.
+- **Split:** test-writing Crewmate may change only tests and approved
+  fixtures. Product Crewmate write set excludes tests and must not weaken
+  independently authored tests. Neither self-certifies.
 
 ## Algorithm
 

package/skills/explorer/SKILL.md

@@ -40,14 +40,15 @@ Wave authority. Coordinates more and implements less than Crewmate.
    conversation history. Independent work, a changed envelope, or owner choice
    starts a fresh Crewmate.
 4. Inspect compact returns against write sets and acceptance; integrate
-   evidence without implementing. Update `implementation.md` and `review.html`
+   evidence without implementing. Update `implementation.json` and `review.html`
    once per wave, plus owner-decision or blocker changes.
-5. Dispatch declared assurance only at-end on the final integrated candidate.
-   Expedition waves defer assurance to the Router's final Journey boundary.
-   Deterministic checks always run. Honor `max_assurance_rounds` of 1 from
-   visible `assurance_rounds`. If the review is repairable, spend at most one
+5. Dispatch declared assurance automatically at wave-end on this wave's
+   integrated candidate. Deterministic checks always run. Honor
+   `max_assurance_rounds` of 1 per declared phase or wave from visible
+   `assurance_rounds`. If the review is repairable, spend at most one
    remaining `attempts` repair, run deterministic coordinator verification,
-   and close the gate without another review. A failed repair or scope change
+   and close the gate without another review. The next distinct declared
+   phase or wave carries its own budget. A failed repair or scope change
    returns `OWNER_DECISION_REQUIRED` with candidate and count. After Journey
    `COMPLETE`, deployment checks do not reopen assurance.
 

package/skills/gather-supplies/SKILL.md

@@ -25,7 +25,13 @@ Planning node, not a persona or plan-state writer.
 ## Algorithm
 
 1. Inspect the repository and available evidence before asking. Never ask the
-   owner for a fact tools can establish.
+   owner for a fact tools can establish. Maintain a coverage ledger from
+   required roles and artifacts. Cells are `DISCOVERABLE`, `OPEN`, `DECIDED`,
+   `DEFERRED`, `NOT_APPLICABLE`, or `BLOCKED`. Exit is falsifiable: zero
+   `OPEN`; `DECIDED` cites owner decision and source; `DEFERRED` has a bounded
+   owner-approved destination or trigger; `NOT_APPLICABLE` has a reason;
+   `BLOCKED` is surfaced. Planning is a fan-out/fan-in DAG with Scribe as an
+   event side lane.
 2. Select the earliest unresolved decision whose dependencies are satisfied.
 3. Ask exactly one question, relayed to the owner through the Router. Lead
    with the recommended answer and why, then explain only material

package/skills/integration-engineer/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: integration-engineer
+description: >
+  Dual-session Integration Engineer for planning assembly strategy and
+  execution assembly of the exact integrated candidate. Use for Planning
+  Integration Engineer or Execution Integration Engineer. Do not
+  implement missing product behavior or self-certify.
+---
+
+# Integration Engineer
+
+Planning and execution sessions are separate because authority differs.
+
+## Inputs and match
+
+- **Inputs:** items/versions, compatibility, order, entry criteria,
+  configuration identity, authorized glue, interfaces.
+- **Match:** progressive assembly is required.
+- **Non-match:** product implementation, requirement rewrite, test
+  authorship.
+
+## Algorithm
+
+1. Planning Integration Engineer defines items/versions, compatibility,
+   order, entry criteria, stubs, configuration identity, post-step V&V
+   handoffs, anomaly/rollback/recovery, and the final integrated
+   candidate after requirements, views, and design interfaces stabilize.
+2. Execution Integration Engineer confirms identities and readiness,
+   assembles approved elements, applies only authorized integration
+   glue, exercises interfaces, records anomalies or rollback, produces
+   the exact integrated candidate, and hands to Assurance Test Engineer.
+3. Missing Integration Engineering method skill is a typed capability
+   gap, not invented behavior.
+
+## Return and recovery
+
+Return `CANDIDATE_READY` or `OWNER_DECISION_REQUIRED` with verdict,
+candidate_ref, changed_paths, tests, findings, and blocker.
+
+Never implement missing product, revise requirements or design, weaken
+tests, or self-certify.

package/skills/map-the-route/SKILL.md

@@ -13,35 +13,36 @@ Fresh planning node. The Router writes Journey state and owns owner conversation
 
 ## Match, inputs, and non-match
 
-- **Match:** material intent is settled and any specification, design, SEIT,
+- **Match:** material intent is settled and any technical-plan, design, SEIT,
   implementation graph, or review HTML is missing.
 - **Inputs:** confirmed decisions, repository map and evidence, artifact status,
   requirements register, repository rules, proposed owner-supplied lineup and
   `review_cadence: at-end`, plus the return schema.
 - **Non-match:** unresolved material scope, behavior, authority, risk, or
   acceptance intent returns `REROUTE_GATHER_SUPPLIES`; generate no
-  `implementation.md` or `review.html`.
+  `implementation.json` or `review.html`.
 
 ## Procedure
 
-1. Derive `<journey-topic>-spec.md` from the confirmed title; ask only on
+1. Derive `<journey-topic>-technical-plan.md` from the confirmed title; ask only on
    ambiguity or collision. Establish whether a requirements register exists;
    if repository evidence cannot decide, return `NEEDS_OWNER_DECISION`. Never
    infer one. Registered identities remain references; author only Journey-local
    criteria; author the needed Journey-level proof or return
    `NEEDS_OWNER_DECISION` when register authority is unclear.
 2. Author and prospectively check, in dependency order, the testable
-   specification, `design.md`, and `seit.md`. Preserve IDs and do not drop
+   technical-plan, `design.md`, and `seit.json`. Preserve IDs and do not drop
    Journey-level proof or published-standard clause coverage.
 3. Map the implementation graph and propose the Explorer Journey or Expedition,
    active/standby/unused role states, lineup, reasoning, and
    `review_cadence: at-end`. Bind the planning-review slots to owner-supplied
    primary and ordered fallback route references under one candidate ref,
    revision, and digest. Use supplied identities; never invent them.
-4. After those stable source inputs, generate `implementation.md` and the
+4. After those stable source inputs, generate `implementation.json` and the
    self-contained offline `review.html` together. Each includes the proposed
    route, lineup, role states, reasoning, cadence, traceability, waves,
-   recovery, approval boundaries, and register references versus Journey-local requirements.
+   recovery, approval boundaries, and register references versus Journey-local
+   requirements. Two `review.html` states: `planning-review` and `final-closeout`.
 5. Give every slice stable requirement/design/SEIT IDs, dependencies, exact
    write set, authority, role, session rule, evidence, recovery, and stop rule.
 6. Open and verify final HTML, then request exactly one integrated owner review

package/skills/map-the-route/references/artifact-grammar.md

@@ -3,18 +3,26 @@
 Apply this closed grammar while authoring or validating planning artifacts.
 Bearing rejects deviations with typed findings.
 
+The canonical Journey planning artifacts are exactly
+`<journey-topic>-technical-plan.md` with `type: technical-plan`, `design.md`,
+`seit.json`, `implementation.json`, and `review.html`. Markdown carries
+technical-plan and design reasoning; the JSON files are schema-validated
+machine authorities; `review.html` is their complete integrated human
+projection. There is no sixth canonical planning artifact. XLSX may be an
+optional derived export and is never authority.
+
 ## Shared artifact rules
 
-1. Frontmatter declares `type` as `plan-spec`, `design`, `seit`, or
-   `implementation`, and `status` as `complete` or `amended`.
+1. Frontmatter declares `type` as `technical-plan` or `design`, and `status` as
+   `complete` or `amended`.
 2. Journey-authored requirement IDs use `AC-*` or `RISK-*`; references to an
    existing requirements register keep that register's identities verbatim.
    Design IDs use `DES-*` or `CONTRACT-*`; SEIT rows use `SEIT-*`; commands
    use `CMD-*` or `PROC-*`. Suffixes contain only uppercase letters, digits,
    dots, or hyphens.
-3. `<journey-topic>-spec.md` declares requirements, Entry criteria, Exit criteria,
-   Rollback or repair, and Accountable controller. `design.md` declares design
-   IDs. `seit.md` declares SEIT rows and commands.
+3. `<journey-topic>-technical-plan.md` declares requirements, Entry criteria,
+   Exit criteria, Rollback or repair, and Accountable controller. `design.md`
+   declares design IDs. `seit.json` declares SEIT rows and commands.
 4. Preserve stable IDs. Every implementation reference resolves to a declared
    requirement, design contract, SEIT row, and command.
 5. Owner-supplied lineup identities and proposed `review_cadence: at-end` are
@@ -39,7 +47,7 @@ Bearing rejects deviations with typed findings.
    to registered identities (no restated text), derivations from them
    (`AC-X derives from REG-ID`), or Journey-local `AC-*`/`RISK-*` criteria about
    write sets, seams, gates, or concurrency. Do not restate registered content.
-4. `seit.md` references verification allocations where the register provides
+4. `seit.json` references verification allocations where the register provides
    them. Where the register provides none for a referenced requirement, author
    Journey-level proof for it or return `NEEDS_OWNER_DECISION` when register
    authority is unclear; do not silently drop coverage. Journey-level proof
@@ -59,37 +67,44 @@ Bearing rejects deviations with typed findings.
 
 ## SEIT rules
 
-1. Include non-empty `Required Commands`, `Traceability Matrix`, and
-   `Cross-cutting Checks` sections.
-2. Declare each command as `- **<CMD/PROC-id>** — description`.
-3. Use one flat traceability table with exactly these columns: SEIT row ID |
+1. `seit.json` is the canonical JSON Schema-validated tailored V&V plan.
+   Always-on sections: scope/baseline; responsibility/change authority;
+   applicable documents/precedence; requirements flowdown/architecture context;
+   V&V methods; verification and validation matrices; levels/integration
+   sequence; environments/fixtures/data/simulations/support;
+   procedures/commands; evidence/pass-fail; anomaly/corrective/closure.
+   System fields only where applicable.
+2. Include non-empty `Required Commands`, `Traceability Matrix`, and
+   `Cross-cutting Checks` sections or JSON equivalents.
+3. Declare each command with a `CMD-*` or `PROC-*` id and description.
+4. Use one flat traceability table with exactly these columns: SEIT row ID |
    Acceptance/risk ID | Design/contract ID | Boundary/test layer | Positive
    case | Negative/failure case | Command/procedure ID | Evidence.
-4. Every row carries exactly one SEIT row ID, requirement ID, design ID, and
+5. Every row carries exactly one SEIT row ID, requirement ID, design ID, and
    command ID, and names an observable failure.
-5. If procedure narratives are used, title each `### SEIT-<id> <title>` under
-   a procedures section and restate Command, Positive case, Negative case, and
-   Evidence exactly. Every PROC row then has exactly one matching narrative.
+6. Bind a stable decision-baseline projection of confirmed decision identities
+   and open-item statuses rather than the whole-file `journey.json` digest.
 
 ## Implementation rules
 
-1. Slice headings are `### Slice <id>` and manifests are
-   `### <id> execution manifest`. IDs are a letter-run plus an integer or
-   dotted integer. Every slice has exactly one matching manifest.
-2. Every slice declares Goal, Requirement IDs, Design IDs, SEIT proof rows,
-   Type, Design lenses, named implementation role, owner-selected model route,
-   reasoning level, and review path. Goals are at most 512 characters.
-3. Every manifest declares Write set, Command IDs, Stop condition, and Human
-   decision. Optional fields are Shared interfaces (`path#Symbol`), Integration
-   boundary, Published standard (`doc#clause`) when applicable, and Parallel
-   safe (`yes` or `no` plus reason).
+1. Regular JSON is the nested execution authority for Journey settings, lineup
+   snapshots, waves, slices, dependencies, traceability, and manifests.
+2. Every slice declares one named role plus goal, type, requirement IDs, design
+   IDs, SEIT proof rows, exact design-lens names sourced from `design.md`,
+   owner-selected model route, reasoning, review path, write set, command IDs,
+   stop condition, human decision, and `authority_id`. Goals are at most 512
+   characters. Slice actions and write sets are subsets of current authority.
+3. Optional fields are Shared interfaces (`path#Symbol`), Integration
+   boundary, Published standard (`doc#clause`) when applicable, SysML and
+   integration fields when selected, and Parallel safe (`yes` or `no` plus
+   reason).
 4. Write sets use one line: `Write only `path``. Paths are bounded, normalized,
    repository-relative literals. Put prohibitions in prose, not the write set.
 5. Multi-slice plans declare consecutive `Wave <n>: <ids>` lines. Every slice
    belongs to one wave. Dependencies use acyclic `S1 --> S2` arrows.
-6. Optional phase graphs use Phase | Slices | Depends on phases | Integration
-   checkpoints. Optional Inputs and Produces name metric denominator, ledger
-   key, or contract field values in backticks.
+6. Ordered integration steps, resources, ownership, and rollback live here.
+   Owner-configured reviewer count `n`, repair bound `k`, and confirmation
+   count `c` are explicit fields with no assistant default integers.
 7. Plans may contain at most 128 slices, manifests, write paths, and commands.
    Aim for at most 500 estimated tokens per slice plus manifest; split larger
    packets when practical.
@@ -113,12 +128,15 @@ placeholders, bare negations, or deferral language.
 1. Select review-oriented feature diagrams (flow diagrams, state-machine diagrams, or process/sequence diagrams) when they materially clarify architecture or lifecycle behavior for owner review.
 2. Major features select a justified subset or full set of diagrams based on architectural complexity. Trivial features or minor fixes do not require unnecessary diagrams.
 3. Every feature diagram must include canonical, reviewable source (such as Mermaid code blocks), render visually inside generated `review.html`, and retain nearby authoritative explanatory text.
+4. Non-trivial technical plans include words plus context/boundary, use-case/outcome, and operational-flow views. In MBSE mode record model revision/digest; never silently substitute Mermaid for mandated SysML. Trivial work may record `diagram_not_required` with a concrete rationale.
 
 ## Completion boundary
 
-Author specification, design, SEIT, implementation, and review HTML in that
+Author technical-plan, design, SEIT, implementation, and review HTML in that
 dependency order with internal prospective checks; generate implementation and
-HTML together after their stable inputs. The single owner review gate requires
+HTML together after their stable inputs. `review.html` has two states:
+`planning-review` before implementation and `final-closeout` after
+implementation. Each records its stage and exact input digests. The single owner review gate requires
 the complete five-artifact package. Do not insert a lineup, route, or
 specification-only owner gate unless the owner explicitly requests staged
 approvals. The HTML becomes authoritative only after integrated owner approval.

package/skills/park-ranger/SKILL.md

@@ -15,16 +15,20 @@ Independent defect assurance, outside the mutation-authority ladder.
 ## Inputs and match
 
 - **Inputs:** approved baseline, exact candidate ref and diff, author identity,
-  relevant evidence, at-end boundary, review focus, and compact return schema.
-- **Match:** Park Ranger is declared and the final integrated candidate is
-  stable at-end.
+  relevant evidence, declared phase or wave end boundary, review focus, and
+  compact return schema.
+- **Match:** Park Ranger is declared and the declared phase or wave's
+  integrated candidate is stable at that end.
 - **Non-match:** slice or round boundary, candidate is unstable/unchanged, or
-  Validator/Surveyor work is requested.
+  Surveyor/Test Engineer work is requested.
 
 ## Algorithm
 
 1. Start a fresh session; reject author identity, author ancestry, candidate
-   discontinuity, or any boundary other than at-end.
+   discontinuity, or any boundary other than the declared phase or wave end.
+   Consume the Assurance
+   Test Engineer receipt. Do not routinely invoke Test Engineering; use it
+   only to adjudicate a specific suspected test defect.
 2. Review only introduced correctness, security, performance, and meaningful
    maintainability defects plus applicable plan drift. When the candidate
    implements a published standard, compare the change against the cited text
@@ -40,9 +44,10 @@ verdict, candidate_ref, changed_paths, tests, findings, and blocker.
 `ACCEPT`, `ACCEPT_WITH_FINDINGS`, and `BLOCK` are terminal. `REPAIR_REQUIRED`
 permits bounded correction. `ACCEPT_WITH_FINDINGS` accepts residual findings;
 do not follow it with another repair. Coordinators enforce
-`max_assurance_rounds` of 1. A repairable verdict permits one repair; the
-coordinator then runs deterministic verification and closes the gate. Do not
-review or repair that Journey again. A failed repair or scope change
-returns to Owner Authority.
+`max_assurance_rounds` of 1 per declared phase or wave. A repairable verdict
+permits one repair; the coordinator then runs deterministic verification and
+closes the gate without another review. Do not review or repair that declared
+unit again. The next distinct declared phase or wave carries its own budget. A
+failed repair or scope change returns to Owner Authority.
 
 Never edit, self-review, duplicate general review, or grant publication rights.