@openrig/cli 0.5.10 → 0.5.11

package/daemon/docs/reference/project-release-profile.yaml

@@ -0,0 +1,82 @@
+schema: openrig.project/v0alpha1
+kind: project
+metadata: { id: example }
+missions: { root: missions }
+lifecycle:
+  profile: release-boundary-v0
+  profiles:
+    release-boundary-v0:
+      required_steps:
+        - mission-outcome
+        - exact-release-candidate
+        - capability-delta
+        - exact-cut-substance
+        - release-verification
+        - git-canonicalization
+        - public-release
+        - parent-adoption
+        - record-shipped
+        - release-boundary
+      workflow:
+        entry: { role: orchestrator }
+        roles:
+          orchestrator: { preferred_targets: [orch@example] }
+        steps:
+          - id: mission-outcome
+            actor_role: orchestrator
+            depends_on: []
+            objective: Judge the mission's promised outcomes against retained evidence; name remaining gaps.
+            allowed_exits: [handoff, waiting, failed]
+          - id: exact-release-candidate
+            actor_role: orchestrator
+            depends_on: [mission-outcome]
+            objective: Establish the exact candidate and tree to which subsequent receipts apply.
+            allowed_exits: [handoff, waiting, failed]
+          - id: capability-delta
+            actor_role: orchestrator
+            depends_on: [exact-release-candidate]
+            objective: Reconcile the shipped capability description with this candidate's actual behavior.
+            allowed_exits: [handoff, waiting, failed]
+          - id: exact-cut-substance
+            actor_role: orchestrator
+            depends_on: [capability-delta]
+            objective: Obtain and judge independent substance admission for the exact release cut.
+            allowed_exits: [handoff, waiting, failed]
+          - id: release-verification
+            actor_role: orchestrator
+            depends_on: [exact-cut-substance]
+            objective: Judge privacy, package shape, conventions and mirrors, builds, tests, and clean-tree evidence for the exact admitted release candidate.
+            allowed_exits: [handoff, waiting, failed]
+          - id: git-canonicalization
+            actor_role: orchestrator
+            depends_on: [release-verification]
+            objective: Obtain the authorized canonical Git identity and reconcile it with the verified candidate.
+            allowed_exits: [handoff, waiting, failed]
+          - id: public-release
+            actor_role: orchestrator
+            depends_on: [git-canonicalization]
+            objective: Obtain publication authorization and the release owner's exact public artifact receipt.
+            allowed_exits: [handoff, waiting, failed]
+          - id: parent-adoption
+            actor_role: orchestrator
+            depends_on: [public-release]
+            objective: Obtain separately authorized parent adoption and judge its effect receipt.
+            allowed_exits: [handoff, waiting, failed]
+          - id: record-shipped
+            actor_role: orchestrator
+            depends_on: [parent-adoption]
+            objective: Record durable shipped truth after judging ceremony receipts; the post-release boundary follows.
+            allowed_exits: [handoff, waiting, failed]
+          - id: release-boundary
+            actor_role: orchestrator
+            depends_on: [record-shipped]
+            objective: >-
+              After the release ceremony, author one attributed disposition record
+              covering seat renewal and re-prime, memory distillation, destination
+              queue sweep, substrate teardown or retention, board freeze and clean-box
+              baseline, capability-delta absorption and expiry, and packaged-product
+              discoverability. These are agent-judged guides, not seven daemon gates.
+              Inspect beyond this packet when useful. Record reasoned not-applicable
+              or deferred dispositions and wait on live dependencies. Finish after
+              this boundary when no successor is authored.
+            allowed_exits: [done, waiting, failed]

package/daemon/docs/reference/release-boundary.md

@@ -52,6 +52,11 @@ playbook.
 
 ## 4. Substrate — teardown as its own atom
 
+- Retain the current release and the immediately previous release. At a boundary
+  for release N, worktrees and other release-scoped substrate from N-2 and older
+  are eligible for cleanup. Eligibility is not permission to discard unique dirty
+  bytes: archive or otherwise disposition those first. Identify live `main` and
+  runtime state by their actual refs and identity, never by a stale directory name.
 - Prune worktrees; remove session-scoped scratch trees; verify merged branches
   deleted (merge receipts authorize).
 - Scratch homes and scenario roots in temp directories: swept.

package/daemon/docs/reference/rig-spec.md

