@llblab/pi-kit 0.1.0

package/node_modules/@llblab/pi-actors/dist/skills/swarm/references/development-swarm.md

@@ -0,0 +1,189 @@
+# Development Swarms
+
+Use this reference when two or more implementation participants can own disjoint mutation zones and one integrator can reconcile them. Keep generic actor execution and lifecycle behavior in `actors`.
+
+## Admission test
+
+Use a development swarm only when all are true:
+
+- the accepted direction is stable enough to partition;
+- each participant can receive a meaningful bounded scope;
+- shared contracts have one named owner;
+- work can be isolated from the shared target while in progress;
+- one integrator owns merge order and final validation.
+
+Do not parallelize implementation when tasks need the same central files, semantic ordering dominates wall-clock time, or the likely conflicts would invalidate the decomposition. Use planning or review first.
+
+## Coordinator role separation
+
+In a host-coordinator topology, the current Pi instance owns the declarative outcome and participant graph rather than acting as the default implementation worker. It may receive intent through Telegram or another companion extension, but transport does not become a gateway or gain hidden instance-creation authority; participant creation remains an explicit actor-kernel Run.
+
+The coordinator should:
+
+- Translate high-level intent into bounded task cards and dependency edges.
+- Keep user authority, shared contracts, integration order, and final validation local.
+- Remain available for checkpoints, permissions, conflicts, and changing evidence.
+- Consume terminal handoffs, durable artifacts, and Trace attention instead of mirroring participant work.
+- Check overdue work on an evidence-based timer; never replace event-driven completion with a rapid polling loop.
+
+A participant should:
+
+- Own one concrete execution or evidence boundary.
+- Avoid global orchestration and undeclared participant creation.
+- Return a bounded handoff that lets the coordinator decide without replaying the entire task.
+
+Use one ordinary Run under `actors` when only one worker is delegated. Activate this development-swarm protocol when two or more participants, parallel ownership, or explicit integration edges exist. Keep trivial single-boundary work inline when delegation overhead has no compensating value.
+
+## Reasoning profiles
+
+| Role | Default | Raise or fan out when |
+| --- | --- | --- |
+| Bounded implementation author | Reasoning off | The card explicitly owns unresolved diagnosis or design judgement |
+| Reviewer | Medium reasoning, clean context | Stakes require independent lenses or repeated judges |
+| Synthesizer / integrator | Medium reasoning | Evidence conflicts, shared contracts move, or merge order is semantic |
+| Coordinator | Sufficient for decomposition and decisions | Scope, authority, or architecture remains unresolved |
+
+Prefer independent review after implementation over asking one author thread to implement, retain all local assumptions, and then certify itself. When risk justifies the cost, use multiple independent reviewers: different lenses increase breadth, while repeated judges increase confidence. Preserve minority high-impact findings and merge only evidence-backed conclusions.
+
+More reviewers are not automatically better. Do not fan out when they would inspect unstable code, share contaminated context, repeat one unsupported claim, or exceed the value of the decision. Never change an already-running participant solely to enforce a newer profile; add a fresh review boundary if evidence remains open.
+
+## Decompose by ownership
+
+Prefer mutation-zone ownership over broad feature labels.
+
+```text
+behavior owner  → production behavior in one domain
+test owner      → regressions and fixtures for that domain
+docs owner      → affected agent/user contract
+integrator      → shared contracts, merge, final checks
+```
+
+A participant may own both behavior and its tests when separating them would force synchronized edits. What matters is one owner per writable surface and an explicit integration edge.
+
+## Task card
+
+Every participant receives one task card before mutation:
+
+```markdown
+# Task Card
+
+Goal:
+Non-goals:
+Allowed files or logical scope:
+Avoided files or shared contracts:
+Execution profile:
+Isolation mode: exclusive paths | isolated worktree | artifact-only
+Shared surfaces reserved for integrator:
+Expected artifact or patch:
+Required evidence:
+Checks:
+Escalate when:
+Handoff destination:
+```
+
+A useful task card names the smallest scope that can independently reach a validation boundary. It does not ask a participant to "help with" a broad project area. Participants must restate scope before editing and record discovered out-of-scope work rather than performing it.
+
+`swarm/development-tasking` can generate and critique one card when the goal, allowed scope, avoided scope, checks, model, and tools are already known.
+
+## Write ownership
+
+- Give each writable file or logical contract one owner.
+- Treat schemas, public APIs, central configuration, migrations, and specifications as exclusive even when textual merges look easy.
+- Parallel readers may inspect a stable shared target.
+- Isolate concurrent mutation through the repository's existing branch/workspace mechanism.
+- Use bounded lock evidence when ownership is not otherwise obvious. A lock records intent; it does not authorize scope expansion.
+- Release ownership at terminal handoff or explicitly transfer it through the integrator.
+
+If a participant discovers that another scope must change, it emits a dependency or conflict report and stops that edge. The coordinator either transfers ownership, serializes the work, or replans.
+
+## Isolation modes
+
+- `Exclusive paths`: Writers share one worktree only when their complete writable path sets are disjoint and the shared baseline remains stable.
+- `Isolated worktree`: Use when compilation, generated files, imports, or likely dependencies can touch shared repository state.
+- `Artifact-only`: Use for reports, inventories, proposed patches, fixtures, or reviews that the integrator applies later.
+
+The integrator exclusively owns `BACKLOG.md`, `CHANGELOG.md`, lockfiles, generated metadata, public schemas, release manifests, and cross-domain configuration by default. A task card may transfer one of these surfaces to another participant, but never create concurrent ownership. Authors report required shared-surface changes in handoff instead of applying them outside scope.
+
+## Coordinator checkpoints
+
+A checkpoint preserves useful local context while requesting one decision:
+
+```markdown
+# Coordinator Checkpoint
+
+Task:
+Current scope:
+Question:
+Why a coordinator decision is required:
+Options and evidence:
+Recommended option:
+Risk if guessed:
+State that must be preserved:
+```
+
+Use checkpoints for scope changes, product choices, shared-contract decisions, permissions, or conflict policy. The coordinator answers only the bounded question. If the participant cannot resume with preserved context, retain the checkpoint as a handoff and start a clean replacement explicitly.
+
+## Handoff
+
+Every participant returns:
+
+```markdown
+# Handoff
+
+Task:
+Status: complete | degraded | blocked
+Summary:
+Touched scope:
+Behavior or contract changes:
+Checks and results:
+Artifacts or patch identity:
+Dependencies discovered:
+Risks and unresolved questions:
+Integrator invariants:
+```
+
+A successful process exit without the expected patch, artifact, or evidence is not a successful handoff. Preserve partial work as degraded evidence when it is useful and safe to integrate.
+
+## Conflict evidence
+
+Distinguish three conflict classes:
+
+- **Textual conflict:** edits overlap mechanically.
+- **Semantic conflict:** edits merge but depend on incompatible meanings.
+- **Architecture conflict:** the decomposition or accepted direction is wrong.
+
+Each affected owner reports:
+
+```markdown
+# Conflict Report
+
+Task and owned scope:
+Conflicting scope:
+Intent:
+Invariant that must survive:
+Change made:
+Evidence:
+Safe-to-discard portion:
+Proposed resolution:
+```
+
+The integrator resolves from both reports. Architecture conflicts stop affected work and return to planning. Do not let participants recursively negotiate until their independent intent is lost.
+
+## Integration protocol
+
+The named integrator:
+
+1. freezes new author mutations and preserves every terminal handoff before integration;
+2. reads task cards, handoffs, dependency edges, and conflict reports;
+3. verifies each result stayed within scope;
+4. integrates in dependency order, one ownership edge at a time;
+5. resolves conflicts while preserving stated invariants;
+6. runs checks after risky edges and the full agreed validation at the end;
+7. obtains fresh review for conflict-resolved or shared-contract changes;
+8. reports integrated tasks, rejected or deferred work, checks, and residual risks.
+
+Do not treat a clean merge, participant-local tests, or a collection of terminal Runs as integrated completion. Completion requires retained shared state plus coordinator-owned validation evidence.
+
+## Stop conditions
+
+Stop and replan when ownership overlaps, an exclusive contract lacks one owner, task cards cannot be independently validated, an out-of-scope dependency is required, architecture conflict appears, or no integrator can validate the retained result. Prefer a smaller serial cohort over parallel diff chaos.

package/node_modules/@llblab/pi-actors/dist/skills/swarm/references/review-swarms.md

@@ -0,0 +1,115 @@
+# Review Swarms
+
+Use this reference for independent review, delegated audit, research synthesis, quorum judgement, and post-merge review. Generic actor execution remains owned by `actors`.
+
+## Select breadth or confidence
+
+```text
+Different lenses on one target → breadth → lens swarm
+Same exact claim, independent judges → confidence → quorum
+Important lenses each need repeated judges → breadth + confidence → lens swarms of quorums
+```
+
+Use the smallest shape that covers the decision risk. A lens swarm of quorums is reserved for high-impact security, financial, governance, migration, or release decisions.
+
+Primary Recipes:
+
+- `swarm/lens-review` for parallel risk lenses plus verification, merge, judge, and normalized result;
+- `swarm/quorum-review` for one prompt judged independently by explicitly selected models;
+- `swarm/research-synthesis` for plan, evidence map, contradictions, verification, and risk-first synthesis;
+- `swarm/architect` for competing directions and one validated smallest next slice;
+- `swarm/review-readiness` for a multi-lens ship/readiness verdict.
+
+## Lens selection
+
+Choose lenses from plausible failure modes, not from a fixed catalog. Common software lenses include correctness, architecture, security, tests, concurrency, data integrity, performance, operator UX, accessibility, maintainability, documentation, and release risk.
+
+A good lens assignment states:
+
+```markdown
+Target:
+Question or claim:
+Lens:
+Evidence required:
+Out of scope:
+Severity rule:
+Output shape:
+Stop condition:
+```
+
+Do not ask every reviewer to cover everything. Keep reviewers independent until synthesis so one early narrative does not contaminate all findings.
+
+## Quorum design
+
+A quorum keeps the target, claim, evidence standard, and output shape constant while varying independent judges. Before fanout:
+
+1. define the exact decision claim;
+2. define what counts as supporting and contradicting evidence;
+3. select the minimum successful threshold;
+4. choose concurrency and timeout bounds;
+5. preflight model and tool availability;
+6. define how partial results affect status.
+
+Provider or model failure reduces available evidence; it is not a vote. When evidence falls below threshold, mark the result degraded or insufficient data.
+
+## Research evidence
+
+Research participants separate source discovery, verification, contradiction mapping, and synthesis when stakes justify it.
+
+- Every material claim traces to a source note, inspected artifact, or explicit uncertainty.
+- Source quality and confidence remain visible.
+- Contradictory evidence is first-class output.
+- Missing source classes block overconfident synthesis.
+- Unsafe or unverifiable evidence is excluded with a reason.
+
+Do not turn a research swarm into an automatic publication pipeline. Stop at the caller's evidence and decision boundary.
+
+## Merge protocol
+
+A merger is a synthesis participant, not a formatter. It may deduplicate, rank, connect evidence, and add a grounded `merger finding`, but it may not fabricate support.
+
+For serious quorum work, use a clean-context merger. The merger receives all retained participant outputs and must produce:
+
+- status: complete, degraded, or insufficient data;
+- consensus findings and vote shape where applicable;
+- minority high-impact findings;
+- contradictions and unresolved evidence gaps;
+- merger findings, clearly labeled;
+- confidence and limitations;
+- ordered next actions.
+
+Keep raw participant outputs until the merged result is accepted. Preserve attribution for major findings. Never promote repeated low-value observations merely because they are numerous, and never discard a severe evidence-backed minority finding merely because it is unique.
+
+## Conflict and disagreement
+
+Disagreement can mean different assumptions, different evidence, ambiguous criteria, or real uncertainty. The merger records:
+
+```markdown
+Finding:
+Supporting participants and evidence:
+Contradicting participants and evidence:
+Assumption difference:
+Impact if minority view is correct:
+Resolution status:
+Next evidence needed:
+```
+
+Resolve only when evidence supports resolution. Otherwise preserve the disagreement and lower confidence.
+
+## Post-merge review
+
+Use a fresh reviewer when the merged result will drive consequential implementation or decisions. The post-merge reviewer checks the report, not the original target by default:
+
+- evidence traceability;
+- honest severity;
+- correct quorum accounting;
+- preserved minority findings;
+- unsupported merger narrative;
+- actionable next steps;
+- retained uncertainty and contradictions.
+
+Possible decisions are accept, accept with notes, revise merge, rerun bounded quorum, or escalate. Rerun only when the raw evidence or scope is genuinely insufficient, not because the verdict is inconvenient.
+
+## Completion and stop rules
+
+A review swarm is complete only when requested evidence is retained, threshold status is explicit, synthesis preserves dissent, and the coordinator can state the safe decision or next evidence slice. Stop when the claim is ambiguous, target changes during review, preflight fails, evidence is not inspectable, threshold cannot be met, or merger independence required by the stakes is unavailable.

package/node_modules/@llblab/pi-actors/docs/README.md

@@ -0,0 +1,20 @@
+# Documentation Index
+
+Living index of all documentation in the `/docs` directory.
+
+## Documents
+
+- [command-templates.md](./command-templates.md) — Portable synchronous command execution standard
+- [template-recipes.md](./template-recipes.md) — Saved JSON/Markdown recipe standard, imports, and reusable command-template graph composition
+- [async-runs.md](./async-runs.md) — Run lifecycle, state, Control, Trace, cancellation, and terminal reconciliation
+- [actor-inspector.md](./actor-inspector.md) — Owner-filtered actor-instance navigation through Recipe, Trace, and Control
+- [tool-registry.md](./tool-registry.md) — Local `pi-actors` registry storage and `register_tool` adaptation
+- [recipe-library.md](./recipe-library.md) — Packaged standard recipe library such as async subagents, coordinator pipelines, utilities, and music playback
+- [releasing.md](./releasing.md) — Guarded tag validation, npm Trusted Publisher setup, registry verification, and GitHub Release convergence
+
+## Project Surfaces
+
+- [Human product entrypoint](../README.md)
+- [Implementation protocol](../AGENTS.md)
+- [Future work](../BACKLOG.md)
+- [Completed delivery history](../CHANGELOG.md)

package/node_modules/@llblab/pi-actors/docs/actor-inspector.md

@@ -0,0 +1,50 @@
+# Actor Inspector
+
+Open the live owner-filtered Run browser with:
+
+```text
+/actor-inspector
+```
+
+The Inspector follows the kernel directly. It shows Runs owned by the current Pi session and offers exactly three tabs.
+
+## Recipe
+
+Shows captured execution provenance:
+
+- file-derived Recipe stem and logical reference;
+- source kind (`user_registry_capability`, `active_skill_component`, or `explicit_file_recipe`) and Skill identity when owned;
+- resolved template and values;
+- root/import roles plus alias ancestry;
+- declared artifacts and actor-local actions;
+- model/thinking policy and launch source.
+
+Captured Recipe evidence belongs to the Run generation and does not change when an active Recipe file later changes. Skill components display logical identities such as `artifacts/report`; private physical `source_file`, `skill_dir`, and `recipe_dir` stay out of Inspector and model-facing views. Non-empty object values render as indented brace-delimited property lists rather than flattened inline strings.
+
+## Trace
+
+Shows the unified bounded Trace projection. Sources include lifecycle/runtime observations, Controls, owned Pi turns, command-log tails, results, artifacts, and diagnostics. Filter by source and open a row for structured detail.
+
+Trace ordering stays deterministic and newest-first: timestamp descending, same-source physical ordinal descending, fixed internal source rank, then stable id. Internal ordinals are never displayed or interpreted as cross-source causality. Row numbers still read chronologically from bottom to top: the oldest visible event is `#1` and the newest carries the highest number. The summary states whether retained history is complete; `runtime.trace_compacted` means older history was discarded and shows bounded cumulative drop evidence. Terminal/result/execution/artifact evidence keeps its own authority. The projection applies path containment and redaction before rendering.
+
+## Control
+
+Shows:
+
+- Recipe-declared actor-local actions;
+- runtime-owned lifecycle actions;
+- generation-fenced endpoint readiness;
+- pending capacity, saturation, journal bytes, stale count, and diagnostics;
+- recent durable Control records and outcomes.
+
+A service endpoint counts as ready only when `control-endpoint.json` matches the Run's immutable `run_instance_id`. Capacity reaches zero at 64 pending Controls; further requests are rejected before admission, while admitted nonterminal Controls never expire automatically. Runtime-owned kill remains available for a stuck saturated Run. Recent Control input and errors use the same bounded structured redaction as tool inspection. The durable `controls.jsonl` journal remains raw and local; rendering never mutates it or attaches an unredacted copy.
+
+## Keys
+
+The footer displays current bindings. Use tab navigation to switch Recipe/Trace/Control, movement keys to select rows, detail navigation to inspect evidence, refresh to reconcile disk state, and the documented kill key for lifecycle termination.
+
+Run kill revalidates owner and generation through the canonical lifecycle path. After success, the Run status header is the sole confirmation; the content area does not duplicate it. The Inspector never edits state directly and never derives authority from displayed data.
+
+## Scope
+
+The Actor Inspector treats each Run as a concrete actor instance. It does not expose group conversations, peer addresses, routing, or communication topology. Use `inspect target=runtime view=status`, `inspect target=recipes view=status`, and `inspect target=tool:<name> view=status` for non-Run management targets.

package/node_modules/@llblab/pi-actors/docs/async-runs.md

@@ -0,0 +1,141 @@
+# Runs
+
+A Run is one detached execution instance:
+
+```text
+Recipe --spawn--> Run
+Run = Recipe + Trace + Control
+```
+
+## Creation
+
+`spawn` accepts a Recipe/file or inline command template and optional values, Run id, transport context, and artifact declarations. The runtime resolves the Recipe, validates typed values and current policy placeholders, claims the state directory, creates a new immutable `run_instance_id`, captures process identity, starts the runner, and appends `run.start` Trace.
+
+A reused state directory fails while its prior generation remains active. Restart cleanup removes stale terminal state before the new generation starts.
+
+## Identity and Ownership
+
+Each Run persists:
+
+- safe Run id and state path;
+- current Pi owner id;
+- immutable `run_instance_id`;
+- process id plus captured process identity;
+- launch source and tool-call provenance;
+- captured Recipe/template/values;
+- model and thinking policy provenance.
+
+Inspection, Control, cancellation, kill, retirement, and teardown filter by owner. Lifecycle mutations revalidate generation, state, and process identity under the canonical lock.
+
+## State Files
+
+```text
+run.json
+trace.jsonl
+controls.jsonl
+control-endpoint.json       controlled services only
+execution.json
+progress.json
+result.json
+stdout.log
+stderr.log
+terminal.json               terminal lifecycle evidence
+terminal-notification.json  reconciliation evidence
+diagnostics.jsonl
+<declared artifacts>
+```
+
+`run.json` carries `state_schema: "run-kernel-v1"`. New Runs do not create communication-plane state.
+
+## Trace
+
+Trace records strict bounded events:
+
+```json
+{"id":"…","ts":"…","kind":"command.done","summary":"Command completed","data":{"code":0},"level":"info","attention":"followup"}
+```
+
+Required fields: `id`, `ts`, `kind`. Optional fields: `summary`, `data`, `level`, `attention`. Trace rejects addressed-envelope fields and malformed or oversized data. It retains a recent suffix within 2,048 events and 4 MiB. When either bound would be exceeded, the canonical lock atomically keeps a newest suffix near the lower targets, the new event, and one cumulative warning-only `runtime.trace_compacted` marker. The marker means older history was discarded; it reports cumulative drop evidence and never requests attention.
+
+Runtime lifecycle, runner progress, command completion, cancellation, kill, parent teardown, and controlled-service observations use Trace. Bounded reads preserve complete UTF-8 lines and disclose omitted legacy prefixes. `inspect view=trace` reports retained-history completeness and projects events with Controls, owned Pi turns, logs, results, artifacts, and diagnostics newest-first. Equal timestamps use same-source physical order, then fixed source rank and stable id without claiming cross-source causality. Terminal state, `result.json`, `execution.json`, and artifacts remain authoritative even when old Trace has compacted.
+
+## Control
+
+A Recipe declares actor-local actions only when its process consumes them:
+
+```json
+{"control":["pause","resume","stop"]}
+```
+
+Public request:
+
+```json
+{"target":"run:player","action":"pause","input":{"reason":"operator"},"verbose":false}
+```
+
+The runtime:
+
+1. acquires the lifecycle lock;
+2. revalidates owner, `run_instance_id`, running state, and process identity;
+3. appends a queued generation-bound record to `controls.jsonl`;
+4. resolves a matching ready endpoint from `control-endpoint.json`;
+5. writes the exact `{id, action, input?}` wire document to FIFO or named pipe;
+6. records delivered or failed outcome.
+
+Unix services may publish a FIFO; native Windows services publish a Windows named pipe. Native Windows FIFO delivery fails before transport rather than degrading to another protocol. Both transports admit the same portable envelope: action is at most 64 lowercase ASCII characters, serialized JSON input is at most 380 bytes, and the newline-terminated wire record is at most 512 bytes. Invalid envelopes fail before journal admission or transport. Put larger data in a declared artifact/path and send only a bounded reference or instruction through Control.
+
+A service exact-id claims queued or transport-delivered Controls and records handled/failed outcomes through the canonical Control journal authority. Admission performs one locked read, integrity/generation check, terminal-tail compaction, capacity decision, and atomic write. The 65th pending Control and a rewrite exceeding 1 MiB fail as bounded `control_backpressure` before admission; malformed, unreadable, oversized, or stale-generation journals fail with an integrity reason and no rejected record. `inspect view=control` reports pending capacity, saturation, stale work, journal bytes, and diagnostics. Every transition uses the same lock, expected-state fence, 128-terminal compaction, and atomic bounded rewrite; persisted errors truncate inside the string at 4 KiB. Admitted nonterminal Controls never expire automatically. Delivery failure evidence cannot regress a Control already claimed or completed by a fast consumer. Services capture their startup generation, so stale-generation Controls never execute.
+
+Runtime lifecycle `kill`, retention actions, and review retry/reset remain runtime-owned rather than Recipe-declared. Kill is the recovery path for a stuck saturated Run: it bypasses actor-local Control capacity and creates no synthetic Control. Same-directory restart clears all generation-local evidence before the new `run_instance_id`; archive moves the exact bounded terminal tree, while prune removes kernel state and preserves only explicitly requested artifacts.
+
+## Execution Evidence
+
+`execution.json` stores general command/session provenance. The async runner keeps bounded stdout/stderr logs plus complete capture artifacts when semantic validation requires untruncated evidence. Pi command execution also records owned session provenance for later Trace projection and review checks. Trace and Control quotas do not constrain declared user artifacts, repositories or media sources, complete execution captures, or actor-owned queue/workload state; each remains governed by its own lifecycle and policy.
+
+Review acceptance remains a command-stage concern. General execution evidence does not imply review approval.
+
+## Status and Terminal Reconciliation
+
+Statuses include `running`, `done`, `failed`, `exited`, `cancelled`, and `killed`. Status resolution combines persisted metadata, result/terminal evidence, and verified process state.
+
+Ambient observation detects terminal transitions and retained Trace attention. Canonical attention is an in-memory wake hint, not a durable queue: observers prime retained ids at startup, deliver each later retained unseen id once, and bound memory to the current retained set across compaction. Persist durable recovery state or an artifact before emitting attention; compaction may discard older hints and its marker makes that history loss explicit. Terminal follow-up delivery persists handled/failure evidence so reloads retry unhandled transitions without duplicating completed notifications.
+
+Large semantic results stay outside compact visible follow-up text and remain available in structured details, execution captures, or artifacts.
+
+## Cancellation and Kill
+
+Cancellation and kill use canonical lifecycle control:
+
+- acquire the state lock;
+- validate owner and optional generation fence;
+- verify process identity;
+- signal the owned process or process group/tree;
+- persist lifecycle evidence and Trace;
+- finalize in-flight execution and progress.
+
+Shutdown and parent teardown kill only exact owned generations. A stale pid or replacement generation fails closed.
+
+## Retention
+
+Archive and prune apply only to terminal Runs and enforce path containment. Retention never removes active or foreign-owned state. The state index can rebuild from trustworthy Run directories after corruption.
+
+## Service Recipes
+
+Packaged controlled services demonstrate the endpoint protocol:
+
+- `music-player/playback` consumes playback Controls and emits playback Trace;
+- `actors/resource-locker` consumes queue/lease actions, emits lock Trace, and atomically retains at most 512 valid journal records within 1 MiB.
+
+Shared archive/prune evidence similarly retains at most 256 valid records within 1 MiB under its canonical lock. The obsolete advisory `wake.jsonl` notifier was removed; filesystem watchers and bounded reconciliation observe authoritative state directly.
+
+One-shot pipelines omit Control and terminate through their command graph.
+
+## Inspection
+
+```text
+inspect target=run:<id> view=recipe
+inspect target=run:<id> view=trace source=lifecycle lines=40
+inspect target=run:<id> view=control
+```
+
+Use `/actor-inspector` to inspect Runs as concrete actor instances in the live TUI. Runtime, Recipe registry, and tool definitions remain separate management targets. No public noun, tool, target, or view is added by bounded retention.