@openrig/cli 0.5.10 → 0.5.12

package/daemon/context-packs/skills/core/openrig-architect/SKILL.md

@@ -21,8 +21,7 @@ metadata:
       - openrig-upgrade
       - forming-an-openrig-mental-model
       - ai-dev-workflows
-    notes: |
-      Description was already correct (starts with "Use when..."; lists specific authoring triggers including the diagnose-bad-rig case). Final sentence ("Covers the full authoring lifecycle from user intent to validated, launchable rig.") is workflow-summary-adjacent; on next iteration, consider trimming. For factory-adoption cycle, kept as-is to match product source-of-truth.
+
 ---
 
 # OpenRig Architect
@@ -33,43 +32,33 @@ Your job is to take a user's intent — "I need a team that does X" — and prod
 
 You also diagnose problems when a rig launches but agents aren't behaving as intended.
 
-## Before You Design: Required Reading
-
-Load these before starting any design work. The quality of your output depends on the depth of knowledge you bring.
-
-**Required (read all of these):**
-
-1. **`openrig-user` skill** — full OpenRig CLI surface. You must know the operator primitives. If your runtime supports skills, load it by name. Otherwise, look for it at `~/.openrig/skills/openrig-user/SKILL.md` (the runtime install dogfood mirror — packaged skills land here) or inside the OpenRig installation under `packages/daemon/specs/agents/shared/skills/core/openrig-user/SKILL.md`. The `~/.openrig/reference/` directory holds reference docs (rig-spec.md, agent-spec.md, etc.), NOT skills.
-
-2. **OpenRig reference docs** — these are installed at `~/.openrig/reference/` when the daemon starts. Read all of them:
-   - `~/.openrig/reference/rig-spec.md` — canonical RigSpec YAML reference. Every field, validation rule, default.
-   - `~/.openrig/reference/agent-spec.md` — canonical AgentSpec YAML reference. Same depth.
-   - `~/.openrig/reference/agent-startup-guide.md` — how to think about what goes into agent startup. Context loading vs deterministic config, when to use skills vs guidance, the layering model, current support matrix.
-   - `~/.openrig/reference/edge-types.md` — what edges do today vs what they're intended to do.
-
-   If `~/.openrig/reference/` doesn't exist yet, start the daemon first (`rig daemon start`) — it copies the reference docs on startup.
-
-**Read as worked examples:**
-
-3. **Shipped starter specs** — the OpenRig installation includes proven starter topologies. Find them by running `rig specs ls`. Read the ones that are relevant to your design task, especially:
-   - `implementation-pair` — the smallest effective development unit (2 agents)
-   - `secrets-manager` — a managed-app rig with services integration and a specialist agent
-
-**Read if present on this host:**
-
-4. **Host-level doctrine** in your host's topology doc, if it keeps one. If this file exists, it supersedes the baseline process below for complex or high-stakes rigs. Specifically:
-   - §3 defines the canonical rig classes (kernel, project, ephemeral, infra-build, managed-app). Classify before designing.
-   - §4 defines context-sharing patterns (pods as context domains, pair pattern, HA via mental-model-ha skill + substrate session logs, terminal nodes as common-room, chatroom/substrate/transcripts/Corpus).
-   - **§7 is the canonical 12-step rig-spec authoring SOP for high-stakes rigs — use it instead of the baseline "Design Process" below when the rig is ≥4 members, uses HA, is a managed-app, or will be shared/copied.** The baseline below still applies to small/focused rigs.
-   - §10 contains the host's bootstrap sequence so you know where your new rig fits.
-   - §12 has the naming canon and vocabulary mapping to shipped terms.
-5. **`building-agent-software` skill** if available in your skill catalog. Design principles for agent-facing tools and surfaces. Relevant when your rig ships a new CLI, service, or managed app.
-
-**Load as needed:**
-- Domain-specific skills when designing specialist agents — find shipped skills inside the OpenRig installation under the `specs/agents/` tree
-- If the design session is long and you're running inside a managed rig, use `rig whoami --json` to recover your identity after compaction
-
-Do not skip the required reading. A rig architect who doesn't know the spec format will produce specs that don't validate. An architect who doesn't know the startup layering model will produce agents that boot without knowing their role. An architect who doesn't check for host-level doctrine will reinvent conventions the host has already established.
+## Before you design: select the relevant sources
+
+Start with the user's outcome, the current project authority, and the part of
+the format you will author. Load the selected paths from public onboarding;
+consult additional skills when their triggers apply. A design task does not
+require reading the whole command library.
+
+- Read the relevant sections of `rig-spec.md` and `agent-spec.md` before writing
+  those declarations. Consult `agent-startup-guide.md` for startup/loadout work
+  and `edge-types.md` when selecting relationships. Resolve the installed
+  reference root from the actual OpenRig installation; `~/.openrig/reference/`
+  is a default, not a fixed location. If it is absent, use the matching source
+  repository docs or report the missing reference. Reading does not require
+  starting or changing a daemon.
+- Use current `rig <command> --help` for command shape. Load `openrig-user` for
+  the specific CLI surface needed, through the installed skill/context catalog.
+- Inspect relevant starter specs with `rig specs ls`. Treat them as examples to
+  validate against the current environment, not proof that your new rig works.
+- If the environment declares host or project doctrine, read the actual
+  applicable authority and reconcile it with the task. Do not assume a filename,
+  section number, rig classification or fixed authoring SOP. Missing authority
+  is a question to resolve when it changes the design.
+- Load domain-specific guidance for specialist roles. When authoring an
+  agent-facing tool, consult `building-agent-software` if available.
+
+Keep the spec, startup layering, role responsibilities and selected proof
+standard explicit. Scale the reading and checks to what the design changes.
 
 ## The Design Process
 
