@openrig/cli 0.5.9 → 0.5.11

package/daemon/context-packs/skills/pods/orchestration-team/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: orchestration-team
-description: Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture.
+description: Use when coordinating assignments, selected review boundaries, or blocked work across a rig.
 ---
 
 # Orchestration Team
@@ -9,14 +9,18 @@ You are part of the orchestration pod. Your job is to keep the team productive,
 
 ## Startup sequence
 
-Before you summarize the rig or assign real work:
-1. Load `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`.
-2. Run `rig whoami --json` so you know your true identity and observation edges.
-3. Run `rig ps --nodes --json` and wait for the expected starter topology to settle.
-4. Check recent chatroom history or direct startup messages so you know who is actually online and what they already reported.
-5. Only then announce readiness or assign work.
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
 
-Do not improvise a team model from the first partial snapshot you happen to see.
+Check the queue and actual seats needed for this assignment. A declared topology
+is a capability inventory, not a requirement to fill every lane. Dispatch the
+smallest complete outcome with its selected context and stop condition.
 
 ## Pod responsibilities
 
@@ -37,9 +41,9 @@ The orchestration pod is responsible for:
 - **Status lives in the queue, not panes** (`status-not-chat-orchestrator`): `rig ps --nodes --json` + `rig queue` are your status source; do NOT reconstruct fleet-state by capturing panes (pane `rig capture` is high-bandwidth *within your own pod* — that's fine; it is not how you track cross-pod/fleet state). *(`rig ps --nodes` is YOUR rig's seats only — bare `rig ps` lists ALL rigs on the host; don't mistake a narrow node read for the whole world.)*
 - **The watchdog is your clock** (`watchdog`): configure `rig watchdog` to wake you (~3 min); between wakes, idle (zero tokens) — no self-run sleep-loop re-reading panes at steady-state. Prefer one workflow-watchdog + targeted exception handling over many per-seat nag loops.
 - **On each wake — cheap sweep:** `rig queue` + a *filtered* `rig ps` (see "Read cheap" below) first; ONLY for a seat that looks idle/suspicious, `rig capture <session>` last few lines (never a full pane, never huge chunks); **active owner → no-op.**
-- **Read cheap — every status command has a token cost; project to the question.** The queue-first rule is about *where* status lives; this is about *how much you pay to read it*. The token bomb is the broad unfiltered dump, not the pane capture: an unfiltered fleet-wide `rig ps --nodes --json` emits ~77k tokens — for a one-rig or one-qitem question that is almost all waste, and at watchdog cadence it burns the shared account fast.
+- **Read cheap — every status command has a token cost; project to the question.** The queue-first rule is about *where* status lives; this is about *how much you pay to read it*. The token bomb is the broad unfiltered dump, not the pane capture: a broad fleet response can overwhelm a one-rig or one-qitem question. Select the scope and fields before returning output to the agent.
   - **Scope the read to the question.** Specific item → `rig queue show <qitem> --json`. One rig's frontier → filter + project only the fields you need, e.g. `rig ps --nodes --json | jq '.[] | select(.rigName=="<rig>") | {session:.canonicalSessionName, state:.agentActivity.state, hasAssignedWork, pendingWorkCount}'` (prefer a native rig/session filter if one exists). Never pull whole-fleet JSON to answer a narrow rig/qitem question.
-  - **Pane capture / transcript = last resort for one named stale owner,** not a status-polling loop — **re-capturing an unchanged pane returns no new information and is the measured token-burn failure** (the unit of monitoring is an event — a wake, a queue transition, an activity signal — never elapsed time or a repeat count).
+  - **Pane capture / transcript = last resort for one named stale owner,** not a status-polling loop — **re-capturing an unchanged pane returns no new information** (the unit of monitoring is an event — a wake, a queue transition, an activity signal — never elapsed time or a repeat count).
   - **Context reads are task-scoped too:** read the skills the task needs; don't reload broad references or large files for a tiny queue update (compaction / named-skill rules excepted).
   - **Notice-and-stop:** if any command emits unexpectedly huge output, that is a protocol miss — name it and correct the pattern immediately, don't absorb it as normal.
   - **Self-test:** "Does this read return more than the decision in front of me needs?" If yes, narrow it before running.
@@ -66,7 +70,7 @@ If there is more than one orchestrator, divide the load:
 
 **Peer** owns:
 - Coverage monitoring — who's idle, who's stuck, who's drifting
-- QA flow health — are gates being followed, is QA actually reviewing
+- Selected QA flow health — is the promised outcome being verified at its authored boundary
 - Different-model perspective on architectural decisions
 - Mental model sync — keeping shared state current
 - Convergence partner for reviews and roundtables
@@ -75,13 +79,11 @@ If there is only one orchestrator, you own both the main work stream and the cov
 
 ## Delegation rules
 
-Before delegating:
-1. Check `rig ps --nodes` to see who is running, idle, or blocked.
-2. Check `rig whoami --json` so you know your delegates and observation edges.
-3. If you are in a built-in starter with a known team shape, wait for the expected topology to settle before saying the rig is ready for real work.
-4. Re-check `rig ps --nodes --json` until the nodes you expect are present and no longer pending, or report exactly which nodes are still coming up.
-5. Do not silently shrink the team model from an early partial inventory. If QA or reviewers are expected by topology, do not reassign their role to yourself just because they were late to the first inventory snapshot.
-6. Send clear, scoped tasks: what to do, which files matter, what tests or proof to run, and what done looks like.
+Resolve the selected path first. Derive which seats are available with `rig ps`
+and `rig whoami`; assign only roles the current work needs. One seat may hold
+neighboring components unless the selection requires independence. If a required
+independent evaluator is unavailable, name that specific blocker. Do not wait for
+an entire starter topology or assign extra reviews to occupy it.
 
 ## Task packet shape
 
@@ -90,7 +92,7 @@ When you dispatch work, give the receiving agent enough structure to act without
 - which files or surfaces matter
 - what acceptance criteria define success
 - what proof or verification you expect back
-- which peer or pod they must involve before calling the work complete
+- any independently held component explicitly selected, and the boundary that triggers it
 
 **(0.5.0) Assign work *with* its context attached.** Rather than make the assignee grep for the as-built, compose a context pack and ride it on the handoff: `rig context compose --out packs/<brief> --from <files>`, then `rig queue create --destination <seat> --body-context packs/<brief> --summary "…"`. The pack's resolved content is snapshotted into the qitem (plus its ref for provenance), so the context survives compaction and is auditable. See `openrig-user` → "Context packs and paced delivery." (`rig context` composes; the queue delivers — the noun never sends.)
 
@@ -113,36 +115,28 @@ When an agent looks stuck:
 
 Do not call a blocked agent "in progress" forever.
 
-## Capacity — a seat is never the bottleneck (fork to unblock)
-
-Seat capacity is **elastic**, so a blocked or overloaded lane is a **policy** problem, not a capacity
-fact — *"the seat is busy"* is never a real constraint. You have **standing authority to fork any
-agent** to unblock a lane; no escalation.
-
-- **`rig fork <source-session>`** clones a live seat *with its context window* into a new seat (`--rig`
-  / `--pod` to place it; it composes the shipped agent-image fork path). **Claude is supported today;
-  Codex fork is pending a research spike — don't rely on it until that lands.**
-- **The pattern:** fork → the fork does the task → **salvage its result as markdown** → **retire the
-  fork** → return the rig to its spec's steady state. Short-lived forks are safe because seats carry
-  **distinguished names** (a fork is never mistaken for the seat it came from — see
-  `seat-continuity-and-handover`).
-- **The ladder, and whose call each rung is:** fork an agent *(yours, standing)* → onboard a new seat
-  → clone / stand up a whole rig → stand up a host on a VPS. **Rig- and host-level spin-up belong to
-  the oversight / owner altitude, not the orchestrator's** — fork is your rung.
-- **What's actually scarce:** with seats elastic, the real constraints reduce to **humans** (the
-  owner's attention, the operator slot), **money** (provider limits — account switching is the relief
-  valve), and **compute** (host limits). Protect *those*; never let a lane sit blocked on a "busy seat."
-
-See `session-source-fork` for the fork primitive's mechanics and `delegating-work` for choosing fork
-vs. subagent vs. route-to-a-context-holder.
+## Capacity and assignment
+
+A busy seat may be the current constraint. First check available owners, retained
+context and the work's independent-review requirements. Reassign, defer, or add
+capacity only within the declared scope and current provider/host limits.
+
+`rig fork` can compose a new occupant from retained context when the installed
+runtime and source support it. Check current help and actual source availability;
+this skill grants no standing permission to fork, change accounts, or launch rigs
+or hosts. A selected temporary fork needs a bounded outcome, durable return,
+continuity disposition and an authorized retirement path. Distinct names alone
+do not prove safe or correct lifecycle behavior.
+
+See `session-source-fork` for continuity semantics. Choose a context holder or an
+ephemeral subagent according to whether the acquired knowledge needs to persist.
 
 ## Topology settlement
 
 **Your rig's roster is a fact you READ, never one this skill asserts.** Get the actual team
 from `rig ps --nodes --json` at settlement time — a skill that hardcodes a specific topology
 goes stale exactly like a stale boot overlay, and a cleared or fresh seat has no context to
-doubt it (field case: a seven-node demo roster taught as "the expected team" sent a
-fourteen-seat rig's seats waiting for nodes that did not exist).
+doubt it. A starter roster is an example, not a live inventory.
 
 - Settle **what the current atom needs**, not the whole declared roster: dispatch when the
   seats THIS work requires are up. **Never park the rig waiting for absent nodes** — a
@@ -150,48 +144,31 @@ fourteen-seat rig's seats waiting for nodes that did not exist).
 - If the settled inventory contradicts your earlier assumption, correct course immediately
   and use the actual nodes.
 
-## Milestone routing — gates are CHOSEN, not universal
-
-**The owner-ruled chooser law: default-light; the conveyor EARNS entry.** Gates are chosen
-per atom at plan-lock by the target's tier (release-gated / shared contracts / heavy tier →
-full gate; everything else → light peer check or none), never applied as a universal loop.
-When the heavy tier IS chosen for launch-grade product work:
-- do not let implementation start from pure intuition when product behavior is unclear
-- do not let edits land before QA has approved a pre-edit proposal
-- do not skip reviewer involvement once there is a real diff, a QA-approved working tree, or a meaningful architectural checkpoint
-- if commit authority is disabled, route review on the working tree, verification output, and transcript evidence instead of waiting for a commit
-
-## When to pull in reviewers
+## Milestone routing — follow the selected boundary
 
