@alphazede/bearing-lite 0.2.1 → 1.0.0

package/skills/planning-and-design/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: planning-and-design
+description: >
+  Create or resume Bearing's complete five-artifact planning package after
+  material decisions are settled. Use for Planning and Design or missing
+  planning artifacts. Do not use to implement, select models, self-approve, or
+  bypass the single integrated owner review.
+---
+
+# Planning and Design
+
+Fresh planning node. The Orchestrator writes Lifecycle state and owns conversation.
+
+## Match, inputs, and non-match
+
+- **Match:** material intent is settled and any technical-plan, design, SEIT,
+  implementation graph, or DoD Manifest is missing.
+- **Inputs:** confirmed decisions, workspace.md and evidence, artifact status,
+  requirements register, repository rules, proposed owner-supplied profile and
+  cadence, plus the return schema.
+- **Non-match:** unresolved material scope, behavior, authority, risk, or
+  acceptance intent returns `REROUTE_SCOPE_DEFINITION`; generate no
+  `implementation.json` or Manifest.
+
+## Procedure
+
+1. Derive `<lifecycle-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 Lifecycle-local
+   criteria; author the needed Lifecycle-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, do not drop
+   Lifecycle-level proof or published-standard clause coverage, and select Reverify only on applicable binary-level SEIT claims.
+3. Map the implementation graph and propose development strategy
+   (`single_implementer` default or `tdd`), role states, profile, reasoning, and
+   cadence. Bind the one planning-review slot 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, freeze: `node <plugin root>/hooks/plan-package.cjs <plan dir>`
+   must PASS; any finding halts. Then generate `implementation.json` and the
+   DoD Manifest input together. Each includes the proposed
+   route, profile, role states, reasoning, cadence, traceability, waves,
+   recovery, approval boundaries, and register references versus Lifecycle-local
+   requirements. DoD Manifest states: `planning` then append-only closeout.
+5. Give every slice stable requirement/design/SEIT IDs, dependencies, exact
+   write set, authority, role, session rule, evidence, recovery, and stop rule.
+6. Follow `../bearing-lite/references/owner-stops.md`.
+   Open and verify the Manifest, then request exactly one integrated owner review
+   of outcome, design, route, profile, cadence, and plan. Dispatch remains
+   prohibited until approval. An owner change regenerates affected artifacts,
+   then returns to this same gate; never insert a profile or route pause.
+
+## Return and recovery
+
+Return `PLAN_REVIEW_READY`, `REROUTE_SCOPE_DEFINITION`,
+`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 → planning-and-design}/references/artifact-grammar.md

@@ -1,13 +1,14 @@
-# Map the Route Artifact Grammar
+# Planning and Design Artifact Grammar
 
 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
+The canonical Lifecycle planning artifacts are exactly
+`<lifecycle-topic>-technical-plan.md` with `type: technical-plan`, `design.md`,
+`seit.json`, `implementation.json`, and the Definition of Done Manifest
+(`<plan-name>-dod-manifest.html`). Markdown carries
 technical-plan and design reasoning; the JSON files are schema-validated
-machine authorities; `review.html` is their complete integrated human
+machine authorities; the DoD Manifest is their complete integrated human
 projection. There is no sixth canonical planning artifact. XLSX may be an
 optional derived export and is never authority.
 
@@ -20,17 +21,18 @@ optional derived export and is never authority.
    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,
+3. `<lifecycle-topic>-technical-plan.md` declares requirements, Entry criteria,
    Exit criteria, Rollback or repair, and Accountable controller. `design.md`
    declares design IDs. `seit.json` declares SEIT rows and commands.
 4. Preserve stable IDs. Every implementation reference resolves to a declared
    requirement, design contract, SEIT row, and command.
-5. Owner-supplied lineup identities and proposed `review_cadence: at-end` are
+5. Owner-supplied profile identities and proposed cadence (`slice`, `phase`, or
+   `lifecycle`) are
    required before implementation drafting; missing identities or cadence block
-   drafting. Do not offer `per-slice` or `per-round`. Map the proposed Journey
+   drafting. Map the proposed Lifecycle
    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:
+   the final implementation and DoD Manifest record those proposals together.
+6. The profile snapshot contains the Lifecycle-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
@@ -38,31 +40,31 @@ optional derived export and is never authority.
 
 ## Requirements register
 
-1. Before authoring a Journey specification, establish whether the target
+1. Before authoring a Lifecycle 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
+   (`AC-X derives from REG-ID`), or Lifecycle-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.
+   Lifecycle-level proof for it or return `NEEDS_OWNER_DECISION` when register
+   authority is unclear; do not silently drop coverage. Lifecycle-level proof
+   rows remain Lifecycle-local.
+5. The DoD Manifest marks every requirement as either a register reference or
+   Lifecycle-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.
-7. A specification-authoring Journey carries its requirement register (UID,
+7. A specification-authoring Lifecycle carries its requirement register (UID,
    statement, rationale, verification method, allocation) as a planning
    artifact: a draft `.sdoc` path (Markdown sections are not lint-checkable),
    recorded as `implementation.json` `journey_settings.journey_type:
    specification` plus `journey_settings.requirement_register`. The freeze
    fails without an existing register; the Requirements Engineer gates it
-   before the integrated owner review; no Expedition wave re-gates it.
+   before the integrated owner review; no later implementation wave re-gates it.
 
 ## Published standards
 
@@ -96,7 +98,7 @@ optional derived export and is never authority.
 
 ## Implementation rules
 
-1. Regular JSON is the nested execution authority for Journey settings, lineup
+1. Regular JSON is the nested execution authority for Lifecycle settings, profile
    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`,
@@ -106,10 +108,10 @@ optional derived export and is never authority.
 3. `work_class` is `light` or `judgement` (default). A `light` slice names
    the Light Implementer role, at least one command id, and a
    `work_class_reason`; see `skills/light-implementer` for the criteria.
-4. For `journey_type: specification`, a specification-authoring Expedition
+4. For `journey_type: specification`, a specification-authoring implementation
    wave defaults to scaffold → author from the gated register → Test Engineer
    verification cases → bind to the host → readback of the bound revision and
-   digest from the host → Park Ranger with both named in the review
+   digest from the host → Reviewer with both named in the review
    request → owner decision. A deviation is a planning-review finding.
 5. Optional fields are Shared interfaces (`path#Symbol`), Integration
    boundary, Published standard (`doc#clause`) when applicable, SysML and
@@ -144,16 +146,16 @@ 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.
+3. Every feature diagram must include canonical, reviewable source (such as Mermaid code blocks), render visually inside generated DoD Manifest 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 technical-plan, design, SEIT, implementation, and review HTML in that
+Author technical-plan, design, SEIT, implementation, and DoD Manifest 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
+HTML together after their stable inputs. The DoD Manifest has two states:
+`planning` before implementation and append-only 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.
+approvals. The HTML becomes a frozen projection only after integrated owner approval.

package/skills/prompt/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: prompt
+description: Write a bounded execution prompt for another agent.
+type: agent-skill
+title: Write Agent Handoff
+okf_status: active
+tags:
+  - internal
+  - skills
+---
+
+# Write Agent Handoff
+
+Create the smallest prompt that allows one agent to perform one responsibility and return verifiable evidence.
+
+## Structure
+
+Use only these sections:
+
+```text
+ROLE
+STATE
+OBJECTIVE
+AUTHORITY
+LOOP
+VERIFY
+RETURN
+STOP
+```
+
+## ROLE
+
+Name one agent role.
+
+State what that role is responsible for.
+
+Do not give the agent responsibilities owned by another role.
+
+```text
+ROLE
+Crewmate
+
+RESPONSIBILITY
+Implement one approved slice.
+```
+
+## STATE
+
+Describe the current known state.
+
+Separate facts from assumptions.
+
+```text
+STATE
+Phase: Authentication
+Slice: AUTH-3
+Status: ready
+Baseline: commit abc123
+Current failure: unauthorized paths are accepted
+```
+
+Include exact paths, revisions, commands, identifiers, and unresolved failures when available.
+
+Do not paste information the agent can retrieve cheaply.
+
+## OBJECTIVE
+
+Define one observable outcome.
+
+```text
+OBJECTIVE
+Reject unauthorized paths without changing valid-path behavior.
+```
+
+The objective should describe the result, not vague activity such as “investigate” or “work on.”
+
+## AUTHORITY
+
+Define what the agent may and may not change.
+
+```text
+AUTHORITY
+Allowed paths:
+- src/path-policy.ts
+- test/path-policy.test.ts
+
+Prohibited:
+- architecture changes
+- public API changes
+- unrelated cleanup
+```
+
+Preserve authority already granted by the controlling workflow.
+
+Do not invent permissions, budgets, deadlines, or reasoning levels.
+
+Do not specify a reasoning level for the agent unless the owner has explicitly instructed one. Otherwise omit it and let the agent's configured model default apply.
+
+## LOOP
+
+Write the shortest controlled execution loop.
+
+```text
+LOOP
+
+1. Observe the current code and evidence.
+2. State a change hypothesis.
+3. Make the smallest allowed change.
+4. Run focused verification.
+5. Inspect the result.
+6. If verification fails, classify the failure.
+7. Retry only with a new hypothesis or new evidence.
+8. Stop when the objective is proven or a genuine blocker exists.
+```
+
+Adapt the loop to the role.
+
+### Crewmate Loop
+
+```text
+Observe
+→ Hypothesize
+→ Implement
+→ Test
+→ Report
+```
+
+### Validator Loop
+
+```text
+Read contract
+→ Inspect evidence
+→ Challenge proof
+→ Classify
+→ Report
+```
+
+### Park Ranger Loop
+
+```text
+Inspect diff
+→ Trace behavior
+→ Find introduced defects
+→ Prove findings
+→ Report verdict
+```
+
+### Explorer Loop
+
+```text
+Read phase state
+→ Select ready work
+→ Dispatch agent
+→ Evaluate returned evidence
+→ Advance, repair, or escalate
+```
+
+### Navigator &Trail Boss Loop
+
+```text
+Read global state
+→ Identify ready phases
+→ Allocate Explorers
+→ Monitor dependencies
+→ Resolve conflicts
+→ Integrate or escalate
+→ Completeness you have authority except for OWNER DECISions
+```
+
+## VERIFY
+
+Define how success is proven.
+
+```text
+VERIFY
+- CMD-UNIT-AUTH passes
+- unauthorized path test fails before repair and passes afterward
+- existing valid-path tests remain passing
+- no files outside the write set change
+```
+
+Verification must use observable evidence.
+
+Do not use statements such as:
+
+```text
+The solution looks correct.
+The agent is confident.
+The implementation appears complete.
+```
+
+## RETURN
+
+Require a machine-routable result.
+
+```text
+RETURN
+
+Outcome:
+- PASS
+- REPAIRABLE_FAILURE
+- CONTRACT_FAILURE
+- ENVIRONMENT_FAILURE
+- NEEDS_MORE_EVIDENCE
+- OWNER_DECISION_REQUIRED
+
+Include:
+- changed paths
+- commands executed
+- evidence
+- remaining risks
+- blocker, if any
+```
+
+## STOP
+
+Define genuine stop conditions.
+
+```text
+STOP WHEN
+- the objective is proven
+- authority is insufficient
+- the contract cannot be satisfied honestly
+- required evidence cannot be produced
+- an owner or architecture decision is required
+```
+
+Do not stop merely because the work is difficult.
+
+## Final Check
+
+Before returning the handoff, confirm:
+
+```text
+- One role
+- One objective
+- Known starting state
+- Clear authority
+- Controlled loop
+- Observable verification
+- Structured return
+- Genuine stop conditions
+```
+
+Remove repetition, conversation history, generic advice, and unnecessary explanation.

package/skills/requirements-engineer/SKILL.md

@@ -2,8 +2,8 @@
 name: requirements-engineer
 description: >
   One Requirements Engineer role, planning stage only. Use for the
-  requirement register quality gate after Gather Supplies and before the
-  Systems Modeler finalizes mappings. Do not use inside an Expedition wave,
+  requirement register quality gate after Scope Definition and before the
+  Systems Modeler finalizes mappings. Do not use inside a Lifecycle wave,
   or for V&V, SysML modeling, implementation, defect review, or publication.
 ---
 
@@ -11,10 +11,10 @@ description: >
 
 One role, one planning session. It owns requirement quality: every statement
 is precise, measurable, traceable, allocated, and verification-ready.
-Requirements are fixed at plan approval; an Expedition wave stores, binds,
+Requirements are fixed at plan approval; a Lifecycle wave stores, binds,
 adds verification cases, and publishes approved statements and never re-gates
-them (the Assurance Test Engineer re-verifies at wave end). It never persists
-SDoc, publishes, selects models or lineups, or writes tests.
+them (the Assurance Test Engineer re-verifies at the cadence boundary). It never persists
+SDoc, publishes, selects models or profiles, or writes tests.
 
 ## Inputs and match
 
@@ -26,17 +26,17 @@ SDoc, publishes, selects models or lineups, or writes tests.
   output, compact return schema.
 - **Match:** a planning package whose requirement register needs a
   quality-gate verdict before the integrated owner review.
-- **Non-match:** any Expedition wave, design, SEIT, implementation, Park
-  Ranger, Surveyor.
+- **Non-match:** any implementation wave, design, SEIT, implementation, Reviewer,
+  Integration Engineer execution.
 
 ## Algorithm
 
-1. Run after Gather Supplies and before the Systems Modeler finalizes
+1. Run after Scope Definition and before the Systems Modeler finalizes
    mappings, on the requirement statements themselves: gate every register
    row's statement, rationale, verification method, and allocation, and the
    `AC-*`/`RISK-*` rows that cite them, against the NASA-adapted checklist;
    reject escape clauses and undefined terms; every row cites its register
-   identity or is marked Journey-local.
+   identity or is marked Lifecycle-local.
 2. Cite the mechanical output (`lint-sdoc.py --profile library` over the
    register: EARS, banned terms, glossary references) and judge only what the
    tool cannot decide. Missing tool output is `NEEDS_MORE_EVIDENCE`.
@@ -48,8 +48,8 @@ SDoc, publishes, selects models or lineups, or writes tests.
 
 Return `PASS`, `REPAIRABLE_FAILURE`, `NEEDS_MORE_EVIDENCE`, or
 `NEEDS_OWNER_DECISION` with verdict, candidate_ref, changed_paths, per-row
-findings, and blocker. Rerun the gate on each corrected register within Map the
-Route's correction rounds. Exhaustion with fixable rows returns
+findings, and blocker. Rerun the gate on each corrected register within Planning and
+Design's correction rounds. Exhaustion with fixable rows returns
 `NEEDS_OWNER_DECISION` listing those rows, never silent acceptance. Missing
 `requirements-engineering` method skill is a typed capability gap.
 

package/skills/{park-ranger → reviewer}/SKILL.md

@@ -1,34 +1,37 @@
 ---
-name: park-ranger
+name: reviewer
 description: >
   Independently review one exact stable candidate for introduced actionable
-  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.
+  defects in a fresh session at the configured cadence boundary. Use for
+  Reviewer, code review, or defect adjudication. Do not use for implementation,
+  automatic review, evidence scoring, user acceptance, author self-review, or
+  unconfigured slice/round boundaries.
 ---
 
-# Park Ranger
+# Reviewer
 
 Independent defect assurance, outside the mutation-authority ladder.
 
 ## Inputs and match
 
 - **Inputs:** approved baseline, exact candidate ref and diff, author identity,
-  relevant evidence, declared phase or wave end boundary, review focus, and
+  relevant evidence, declared cadence boundary, review focus, and
   compact return schema.
-- **Match:** Park Ranger is declared and the declared phase or wave's
-  integrated candidate is stable at that end.
-- **Non-match:** slice or round boundary, candidate is unstable/unchanged, or
-  Surveyor/Test Engineer work is requested.
+- **Match:** Reviewer is declared and the configured slice, phase, or
+  lifecycle candidate is stable at that boundary. Default cadence is `phase`.
+- **Non-match:** unconfigured slice or round boundary, candidate is
+  unstable/unchanged, or Test Engineer / Integration Engineer execution work
+  is requested.
 
 ## Algorithm
 
 1. Start a fresh session; reject author identity, author ancestry, candidate
-   discontinuity, or any boundary other than the declared phase or wave end.
+   discontinuity, or any boundary other than the declared cadence unit.
    Consume the Assurance
    Test Engineer receipt. Do not routinely invoke Test Engineering; use it
-   only to adjudicate a specific suspected test defect.
+   only to adjudicate a specific suspected test defect. Deterministic
+   verification may support a suspected defect; author diagnostics cannot
+   satisfy assurance, and post-repair closure adds no review round.
 2. Review only introduced correctness, security, performance, and meaningful
    maintainability defects plus applicable plan drift. When the candidate
    implements a published standard, compare the change against the cited text

package/skills/{gather-supplies → scope-definition}/SKILL.md

@@ -1,22 +1,22 @@
 ---
-name: gather-supplies
+name: scope-definition
 description: >
-  Relentlessly resolve material owner decisions for a Bearing Journey, one
+  Relentlessly resolve material owner decisions for a Bearing Lifecycle, one
   dependency-ordered question at a time, until shared understanding is explicit.
-  Use for Gather Supplies or unresolved plan intent. Do not use for discoverable
+  Use for Scope Definition or unresolved plan intent. Do not use for discoverable
   repository facts, design drafting, implementation, or settled decisions.
 ---
 
-# Gather Supplies
+# Scope Definition
 
-Planning node, not a persona or plan-state writer.
+Planning node after Architectural Alignment, not a persona or plan-state writer.
 
 ## Match and inputs
 
 - **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 route review after Map the Route
-  maps the implementation graph.
+  decision is unresolved. Development strategy is not gathered here; the
+  Orchestrator records `single_implementer` or `tdd` from the profile or an
+  explicit owner choice in `implementation.json`.
 - **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,
@@ -33,7 +33,7 @@ Planning node, not a persona or plan-state writer.
    `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
+3. Ask exactly one question, relayed to the owner through the Orchestrator. 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
@@ -41,9 +41,9 @@ Planning node, not a persona or plan-state writer.
 5. Follow the affected dependency branch. Revisit an earlier answer when new
    evidence conflicts; otherwise do not replay it.
 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
+   re-render Lifecycle state after each answer.
+7. Return one consolidated decision batch to the Orchestrator at a natural checkpoint:
+   the dependency branch is complete, Planning and Design 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
@@ -57,4 +57,4 @@ 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.
+Never write Lifecycle state, choose for the owner, design, or implement.

package/skills/scribe/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: scribe
 description: >
-  Transcribe Journey decisions, authority events, ledger snapshots, and
-  lineup selections as an event side lane. Use for Scribe. Do not use to
-  activate authority, invent choices, or save lineups unless the owner
+  Transcribe Lifecycle decisions, authority events, ledger snapshots, and
+  profile selections as an event side lane. Use for Scribe. Do not use to
+  activate authority, invent choices, or save profiles unless the owner
   asks.
 ---
 
@@ -13,17 +13,21 @@ Event side lane. Transcribes; cannot activate authority.
 
 ## Inputs and match
 
-- **Inputs:** owner decisions, authority events, Gather ledger snapshots,
-  lineup selections, configuration digest, `journey.json`.
-- **Match:** a visible Journey event must be appended to history.
+- **Inputs:** owner decisions, authority events, Scope Definition ledger snapshots,
+  profile selections, configuration digest, `journey.json`.
+- **Match:** a visible Lifecycle event must be appended to history.
 - **Non-match:** planning dispatch, specialist engineering, execution.
 
 ## Algorithm
 
-1. Append owner decisions, authority events, ledger snapshots, lineup
+1. Append owner decisions, authority events, ledger snapshots, profile
    selections, and configuration digest to `journey.json` history.
+   Follow `../bearing-lite/references/owner-stops.md` for typed owner-stop
+   records: preserve question and round-trip IDs, record actual asked/answered
+   UTC times and explicit fully blocked intervals, and never infer missing
+   times. Automatic resolutions and owner steering are not invented questions.
 2. Do not activate authority or invent unresolved choices.
-3. Do not write Journey selections into `lineups.json` unless the owner
+3. Do not write Lifecycle selections into `profiles.json` unless the owner
    asks to save a reusable profile.
 
 ## Return and recovery

package/skills/systems-modeler/SKILL.md

@@ -2,13 +2,15 @@
 name: systems-modeler
 description: >
   Select modeling mode and attach view metadata after Requirements
-  Engineer work and before design finalization. Use for Systems Modeler.
-  Do not finalize requirement mappings against unstable requirements.
+  Engineer work and before design finalization. Use for Systems Modeler
+  planning session. Do not finalize requirement mappings against unstable
+  requirements.
 ---
 
 # Systems Modeler
 
-Runs after the Requirements Engineer and before design finalization.
+One role with a planning session. Runs after the Requirements Engineer and
+before design finalization.
 
 ## Inputs and match