@openrig/cli 0.6.4 → 0.6.5

package/daemon/context-packs/skills/claude-compaction-restore/reference/SKILL-v1.md

@@ -0,0 +1,143 @@
+> **Superseded by `../SKILL.md` (openrig-core 0.1.3). Kept for comparison only; do not follow it.**
+> This is the 0.1.2 text with its frontmatter removed so that nothing indexes it as a live skill.
+
+# Claude Compaction Restore
+
+Use this skill to preserve continuity before Claude Code compacts and to
+restore continuity after compaction. Follow the active restore request or
+configured continuity policy. A hook notice identifies available evidence; it
+does not by itself request a seat restoration.
+
+## If You Are About To Compact
+
+Prepare durable continuity before the context boundary.
+
+1. Identify the active task, queue item, mission/slice, branch or commit, and
+   current working directory.
+2. Record the current state: decisions made, files changed, commands/tests run,
+   evidence produced, blockers, caveats, and the next concrete step.
+3. Create or update a durable mental-model restore map. This map is the main
+   artifact future-you will use to rebuild context after compaction.
+4. In the restore map, write an ASCII file/folder tree of every path that
+   mattered to your working mental model during this session. Include:
+   - the active queue item or mission packet;
+   - mission notes, progress, decisions, and evidence files;
+   - Claude memory/project notes you used or wrote, especially when the memory
+     folder is shared by many agents;
+   - files with active edits or recently inspected source;
+   - root instructions such as `AGENTS.md`, `CLAUDE.md`, or `README.md`;
+   - as-built docs, codemaps, conventions, skills, and product docs needed
+     before code/review work;
+   - source files, tests, scripts, UI evidence, screenshots, logs, or reports
+     that shaped your current state.
+5. For every file or folder in the tree, add a short note explaining why it
+   matters and whether it is required reading after compaction.
+6. Write any important glue context that is not already on disk into the
+   handoff/restore map. This includes assumptions, partial conclusions, failed
+   paths, and why the listed files fit together.
+7. In the compaction summary, include the restore map path and the top required
+   reading paths from that map.
+
+## If You Just Compacted
+
+Restore from the evidence for this session before relying on remembered task state.
+
+1. Inspect the restore request and any named marker, packet, transcript, restore
+   map, or extra instruction file. Check recorded seat/session/transcript identity
+   against the current request, and verify that the referenced packet is readable.
+   A marker path alone does not prove a usable packet; do not substitute another
+   seat's packet or select one only because it is the newest.
+2. **Use the existing packet when usable.** Read its `restore-instructions.md`,
+   `touched-files.md`, and any named restore map. A packet already prepared for this
+   session does not need rebuilding merely because compaction occurred.
+3. **Fall back when the packet is absent or unusable.** Record what is missing or
+   mismatched. Resolve this skill's installed directory and run its
+   `scripts/restore-from-jsonl.mjs` with the matching Claude JSONL transcript and a
+   separate output directory. For a skill installed in the global Claude skill root:
+
+```bash
+node ~/.claude/skills/claude-compaction-restore/scripts/restore-from-jsonl.mjs /path/to/session.jsonl --out /tmp/claude-compaction-restore
+```
+
+   If no transcript was named, identify the current session's transcript first.
+   The script can discover a transcript from a working directory, but inspect that
+   selection before relying on it. If the session cannot be identified, report
+   the missing input instead of reconstructing from an unrelated conversation.
+   Read the resulting `restore-instructions.md` and `touched-files.md`.
+4. Inspect the actual packet and transcript sizes before choosing how much to read.
+   The generated instructions report estimated token cost. State a read budget
+   and stopping rule that leave room for the task. For a large transcript, begin
+   with the most recent task-relevant unique narrative; read earlier material when
+   a specific missing decision or dependency requires it. Report ranges actually
+   read rather than treating a chosen budget as completed coverage.
+5. Use the restore map and touched-file list to identify current task files.
+   The list is a triage aid, not an exhaustive inventory. Prioritize the active
+   queue/mission packet, decisions and memory named in the map, files with active
+   edits, root instructions, and relevant as-built docs or codemaps. Read required
+   task files in full within the stated budget; record any remaining gaps.
+6. Re-establish the task's purpose and operating context from the current project,
+   mission and seat files. A transcript summary alone does not establish current
+   scope or obligations. Use the shipped `refocusing` skill for the path-only
+   topology/work trace when operating inside OpenRig.
+7. Report the read-depth audit below. Once the required context is restored, use
+   the packet's requested acknowledgment, normally:
+
+```text
+restored from packet at <path>; resumed at step <X>
+```
+
+   Include the main files actually read in full. If essential context remains
+   missing, report partial restoration and the next recovery action instead of
+   claiming completion.
+
+The packaged PreCompact writer can prepare a packet and a per-seat pending marker;
+the restore bridge can deliver its pointer once for a matching session. Inspect
+those actual artifacts. Their creation or delivery is not proof that a provider
+restored its context, that the files were read, or that task understanding returned.
+
+## Required Read-Depth Audit
+
+After the first restore pass, audit yourself before continuing.
+
+1. List every file, packet, marker, restore map, instruction file, and source
+   document you were asked to read during restore.
+2. Mark each item as `FULL`, `PARTIAL`, or `NOT_READ`.
+3. Distinguish essential current-task context from supplementary history, using
+   the actual restore request and active task.
+4. Read `PARTIAL`/`NOT_READ` items in full — but **to a declared budget with a stopping rule**, not
+   unbounded. Prioritize by relevance to the active task; for a large transcript read the most recent
+   unique narrative first (see *If You Just Compacted*), not front-to-back.
+5. **Stop** when either every task-relevant item is `FULL`, or you reach the budget — *a restore that
+   cannot leave room for the work it was restored to do is not a successful restore.* "Read everything,
+   never conserve" has no termination condition; that open-endedness is the bug, not the goal.
+6. Report the final read-depth table **honestly** (`FULL`/`PARTIAL`/`NOT_READ`, each with a reason)
+   before task work. **An honest `PARTIAL` with its reason is a correct outcome, not a failure** — do
+   not claim a completion you did not reach.
+
+## Guardrails
+
+- Compaction is survival, not housekeeping — never compact to free space, "lean" a seat, or capture/prepare an agent starter (the `rig agent-image` library). It is lossy (a compacted Claude is confident-but-hollow); compact only when a seat is genuinely near its context limit, with a before/after plan. A starter's value is being *functional*, not small — see the `agent-starters` skill.
+- Do not silently launch fresh after compaction.
+- Do not continue from memory when restore evidence exists.
+- Do not defer required restore reading until a later user task. The restore is
+  the current task.
+- Do not skip root instructions, as-built docs, or codemaps before product
+  code/review work.
+- Do not treat the generated touched-file list as exhaustive.
+- Do not mark a file `FULL` unless you actually read the full file content
+  after compaction.
+- Do not resume task work until the restore sentinel and read-depth audit are
+  complete.
+
+## Failure Modes To Avoid
+
+1. **Confidently-wrong restoration**: claiming restoration after reading only
+   the touched-file list or summary.
+2. **Unreported partial restore**: continuing without essential task context or
+   claiming full coverage after a budget-limited read.
+3. **Skipping project instructions**: missing `AGENTS.md`, `CLAUDE.md`,
+   `README.md`, as-built docs, or codemaps that govern the task.
+4. **Treating the packet as exhaustive**: ignoring mission or workspace files
+   that are important but were not discovered by the script.
+5. **Waiting for the next task**: treating restore reading as conditional on a
+   future user assignment instead of completing it immediately.

