@openrig/cli 0.5.7 → 0.5.9

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

@@ -187,9 +187,19 @@ The layers compose from surfaces that already exist; no new mechanism is require
   situation says which composition menu applies (fresh boot, occupant handover,
   post-compaction restore); FULL vs HIGH-ALTITUDE says how much of each layer the
   seat class receives. Choose both, independently.
+- Named install profiles make that independent depth/ordering choice explicit.
+  `rig context profile world-public --situation fresh --runtime codex --profile codex-coverage
+  --rig <rig> --seat <seat> --mission <mission> --slice <slice> --json` is
+  delivery-free inspection: it reports the selected profile, ordered phases,
+  exact pieces, token estimates, hashes, and source provenance before anything
+  reaches a seat. The `codex-coverage` profile orders bootstrap → concrete
+  project/mission/role/task → coverage map; `guided` keeps the fuller authored
+  walk separately selectable. Both select from the same source graph.
 - Position: the `--rig`/`--seat` grant serves the seat's lessons and recap.
-- Delivery: `rig walk <seat> --through <files> --pace <interval>` for byte-walks;
-  paced sends naming addressed reads for pointer-walks.
+- Delivery: `rig walk <seat> --through-profile world-public --profile <profile>
+  --situation <situation> ...` applies the already-inspected profile;
+  `--through <files> --pace <interval>` remains the raw byte-walk path. Paced
+  sends naming addressed reads serve pointer-walks.
 - The delta: a dated markdown file beside the seat's recap; verified by reading it.
 
 Where these verbs are unavailable (a different toolchain, a plain filesystem), the

package/daemon/docs/reference/project-workspace.md

@@ -4,6 +4,9 @@ OpenRig's Project TUI is a file-backed view over a workspace root. The folder
 shape is intentionally simple so humans and agents can create or repair it
 without daemon-internal knowledge.
 
+This subtree is part of the wider [OpenRig Instance Layout](instance-layout.md).
+The instance initializer delegates these exact workspace bytes to this owner.
+
 ## Default Shape
 
 `rig config init-workspace` creates the default workspace at
@@ -11,48 +14,70 @@ without daemon-internal knowledge.
 
 ```text
 workspace/
-  README.md
-  STEERING.md
+  SPEC.md
+  project.yaml
+  workspace.yaml
+  .gitignore
   missions/
-    README.md
-    idea-ledger/
-      SPEC.md
-      NOTES.md
-      PROGRESS.md
-      slices/
-        capture-product-ideas/
-          SPEC.md
-          PROGRESS.md
-          PROOF.md
-          proof/
-        triage-product-ideas/
-          SPEC.md
-          PROGRESS.md
-          PROOF.md
-          proof/
-    handoff-loop/
-      SPEC.md
-      NOTES.md
-      PROGRESS.md
-      slices/
-        route-work-packets/
-          SPEC.md
-          PROGRESS.md
-          PROOF.md
-          proof/
-        verify-loop-evidence/
-          SPEC.md
-          PROGRESS.md
-          PROOF.md
-          proof/
-  progress/
-  field-notes/
-  specs/
+  exhaust/
+```
+
+The scaffold is additive: it creates missing canonical entries and never
+overwrites existing files, including with the deprecated `--force` flag.
+`exhaust/` and local `.openrig/` runtime projections are ignored; authored
+project context and mission/slice files remain versionable. `workspace.yaml`
+is the project-location catalog. The project manifest exposes empty
+`install.context` and `install.skills` selectors for ordered Markdown
+addresses and stable managed-catalog skill IDs, but neither skill source nor a
+System World belongs in this tree.
+
+## Project-world install
+
+`project.yaml` may select project context and managed skills together:
+
+```yaml
+schema: openrig.project/v0alpha1
+kind: project
+install:
+  intent: SPEC.md
+  context:
+    - conventions.md
+  skills:
+    - repository-maintenance
 ```
 
+`install.context` contains project-relative Markdown addresses. `install.skills`
+contains stable skill identities only. Skill source bytes live in the single
+configured managed catalog (`skills.root`, default `$OPENRIG_HOME/skills`),
+never under the project or workspace. `rig context work-install --runtime
+<claude-code|codex>` resolves both parts; add `--apply-skills` to reconcile the
+selected exact bytes into `.claude/skills/` or `.agents/skills/` under the
+caller's current working directory. Use `--cwd` when the receiving agent works
+somewhere else; the project-world metadata root is never assumed to be its code
+working directory.
+
+The generated harness directories and `.openrig/skill-loadouts/` ownership
+receipts are projections, not source. Product repositories should ignore them.
+Reconciliation removes a deselected entry only when its current bytes still
+match OpenRig's last owned projection; unrelated and locally modified entries
+are preserved or reported as conflicts.
+
+Seats of the same runtime commonly share one working directory. Their topology
+selectors are retained per canonical seat identity and projected as a union, so
+starting one role cannot remove another role's skill. A changed projection is
+visible only to a fresh harness process; reconciliation reports that boundary
+instead of claiming a running seat hot-reloaded it.
+
+An installed project selection is also retained in that working directory's
+ownership receipt. A later seat start with no project-world input preserves it;
+an explicit install whose `install.skills` is empty clears it. This keeps
+"project not supplied" distinct from "project deliberately selects no skills."
+
 ## UI Mapping
 
 - `workspace.root` maps to the Project workspace.
+- `workspace.catalog_path` maps to the `workspace.yaml` project catalog.
+- `workspace.projects_root` is the default home for catalogued project worlds.
 - `workspace.root/missions/<mission-id>` maps to a Project mission.
 - `workspace.root/missions/<mission-id>/slices/<slice-id>` maps to a Project slice.
 - Mission `PROGRESS.md` frontmatter supplies the mission status badge when the
@@ -98,12 +123,13 @@ default setup contract.
 If Project shows a mission discovery warning:
 
 1. Run `rig config get workspace.root --show-source`.
-2. Run `rig config get workspace.slices_root --show-source`.
-3. Confirm `workspace.slices_root` points at a folder containing mission
+2. Run `rig config get workspace.catalog_path --show-source`.
+3. Run `rig config get workspace.slices_root --show-source`.
+4. Confirm `workspace.slices_root` points at a folder containing mission
    directories with `slices/` children.
-4. Confirm `files.allowlist` includes `workspace:<workspace.root>` so the TUI
+5. Confirm `files.allowlist` includes `workspace:<workspace.root>` so the TUI
    can read mission `PROGRESS.md`.
-5. If the workspace is missing, run `rig config init-workspace` after operator
+6. If the workspace is missing, run `rig config init-workspace` after operator
    approval.
 
 No daemon restart is required for most config reads. Restart when changing

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

@@ -74,12 +74,36 @@ playbook.
 ## 6. The capability-delta lifecycle (standing law)
 
 Each release's capability delta is authored at the fence and bound to the exact
-published cut. Canon absorbs its named items; the canon header then names the delta,
-which EXPIRES it — verify the expiry fired, and never cite an expired delta. The new
-release's delta obligations start at ITS cut. A delta that outlives its absorption
-is a stale teaching site wearing a version number.
+published cut. Its baseline is the canon's actual last-absorbed marker, not an
+assumption that the immediately prior semver was absorbed. When canon is behind, the
+new delta is a cumulative synthesis of every intervening delta, preserving
+supersessions and pivots rather than concatenating old prose.
 
-## 7. What deliberately does NOT happen at the boundary
+Canon absorbs the kept public-product truths; the canon header then names the delta,
+which EXPIRES it — verify the expiry fired, and never cite an expired delta. Private
+project topology, host practice, and release ownership go to the versioned project
+world instead of leaking into the public package. The new release's delta obligations
+start at ITS cut. A delta that outlives its absorption is a stale teaching site
+wearing a version number.
+
+## 7. World absorption and discoverability
+
+- Every changed capability gets one small map: **user situation · current capability
+  · authoritative source · natural first product encounter · durable context home ·
+  clean-agent probe**. Record an already-good route and leave it alone.
+- Prefer point-of-need truth from the existing `--help`, error, command output, live
+  state, context catalog, work install, or skill router. The world install supplies
+  width and ontology; it should not copy exact facts a live surface can derive.
+- The release mission owns this review before its cut when possible, so public
+  world/help changes ship with the capability. This boundary verifies the exact
+  packaged result, repairs any missed absorption as explicit debt, absorbs private
+  project truth, re-primes, and observes whether a clean world-installed agent
+  reaches the capability from its situation without being told its name.
+- A missing route is a release finding. Repair the smallest existing seam or deposit
+  the evidenced gap into the derivable-context mission; do not create a second
+  capability registry, search service, or world store at the boundary.
+
+## 8. What deliberately does NOT happen at the boundary
 
 - No process migration: situational rules expired at the fence. The standing corpus
   is the four checking principles — verify by effect · evidence at source · honest

package/daemon/docs/reference/sdlc-conventions.md

@@ -73,6 +73,12 @@ should almost never see something that doesn't match what was planned — QA cat
 kicks them back. When the human looks, they map intent → plan → delivered at a glance, mostly by
 scanning screenshots down a single column, and give the final 1% approval.
 
+For a release mission, `mission.yaml` also names the Git strategy before build
+work starts: the branch/ref that is cumulative integration truth, its base, and
+when that truth is reconciled to main. Continuous integration to main and a
+release-line fold followed by one explicit merge are both valid; leaving the
+choice implicit is not.
+
 **The heavier flow — proof contracts, plan-lock, C1 drops, proof-lock — is PART B and is not in
 force unless assigned.**
 

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

@@ -13,7 +13,7 @@ You're running inside OpenRig. OpenRig ships a set of **skills** — small docum
 
 ## How OpenRig context works (30 seconds)
 
-Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file is the index over the whole shipped set. (For the full model of building/operating agent software, open `software-for-agents`.)
+Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file is the index over the whole shipped set. (For bounded procedures, open `agent-operated-workflows`; for ongoing agent-backed applications, open `agent-operated-software`.)
 
 Every row below names **how to reach the skill** — already-hot, or an exact load path. No row is a dead end.
 
@@ -63,7 +63,9 @@ These are auto-delivered to every rig; their name+description are already in you
 - **retiring-and-inheriting-a-seat** — you're planning a seat transition and need to retire the current occupant into a fresh successor without losing continuity.
 - **mission-slice-sop** — you're working a mission/slice (the SDLC: intent → mini-requirements + proof contract → build → QA → proof). The operating manual.
 - **messaging-the-human** — composing a message to the human. Plain language, no insider jargon.
-- **software-for-agents** — you want the full first-load model of how agent software is built and operated here.
+- **agent-operated-workflows** — a bounded real-world procedure needs an agent to interpret state and operate exact tools, or you are deciding whether ordinary code should own the loop.
+- **agent-operated-software** — you are designing or operating an ongoing application whose live backend includes OpenRig agents.
+- **software-for-agents** — compatibility redirect for the former `agent-operated-software` name; remove in 0.6.0.
 - **openrig-skills** — this index (you're reading it). Always loaded; the entry point to everything below.
 
 ### Load when your role or task calls for it (repo-shipped, profile-selected)