@openrig/cli 0.5.10 → 0.5.11

package/daemon/assets/plugins/openrig-core/README.md

@@ -27,11 +27,30 @@ All other skills are cross-runtime by design.
 
 ## Distribution
 
-**At v0 (today):** the vendored copy inside the OpenRig npm package is the source of truth. When you install `@openrig/cli` (or run the daemon), `openrig-core/` is copied to `~/.openrig/plugins/openrig-core/` on first run. This is the offline-safe baseline and is always available.
-
-**Auto-fetch from GitHub at v0:** the OpenRig daemon probes `github.com/mvschwarz/openrig-plugins/releases/latest/download/openrig-core.tar.gz` on launch with a 5s timeout. **At v0 the success path only logs the response and does NOT extract a tarball, compare versions, or update the local copy** — extraction + version-compare + update are scoped to a later marketplace-consumption phase (mission slice 3.6). 404 (the expected normal-state response while the GitHub repo is empty), network errors, and timeouts are all tolerated silently with the vendored copy remaining authoritative.
-
-**Future (slice 3.6, marketplace-consumption phase):** when the GitHub releases workflow is set up and authorization to publish lands, the daemon will start extracting fetched tarballs + comparing versions + updating the local copy as the "hot update" path that skips OpenRig CLI version bumps.
+The npm package includes an offline baseline under the daemon's
+`assets/plugins/openrig-core/`. The daemon resolves local plugin authority before
+attempting a network fetch, using the configured OpenRig home (normally
+`~/.openrig/plugins/openrig-core/` for the installed copy):
+
+| Installed state | Local vendoring behavior |
+| --- | --- |
+| Absent | Seed the bundled plugin. |
+| Older manifest version | Advance files from the newer bundled version. |
+| Equal manifest version | Preserve installed content; executable modes may be reconciled on byte-identical files. |
+| Newer manifest version | Preserve the installed copy. |
+
+Version authority comes from the plugin manifests. An existing directory without
+a manifest is left unchanged; invalid or disagreeing manifest versions are
+reported rather than guessed. Updating the CLI therefore does not unconditionally
+overwrite an equal/newer or independently managed plugin copy.
+
+After local resolution, the daemon attempts the GitHub release endpoint for
+`openrig-core.tar.gz` with a five-second timeout. This path currently fetches and
+logs the response only: it does not extract the archive, compare its version, or
+install its content. Fetch failures, including 404 and network errors, leave the
+resolved local copy in place. A successful fetch also leaves it unchanged.
+This describes the fetch implementation, not a claim that a release artifact is
+currently available at the external repository.
 
 You can also install directly via Claude Code or Codex's own plugin commands if you prefer to manage plugins outside OpenRig.
 

package/daemon/assets/plugins/openrig-core/skills/agent-operated-workflows/SKILL.md

@@ -75,5 +75,7 @@ knowledge.
 A capability composition is a reusable recipe; this is the execution architecture that operates
 capabilities toward an outcome. Promote a proven workflow to the composition shelf only after use.
 
-**Reference implementation:** Release 0.5.9 Slice 05 is the first **Agent-Operated Migration**. Its
-runbook and helpers remain there; this skill carries the reusable contract, not a duplicate procedure.
+**Public example:** load `skills/core/openrig-upgrade/SKILL.md` with
+`rig context get` for the upgrade runbook. Its adjacent `scripts/` directory
+contains the bounded inspection, backup, plugin-refresh and migration helpers.
+Follow that runbook for the procedure; this skill carries the reusable contract.

package/daemon/assets/plugins/openrig-core/skills/applying-a-permission-policy/SKILL.md

@@ -3,12 +3,12 @@ name: applying-a-permission-policy
 description: "Use when a permission policy is attached to a rig/seat (rig.yaml permission_policy:), or a user asks you to apply one, and you must translate that harness-neutral policy into the target harness's LIVE permission config — Claude settings.json / Codex config.toml / Pi run flags. Agent-driven and interactive: you read the policy, ground yourself in YOUR harness version, show the diff, and ask before writing. NOT for defining policies (that's the policy spec) and NOT a set-and-forget updater."
 metadata:
   openrig:
-    stage: established             # config cells VM-verified + cold-transfer PASSING (rerun #2) + built-in SPEC FILES landed → skill translates FROM the spec (POINT-not-COPY). The two established criteria met 2026-08-04. Reviewed at push.
+    stage: established
     tested_against:                # VERSION STAMP — the whole point; re-verify at every harness bump
       claude_code: "2.1.220 — VM-CONFIRMED 2026-08-03 (all cells)"
       codex: "0.120.0 — VM-CONFIRMED 2026-08-03 (sandbox_mode/approval_policy; on-failure deprecated-but-accepted)"
       pi: "0.83.0 — VM-CONFIRMED 2026-08-03: --approve/--no-approve govern PROJECT-RESOURCE TRUST, NOT tool permissions; Pi has NO permission surface (see Pi leg)"
