@openrig/cli 0.5.9 → 0.5.10

package/daemon/specs/agents/shared/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
 
@@ -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.)
 
@@ -150,41 +152,24 @@ 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
+## Milestone routing — follow the selected boundary
 
-**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
+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.
 
-## When to pull in reviewers
+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.
 
-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
+## Keeping work moving
 
-## Keeping the team utilized
-
-**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.
-
-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
 
@@ -209,9 +194,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
@@ -252,8 +236,7 @@ For destructive operations (git push, rm, daemon stop, npm publish): DO NOT auto
 - 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
+- After compaction: restore the active assignment and its selected context; skill names alone are not restored content. Follow the declared continuity policy without adding a universal quiz gate.
 
 ### Codex agents (QA, peer, R2)
 - Self-manages its own context window — do NOT intervene based on context percentage
@@ -286,13 +269,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
 

package/daemon/specs/agents/shared/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/specs/agents/shared/skills/process/test-driven-development/SKILL.md

@@ -33,14 +33,12 @@ Write the test first. Watch it fail. Write minimal code to pass.
 
 Thinking "skip TDD just this once"? Stop. That's rationalization.
 
-**Chunk size is a dial, and it points up (2026-08) — this is NOT "skip TDD".** *How much* you build per
-red-green cycle is configurable, and with frontier agents handling hour-plus goal-oriented work it is
-**much larger than the classic tiny ping-pong**, and rising. Keep everything below — the Iron Law, red
-before green, two sets of eyes, the guard structure — **fully intact**; only the *cadence / granularity*
-loosens. You still write the failing test(s) first for the chunk; the chunk is simply bigger. Tiny
-back-and-forth is overhead, not virtue, once the SDLC's gates (QA, review, guards) bound a larger chunk's
-risk. Match the chunk to the task; treat it as a configured lever — never as license to write code before
-its test (that's the rationalization this skill exists to stop).
+**Chunk size follows the outcome.** Keep red → green → refactor for the behavior
+being changed and build a coherent chunk. TDD does not require two people,
+pre-edit permission or a guard: independence and review cadence come from the
+project/mission/slice component or wave selection. An explicitly selected gate
+still applies; an unselected role cannot add one.
+
 
 ## The Iron Law
 

package/daemon/specs/rigs/launch/demo/CULTURE.md

@@ -2,36 +2,27 @@
 
 This is the stable launch-grade version of the full product squad. Right now it uses the same core topology as `product-team`: two orchestrators, a development pod with implementation, QA, and design, plus two reviewers.
 
-## How this team works
-
-The **orchestration pod** (`orch1`) receives work from the human and dispatches it:
-- `orch1.lead` owns the main work stream and milestone decisions
-- `orch1.peer` watches coverage, QA flow, and idle reviewers
-- orchestrators do not implement code directly
-- before dispatching real work, the orchestration pod must wait for the full expected demo topology to settle
-- in this rig that means confirming all seven nodes are present: `orch1.lead`, `orch1.peer`, `dev1.design`, `dev1.impl`, `dev1.qa`, `rev1.r1`, `rev1.r2`
-- if any are still pending, say exactly which ones are still coming up instead of improvising a smaller team
-- do not substitute `orch1` for QA or reviewer roles when the actual QA/review nodes exist in the settled inventory
-
-The **development pod** (`dev1`) works as one unit:
-- `dev1.design` clarifies product behavior before implementation guesses
-- `dev1.impl` writes the change through a gated QA loop
-- `dev1.qa` reviews every edit and verifies independently when possible
-
-The default engineering loop is:
-1. clarify the task and acceptance criteria
-2. `dev1.impl` sends a pre-edit proposal to `dev1.qa`
-3. QA approves or rejects with specifics
-4. implementation happens with TDD
-5. `dev1.impl` sends the diff and verification output back to QA
-6. QA approves or rejects with specifics
-7. if commit authority is enabled, the implementer may commit
-8. if commit authority is not enabled, stop at a QA-approved working tree and report that honestly
-
-The **review pod** (`rev1`) provides independent scrutiny:
-- reviewers inspect milestone work, current diffs, verification output, and transcripts
-- if commit authority is disabled, they still review the work that exists instead of waiting for commits
-- reviewers report findings with evidence and clear severity
+## Work selection
+
+Derive identity with `rig whoami --json`, then follow
+`project.yaml -> mission.yaml -> active slice.yaml -> selected component or wave
+map -> addressed context`. Use
+`docs/reference/product-journey-sdlc.md#resolve-the-selected-path` (installed:
+`$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+No selection means light Part A. Only the selected work's required capabilities
+need to be ready; do not wait for the whole topology or invent work for idle roles.
+
+Orchestration routes outcomes and resolves exceptions. Implementation completes
+coherent changes and verifies by effect. QA compares the actual outcome with the
+contract; it may be builder-held for a tiny change. Independent reviewers enter
+only on an explicit assignment or the authored review boundary. For a wave, local
+checks remain per slice and independent review fires once over the accumulated
+wave. A named rigorous slice retains its selected checks. A topology does not
+select a pre-edit, QA, guard, review or lock gate.
+
+Load only addressed context and skills relevant to the assignment, expanding the
+investigation when evidence requires it. Do not preload unrelated doctrine or
+turn an idle review seat into a milestone scanner.
 
 ## Communication
 

package/daemon/specs/rigs/launch/implementation-pair/rig.yaml

@@ -1,9 +1,9 @@
 version: "0.2"
 name: implementation-pair
 summary: >
-  Fastest first success: a focused dev pair where one implementer writes
-  code following TDD and one QA partner gates every edit. Use this when
-  you want the quickest path to a trustworthy OpenRig workflow.
+  A focused development pair providing implementation and QA capabilities.
+  Project/mission/slice components choose the work and any independent checks;
+  no composition means light Part A, not a per-edit approval loop.
 
 pods:
   - id: dev

package/daemon/specs/rigs/preview/product-team/CULTURE.md

@@ -2,75 +2,27 @@
 
 This is the human-operated product-development starter. It uses a full product-team topology: two orchestrators, a development pod with implementation, QA, and design, plus two reviewers.
 
-## Team shape
-
-**Orchestration pod** (`orch1`):
-- `orch1.lead` — primary orchestrator, dispatches work, makes architectural calls
-- `orch1.peer` — secondary orchestrator, monitors QA and review coverage, handles overflow
-
-**Development pod** (`dev1`):
-- `dev1.impl` — implementer, writes code through the gated QA workflow
-- `dev1.qa` — QA, gates every edit with adversarial review
-- `dev1.design` — product designer, translates intent into concrete UX
-
-**Review pod** (`rev1`):
-- `rev1.r1` — independent reviewer, proactive analysis
-- `rev1.r2` — independent reviewer, different perspective
-
-## Orchestrator division of labor
-
-`orch1.lead` owns the main work stream:
-- Receives tasks from the human
-- Dispatches implementation to `dev1.impl`
-- Dispatches design questions to `dev1.design`
-- Calls reviews from `rev1.r1` at milestones
-
-`orch1.peer` owns QA and review coverage:
-- Monitors `dev1.qa` for stuck reviews
-- Dispatches `rev1.r2` when the review load justifies it
-- Escalates to `orch1.lead` when QA and implementation are misaligned
-
-Neither orchestrator implements code directly.
-
-Before either orchestrator dispatches real work, the team topology must settle.
-For the current full product-team shape that means confirming all seven nodes are present:
-- `orch1.lead`
-- `orch1.peer`
-- `dev1.design`
-- `dev1.impl`
-- `dev1.qa`
-- `rev1.r1`
-- `rev1.r2`
-
-If any are still pending, say exactly which nodes are still coming up instead of improvising a smaller team. Do not substitute `orch1` for QA or reviewer roles when the settled inventory contains the real QA/review nodes.
-
-## Implementation workflow
-
-`dev1.impl` follows a strict gated loop:
-1. Pre-edit proposal → send to `dev1.qa`
-2. Wait for QA approval
-3. Implement with TDD (red → green → refactor)
-4. Post-edit review → send to `dev1.qa`
-5. Wait for QA approval
-6. If commit authority is enabled, commit
-7. If commit authority is not enabled, stop at a QA-approved working tree and report that honestly
-
-`dev1.qa` should not rubber-stamp. If the diff doesn't match the approved scope, reject it.
-
-## Review workflow
-
-Reviewers do not wait to be asked. When meaningful work exists:
-- `rev1.r1` proactively inspects the current range or working tree state
-- `rev1.r2` provides a second independent perspective when dispatched by `orch1.peer`
-- Both write structured findings with severity, file:line references, and evidence
-- Reviewers disagree with each other when the evidence supports it
-
-If no work is pending for review, reviewers should:
-- Check `rig ps --nodes` for work they haven't seen
-- Run `rig capture dev1-impl@<rig>` to see what implementation is doing
-- Ask the orchestrator for review assignments via `rig send`
-
-Do not idle. If the team is obviously producing work, review it.
+## Work selection
+
+Derive identity with `rig whoami --json`, then follow
+`project.yaml -> mission.yaml -> active slice.yaml -> selected component or wave
+map -> addressed context`. Use
+`docs/reference/product-journey-sdlc.md#resolve-the-selected-path` (installed:
+`$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+No selection means light Part A. Only the selected work's required capabilities
+need to be ready; do not wait for the whole topology or invent work for idle roles.
+
+Orchestration routes outcomes and resolves exceptions. Implementation completes
+coherent changes and verifies by effect. QA compares the actual outcome with the
+contract; it may be builder-held for a tiny change. Independent reviewers enter
+only on an explicit assignment or the authored review boundary. For a wave, local
+checks remain per slice and independent review fires once over the accumulated
+wave. A named rigorous slice retains its selected checks. A topology does not
+select a pre-edit, QA, guard, review or lock gate.
+
+Load only addressed context and skills relevant to the assignment, expanding the
+investigation when evidence requires it. Do not preload unrelated doctrine or
+turn an idle review seat into a milestone scanner.
 
 ## Design workflow
 
@@ -136,6 +88,9 @@ Follow patterns agents already know: docker, git, kubectl, npm.
 
 This is the advanced product-team lane. Use it when the work needs richer coordination than the conveyor starter. The human sets direction; the team plans, implements, reviews, and surfaces gaps honestly.
 
-## Mission/slice tracking (the SDLC)
+## Mission/slice tracking
 
-Work is tracked as missions and slices — on-disk markdown the Living Notes UI projects. Load the packaged `mission-slice-sop` skill before authoring or building a slice; the conventions (section names, proof contract, the two locks, C1 proof headers) live in `docs/reference/sdlc-conventions.md` (installed: `$OPENRIG_HOME/reference/sdlc-conventions.md`; shipped with the CLI package). The short form: record intent → author mini-requirements + a proof contract (→ mockups for UI slices) → plan-lock (`rig scope slice approve --scope spec`) → build the locked set → QA visually compares planned vs delivered → `rig proof add … --evidences --media` drops (the C1 drop verb — never hand-place evidence) → proof-lock (`--scope delivery`). `rig scope audit` is the advisory backstop — fix the flag, don't suppress it.
+Use `mission-slice-sop` for the active work's artifact and handoff conventions.
+The selected components or wave determine checks and independence; locks and
+Part B proof ceremony apply only when explicitly assigned. The scope audit is
+advisory, not a permission gate.

package/dist/build-info.js

@@ -1,9 +1,9 @@
 // GENERATED by scripts/build-package.sh — the packaged build-identity stamp.
 export const BUILD_INFO = {
-  semver: "0.5.9",
-  commit: "dbf05f9d59ef3b0ae14fc00174c643df4858d45a",
+  semver: "0.5.10",
+  commit: "b4c833c646f8e49ae47cbee7b0e941be7b49f160",
   dirty: false,
-  builtAt: "2026-09-05T02:09:38Z",
+  builtAt: "2026-09-06T18:25:23Z",
 };
 export function stampFields(info = BUILD_INFO) {
   if (!info.commit) return {};

package/dist/commands/config.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"config.d.ts","sourceRoot":"","sources":["../../src/commands/config.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAsBpC,wBAAgB,aAAa,CAC3B,UAAU,CAAC,EAAE,MAAM,EACnB,IAAI,CAAC,EAAE;IACL,mFAAmF;IACnF,kBAAkB,CAAC,EAAE,MAAM,OAAO,CAAC,OAAO,CAAC,CAAC;CAC7C,GACA,OAAO,CAsKT"}
+{"version":3,"file":"config.d.ts","sourceRoot":"","sources":["../../src/commands/config.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAsBpC,wBAAgB,aAAa,CAC3B,UAAU,CAAC,EAAE,MAAM,EACnB,IAAI,CAAC,EAAE;IACL,mFAAmF;IACnF,kBAAkB,CAAC,EAAE,MAAM,OAAO,CAAC,OAAO,CAAC,CAAC;CAC7C,GACA,OAAO,CAuKT"}

package/dist/commands/config.js

@@ -62,6 +62,7 @@ Keys:
   context.system_world   default System World, replacement manifest path, or disabled
   skills.root            versioned skill catalog (default $OPENRIG_HOME/skills)
   onboarding.default_pack.enabled  deliver the two-part fresh-seat mental-model pack (default on)
+  health.context_pressure.*        context-pressure warning/critical percentages (defaults 95/99)
   files.allowlist        name:/abs/path,name:/abs/path
   progress.scan_roots    name:/abs/path,name:/abs/path
   ui.preview.*           refresh_interval_seconds, max_pins, default_lines

package/dist/commands/config.js.map

@@ -1 +1 @@
-{"version":3,"file":"config.js","sourceRoot":"","sources":["../../src/commands/config.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AACpC,OAAO,EAAE,WAAW,EAAE,UAAU,EAAuC,MAAM,oBAAoB,CAAC;AAClG,OAAO,EAAE,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAElE,SAAS,SAAS,CAAC,GAAW,EAAE,KAAc;IAC5C,OAAO,GAAG,GAAG,CAAC,MAAM,CAAC,EAAE,CAAC,IAAI,KAAK,EAAE,CAAC;AACtC,CAAC;AAED,SAAS,iBAAiB,CAAC,KAAkB;IAC3C,OAAO,KAAK,CAAC,oBAAoB,EAAE,CAAC;AACtC,CAAC;AAED,qFAAqF;AACrF,qFAAqF;AACrF,8BAA8B;AAC9B,MAAM,cAAc,GAAG,CAAC,aAAa,EAAE,aAAa,EAAE,SAAS,CAAC,CAAC;AACjE,MAAM,kBAAkB,GAAG,CAAC,cAAc,CAAC,CAAC;AAE5C,SAAS,aAAa,CAAC,GAAW;IAChC,OAAO,cAAc,CAAC,QAAQ,CAAC,GAAG,CAAC,IAAI,kBAAkB,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,CAAC;AAC3F,CAAC;AAED,MAAM,UAAU,aAAa,CAC3B,UAAmB,EACnB,IAGC;IAED,MAAM,GAAG,GAAG,IAAI,OAAO,CAAC,QAAQ,CAAC,CAAC,WAAW,CAAC,0CAA0C,CAAC,CAAC;IAC1F,MAAM,KAAK,GAAG,IAAI,WAAW,CAAC,UAAU,CAAC,CAAC;IAC1C,MAAM,kBAAkB,GAAG,IAAI,EAAE,kBAAkB,IAAI,CAAC,KAAK,IAAI,EAAE;QACjE,IAAI,CAAC;YACH,MAAM,EAAE,eAAe,EAAE,GAAG,MAAM,MAAM,CAAC,wBAAwB,CAAC,CAAC;YACnE,MAAM,EAAE,QAAQ,EAAE,GAAG,MAAM,MAAM,CAAC,aAAa,CAAC,CAAC;YACjD,MAAM,MAAM,GAAG,MAAM,eAAe,CAAC,QAAQ,EAAE,CAAC,CAAC;YACjD,OAAO,MAAM,CAAC,KAAK,KAAK,SAAS,CAAC;QACpC,CAAC;QAAC,MAAM,CAAC;YACP,OAAO,KAAK,CAAC,CAAC,kDAAkD;QAClE,CAAC;IACH,CAAC,CAAC,CAAC;IAEH,GAAG;SACA,MAAM,CAAC,QAAQ,EAAE,gDAAgD,CAAC;SAClE,MAAM,CAAC,eAAe,EAAE,oDAAoD,CAAC;SAC7E,WAAW,CAAC,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oEAoD0C,CAAC;SAChE,MAAM,CAAC,CAAC,IAA8C,EAAE,EAAE;QACzD,IAAI,CAAC;YACH,IAAI,IAAI,CAAC,UAAU,EAAE,CAAC;gBACpB,MAAM,GAAG,GAAG,iBAAiB,CAAC,KAAK,CAAC,CAAC;gBACrC,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC;oBACd,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,GAAG,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;gBAC5C,CAAC;qBAAM,CAAC;oBACN,KAAK,MAAM,GAAG,IAAI,UAAU,EAAE,CAAC;wBAC7B,MAAM,CAAC,GAAG,GAAG,CAAC,GAAG,CAAC,CAAC;wBACnB,OAAO,CAAC,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,GAAG,CAAC,CAAC,KAAK,cAAc,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;oBACnE,CAAC;gBACH,CAAC;gBACD,OAAO;YACT,CAAC;YACD,4DAA4D;YAC5D,+DAA+D;YAC/D,MAAM,MAAM,GAAG,KAAK,CAAC,OAAO,EAAE,CAAC;YAC/B,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC;gBACd,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;YAC/C,CAAC;iBAAM,CAAC;gBACN,MAAM,GAAG,GAAG,iBAAiB,CAAC,KAAK,CAAC,CAAC;gBACrC,KAAK,MAAM,GAAG,IAAI,UAAU,EAAE,CAAC;oBAC7B,MAAM,CAAC,GAAG,GAAG,CAAC,GAAG,CAAC,CAAC;oBACnB,OAAO,CAAC,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,GAAG,CAAC,CAAC,KAAK,cAAc,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;gBACnE,CAAC;YACH,CAAC;QACH,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,MAAM,MAAM,GAAG,IAAI,OAAO,CAAC,KAAK,CAAC;SAC9B,QAAQ,CAAC,OAAO,EAAE,+BAA+B,CAAC;SAClD,MAAM,CAAC,QAAQ,EAAE,2CAA2C,CAAC;SAC7D,MAAM,CAAC,eAAe,EAAE,uCAAuC,CAAC;SAChE,WAAW,CAAC,4BAA4B,CAAC;SACzC,MAAM,CAAC,CAAC,GAAW,EAAE,IAA8C,EAAE,EAAE;QACtE,IAAI,CAAC;YACH,IAAI,IAAI,CAAC,IAAI,IAAI,GAAG,CAAC,IAAI,EAAsB,CAAC,IAAI,EAAE,CAAC;gBACrD,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,iBAAiB,CAAC,GAAG,CAAC,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;gBACnE,OAAO;YACT,CAAC;YACD,IAAI,IAAI,CAAC,UAAU,EAAE,CAAC;gBACpB,MAAM,CAAC,GAAG,KAAK,CAAC,iBAAiB,CAAC,GAAG,CAAC,CAAC;gBACvC,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,KAAK,cAAc,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC;gBACjD,OAAO;YACT,CAAC;YACD,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC;QACtC,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,MAAM,MAAM,GAAG,IAAI,OAAO,CAAC,KAAK,CAAC;SAC9B,QAAQ,CAAC,OAAO,EAAE,+BAA+B,CAAC;SAClD,QAAQ,CAAC,SAAS,EAAE,cAAc,CAAC;SACnC,WAAW,CAAC,oBAAoB,CAAC;SACjC,MAAM,CAAC,KAAK,EAAE,GAAW,EAAE,KAAa,EAAE,EAAE;QAC3C,IAAI,CAAC;YACH,KAAK,CAAC,GAAG,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;YACtB,OAAO,CAAC,GAAG,CAAC,GAAG,GAAG,MAAM,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;YAC1C,gFAAgF;YAChF,IAAI,aAAa,CAAC,GAAG,CAAC,IAAI,CAAC,MAAM,kBAAkB,EAAE,CAAC,EAAE,CAAC;gBACvD,OAAO,CAAC,KAAK,CAAC,UAAU,GAAG,4JAA4J,CAAC,CAAC;YAC3L,CAAC;QACH,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,MAAM,QAAQ,GAAG,IAAI,OAAO,CAAC,OAAO,CAAC;SAClC,QAAQ,CAAC,OAAO,EAAE,0DAA0D,CAAC;SAC7E,WAAW,CAAC,uEAAuE,CAAC;SACpF,MAAM,CAAC,CAAC,GAAuB,EAAE,EAAE;QAClC,IAAI,CAAC;YACH,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;YACjB,IAAI,GAAG,EAAE,CAAC;gBACR,OAAO,CAAC,GAAG,CAAC,GAAG,GAAG,sBAAsB,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;YAC9D,CAAC;iBAAM,CAAC;gBACN,OAAO,CAAC,GAAG,CAAC,2BAA2B,CAAC,CAAC;YAC3C,CAAC;QACH,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;IACvB,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;IACvB,GAAG,CAAC,UAAU,CAAC,QAAQ,CAAC,CAAC;IACzB,GAAG,CAAC,UAAU,CAAC,oBAAoB,CAAC,UAAU,CAAC,CAAC,CAAC;IAEjD,OAAO,GAAG,CAAC;AACb,CAAC"}
+{"version":3,"file":"config.js","sourceRoot":"","sources":["../../src/commands/config.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AACpC,OAAO,EAAE,WAAW,EAAE,UAAU,EAAuC,MAAM,oBAAoB,CAAC;AAClG,OAAO,EAAE,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAElE,SAAS,SAAS,CAAC,GAAW,EAAE,KAAc;IAC5C,OAAO,GAAG,GAAG,CAAC,MAAM,CAAC,EAAE,CAAC,IAAI,KAAK,EAAE,CAAC;AACtC,CAAC;AAED,SAAS,iBAAiB,CAAC,KAAkB;IAC3C,OAAO,KAAK,CAAC,oBAAoB,EAAE,CAAC;AACtC,CAAC;AAED,qFAAqF;AACrF,qFAAqF;AACrF,8BAA8B;AAC9B,MAAM,cAAc,GAAG,CAAC,aAAa,EAAE,aAAa,EAAE,SAAS,CAAC,CAAC;AACjE,MAAM,kBAAkB,GAAG,CAAC,cAAc,CAAC,CAAC;AAE5C,SAAS,aAAa,CAAC,GAAW;IAChC,OAAO,cAAc,CAAC,QAAQ,CAAC,GAAG,CAAC,IAAI,kBAAkB,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,CAAC;AAC3F,CAAC;AAED,MAAM,UAAU,aAAa,CAC3B,UAAmB,EACnB,IAGC;IAED,MAAM,GAAG,GAAG,IAAI,OAAO,CAAC,QAAQ,CAAC,CAAC,WAAW,CAAC,0CAA0C,CAAC,CAAC;IAC1F,MAAM,KAAK,GAAG,IAAI,WAAW,CAAC,UAAU,CAAC,CAAC;IAC1C,MAAM,kBAAkB,GAAG,IAAI,EAAE,kBAAkB,IAAI,CAAC,KAAK,IAAI,EAAE;QACjE,IAAI,CAAC;YACH,MAAM,EAAE,eAAe,EAAE,GAAG,MAAM,MAAM,CAAC,wBAAwB,CAAC,CAAC;YACnE,MAAM,EAAE,QAAQ,EAAE,GAAG,MAAM,MAAM,CAAC,aAAa,CAAC,CAAC;YACjD,MAAM,MAAM,GAAG,MAAM,eAAe,CAAC,QAAQ,EAAE,CAAC,CAAC;YACjD,OAAO,MAAM,CAAC,KAAK,KAAK,SAAS,CAAC;QACpC,CAAC;QAAC,MAAM,CAAC;YACP,OAAO,KAAK,CAAC,CAAC,kDAAkD;QAClE,CAAC;IACH,CAAC,CAAC,CAAC;IAEH,GAAG;SACA,MAAM,CAAC,QAAQ,EAAE,gDAAgD,CAAC;SAClE,MAAM,CAAC,eAAe,EAAE,oDAAoD,CAAC;SAC7E,WAAW,CAAC,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oEAqD0C,CAAC;SAChE,MAAM,CAAC,CAAC,IAA8C,EAAE,EAAE;QACzD,IAAI,CAAC;YACH,IAAI,IAAI,CAAC,UAAU,EAAE,CAAC;gBACpB,MAAM,GAAG,GAAG,iBAAiB,CAAC,KAAK,CAAC,CAAC;gBACrC,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC;oBACd,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,GAAG,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;gBAC5C,CAAC;qBAAM,CAAC;oBACN,KAAK,MAAM,GAAG,IAAI,UAAU,EAAE,CAAC;wBAC7B,MAAM,CAAC,GAAG,GAAG,CAAC,GAAG,CAAC,CAAC;wBACnB,OAAO,CAAC,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,GAAG,CAAC,CAAC,KAAK,cAAc,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;oBACnE,CAAC;gBACH,CAAC;gBACD,OAAO;YACT,CAAC;YACD,4DAA4D;YAC5D,+DAA+D;YAC/D,MAAM,MAAM,GAAG,KAAK,CAAC,OAAO,EAAE,CAAC;YAC/B,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC;gBACd,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;YAC/C,CAAC;iBAAM,CAAC;gBACN,MAAM,GAAG,GAAG,iBAAiB,CAAC,KAAK,CAAC,CAAC;gBACrC,KAAK,MAAM,GAAG,IAAI,UAAU,EAAE,CAAC;oBAC7B,MAAM,CAAC,GAAG,GAAG,CAAC,GAAG,CAAC,CAAC;oBACnB,OAAO,CAAC,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,GAAG,CAAC,CAAC,KAAK,cAAc,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;gBACnE,CAAC;YACH,CAAC;QACH,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,MAAM,MAAM,GAAG,IAAI,OAAO,CAAC,KAAK,CAAC;SAC9B,QAAQ,CAAC,OAAO,EAAE,+BAA+B,CAAC;SAClD,MAAM,CAAC,QAAQ,EAAE,2CAA2C,CAAC;SAC7D,MAAM,CAAC,eAAe,EAAE,uCAAuC,CAAC;SAChE,WAAW,CAAC,4BAA4B,CAAC;SACzC,MAAM,CAAC,CAAC,GAAW,EAAE,IAA8C,EAAE,EAAE;QACtE,IAAI,CAAC;YACH,IAAI,IAAI,CAAC,IAAI,IAAI,GAAG,CAAC,IAAI,EAAsB,CAAC,IAAI,EAAE,CAAC;gBACrD,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,iBAAiB,CAAC,GAAG,CAAC,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;gBACnE,OAAO;YACT,CAAC;YACD,IAAI,IAAI,CAAC,UAAU,EAAE,CAAC;gBACpB,MAAM,CAAC,GAAG,KAAK,CAAC,iBAAiB,CAAC,GAAG,CAAC,CAAC;gBACvC,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,KAAK,cAAc,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC;gBACjD,OAAO;YACT,CAAC;YACD,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC;QACtC,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,MAAM,MAAM,GAAG,IAAI,OAAO,CAAC,KAAK,CAAC;SAC9B,QAAQ,CAAC,OAAO,EAAE,+BAA+B,CAAC;SAClD,QAAQ,CAAC,SAAS,EAAE,cAAc,CAAC;SACnC,WAAW,CAAC,oBAAoB,CAAC;SACjC,MAAM,CAAC,KAAK,EAAE,GAAW,EAAE,KAAa,EAAE,EAAE;QAC3C,IAAI,CAAC;YACH,KAAK,CAAC,GAAG,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;YACtB,OAAO,CAAC,GAAG,CAAC,GAAG,GAAG,MAAM,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;YAC1C,gFAAgF;YAChF,IAAI,aAAa,CAAC,GAAG,CAAC,IAAI,CAAC,MAAM,kBAAkB,EAAE,CAAC,EAAE,CAAC;gBACvD,OAAO,CAAC,KAAK,CAAC,UAAU,GAAG,4JAA4J,CAAC,CAAC;YAC3L,CAAC;QACH,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,MAAM,QAAQ,GAAG,IAAI,OAAO,CAAC,OAAO,CAAC;SAClC,QAAQ,CAAC,OAAO,EAAE,0DAA0D,CAAC;SAC7E,WAAW,CAAC,uEAAuE,CAAC;SACpF,MAAM,CAAC,CAAC,GAAuB,EAAE,EAAE;QAClC,IAAI,CAAC;YACH,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;YACjB,IAAI,GAAG,EAAE,CAAC;gBACR,OAAO,CAAC,GAAG,CAAC,GAAG,GAAG,sBAAsB,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;YAC9D,CAAC;iBAAM,CAAC;gBACN,OAAO,CAAC,GAAG,CAAC,2BAA2B,CAAC,CAAC;YAC3C,CAAC;QACH,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,OAAO,CAAC,KAAK,CAAE,GAAa,CAAC,OAAO,CAAC,CAAC;YACtC,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACvB,CAAC;IACH,CAAC,CAAC,CAAC;IAEL,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;IACvB,GAAG,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;IACvB,GAAG,CAAC,UAAU,CAAC,QAAQ,CAAC,CAAC;IACzB,GAAG,CAAC,UAAU,CAAC,oBAAoB,CAAC,UAAU,CAAC,CAAC,CAAC;IAEjD,OAAO,GAAG,CAAC;AACb,CAAC"}

package/dist/commands/gateway.d.ts

@@ -13,7 +13,24 @@ export type HumanRowsLookup = (address: string) => Promise<{
 }>;
 export interface GatewayCommandDeps {
     queueRows?: HumanRowsLookup;
+    humanReadiness?: HumanReadinessLookup;
 }
+export interface HumanReadinessView {
+    state: "ready" | "not-ready" | "indeterminate";
+    configured: boolean | null;
+    enabled: boolean | null;
+    active: boolean | null;
+    ready: boolean;
+    connector?: {
+        kind: string;
+        ref: string;
+    };
+    reason: string;
+    nextAction: string | null;
+    checkedAt?: string;
+}
+export type HumanReadinessLookup = (entityId: string) => Promise<HumanReadinessView>;
+export declare function daemonHumanReadiness(entityId: string): Promise<HumanReadinessView>;
 /** Default queue-row half of the remove guard: non-terminal rows addressed to the human,
  *  via the daemon. ok:false carries the reason the board COULD NOT BE CHECKED. */
 export declare function daemonQueueRows(address: string): ReturnType<HumanRowsLookup>;

package/dist/commands/gateway.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"gateway.d.ts","sourceRoot":"","sources":["../../src/commands/gateway.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAmBpC,MAAM,WAAW,WAAW;IAC1B,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AACD,MAAM,MAAM,eAAe,GAAG,CAAC,OAAO,EAAE,MAAM,KAAK,OAAO,CACtD;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,IAAI,EAAE,WAAW,EAAE,CAAA;CAAE,GACjC;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAC/B,CAAC;AAEF,MAAM,WAAW,kBAAkB;IACjC,SAAS,CAAC,EAAE,eAAe,CAAC;CAC7B;AAED;kFACkF;AAClF,wBAAsB,eAAe,CAAC,OAAO,EAAE,MAAM,GAAG,UAAU,CAAC,eAAe,CAAC,CA8BlF;AAED,wBAAgB,cAAc,CAAC,IAAI,GAAE,kBAAuB,GAAG,OAAO,CAmJrE"}
+{"version":3,"file":"gateway.d.ts","sourceRoot":"","sources":["../../src/commands/gateway.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAoBpC,MAAM,WAAW,WAAW;IAC1B,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AACD,MAAM,MAAM,eAAe,GAAG,CAAC,OAAO,EAAE,MAAM,KAAK,OAAO,CACtD;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,IAAI,EAAE,WAAW,EAAE,CAAA;CAAE,GACjC;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAC/B,CAAC;AAEF,MAAM,WAAW,kBAAkB;IACjC,SAAS,CAAC,EAAE,eAAe,CAAC;IAC5B,cAAc,CAAC,EAAE,oBAAoB,CAAC;CACvC;AAED,MAAM,WAAW,kBAAkB;IACjC,KAAK,EAAE,OAAO,GAAG,WAAW,GAAG,eAAe,CAAC;IAC/C,UAAU,EAAE,OAAO,GAAG,IAAI,CAAC;IAC3B,OAAO,EAAE,OAAO,GAAG,IAAI,CAAC;IACxB,MAAM,EAAE,OAAO,GAAG,IAAI,CAAC;IACvB,KAAK,EAAE,OAAO,CAAC;IACf,SAAS,CAAC,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAA;KAAE,CAAC;IAC1C,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,GAAG,IAAI,CAAC;IAC1B,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,MAAM,oBAAoB,GAAG,CAAC,QAAQ,EAAE,MAAM,KAAK,OAAO,CAAC,kBAAkB,CAAC,CAAC;AAErF,wBAAsB,oBAAoB,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAAC,kBAAkB,CAAC,CAiCxF;AAED;kFACkF;AAClF,wBAAsB,eAAe,CAAC,OAAO,EAAE,MAAM,GAAG,UAAU,CAAC,eAAe,CAAC,CA8BlF;AAED,wBAAgB,cAAc,CAAC,IAAI,GAAE,kBAAuB,GAAG,OAAO,CA2LrE"}