docs(projects): refresh the project, context and chain-file references against main (#789)

Projects, context and chain-file references re-verified against main (aa4ee793) for 0.6.6. Text only.

- chain-file-convention and legacy-topology-migration: CRAFT.md and ORCHESTRATION-CRAFT.md are chain names; startup delivers the rig spec's culture_file; the walkers also read NOTES.md and fall back to README.md; the legacy topology fallback covers only rig context trace (refocus trace, seat: atoms and handover priming read topology.root only); only product-team ships topology defaults today.
- refocus-channel: the content file is set in the harness environment (specs have no env key); a LEARNED.md practice reaches running seats through the refocus trace, a CRAFT.md practice only through configured refocus content; hook time limits.
- project-workspace: install never overwrites an existing project folder; work-install without a catalog; slice: tags are the authoritative queue-to-slice link, with mention-matching as the fallback.
- knowledge-maturity, lore-routing, mission-install, planning-dial: which commands enforce stage values, the rig and seat grant flags, walk's --seat-grant and --runtime, and where approved-spec-dial is recorded and shown.

Commands checked against the help inventory of a clean build of a350c59b.

docs/reference/chain-file-convention.md

@@ -50,13 +50,19 @@ Established chain names on the topology tree:
 - `LEARNED.md` — what a POSITION has learned; never shared or shipped as-is.
   A seat's LEARNED is identified by its PATH: the same seat name in two rigs
   is two different files.
-- `CULTURE.md` — norms layered into members at startup.
+- `CRAFT.md` — how work is done at that altitude (shipped at instance, rig and
+  seat), with `ORCHESTRATION-CRAFT.md` at rig level for orchestration practice.
+- `CULTURE.md` — team norms. Note that startup delivers the rig spec's own
+  `culture_file` (a path beside `rig.yaml`), not a `CULTURE.md` under
+  `topology.root`.
 
 ### The project tree
 
 Rooted at the workspace keys (`workspace.root`, `workspace.slices_root`).
 Chain names there: `SPEC.md` (intent in frontmatter composes up the chain;
-specification is a leaf property), `PROOF.md`, `PROGRESS.md`.
+specification is a leaf property), `PROOF.md`, `PROGRESS.md`. The walkers also
+read `NOTES.md` (or `MISSION_NOTES.md`), and fall back to `README.md` for a node
+without a `SPEC.md`.
 
 **Project-tree context cannot ship.** It describes what *you* are building —
 mission intent, slice specifications, proof contracts. No vendor can author it
@@ -70,8 +76,11 @@ defaults.)
 
 Before this convention the topology tree lived at `~/.openrig/shared-docs/rigs/`
 (design decision 2026-08-14: an arbitrary folder on one machine, not a product
-path). That location **stays readable** as a per-level fallback so existing
-rigs migrate instead of breaking — but every read that resolves there emits a
+path). That location **stays readable** as a per-level fallback for
+`rig context trace`, at the rig and seat levels, so existing rigs migrate instead
+of breaking. The refocus trace, `seat:` profile atoms and handover priming read
+only `topology.root`, so until migration they report those files as missing. Every
+read that resolves to the legacy location emits a
 named advisory (`legacy-topology-read: …`) stating the legacy source, the
 canonical destination under `topology.root`, and the config key. A silent
 legacy read is a defect. The legacy literal lives in exactly one helper per
@@ -93,9 +102,9 @@ reproduces the drift it was meant to catch. Run it; do not recall it.
 
 ## Shipped defaults and the curation path
 
-Included rigs (product-team first) ship sensible-default chain files at the
-applicable instance, rig, pod, and seat altitudes, installed under
-`topology.root` at rig-up.
+Included rigs ship sensible-default chain files under a `topology/` folder,
+installed under `topology.root` at rig-up. Today only `product-team` ships one,
+with instance, rig and seat defaults; the installer also supports pod defaults.
 A shipped default is a **starting point** the occupying team appends to — it
 is never overwritten by a later rig-up (existing files win).
 

docs/reference/knowledge-maturity.md

@@ -91,7 +91,9 @@ shipped vocabulary (four rungs plus two exits):
 `wip | provisional | established | canonical | superseded | retired`
 
 `superseded` must name its successor; `retired` means do-not-use. These are the ONLY
-valid values — invented stages (shape, shaped, draft) are rejected. Items minted under
+valid values — `rig scope slice stage` and `rig scope mission stage` reject invented stages
+(shape, shaped, draft) and a `superseded` without a successor; context-pack manifests and
+lore frontmatter aren't checked. Items minted under
 new conventions carry a stage from birth: labeling from day one is free, retrofitting
 is archaeology.
 

docs/reference/legacy-topology-migration.md

@@ -3,8 +3,10 @@
 For rigs whose hand-authored context predates the chain-file convention and
 lives at the legacy location (`~/.openrig/shared-docs/rigs/<rig>/`, or
 `$OPENRIG_SHARED_DOCS_ROOT/rigs/<rig>/`). Nothing here is destructive: the
-legacy tree is left in place, reads keep working throughout (the walker's
-advisory-emitting fallback), and every copy is no-clobber.
+legacy tree is left in place, `rig context trace` keeps reading it at the rig and
+seat levels throughout (with an advisory), and every copy is no-clobber. The refocus
+trace, `seat:` profile atoms and handover priming read only `topology.root`, so
+they see these files only after migration.
 
 ## The path, with exact commands
 

docs/reference/lore-routing.md

@@ -84,7 +84,8 @@ line so attribution remains visible when the resolver returns only that section.
 
 ## Addressing and composition
 
-Lore uses the existing `seat:` grammar and an explicit rig-and-seat read grant.
+Lore uses the existing `seat:` grammar and an explicit rig-and-seat read grant
+(`rig context profile <pack> --rig <rig> --seat <seat>`, which needs both flags).
 The address says which file or section to read; the grant says whose seat tree
 the address is relative to. No grant means no read.
 

docs/reference/mission-install.md

@@ -196,7 +196,9 @@ The layers compose from surfaces that already exist; no new mechanism is require
   retains `claude-code`. Profile defaults from `OPENRIG_RUNTIME`, otherwise
   Claude; work-install requires the flag to inspect or apply skills.
 - Delivery: `rig walk <seat> --through-profile world-public --profile <profile>
-  --situation <situation> ...` applies the already-inspected profile;
+  --situation <situation> ...` applies the already-inspected profile (walk's
+  seat grant is `--seat-grant`, and its `--runtime` takes `claude` or `codex`,
+  defaulting to `claude`, so a Codex profile needs `--runtime codex`);
   `--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.

docs/reference/planning-dial.md

@@ -50,4 +50,5 @@ Scope research to the unknown that could change the plan; scope an adversarial
 pass to the failure modes the author may miss. Record the questions resolved and
 the resulting design changes so the owner can judge the value of the selected
 rung. Run planned research before build dispatch, while its answers can still
-shape the spec.
+shape the spec. Record the chosen rung in the slice's frontmatter as
+`approved-spec-dial:`; `rig view show execution` shows it as `planning_dial`.

docs/reference/project-workspace.md

@@ -41,8 +41,12 @@ Reinstalling changes nothing. If the file's shape doesn't allow that (for
 example a flow-style list), if the id is already taken by another root, if the
 folder is registered under a different id, or if the rig is already listed
 under another project, install writes nothing to the catalog and prints what to
-change. Without a catalog, the one it writes keeps a `default` entry for the
-workspace root beside the bundle's.
+change, and the folder isn't copied either. An existing folder at
+`<workspace.projects_root>/<id>/` is never overwritten: if its files differ from
+the bundle's, install keeps it and says so. Without a catalog, the one it writes
+keeps an entry for the workspace root beside the bundle's, under the id from the
+workspace's own `project.yaml` (`default` when it declares none); if that id is the
+bundle's project id, install reports a conflict and writes no catalog.
 
 ## Project-world install
 
@@ -106,8 +110,12 @@ an explicit install whose `install.skills` is empty clears it. This keeps
 
 ## Work-install project selection
 
-`rig context work-install` picks one project from `workspace.yaml`, in this
-order:
+`rig context work-install` picks one project from the catalog at
+`workspace.catalog_path` (default `workspace.yaml`), in the order below. Without a
+catalog, the workspace root itself is the project (`selectedBy: workspace`), and
+`--project` must match its `project.yaml` id. Operating posture uses steps 3-5
+the same way when a queue row names no project (see
+[scoped operating posture](scoped-operating-posture.md)).
 
 1. `--project <id>`;
 2. the only declared project;
@@ -129,8 +137,9 @@ projects:
     rigs: [openrig-dev]
 ```
 
-`rigs` is optional. An entry whose `rigs` isn't a list of rig names is ignored
-with a warning. A rig listed under two projects, or two projects sharing the
+`rigs` is optional. A `rigs` value that isn't a list of rig names is ignored
+with a warning; the entry can still be chosen by `--project`, as the only entry
+or by working directory, but never counts as unclaimed in step 5. A rig listed under two projects, or two projects sharing the
 deepest root, leave the choice to `--project`. Step 3 reads the seat's
 `OPENRIG_SESSION_NAME`, so a plain shell skips it. `--json` reports the step
 that chose the project as `position.selectedBy`.
@@ -178,14 +187,19 @@ ambiguity.
 
 ## Queue Mapping
 
-Queue items attach to a slice when their body or tags mention one of:
+A `slice:<id>` tag is the authoritative way to attach a queue item to a slice;
+with a project selected, typed rows also need the `project:<id>` tag. As a
+fallback, for slices with no typed rows, items attach when their body or tags
+mention one of:
 
 - the slice id;
 - the mission id;
 - the legacy `rail-item` value in slice frontmatter.
 
-For new work, include both mission and slice ids in the queue item body or
-tags. Example:
+Once any slice in a mission has typed rows, the fallback stops matching on the
+mission id (and on a `rail-item` defaulted from it) for that mission's other
+slices too. For new work, tag rows with `slice:<id>` (and `project:<id>`), and
+include the mission and slice ids in the body as well. Example:
 
 ```text
 Mission: idea-ledger

docs/reference/refocus-channel.md

@@ -26,7 +26,10 @@ redundant double-fire around Codex's own compaction cadence. Set
 `OPENRIG_REFOCUS_ENABLED=0` to disable the feature. Fresh `SessionStart` is
 always a no-op: the default onboarding pack owns fresh orientation. Both
 runtimes retain `PostCompact` due-state for the next prompt. Otherwise the hook
-is a silent no-op, and it degrades to silence on unrelated hook errors. A
+is a no-op (it writes a stderr advisory when the transcript shrinks or the
+session has no identity), and it degrades to silence on unrelated hook errors.
+Both runtimes stop the hook after 5 seconds, and the content REF lookup gets 2;
+a slow REF shows as `REFOCUS CONTENT REF FAILED`. A
 configured REF resolution failure instead degrades
 loudly in the delivered payload while still completing the hook — a refocus
 must never break a seat's turn.
@@ -44,8 +47,9 @@ Resolution order:
 1. `OPENRIG_REFOCUS_CONTENT_REF` — a path-like context-library ref resolved
    through `rig context get`, so refocus receives the same assembled bytes as
    on-demand pull. This wins when REF and FILE are both set.
-2. `OPENRIG_REFOCUS_CONTENT_FILE` — an operator-authored file (per-seat or
-   per-rig via spec env).
+2. `OPENRIG_REFOCUS_CONTENT_FILE` — an operator-authored file, set in the
+   environment the seat's harness runs in (rig and agent specs have no `env`
+   key).
 3. `$OPENRIG_HOME/refocus/REFOCUS.md` — the instance's standing content.
 4. The generic default at
    `skills/refocusing/references/refocus.md`: three project-neutral orientation
@@ -77,8 +81,10 @@ This automatic hook path is additive to one-shot manual injection through
 
 The chain files are the durable, altitude-addressed home of orientation
 content; the refocus channel is its delivery schedule. A practice added to a
-rig's `CRAFT.md` today reaches running seats through their next refocus
-pointer, and future installs through the shipped defaults
+rig's `LEARNED.md` today reaches running seats through their next refocus
+trace, which reads `LEARNED.md` at each topology level. A `CRAFT.md` practice
+reaches them only through the configured refocus content (REF or FILE), and future
+installs through the shipped defaults
 (discovery → curation → ship, per the convention doc).
 
 ## What a refocus is NOT