@@ -343,12 +343,51 @@ Startup blocks can appear at three levels: rig, pod, and member. They are merged
 
 | Field | Type | Required | Default | Description |
 |-------|------|----------|---------|-------------|
-| `type` | string | yes | — | Action type. One of: `slash_command`, `send_text`. Note: `shell` is explicitly NOT supported in v1. |
-| `value` | string | yes | — | The command or text to send. |
-| `phase` | string | no | `after_files` | When to execute. One of: `after_files` (after startup files are delivered), `after_ready` (after harness readiness check passes). |
+| `type` | string | yes | — | Action type. One of: `slash_command`, `send_text`, `startup_proof`. Note: `shell` is explicitly NOT supported in v1. |
+| `value` | string | yes | — | Command/text to send, or `authenticated` / `none` for `startup_proof`. |
+| `phase` | string | no | `after_files` | When to execute text/commands. One of: `after_files` (after startup files are delivered), `after_ready` (after harness readiness check passes). Proof selection is resolved before projection regardless of phase. |
 | `idempotent` | boolean | yes | — | Whether this action is safe to replay on restore. **Required field.** Non-idempotent actions must NOT include `restore` in `applies_on`. |
 | `applies_on` | string[] | no | `[fresh_start, restore]` | When this action runs. Subset of: `fresh_start`, `restore`. |
 
+### Startup proof selection
+
+Startup adds no orientation exercise by default. To select the authenticated
+startup challenge, declare an action in an agent, profile, rig, pod, member, or
+operator startup block:
+
+```yaml
+startup:
+  actions:
+    - type: startup_proof
+      value: authenticated
+      idempotent: true
+```
+
+Use `value: none` in a later layer to select lean startup explicitly. The last
+applicable declaration wins in agent → profile → rig → pod → member → operator
+order. Culture contributes files, not a proof selection. With no applicable
+declaration, the result is `none`; the number of startup files never selects
+proof. Invalid values and non-idempotent proof declarations fail validation,
+including declarations overridden later. These actions declare policy and are
+never typed into a terminal.
+
+An authenticated selection challenges only a fresh or fresh-fallback managed
+agent launch. Resumed, forked, rebuilt, and adopted sessions receive no new
+challenge; terminal nodes never receive one. `applies_on` follows the requested
+startup context, so a fresh fallback during restore uses `restore` selections.
+Keep the default `[fresh_start, restore]` to cover both fresh launch paths.
+
+Identity delivery, projection, readiness, and ordinary startup actions still
+run. `startup_status: ready` means startup completed, while `oriented: missing`
+means a selected proof awaits authenticated submission. Omission/`none` yields
+`oriented: n-a` on a new fresh launch and retires an older challenge without
+deleting its audit history. Retirement follows successful harness launch,
+before readiness checks, so attention, timeout, or a readiness exception cannot
+retain the preceding proof. A replacement that fails to launch does not retire
+the current proof; resume/adoption also preserves existing proof history.
+The effective selection is recorded on `node.startup_pending`; actions are
+persisted in startup context for restore and fresh relaunch.
+
 ---
 
 ## Services Block
@@ -477,7 +516,7 @@ These rules are enforced by the validator. A spec that violates any of these wil
 19. Each wait target must define exactly one of: `service`, `url`, `tcp`.
 20. `condition` is only valid on `service` targets and must be `healthy`.
 21. Startup file `delivery_hint` must be one of: `auto`, `guidance_merge`, `skill_install`, `send_text`.
-22. Startup action `type` must be one of: `slash_command`, `send_text`. (`shell` is explicitly rejected.)
+22. Startup action `type` must be one of: `slash_command`, `send_text`, `startup_proof`. (`shell` is explicitly rejected.) Proof selection requires `value: authenticated` or `none` and `idempotent: true`.
 23. Startup action `phase` must be one of: `after_files`, `after_ready`.
 24. Startup action `idempotent` is a required boolean.
 25. Non-idempotent actions must not include `restore` in `applies_on`.

package/daemon/specs/agents/conveyor/planner/guidance/role.md

@@ -1,6 +1,6 @@
 # Role: Conveyor Planner
 
-You are the planning station for the `conveyor` starter rig. Your job is to
+You are a reusable planning station for the selected rig. Your job is to
 convert an accepted work packet into a bounded plan that the build station can
 execute without guessing.
 
@@ -17,8 +17,10 @@ execute without guessing.
 - Read the packet, identify the concrete outcome, and name any missing input.
 - Produce a short plan with expected files, commands, and verification.
 - Keep the plan small enough for one build turn.
-- Hand off to `build-builder@conveyor` with the plan and any constraints the
-  builder must preserve.
+- Derive your seat from `rig whoami --json` and the next role/target from the
+  assigned packet and selected workflow. Return the plan and constraints through
+  the workflow's selected projection/exit when it owns routing; otherwise hand
+  off to the packet's resolved destination. Do not hard-code a starter address.
 - Mark blockers honestly if the packet cannot be planned from available input.
 
 ## Principles

package/daemon/specs/agents/conveyor/planner/startup/context.md

@@ -1,12 +1,21 @@
 # Startup Context
 
-Run `rig whoami --json` before making topology claims. Confirm that your
-session is `plan-planner@conveyor`.
+Run `rig whoami --json` before making topology claims. Derive your actual seat
+and rig from that result; this planner is reused by multiple rigs.
 
 Default workflow role: `planner`.
 
-Receive packets from `intake-lead@conveyor`. Send executable plans to
-`build-builder@conveyor`.
+Read the assigned packet and selected workflow to identify the sender, current
+step and next role/target. An active workflow owns the inner-loop routing:
+return the plan through its selected projection/exit, without a parallel queue
+handoff. Outside a workflow, use the packet's destination resolved against the
+actual rig. Missing routing context is an input to resolve, not a reason to
+guess an address.
+
+For example, the shipped `conveyor` uses `plan-planner@conveyor` and
+`build-builder@conveyor`; `factory-rsi` uses `plan-planner@factory-rsi`
+and routes the plan to its implementer through the workflow. These examples
+do not set the identity or destination of a reused planner.
 
 Keep planning outputs concise: objective, assumptions, steps, verification, and
 handoff notes.

package/daemon/specs/agents/design/product-designer/agent.yaml

@@ -30,9 +30,10 @@ startup:
   actions:
     - type: send_text
       value: >-
-        A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: frontend-design,
-        verification-before-completion. Load them first, then begin the work.
+        Resolve the assigned outcome and its selected procedure. Use frontend-design
+        when shaping an interface and verification-before-completion when validating
+        a result. Load relevant skills when their task arises; this startup action
+        adds no blanket preload or review gate.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/design/product-designer/guidance/role.md

@@ -2,16 +2,18 @@
 
 You are the design side of the product team. Your job is to turn rough product intent into clear user flows, interface structure, and design-system decisions that implementation and QA can execute without guesswork.
 
-## Startup checklist
-
-Load these packaged skills now before giving product direction:
-- `openrig-user`
-- `mission-slice-sop`
-- `development-team`
-- `frontend-design`
-- `verification-before-completion`
-
-Then run `rig whoami --json` and look for the first ambiguity the development pod should not have to guess through.
+## Task-triggered capabilities
+
+Run `rig whoami --json`, resolve the assigned outcome and selected procedure,
+and look for the first ambiguity the development pod should not have to guess through.
+Load skills when the work calls for them:
+- `openrig-user` for command syntax.
+- `mission-slice-sop` for mission/slice operations.
+- `development-team` for coordination under the selected development path.
+- `frontend-design` for interface design.
+- `verification-before-completion` before claiming a verified result.
+
+This list adds no blanket preload or gates beyond the selected task.
 
 ## Responsibilities
 

package/daemon/specs/agents/product-management/pm/guidance/role.md

@@ -3,36 +3,38 @@
 ## Role
 Senior Product Manager. Own the "what" and "why" — never architecture, estimates, or implementation details.
 
-## Skills Loaded
-
-Load these packaged skills now before shaping product work:
-- `openrig-user`
-- `mission-slice-sop`
-- `office-hours`
-- `context-builder`
-- `requirements-writer`
-- `ui-mockup`
-- `plan-review`
-- `exec-summary`
-- `backlog-capture`
+## Task-triggered capabilities
+
+Resolve the assigned outcome and selected procedure. Load `openrig-user` for
+command syntax and `mission-slice-sop` for mission/slice operations. When the
+8-step feature flow below is selected, load each step's named skill as that
+step begins: `backlog-capture`, `office-hours`, `context-builder`,
+`requirements-writer`, `ui-mockup`, `plan-review`, and `exec-summary`.
+Keep that selected flow and its SPEC contract; this list adds no blanket
+preload or feature-flow gate to other assignments.
 
 ## 8-Step Feature Flow
 
 1. **Capture** — run `backlog-capture` and record the idea in `idea_backlog.md`.
 2. **Validate** — run `office-hours` and produce `validation.md` with a `GO`, `REFINE`, or `PAUSE` verdict.
 3. **Context** — run `context-builder` and produce `background.md` using `validation.md` as the starting point.
-4. **Require** — run `requirements-writer` and produce `requirements.md` using `validation.md` and `background.md`.
+4. **Require** — run `requirements-writer` and produce `SPEC.md` using `validation.md` and `background.md`.
 5. **Mockup** — run `ui-mockup` and produce `supporting/mockup-ascii.md` plus one or more `mockup-*.html` artifacts.
 6. **Review** — run `plan-review` and record issues or revisions before handoff.
 7. **Summarize** — run `exec-summary` and produce `executive-summary.md` from the full artifact set.
 8. **Handoff** — prepare the branch/ticket handoff only after the earlier artifacts are coherent.
 
-Each step's output feeds the next. `validation.md` is the foundation for the rest of the feature packet.
+Each step's output feeds the next. The feature folder below is the selected
+slice directory; `SPEC.md` is its single requirements authority.
+`validation.md`, `background.md`, mockups and the executive summary are supporting
+artifacts. For legacy `requirements.md`, preserve it as input/history and
+reconcile its requirements into `SPEC.md` before continuing this flow; do not
+maintain two competing contracts.
 
 ## Working Norms
 
 1. **Research before you build** — every feature needs context (competitive, regulatory, customer) before requirements are finalized.
-2. **Requirements are literal** — AI agents treat requirements.md as instructions. Be precise. No aspirational content.
+2. **Requirements are literal** — AI agents treat SPEC.md as instructions. Be precise. No aspirational content.
 3. **Stay in your lane** — PM writes requirements, researcher gathers context, coder builds prototypes. Escalate when you hit a boundary.
 4. **Write things down** — every step should leave artifacts in the feature folder. Nothing important lives only in conversation.
 
@@ -42,7 +44,7 @@ Each step's output feeds the next. `validation.md` is the foundation for the res
 {feature}/
 ├── validation.md
 ├── background.md
-├── requirements.md
+├── SPEC.md
 ├── executive-summary.md
 └── supporting/
     ├── mockup-ascii.md
@@ -52,5 +54,5 @@ Each step's output feeds the next. `validation.md` is the foundation for the res
 ## Key Outputs
 - validation.md — GO/REFINE/PAUSE verdict on feature ideas
 - background.md — synthesized context for a feature
-- requirements.md — structured acceptance criteria and business rules
+- SPEC.md — structured acceptance criteria and business rules
 - executive-summary.md — single document orienting sales, leadership, and engineering

package/daemon/specs/agents/shared/skills/core/agent-starters/SKILL.md

@@ -23,9 +23,9 @@ A named, reusable per-seat starting point. Composes an agent role, startup
 context, optional native session source, and provenance into something a
 user or rig can choose when creating, refreshing, or packaging a seat.
 
-"Agent image" is the analogy. **Agent Starter is the cleaner product
-noun.** This is NOT a VM image — it is a managed starting point for an
-agent seat, with provenance you can inspect.
+This registry-backed startup context is distinct from the `rig agent-image`
+surface and from a VM image. See the current behavior below before treating
+optional session provenance as an executable native session source.
 
 ## Use this when
 
@@ -49,7 +49,7 @@ Capture the seat as it naturally is at a functional, proven point. Don't pad it
 
 Never compact, summarize, or shrink a seat in order to make or "lean" a starter. There is nothing valuable in "smaller," and compaction is lossy — you would trade away the exact capability the starter exists to preserve. (Compaction is a separate last-resort step for a seat genuinely near its context limit, with its own before/after plan — never part of capturing a starter.)
 
-## State model — 6 states
+## Authoring lifecycle — 6 conceptual states
 
 1. **Captured** — a useful seat/session/context pattern is identified.
 2. **Named** — it becomes an Agent Starter with stable id and owner.
@@ -66,30 +66,32 @@ Never compact, summarize, or shrink a seat in order to make or "lean" a starter.
 4. **Secret leakage** — starter packages or displays provider auth material. **Refuse.** Refer to session sources and context, never copy credentials.
 5. **Runtime mismatch** — starter used with unsupported runtime. **Refuse with a clear error.**
 
-## Manifest shape (v0+v1 shipped)
+## Registry entry and current behavior
+
+Save one entry as `<registry-root>/reviewer-v1.yaml`. The resolver selects an
+explicit root or `OPENRIG_AGENT_STARTER_ROOT`; absent those, it checks the home
+registry `~/.openrig/agent-starters` and a configured fallback.
 
 ```yaml
-agent_starters:
-  - id: velocity-reviewer-v1
-    runtime: claude-code
-    agent_ref: local:reviewer
-    context_refs:
-      - doctrine:advisor-orchestrator-mode-judgment
-      - convention:workstream-continuity
-    session_source:
-      mode: fork
-      ref:
-        kind: native_id
-        value: "<prior-native-session-id>"
+starter_id: reviewer-v1
+role: Review the assigned change against its stated outcome.
+context: Read the current task and the source needed to judge it.
 ```
 
+The current resolver checks the entry shape and credential boundary, then
+delivers this YAML itself as one required `guidance_merge` startup file on a
+fresh start. It does not interpret arbitrary context refs, load a native
+conversation from this example, or seal an image. A RigSpec member combining
+`starter_ref` with `session_source.mode: fork` is currently rejected; use a
+separate supported session-source path when native continuity is the outcome.
+
 Member usage:
 
 ```yaml
 members:
   - id: reviewer
     starter_ref:
-      name: velocity-reviewer-v1
+      name: reviewer-v1
 ```
 
 When a starter points at a primed session produced from a Composable
@@ -113,7 +115,7 @@ Priming Pack, record:
 
 ## Dependencies on other primitives
 
-- **Firm**: `session-source-fork` — native conversation-source continuity for fork-based starters
+- **Separate path**: `session-source-fork` — native conversation-source continuity; currently not composable with `starter_ref`
 - **Firm**: `specification-system` — declarative starter and member references
 - **Soft**: `rig-bundles-and-shareable-artifacts` — shareable starter packaging
 - **Soft**: `context-engineering-and-retrieval` — richer declarative context assembly

package/daemon/specs/agents/shared/skills/core/agent-startup-and-context-ingestion/SKILL.md

@@ -24,8 +24,7 @@ metadata:
 
 How an agent becomes useful after launch: **AGENTS.md overlays, role
 files, skills, rig specs, workflow specs, startup checklists, refocus
-messages**, and any future "rig context" command or skill-librarian
-surface.
+messages**, and the current `rig context` retrieval and profile surface.
 
 It is the current concrete startup path inside the broader
 context-engineering-and-retrieval primitive. Startup gets a seat into
@@ -91,14 +90,16 @@ reentry case, distinct from reusable Agent Starters / priming packs):
 
 ## Memory surfaces consumed at startup
 
-Per the externalized-memory-surfaces convention's 13-row inventory:
+Inventory the selected startup inputs: AGENTS/role/CULTURE overlays, replay
+context, and any declared restore packet or starter. Record where each comes
+from, whether it is current, and why this task needs it. An available skill or
+old packet does not select the work.
 
-- **Row 7** — AGENTS/role/CULTURE/startup overlays (primary)
-- **Row 3** — startup replay context (primary)
-- **Row 12** — restore/reentry packets and Agent Starters (cross-runtime startup path)
-
-The umbrella's authority-rank + permission-posture columns govern which
-surfaces a startup ingestion path can write vs only read.
+Use the task-scoped startup path above to resolve current authority. Permission
+to read an input is not permission to rewrite its source; writes follow the
+active project/rig policy and assignment. Load
+`skills/openrig-operating-model/SKILL.md` with `rig context get` when deciding
+where durable context belongs.
 
 ## Startup files vs skills (the distinction)
 
@@ -123,5 +124,5 @@ culture / pod / member / operator) handles the layering.
 - `session-compaction-and-restore` skill — restore-time startup ingestion
 - `agent-starters` skill — reusable starter manifests that compose startup context
 - `composable-priming-packs` skill — manifests that produce primed sessions
-- `externalized-memory-surfaces` skill — umbrella convention for memory surfaces this primitive consumes
+- `openrig-operating-model` skill — placement and authority of durable context
 - `openrig/docs/reference/agent-startup-guide.md` (product reference doc; not a skill) — the 7-layer additive startup model + delivery hints