@openrig/cli 0.5.9 → 0.5.11

package/daemon/docs/reference/health-diagnosis.md

@@ -0,0 +1,331 @@
+# Agent-operated System Health diagnosis
+
+System Health can give a responsible agent one durable investigation packet when
+a configured detector needs interpretation. The packet preserves the finding,
+policy version, evidence, and current authority documents. It invites the agent
+to investigate beyond that selection, including its own contribution. It does
+not declare a pathology or perform corrective actions.
+
+## Enable a bounded diagnosis loop
+
+```sh
+rig health policy --json > effective-policy.json
+jq '.policy' effective-policy.json > health-policy.json
+# Edit health-policy.json: diagnosis.enabled=true and diagnosis.owner=<seat@rig>.
+rig health policy --file health-policy.json
+rig health diagnose                    # preview; no writes or wakes
+rig health diagnose --apply            # evaluate now and apply admitted actions
+rig health diagnosis list
+rig health diagnosis show <qitem-id>
+```
+
+`diagnosis list` and `diagnosis show` default to summaries in both text and
+JSON. The detailed text summary shows queue state, owner, blocker, disposition,
+uncertainty, finding identity and authority references. Summary JSON also keeps
+the ceremony basis and current receipt identities. It keeps its object/array
+shape and adds `readView`: `complete`, `omittedFields` (paths,
+JSON byte counts and array counts), `fullJsonBytes`, and the exact `fullCommand`.
+Packet copies, authority contents, evidence arrays and the diagnostic receipt ledger
+are omitted explicitly. Current workflow-receipt envelopes remain, with
+`evidenceIdentity` carrying recognized cut/candidate, verdict and evidence-reference
+strings; their opaque evidence is omitted. These identity labels do not validate
+a receipt. A summary is not the complete evidence. Byte counts describe
+compact JSON serialization without the trailing newline, not model token counts.
+
+For investigation or existing consumers that need the former complete JSON:
+
+```sh
+rig health diagnosis show <qitem-id> --full --json > diagnosis.json
+rig health diagnosis list --full --json > diagnoses.json
+```
+
+`--full` without `--json` prints the complete record as formatted JSON. These
+expansions may be large. Plain `--json` no longer includes all evidence fields;
+migrate consumers of those fields to `--full --json`. HTTP API responses and
+mutation-result JSON are unchanged. Full context remains necessary before an
+agent acts on a diagnosis; the generated investigation packet names that command.
+
+The daemon checks enabled policy once per minute. `health policy` reports whether
+that check is scheduled and its last result, including errors. Ordinary `health`
+list/explain commands remain observational. Diagnosis defaults to disabled;
+ceremony amplification is the only default diagnosis trigger. A continuing
+episode keeps one qitem, receives at most one additional presentation by default,
+and shares an owner cooldown across episodes (one hour by default). A disposition
+stops re-presentation. Disabling policy stops automatic admission and presentation.
+Ownership changes do not silently reroute existing occurrences.
+Outside a managed seat, name the writer with `rig health --actor <name> ...`.
+Managed-seat transport identity takes precedence over that declared name.
+Only the occurrence's assigned owner may record its disposition or request human
+notification. Other agents can advise the owner; a policy-owner change does not
+grant custody of existing occurrences. Writes retain the sender's identity
+provenance on the queue transition.
+
+Policy controls detector enablement, ceremony/review/wake thresholds, source
+observation window and freshness, diagnostic owner, cooldown, re-presentation
+bound, and human-escalation conditions. Edit plain JSON and apply it with the
+command; unknown keys and invalid values refuse without changing the policy.
+Applied proposals and their predecessors are retained under the configured
+OpenRig home in `health/policy-history/`. The effective version also includes
+the existing `health.context_pressure.warning_percent` and `critical_percent`
+settings, which remain configurable with `rig config`. Their defaults are 95
+and 99. CLI/TUI finding explanations show the policy version used.
+
+## Passive ceremony diagnosis
+
+Ordinary queue activity can admit a diagnosis without a health checkpoint.
+The source discovers declared handoff families touched in the observation window,
+uses their explicit `mission:` / `slice:` tags, and collects exact transition IDs,
+normal project/mission/slice authority, progress and proof references, and workflow
+closure evidence. It never interprets Markdown or counts proof files, approvals,
+C1 pairing, commits, tests, or terminal rows as accepted product outcomes.
+
+At the configured traffic threshold (20 transitions by default), a fresh,
+complete family becomes `ceremony.stage=needs-diagnosis`, `status=indeterminate`,
+and `severity=info`. CLI/TUI call this **needs diagnosis**, not a confirmed
+warning. Enabled diagnosis policy admits one bounded packet even though the
+product denominator is unknown. Ordinary unavailable/stale detector records
+remain ineligible. Diagnosis and human-notification traffic are excluded from
+the numerator and cannot recursively generate another investigation.
+
+The agent reads the actual evidence, including beyond the supplied references,
+and resolves the semantic outcome granularity and consequence boundary. Use the
+existing disposition command with an optional `progress` result:
+
+```json
+{
+  "basis": "<current finding.ceremony.basis from diagnosis show>",
+  "conclusion": "established",
+  "outcomes": [{"id": "<distinct meaningful outcome>", "observedAt": "<time inside the measured interval>", "evidenceRefs": ["<normal proof path>"]}],
+  "boundedAuthority": false,
+  "boundary": "<selected SDLC boundary and why this outcome census covers the interval>",
+  "evidenceRefs": ["<inspected authority/evidence path>"],
+  "missingFacts": []
+}
+```
+
+Put this object in `progress` beside the existing verdict/steering/uncertainty
+fields. `established` affirms a complete census for the exact interval; an empty
+outcome list affirms zero outcomes, not failed discovery. `false-positive`
+clears the suspicion without inventing a denominator when no missing facts remain.
+A false-positive assessment that still names missing facts stays indeterminate
+and does not close the episode interval. `indeterminate` supplies
+no outcomes and names the missing fact in `missingFacts`. Required references
+must resolve inside the workspace; extra evidence beyond the initial packet is
+allowed. The receipt retains the actual actor, timestamp, identity provenance,
+source basis, and evidence hashes. A changed basis refuses a stale submission.
+Later evidence changes make confirmation indeterminate rather than preserving
+a false ratio. Outcome meaning remains attributed agent judgment.
+
+Only an established, current assessment permits a ratio. The projector computes
+it from the distinct listed outcomes and exact transitions; a qualifying ratio
+with no bounded-authority counter-signal becomes `confirmed` / `active` /
+`warning`. Proportionate or bounded-authority results clear the episode. An
+explicitly cleared assessment marks the end of that interval; sufficient later
+traffic in the same family starts a new episode. Repeated reads never advance
+these boundaries. One occurrence and the existing owner cooldown apply to each
+episode; a disposition stops repeated requests.
+
+This bounded source covers explicitly tagged mission work: at most 2,000 touched
+qitems, 200 roots, 1,000 members / 10,000 transitions per family, 200 workflow
+receipts, 200 declared slices, and 100 proof files per selected slice. Overflow
+refuses visibly. Context files are bounded to 64 KiB. A lineage beginning before
+the retained window remains indeterminate, with the missing interval named.
+Untagged or ambiguously mission-tagged work is outside this source's coverage;
+absence is not health. The packet includes missing context references so an agent
+can name or repair its own knowledge gap without manufacturing source truth.
+
+## Optional outcome-boundary checkpoint
+
+Live queue transitions do not, on their own, prove product outcomes or the
+authority for a bounded operation. At a meaningful outcome boundary, the agent
+holding those facts may submit a census for one qitem lineage and time window. Set `includeHandoffs: true`
+to follow its declared handoff descendants; this is the normal path for work that
+passed between seats. The root alone usually misses the review/return traffic.
+Prefer the existing proof/progress/outcome artifact as evidence. Do not add a
+checkpoint to each edit or message. This is a fallback for explicitly supplied evidence;
+normal activity uses passive diagnosis above. An existing checkpoint owns its
+lineage so the passive source does not create a duplicate episode.
+
+```json
+{
+  "schema": "openrig.health-checkpoint/v0alpha1",
+  "lineageQitemId": "<existing-product-qitem>",
+  "includeHandoffs": true,
+  "scope": {"type": "slice", "projectId": "<project>", "missionId": "<mission>", "sliceId": "<slice>"},
+  "startedAt": "<ISO timestamp>",
+  "observedAt": "<ISO timestamp>",
+  "transitionIds": "derive",
+  "productOutcomes": [
+    {"id": "<outcome-id>", "observedAt": "<ISO timestamp>", "evidenceRef": "<proof-artifact-path>"}
+  ],
+  "productCensusRef": "<artifact establishing the complete outcome census for this lineage/window>",
+  "boundedAuthority": {"applies": false, "evidenceRef": "<bounded-effect-authority assessment>"},
+  "sdlc": {"expectation": "<selected components and review boundary>", "evidenceRef": "<authority for that selection>"},
+  "authorityPaths": {
+    "project": ["<current project SPEC and project.yaml paths>"],
+    "mission": ["<current mission SPEC and mission.yaml paths>"],
+    "slice": ["<current slice SPEC and slice.yaml paths>"]
+  }
+}
+```
+
+```sh
+rig queue transitions <existing-product-qitem>
+rig health checkpoint --file checkpoint.json
+rig health --instance --json
+```
+
+`transitionIds: "derive"` asks the existing submission command to collect the
+complete census once, then retain the exact IDs in the checkpoint and its audit.
+The author supplies outcomes and their meaning, not a row-by-row bookkeeping
+ritual. An explicit ID array is also supported for sealed replay or a
+caller-supplied census. Later reads never silently extend either form.
+
+The daemon verifies that transition IDs are the complete census for that exact
+qitem and window, including all handoff descendants when selected. It does not
+infer shared lineage from similar names or seat names. The complete transition
+census may be assembled from the queue ledger; omitting a descendant refuses.
+Explicit mission/slice tags on counted family members must match the checkpoint
+scope; untagged descendants inherit the declared handoff relationship.
+The bound is 1,000 linked qitems and 10,000 transitions; an oversized family
+refuses rather than silently sampling it. Independent roots are separate censuses. It counts
+those transitions and the distinct, evidenced product outcomes, and explains
+both sides of the ratio, the literal gate-tag breakdown, and the selected SDLC
+expectation. These are custody/status transitions, not messages or judgments
+about whether each review was useful. A product outcome is a distinct evidenced
+user-visible result; commits, test runs, returns and fixes needed to achieve
+that same promised result do not each create another denominator unit. The
+census must state its outcome granularity and coverage. The same granularity
+must be used for positive and proportionate controls. An empty outcome list requires the same census evidence
+as a nonempty one. An unavailable product census is a null denominator: the explanation says
+no ratio was computed, rather than silently substituting zero or one.
+`boundedAuthority.applies=null` means unknown, never false.
+Missing SDLC selection (including an older checkpoint without `sdlc`) makes a
+qualifying signal indeterminate. Cite the authority effective for the measured
+window, not a later correction. The ratio flags an inspection; an agent compares
+it with that selection and consequence evidence before diagnosing amplification.
+Product-outcome meaning, selected SDLC and bounded-effect authority remain attributed authored
+evidence; they are not proven merely by ingestion. Findings label that source
+and use medium confidence. Required evidence references must resolve to nonempty,
+readable local files (at most 1 MiB) inside the configured workspace. Absolute
+paths and paths relative to that workspace are supported; other reference kinds
+(including section addresses) remain unavailable. Resolved evidence records carry
+a SHA-256; missing files and symlink escapes remain attributed claims but force
+indeterminate source truth and cannot admit a diagnosis. Availability is checked
+again on every projection; presence does not certify the artifact's meaning.
+This authority assessment is distinct from the
+project/mission/slice documents supplied to the diagnosing agent. Embedded
+context is limited to canonical `SPEC.md` and project/mission/slice YAML files
+at their corresponding work-tree nodes, at most 64 KiB each. Other paths and
+symlink aliases are reported unavailable without embedding their contents.
+Each entry retains its authority level. Project files must be at the configured
+project root; mission files must belong to the finding's mission; slice files
+must also have a sibling `SPEC.md` declaring the finding's slice ID (and matching
+mission when declared). A sibling slice or another mission is unavailable even
+when its filename is canonical. Without mission/slice scope, those authority
+levels remain unavailable.
+
+Checkpoints are audited under `health/checkpoints/history/`; replaying identical
+bytes writes nothing. Later censuses advance observation time. High-to-high
+observations retain episode identity; a clearing checkpoint and later recurrence
+produce a cleared episode and a new ID. Reads never update checkpoint state.
+Stale, unavailable, contradictory, clipped, or missing evidence cannot admit a
+diagnosis. No findings is not a healthy assertion. The current source bounds are
+200 lineages, 10,000 transitions and 1,000 product outcomes per checkpoint, and
+1 MiB per input. Unsupported or invalid sources fail visibly.
+
+## Investigate and record a disposition
+
+Read the exact evidence and the current authority. Trace where the pattern
+began, test whether your own actions amplified it, and distinguish another seat
+or stale guidance. A second opinion is optional. The packet is a starting point,
+not a closed evidence set.
+
+```json
+{
+  "verdict": "insufficient evidence",
+  "causalStart": null,
+  "steering": "Inspect the product-outcome census before changing work.",
+  "uncertainty": "The cited artifact does not yet establish the denominator.",
+  "evidenceRefs": ["<inspected-evidence-path>"]
+}
+```
+
+```sh
+rig health diagnosis record <qitem-id> --file disposition.json
+rig health diagnosis show <qitem-id>
+```
+
+Verdicts are `false positive`, `early real condition`, `established pathology`,
+`insufficient evidence`, or `resolved`. The disposition is retained on the
+diagnostic qitem's transitions and visible in CLI output and the queue. Recording
+it does not close or alter the underlying product work. Changed dispositions
+retain earlier testimony; exact replay is a no-op. A detector clearing is
+recorded separately from an agent declaring the problem resolved.
+
+## Human delivery
+
+An assigned agent may explicitly request human escalation:
+
+```sh
+rig health diagnosis notify <qitem-id>
+```
+
+It requires a registered `human.address` and an admitted `human.conditions`
+entry (`critical`, `established pathology`, or `confirmed ceremony`). The connector must be enabled
+and pass live readiness checks. The current connector implementation verifies
+Slack scopes and channel membership; the diagnosis service itself uses a
+transport-neutral readiness port. The existing gateway owns delivery policy
+and posting. One human request is retained per episode, and its actual delivery
+outcome comes from queue receipts. `pending` is never presented as `posted`.
+Inspect the returned qitem's transitions for the connector receipt. No periodic
+health check performs remediation. With `human.conditions=["confirmed ceremony"]`,
+the enabled diagnosis loop automatically requests one notification for an active,
+confirmed passive ceremony episode. Provisional, indeterminate, cleared, and stale
+episodes never notify. The existing readiness/gateway path owns the effect; an
+unready connector leaves a visible, deduplicated readiness receipt. Later checks
+may retry readiness but never create a second request for an existing episode.
+Read-only list/explain/preview commands never send.
+
+## Read-only consumers and calibration
+
+A consumer such as a later Herder plugin reads `GET /api/health` and
+`GET /api/health/:findingId`, or the identical `rig health --json` and
+`rig health explain <finding-id> --json` records. The record schema is
+`openrig.health/v0alpha1`; list metadata is `openrig.health-list/v0alpha1`.
+Preserve ID, status, policy version, time window, freshness, evidence and
+threshold together. There is no health score or implicit remediation authority.
+The default list excludes cleared records; explicit cleared queries and exact
+ID reads retain them while the source can still project them. A recurrence after
+clear receives a new episode ID. This is an on-demand projection, not a history
+store; a detail 404 does not prove resolution.
+
+Lists default to 100 and cap at 200, with `total` and `truncated` explicit.
+Ceremony findings take precedence before the cap so context pressure cannot
+hide the primary signal. Narrow a truncated query; do not certify the unseen
+remainder. Empty is not healthy, unavailable is not empty, and an indeterminate
+finding cannot authorize a diagnostic occurrence except the explicit, fresh
+`needs-diagnosis` passive candidate described above. An existing occurrence may
+receive one status-observation receipt when its source becomes indeterminate;
+that does not create another obligation or wake.
+
+Live sources supply context pressure, passive ceremony candidates and attributed
+assessments, plus optional ceremony checkpoints.
+Behavioral and epistemic categories intentionally have no detector. Review
+carousel, redundant wakes, stale directives and scope admission have typed
+evaluators and replay controls, but the live source does not infer their missing
+candidate-change, rescue, directive-conflict or admission-authority facts.
+Untagged work and undeclared relationships remain outside passive ceremony
+coverage; normal tagged work no longer requires a special outcome census. A small lineage below the configured threshold may still deserve an
+agent's inspection; the threshold is a conservative admission rule, not a
+definition of good process.
+
+`packages/daemon/scripts/probe-health-calibration.mjs` accepts a sealed replay
+export and output directory after daemon/CLI/TUI builds. It drives the compiled
+checkpoint/list/explain/diagnosis commands, renders the TUI, retains exact
+records and screens, compares database and filesystem effects around reads,
+and measures query cost against declared budgets. Every write uses a disposable
+home and database. Historical expected states must be grounded independently
+of the detector formula; incomplete outcome evidence is an indeterminate case,
+not a denominator of one. A calibration report describes its selected corpus
+and remaining blind spots, not a fleet-wide false-positive rate.

package/daemon/docs/reference/mission-install.md

@@ -196,6 +196,11 @@ The layers compose from surfaces that already exist; no new mechanism is require
   project/mission/role/task → coverage map; `guided` keeps the fuller authored
   walk separately selectable. Both select from the same source graph.
 - Position: the `--rig`/`--seat` grant serves the seat's lessons and recap.
+- Runtime: `context profile` and `context work-install` both accept
+  `--runtime claude-code` (alias `claude`) or `--runtime codex`. Profile
+  composition retains the `claude` manifest/output key; skill projection
+  retains `claude-code`. Profile defaults from `OPENRIG_RUNTIME`, otherwise
+  Claude; work-install requires the flag to inspect or apply skills.
 - Delivery: `rig walk <seat> --through-profile world-public --profile <profile>
   --situation <situation> ...` applies the already-inspected profile;
   `--through <files> --pace <interval>` remains the raw byte-walk path. Paced

package/daemon/docs/reference/product-journey-sdlc.md

@@ -52,9 +52,10 @@ mission YAML to change.
   implementation momentum.
 - **Skip when:** the current agent can independently state the user outcome,
   starting candidate, and boundaries from primary sources.
-- **Input:** world install, mission/slice YAML, and the addresses it names.
-- **Action:** start or clear a session, load only the selected context, and
-  derive current identity and source state.
+- **Input:** identity, project/mission/slice YAML, and the selected addresses.
+- **Action:** load the selected context into a fresh session, or reorient the
+  current session from live sources. Clearing a seat requires its separate
+  continuity decision; selecting this component does not authorize it.
 - **Output:** a one-paragraph readiness statement naming role, user outcome,
   starting candidate, and boundaries.
 - **Stop:** do not reconstruct old queue lore merely because it exists.
@@ -213,7 +214,8 @@ possible explanation.
 
 ## Composition rules
 
-1. `mission.yaml` may declare the catalog and mission defaults.
+1. `project.yaml` may declare project defaults; `mission.yaml` may select the
+   catalog and override those defaults for the mission.
 2. `slice.yaml` selects or overrides the components for that slice.
 3. Edges are explicit data. Array order is presentation, not dependency.
 4. Select the fewest components that honestly fit the work.
@@ -290,16 +292,52 @@ build.minimal-gap → qa.public-journey → qa.installed-smoke?`
 The recurrence admits one causal descent. It does not authorize a general
 platform rewrite.
 
+## Resolve the selected path
+
+On a fresh start, restore, or new assignment:
+
+1. Derive identity with `rig whoami --json`. Resolve the project's work root from
+   the assignment/workspace binding; `rig config get workspace.root` locates the
+   configured work tree, which may differ from the seat's code checkout.
+2. Read `project.yaml` and its project-authority context. Follow its mission root
+   to the assigned `mission.yaml`, then its composition ref to the active
+   `slice.yaml`. Read the current intent and acceptance files those records name.
+   Do not choose a mission from an old onboarding packet or a folder's recency.
+3. Resolve SDLC selection in order: project defaults, mission defaults, then the
+   active slice's explicit selection/override. A narrower explicit selection
+   replaces the broader component list; it does not append every ancestor's
+   gates. Follow an addressed wave map for its membership, review model and
+   boundary; an explicit named-slice exception applies only to that slice.
+4. Read only the selected components and additional addressed context. Repository
+   references resolve from the code repository root; installed references from
+   `$OPENRIG_HOME/reference`; context-pack refs use `rig context get`. For a
+   Markdown `#section` address, use `loading-addressable-markdown` rather than
+   loading an entire unrelated manual. Expand the investigation when the task's
+   evidence requires it: the address map is a starting point, not a search limit.
+5. State briefly the user outcome, current role, candidate, selected path and
+   next completion boundary. No composition means the light Part A flow in
+   `sdlc-conventions.md#a1-the-flow-in-one-pass`. Do not author a
+   composition merely to have one, or mint QA, guard, review, lock or proof gates
+   because those roles exist. On a tiny change the builder can verify the whole
+   outcome; independent review happens only when selected.
+
+A missing referenced file is a named gap, not evidence of no selection. Inspect
+or ask the owner to resolve a consequential ambiguity; do not silently fall back
+from an explicitly selected rigorous path. An owner can explicitly amend the
+selection for named work; record that decision at the work's authority. Current
+command/source reality outranks stale YAML as a factual claim: record the
+mismatch, re-derive, and preserve the distinction between scope and observed state.
+
+Startup overlays, role guidance, available seats, old mode names and historical
+packets cannot add steps to this selection. They supply capabilities. Skills load
+when the selected work calls for them; there is no quiz, per-file ACK gate or
+universal preloading requirement.
+
 ## Blank-agent start
 
-An agent with only the base world install should:
-
-1. Read `mission.yaml`, then the active `slice.yaml`.
-2. Resolve the catalog address and only the additional addresses those files
-   name.
-3. State: **my role; the user outcome; the starting candidate; the
-   boundaries**.
-4. Follow the selected component edges and their stop conditions.
-5. If no composition exists, use Part A in `mission-slice-sop`.
-6. If current reality contradicts the YAML, stop treating the YAML as fact,
-   record the discrepancy, and re-derive from the public journey and source.
+Follow **Resolve the selected path** above before choosing work. For an authored
+wave, build and verify each slice with its local discipline and integrate serially
+where required; request independent review once when the authored wave boundary
+arrives. Do not start per-slice reviews while waiting. A separately selected
+rigorous slice retains its named checks. Review findings justify bounded repairs,
+not an automatic increase in process for the next round.

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/docs/reference/sdlc-conventions.md

@@ -68,10 +68,12 @@ intent (what is this for, what does done look like)
       → hand off (rig queue handoff) or stop
 ```
 
-One full-breadth review at the end, not per increment. Bring work when it is **done**. The human
-should almost never see something that doesn't match what was planned — QA catches mismatches and
-kicks them back. When the human looks, they map intent → plan → delivered at a glance, mostly by
-scanning screenshots down a single column, and give the final 1% approval.
+Verify the whole outcome at completion, not through a review chain per increment.
+For a tiny change the builder may hold this check. Independent QA/review runs only
+when selected by the project/mission/slice composition or an explicit owner
+assignment; for a wave, at its authored boundary. Available roles never add gates.
+The authority lookup is `product-journey-sdlc.md#resolve-the-selected-path`.
+Bring work with evidence that its promised user outcome actually works.
 
 For a release mission, `mission.yaml` also names the Git strategy before build
 work starts: the branch/ref that is cumulative integration truth, its base, and

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