@@ -152,14 +141,17 @@ To verify the current builtin set on this host, run `rig specs ls` and look for
 
 Each member needs a `runtime` and optionally a `model`.
 
-**Runtime selection:**
-- `claude-code` — Claude Code. Best for: complex reasoning, architecture, code review, orchestration. Supports `/loop` for recurring tasks, rich hooks system, MCP servers.
-- `codex` — Codex. Best for: parallel work, implementation, testing. Different approval model. Less reliable for recurring tasks.
-- `terminal` — Infrastructure nodes. Servers, log tails, build watchers. Not an agent — a process.
-
-**Runtime diversity is valuable.** Using both Claude Code and Codex in the same rig gives you different reasoning perspectives. The `product-team` starter uses Claude Code for the lead/impl/design/r1 roles and Codex for peer/qa/r2 roles. This is deliberate — model diversity catches different classes of issues.
+Choose from the installed, authenticated runtimes and the project's current
+execution policy. `claude-code` and `codex` are agent runtimes; `terminal` is an
+infrastructure process. Their model availability, hooks, approval behavior and
+continuation support differ. Check the relevant installed interfaces rather
+than ranking vendors permanently in a reusable role skill.
 
-**Model selection** is optional. The runtime's default model is usually fine. Override only when you have a specific reason (e.g., a complex architecture agent might benefit from a specific model).
+Pin a model when the work or environment requires it, and verify the active
+runtime reports that model before relying on its result. Select reviewers and
+support roles by consequence, competence and the declared policy. Runtime
+diversity can provide different methods; it does not by itself prove independence
+or make any model suitable for a task.
 
 ### Step 5: Design Edge Topology
 
@@ -181,7 +173,8 @@ This is where most rigs succeed or fail. The topology is mechanical; the startup
 **Minimum for every rig:**
 1. Each agent has a `guidance/role.md` — who they are, what they do
 2. The rig has a `CULTURE.md` — how the team works together
-3. Each agent gets `openrig-user` skill — so they know how to use the rig primitives
+3. Each agent gets the selected onboarding path and can discover the relevant
+   command/skill references when needed
 
 **For serious rigs, also include:**
 4. `startup/context.md` per agent — boot-time grounding (project info, environment details)

package/daemon/context-packs/skills/core/openrig-architect/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-architect"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (use openrig-builder); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig."
 files:

package/daemon/context-packs/skills/core/openrig-cmux/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-cmux"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals into cmux — turning a rig, pod, mission, slice, or saved view into live agent tiles via `rig terminal --provider cmux`, or driving cmux on an agent's request. Same OpenRig view semantics as openrig-herdr (the verbs, honest-partial/degrade, read-only cross-rig, scroll/copy, same-size-only duplicates); cmux is the **best-effort** provider (herdr is the default and the proof-gated one). Prefer openrig-herdr unless cmux is specifically wanted."
 files:

package/daemon/context-packs/skills/core/openrig-herdr/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-herdr"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals as a herdr wall — turning a rig, pod, mission, slice, or saved view into live interactive agent tiles via `rig terminal`, watching another rig read-only, or driving herdr on an agent's request (\"open all my rigs + a mission as views\"). Covers the `rig terminal open|views|status` verbs, the honest-partial/degrade reading of the result, the read-only-by-construction rail for cross-rig views, scroll/copy out of the box, and the same-size-only duplicate-pane "
 files:

package/daemon/context-packs/skills/core/openrig-skills/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-skills"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't know what applies or nothing is projected on cold boot."
 files:

package/daemon/context-packs/skills/core/openrig-upgrade/SKILL.md

@@ -44,6 +44,22 @@ host, use the host's normal operator ceremony. On a recovery-friendly build VM,
 the orchestrator may adopt a tested runtime directly, but still observes each
 step and stops on unexplained drift.
 
+## When recovery crosses an instance boundary
+
+Before either lane changes runtime state, record one host-qualified executor and
+explicitly select the queue store that owns the recovery ruling. State whether
+the original owner continues, waits, or transfers; an open obligation in another
+store is not exclusive custody of this ruling. If the original store is down,
+retain its owner's disposition in the surviving ruling and communicate it to
+that owner before a competing executor acts.
+
+A refused claim means reconcile ownership with the ruling owner before any
+further runtime action; it does not authorize continuing under a separate older
+row. A return names the full executor address and deliberately selected store.
+Read the resulting row there, including source, destination, body, and the
+original owner's disposition, before resuming. Receipt creation alone does not
+establish that a waiting lane received or accepted the transfer.
+
 ## The loop
 
 For every step:

package/daemon/context-packs/skills/core/openrig-upgrade/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-upgrade"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when an agent is preparing or performing an OpenRig CLI/daemon upgrade and must preserve live seats, verify each mutation, or reconcile managed plugin and skill files without overwriting local work."
 files:

package/daemon/context-packs/skills/core/rig-bundles-and-shareable-artifacts/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "rig-bundles-and-shareable-artifacts"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when authoring or installing a rig bundle (packaged, shareable artifact that instantiates an opinionated OpenRig topology + workflow), reasoning about the bundle vs extension boundary, or auditing a bundle for portability. Covers the 4 failure modes that prevent bundles from working anywhere but the operator's machine, and the inspect-before-install discipline."
 files:

package/daemon/context-packs/skills/core/rig-lifecycle/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "rig-lifecycle"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAIL"
 files:

package/daemon/context-packs/skills/core/session-source-fork/SKILL.md

@@ -95,8 +95,8 @@ The primitive must NOT report "restored the original agent" or "resumed
 the original seat" or "snapshot." The correct framing is **"forked from
 source session"** / **"started from prior conversation source."**
 
-Negative-grep over adapter source confirms ZERO `restored` / `resumed` /
-`snapshot` strings in fork code paths.
+Check the actual user-facing outcome and persisted identity; wording alone
+does not prove the intended continuity was created.
 
 ## Hard boundaries (do-not list; verbatim)
 
@@ -128,14 +128,17 @@ Mutual exclusion between `resumeToken` (restore path) and `forkSource`
 For `seat handover over fork` composition, the binding outcome is
 independent (see `seat-continuity-and-handover` skill).
 
-## Active-daemon caveat (live-runtime gap)
+## Verify the running implementation
 
-2026-04-30 live scale-out dogfood found: source checkout contained fork
-support, but active daemon was running from a pre-fork commit. **Verify
-the active daemon/runtime commit contains the fork path before live
-proof.** Isolated daemon proof at the target commit can prove the
-feature safely; live forked scale-out remains unproven until the active
-daemon parity is verified.
+A source checkout and the running daemon can contain different implementations.
+Before an authorized fork, check the target daemon's build identity and support
+for the requested source. A source or isolated test establishes only that cut's
+behavior; it does not prove the live runtime uses it.
+
+Record the actual parent history, new seat identity, new continuity token and
+independent binding outcome. Preserve errors and incomplete results rather than
+reporting a fresh launch or restored original seat as a successful fork. These
+checks confer no authority to launch, replace or retire a live seat.
 
 ## Currently shipped (v1) vs deferred
 