-    verification_status: "Live-verified 2026-08-03/04. Claude 2.1.220 + Codex 0.120.0 config cells CONFIRMED live. Pi 0.83.0 divergence folded (flags = project-resource trust, not a permission gate). Cold-transfer rerun #1 blocked on the force_push/push_to_remote prefix collision → added the PREFIX-COLLISION rule. Cold-transfer rerun #2: TRANSFERS — all 5 gate checks pass (collision resolved deterministically without asking; single ordinary write confirmation; defaultMode floor written; Codex workspace-write/on-request; Pi compute-nothing). Blocking collision/floor defect CLOSED → gate cleared, 4.8-shippable (provisional-with-passing-cold-transfer). Non-blocking seam closed: the built-in SPEC FILES landed (arch-accepted, source:builtin) → skill translates FROM the spec, interim in-skill pinned summary retired (POINT-not-COPY). stage:ESTABLISHED 2026-08-04 — both criteria met."
+    verification_status: "Historical compatibility checks on the versions and dates in tested_against. These observations do not establish behavior on a later harness; verify its current format before applying the mapping."
 ---
 
 # Applying a permission policy
@@ -30,17 +30,17 @@ Harness permission formats are a **moving target**. The exact fact this skill is
 - NOT for authoring policies (that's the policy spec) and NOT for daemon-level enforcement (OpenRig is agnostic — it injects nothing).
 
 ## What you're translating (the boundary)
-INPUT = a **harness-neutral policy spec** (arch's schema): `default_posture`, `floor`, `allow`/`ask`/`deny` as **semantic actions** (`push_to_remote`, `delete_files`, …), `destructive_class`, `source: builtin|custom`. You TRANSLATE that intent → the harness's live config. You never invent policy; you never pre-bake harness config into the spec.
+INPUT = a **harness-neutral policy spec** (semantic action schema): `default_posture`, `floor`, `allow`/`ask`/`deny` as **semantic actions** (`push_to_remote`, `delete_files`, …), `destructive_class`, `source: builtin|custom`. You TRANSLATE that intent → the harness's live config. You never invent policy; you never pre-bake harness config into the spec.
 
 ## The apply flow (interactive — the interactive-ask IS the product)
 1. **Read the policy spec** + its `source:` marker (built-in read-only from the package = copy-to-customize before editing; custom = user space).
 2. **PREFLIGHT (mandatory) — ground yourself in THIS environment:**
-   - **daemon-HOME must equal seat-HOME**, or a user-level Claude write never reaches the seat (assessment iv). Check; if they differ, **stop and ask** — do not write into the wrong HOME.
+   - **daemon-HOME must equal seat-HOME**, or a user-level Claude write never reaches the seat. Check; if they differ, **stop and ask** — do not write into the wrong HOME.
    - Read the harness's **actual current config file** + confirm its schema against your installed version (`claude --version`, the live settings.json shape, codex/pi versions). If the format differs from this skill's `tested_against`, trust the LIVE format and flag the drift.
 3. **Derive the per-harness config** from the semantic actions (see the three legs below). Compute the Codex posture-collapse + Pi bit.
 4. **Show the concrete DIFF before writing** (old → new, per file). Never a blind write.
-5. **Resolve best-effort actions by the built-in's rule FIRST, then ask only on genuine ambiguity.** Best-effort destructive actions (`force_push`, `delete_files`, `delete_everything`, `read_secrets`) default to **`ask`** (never a `deny` that can't be enforced) — apply that default rather than stopping to question-back. Surface a question only when the policy is genuinely ambiguous or the seat is interactive. **For a same-prefix collision (`push_to_remote` vs `force_push`, both `Bash(git push:*)`), NEVER ask — apply the deterministic PREFIX-COLLISION rule in the Claude leg.** (Live cold-transfers caught fresh agents *question-backing* — first on the `force_push` default, then on the prefix collision — instead of applying the fixed rule; both freeze an autonomous seat.) On a Claude-only fleet, if the policy denies `network_egress`, **say so explicitly**: it is NOT enforceable — Claude has no network gate, a `Bash(curl:*)`/`Bash(wget:*)` deny is best-effort, and `python`/`node` fetch bypasses it (live-verified: `urllib` reached HTTPS 200 under a curl/wget deny). Route real egress-gating to the Codex sandbox, or record it as advisory on Claude.
-6. **Back up the current config**, then write. Prefer the **user-level** file (`~/.claude/settings.json`) for durable policy — it's the clobber-resistant tier (deny wins across the union). **ALWAYS include `defaultMode: "acceptEdits"` in the Claude settings.json you write** — the floor key must be PRESENT in the file, or the config policy strips the floor. (This is the exact gap a live cold-transfer test FAILED on: the fresh agent wrote allow/deny lists but omitted `defaultMode`, leaving the seat below the floor.)
+5. **Resolve best-effort actions by the built-in's rule FIRST, then ask only on genuine ambiguity.** Best-effort destructive actions (`force_push`, `delete_files`, `delete_everything`, `read_secrets`) default to **`ask`** (never a `deny` that can't be enforced) — apply that default rather than stopping to question-back. Surface a question only when the policy is genuinely ambiguous or the seat is interactive. **For a same-prefix collision (`push_to_remote` vs `force_push`, both `Bash(git push:*)`), NEVER ask — apply the deterministic PREFIX-COLLISION rule in the Claude leg.** On a Claude-only fleet, if the policy denies `network_egress`, **say so explicitly**: it is NOT enforceable — Claude has no network gate, a `Bash(curl:*)`/`Bash(wget:*)` deny is best-effort, and `python`/`node` fetch bypasses it (live-verified: `urllib` reached HTTPS 200 under a curl/wget deny). Route real egress-gating to the Codex sandbox, or record it as advisory on Claude.
+6. **Back up the current config**, then write. Prefer the **user-level** file (`~/.claude/settings.json`) for durable policy — it's the clobber-resistant tier (deny wins across the union). **ALWAYS include `defaultMode: "acceptEdits"` in the Claude settings.json you write** — the floor key must be PRESENT in the file, or the config policy strips the floor.
 7. **Verify** the write landed and the seat can see it (re-read; confirm `defaultMode: "acceptEdits"` is present; for an autonomous seat, confirm no `ask` will freeze it).
 
 ## Two surfaces — and this skill writes only ONE of them
@@ -48,7 +48,7 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **LAUNCH-FLAG surface — STABLE (>1yr) → OpenRig sets it DETERMINISTICALLY, NOT this skill.** The flags OpenRig passes at boot: Claude `--permission-mode` / `--dangerously-skip-permissions`; Codex sandbox/bypass flags; Pi `--approve`/`--no-approve`. **Two things live here, both OpenRig-owned: the FLOOR (minimum, by default) and YOLO (full bypass, opt-in).**
 - **CONFIG-FILE surface — CHAOTIC → NEVER deterministic → THIS SKILL'S DOMAIN.** Claude `settings.json` allow/ask/deny + defaultMode; Codex `config.toml` approval rules. This is where the Locked / Standard / Open policies get applied — agent-driven, version-stamped, caveated. (Pi has **no permission surface at all** — its `--approve`/`--no-approve` flags govern project-resource trust, not tool permissions (VM-confirmed Pi 0.83.0); a permission policy does not translate to Pi. See the Pi leg.)
 
-**THE FLOOR (launch-flag, OpenRig-set — this skill KNOWS it, never WRITES it):** Claude `--permission-mode acceptEdits` (keep it); **Codex workspace-only** (stop forcing `danger-full-access` — ≈ Codex's own default ≈ setting-nothing = agnostic); Pi `--no-approve` (a project-resource-trust floor — Pi has no permission gate; see the Pi leg). **One consistent unconditional minimum** (no by-context switching — that mode idea is parked 5.0). A chosen config-file policy layers ON TOP of the floor.
+**THE FLOOR (launch-flag, OpenRig-set — this skill KNOWS it, never WRITES it):** Claude `--permission-mode acceptEdits` (keep it); **Codex workspace-only** (stop forcing `danger-full-access` — ≈ Codex's own default ≈ setting-nothing = agnostic); Pi `--no-approve` (a project-resource-trust floor — Pi has no permission gate; see the Pi leg). **One consistent unconditional minimum**. A chosen config-file policy layers ON TOP of the floor.
 
 **YOLO MODE (launch-flag, OpenRig-set, opt-in — for people done with permissions):** OpenRig boots every seat with the full-bypass flag (Claude `--dangerously-skip-permissions`; Codex full-bypass). **When YOLO is on, CONFIG-FILE POLICY IS MOOT** — this skill does NOT apply a config policy (or explicitly notes it's overridden by the flag); don't fight the bypass. YOLO is OpenRig's deterministic job, not this skill's. (**Operator = YOLO mode** — subsumed.)
 
@@ -79,10 +79,10 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **PREFIX-COLLISION resolution (deterministic — resolve it, NEVER ask).** When two actions collapse to the SAME base prefix with different dispositions — the canonical case is `push_to_remote`=allow + `force_push`=ask, both basing to `Bash(git push:*)` — you cannot put that base prefix in both `allow` and `ask`. Resolve without a question-back:
   - **Push allowed + force asked (Standard / Open):** put the base `Bash(git push:*)` per push's disposition (`allow`), AND add the flag-first force forms to `ask` (`Bash(git push --force:*)`, `Bash(git push -f:*)`, `Bash(git push --force-with-lease:*)`). RECORD in your diff that this is best-effort — flag-LAST force (`git push origin main --force`) leaks past the flag-first ask rules and runs under the allow. Don't block on it.
   - **Push denied (Locked):** `Bash(git push:*)` in `deny` already covers force — no conflict.
-  This is a FIXED rule, not a user decision — apply it and note the leak. (A live cold-transfer FAILED because a fresh agent *blocked asking* "how to resolve the force_push/push_to_remote collision" instead of applying this default.)
-- **`defaultMode: "acceptEdits"` is the FLOOR and MUST be written into every Claude settings.json you produce.** It is not a knob you tune, but it IS a key you must always include — a config policy that omits it strips the floor (the cold-transfer failure). Live-confirmed schema: `{"permissions":{"allow":[],"ask":[],"deny":[],"defaultMode":"acceptEdits"}}`.
+  This is a FIXED rule, not a user decision — apply it and note the leak.
+- **`defaultMode: "acceptEdits"` is the FLOOR and MUST be written into every Claude settings.json you produce.** It is not a knob you tune, but it IS a key you must always include — a config policy that omits it strips the floor. Live-confirmed schema: `{"permissions":{"allow":[],"ask":[],"deny":[],"defaultMode":"acceptEdits"}}`.
 
-### Codex — `~/.codex/config.toml` (via the existing X10 `codex_config_fragment` splice path — reuse, don't invent)
+### Codex — `~/.codex/config.toml` (via the existing `codex_config_fragment` splice path — reuse, don't invent)
 - Codex is **per-posture, not per-action**: the whole action set **collapses** to the nearest `{sandbox_mode, approval_policy}` pair. **Built-in → posture** (VM-CONFIRMED @ Codex 0.120.0, 2026-08-03 — each posture applied to a real seat: read-only blocked writes+egress, workspace-write allowed writes/blocked egress, danger-full-access allowed both):
 
   | Built-in | `sandbox_mode` | `approval_policy` | Collapse note (surface this to the user) |
@@ -107,7 +107,7 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **daemon-HOME ≠ seat-HOME** silently voids user-level writes — always the preflight check above.
 
 ## The built-ins — DEFINED by the shipped policy spec files (translate FROM the spec; POINT, don't COPY)
-The four built-in policies ship as read-only spec files (`source: builtin`, `policy_schema_version: 1`) — they are the AUTHORITATIVE definitions. **Do NOT restate their action-sets here.** An earlier in-skill copy drifted (it under-asked `publish_package`/`merge_or_release`, which the spec ASKs) — the exact reason POINT-don't-COPY is the rule. Read the attached/selected spec and translate its semantic-action sets (`default_posture` / `allow` / `ask` / `deny` / `destructive_class`) per the three legs above.
+The four built-in policies ship as read-only spec files (`source: builtin`, `policy_schema_version: 1`) — they are the AUTHORITATIVE definitions. **Do NOT restate their action-sets here.** The selected spec supplies the action sets; a second copy in this skill can diverge. Read the attached/selected spec and translate its semantic-action sets (`default_posture` / `allow` / `ask` / `deny` / `destructive_class`) per the three legs above.
 - **Locked / Standard ⭐ / Open** — `surface: config`. Translate to the Claude / Codex config surface. **Standard ⭐** is the recommended default: routine dev incl. push allowed, the outward/release/history-rewriting acts (`create_pr`, `publish_package`, `merge_or_release`, `force_push`) ASK, destructive_class ASKs. Standard has live `ask` gates → not for a headless-autonomous Claude seat (use Open or YOLO). Locked = deny-default whitelist; Open = allow-default, destructive_class asks only.
 - **YOLO** — `surface: flag`, `launch_posture: full_bypass`. This skill does **NOT** translate it — it points at OpenRig's deterministic flag-surface opt-in (the rip-out YOLO setting). When YOLO is on, any config-surface policy is MOOT (the bypass overrides it). (Subsumes the former "Operator".)
 
@@ -115,6 +115,3 @@ Built-ins ship read-only in the package (canonical names); copy-to-customize int
 
 ## Boundary (keeps this the only maintained piece)
 This skill TRANSLATES + APPLIES only. It does **not** define policies (the policy spec does) and does **not** enforce at the daemon (OpenRig is agnostic). Spec = *what* (neutral intent); this skill = *how, on this harness version* (the caveated, version-stamped translation).
-
----
-*Stage: ESTABLISHED (2026-08-04) — both criteria met: (1) cold-transfer PASSING (rerun #2, all 5 gate checks TRANSFER); (2) the built-in policy SPEC FILES landed (`source: builtin`, arch-accepted) as the authoritative source — the skill now translates FROM the spec and the interim in-skill pinned summary is retired (POINT-not-COPY). Config cells VM-CONFIRMED (Claude 2.1.220 / Codex 0.120.0); Pi has no permission surface (compute-nothing). Reviewed at push. feedback.md maintained.*

package/daemon/assets/plugins/openrig-core/skills/claude-compaction-restore/SKILL.md

@@ -3,7 +3,6 @@ name: claude-compaction-restore
 description: Use when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files.
 metadata:
   openrig:
-    stage: factory-approved
     sibling_skills:
       - mental-model-ha
       - scope-recovery
@@ -20,8 +19,9 @@ metadata:
 # Claude Compaction Restore
 
 Use this skill to preserve continuity before Claude Code compacts and to
-restore continuity after compaction. Do the work described here; do not merely
-explain the protocol.
+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
 
@@ -55,68 +55,60 @@ Prepare durable continuity before the context boundary.
 
 ## If You Just Compacted
 
-Treat your memory as unreliable until you restore from durable evidence.
-Restoration is your current task. Do not wait for a future user request or a
-new task assignment before reading the required files.
-
-1. Read any restore prompt, marker path, packet path, transcript path, restore
-   map, or extra instruction file named by the operator or OpenRig.
-2. Run the restore script from this skill:
-
-```bash
-node ~/.claude/skills/claude-compaction-restore/scripts/restore-from-jsonl.mjs --out /tmp/claude-compaction-restore
-```
-
-If the prompt names a specific Claude JSONL transcript, pass it explicitly:
+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
 ```
 
-3. Read the generated `restore-instructions.md`.
-4. Read the generated `touched-files.md`.
-5. Find and read the mental-model restore map if one exists. Treat it as the
-   highest-value guide to which memory files, mission files, source files, and
-   docs mattered before compaction.
-6. Identify the important files for the active task. The touched-file list is
-   a triage aid, not a complete inventory.
-7. Read every important file in full. Prioritize the restore map, Claude memory
-   files named in the map, Markdown state/planning files, queue/mission packets,
-   source files with active edits, root instruction files, and as-built or
-   codemap docs.
-8. After the required reads are complete, state:
+   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 you read in full when you make that statement.
-
-9. **REFOCUS BEFORE YOU RESUME — the restore returns your TASK, not your BEARINGS.** Everything
-   above rebuilds *what you were doing*. None of it rebuilds *what the work is for* or *how this
-   rig operates* — those live in the chains, and nothing in steps 1–8 walks them. Invoke the
-   `refocus` skill and do its reads before your next substantive move.
-
-   **Measured 2026-08-13, and this step exists because of it:** a seat completed this protocol
-   faithfully — packet built, narrative read tail-first, read-depth audit reported honestly — and
-   resumed with a perfect picture of its atom and *zero* work-tree context. It had never opened
-   the mission or project nodes, and could only paraphrase the release's intent second-hand from
-   a peer's message. It then produced a technically-correct trace concluding *"I hold nothing"*
-   while holding 18 pending rows. **A restore that returns you to your task without your bearings
-   is how a confidently-wrong agent gets back to work.**
-
-**On the marker and the packet's size (measured across restores, 2026-08):** two realities the restore
-must handle honestly —
-
-- **The per-seat marker (`restore-pending/<session>.json`) is frequently absent** — in five observed
-  restores it was never present. Treat the JSONL rebuild via `restore-from-jsonl.mjs` as the **primary**
-  path, not a fallback: run it regardless of whether a marker exists. (When product-infra reliably writes
-  the marker for tmux-launched seats, it becomes a fast-path upgrade — not a prerequisite that keeps failing.)
-- **The generated transcript can be very large** (measured at ~346k tokens in one restore). Do **not**
-  read it front-to-back or claim to. `restore-instructions.md` declares its token cost up front; default
-  to the **most recent ~50k tokens of unique narrative first** (recency is what a restore needs — the
-  thread that produced the current frontier, not the boot handshake), and go earlier only if a specific
-  question requires it. A restore must leave room for the work it was restored to do.
+   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
 
@@ -125,8 +117,8 @@ 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. You will be given a task where all of these files are required reading in
-   order to understand the task.
+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.
@@ -156,8 +148,8 @@ After the first restore pass, audit yourself before continuing.
 
 1. **Confidently-wrong restoration**: claiming restoration after reading only
    the touched-file list or summary.
-2. **Partial restore**: reading the first few files, then continuing before the
-   full reading list is complete.
+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

package/daemon/assets/plugins/openrig-core/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/assets/plugins/openrig-core/skills/openrig-operating-model/SKILL.md

@@ -9,7 +9,7 @@ description: >-
 metadata:
   openrig:
     stage: draft
-    author: OpenRig product team (sole-context authorship)
+    author: OpenRig product team
 ---
 
 # The OpenRig Operating Model
@@ -20,10 +20,9 @@ find what it needs and knows where to write what it learns. Everything below
 runs on **markdown files, scripts, and conventions only**; the `rig` verbs that
 formalize pieces of it are conveniences, never dependencies.
 
-**Boundary (2026-08-11):** this skill owns the STRUCTURE (trees, chains, trace,
-write protocol). The SUPPLY layer — how canon content flows into the chains:
-addresses, maps, renders, EMM maturity, census — is `openrig-corpus-canon`,
-the deliberate drain mechanism the dual-home interim anticipated.
+This skill owns the structure: trees, chains, tracing, and placement of authored
+knowledge. Resolve installed context through its current library addresses and
+the project's selected loadout; a private corpus is not a required public dependency.
 
 Companion implementation assets in this skill's folder:
 - `templates/` and `scripts/` — starters and working tools, described in §8.
@@ -43,7 +42,7 @@ An **instance** is one OpenRig daemon and the rigs it manages; a **fleet** is al
 a daemon runs is a deployment fact, not an altitude — say the instance's name when you mean a
 particular one.
 
-**The one-parent law (design-ruled 2026-08-10):** the trace follows the
+**The one-parent law:** the trace follows the
 directory path and NOTHING else — no pointer fields, no link-following, no
 branching, ever. The trace is the instrument confused agents reach for, so it
 must be simpler than anything it corrects: path-only ascent fails only in
@@ -99,18 +98,17 @@ generated or projected.** It is the work tree's lived file, the way `LEARNED.md`
 tree's — the field-notes rung, where raw observation goes before anything has earned a place in the
 node itself. Keeping lived files out of the render path is what makes them safe to write freely in.
 
-**Legacy name:** the adopted spelling is `MISSION_NOTES.md` (35 at mission root). It stays
-resolvable, but the chain name is `NOTES.md` — `MISSION_` is altitude-specific and a chain uses one
-name at every altitude.
+**Legacy name:** older workspaces may use `MISSION_NOTES.md`. Keep legacy
+content addressable; use `NOTES.md` for the chain because its name works at every altitude.
 
 | Level | `SPEC.md` — frontmatter `intent:` (why) + body (what must be built) | progress | kept true by |
 |---|---|---|---|
 | project | `intent:` only — stable, changes at real pivots | derived roll-up | the project's PM |
-| mission | `intent:` only — a mission ORGANISES slices; it specifies nothing | authored checklist marks; roll-up derived | the mission's PM |
-| slice | `intent:` **and** a body — the only altitude that specifies | authored checklist marks; roll-up derived | the slice's owner |
+| mission | `intent:` and proportional mission-level specification; organizes slices | authored checklist marks; roll-up derived | the mission's PM |
+| slice | `intent:` and the concrete slice specification | authored checklist marks; roll-up derived | the slice's owner |
 | proof item | *(inherits)* | **the checkbox — the stored acceptance mark** | the prover |
 
-**PROGRESS reconciliation (2026-08-26):** Checkbox items stored in a mission or slice
+**Progress checklists:** Checkbox items stored in a mission or slice
 `PROGRESS.md` are authored acceptance marks. In-process task tracking stays in the agent's own todo
 tool. Everything that rolls those marks up above the managed checklist is derived at render time,
 so authored checklists and the never-author-a-derived-roll-up rule are the same model.
@@ -134,13 +132,10 @@ becomes a confident lie.
 Two directions on the same trees: intent/values/practice **compose downward**
 (you trace UP to read them); progress **aggregates upward** (never hand-written
 above the stored marks). **And PROGRESS above the managed checklist is a RENDER, not a
-file** (design-ruled 2026-08-10): the checkbox is the stored acceptance mark;
-`scripts/compose.py progress` derives the roll-up tree at render time. The
-old PROGRESS.md files that embedded a hand-rendered tree were the right idea
-in the wrong home — a stored derivation drifts into a confident lie (the same
-law that retired `serves:`). Existing legacy PROGRESS.md files with embedded
-trees stay per rule zero and are read as testimony; nobody authors a progress
-tree by hand again.
+file**: the checkbox is the stored acceptance mark;
+`scripts/compose.py progress` derives the roll-up tree at render time. Keep legacy
+embedded roll-ups as historical records when needed, but derive the current view
+from its marks rather than maintaining another copy by hand.
 
 **The axis behind the columns:** every context kind has a *template* half
 (what ships — SOP, the default culture) and a *learned* half (what living
@@ -152,16 +147,13 @@ constitution.
 
 ## 3. Why this exists (the failure it fixes)
 
-*How this seat does its job, learned over time* had no durable home. It lived
-in one runtime's private memory (invisible to the other runtime, the operator,
-and every successor), in handover documents (where day-to-day duties drown
-under urgent state), and in skills nobody opened at the right moment. Measured
-result: several consecutive generations of critical seats each started with a
-fraction of their predecessor's ability, without knowing it. The structural fix
-is the pair: `openrig-core`'s operating-model skill (the job, by type — shared,
-versioned, shipped) + `LEARNED.md` on the chain (the job, as lived — per-instance,
-occupant-written) — **read at every boot before any handover document**, written
-by every generation. A bad handover now costs recent state, not the job itself.
+Seat knowledge needs a durable home that successors and other runtimes can read.
+A private runtime memory or an urgent handover packet alone can omit standing
+duties and the reasons behind a practice. Keep general operating craft in the
+shared skill and position-specific knowledge in the seat's `LEARNED.md` chain.
+At a handover, read the current chain alongside the packet and record any missing
+job context before claiming readiness. Each occupant maintains what the seat has
+learned; the handover packet carries the current transition.
 
 ## 4. LEARNED.md — the living file (all altitudes; seat shown)
 
@@ -187,15 +179,14 @@ Sections, in order — see `templates/LEARNED.md`:
 **Size: soft guidance, not a rule.** Keep it as small as honestly covers the
 job — attention is the budget, and every reader pays it. Some seats genuinely
 need more; write what the job needs. The failure mode to watch for is the
-rulebook that only ever grows — hundreds of accumulated edicts nobody can hold
-(the Deuteronomy pattern, which this fleet has lived through once at population
-scale). The antidote is the distillation habit in §8 above, not a line count.
+rulebook that only ever grows. Distill lessons into practices with reasons at
+deposit boundaries (before clear or handover); use that habit, not a line count.
 
 ## 5. The trace — deliberate reorientation
 
 A trace is walking your chains **with your own file reads** and writing down
 where you stand: what am I doing (queue/NOTES) → under what contract (SPEC) →
-toward what intent (INTENT chain, leaf to root) → by what practice (LEARNED +
+toward what intent (`SPEC.md` intent field, leaf to root) → by what practice (LEARNED +
 SOP) → within what values (CULTURE). A few written lines at the end.
 `scripts/compose.py up` assembles any chain for you.
 
@@ -215,7 +206,7 @@ picture of where you stand may be stale* — after a large stretch of work, at a
 boundary (boot, handover, new mission, confusion), or when someone asks you to
 reorient. Why not simply "every N hours": identical scheduled prompts fade
 from an agent's attention with repetition, and idle seats accumulate ritual
-traces that crowd out real context — both failures observed here, at cost.
+traces that crowd out real context.
 Where a schedule fits your context anyway, use one — but prefer gating the
 *action* on evidence of change: `scripts/trace-due.sh` decides "has enough
 happened since my last trace?" deterministically and stays silent when the
@@ -245,17 +236,14 @@ exist and both are chains in that sense:
 delivery regardless of content. That is why `rig walk` elapses `--pace` between pieces, and why a
 composed render is meant to be read as a sequence rather than skimmed as a wall.
 
-**NAMING, RULED 2026-08-14 — the two ends have two words and neither is shared.**
+Use distinct names for the two directions:
 
-- **TRACE** — the pull ascent. `compose.py up` renders a node's chain to the root. This is what
-  `refocus` means by *run a trace*, and it is what the render itself now prints.
-- **`rig walk`** — the push verb, paced delivery into a seat's pane. It ships in the CLI, so treat
-  renaming it as a product change.
+- **TRACE** — the pull ascent. `compose.py up` renders a node's chain to the root.
+- **`rig walk`** — the push verb for paced delivery into a seat's pane.
 
-**"Walk" no longer means the ascent.** It drifted in through the render's own header and started
-competing with `trace`, which was already the word in `refocus` and in this file. **The fix is the
-name, not a sentence explaining the name** — a disambiguation you have to maintain is a defect you
-decided to live with.
+Use `refocusing` for the current trace workflow. A delivery receipt and an
+agent's read-depth report answer different questions; pacing alone does not
+establish understanding.
 
 ## 6. Writing — two principles
 
@@ -338,8 +326,11 @@ further setup. **A script that only works for its author is not shippable, howev
 tree (`LEARNED.md`). What is being built is the *work* tree (`SPEC.md`). One rig owns both; they
 still do not mix.
 
-**Project and mission bodies are short or absent** — `intent:` is the whole job at those altitudes.
-The slice is the only altitude that specifies.
+**Keep specification depth proportional.** A project carries stable intent; a
+mission carries its intent and mission-level specification in the same authored
+`SPEC.md`. Slices provide their concrete implementation scope. Follow the selected
+`mission-slice-sop` and any explicit mode overlay; mission specification is not a
+requirement to repeat every slice detail.
 
 ### The other axis: AUDIENCE is not MATURITY
 
@@ -363,8 +354,7 @@ practice must accrue** (*never broadcast to a large rig* took an incident).
 
 **LEARNED.md is not a staged item — it is the bed everything lies in.** Its gradient is
 positional: the dated append-log at the bottom is raw observation, the concise sections at the top
-are what survived. What is missing is a **trigger**, not structure — "periodically distill" has
-meant *never*. The answer: distil at deposit boundaries (pre-clear, pre-handover) where a write is
+are what survived. Attach distillation to a **trigger**: distil at deposit boundaries (pre-clear, pre-handover) where a write is
 already required and the author still remembers why each line exists; refocus merely *notices*
 when the log has outgrown the distilled part.
 
@@ -384,10 +374,9 @@ and how you discover which seats cannot yet describe their own job.
   at the next render, silently.
 - "Improving" the trace with pointer-following, serves-resolution, or any
   branching — the trace's entire value is that path-only ascent cannot fail
-  subtly; a smarter trace is a worse trace (design-ruled 2026-08-10).
+  subtly; keep the trace path-only.
 - Summarizing this model for another agent instead of pointing them here —
-  secondhand operating models are how operating models die; this skill was
-  authored precisely because a chain of summaries destroyed the last one.
+  a summary becomes another copy that can drift from its source.
 - Scripts in `scripts/` are macOS-flavored in places (`stat -f`); verify
   platform compatibility before trusting them on another OS.
 

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/scripts/trunk-diff.sh

@@ -6,7 +6,7 @@
 set -euo pipefail
 ROOT="${1:?usage: trunk-diff.sh <root-dir> <state-file> [--name FILE ...]}"
 STATE="${2:?state-file required}"; shift 2
-NAMES=("$@"); [[ ${#NAMES[@]} -eq 0 ]] && NAMES=(--name CULTURE.md --name PLAYBOOK.md --name LEARNED.md --name INTENT.md)
+NAMES=("$@"); [[ ${#NAMES[@]} -eq 0 ]] && NAMES=(--name CULTURE.md --name SOP.md --name LEARNED.md --name SPEC.md --name PLAYBOOK.md --name INTENT.md)
 HERE="$(cd "$(dirname "$0")" && pwd)"
 NEW="$(mktemp)"
 python3 "$HERE/compose.py" down "$ROOT" "${NAMES[@]}" | grep -v '^<!-- GENERATED' > "$NEW"

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/templates/LEARNED.md

@@ -1,14 +1,15 @@
 ---
 seat: <pod>-<member>@<rig>            # or rig/pod/fleet coords at higher altitudes
-template: <path-or-name of PLAYBOOK.md this diffs against> @ <version/sha>
+template: <path-or-name of SOP.md this refines> @ <version/sha>
 owners: self (sole direct writer) · <orchestrator/PM> (by proposal) · hierarchy (boundaries only, marked)
 updated: <YYYY-MM-DD from the clock command — never mental math>
 status: UNSEEDED  # the first real occupant replaces this line with: seeded-by-self <date>
 ---
 # LEARNED — <instance coords>
-<!-- HARD CAP ~150 lines. At the cap: distill LESSONS into HOW I WORK, or expire them. -->
+<!-- Size is soft guidance: keep the file as small as honestly covers the job.
+     Before handover or clear, distill LESSONS into HOW I WORK and retain needed context. -->
 
-## MY JOB HERE (≤10 lines)
+## MY JOB HERE
 <!-- This instance's actual function, in operational terms. If you cannot write
      this section yourself, say so to your orchestrator — that discovery is the
      audit working, not a failure. -->
@@ -35,6 +36,7 @@ status: UNSEEDED  # the first real occupant replaces this line with: seeded-by-s
 <!-- situation → read this. Attach pointers to MOMENTS, not to boot. -->
 - 
 
-## LESSONS (append-only, dated, capped)
-<!-- newest first. At cap: distill upward or expire. -->
+## LESSONS (dated, newest first)
+<!-- Distill into HOW I WORK at deposit boundaries; preserve necessary reasons
+     and archive superseded material. Attention is the budget, not a hard line cap. -->
 - 

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/templates/PLAYBOOK.md

@@ -1,5 +1,4 @@
-# MOVED — this file is now SOP.md
+# Legacy pointer — use SOP.md
 
-Renamed PLAYBOOK.md -> SOP.md per owner naming ruling 2026-08-11 (names are
-prompts; SOP is the stronger consult-and-follow trigger and the factory-native
-term). Read ./SOP.md. One-transition-period pointer; do not edit here.
+The procedure template is [SOP.md](SOP.md). Use it for new chain files; this
+PLAYBOOK.md pointer preserves the old address. Edit the current template.