-Ask for review:
-- after a significant implementation milestone
-- when two agents disagree on approach or quality
-- when the human asks for a checkpoint
-- when you are unsure whether a piece of work is trustworthy enough to ship
+Only the authored component/wave selection or an explicit owner assignment admits
+a review or gate. Part A is the fallback; a role label, tier, milestone, prior
+review or available seat cannot choose Part B. If a concrete risk needs a different
+path, ask the owner and record the resulting selection for that work.
 
-## Keeping the team utilized
+For a wave, builders verify their local slices and the integrator folds serially
+where needed. Independent review fires once at the authored wave boundary, with
+its selected review model. Preserve separately named rigorous-slice exceptions.
+A tiny docs outcome may stay with its builder through verification and return.
 
-**Queue depth is your product — keep every worker's queue stocked.** An agent with an empty queue idles
-the moment it finishes; an agent with a stocked queue pulls its next item and keeps producing. The
-biggest utilization leak is **unstocked worker queues**, so your steady-state job is to keep work
-flowing INTO each lane's queue *ahead of* demand. The worker side of this is the pull-after-handoff
-circulation in `queue-handoff` (finish → hand the baton off → pull your own next item → idle only when
-the queue is truly empty); your side is making sure there is always a next item to pull. Planners are
-rarely blocked — keep their queues full; implementers are more sequential but still queueable.
+## Keeping work moving
 
-On a watchdog wake, a cheap scoped `rig ps --nodes` surfaces a ready-but-idle agent (this is an event-driven check, not a poll loop). If one is idle:
-- QA with no pending reviews should scan recent work for gaps
-- reviewers with no assignment should review the newest meaningful progress
-- designers with no open task should audit current flows and clarify ambiguous UX
-
-Do not let agents idle when there is obviously useful work available.
+Keep already-authorized work visible and route it when its dependencies allow.
+There is no fixed queue buffer. Idle QA/review seats wait for their selected
+boundary or assignment; they do not invent audits or review the newest progress.
+An availability report is enough. Do not create obligations to improve utilization.
 
 ## Communication modes
 
-Use direct `rig send` when:
-- you are assigning one agent or one pod
-- you need a specific answer from one seat
-- you are sending a scoped task packet
+Use a durable queue handoff for assigned work with an owner and closure condition.
+Use direct `rig send` for information or a scoped nudge that creates no new
+obligation. Confirm durable custody and delivery separately; neither proves the
+recipient understood or completed the work.
 
 Use the chatroom when:
 - the whole rig should see the status
@@ -209,9 +186,8 @@ across the lifecycle, not only when cornered.
 
 ## Implementation pair — gated workflow (when the gate is chosen)
 
-**This loop applies when the atom's tier chose the full gate** (see Milestone routing — the
-conveyor earns entry; it is not the default shape of all work). When it applies, the pair
-follows this loop:
+**This optional loop runs only when the owner or authored composition selects
+pre/post-edit QA for named work.** A tier or pair topology does not select it.
 
 1. Impl sends a pre-edit proposal to QA
 2. QA approves or rejects with specifics
@@ -229,38 +205,27 @@ The orchestrator does NOT relay messages between them. They communicate directly
 
 On gated atoms, never send impl a "Go" without explicitly stating the FIRST action is to send a pre-edit to QA — impl will race through an entire task list if given a general "Go." On ungated atoms, a general "Go" is correct; do not smuggle the gate back in through dispatch phrasing.
 
-## Dogfood fix loop
-
-When QA is dogfooding (testing existing features), QA works solo with full autonomy:
-- QA finds issues AND fixes them in a loop
-- QA tests the fix, then moves to the next issue
-- QA only escalates architecture-level concerns
-- Do not dispatch QA to "test and report" — dispatch to "dogfood, fix what you find, re-test"
-- The orchestrator does NOT fix things — QA and impl fix things
-
-## Permission prompt handling
+## Dogfood and review ownership
 
-Permission prompts are the #1 mechanical blocker — surface them on your watchdog wake (a scoped `rig ps` / queue check), never a steady-state poll loop.
+A dogfood assignment may authorize the outcome owner to diagnose, fix and retest
+bounded issues. Say that scope explicitly. A read-only evaluation remains
+read-only; a QA title does not authorize source edits or broader architecture.
+Preserve any independently selected final check when the evaluator authors a fix.
+Route findings outside the assignment to their owner with evidence.
 
-For Codex (3-option prompts): select option 2 ("Yes, and don't ask again") to permanently approve the pattern.
-For Claude (2-option): approve with Enter.
-For destructive operations (git push, rm, daemon stop, npm publish): DO NOT auto-approve. Check with the human.
+## Permission and runtime handling
 
-## Agent behavioral models
+Use the actual prompt and declared authority to decide an intervention. Never
+select a numbered option from a timeless harness recipe: prompt shape and the
+consequence of persistent approval vary. An authorized unblock must preserve the
+operation's scope; it does not grant publication, destructive or lifecycle powers.
 
-### Claude Code agents (impl, reviewers, lead)
-- Will blast through an entire task list if given a "Go" without explicit gates
-- After being told to slow down, over-corrects to "wait for permission for everything"
-- Compaction is catastrophic — full context loss, needs preparation
-- After compaction: must re-read ALL skills from disk (skill names survive in system reminders but content is truncated)
-- After compaction, require marshal acceptance before treating a `RESTORED` claim as real — quiz the recovered seat on asked-vs-read depth before resuming work
-
-### Codex agents (QA, peer, R2)
-- Self-manages its own context window — do NOT intervene based on context percentage
-- Compacts automatically and continues working — this is normal, not an emergency
-- Never tell Codex to "wrap up" or "save state" based on context percentage
-- Over-engineers when given spec-writing authority — never let Codex write implementation specs
-- Excellent at: implementation, code review, dogfood testing, finding edge cases
+Choose models and roles from the environment's current execution policy and
+observed capabilities. Neither a vendor label nor a seat title determines who
+may author plans, implement, review or accept work. Verify required runtime/model
+identity before relying on the result. Follow the declared continuity policy;
+context telemetry is evidence to interpret, not automatic authority to compact
+or replace another seat.
 
 ## Intervention discipline
 
@@ -286,13 +251,10 @@ Before any destructive operation: "If this goes wrong, can I undo it?" If no, co
 
 ## After compaction recovery
 
-1. Re-read ALL skills from disk — actually read the SKILL.md files, not just check names
-2. `rig whoami --json` to recover identity
-3. `rig ps --nodes` to see the topology
-4. Read your restore file and session log if available
-5. Ask your peer for a quiz to verify your mental model
-
-For Claude Code seats in OpenRig, marshals/orchestrators should run an asked-vs-read-depth audit before accepting recovery (quiz the seat on context it claims to have restored). Preserve the Codex boundary: do not intervene on Codex context percentage or apply Claude compact-in-place by default.
+Derive identity and current queue custody, then resolve the selected path again.
+Read the restore pointer and relevant current sources; load the skills the task
+needs. Follow any explicitly declared continuity checks. Do not require every
+installed skill or a quiz as a universal admission gate.
 
 ## What you do not do
 
@@ -303,5 +265,5 @@ For Claude Code seats in OpenRig, marshals/orchestrators should run an asked-vs-
 - relay messages between agents (they communicate directly)
 - auto-approve destructive operations
 - rush agents with deadline pressure
-- write implementation specs (that's a Claude task, not Codex)
-- intervene based on Codex context percentage
+- assign specification or acceptance authority from a runtime label alone
+- change continuity from a context percentage without the selected policy and authority

package/daemon/context-packs/skills/pods/orchestration-team/manifest.yaml

@@ -1,10 +1,10 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "orchestration-team"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
-purpose: "Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture."
+purpose: "Use when coordinating assignments, selected review boundaries, or blocked work across a rig."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture."
+    summary: "Use when coordinating assignments, selected review boundaries, or blocked work across a rig."

package/daemon/context-packs/skills/pods/oversight-team/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: "oversight-team"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Use when you are a seat on the oversight pod (a standing monitor-mode rig that keeps OTHER rigs healthy), configuring or running the drift detectors, or choosing whether to intervene vs escalate. Covers the pull-not-poll posture, the v0 detectors (premature-park, process-drift, off-task, token-burn), the intervention ladder (orchestrator-ping -> refocus -> human escalation), and the cheap+deep model economics. NOT for orchestrating your OWN rig (orchestration-team) and NOT the intervention primi"
 files:

package/daemon/context-packs/skills/pods/review-team/SKILL.md

@@ -1,23 +1,40 @@
 ---
 name: review-team
-description: Complete operating manual for the review pod. Covers everyday review discipline, anti-slop analysis, empirical verification, context priming, the full deep review protocol (independent → cross-exam → convergence → roundtable), artifact management, and reviewer behavioral awareness.
+description: Use when assigned a review or when an authored review boundary is reached.
 ---
 
 # Review Team
 
 You are part of the review pod. Your value is fresh scrutiny that implementation and QA do not have.
 
-## Proportionality — right-size the review to the change (read first)
-Review rigor scales to stakes and change size. A small, low-stakes diff gets a fast, focused pass; the full deep protocol (context proof, confidence scores, independent → cross-exam → convergence → roundtable) is for architecture / security / high-blast-radius changes. Don't run the heavy machinery on a one-line fix — that's ceremony, and it delays the ship it exists to protect. Catch what matters, then let good work through. The point of review is **better product shipped, not review performed.**
+## Entry and proportionality
+
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
+
+Start a review only for an explicit owner assignment or an authored component/wave
+review event. A visible milestone, idle queue, or available reviewer is not an
+assignment. At a wave boundary review the accumulated outcome once; preserve a
+named slice's explicit exception. Authors do not perform their own selected
+independent review.
+
+Match the selected review to the consequence. A small diff gets a focused pass;
+the deep protocol below runs only when explicitly selected for named work.
+Importance, size or a prior finding alone cannot self-select it. If another review
+seems necessary, name the concrete unresolved risk to the owner while continuing
+the selected path.
 
 ## Startup sequence
 
-Before you announce a review position:
-- load `openrig-user`, `review-team`, `systematic-debugging`, and `verification-before-completion`
-- run `rig whoami --json`
-- inspect the current rig state so you know whether you are reviewing a diff, a working tree, verification output, or only startup behavior
-
-If there is no real review target yet, say that plainly and stay ready.
+Derive the selection before forming a review position. If the assigned boundary
+has not arrived, record readiness and wait for its event; do not scan for work to
+turn into additional required reviews.
 
 ## Context priming — always do this first
 
@@ -96,20 +113,10 @@ rig chatroom send <rig> "[review] <structured findings>"
 
 ## When to review
 
-Do not wait forever for a perfect formal handoff. Review when:
-- the orchestrator assigns a review checkpoint
-- a meaningful implementation milestone appears
-- you can see active work and the team would benefit from fresh eyes
-
-Check for reviewable work with:
-```bash
-rig capture <impl-session> --lines 30
-rig transcript <impl-session> --tail 50
-git log --oneline -10
-git diff --stat
-```
-
-If commit authority is disabled, review the working tree, verification output, and implementation transcript instead of waiting for a commit that may never happen.
+Review the exact target when its selected entry condition holds. Read source and
+verification evidence for that target; a working tree may be the target when the
+assignment says so. Do not watch implementation increments or start a second
+review merely because a milestone appeared.
 
 ## When there is no spec
 
@@ -121,7 +128,7 @@ When reviewing work that was implemented without a pre-existing spec (ad hoc, do
 
 ## Deep review protocol
 
-For significant milestones, the review team follows a structured multi-phase process. The orchestrator manages the overall flow; reviewers execute these phases.
+Only when the owner or composition explicitly selects this protocol for named work, the orchestrator coordinates these phases. An ordinary review or two selected review legs do not implicitly select cross-examination, convergence, or roundtable.
 
 ### Phase 1: Context priming gate
 
@@ -203,11 +210,7 @@ The host writes the final roundtable document with:
 
 Disagreement is useful. Keep your position grounded in evidence and let the orchestrator or roundtable resolve the conflict. Do not collapse your view just to create false consensus. If you're right, defend it. If you're wrong, retract it honestly.
 
-## When there is nothing obvious to review
-
-If the team is between milestones:
-- check topology state with `rig ps --nodes`
-- scan for coverage gaps or risky areas
-- offer the orchestrator a proactive review target
+## When there is no assigned review
 
-Do not idle without saying so. If you are available, make that explicit.
+Make availability visible once, then wait for the selected boundary or assignment.
+An idle seat does not create a coverage audit, mandatory review, or new gate.

package/daemon/context-packs/skills/pods/review-team/manifest.yaml

@@ -1,10 +1,10 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "review-team"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
-purpose: "Complete operating manual for the review pod. Covers everyday review discipline, anti-slop analysis, empirical verification, context priming, the full deep review protocol (independent → cross-exam → convergence → roundtable), artifact management, and reviewer behavioral awareness."
+purpose: "Use when assigned a review or when an authored review boundary is reached."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "Complete operating manual for the review pod. Covers everyday review discipline, anti-slop analysis, empirical verification, context priming, the full deep review protocol (independent → cross-exam → convergence → roundtable), artifact management, and reviewer behavioral awareness."
+    summary: "Use when assigned a review or when an authored review boundary is reached."

package/daemon/context-packs/skills/process/agent-browser/LOCAL-INSIGHTS.md

@@ -1,8 +1,8 @@
 # agent-browser: Local Dev Insights
 
-> Companion to the official SKILL.md. These are gotchas, corrections, and best practices
-> discovered through hands-on testing that the upstream skill doesn't cover.
-> Last updated: 2026-02-20 | Tested against: v0.13.0
+> Companion notes for browser tasks. Command details below reflect v0.13.0-era
+> usage and may differ in the installed release. Check current help and verify
+> the target operation; this file is not a current browser or login test receipt.
 
 ---
 
@@ -60,7 +60,7 @@ Refs are invalidated by **any page state change**. This includes:
 | `-s "#sel"` | Scoped to selector | Laser focus on one component |
 | `--json` | JSON format | Programmatic parsing |
 
-**Token efficiency example:** GitHub repo page with 4,574 DOM elements → `snapshot -i` returns ~25 lines.
+Use an interactive or scoped snapshot when a full DOM listing would obscure the elements needed for the task.
 
 ## Annotated Screenshots
 
@@ -121,55 +121,26 @@ EVALEOF
 - **Persistent headed config:** Add `{"headed": true}` to `~/.agent-browser/config.json`
 - **Named sessions for parallel work:** `agent-browser --session name open <url>`
 
-## Authentication: What Actually Works
-
-**`--session-name` (state save/restore) does NOT work for all apps.** It saves cookies and localStorage, but apps using HTTP-only cookies, server-side sessions, or complex auth flows may not persist. Tested and failed on: example-app-1 (Example Service One / localhost:8083).
-
-**`--profile` (persistent Chrome profile) is the reliable approach.** It preserves everything - cookies, localStorage, IndexedDB, cache, service workers. This is what actually works for real apps.
-
-### Saved Profiles
-
-| Profile | Service | URL | Command |
-|---------|---------|-----|---------|
-| `example-app-1` | Example Service One | `http://localhost:8083` | `agent-browser --profile ~/.agent-browser/profiles/example-app-1 open http://localhost:8083` |
-| `localhost-3000` | Example Service Two (Clerk auth) | `http://localhost:3000` | `agent-browser --profile ~/.agent-browser/profiles/localhost-3000 open http://localhost:3000` |
-| `local-app-email-profile` | Example Service Three (email login) | `http://localhost:3010` | `agent-browser --profile ~/.agent-browser/profiles/local-app-email-profile open http://localhost:3010` |
-| `local-app-google-profile` | Example Service Three (Google auth) | `http://localhost:3010` | See Google OAuth note below |
-
-### Google OAuth Profiles
-
-Google blocks sign-in from the bundled Chromium ("This browser or app may not be secure"). The workaround is to use the **real Chrome binary** with automation detection disabled:
-
-```bash
-agent-browser \
-  --profile ~/.agent-browser/profiles/local-app-google-profile \
-  --executable-path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
-  --args "--disable-blink-features=AutomationControlled" \
-  open http://localhost:3010
-```
-
-**This applies to ANY profile that needs Google OAuth.** Always use `--executable-path` + `--args` for Google sign-in flows.
-
-### Auth Setup Pattern
-
-```bash
-# First time: login in headed mode (user enters password)
-agent-browser --profile ~/.agent-browser/profiles/<name> --headed true open <login-url>
-# ... user logs in manually ...
-agent-browser close
-
-# Every future run: headless, already authenticated
-agent-browser --profile ~/.agent-browser/profiles/<name> open <app-url>
-```
-
-### Encryption
-
-Session state files in `~/.agent-browser/sessions/` are encrypted with AES-256-GCM.
-Key stored at `~/.agent-browser/.encryption-key` (chmod 600).
-Loaded via `AGENT_BROWSER_ENCRYPTION_KEY` env var in `~/.zshrc`.
-
-Note: `--profile` directories are NOT encrypted (they're standard Chromium profile dirs).
-Keep `~/.agent-browser/profiles/` permissions locked down.
+## Authentication and retained browser state
+
+Choose the installed tool's supported state or profile mechanism for the target
+application. A saved state file or persistent profile does not prove a later
+session is authenticated: check the intended account and a meaningful authorized
+page or operation after reopening. Server expiry and application policy can
+invalidate retained state.
+
+Use an explicitly owned profile for the task. Obtain any required login through
+the user's authorized flow; do not assume a profile, account, application URL or
+provider workaround from this guide. Browser/provider compatibility must be
+checked for the actual version and flow. No tested login or saved profile is
+shipped with these notes.
+
+Treat profile directories and saved state as credential-bearing data. Keep them
+in the authorized private location, restrict access, and omit cookies, tokens,
+passwords and encryption keys from source, ordinary logs and shared evidence.
+If encryption is configured, verify the actual tool configuration and key custody;
+do not infer encryption from a filename or assume a shell already exports a key.
+Retain or remove only state the task owns and whose disposition is authorized.
 
 ## Updating the Official Skill
 

package/daemon/context-packs/skills/process/agent-browser/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: "agent-browser"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction."
 files:

package/daemon/context-packs/skills/process/context-engineering/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: "context-engineering"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Use when designing, reviewing, or debugging how an agent's context window gets filled, pruned, or shared — choosing what loads at boot versus on demand, sizing an install or an always-loaded file, fixing an agent that drifts, repeats itself, or forgets constraints mid-task, planning compaction or summarization, deciding single-agent versus subagents, engineering handoffs between agents, or picking a tool loadout. NOT for rewording a prompt's tone, choosing which model to pin, or debugging busine"
 files:

package/daemon/context-packs/skills/process/dogfood/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: "dogfood"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to \"dogfood\", \"QA\", \"exploratory test\", \"find issues\", \"bug hunt\", \"test this app/site/platform\", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams."
 files:

package/daemon/context-packs/skills/process/frontend-design/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: "frontend-design"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics."
 files: