@openrig/cli 0.5.10 → 0.5.11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "mission-slice-sop"
-version: "0.5.10"
+version: "0.5.11"
 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

@@ -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/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.5.10"
+version: "0.5.11"
 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/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/context-packs/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/context-packs/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.

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

@@ -15,9 +15,10 @@ status: UNSEEDED
      checkbox items are stored marks; every roll-up above them is derived, never hand-authored.
      Legacy README.md nodes stay valid indefinitely; nothing is forced to migrate.
 
-     PROJECT and MISSION nodes: the frontmatter `intent:` IS the whole job. A mission
-     ORGANISES slices and carries the context they need; it specifies nothing. Keep the
-     body short or delete it — everything below this line is for SLICES.
+     PROJECT nodes carry stable intent. MISSION nodes carry intent and proportional
+     mission-level specification in this same authored file, organizing slices and
+     giving them shared scope. SLICE nodes carry concrete implementation scope.
+     Keep body depth proportional; do not repeat all slice details at mission level.
 
      WHATEVER BODY YOU DO WRITE, two tests per sentence:
        PORTABILITY — if it would read correctly on a stranger's machine it is knowledge
@@ -27,10 +28,9 @@ status: UNSEEDED
      And check the tree: traps and how-we-work live in LEARNED.md on the topology tree,
      not here. This file is what is being BUILT.
 
-     SLICE nodes are the ONLY altitude that specifies. Keep the sections you need and
-     delete the rest; this is a starting shape, not a contract. Under the FACTORY operating
-     model this node also carries mini-requirements and a proof contract — see that mode's
-     plugin. Under the LAB it does not. -->
+     Follow the selected mission-slice-sop and any explicit operating-mode overlay.
+     Use the required sections for that work; the generic body below is a starting
+     shape, not an additional gate or a requirement for every mission. -->
 
 # <name>