@alphazede/bearing-lite 0.1.1 → 0.1.9

package/README.md

@@ -14,6 +14,27 @@ execution/correction round, or once at the end. Owner Authority remains human-on
 
 Bearing Lite was created by William Rumph.
 
+## Quick start with Pi
+
+Install the published skills package:
+
+```sh
+pi install npm:@alphazede/bearing-lite
+```
+
+Then give your agent a real task:
+
+> Use Bearing Lite to add rate limiting to this API without changing its public
+> responses. Require one independent review at the end.
+
+Bearing Lite asks whether the work is an Explorer Journey or an Expedition,
+fills only the missing planning stages, confirms the agent lineup and review
+cadence, and dispatches bounded sessions with visible Markdown state.
+
+If Bearing Lite helps keep a long agent task scoped and reviewable,
+[star the repository](https://github.com/alphazede/bearing-lite). It helps other
+coding-agent users find it.
+
 ## Install
 
 Install as a host plugin. The portable identity is always `bearing-lite` /
@@ -43,7 +64,7 @@ grok plugin install bearing-lite --trust
 agy plugin install /path/to/bearing-lite/.agy
 
 # Pi — skills package, no command hooks
-pi install git:github.com/alphazede/bearing-lite
+pi install npm:@alphazede/bearing-lite
 ```
 
 Claude Code, Codex, Grok Build, Cursor, and Kimi Code are **partial** hook
@@ -75,11 +96,11 @@ the applicable Journey snapshot before implementation.
 | Route | When | Cost |
 |---|---|---|
 | **Explorer Journey** | One bounded packet or one wave | Direct Crewmate or one Explorer |
-| **Expedition** | Multi-phase or concurrent independent lanes | Navigator; Trail Boss only for concurrent/conflicting waves |
+| **Expedition** | Multi-phase or concurrent independent lanes | Navigator |
 
 An **Explorer Journey** uses a direct Crewmate for one ready packet or one
 Explorer over a compact/sequential wave.
-**Expedition** adds navigation (and sometimes a Trail Boss) so independent lanes
+**Expedition** adds navigation so independent lanes
 stay small and sharp instead of degrading in one long context. Either shape can
 use substantial tokens; the product does not impose a default budget ceiling.
 
@@ -91,8 +112,9 @@ The text below remains authoritative for clients that do not render Mermaid.
 **Authoritative text (vision optional):** Owner Authority remains human-only. The
 Bearing Lite Router is the stateful planning controller, not a work role. It
 invokes only missing planning stages in fresh sessions, confirms the owner's
-lineup and cadence, then dispatches an Explorer Journey or Expedition. Nested
-Sub-Explorer opens only for proven-independent lanes. Validator, Park Ranger,
+lineup and cadence, then dispatches an Explorer Journey or Expedition. Explorer
+coordinates proven-independent in-wave lanes without a nested coordinator.
+Validator, Park Ranger,
 and Surveyor appear only when declared and when the selected per-slice,
 per-round, or at-end boundary is reached. Diagrams explain orientation; they
 never authorize a transition.
@@ -102,10 +124,8 @@ never authorize a transition.
 | Role | What it is | Executes | Notes |
 |---|---|---|---|
 | **Router** | Stateful planning controller | no | User-facing; planning-state writer |
-| **Navigator** | Expedition orchestrator | no | Owns cross-wave sequencing |
-| **Trail Boss** | Multi-wave controller | no | Only concurrent or conflicting waves |
-| **Explorer** | One-wave controller | no | Dispatches Crewmates |
-| **Sub-explorer** | Nested lane controller | no | Only when lanes are proven independent |
+| **Navigator** | Expedition orchestrator | no | Owns cross-wave sequencing and conflicts |
+| **Explorer** | One-wave controller | no | Dispatches Crewmates; owns proven-independent lanes |
 | **Crewmate** | Bounded implementer | yes | Most hands-on work; exact write set |
 | **Validator** | Evidence sufficiency | no | Independent of the author |
 | **Park Ranger** | Defect review | no | Independent of the author |
@@ -120,21 +140,21 @@ Failure escalates to the nearest role whose scope can see it:
 | Failure scope | Escalates to |
 |---|---|
 | Within one slice or packet | Explorer or nearest parent |
-| Across slices in a wave | Trail Boss when present, else Navigator |
-| Across phases | Navigator |
+| Across slices in a wave | Explorer |
+| Across waves or phases | Navigator |
 | Contract, security, or authority change | Owner Authority |
 
 ## Task state (explanatory)
 
-![Bearing Lite task state machine: PROPOSED through READY, IN_PROGRESS, EVIDENCE_READY, optional VALIDATING or REVIEWING, ACCEPTANCE, COMPLETE, with WAITING_ON, CORRECTION_REQUIRED, OWNER_DECISION_REQUIRED, and CANCELLED paths](skills/bearing-lite/assets/task-state.png)
-
-Reviewable Mermaid source: [`skills/bearing-lite/references/task-state.mmd`](skills/bearing-lite/references/task-state.mmd).
+Current task-state diagram source: [`skills/bearing-lite/references/task-state.mmd`](skills/bearing-lite/references/task-state.mmd).
+The text below remains authoritative for clients that do not render Mermaid.
 Authoritative transition rules: [`skills/bearing-lite/references/task-state.md`](skills/bearing-lite/references/task-state.md).
 
 **Authoritative summary:** The project's plan is the only task-state record.
 Normal progress is `PROPOSED` → `READY` → `IN_PROGRESS` → `EVIDENCE_READY`, then
 optional `VALIDATING` / `REVIEWING` when required, then `ACCEPTANCE` →
-`COMPLETE`. `WAITING_ON` holds for missing prerequisites or assurance dispatch.
+`COMPLETE`. `WAITING_ON` holds for missing prerequisites, checkout-lease
+conflict, or assurance dispatch.
 `CORRECTION_REQUIRED` allows two in-authority repairs; a third failed correction
 escalates to `OWNER_DECISION_REQUIRED`. Diagrams never create state or authorize
 transitions.

package/hooks/com.anthropic.claude-code/host.cjs

@@ -53,7 +53,8 @@ const TASK_MARK = /(?:^|\n)###\s*task_id:\s*\S+/;
 const TASK_LINE = /^###\s*task_id:\s*(\S+)\s*$/;
 const FIELD_LINE =
   /^-\s*(assigned_role|next_action|status|required_assurance|blocker|evidence|candidate_ref|scope|authority|outcome|depends_on|receiving_role|plan_ref|role|subject):\s*(.*)$/;
-const JOURNEY_LINE = /^-\s*journey:\s*(.+)$/i;
+const JOURNEY_LINE = /^\s*-\s*journey:\s*(.+)$/i;
+const LEASE_MARK = /^\s*-\s*checkout_lease:/m;
 
 const ACTIVATION_EVENTS = new Set([
   "SessionStart",
@@ -63,6 +64,7 @@ const ACTIVATION_EVENTS = new Set([
   "SubagentStart",
 ]);
 const CLOSEOUT_EVENTS = new Set(["Stop", "SubagentStop", "SessionEnd"]);
+const STOP_CONTINUATION_EVENTS = new Set(["Stop", "SubagentStop"]);
 
 const EVENT_ALIASES = Object.freeze({
   sessionstart: "SessionStart",
@@ -212,9 +214,13 @@ function deriveContext(cwd) {
     } catch {
       continue;
     }
-    if (!TASK_MARK.test(text) && !/^-\s*assigned_role:/m.test(text)) continue;
-    planPresent = true;
     const parsed = parsePlanMarkdown(text);
+    const hasAssignedRole = /^-\s*assigned_role:/m.test(text);
+    const hasLease = LEASE_MARK.test(text);
+    if (!TASK_MARK.test(text) && !hasAssignedRole && !parsed.journey && !hasLease) {
+      continue;
+    }
+    planPresent = true;
     if (parsed.journey) journey = parsed.journey;
     for (const task of parsed.tasks) allTasks.push(task);
   }
@@ -248,6 +254,28 @@ function classForEvent(eventName) {
   return null;
 }
 
+function isTruthyFlag(value) {
+  return value === true || value === "true";
+}
+
+function isStopReentry(input, eventName) {
+  if (!STOP_CONTINUATION_EVENTS.has(eventName)) return false;
+  return isTruthyFlag(input.stop_hook_active) || isTruthyFlag(input.stopHookActive);
+}
+
+function hasDiscoverableJourney(derived) {
+  return (
+    derived.plan_present === true ||
+    derived.router_invoked === true ||
+    Boolean(derived.assigned_role) ||
+    derived.active_task != null
+  );
+}
+
+function quietSuccess() {
+  return {};
+}
+
 function formatAdvice(verdict) {
   const lines = [
     "Bearing Lite " + verdict.hook_class + ": " + verdict.outcome,
@@ -346,6 +374,10 @@ function handle(input) {
     return unavailableHost(eventName || "SessionStart", "unmapped_host_event");
   }
 
+  if (isStopReentry(parsed, eventName)) {
+    return quietSuccess();
+  }
+
   const cwd =
     presentString(parsed.cwd) ||
     presentString(parsed.workspaceRoot) ||
@@ -361,6 +393,10 @@ function handle(input) {
     );
   }
 
+  if (STOP_CONTINUATION_EVENTS.has(eventName) && !hasDiscoverableJourney(derived)) {
+    return quietSuccess();
+  }
+
   return toHostResponse(eventName, evaluateForHost(eventName, derived));
 }
 

package/hooks/com.anthropic.claude-code/mapping.md

@@ -43,7 +43,7 @@ trees) and sets only:
 
 | Bearing field | Source |
 |---|---|
-| `plan_present` | a Markdown file contains a `task_id` or `assigned_role` block |
+| `plan_present` | a Markdown file contains a `task_id`, `assigned_role`, non-placeholder journey marker, or `checkout_lease` block |
 | `router_invoked` | a `- journey:` setting is present and not a placeholder |
 | `assigned_role` | active task `assigned_role` when not `unassigned` or `<…>` |
 | `next_action` / `next_action_known` | active task `next_action` when not a placeholder |
@@ -57,7 +57,13 @@ of inventing context.
 
 | Outcome | Host JSON | Process exit |
 |---|---|---|
-| `ADVISE`, `REROUTE`, `UNAVAILABLE` | `hookSpecificOutput.additionalContext` | always `0` |
+| `ADVISE`, `REROUTE`, `UNAVAILABLE` on activation or a discoverable-Journey first-pass Stop | `hookSpecificOutput.additionalContext` | always `0` |
+| Stop/SubagentStop re-entry (`stop_hook_active`) | quiet success (empty JSON; no `additionalContext`) | always `0` |
+| Stop/SubagentStop with no discoverable Journey | quiet success (empty JSON; no `additionalContext`) | always `0` |
+| first-pass Stop/SubagentStop with a discoverable Journey | `hookSpecificOutput.additionalContext` | always `0` |
 | `BLOCK` | JSON `decision: "block"` only; this mapping never requests protected completion | always `0` |
 
-Never map policy or infrastructure to a non-zero exit.
+A discoverable Journey is a visible plan with a `task_id`, `assigned_role`,
+non-placeholder journey marker, or `checkout_lease` block. Empty cwd and
+`stop_hook_active` re-entry stay quiet. Never map policy or infrastructure to
+a non-zero exit.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alphazede/bearing-lite",
-  "version": "0.1.1",
+  "version": "0.1.9",
   "description": "Skills-first Agent Plugin for planning, routing, bounded execution, and independent review of repository work—without CLI, MCP, server, or hidden runtime state.",
   "keywords": [
     "agent-plugins",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "bearing-lite",
-  "version": "0.1.1",
+  "version": "0.1.9",
   "description": "Skills-first portable plugin that routes repository work through the smallest valid planning stages and agent roles, using project Markdown as the only task record.",
   "author": {
     "name": "William Rumph / AlphaZede",

package/skills/bearing-lite/SKILL.md

@@ -1,52 +1,49 @@
 ---
 name: bearing-lite
-description: >
-  Stateful Bearing Lite Router for starting or resuming a Journey, owning the
-  planning conversation, recording visible state, and dispatching fresh nodes.
-  Use only on explicit Bearing Lite invocation. Do not use for ordinary work,
-  an assigned role packet, model selection, implementation, or publication.
+description: Bearing Lite Router for Journeys. Not for ordinary work, assigned packets, implementation, or publication.
 ---
 
-# Bearing Lite Router
-
-Owner-facing planning controller, never a work role. Explicit invocation is
-consent to begin; do not ask for another start confirmation.
-
-## Inputs and state
-
-Read the request, repository evidence, visible plan artifacts, and global lineup
-when present. The Router alone writes Journey planning state; no `.bearing`,
-CLI, MCP, scheduler, or hidden ledger. Report hook coverage honestly: plugin
-hosts are partial; skill-copy is skills-only.
-
-## Algorithm
-
-1. Say `Gathering Supplies for this Journey.` Detect new versus resumed work.
-2. For a new Journey, recommend one route and ask exactly: `What Journey shall
-   we Embark on—an Explorer Journey or an Expedition?` Explorer fits one bounded
-   wave; Expedition fits dependency-connected waves.
-3. For a resume, state the next incomplete planning stage and continue unless
-   owner intent is missing. Never replay accepted stages.
+The Router alone writes Journey planning state and owns owner conversation;
+planning nodes return owner questions. No second start confirmation, `.bearing`,
+or hidden ledger. plugin hosts are partial; skill-copy is skills-only.
+
+1. Say `Preparing this Journey.` Inventory visible nonterminal Journeys; acquire or
+   resume a generation-bound checkout lease before any planning write or dispatch.
+   A live same-checkout competitor returns `WAITING_ON` with sanitized competing identity;
+   Distinct explicitly approved compatible worktrees may proceed.
+2. New Journey: recommend Explorer Journey or Expedition with reason; say when
+   the other fits. Ask exactly: `What Journey shall
+   we Embark on—an Explorer Journey or an Expedition?`
+3. On resume, keep the same lease generation and next incomplete stage. Parent-proven
+   same-Journey progress refreshes `candidate_revision` on that generation.
+   Never replay accepted stages or duplicate a dispatch.
 4. If `~/.agents/bearing-lite/default-role-lineup.md` is absent, create a
-   proposed copy from `templates/default-role-lineup.md` and ask the owner to
-   fill or confirm it one role at a time. Never infer identity values.
-5. Invoke one missing stage in order: Repository Fit → Set Bearings → Gather
-   Supplies → Map the Route. Give each a fresh session and integrate its return.
-6. Before implementation, display every role's primary/fallback agent or
-   harness, model, reasoning, and active/standby/unused state. Ask `Is this a
-   good lineup for the roles on this Journey?`; never choose those values.
-7. Ask `How often would you like an independent review—per slice, per round, or
-   at the end?` Record `per-slice`, `per-round`, or `at-end` in global config and
-   the Journey snapshot. The owner's Journey answer overrides the default.
-8. Dispatch only ready nodes. Every node gets a fresh session containing the
-   approved baseline, bounded assignment, dependencies, authority, relevant
-   evidence, review cadence, lineup identity, and return schema.
-
-## Return and recovery
-
-Write the node result into visible state and return `READY`, `WAITING_ON`,
-`OWNER_DECISION_REQUIRED`, or `COMPLETE` with evidence and next action. Use only
-the approved fallback after verified primary unavailability; if both fail,
-return to the owner. Allow at most three evidence-changing corrections.
-
-Never implement, self-assure, select models, expand scope, or publish.
+   proposed copy from `templates/default-role-lineup.md`; confirm one role at a
+   time. Never infer identity values.
+5. Run one missing stage in order: Repository Fit → Set Bearings → Gather
+   Supplies. The Router holds every owner conversation inline; Gather Supplies
+   is a Router-led interview, never dispatched. Dispatch a fresh session only
+   for bounded mechanical legwork (mapping, drafting) after stage intent is
+   clear, on a cheaper lower-reasoning model than the Router; integrate returns.
+6. Before Map the Route, display each role's primary/fallback, model, reasoning,
+   and active/standby/unused state. Ask `Is this a
+   good lineup for the roles on this Journey?`; never choose. Recommend cadence
+   with a reason plus one cheaper and one more expensive alternative stating
+   what each gives up or buys. Ask `How often would you like an independent
+   review—per slice, per round, or at the end?`
+7. Record route, lineup, and cadence before task mapping; if declined, record the named default explicitly.
+   The recorded snapshot is authoritative for this Journey. Later edits to
+   `~/.agents/bearing-lite/default-role-lineup.md` have no effect on it. Replace
+   only through an explicit owner-confirmed dated visible amendment. Invoke Map the Route with the snapshot.
+8. Every ready node gets a fresh session with lineup identity from the recorded snapshot.
+
+Return `READY`, `WAITING_ON`, `OWNER_DECISION_REQUIRED`, or `COMPLETE`. Fallback
+follows primary unavailability; both failing returns to owner.
+Allow three evidence-changing corrections. `max_assurance_rounds` is 3 per
+candidate lineage; Direct route checks `assurance_rounds`; Navigator is not required. 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` naming the candidate and count; new candidate lineage resets;
+release the checkout lease exactly once on `COMPLETE` or `CANCELLED`. Recover by
+explicit recorded generation increment that cannot steal a live lease. Process discovery
+cannot replace the lease. Never implement, self-assure, select models, or publish.

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

@@ -11,10 +11,8 @@ copy peer text, runtimes, state stores, or authority assumptions.
 | Set Bearings | [Kiro steering](https://kiro.dev/docs/steering/) | durable human-readable workspace context |
 | Gather Supplies | [Matt Pocock grilling](https://github.com/mattpocock/skills/blob/main/skills/productivity/grilling/SKILL.md) | relentless dependency-ordered interview, one recommended question at a time |
 | Map the Route | [Kiro Quick Spec](https://kiro.dev/docs/specs/quick-spec/) and [GitHub Spec Kit](https://github.com/github/spec-kit/blob/main/workflows/speckit/workflow.yml) | staged requirements/design/tasks and explicit gates |
-| Navigator | LangChain subagents | central sequencing and context isolation |
-| Trail Boss | Spec Kit fan-out/fan-in workflows | conflict-aware wave integration |
-| Explorer | LangChain subagents | bounded worker dispatch and result integration |
-| Sub-Explorer | LangChain subagents | one justified extra context-isolation level |
+| Navigator | LangChain subagents | central sequencing, context isolation, and conflict-aware wave integration |
+| 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 |
 | Park Ranger | LangChain reviewer subagent | independent defect review with a typed return |

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

@@ -11,14 +11,8 @@ flowchart TD
     J -->|Explorer Journey: one packet| C[Fresh Crewmate]
     J -->|Explorer Journey: one wave| E[Fresh Explorer]
     J -->|Expedition| N[Fresh Navigator]
-    N --> TB{Concurrent or conflicting waves?}
-    TB -->|yes| T[Fresh Trail Boss]
-    TB -->|no| E
-    T --> E
-    E --> X{Two or more proven-independent lanes?}
-    X -->|yes| SE[Fresh Sub-Explorer]
-    SE --> C
-    X -->|no| C
+    N --> E
+    E --> C
     C --> A{Selected cadence boundary?}
     A -->|Validator declared| V[Fresh Validator]
     A -->|Park Ranger declared| PK[Fresh Park Ranger]

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

@@ -8,7 +8,7 @@ The project's human-readable plan is the only task-state record. Diagrams explai
 | --- | --- | --- |
 | `PROPOSED` | Parent coordinator | Task exists but is not execution-ready |
 | `READY` | Parent coordinator | Dependencies, scope, authority, and route are satisfied |
-| `WAITING_ON` | Parent coordinator | Named prerequisite or independent-assurance dispatch unavailable |
+| `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 |
@@ -40,3 +40,21 @@ The project's human-readable plan is the only task-state record. Diagrams explai
 - Workers and assurance roles return handoffs; they do not race plan edits.
 - Candidate authors never provide their own Validator, 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.
+
+## Checkout lease
+
+The Router inventories visible nonterminal Journeys and holds one
+generation-bound checkout lease before any planning write or dispatch.
+
+- Same checkout plus a live other Journey → `WAITING_ON` with sanitized
+  competing Journey and controller. Distinct explicitly approved compatible
+  worktrees may proceed.
+- Resume keeps the same generation and must not duplicate dispatch.
+- `COMPLETE` or `CANCELLED` releases the lease exactly once.
+- Stale recovery is explicit, recorded, increments generation, and cannot
+  steal a live lease. Forged or stale-generation records fail closed.
+- Branch or HEAD drift from the leased identity stops the transition before
+  mutation. Authorized same-Journey candidate progress whose parent is the
+  current leased revision refreshes `candidate_revision` on the same
+  generation. Foreign controller, branch/worktree, or unrelated HEAD still
+  fail closed as `WAITING_ON`.

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

@@ -1,7 +1,7 @@
 stateDiagram-v2
     [*] --> PROPOSED
     PROPOSED --> READY
-    PROPOSED --> WAITING_ON
+    PROPOSED --> WAITING_ON: named prerequisite or checkout-lease conflict
     WAITING_ON --> READY: prerequisite satisfied
     WAITING_ON --> EVIDENCE_READY: fresh assurance available
     WAITING_ON --> CANCELLED

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

@@ -12,9 +12,7 @@ review_cadence: <per-slice | per-round | at-end>
 | --- | --- | --- | --- | --- | --- | --- |
 | Router | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
 | Navigator | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |
-| Trail Boss | 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 |
-| Sub-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 |
 | Park Ranger | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET | OWNER_TO_SET |

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

@@ -18,6 +18,39 @@ author self-checks. Never infer it from `required_assurance` on an individual
 task. `per-round` means after each integrated execution or correction round;
 `at-end` means one review of the final integrated candidate. The Router asks the
 owner to confirm both the applicable lineup and cadence before implementation.
+`lineup_snapshot` is authoritative for this Journey after recording. Later
+edits to `~/.agents/bearing-lite/default-role-lineup.md` have no effect.
+Replace it only through an explicit owner-confirmed dated visible amendment.
+Record the amendment date beside the replacement values. Dispatch identities
+come from this snapshot, not from the current global defaults file.
+
+## Checkout lease (record before any planning write)
+
+The Router's first write is this visible lease. Inventory nonterminal Journeys
+first. Do not dispatch or write other planning state until the lease is
+`active` for this Journey.
+
+```markdown
+- checkout_lease:
+  - journey: <Journey id>
+  - controller: <Router>
+  - repository: <canonical repository>
+  - checkout: <worktree or checkout identity>
+  - branch: <branch>
+  - candidate_revision: <candidate revision>
+  - acquired_at: <acquisition time>
+  - generation: <positive integer>
+  - state: <active | released>
+```
+
+Same checkout plus a live other Journey returns `WAITING_ON` with sanitized
+competing Journey and controller identities. Distinct explicitly approved
+compatible worktrees may proceed. Resume keeps the same generation and does
+not duplicate dispatch. Authorized same-Journey candidate progress whose
+parent is the current leased revision refreshes `candidate_revision` on the
+same generation. `COMPLETE` or `CANCELLED` releases the lease exactly
+once. Stale recovery is explicit, recorded, increments generation, and cannot
+steal a live lease. Process discovery cannot replace this durable lease.
 
 ## Always present
 
@@ -54,9 +87,18 @@ Field rules:
 ```markdown
 - candidate_ref: <strongest native revision or changed-path reference available>
 - evidence: <commands run, results observed, and inferences labeled separately>
+- assurance_rounds: <0-3 completed assurance rounds for this candidate lineage>
 ```
 
 `candidate_ref` must not claim stronger provenance than the client can prove.
+`assurance_rounds` counts each candidate version submitted to required assurance
+in one candidate lineage against Bearing Lite `max_assurance_rounds`. A repair
+of the same work stays in the lineage. A new candidate lineage resets the count
+to 0. The parent coordinator writes the count and checks it before redispatched
+assurance. Review and repair rounds are separate budgets, and the cycle ends on
+a repair: `assurance_rounds` counts reviews while `attempts` counts repairs.
+When the last review permits a remaining repair, spend it and close the gate
+without another review.
 
 ## Waiting or correcting only
 

package/skills/crewmate/SKILL.md

@@ -14,7 +14,8 @@ 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.
+  authority, acceptance/SEIT rows, commands, cadence, stop rule, return schema,
+  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.
@@ -22,7 +23,15 @@ Lowest mutation authority and highest hands-on work in the Bearing ladder.
 ## Algorithm
 
 1. Start a fresh session and confirm candidate continuity, boundaries, and clean
-   dependency state. Do not infer missing owner choices.
+   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
+   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
+   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

package/skills/explorer/SKILL.md

@@ -3,35 +3,52 @@ name: explorer
 description: >
   Own one approved execution wave, dispatching bounded fresh-session packets
   and integrating their evidence. Use for Explorer Journey, wave orchestration,
-  or parallel packet sequencing. Do not use for implementation, cross-wave
-  Trail Boss work, planning, automatic nesting, or independent assurance.
+  proven-independent in-wave lanes, or parallel packet sequencing. Do not use
+  for implementation, cross-wave work, planning, automatic nesting, or
+  independent assurance.
 ---
 
 # Explorer
 
-Wave authority. Coordinates more and implements less than Sub-Explorer.
+Wave authority. Coordinates more and implements less than Crewmate.
 
 ## Inputs and match
 
 - **Inputs:** approved baseline, wave objective, packet graph, dependencies,
-  scope, authority, lineup, review cadence, acceptance, and return schema.
-- **Match:** one wave needs packet sequencing, dispatch, or integration.
+  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.
 
 ## Algorithm
 
 1. Start fresh and verify wave readiness, exact packet boundaries, dependencies,
-   and approved primary/fallback identities.
-2. Use direct Crewmates by default. Add one Sub-Explorer only for at least two
-   proven-independent lanes where it materially reduces conflict or context.
+   and approved primary/fallback 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 on the same generation. The same valid lease continues
+   without duplicate dispatch.
+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 at `per-slice` or after each integrated execution
    or correction round at `per-round`. At `at-end`, an Explorer Journey reviews
    its final wave once; an Expedition wave defers assurance to the Navigator's
-   final Journey boundary. Deterministic checks always run.
+   final Journey boundary. Deterministic checks always run. 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.
 
 ## Return and recovery
 

package/skills/gather-supplies/SKILL.md

@@ -13,8 +13,9 @@ Planning node, not a persona or plan-state writer.
 
 ## Match and inputs
 
-- **Match:** a Journey choice or material scope, behavior, authority, risk, or
-  acceptance decision is unresolved.
+- **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.
 - **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,
@@ -25,21 +26,28 @@ Planning node, not a persona or plan-state writer.
 1. Inspect the repository and available evidence before asking. Never ask the
    owner for a fact tools can establish.
 2. Select the earliest unresolved decision whose dependencies are satisfied.
-3. Ask exactly one question. Lead with the recommended answer and why, then
-   explain only material alternatives and tradeoffs. Wait for the owner.
+3. Ask exactly one question, relayed to the owner through the Router. Lead
+   with the recommended answer and why, then explain only material
+   alternatives and tradeoffs. Wait for the owner.
 4. Challenge vague terms, contradictions, unsafe assumptions, and incomplete
    acceptance. A default, probability, or silence is not approval.
 5. Follow the affected dependency branch. Revisit an earlier answer when new
    evidence conflicts; otherwise do not replay it.
-6. Return each confirmed decision immediately to the Router for recording.
-7. When no material branch remains, summarize the shared interpretation and ask
-   for explicit confirmation that shared understanding has been reached.
+6. Buffer confirmed decisions in the active session. Do not persist, patch, or
+   re-render Journey state after each answer.
+7. Return one consolidated decision batch to the Router at a natural checkpoint:
+   the dependency branch is complete, Map the Route is next, handoff/context
+   loss is imminent, or the owner requests a flush.
+8. When no material branch remains, summarize the shared interpretation and ask
+   for explicit confirmation that shared understanding has been reached; then
+   return the final decision batch.
 
 ## Return and recovery
 
 Return `DECISION_CONFIRMED`, `SHARED_UNDERSTANDING_CONFIRMED`,
 `NEEDS_EVIDENCE`, or `OWNER_DECISION_REQUIRED` with decision ID, answer,
-rationale, affected requirements, remaining branch, and next action. Stop after
-three evidence-changing attempts on one blocked decision.
+rationale, affected requirements, buffered decision count, remaining branch,
+checkpoint, and next action. Stop after three evidence-changing attempts on one
+blocked decision.
 
 Never write Journey state, choose for the owner, design, or implement.

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

@@ -14,30 +14,33 @@ 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 lineup/cadence, repository rules, and return schema.
+  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 `<journey-topic>-spec.md` from the confirmed title and return the name
-   for owner verification before first write. Never require generic `plan-spec.md`.
-2. Write the testable specification and self-contained offline `review.html`.
-   Open the exact HTML in the user's browser and verify the launcher/process.
-3. After specification approval, select and record suitable design lenses
-   without asking unless owner intent changes. Write `design.md`, then `seit.md`;
-   draft `implementation.md` only after both prospective gates are complete.
+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 lineup and review cadence into implementation and HTML.
-   Show named active, standby, and unused role instances.
-6. Generate the final HTML with deep zoomable diagrams for architecture, state,
-   interactions, failures, dependencies, and ownership. Put the recommended
-   Journey path in Implementation, open it, and request owner approval.
+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.
 
 ## Return and recovery
 
-Return `SPEC_REVIEW_READY`, `PLAN_REVIEW_READY`, `NEEDS_OWNER_DECISION`, or
-`VALIDATION_FAILED` with artifact paths, evidence, blocker, and next action.
-After final approval, `review.html` is authoritative. At most three
-evidence-changing correction rounds; never invent approval or implement.
+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.

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

@@ -76,8 +76,8 @@ placeholders, bare negations, or deferral language.
 
 ## Completion boundary
 
-The first review gate needs the topic-specific specification and `review.html`.
-After approval, complete-route work remains incomplete until that specification,
-`design.md`, `seit.md`, and `implementation.md` are current. Bearing then
-generates and opens the complete `review.html`; it becomes authoritative only
-after owner approval.
+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.

package/skills/navigator/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: navigator
 description: >
-  Sequence dependency-connected Expedition waves, fresh-session coordinators,
-  and integration boundaries. Use for Navigator, Expedition, or multi-wave
+  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.
 ---
@@ -14,20 +14,37 @@ Highest execution authority below Router; performs the least hands-on execution.
 ## Inputs and match
 
 - **Inputs:** approved artifacts, wave graph, dependencies, repository scope,
-  authority, lineup, review cadence, acceptance, and return schema.
-- **Match:** an Expedition has multiple dependency-connected waves or phases.
+  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.
 
 ## Algorithm
 
 1. Start fresh and reread the approved specification, design, SEIT,
    implementation, and review baseline. Verify snapshot lineup and cadence.
-2. Sequence fresh Explorer sessions. Add Trail Boss only for simultaneous waves
-   with shared-interface or dependency conflicts.
+   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.
 

package/skills/park-ranger/SKILL.md

@@ -34,6 +34,18 @@ Independent defect assurance, outside the mutation-authority ladder.
 
 Return `BLOCK`, `REPAIR_REQUIRED`, `ACCEPT_WITH_FINDINGS`, or `ACCEPT` with
 candidate ref, findings, evidence, verdict, blocker, next action, and receiver.
-Review again only after candidate-changing repairs, at most three rounds.
+`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.
 
 Never edit, self-review, duplicate general review, or grant publication rights.

package/skills/repository-fit/SKILL.md

@@ -27,7 +27,8 @@ Fresh planning node. It returns evidence; the Router records the decision.
    owner evidence with a typed finding.
 4. Propose exactly one repository and one plan-directory assumption with path
    evidence and a short reason.
-5. Ask one owner confirmation question. A recommendation is not confirmation.
+5. Return one owner confirmation question through the Router. A recommendation
+   is not confirmation.
 
 ## Return and recovery
 

package/skills/validator/SKILL.md

@@ -33,8 +33,10 @@ Independent assurance responsibility, outside the mutation-authority ladder.
 ## Return and recovery
 
 Return `PASS`, `NEEDS_MORE_EVIDENCE`, or `FAIL` with candidate ref, criteria,
-evidence, findings, blocker, next action, and receiver. Re-evaluate only a new
-candidate or materially new evidence, at most three rounds.
+evidence, findings, blocker, next action, and receiver. `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.
 
 Never implement, repeat unchanged review, replace Park Ranger/Surveyor, or
 grant owner-only approval.

package/skills/sub-explorer/SKILL.md

@@ -1,39 +0,0 @@
----
-name: sub-explorer
-description: >
-  Coordinate at least two proven-independent lanes inside one Explorer wave in
-  a fresh session. Use for Sub-Explorer or necessary in-wave lane coordination.
-  Do not use for one lane, nested Sub-Explorers, implementation, cross-wave
-  control, planning, or assurance.
----
-
-# Sub-Explorer
-
-Second mutation-authority level; coordinates more and implements less than a
-Crewmate. Maximum one Sub-Explorer level.
-
-## Inputs and match
-
-- **Inputs:** parent wave, lane boundaries, packet specs, dependencies,
-  authority, lineup identities, cadence, and return schema.
-- **Match:** two or more disjoint lanes materially reduce context or conflict.
-- **Non-match:** direct packets suffice, independence is unproven, or another
-  Sub-Explorer level is requested.
-
-## Algorithm
-
-1. Start fresh; verify parent authority, lane disjointness, dependencies, and
-   approved primary/fallback identity for each node.
-2. Dispatch fresh Crewmate sessions with only their bounded packet and evidence.
-3. Track returns by packet ID; preserve foreign changes and never write a packet.
-4. Reconcile lane evidence and return conflicts to the Explorer.
-5. Request assurance only at the recorded cadence boundary and only through the
-   parent coordinator.
-
-## 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. Allow three evidence-changing corrections per lane.
-
-Never implement, add nesting, expand the wave, or provide assurance.

package/skills/trail-boss/SKILL.md

@@ -1,40 +0,0 @@
----
-name: trail-boss
-description: >
-  Coordinate concurrent Explorer waves that share interfaces, dependencies, or
-  integration conflicts in a fresh session. Use for Trail Boss, cross-wave
-  readiness, or integration ordering. Do not use for one wave, packet work,
-  planning, model selection, review, grading, or assurance.
----
-
-# Trail Boss
-
-Cross-wave authority. Coordinates more and implements less than Explorer.
-
-## Inputs and match
-
-- **Inputs:** approved wave graph, lane status, shared interfaces, dependencies,
-  authority, lineup, cadence, budgets, and return schema.
-- **Match:** at least two active Explorer waves require conflict or integration
-  control.
-- **Non-match:** one Explorer can sequence all work or the request is execution
-  or assurance.
-
-## Algorithm
-
-1. Start fresh; verify every wave owner, dependency edge, shared interface, and
-   candidate boundary.
-2. Schedule readiness and integration order. Serialize conflicting writes;
-   allow parallel waves only when independence is proven.
-3. Dispatch fresh Explorer sessions with bounded wave packets and named lineup.
-4. Reconcile typed returns and surface interface drift without repairing it.
-5. Tell the Navigator when the cadence boundary is ready for assurance; never
-   create an extra review round.
-
-## 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. Try at most three evidence-changing schedules.
-
-Never implement, absorb Explorer work, self-assure, or expand authority.

package/skills/trail-boss/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Trail Boss"
-  short_description: "Coordinate approved Expedition Explorer lanes"
-  default_prompt: "Use $trail-boss to coordinate the approved Expedition wave graph."