@alphazede/bearing-lite 0.1.9 → 0.1.11

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

@@ -1,46 +1,57 @@
 ---
 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 specification, 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`.
+
+## Procedure
+
+1. Derive `<journey-topic>-spec.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
+   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
+   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.
+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

@@ -7,16 +7,55 @@ Bearing rejects deviations with typed findings.
 
 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.
+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.
 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.md` 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
 
@@ -42,7 +81,8 @@ Bearing rejects deviations with typed findings.
    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).
+   boundary, Published standard (`doc#clause`) when applicable, 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
@@ -76,8 +116,9 @@ placeholders, bare negations, or deferral language.
 
 ## 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 specification, 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
+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 at the confirmed cadence: every slice, every
-   integrated execution/correction round, or only the final integrated outcome.
-   Before redispatched assurance, honor `max_assurance_rounds` from visible
-   `assurance_rounds`. At the bound, do not dispatch another review. If a
-   repairable result has a remaining `attempts` repair, spend it and close the
-   gate; otherwise return `OWNER_DECISION_REQUIRED` with candidate and count.
-   A new candidate lineage resets the count.
-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.

package/skills/park-ranger/SKILL.md

@@ -2,9 +2,10 @@
 name: park-ranger
 description: >
   Independently review one exact stable candidate for introduced actionable
-  defects in a fresh session at the selected review boundary. Use for Park
-  Ranger, code review, or defect adjudication. Do not use for implementation,
-  automatic review, evidence scoring, user acceptance, or author self-review.
+  defects in a fresh session at the end. Use for Park Ranger, code review, or
+  defect adjudication. Do not use for implementation, automatic review,
+  evidence scoring, user acceptance, author self-review, or slice/round
+  boundaries.
 ---
 
 # Park Ranger
@@ -14,18 +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, cadence boundary, review focus, and return schema.
-- **Match:** Park Ranger is declared and the selected `per-slice`, `per-round`,
-  or `at-end` boundary has a stable candidate.
-- **Non-match:** boundary is not reached, candidate is unstable/unchanged, or
+  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.
+- **Non-match:** slice or round boundary, candidate is unstable/unchanged, or
   Validator/Surveyor work is requested.
 
 ## Algorithm
 
-1. Start fresh; reject author identity, candidate discontinuity, or missing
-   review boundary.
+1. Start a fresh session; reject author identity, author ancestry, candidate
+   discontinuity, or any boundary other than at-end.
 2. Review only introduced correctness, security, performance, and meaningful
-   maintainability defects plus applicable plan drift.
+   maintainability defects plus applicable plan drift. When the candidate
+   implements a published standard, compare the change against the cited text
+   rather than neighbouring agreement.
 3. Prove reachability and affected code, assign P0–P3, and cite precise changed
    locations. Avoid speculation and nits.
 4. Return a patch verdict and repair targets. Never implement a finding.
@@ -33,19 +36,13 @@ Independent defect assurance, outside the mutation-authority ladder.
 ## Return and recovery
 
 Return `BLOCK`, `REPAIR_REQUIRED`, `ACCEPT_WITH_FINDINGS`, or `ACCEPT` with
-candidate ref, findings, evidence, verdict, blocker, next action, and receiver.
+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`. Review again only after candidate-changing repairs
-when rounds remain.
-
-The gate cycle terminates on a repair, not on a review: `review → repair →
-review → repair → done`. The final repair within bounds completes the gate.
-Do not require an additional review to confirm the last repair — that would
-make every review demand another repair and every repair another review, an
-unbounded loop. A coordinator that has consumed its review rounds and has an
-`attempts` repair remaining spends it and closes the gate; that is completion,
-not bounds exhaustion.
+`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.
 
 Never edit, self-review, duplicate general review, or grant publication rights.

package/skills/surveyor/SKILL.md

@@ -2,9 +2,9 @@
 name: surveyor
 description: >
   Independently compare one stable integrated candidate with the approved
-  user-facing outcome in a fresh session at the selected acceptance boundary.
-  Use for Surveyor or outcome acceptance. Do not use for implementation,
-  evidence scoring, defect review, automatic review, or publication approval.
+  user-facing outcome in a fresh session at the end. Use for Surveyor or
+  outcome acceptance. Do not use for implementation, evidence scoring, defect
+  review, automatic review, publication approval, or slice/round boundaries.
 ---
 
 # Surveyor
@@ -14,17 +14,18 @@ Independent outcome assurance, outside the mutation-authority ladder.
 ## Inputs and match
 
 - **Inputs:** approved specification/review baseline, exact integrated candidate,
-  author identities, user-facing evidence, cadence boundary, prior required
-  assurance, and return schema.
-- **Match:** Surveyor is declared and a selected review boundary has an integrated
-  candidate suitable for user-facing comparison.
-- **Non-match:** unfinished packet, unstable candidate, Validator sufficiency,
-  Park Ranger defect review, or owner-only release decision.
+  author identities, user-facing evidence, at-end boundary, prior required
+  assurance, and compact return schema.
+- **Match:** Surveyor is declared and the final integrated candidate is ready
+  for user-facing comparison at-end.
+- **Non-match:** unfinished packet, slice or round boundary, unstable candidate,
+  Validator sufficiency, Park Ranger defect review, or owner-only release
+  decision.
 
 ## Algorithm
 
-1. Start fresh; verify candidate continuity, independence, completed prerequisite
-   assurance, and the cadence boundary.
+1. Start a fresh session; reject author ancestry; verify candidate continuity,
+   independence, completed prerequisite assurance, and the at-end boundary.
 2. Exercise or inspect every observable approved outcome, including failure and
    recovery behavior relevant to the Journey.
 3. Map each gap to an exact requirement and evidence location. Separate observed
@@ -33,8 +34,9 @@ Independent outcome assurance, outside the mutation-authority ladder.
 
 ## Return and recovery
 
-Return `ACCEPT`, `GAPS`, or `OWNER_DECISION_REQUIRED` with candidate ref,
-requirement coverage, evidence, gaps, blocker, next action, and receiver.
-Reassess only a new integrated candidate, at most three rounds.
+Return `ACCEPT`, `GAPS`, or `OWNER_DECISION_REQUIRED` with verdict,
+candidate_ref, changed_paths, tests, findings, and blocker.
+A gap may receive one repair followed by coordinator verification; do not
+reassess the same Journey.
 
 Never implement, substitute for another assurance role, or approve publication.

package/skills/validator/SKILL.md

@@ -2,9 +2,9 @@
 name: validator
 description: >
   Independently validate evidence sufficiency and optional rubric scoring for
-  one exact stable candidate in a fresh session at the selected review boundary.
-  Use for Validator or evidence validation. Do not use for implementation,
-  defect review, user acceptance, automatic reviews, or author self-checks.
+  one exact stable candidate in a fresh session at the end. Use for Validator
+  or evidence validation. Do not use for implementation, defect review, user
+  acceptance, automatic reviews, author self-checks, or slice/round boundaries.
 ---
 
 # Validator
@@ -14,29 +14,31 @@ Independent assurance responsibility, outside the mutation-authority ladder.
 ## Inputs and match
 
 - **Inputs:** approved baseline, exact candidate ref, author identity, scope,
-  evidence, acceptance, cadence boundary, optional rubric, and return schema.
-- **Match:** Validator is declared and the chosen `per-slice`, `per-round`, or
-  `at-end` boundary is reached.
-- **Non-match:** candidate is unstable, boundary is not reached, evidence alone
+  evidence, acceptance, at-end boundary, optional rubric, and compact return
+  schema.
+- **Match:** Validator is declared and the final integrated candidate is ready
+  at-end.
+- **Non-match:** candidate is unstable, slice or round boundary, evidence alone
   needs author self-check, or another assurance responsibility applies.
 
 ## Algorithm
 
-1. Start fresh and reject author identity, candidate discontinuity, or a missing
-   cadence boundary.
+1. Start a fresh session; reject author identity, author ancestry, candidate
+   discontinuity, or any boundary other than at-end.
 2. Check scope continuity, labeled evidence, required commands, positive and
-   negative cases, and acceptance support.
+   negative cases, and acceptance support. Where the candidate cites a published
+   standard, verify against that text rather than neighbouring agreement.
 3. Apply `references/grading-rubric.md` only when explicit scoring is requested.
 4. Return the smallest missing proof or exact failing criterion. Never mutate the
    candidate or manufacture evidence.
 
 ## Return and recovery
 
-Return `PASS`, `NEEDS_MORE_EVIDENCE`, or `FAIL` with candidate ref, criteria,
-evidence, findings, blocker, next action, and receiver. `PASS` is terminal.
+Return `PASS`, `NEEDS_MORE_EVIDENCE`, or `FAIL` with verdict, candidate_ref,
+changed_paths, tests, findings, and blocker. `PASS` is terminal.
 `NEEDS_MORE_EVIDENCE` and `FAIL` permit bounded correction. Coordinators
-enforce `max_assurance_rounds`; this role does not redispatch. Re-evaluate only
-a new candidate or materially new evidence.
+enforce `max_assurance_rounds` of 1; this role does not redispatch or re-evaluate
+the Journey's repair. The coordinator verifies it deterministically.
 
 Never implement, repeat unchanged review, replace Park Ranger/Surveyor, or
 grant owner-only approval.