@alphazede/bearing-lite 0.1.10 → 0.2.0

package/skills/crewmate/SKILL.md

@@ -1,10 +1,11 @@
 ---
 name: crewmate
 description: >
-  Implement one approved bounded packet in a fresh session and exact write set.
-  Use for Crewmate, implementation, repair, or integration packets. Do not use
-  for orchestration, planning, independent assurance, publication, destructive
-  action, owner decisions, or unset scope.
+  Implement one approved bounded packet in an exact write set. Continue the
+  same-wave session when identity, authority, route, and generation are
+  unchanged. Use for Crewmate, implementation, repair, or integration packets.
+  Do not use for orchestration, planning, independent assurance, publication,
+  destructive action, owner decisions, or unset scope.
 ---
 
 # Crewmate
@@ -14,36 +15,44 @@ Lowest mutation authority and highest hands-on work in the Bearing ladder.
 ## Inputs and match
 
 - **Inputs:** approved baseline, objective, dependencies, exact write set,
-  authority, acceptance/SEIT rows, commands, cadence, stop rule, return schema,
-  and lineup identity from the recorded Journey snapshot.
+  authority, acceptance/SEIT rows, commands, stop rule, compact return schema,
+  visible wave receipt, and lineup identity from the recorded Journey snapshot.
 - **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
 
-1. Start a fresh session and confirm candidate continuity, boundaries, and clean
-   dependency state. Do not infer missing owner choices. Read dispatch
-   identities only from the recorded Journey snapshot, never from the current
-   global defaults file. Revalidate the visible checkout
+1. Continue the current session when repository, worktree, branch, wave
+   generation, authority, and route are unchanged. Start a fresh session only
+   for a route change, conflicting writer, new authority envelope, independent
+   work, or explicit owner choice. Do not infer missing owner choices. Read
+   dispatch identities only from the recorded Journey snapshot, never from the
+   current global defaults file. Revalidate the visible checkout
    lease against the approved Journey, repository, checkout/worktree, branch,
-   candidate revision, generation, and active state before the first write and
-   every mutation. Released, stale-generation, forged, or
+   candidate revision, generation, and active state at wave start, after
+   detected drift, and before commit. Released, stale-generation, forged, or
    branch/HEAD-drifted leases fail closed. Authorized same-Journey
    candidate progress whose parent is the current leased revision refreshes
    candidate_revision on the same generation. On mismatch, return WAITING_ON without writing.
 2. For a verified contract defect, create the smallest failing regression first.
 3. Make the smallest change that satisfies the packet inside the write set.
-4. Run assigned focused commands and author self-checks. Review cadence never
+   When the packet implements a published standard, verify against the cited
+   document and clause before changing code; neighbouring behavior is not the
+   authority.
+4. Run assigned focused commands and author self-checks. At-end review never
    removes deterministic testing or grants independent-review identity.
-5. Preserve unrelated work and report every changed path and observed result.
+5. Preserve unrelated work. Return only the compact receipt.
 6. Stop on acceptance, authority boundary, design gap, or exhausted correction.
 
 ## Return and recovery
 
 Return `CANDIDATE_READY`, `PARTIAL`, `WAITING_ON`, or
-`OWNER_DECISION_REQUIRED` with plan ref, role, subject, dependencies, scope,
-authority, candidate ref, evidence, blocker, next action, and receiving role.
-Attempts 1–3 require new evidence, hypothesis, or narrower strategy.
+`OWNER_DECISION_REQUIRED` with verdict, candidate_ref, changed_paths, tests,
+findings, and blocker. Attempts 1–3 require new evidence, hypothesis, or
+narrower strategy.
 
 Never expand scope, self-certify as assurance, publish, or hide a failure.

package/skills/explorer/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: explorer
 description: >
-  Own one approved execution wave, dispatching bounded fresh-session packets
-  and integrating their evidence. Use for Explorer Journey, wave orchestration,
-  proven-independent in-wave lanes, or parallel packet sequencing. Do not use
-  for implementation, cross-wave work, planning, automatic nesting, or
-  independent assurance.
+  Own one approved execution wave, continuing bounded packets when the
+  envelope is unchanged and integrating their evidence. Use for Explorer
+  Journey, wave orchestration, proven-independent in-wave lanes, or parallel
+  packet sequencing. Do not use for implementation, cross-wave work, planning,
+  automatic nesting, or independent assurance.
 ---
 
 # Explorer
@@ -15,45 +15,46 @@ Wave authority. Coordinates more and implements less than Crewmate.
 ## Inputs and match
 
 - **Inputs:** approved baseline, wave objective, packet graph, dependencies,
-  scope, authority, lineup from the recorded Journey snapshot, review cadence,
-  acceptance, and return schema.
-- **Match:** one wave needs packet sequencing, dispatch, integration, or
-  proven-independent lane coordination.
-- **Non-match:** one bounded packet needs no orchestration, multiple waves
-  conflict, or assurance alone is requested.
+  scope, authority, lineup from the recorded Journey snapshot, visible wave
+  receipt, acceptance, and compact return schema.
+- **Match:** one wave needs packet sequencing, dispatch, integration, or proven-independent lane coordination.
+- **Non-match:** one bounded packet needs no orchestration, multiple waves conflict, or assurance alone is requested.
 
 ## Algorithm
 
-1. Start fresh and verify wave readiness, exact packet boundaries, dependencies,
-   and approved primary/fallback identities from the recorded Journey snapshot,
+1. Continue this wave when identity, authority, route, and generation are
+   unchanged; otherwise start fresh. Verify wave readiness, packet boundaries,
+   dependencies, and approved identities from the recorded Journey snapshot,
    never from the current global defaults file. Revalidate the visible checkout
    lease against the approved Journey, repository, checkout/worktree, branch,
-   candidate revision, generation, and active state before the first write,
-   dispatch, or integration. Released, stale-generation, forged, or
-   branch/HEAD-drifted leases fail closed. Authorized same-Journey
-   candidate progress whose parent is the current leased revision refreshes
+   candidate revision, generation, and active state at wave start, after
+   detected drift, and before commit. Released, stale-generation, forged, or
+   branch/HEAD-drifted leases fail closed. Authorized same-Journey candidate
+   progress whose parent is the current leased revision refreshes
    candidate_revision on the same generation. The same valid lease continues
-   without duplicate dispatch.
+   without duplicate dispatch. Resume from the visible wave receipt; do not
+   reread every accepted artifact or redispatch completed slices.
 2. Use direct Crewmates by default. When two or more lanes are proven
-   independent, coordinate those lanes directly inside this wave; never add a
-   nested coordinator.
-3. Give every node a fresh bounded session. Never pass raw conversation history.
-4. Inspect returns against write sets and acceptance; integrate evidence without
-   implementing missing packet work.
-5. Dispatch declared assurance once at the owner-confirmed `per-slice`,
-   `per-round`, or `at-end` boundary. At `at-end`, an Explorer Journey reviews
-   its final wave; an Expedition wave defers assurance to the Navigator'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 remaining `attempts` repair, run deterministic
-   coordinator verification, and close the gate without another review. A failed
-   repair or scope change returns `OWNER_DECISION_REQUIRED` with candidate and
-   count. After Journey `COMPLETE`, deployment checks do not reopen assurance.
+   independent, coordinate those lanes directly inside this wave; never add a nested coordinator.
+3. Permit Crewmate continuation when the envelope is unchanged. Never pass raw
+   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.json` and `review.html`
+   once per wave, plus owner-decision or blocker changes.
+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. 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.
 
 ## Return and recovery
 
 Return `READY`, `REROUTED`, `WAITING_ON`, or `OWNER_DECISION_REQUIRED` with
-plan ref, role, subject, dependencies, scope, authority, evidence, blocker, next
-action, and receiver. Reroute only from new evidence; three attempts per packet.
+verdict, candidate_ref, changed_paths, tests, findings, and blocker. Reroute only from new evidence; three attempts per packet.
 
 Never implement, self-assure, select models, or expand the wave.

package/skills/gather-supplies/SKILL.md

@@ -15,7 +15,8 @@ Planning node, not a persona or plan-state writer.
 
 - **Match:** a material scope, behavior, authority, risk, or acceptance
   decision is unresolved. The Explorer-versus-Expedition route choice is not
-  gathered here; the Router asks it at the pre-implementation gate.
+  gathered here; the Router asks it at the route review after Map the Route
+  maps the implementation graph.
 - **Non-match:** evidence can answer it, the owner already decided it, or a work
   packet is ready.
 - **Inputs:** goal, visible plan state, repository evidence, prior decisions,
@@ -24,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

@@ -1,46 +1,58 @@
 ---
 name: map-the-route
 description: >
-  Create or resume Bearing's topic-specific specification, design, SEIT,
-  implementation graph, and self-contained review HTML after decisions are
-  resolved. Use for Map the Route or missing planning artifacts. Do not use to
-  implement, select agents/models, self-approve, or bypass owner review.
+  Create or resume Bearing's complete five-artifact planning package after
+  material decisions are settled. Use for Map the Route or missing planning
+  artifacts. Do not use to implement, select models, self-approve, or bypass
+  the single integrated owner review.
 ---
 
 # Map the Route
 
-Fresh planning node. The Router remains the plan-state writer and user contact.
-
-## Inputs and match
-
-- **Inputs:** confirmed decisions, repository map, artifact status, requirements,
-  owner-selected route/lineup/cadence, repository rules, and return schema.
-- **Match:** first specification gate or post-approval planning package is missing.
-- **Non-match:** executable tasks already map to current approved artifacts.
-
-## Algorithm
-
-1. Derive and announce `<journey-topic>-spec.md` from the confirmed title;
-   require owner input only on ambiguity or collision. Never require generic
-   `plan-spec.md`.
-2. Author in dependency order: testable specification, `design.md`, `seit.md`,
-   then `implementation.md`. Run prospective checks internally; interrupt the
-   owner only when evidence creates a material intent, scope, risk, or authority
-   decision.
-3. Generate one complete self-contained offline `review.html` after all four
-   artifacts are current. Include implementation, traceability, roles, waves,
-   failure/recovery paths, and approval boundaries in that review.
-4. Give every slice stable requirement/design/SEIT IDs, dependencies, exact
-   write set, authority, fresh-session role, evidence, recovery, and stop rule.
-5. Copy the confirmed route, lineup, and review cadence into implementation and
-   HTML. Show named active, standby, and unused role instances.
-6. Open the exact final HTML, verify its launcher/process, and request one
-   integrated owner approval. Use staged owner approvals only when the owner
-   explicitly requests them.
+Fresh planning node. The Router writes Journey state and owns owner conversation.
+
+## Match, inputs, and non-match
+
+- **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.json` or `review.html`.
+
+## Procedure
+
+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
+   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.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. 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
+   of outcome, design, route, lineup, cadence, and plan. Dispatch remains
+   prohibited until approval. An owner change regenerates affected artifacts,
+   then returns to this same gate; never insert a lineup or route-review pause.
 
 ## Return and recovery
 
-Return `PLAN_REVIEW_READY`, `NEEDS_OWNER_DECISION`, or `VALIDATION_FAILED` with
-artifact paths, evidence, blocker, and next action. After approval,
-`review.html` is authoritative. At most three evidence-changing correction
-rounds; never invent approval or implement.
+Return `PLAN_REVIEW_READY`, `REROUTE_GATHER_SUPPLIES`,
+`NEEDS_OWNER_DECISION`, or `VALIDATION_FAILED` with paths, evidence, blocker,
+and next action. Owner-decision pauses do not consume correction rounds. At
+most three evidence-changing correction rounds; never implement or invent approval.

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

@@ -3,53 +3,108 @@
 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`.
-2. Requirement IDs use `AC-*` or `RISK-*`; 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.
+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>-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. The owner-confirmed lineup and review cadence supply named active, standby,
-   and unused instances. Missing values block implementation drafting.
+5. Owner-supplied lineup identities and proposed `review_cadence: at-end` are
+   required before implementation drafting; missing identities or cadence block
+   drafting. Do not offer `per-slice` or `per-round`. Map the proposed Journey
+   type and active/standby/unused role states before generating implementation;
+   the final implementation and `review.html` record those proposals together.
+6. The lineup snapshot contains the Journey-owned `planning_review` binding:
+   policy reference, one candidate ref/revision/digest, and unique abstract
+   reviewer slots with a primary route reference plus ordered fallback route
+   references. Slot count satisfies the referenced core policy. Do not put route
+   identities in the core policy or map these slots to implementation assurance.
+
+## Requirements register
+
+1. Before authoring a Journey specification, establish whether the target
+   repository or system already has a requirements register and where. When the
+   repository cannot answer, ask the owner; never infer.
+2. Where no register exists, author requirements as today; this section does not
+   apply.
+3. Where a register exists, specification requirement rows are either references
+   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.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
+   rows remain Journey-local.
+5. `review.html` marks every requirement as either a register reference or
+   Journey-local, so a reviewer can tell which artifact owns each statement.
+6. `design.md` is unaffected: it records how the work is built, which no
+   requirements register covers.
+
+## Published standards
+
+1. When a slice, command, or proof implements a published standard, the plan and
+   its execution manifest cite the exact document and clause.
+2. Verification is against the standard's text, not against neighbouring
+   implementation agreement; a passing cross-boundary test does not substitute
+   for clause conformance.
 
 ## 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, 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.
@@ -73,11 +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, and implementation in that dependency order
-with internal prospective checks. The owner review gate requires all four
-artifacts plus the complete `review.html`; do not insert a specification-only
-owner gate unless the owner explicitly requests staged approvals. The HTML
-becomes authoritative only after integrated owner approval.
+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. `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/navigator/SKILL.md

@@ -1,59 +1,36 @@
 ---
 name: navigator
 description: >
-  Sequence dependency-connected Expedition waves, resolve cross-wave conflicts,
-  and own integration boundaries. Use for Navigator, Expedition, or multi-wave
-  execution control. Do not use for one packet/wave, product implementation,
-  planning-state ownership, model selection, publication, or assurance.
+  Compatibility diagnostic for plans that still name Navigator. Use when an
+  existing plan assigns Navigator or asks to sequence expedition waves as
+  navigator. Do not use for new Journeys, packet work, planning, assurance,
+  or publication.
 ---
 
 # Navigator
 
-Highest execution authority below Router; performs the least hands-on execution.
+Compatibility only. Router now owns cross-wave sequencing and conflict
+resolution.
 
 ## Inputs and match
 
-- **Inputs:** approved artifacts, wave graph, dependencies, repository scope,
-  authority, lineup from the recorded Journey snapshot, review cadence,
-  acceptance, and return schema.
-- **Match:** an Expedition has multiple dependency-connected waves or phases,
-  including simultaneous waves that share interfaces or conflict.
-- **Non-match:** one Explorer wave or Crewmate packet is sufficient.
+- **Inputs:** a plan that still assigns `Navigator`, plus the recorded Journey
+  snapshot.
+- **Match:** an existing plan names Navigator as an assigned role.
+- **Non-match:** new Journeys, Explorer waves, Crewmate packets, or assurance.
 
 ## Algorithm
 
-1. Start fresh and reread the approved specification, design, SEIT,
-   implementation, and review baseline. Verify snapshot lineup and cadence.
-   Read dispatch identities only from the recorded Journey snapshot, never
-   from the current global defaults file. Revalidate the visible checkout
-   lease against the approved Journey, repository, checkout/worktree, branch,
-   candidate revision, generation, and active state before the first write,
-   dispatch, integration, or cross-wave transition. Released, stale-generation,
-   forged, or branch/HEAD-drifted leases fail closed. Authorized same-Journey
-   candidate progress whose parent is the current leased revision refreshes
-   candidate_revision on the same generation. The same valid lease
-   continues without duplicate dispatch.
-2. Sequence fresh Explorer sessions. For simultaneous waves with
-   shared-interface or dependency conflicts, resolve ordering and integration
-   here; never add a nested multi-wave controller.
-3. Integrate typed wave returns and correct only sequencing/coverage gaps inside
-   approved authority; never perform implementation.
-4. Dispatch independent assurance once at the confirmed `per-slice`,
-   `per-round`, or final integrated boundary. Honor `max_assurance_rounds` of 1
-   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
-   returns `OWNER_DECISION_REQUIRED` with candidate and count. After Journey
-   `COMPLETE`, deployment checks do not reopen assurance.
-5. Return to the Router after the bounded Expedition outcome; do not silently
-   continue into another Journey or protected action.
+1. Do not sequence waves, reread the artifact set, dispatch Explorers, or
+   run assurance. Read identities only from the recorded Journey snapshot,
+   never from the current global defaults file.
+2. Return `REROUTED` to the Router with a diagnostic that Navigator is not a
+   normal role; treat the assignment as unused and continue under Router.
+3. Preserve the checkout lease. Do not write planning state.
 
 ## Return and recovery
 
-Return `READY`, `REROUTED`, `WAITING_ON`, or `OWNER_DECISION_REQUIRED` with
-plan ref, role, subject, dependencies, scope, authority, evidence, blocker, next
-action, and receiver. Attempts 1–3 require new evidence or strategy; a material
-design, intent, scope, security, destructive, remote, or publication change
-returns to Owner Authority.
+Return `REROUTED` with verdict, candidate_ref, changed_paths, tests, findings,
+and blocker. Findings name the compatibility path.
 
 Never implement, self-assure, select models, or mutate remotes.