@@ -148,7 +151,6 @@ Shipped at openrig `c7b6df1` (2026-04-30):
 - Honest UX literal contract (`continuityOutcome: forked`)
 
 Deferred:
-- Tier 2 real-runtime fork proof (disposable Tart VM cycle, human-gated)
 - Claude `artifact_path` mode (schema currently refuses with deferred message)
 - Provenance columns (`parent_native_id` / `created_via` for queryable RSI consumer)
 - Cross-host fork (source on host A, new seat on host B) — depends on `cross-host-rig-commands`

package/daemon/context-packs/skills/core/session-source-fork/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "session-source-fork"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when authoring a rig spec member or `rig expand` payload that needs to start a new managed seat from a prior runtime conversation source — `session_source: { mode: fork, ref: { kind, value } }`. v1 supports `mode: fork` with `ref.kind: native_id` for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild."
 files:

package/daemon/context-packs/skills/core/specification-system/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "specification-system"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when authoring rig specs, agent specs, workflow specs, startup/context fragments, operating-mode declarations, or designing the user spec library. Covers the 4 failure modes (spec instantiates topology but not workflow/mode; spec depends on local paths and fails on another host; agents modify specs as one-off files instead of preserving reusable intent; validation proves YAML shape but not whether topology can run) and the validation-vs-runtime-realization distinction."
 files:

package/daemon/context-packs/skills/core/topology-mutation-and-seat-management/SKILL.md

@@ -79,13 +79,11 @@ clean test fixture. The useful matrix:
 A clean-fixture proof is necessary but not sufficient. Live-rig proof
 catches the failure modes that fixture-mode misses.
 
-## Why important strategically
+## Stable roles during topology changes
 
-The current coordination experiments repeatedly need new queues,
-watchdogs, humans, and test seats — which makes this family
-**strategically important.** Seat continuity work will eventually
-separate stable seat identity from runtime occupant identity (see
-`seat-continuity-and-handover`).
+Capacity changes must preserve useful roles, routing and durable work. Distinguish
+adding or removing a seat from replacing its occupant; use
+`seat-continuity-and-handover` for the latter.
 
 ## Currently shipped surfaces
 
@@ -101,14 +99,18 @@ Per `cli-reference.md` v0.2.0:
 - `rig attach --self --rig <rigId> --node <logicalId>`
 - `rig unclaim <sessionRef>` / `rig release <rigId>`
 
-## Active proof gap (current)
+## Choose the proving environment and authority
 
-The 2026-04-30 topology mutation add-seat proof pass is **active**.
-Product Lab shaped it; planner authored `IMPLEMENTATION.md`; driver
-landed the smallest honest CLI retry-guidance patch for failed
-`rig expand` recovery. **Remaining proof is the Section B disposable-rig
-runtime matrix, blocked on operator posture** and owned by
-`orch-lead@your-rig`.
+Select an isolated active rig or an explicitly authorized live target for the
+relevant operation. Record its running build, before/after topology, continuity
+and outstanding work. A passing schema check or isolated fixture does not prove
+an existing live rig was changed correctly. A runtime timeout is indeterminate
+until its durable and process effects are reconciled; do not retry blindly.
+
+The matrix above is verification guidance, not permission to modify another
+rig. Name the operation's owner and scope, preserve the state needed for recovery,
+and retain missing or failed checks in the result. No local experiment or
+unfinished proof obligation is implied by loading this skill.
 
 ## See also
 

package/daemon/context-packs/skills/core/topology-mutation-and-seat-management/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "topology-mutation-and-seat-management"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when changing a rig while it is alive — `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures."
 files:

package/daemon/context-packs/skills/core/watchdog/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "watchdog"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking."
 files:

package/daemon/context-packs/skills/delegating-work/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "delegating-work"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when you have a task and must decide WHO does it — yourself, a spawned subagent, or another agent in the topology that already holds the context. The rule: how much would a blank slate have to read in to do this correctly? A lot → route to a context-holding agent; a little → subagent; unsure → a real agent or yourself. NOT the mechanics of fanning out (that's dispatching-parallel-agents / subagent-driven-development) — this is the who/whether decision, and the failure mode that makes teams a"
 files:

package/daemon/context-packs/skills/forming-an-openrig-mental-model/SKILL.md

@@ -84,14 +84,14 @@ you should know which pillar you're operating in:
 
 | Pillar | What it is | Where it lives |
 |---|---|---|
-| **Ontology** | What exists. Curated knowledge — facts, code maps, as-built docs. | Corpus (planned future system). Today: substrate prose docs. |
+| **Ontology** | What exists. Curated knowledge — facts, code maps, as-built docs. | Shipped public context packs plus project-authored docs; discover with `rig context list`. |
 | **Epistemology** | Why an agent believes what it believes — reasoning, instincts, decisions. | Transcripts (auto-captured). Session logs. ADRs. |
 | **Topology** | How agents are connected — pods, edges, communication paths. | OpenRig itself. RigSpec YAML. |
 
-OpenRig **manages the topology pillar**. The other two are filled by Corpus
-(future) and transcripts (now). Most of your work probably touches multiple
-pillars; knowing which one you're operating in helps you reach for the right
-artifacts.
+OpenRig manages topology and exposes public context through `rig context`.
+Project-authored sources supply project-specific knowledge; transcripts retain
+recorded work. These sources already coexist. Discover the configured library
+and selected task context rather than assuming a particular private corpus.
 
 ---
 
@@ -174,14 +174,15 @@ cost when you reach for one.
 | Home | Purpose |
 |---|---|
 | `<rig-cwd>/.claude/skills/`, `<rig-cwd>/.agents/skills/` | Where the harness actually loads from. Populated by `rig up`. |
-| `~/.claude/skills/`, `~/.agents/skills/` | Your personal / user-installed global skills, loaded by the harness itself (independent of OpenRig). NOT where OpenRig's own bootstrap skills live — those ship in the product (below) and project into the cwd `.claude/skills/` at `rig up`. |
+| `~/.claude/skills/`, `~/.agents/skills/` | User-level harness skill directories. Inspect the current projection and harness configuration to determine which skills are installed and where they came from. |
 | `openrig/packages/daemon/{specs/agents/shared/skills,assets/plugins/*/skills}/` | Product skills that ship with OpenRig — the spec pool + the bundled plugin assets (openrig-user, openrig-operator, openrig-architect, forming-an-openrig-mental-model, queue-handoff, claude-compaction-restore, …). |
-| `~/.openrig/skills/` | Future runtime install home for OpenRig-shipped skills. |
 | the skills authoring workspace | Skill authoring source (not runtime-loaded). |
 
-The harness only sees the first two. Other locations are authoring,
-shipping, and source-of-truth — they reach the harness via projection or
-NPM install, not directly.
+The product already discovers its installed shared skill pool and serves
+packaged context through `rig context list/get`. Discovery and retrieval do
+not prove that every skill was projected into every harness. Inspect the
+selected profile and actual runtime directories; do not assume a universal
+home/bootstrap installation from this table.
 
 ---
 

package/daemon/context-packs/skills/forming-an-openrig-mental-model/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "forming-an-openrig-mental-model"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when the system around you does not make sense yet: you just booted into a seat and do not know how the pieces fit; someone said rig, pod, seat, fleet, topology, or slice and you are not certain what they mean here; you are unsure what kind of rig you are in or what it is for; you do not know how skills reach you or where context comes from; or you are about to act on a guess about how OpenRig works. Gives the runtime mental model fast, so you stop guessing."
 files:

package/daemon/context-packs/skills/loading-addressable-markdown/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "loading-addressable-markdown"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when a mission, slice, dashboard, or task references Markdown as path#h2-slug or path#h2-slug/h3-slug outside the OpenRig context-pack library."
 files:

package/daemon/context-packs/skills/mission-slice-sop/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "mission-slice-sop"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when starting, building, handing off, restoring, or closing a mission or slice under the default lightweight SDLC."
 files: