@openrig/cli 0.5.5 → 0.5.6

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

@@ -1,234 +0,0 @@
-# ROLLOUT — adopting the Operating Model on a live fleet
-
-This file is deliberately verbose. It is the adoption plan, the interim
-practices, and the reasoning — everything time-bound that does NOT belong in
-SKILL.md (which teaches the model itself, timelessly).
-
-## Why a rollout plan exists at all
-
-This model was designed after a measured failure: several consecutive
-generations of critical seats onboarded through handover documents alone and
-each lost most of the operational knowledge of its predecessor — without
-knowing it (the Dunning-Kruger shape: the loss is invisible from inside).
-The fleet also has real rate limits: fifty seats reading a large skill
-simultaneously is a provider incident, not a rollout. Both facts shape
-everything below.
-
-## The three pieces
-
-1. **The markdown** — files must exist before anyone can walk them.
-2. **The rolling upgrade** — seats adopt in small waves, top-down.
-3. **The enforcement floor** — watchdog-fired due-checks keep the trace habit
-   alive without any new product code.
-
-## Piece 1 — the markdown layer (create/rename/map; migrate nothing finished)
-
-- **Rule zero: no migration of finished work.** Completed missions, closed
-  specs, historical notes stay untouched forever. The model starts with work
-  IN FLIGHT and everything new.
-- **Renames:** the old `STEERING.md` files become `INTENT.md` (same content,
-  new name — "steering" predated the fleet's settled use of the word intent).
-  Leave a one-line pointer file at the old name for one transition period.
-  The frozen drift-correction spec (0.5.4) refers to the steering substrate;
-  its owner amends the naming there (see ROADMAP.md).
-- **Mappings, not moves:** today's standalone slice PRD IS the slice-level
-  `SPEC.md`, as-is, no edits. `MISSION_NOTES.md` keeps serving every mission
-  that already uses it; new missions start with `NOTES.md`.
-- **Creation:** `scripts/scaffold.sh` places missing chain files as UNSEEDED
-  templates. It never overwrites, never deletes.
-- **Topology-tree root, RULED (pm-lead wave-1 review, 2026-08-10):** the
-  canonical on-disk root for topology chain files is the existing rig home —
-  `shared-docs/rigs/<rig>/` — so a seat's files live at
-  `shared-docs/rigs/<rig>/seats/<seat>/`. That shelf already holds each rig's
-  `rig.yaml`, rig-level `CULTURE.md`, and `state/`, so the chain composes with
-  what exists instead of minting a parallel tree. Seat instances never live
-  inside this skill's directory (the skill is distribution canon, not runtime
-  state; the two early seeds that diverged were reconciled here: pm-openrig's
-  provisional placement confirmed, pm-lead's moved to match).
-- **Seat files:** created by scaffold, but their CONTENT is seeded only by the
-  protocol below — never mass-produced.
-
-## Piece 2 — the rolling upgrade
-
-**Wave order and why:** those who review others must hold the model first.
-
-- **Wave 1 — coordinators:** the PMs, the operator agent, the oversight lead,
-  rig orchestrators. Small group, immediately; they will be reviewing every
-  later seed.
-- **Wave 2 — the priority rig.** (At the time of writing: the build VM — the
-  current unblock focus.) Its orchestrator paces its own seats: a few at a
-  time, as their work allows, never all at once.
-- **Wave 3 — the next rig.** (At the time of writing: the studio rig.)
-- **Wave 4 — everyone else, on contact:** a seat reads the skill the first
-  time work reaches it under the model. No seat is interrupted just to read.
-
-**Pacing law:** waves are small and self-paced BY DESIGN — this is a
-rate-limit safety rule, not a preference. An orchestrator rolling its rig
-staggers reads. If a wave would put more than a handful of seats into
-simultaneous heavy reading, split the wave.
-
-**The adoption receipt is the seed.** A seat has adopted when its
-`LEARNED.md` v1 exists, written BY THAT SEAT in its own words (distilled from
-whatever records it has — handover documents, its runtime memory, its queue
-history), and reviewed by its orchestrator or PM. Reading without seeding is
-not adoption; there is deliberately no other receipt to fake.
-
-**Seeding doubles as the capability audit.** A seat that cannot write its own
-MY JOB HERE section has just revealed precisely what its handover lineage
-lost. That discovery is a SUCCESS of the rollout, not a failure — it converts
-an invisible capability gap into a named, fixable one. Orchestrators: when a
-seed comes back thin or confused, that seat needs re-onboarding against its
-SOP, not a rewrite of its seed by someone else.
-
-**Hierarchy-seeded exceptions:** empty seats, broken seats, and seats being
-re-staffed get their files written by whoever is responsible for them, with
-those lines marked as written-for-the-instance. The next real occupant
-rewrites them in its own words as a first act.
-
-## Piece 3 — the enforcement floor (no product code required)
-
-Register a watchdog (or any scheduler) per adopted seat that fires
-`scripts/trace-due.sh` on a modest cadence. The script no-ops silently unless
-enough has actually changed since the seat's last trace, so the schedule can
-be dumb while the action stays evidence-gated. When it reports DUE, the seat
-runs the trace per SKILL.md §5 and stamps (`scripts/trace-stamp.sh`).
-Schedulers, files, and two tiny scripts — that is the entire interim
-enforcement system, and it degrades gracefully: if every scheduler dies, the
-model still works, just without reminders.
-
-## The dual-home interim (skills are NOT drained yet)
-
-Much altitude-specific knowledge currently lives in the skill layer (pod
-handbooks, seat SOPs, fleet doctrine) because the skill layer was the only
-durable shelf that existed. The placement rule says that knowledge belongs in
-the trees — AND the drain does not happen now. During rollout:
-
-- existing skills remain exactly where they are and remain authoritative;
-- the new tree files are built USING them as reference material;
-- the same knowledge deliberately lives in both places for a while;
-- the drain happens later, deliberately, when the unified skill registry
-  lands (see ROADMAP.md) — never as a side effect of the rollout.
-
-## SOP authoring plan (owner-approved 2026-08-10; product team owns)
-
-**Composition (owner-ruled 2026-08-10):** pod SOP = the general layer ·
-seat SOP = a TYPE fragment, shared/projected across same-type seats (byte-
-identical; occupant edits go to LEARNED, never the fragment; divergence is a
-parity scream) · LEARNED = the lived instance. Fragments are authored per TYPE
-(roughly ten fleet-wide), never per seat.
-
-**Round 1 — type fragments, by the three-hands pattern:**
-1. *Incumbents* of the type dump raw seat-truth to a `SOP-STASH-raw.md`
-   (facts as learned, not doctrine), including a **drift-check line**: which
-   skills they actually consult vs what their `agent.yaml` declares.
-2. *A fresh one-shot author* (single-purpose agent, no continuity required —
-   all state lives in files, so the step is robust to handover/compaction
-   failures) distills the fragment from a **named reading list**, pinned at
-   dispatch with an existence check on every path:
-   exemplar fragments (the accepted product-manager fragment + the PM pod
-   layer) → the seat's `agents/<role>/agent.yaml` (its `uses.skills` list IS
-   the derived canon list) + `guidance/role.md` (the fragment's direct
-   ancestor — read AGE-STAMPED; where it disagrees with the STASH, record
-   drift, don't resolve) → the 2–4 declared team/role skills →
-   `state/onboarding/` material and ADRs where the rig has them → the STASH.
-   Constraints inline: ~1 page · type-level only (instance→LEARNED candidates,
-   rig-wide→pod/rig layer — the author routes, never dumps) · `Sources:` line ·
-   flag gaps, never invent.
-3. *Type occupants verify* ("does this describe my job?") and the rig
-   orchestrator/PM holds the coherence + placement review.
-   **Criterion upgrade (from the wave-1 outside-lineage cold read, 2026-08-11):**
-   beyond voice/duties/scars/gaps, review for **SELF-CONSISTENCY** — does the
-   file obey its own stated rules? (the wave-1 misses were all files breaking
-   their own rule: cached doctrine beside a read-at-source rule; a volatile
-   snapshot beside a presence-check rule; an expiry with no trigger beside a
-   remembered-follow-up-is-not-a-mechanism rule) — and **POST-SEED ALIVENESS**:
-   a one-sitting seed legitimately wears the dated-ledger form, but reviewers
-   re-read at ~+2 weeks; a LEARNED that never gains a post-seed entry is a
-   monument, not a rail.
-   Old artifacts (role.md, agent.yaml, team skills) stay exactly where they
-   are and stay authoritative — dual-home until the deliberate drain.
-   Order: wave-2 build-VM types first, then oversight, kernel/ops, studio.
-   skills-architect spends ZERO tokens now (context-constrained + handover in
-   process); their batched consistency pass rides the 0.6 registry drain.
-
-**Binding inputs registered for round-1 fragments** (owner-flagged content
-that MUST land in the named fragment; a draft missing its binding input fails
-review — this list is read at every one-shot dispatch and at every review):
-- **DRIVER type (build VM)** — owner recurrence flag 2026-08-10 (~100th
-  correction, zero uptake while it lived only in chat): on the VM, the DEFAULT
-  for a runtime defect is the **inner loop** — ground → fix → upgrade the
-  daemon in place → test with your own eyes → iterate; ship-rigor once at the
-  end; rollback only for a VM that cannot work. The conveyor is not the
-  default for a one-mechanism defect.
-- **ORCHESTRATOR type (build VM)** — same flag: before routing any defect
-  into the conveyor, ask first whether ONE grounded agent with its own
-  feedback loop can fix and verify it in place. Conveyor only for what ships
-  beyond the VM or touches locked contracts.
-- **THE CHOOSER (owner root diagnosis, same conversation, addendum 2026-08-11):**
-  the incoherence under the recurrence is that every task gets the identical
-  SDLC regardless of shape. Carried as ONE principle, not a rubric: **default =
-  the lightest thing that could work** (one agent, own judgment, own feedback
-  loop); the conveyor must be EARNED by a stated one-line reason (ships beyond
-  VM / public / locked contract / security boundary / multi-hand scope); no
-  reason line = light path. The orchestrator fragment carries the triage
-  question; the driver fragment carries the inner loop. Deliberately NOT a
-  classification taxonomy — a taxonomy would be new ceremony.
-- **SHARPER FORM (orch-advisor's self-seeded fold — use this shape):**
-  (1) SCAR-vs-LAW — a lesson stated only negatively teaches fear of one
-  mistake, and occupants drift back UP because ceremony always FEELS like
-  rigor at zero visible cost; the fragment must state the POSITIVE default
-  (light; conveyor earns entry with a reason line) because that is what makes
-  the choice decidable. (2) THE COROLLARY — a tier chosen correctly once does
-  not stay correct; the tier is a function of the atom, not a property the
-  atom keeps; RE-CHOOSE whenever the surface changes (specimen: P18 judged
-  conveyor-worthy with a config surface, descoped to mostly-deletion, old
-  tier = ceremony inherited by momentum). Both belong in the ORCHESTRATOR
-  fragment, verbatim-substance.
-- **ALL-TYPES binding input (triple-confirmed 2026-08-11: dev50-driver ×4 in
-  one night, orch-advisor ×3, pm-openrig desk ×2): THE SCOPED-READ LAW —
-  "a scoped read that does not name its scope manufactures a false absence."**
-  Every list/show/ps/send resolves against SOME scope (rig, daemon, host,
-  registry, filter); a negative result is only evidence within the named
-  scope. Every seat-type fragment carries this; reviewers enforce it like the
-  chooser.
-(Companion folds already in flight at the implicated seats' LEARNED files:
-product planning done; operator a947ed35 and advisor 1f89e5d6 owner-directed.)
-
-**Round 2 — ontology backfill per seat, pod, and rig (owner-directed
-2026-08-10):** after a node's SOP/LEARNED pair exists, one deliberate
-audit pass folds the rest of its scattered wisdom into the walkable layer:
-- **Claude memory files** (`~/.claude/projects/*/memory/` per seat) — tribal
-  wisdom that is written but almost never re-read (the "learning banked, then
-  never consulted again" failure mode this model exists to kill). Each memory
-  item either folds into LEARNED/SOP at its altitude or is explicitly
-  left as session-scoped; LEARNED folds are executed by the seat itself
-  (self-seeded law), playbook-layer folds by the fragment's owner.
-- **openrig-work core** — doctrines, `conventions/`, and skills content that
-  is really seat/pod/rig practice — same routing, same dual-home rule:
-  originals stay in place and authoritative; the trees gain the walkable copy;
-  the drain stays a later deliberate act.
-
-## Current status (update this section as waves complete)
-
-- Design locked by the owner: 2026-08-09.
-- Skill authored (sole-context authorship) and projected on the primary host:
-  2026-08-09. VM projection: operator's leg, with wave 2.
-- Wave 1 COMPLETE 2026-08-10: all five coordinator seats seeded + reviewed
-  (pm-openrig, pm-lead, watch-lead, pm-studiobox, operator-agent). Wave 2
-  (build VM) released the same day; its orchestrator paces.
-- First SOPs exist: PM pod layer + product-manager type fragment
-  (projected to both product-PM seats) + program-manager type fragment.
-- STEERING→INTENT rename: openrig-platform done (owner) · factory anchor +
-  openrig-work root done 2026-08-10 (pointers at old names) · studio-boxes =
-  pm-studiobox's to execute · idea-ledger-gstack pending its owner.
-- The factory is unparked (wave-1 adoption complete).
-- NAMING RULED (owner, 2026-08-11): PLAYBOOK.md -> **SOP.md** fleet-wide
-  (names are prompts; SOP = the consult-and-follow trigger, factory-native).
-  All seven existing files renamed with one-transition pointers at old names;
-  LEARNED keeps its name (it is the maturity PIPELINE, and the low-friction
-  write-prompt is load-bearing). Projection recipes are **maps** (codemaps,
-  the name's prior holder, retire into this system). The corpus/canon
-  distribution program = skill **openrig-corpus-canon** (design of record:
-  product/DESIGN-context-distribution-2026-08-10.html); round-2's
-  hand-fold-canon leg is SUPERSEDED by it — round-2's lived-side leg
-  (claude-memory -> LEARNED, seat-executed) continues unchanged.

package/daemon/context-packs/skills/core/attention-queue/SKILL.md

@@ -1,264 +0,0 @@
----
-name: attention-queue
-description: Coordination primitive for OpenRig. Per-agent queue files tracking in-flight work with explicit state transitions + handoff semantics + cross-agent composition. Prevents memory-loss drops; surfaces stalls mechanically; closes the feedback loop on handed-off work. Applied liberally by every agent on every kernel-supervised rig; composed views serve human attention, orch pod-load, rig pending-work.
-status: L4-insight
-authored-by: advisor-peer-observer@your-rig
-date: 2026-04-13
-cited-captures:
-  - improvements-inbox.md 2026-04-13T12:54:50Z — broadcast primitive RSI (same batching-by-theme cluster)
-  - Mission 4 cmux stall (2026-04-13 midday) — packet-design + queue-for-cross-rig coordination
-metadata:
-  cli_surfaces_referenced:
-    - chatroom
-    - send
-  openrig:
-    stage: factory-approved
-    sibling_skills:
-      - queue-handoff
-      - workflow-runtime
-      - watchdog
-      - refocus
-      - looping-workflows
-      - intake-routing
-      - human-in-the-loop
-      - dispatching-parallel-agents
-      - subagent-driven-development
-      - control-plane-capabilities
-      - status-not-chat-orchestrator
-      - control-plane-queue
-      - control-plane-watchdog
-      - control-plane-workflows
-      - control-plane-delivery-loop
-      - control-plane-rollout-manager
----
-
-# Attention queue
-
-Use this skill when coordinating work that must survive compaction, cross-agent handoffs, or multi-hour stall detection. Applies when you'd otherwise narrate status to chat or rely on memory for pending items.
-
-## Live protocol override
-
-Current live routing protocol:
-
-- **Known target / explicit owner that should wake now**: `rigx queue handoff <destination> "<body>" --type handoff --urgency soon`
-- **Passive durable assignment without wake-up**: `rigx queue create <destination> "<body>" --type handoff --urgency soon`
-- **Ambiguous or raw intake**: `rigx stream emit "<body>" ...`
-- **Direct dialogue / urgent 1:1 conversation**: `rig send ...`
-- **Summoned 3+ party roundtable**: `rig chatroom ...`
-
-Do not cargo-cult the earlier "stream everything with `--destination`" prototype shape into the
-live control-plane. Stream is now the ambiguous-intake lane, not the universal lane.
-
-## Core shape (minimum-viable discipline)
-
-1. **Author a queue file at** `substrate/shared-docs/rigs/<your-rig>/state/<your-pod>/<your-member>.queue.md`. Same per-pod directory as your session log.
-2. **Every known-target hot-potato work handoff** should arrive via `rigx queue handoff`, not via `rig send`. Use `rigx queue create` only when you intentionally want a passive durable item without wake-up.
-3. **State transitions** (start → promote; finish → complete; stuck → block; hand off → handoff; completed handed-off work notifies source → handoff-complete) are appended to the entry body with timestamp. Never in-place rewrites.
-4. **Cross-rig reads permitted; cross-rig writes forbidden.** Pod-as-authority-boundary doctrine.
-
-### Live command surface note
-
-When the queue control-plane wrapper is installed, treat queue identity as command-resolved, not
-seat-name-guessed:
-
-- `rigx queue whoami` resolves the durable queue that belongs to your current seat
-- `rigx queue list --mine` shows your queue without guessing from member name
-
-This matters for continuity successors such as `lead2` or `lead5`, which may intentionally share
-the canonical `lead.queue.md` file instead of owning a separate `lead2.queue.md` or `lead5.queue.md`.
-
-Known-target direct handoff on the live wrapper:
-
-```bash
-rigx queue handoff orch-lead5@your-rig "Need PM shaping on queue attention loop" --type handoff --urgency soon
-```
-
-Passive durable write without wake-up:
-
-```bash
-rigx queue create orch-lead5@your-rig "Need PM shaping on queue attention loop" --type handoff --urgency soon
-```
-
-## Six operations
-
-| Op | Effect |
-|---|---|
-| append | New entry (state=pending) on inbound request |
-| promote | state=in-progress when you start work |
-| complete | state=done with optional result |
-| block | state=blocked + blocked-on=<id or condition> |
-| handoff | state=handed-off + handed-off-to=<target>/<new-id>; send rig-send with `[queue-handoff:]` prefix to target |
-| handoff-complete | target signals source that handed-off work finished (closes feedback loop) |
-| escalate | walk authority chain when blocked past tier threshold |
-| defer / drop | push-to-later or drop-with-rationale |
-
-## When is something a queue handoff?
-
-**Queue handoff** (`rigx queue handoff`):
-- Asks a known recipient to do new work
-- Transfers ownership of pending work
-- Names a deliverable + acceptance criteria
-
-**NOT a queue handoff**:
-- Wake-ping `1`
-- PSA / broadcast / status update
-- Ack / courtesy notification / diagnostic ping / reply to question
-- Raw idea or bug where you do not yet know the right owner
-
-If you do not know the correct owner, emit to stream instead of guessing.
-
-## Tier-based ack + notification rules
-
-- **human-gate tier** (gated items; human-watching): mandatory ack on handoff; mandatory notification on completion
-- **agent-coordination tier** (standard inter-agent work): recommended ack + notification
-- **internal-self tier** (your own to-dos): optional
-
-## Read discipline
-
-- Read your own queue at turn start before picking up new work
-- Orchestrators read pod-member queues on wake cadence (`1` ping)
-- Advisor-pod reads cross-rig queues for composed views + human-attention
-- Past-threshold blocked entries surface during sweeps; execute escalate op if you can't self-unblock
-
-Recommended turn-start queue commands on the live wrapper:
-
-```bash
-rigx queue whoami
-rigx queue list --mine
-```
-
-### Resume-from-idle state sweep
-
-Agents returning from idle-standby (supervisor-wake-only pings; no substantive dispatch during the window) MUST sweep adjacent state before pulling new work. Minimum sweep:
-
-- Supervisor-log tail (~200 lines) at `rigs/kernel/state/supervisor-log.md`
-- human-attention.md at `substrate/shared-docs/human-attention.md`
-- Any doctrine-decisions added since last-active (`rigs/kernel/state/doctrine-decisions/`)
-- Partner queue files at `rigs/kernel/state/<pod>/<peer-member>.queue.md` (peer load-tracking for pairs)
-- **Fleet-changes-feed** at `substrate/shared-docs/fleet-changes-feed.md` (pull-native rollout surface; catches any fleet-wide doctrine / skill / convention / operational changes that landed during idle; filter by scope = fleet-wide + your rig/pod)
-
-**Trigger:** first active turn after ≥3 consecutive wake-only cycles OR on peer HA-check request. Sweep before responding to HA-check so the response is grounded in current reality, not stale memory.
-
-**Rationale:** own-queue-at-turn-start catches own-queue drift; adjacent-state drift is a separate failure class that requires its own read discipline. Composable with own-queue sweep (both at same reading point); adds ~2-5 minutes of read time; cheap insurance against peer-driven HA-check round-trips.
-
-**Worked example (genesis):** advisor-co-observer@your-rig after ~2h idle-standing-by on 2026-04-13 — 5-of-7 HA-check items out-of-sync when peer queried. Rule addition would have caught the drift pre-query via adjacent sweep on wake-to-active transition.
-
-## Status-not-chat corollary
-
-Your chat pane is for operational work + ad-hoc human exchanges. Your STATUS lives in queue files + composed views. If you finish work + hit a gate-requiring next-action, do NOT narrate to chat + idle-wait. Queue-handoff to advisor-pod with `tier: human-gate`. The operator doesn't watch agent panes; they watch human-attention.md (composed from human-gate queue entries).
-
-## Composed views (4 layers)
-
-- **Pod-load view** — who's loaded / blocked (orch reads)
-- **Rig pending-work** — cross-pod roll-up
-- **Fleet cross-rig** — host-wide
-- **human-attention** — human-gate-tier items across all queues (advisor-pod composes)
-
-v0: manual regen by orchestrators + advisor-pod.
-v0.5: terminal-node watch scripts auto-regen.
-v1: generative UI consuming structured queue data.
-
-## Codex-sandbox proxy-write pattern (sanctioned workaround)
-
-Codex members whose sandbox blocks substrate writes can still participate via proxy-write:
-- Codex authors content locally (e.g., `/tmp/<rig>-attention-queue/<member>.queue.md`)
-- Claude counterpart physically writes to substrate with sha256-verified integrity check
-- Subsequent state transitions via `[queue-update: <id> <new-state> <reason>]` rig-send from Codex to Claude-writer
-- Authorship preserved; only write-access delegated. Distinct from peer-injection (which is forbidden).
-
-## Escalation mechanics
-
-When entry stays blocked past tier threshold AND agent can't self-unblock:
-
-1. Identify escalation target per authority chain:
-   - Pod member → pod orchestrator
-   - Pod orch → rig orch-lead
-   - Rig orch-lead → kernel orch-lead OR advisor-pod (if human-gate)
-   - Skip-levels allowed when agent KNOWS correct target
-2. Create new entry in escalation-target's queue with `escalated-from: <source-id>`; state=pending; priority elevated
-3. Send handoff-shape rig-send: `[queue-escalate: <new-id>] <title> — blocked <Nh> on <reason>`
-4. Update own entry: state=escalated; escalated-to=<target>/<new-id>; transitions-log appended
-
-Threshold guidance: 1h human-gate / 4h agent-coordination / 24h internal-self. Rigs may tighten.
-
-## Task-close RSI-check (flywheel trigger)
-
-Every `complete` op on substantive work reflects briefly: "what did we learn? is this worth filing as L2 capture to improvements-inbox?"
-
-Two outcomes; both leave evidence in the transition trail:
-
-- **Novel observation worth filing:** append L2 capture entry to `rigs/kernel/state/improvements-inbox.md` per the v1 queue template (`state: pending` + transition trail started). Transition line in your own queue: `<ts> — RSI-check: filed <capture-id>`.
-- **Nothing novel:** transition line in your own queue: `<ts> — RSI-check: none`.
-
-Applies to substantive work-streams. Does NOT apply to:
-- Wake-pings (`1`) — not a work-stream
-- Trivial status updates — nothing to reflect on
-- Pure acks / routing-map updates — no work done
-
-Rationale: task-close is the deterministic interval that makes recursive-self-improvement mechanical rather than ad-hoc. Pattern named in skill-maturity-convention.md §"Task-close RSI-check discipline".
-
-## Push vs pull — when to use rig-send vs queue-write
-
-Not every communication belongs in the receiver's chat pane. The discipline mirrors status-not-chat: most inter-agent signals can flow through queue files (pull) rather than rig-sends (push). Reduces noise; respects receiver's attention cycle.
-
-**Sender's test:** *Does my message need the receiver's attention within their next turn cycle?*
-- **Yes → push** via `rig send` (lands in chat; receiver processes on next turn)
-- **No → pull** via queue-write (write to own queue OR receiver's queue via handoff; receiver sweeps at cadence)
-
-### Push (rig-send to chat) when:
-
-- Receiver needs info NOW to unblock their work
-- Question requires specific answer to proceed
-- Handoff is past ack-threshold + tier=human-gate (mandatory-ack window)
-- Blocker surfacing (can't self-unblock; need help from target)
-- human-gate item needing surface to advisor-pod
-- Destructive or time-critical coordination
-
-### Pull (queue-write only) when:
-
-- Status update / adoption signal / cascade-complete ack
-- Non-urgent ack (within tier threshold)
-- Information that can batch in receiver's curator sweep
-- Broadcast-receipt confirmation (receiver's cadence catches it)
-- Observed patterns or captures with no time pressure
-- Resync material for HA peers (they sweep on resume-from-idle)
-
-### Why this matters
-
-Push-as-default floods the receiver's chat pane with status that could be pulled. Today's rollout volume proved this: during attention-queue + EMM cascades, most acks arrived as push (rig-sends) when they could have been pull (queue-writes). Receiver (advisor-pod) had to process each ping; most were status signals needing no action.
-
-Pull-over-push is the queue primitive's whole point. Status lives in queue files; readers sweep at cadence; only genuine unblockers + gate-surfaces push to chat.
-
-### Worked example
-
-orch-lead@your-rig ack'd attention-queue cascade:
-- **Push version (what happened):** `rig send advisor-peer-observer@your-rig "[queue-handoff-ack: ...] ... cascaded to 8 pod members ..."` → lands in my chat; I read immediately; process the status
-- **Pull version (what should happen):** write ack-receipt to `rigs/openrig-build/state/orch/lead.queue.md` as state-transition on their adoption entry; I sweep their queue on my curator cadence; pick up the ack without chat-ping
-
-Ack-receipts for status are pull-native. Handoff-complete notifications for human-gate items stay push (they close feedback loops on time-sensitive work).
-
-### Corollary — orchestrator-to-advisor cadence
-
-Orchestrators writing to their own queue files lets advisor-pod read without being interrupted. The curator-sweep pattern (advisor reads pod queues on their cadence) is the canonical pull mechanism. Push only when time-matters.
-
-## Anti-patterns (don't do these)
-
-- **Chat-as-status** — narrating status/gates to your chat pane + idle-waiting. Use queue + human-attention instead.
-- **Duplicate-storage** — writing the same fact in queue + session-log + chat + mission-control. Queue is authoritative for in-flight state.
-- **Peer-injection** — writing directly to another agent's queue without their authorship. Only handoff op moves work cross-queue.
-- **Silent drops** — don't leave items in pending forever without state transitions. defer or drop with rationale.
-- **Global queue** — don't try to make one queue for everyone. Per-agent primary; compose for views.
-
-## Maturity status
-
-**L4-insight** per skill-maturity-convention. Applied liberally across the host; evolving via observation. Feedback loop: RSI filings reshape this skill; demotion valid if convention reveals wrong shape; promotion to L5-canon requires architect+reviewer pair-review per HOST-TOPOLOGY §7 SOP.
-
-Rollout date: 2026-04-13 host-wide adoption. 48h observation cycle active; RSI with learnings due ~2026-04-15.
-
-## Related
-
-- Spec (full reference): the internal attention-queue spec
-- Skill-maturity convention: `substrate/shared-docs/skill-maturity-convention.md`
-- Config-wrapper-code loop doctrine: `config-wrapper-code-loop` skill
-- HOST-TOPOLOGY §4 context-sharing patterns — attention queue is a new pattern here
-- SUBSTRATE-CONVENTIONS §7 HA session logs — queue lives in same per-pod directory

package/daemon/context-packs/skills/core/attention-queue/manifest.yaml

@@ -1,9 +0,0 @@
-# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
-# Package-time projection of a canonical skill; regenerated every build.
-name: "attention-queue"
-version: "0.5.5"
-purpose: "Coordination primitive for OpenRig. Per-agent queue files tracking in-flight work with explicit state transitions + handoff semantics + cross-agent composition. Prevents memory-loss drops; surfaces stalls mechanically; closes the feedback loop on handed-off work. Applied liberally by every agent on every kernel-supervised rig; composed views serve human attention, orch pod-load, rig pending-work."
-files:
-  - path: "SKILL.md"
-    role: "instruction"
-    summary: "Coordination primitive for OpenRig. Per-agent queue files tracking in-flight work with explicit state transitions + handoff semantics + cross-agent composition. Prevents memory-loss drops; surfaces stalls mechanically; closes the feedback loop on handed-off work. Applied liberally by every agent on every kernel-supervised rig; composed views serve human attention, orch pod-load, rig pending-work."