package/daemon/context-packs/skills/core/agent-starters/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: "agent-starters"
-version: "0.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance."
 files:

package/daemon/context-packs/skills/core/agent-startup-and-context-ingestion/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: "agent-startup-and-context-ingestion"
-version: "0.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, \"rig context\" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent)."
 files:

package/daemon/context-packs/skills/core/cross-host-rig-commands/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: "cross-host-rig-commands"
-version: "0.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result."
 files:

package/daemon/context-packs/skills/core/human-in-the-loop/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: "human-in-the-loop"
-version: "0.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when classifying a slice closeout (auto-continue / human gate / park), routing a real decision to a human, or designing a human queue/dashboard surface. Treats humans as durable network participants with attention surfaces, queues, and decision records — escalation lands as a durable attention item, not a chat message. Approval is NOT required for every clean closeout; the default RSI conveyor continues unless an explicit human gate is reached."
 files:

package/daemon/context-packs/skills/core/messaging-the-human/SKILL.md

@@ -79,6 +79,30 @@ never silently clipped. Shorten the brief or related detail as directed. Inspect
 the failed row, then deliberately cancel/replace the authored request if its
 content needs correction; a timeout alone is never a reason to replace it.
 
+A follow-up **update** about earlier work ("the change you approved is merged")
+can post into that item's thread with `--reply-to <earlier-qitem-id>`. It is
+accepted only with `--human-intent update`. Name the item whose thread the
+human saw, such as the parked row, and create the update on the same host as
+that item. Send the update from the seat that owns that thread: the seat that
+parked the row, or the author of the earlier item. A human reply in a thread
+reaches its owning seat, so an update from any other seat posts as a new
+message. It also posts as a new message, rather than being refused, if the
+earlier thread is missing or closed, or while the earlier item still waits on
+the human (a pending human decision, or a row parked on the human), since a
+reply in that thread would answer the decision. In every such case the
+`--verify` result says `threaded: false` with the reason.
+
+A **decision** with a few clear choices can carry `--human-questions-file <path>`:
+a JSON array of 1–4 questions, each
+`{"id", "question", "options": [{"id", "label", "recommended"?}]}` with 2–4
+options (labels up to 75 characters, at most one recommended). Slack shows each
+question as a row of buttons. Each click records that answer on the item, and
+the decision resolves once every question has one. You then receive one reply
+row listing the answers, and the item's `humanAnswers` holds the option ids. The
+human may instead type a reply in the thread; that resolves the decision as
+usual, so read the reply rather than assuming an option was picked. Keep the
+brief complete: the questions add buttons, they do not replace the explanation.
+
 If an existing agent-owned row must wait for a **decision**, block it on the **new live qitem ID**
 (`rig queue block <work-id> --on <human-qitem-id> ...`), not on the human address.
 Completion of the human qitem resumes its dependants. Blocking on the human as

package/daemon/context-packs/skills/core/messaging-the-human/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: "messaging-the-human"
-version: "0.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when project policy calls for a human decision or update, a human delivery is pending or failed, or a reply must resume the right work."
 files:

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.6.4"
+version: "0.6.5"
 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.6.4"
+version: "0.6.5"
 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.6.4"
+version: "0.6.5"
 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/SKILL.md

@@ -120,6 +120,12 @@ and a useful report to the OpenRig team if you are still stuck. If `rig` won't r
 `daemon/docs/reference/help.md` inside the installed `@openrig/cli` package, or https://www.openrig.dev/help/agents
 (the same text).
 
+## Developing OpenRig itself
+
+If you're changing OpenRig's own source in a clone of the openrig repository, use that repository's
+`developing-openrig` skill (in the checkout's `.claude/skills/` or `.agents/skills/`). It maps the architecture, the
+areas where a small change has a large effect, and which tests to run before a pull request.
+
 ## Need more than what ships here?
 
 This index covers the **shipped** surface. Your project, rig or machine may add its own skills and routers. Check the

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.6.4"
+version: "0.6.5"
 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-software-factory/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-software-factory"
-version: "0.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when a user wants a continuing software team for a real repository, or has a first OpenRig team and needs a repeatable path for reviewed work and later tasks."
 files:

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.6.4"
+version: "0.6.5"
 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.6.4"
+version: "0.6.5"
 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.6.4"
+version: "0.6.5"
 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/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.6.4"
+version: "0.6.5"
 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.6.4"
+version: "0.6.5"
 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

@@ -1,6 +1,6 @@
 ---
 name: topology-mutation-and-seat-management
-description: 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.
+description: Use when changing a rig while it is alive — `rig grow` / `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.
 metadata:
   cli_surfaces_referenced:
     - adopt
@@ -8,6 +8,7 @@ metadata:
     - bind
     - discover
     - expand
+    - grow
     - launch
     - ps
     - release
@@ -43,13 +44,32 @@ static launch scripts.
 
 ## Use this when
 
-- Adding capacity to a running rig (`rig expand <rig> <pod-fragment-path>`)
+- Adding seats to a running rig (`rig grow <rig-id> <member...>` for the simple case, a fragment with `rig expand` or `rig add` otherwise; see below)
 - Removing capacity (`rig shrink` / `rig remove`)
 - Launching/relaunching a node in a running rig (`rig launch`)
 - Binding a discovered session into an existing logical node (`rig bind`)
 - Adopting a topology + binding live sessions (`rig adopt`)
 - Attaching a shell or agent into a rig node (`rig attach --self`)
 
+## Adding seats: `rig grow` first, a fragment when you need more
+
+`rig grow <rig-id> <member...>` adds one or more seats to a running rig without
+writing YAML. Each seat gets the default agent spec and its `default` profile.
+Check `rig grow --help` on your installed version; at the time of writing:
+
+- `--pod <pod>`: the target pod; inferred when the rig has one pod
+- `--new-pod <pod>`: create a new pod for the seats (not together with `--pod`)
+- `--runtime <runtime>`: one runtime for every named seat (default `claude-code`)
+- `--cwd <path>`: one working directory for every named seat (default: the current directory)
+- `--json`: output for agents
+
+Write a fragment instead when a seat needs something `rig grow` does not set: an
+explicit model, a permission policy, a different agent spec or role profile, a
+per-seat runtime or working directory, or startup files. Use
+`rig expand <rig-id> <pod-fragment-path>` to add a pod, or
+`rig add <rig-id> <pod-namespace> <member-fragment-path>` to add one member to an
+existing pod.
+
 ## Don't use this when
 
 - The rig is being created fresh from scratch — use `rig up` (lifecycle, not mutation)
@@ -89,6 +109,7 @@ adding or removing a seat from replacing its occupant; use
 
 Per `cli-reference.md` v0.2.0:
 
+- `rig grow <rig-id> <member...> [--pod <pod> | --new-pod <pod>] [--runtime <runtime>] [--cwd <path>]` (added after v0.2.0; check `rig grow --help`)
 - `rig expand <rig-id> <pod-fragment-path>` (with optional `session_source`)
 - `rig shrink <rigId> <podRef>`
 - `rig launch <rigId> <nodeRef>`
@@ -114,7 +135,7 @@ unfinished proof obligation is implied by loading this skill.
 
 ## See also
 
-- `openrig-user` skill — CLI surface for `rig expand / shrink / launch / remove / bind / adopt / attach`
+- `openrig-user` skill — CLI surface for `rig grow / expand / shrink / launch / remove / bind / adopt / attach`
 - `seat-scaling-and-specialization` skill — when to add specialized capacity vs generic
 - `seat-continuity-and-handover` skill — replacing an occupant on a stable seat (different shape than topology mutation)
 - `cross-host-rig-commands` skill — cross-host topology mutation (deferred)

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

@@ -1,10 +1,10 @@
 # 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.6.4"
+version: "0.6.5"
 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."
+purpose: "Use when changing a rig while it is alive — `rig grow` / `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:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "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."
+    summary: "Use when changing a rig while it is alive — `rig grow` / `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."

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.6.4"
+version: "0.6.5"
 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.6.4"
+version: "0.6.5"
 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

@@ -20,8 +20,6 @@ metadata:
     stage: factory-approved
     sibling_skills:
       - openrig-user
-      - openrig-operator
-      - openrig-builder
       - openrig-architect
       - openrig-upgrade
       - agent-operated-workflows
@@ -91,7 +89,10 @@ you should know which pillar you're operating in:
 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.
+and selected task context rather than assuming a particular private corpus:
+`rig context list` shows the configured packs, and `rig context work-install`
+lists what the current project declares (intent, context files, skills), so you
+read only the pieces a task needs.
 
 ---
 
@@ -175,7 +176,7 @@ cost when you reach for one.
 |---|---|
 | `<rig-cwd>/.claude/skills/`, `<rig-cwd>/.agents/skills/` | Where the harness actually loads from. Populated by `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, …). |
+| `packages/daemon/{specs/agents/shared/skills,assets/plugins/*/skills}/` (source checkout) | Product skills that ship with OpenRig — the spec pool + the bundled plugin assets (openrig-user, openrig-architect, forming-an-openrig-mental-model, queue-handoff, claude-compaction-restore, …). |
 | the skills authoring workspace | Skill authoring source (not runtime-loaded). |
 
 The product already discovers its installed shared skill pool and serves
@@ -258,12 +259,12 @@ For real depth, these are the load-bearing canonical docs:
 
 | Reference | What it covers |
 |---|---|
-| `openrig/docs/as-built/README.md` | As-built map of territory — daemon architecture, system overview, package boundaries; routes to the 13 `architecture/` + 4 `ui/` modules via `codemap.md` |
-| `openrig/docs/as-built/cli-reference.md` | The full `rig` CLI surface with all subcommands and flags |
-| `openrig/docs/reference/rig-spec.md` | The RigSpec YAML format — pods, members, edges, all fields |
-| `openrig/docs/reference/agent-spec.md` | The AgentSpec YAML format — resources, profiles, imports |
-| `openrig/docs/reference/agent-startup-guide.md` | The 7-layer startup layering model; delivery hints |
-| the product taxonomy | Canonical vocabulary (read literally) |
+| `docs/as-built/README.md` (source checkout) | As-built map of territory — daemon architecture, system overview, package boundaries; routes to architecture and UI modules via `codemap.md` |
+| `rig --help`, then `rig <command> --help` | The installed CLI surface, subcommands and flags |
+| `rig context get reference/rig-spec.md` | The RigSpec YAML format — pods, members, edges, all fields |
+| `docs/reference/agent-spec.md` (source checkout) | The AgentSpec YAML format — resources, profiles, imports |
+| `docs/reference/agent-startup-guide.md` (source checkout) | The 7-layer startup layering model; delivery hints |
+| [Core vocabulary above](#the-core-vocabulary-read-these-terms-literally) | Vocabulary used in this skill (read literally) |
 | `openrig-operating-model` skill | Placement and operating-model guidance — topology and work trees, context altitude |
 | `openrig-architect` skill | Rig and topology authoring |
 | `https://agentskills.io/specification` | The cross-runtime skill standard |
@@ -281,7 +282,6 @@ touching YAML.
   CULTURE.md. Read those.
 - **Authoring a new rig.** Use the `openrig-architect` skill for that.
 - **Day-to-day OpenRig operation.** Use `openrig-user` for that.
-- **Administering an OpenRig install.** Use `openrig-operator`.
 
 This skill exists to **form your initial mental model of OpenRig as a
 system**. Once oriented, reach for the role-specific or task-specific skills

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.6.4"
+version: "0.6.5"
 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.6.4"
+version: "0.6.5"
 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/loading-addressable-markdown/scripts/resolve-markdown.mjs

@@ -54,7 +54,8 @@ function scanHeaders(lines) {
       const marker = fenceMatch[1][0];
       const length = fenceMatch[1].length;
       if (!fence) fence = { marker, length };
-      else if (fence.marker === marker && length >= fence.length) fence = null;
+      else if (fence.marker === marker && length >= fence.length
+        && /^[ \t\r]*$/.test(line.slice(fenceMatch[0].length))) fence = null;
       continue;
     }
     if (fence) continue;

package/daemon/context-packs/skills/mission-slice-sop/SKILL.md

@@ -64,9 +64,9 @@ These three are a division of labour, not a chain of gates. One agent may hold a
 - **HOW:** a slice carries `intent:` in frontmatter and opens with `## Intent`, `## Mini-requirements`, and `## Proof contract`. A mission carries its intent and mission-level specification in the same authored node file. Keep depth proportional to the work.
 
 ### PROGRESS.md
-- **WHO:** the orchestrator owns `§1` (current state); every agent logs its own outcomes.
+- **WHO:** the orchestrator owns the current state; every agent logs its own outcomes.
 - **WHEN:** on material delivery-state changes and at acceptance.
-- **HOW:** one line per outcome (checkbox), link down for detail; keep frontmatter `stage`/`verified` honest.
+- **HOW:** keep current delivery state in `## Current state`; append material outcomes with links to proof under `## Outcomes`. Retain historical entries and existing checkboxes without treating them as current acceptance authority. For a selected proof policy, use `rig proof show <slice>` for current readiness; keep frontmatter `stage`/`verified` honest.
 
 ### PROOF.md + proof/
 - **WHO:** the impl/QA pair that worked the slice.

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.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when starting, building, handing off, restoring, or closing a mission or slice under the default lightweight SDLC."
 files:

package/daemon/context-packs/skills/openrig-operating-model/SKILL.md

@@ -343,6 +343,23 @@ mission carries its intent and mission-level specification in the same authored
 `mission-slice-sop` and any explicit mode overlay; mission specification is not a
 requirement to repeat every slice detail.
 
+### Project knowledge: three kinds, three homes
+
+Before you write down something you learned about a project, decide which kind it is.
+
+- **Product facts** say what is true of the software at a version: commands, behaviour, formats. They live in the
+  product's own documentation, versioned with the code and checked against source. Anywhere else, link to them
+  rather than copying them; a copy stops following releases.
+- **Project judgment** says how to work on the project now: intent, workflow, priorities, routes, who decides what.
+  It lives in the project's world pack and its work tree, and it can change without a release.
+- **Machine-local state** is true of one instance only: paths, hosts, live rosters, counts, credentials. It belongs
+  in configuration, in a seat's `LEARNED.md`, or as the command that derives it. It never goes into shipped content
+  or a shared world.
+
+Agents find a project's declared context with `rig context work-install`, which lists what the project declares:
+its intent, the context files in its `project.yaml` `install` block, and its skills. When project knowledge should
+reach every agent working on the project, add it to that declaration rather than starting a second index.
+
 ### The other axis: AUDIENCE is not MATURITY
 
 These are independent, and merging them is seductive because the merged version is prettier.

package/daemon/context-packs/skills/openrig-operating-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: "openrig-operating-model"
-version: "0.6.4"
+version: "0.6.5"
 taxonomy: "skills"
 purpose: "Use when you do not know WHERE something belongs: you learned a lesson and are unsure which file takes it; you are about to create a new doc, folder, or convention; you are asking \"should this be a skill, a note, or a chain file?\"; you inherited a seat and want to know what SHOULD exist; or you are about to duplicate knowledge that already has a home. Also the trace-to-root: how a seat orients by reading one filename at each level from where it stands up to the fleet."
 files:

package/daemon/context-packs/skills/openrig-operating-model/scripts/compose.py

@@ -285,7 +285,7 @@ def resolve_roots():
     out = {}
     out["work_root"] = os.environ.get("OPENRIG_WORKSPACE_ROOT") or rig_config("workspace.root")
 
-    t = os.environ.get("OPENRIG_TOPOLOGY_ROOT") or rig_config("workspace.topology_root")
+    t = os.environ.get("OPENRIG_TOPOLOGY_ROOT") or rig_config("topology.root")
     if not t:
         # Resolve symlinks before walking upward; otherwise a projection ascends
         # its own tree rather than the shared-docs source.
@@ -559,7 +559,7 @@ if __name__ == "__main__":
             if v:
                 print(f"{k}={v}")
             else:
-                key = "workspace.root" if k == "work_root" else "workspace.topology_root"
+                key = "workspace.root" if k == "work_root" else "topology.root"
                 print(f"# {k} UNRESOLVED — set it: rig config set {key} <path>", file=sys.stderr)
         sys.exit(0 if all(r.values()) else 3)
     if not a.name: