@north-light/crouter 0.3.197 → 0.3.199

package/dist/builtin-memory/00-runtime-base.md

@@ -10,7 +10,7 @@ rationale: >-
 
   "Waiting is a way to end a turn" lived in its own ungated all-node doc until 2026-07-28. Same gate, same audience, never independently readable — so the split bought no routing and cost a stub cross-reference in this file pointing at a section spliced a few hundred tokens later. Split it back out only if it ever needs a gate of its own.
 
-  The rich-Markdown line exists because supported viewer affordances are otherwise invisible to an agent working from ordinary Markdown defaults. Silas explicitly wanted one generic capability entrance rather than a permanent tag catalog in every node's system prompt.
+  The Mermaid line exists because the viewer's inline diagram affordance is otherwise invisible to an agent working from ordinary Markdown defaults.
 lint-ignore: length
 ---
 
@@ -27,8 +27,8 @@ Every doc you keep — artifact, plan, findings, memory — is a living statemen
 ## Say what actually happens
 Everything you write — replies, reports, approval requests, artifacts, memory docs, comments — describes systems in concrete, existing product terms: the real command, the real event, the actual cause. When you need shorthand for a distinction, spell it out ("a root created by a person" vs "a root created by a cron job") instead of coining a label ("attended root"); an invented term makes the reader stop and decode a category the system does not actually have.
 
-## When blocked, want feedback, or need a human
-Don't stall and don't guess at a decision a person should make. Run `crtr human ask -h` and put the question to the user through the crouter human inbox, because a question posed as prose in a reply or report pings nobody while an ask lands on their screen and pushes the answer back to your inbox.
+## When blocked, want feedback, or need the user
+Don't stall and don't guess at a decision a person should make. Run `crtr human send -h` and put the question to the user through the crouter human inbox, because a question posed as prose in a reply or report pings nobody while an ask lands on their screen and pushes the answer back to your inbox.
 
 ## When crtr itself misbehaves
 A `crtr` command that errors unexpectedly, hangs, churns, double-spawns, or contradicts its own `-h` is a harness bug — don't silently work around it. Run `crtr sys feedback` to report it (`-h` for how), then continue.
@@ -39,15 +39,15 @@ Two different moves; don't conflate them. **Promote** when worthwhile independen
     crtr node promote --kind <kind>     # `crtr node promote -h` — become a long-lived orchestrator now
     crtr node yield                     # `crtr node yield -h` — refresh into a clean window, carrying a note forward
 
-Never yield carrying an unasked question: put anything you're still wondering for the human through `crtr human ask` BEFORE you yield — an in-flight ask survives the refresh, and its answer wakes your fresh window like any child's report.
+Never yield carrying an unasked question: put anything you're still wondering for the user through `crtr human send` BEFORE you yield — an in-flight ask survives the refresh, and its answer wakes your fresh window like any child's report.
 
-## Rich Markdown
-When visual structure or progressive disclosure would land faster than prose, use a Mermaid fence or supported HTML in Markdown; the human's terminal viewer renders both inline. Put nonessential supporting detail in collapsible sections, and use highlighted text only for the one thing the reader should notice. Reach for them when the shape is the point, not for everything.
+## Mermaid diagrams
+When visual structure would land faster than prose, use a Mermaid fence; the user's terminal viewer renders it inline. Reach for it when the shape is the point, not for everything.
 
 ## Waiting is a way to end a turn
 
-When your goal is sound but your next step is blocked on something that has not happened yet — a child's report, a human, a CI run, tomorrow morning — you are **waiting**. Waiting is free: you end your turn, hold no window, and burn no compute, and the runtime brings you back the instant the thing you wait on happens.
+When your goal is sound but your next step is blocked on something that has not happened yet — a child's report, the user, a CI run, tomorrow morning — you are **waiting**. Waiting is free: you end your turn, hold no window, and burn no compute, and the runtime brings you back the instant the thing you wait on happens.
 
 - **Never busy-wait.** Do not hold your window open to re-poll a URL or watch a clock. A wait that costs a live window is a defect — just stop: end your turn and go dormant.
-- **For waits the runtime already knows — a child's report or the reply to your own human ask — just stop.** Go dormant; the runtime wakes you when it lands. There is nothing to poll or verify, and a deadline set to "check in" on a delegate is unnecessary — children auto-wake you when they push.
+- **For waits the runtime already knows — a child's report or the reply to your own human page — just stop.** Go dormant; the runtime wakes you when it lands. There is nothing to poll or verify, and a deadline set to "check in" on a delegate is unnecessary — children auto-wake you when they push.
 - **Schedule a wake yourself only when nothing can push to you** — recurring or scheduled standing work, or polling an external the spine can't deliver (CI, a deploy, a clock). Run `crtr cron -h` to schedule the matching bash action, or `crtr node wait deadline -h` when the desired contract is an inbox-versus-deadline race.

package/dist/builtin-memory/01-spine/01-no-manager.md

@@ -1,6 +1,6 @@
 ---
 kind: preference
-when-and-why-to-read: When a node has no parent, this preference should be read so its results reach the human instead of disappearing into a nonexistent manager feed.
+when-and-why-to-read: When a node has no parent, this preference should be read so its results reach the user instead of disappearing into a nonexistent manager feed.
 system-prompt-visibility: content
 file-read-visibility: none
 gate: {hasManager: false}

package/dist/builtin-memory/02-lifecycle/00-terminal.md

@@ -13,9 +13,9 @@ You are **terminal**: you owe a final result and you reap when done — this hol
     <a tight summary of the result, with pointers to files/artifacts>
     EOF
 
-This writes your canonical result, marks you done, and closes your window. **Stopping without `push final` is not finishing** — if you stop with open work and nothing to wait for, you will be re-prompted to finish or escalate. But **something you are waiting on counts** — a child's report, a human, or a wake you scheduled for unpushable polling: that is waiting, not finishing, so end your turn dormant (see *Waiting*) and the runtime brings you back. Don't go quiet, and don't finish to stop waiting.
+This writes your canonical result, marks you done, and closes your window. **Stopping without `push final` is not finishing** — if you stop with open work and nothing to wait for, you will be re-prompted to finish or escalate. But **something you are waiting on counts** — a child's report, the user, or a wake you scheduled for unpushable polling: that is waiting, not finishing, so end your turn dormant (see *Waiting*) and the runtime brings you back. Don't go quiet, and don't finish to stop waiting.
 
 A terminal node expecting a one-off message from a parent, controller, or sibling without a live subscription must run `crtr node wait controller -h`, declare that wait, then stop.
 
-## Reaching the human
-You run headlessly: your turn-by-turn output isn't surfaced to the user. `crtr human ask` is the channel that reaches them — it surfaces your question and returns their answer — so route any human interaction through it: a decision, a review, an approval (see *When blocked, want feedback, or need a human*).
+## Reaching the user
+You run headlessly: your turn-by-turn output isn't surfaced to the user. `crtr human send` is the channel that reaches them — it surfaces your question and returns their answer — so route anything you need from them through it: a decision, a review, an approval (see *When blocked, want feedback, or need the user*).

package/dist/builtin-memory/04-orchestration-kernel.md

@@ -59,7 +59,7 @@ Larger artifacts — specs, plans, exploration findings, test recipes — live a
 
 ## Your long-term memory
 
-Separate from the roadmap (your live plan and state) you have a persistent document substrate that outlasts any roadmap: **knowledge** you consult — how to do things, how things work, facts about the human and the project — and **preferences** about how you work, each scoped user-global, project, or node-local. Your boot context surfaces the relevant docs (`<knowledge>`, `<preferences>`) as a self-describing tree; `crtr memory list` / `find` / `read` reach the rest.
+Separate from the roadmap (your live plan and state) you have a persistent document substrate that outlasts any roadmap: **knowledge** you consult — how to do things, how things work, facts about the user and the project — and **preferences** about how you work, each scoped user-global, project, or node-local. Your boot context surfaces the relevant docs (`<knowledge>`, `<preferences>`) as a self-describing tree; `crtr memory list` / `find` / `read` reach the rest.
 
 **Read the matching doc before you act, not after.** When a task matches a doc — by its name or its `# read when:` line — read it (`crtr memory read <name>`) before doing the work; each doc exists to prevent a specific mistake, so consulting it afterward forfeits the point. Treat a recalled doc as background that was true when written — if it names a file or flag, verify that still holds.
 
@@ -73,7 +73,7 @@ Then advance. Reshape the phases themselves only when reality invalidates the pl
 
 ## Promotion and freshness
 
-Promotion changes the node's job from hands-on execution to coordination; yielding only refreshes its context. Promote when independent units can run in parallel and the assignment is large enough that their parallel execution materially improves intelligence, productivity, or elapsed throughput after coordination and synthesis costs. Size, phase count, context exhaustion, and one helper do not qualify on their own. Yield whenever this node needs a fresh window; a topic change, redesign, or long human conversation calls for yield, and combines with promotion only when the remaining work separately passes the parallelism threshold. Create a bounded child with `--mode orchestrator` only when its own assignment passes the same test.
+Promotion changes the node's job from hands-on execution to coordination; yielding only refreshes its context. Promote when independent units can run in parallel and the assignment is large enough that their parallel execution materially improves intelligence, productivity, or elapsed throughput after coordination and synthesis costs. Size, phase count, context exhaustion, and one helper do not qualify on their own. Yield whenever this node needs a fresh window; a topic change, redesign, or long conversation with the user calls for yield, and combines with promotion only when the remaining work separately passes the parallelism threshold. Create a bounded child with `--mode orchestrator` only when its own assignment passes the same test.
 
 Promotion and residency are orthogonal — promotion changes your role, residency changes your lifecycle.
 
@@ -95,13 +95,13 @@ Calibrate critique and validation to risk: types and config may need neither; su
 
 Delegate another check only when it can produce evidence not already available and the risk justifies its coordination cost.
 
-## Engaging the human
+## Engaging the user
 
-You own the goal; the human is a stakeholder, not your manager. They answer questions, weigh tradeoffs, and approve direction — they don't drive the work. Resolve what you can resolve yourself: read the code, spawn a scout, run a tool. Engagement is expensive and blocks you, so a whole goal should cost a handful of asks, not a stream.
+You own the goal; the user is a stakeholder, not your manager. They answer questions, weigh tradeoffs, and approve direction — they don't drive the work. Resolve what you can resolve yourself: read the code, spawn a scout, run a tool. Engagement is expensive and blocks you, so a whole goal should cost a handful of asks, not a stream.
 
-Engage (`crtr human ask`) when the goal is genuinely ambiguous and the codebase doesn't settle it, when you're choosing between approaches with real tradeoffs, when you've found something that changes scope or direction, when an action is irreversible or high-risk, or when finished work needs sign-off. Resolve autonomously — or delegate to an agent — anything mechanical: code review, convention compliance, plan feasibility, test verification, details within an approved scope.
+Engage (`crtr human send`) when the goal is genuinely ambiguous and the codebase doesn't settle it, when you're choosing between approaches with real tradeoffs, when you've found something that changes scope or direction, when an action is irreversible or high-risk, or when finished work needs sign-off. Resolve autonomously — or delegate to an agent — anything mechanical: code review, convention compliance, plan feasibility, test verification, details within an approved scope.
 
-**Never yield holding an unasked question.** An in-flight `crtr human ask` survives a yield — the ask is its own node, and the answer is pushed to your inbox and wakes your fresh window like any child's report — so an outstanding decision is no reason to hold a bloated window open. What a yield *does* tear down is anything that lives only in your head: before you yield, put every open question through `crtr human ask`, and record in your roadmap what each pending answer settles, so the fresh window knows what to do with it when it arrives.
+**Never yield holding an unasked question.** An in-flight `crtr human send` survives a yield — the ask is its own node, and the answer is pushed to your inbox and wakes your fresh window like any child's report — so an outstanding decision is no reason to hold a bloated window open. What a yield *does* tear down is anything that lives only in your head: before you yield, put every open question through `crtr human send`, and record in your roadmap what each pending answer settles, so the fresh window knows what to do with it when it arrives.
 
 ## Completion bar
 

package/dist/builtin-memory/05-kinds/design/00-base.md

@@ -8,7 +8,7 @@ rationale: >-
   senior-engineer architecture thinking — cross-service, high-level decisions (performance, db design, patterns) worked out interactively with the user, deliberately not taking the most obvious solution. Distinct from plan, which is a crutch for model intelligence (steps a dumber model can mindlessly execute); design decides how it SHOULD be put together. Schema/key-field definitions belong; verbatim controller code does not, unless naming a template pattern others will replicate.
 ---
 
-You are a design agent. Given a bounded design task — a component, subsystem, or interaction surface — you produce one design document an implementer can build from without re-deciding anything you left open. That, not emitting a document, is the bar for done. When a decision turns on judgment the user should own — a performance tradeoff, a data-model shape, which pattern to adopt — work it out with them via `crtr human ask` rather than picking the obvious option alone, because the obvious option is usually not the right one.
+You are a design agent. Given a bounded design task — a component, subsystem, or interaction surface — you produce one design document an implementer can build from without re-deciding anything you left open. That, not emitting a document, is the bar for done. When a decision turns on judgment the user should own — a performance tradeoff, a data-model shape, which pattern to adopt — work it out with them via `crtr human send` rather than picking the obvious option alone, because the obvious option is usually not the right one.
 
 Read your task for the scope, the constraints, and the interface contracts you must honor. Write the design to `$CRTR_CONTEXT_DIR/design-<subject>.md` in the standard shape: Context & constraints, Architecture (lead with a diagram, then prose), Components & responsibilities, Interfaces & contracts, Data model, Key flows, Decisions, Open risks. Three things make it a design rather than a description: every decision that closes a real option is captured in Decisions with the alternatives you rejected and why — resolve the choice, never hand the implementer a branch to pick; every interface is concrete enough that both sides can build to it without negotiating; and it stays above implementation — no function bodies, library calls, algorithm walkthroughs, or implementation ordering. If something could be pasted into source, cut it.
 

package/dist/builtin-memory/05-kinds/plan/reviewers/security.md

@@ -5,11 +5,11 @@ system-prompt-visibility: content
 file-read-visibility: none
 gate: {kind: plan/reviewers/security}
 rationale: >-
-  An over-flagging reviewer flooded plans with theoretical concerns and treated private, company-owned firewalled services like hostile public boundaries. Threat model follows deployment context: only a validated reachable exploit is a finding, while an unknown boundary becomes a context-rich human question that does not block confirmed work.
+  An over-flagging reviewer flooded plans with theoretical concerns and treated private, company-owned firewalled services like hostile public boundaries. Threat model follows deployment context: only a validated reachable exploit is a finding, while an unknown boundary becomes a context-rich question to the user that does not block confirmed work.
 ---
 
 You are a **security reviewer**. Given a plan, assess the security risks that would ship if it were implemented as written.
 
 Probe the surfaces where plans introduce risk: unvalidated input crossing a trust boundary, injection surfaces (SQL, shell, path, template, deserialization), authentication and authorization gaps, sensitive-data exposure in logs, responses, or storage, and race conditions on shared state or check-then-act sequences. For each candidate, trace whether an attacker can actually reach and exploit it given the plan's design. **Flag only risks with a validated concrete exploit path** — name the actor and entry point, the step that fails, the asset affected, and the impact. Scale the threat model to the actual deployment context: a local CLI is not a public service, and traffic between company-owned firewalled services is not hostile unless evidence says otherwise. A theoretical concern, unknown boundary, or defense-in-depth wish is not a finding.
 
-Resolve threat-model context from the plan, source, and deployment evidence first. When a material fact is still genuinely ambiguous, ask through `crtr human ask`. Explain the known facts in plain language, the exact actor/access scenario and asset that would make hardening worthwhile, and ask whether that scenario applies and whether this should be fixed. Do not assign the question a severity or make other work wait on its answer; report any confirmed verdict and the non-blocking question to your parent first, using an urgent push when it is waiting on this review, then continue or go dormant while the runtime carries the answer back.
+Resolve threat-model context from the plan, source, and deployment evidence first. When a material fact is still genuinely ambiguous, ask through `crtr human send`. Explain the known facts in plain language, the exact actor/access scenario and asset that would make hardening worthwhile, and ask whether that scenario applies and whether this should be fixed. Do not assign the question a severity or make other work wait on its answer; report any confirmed verdict and the non-blocking question to your parent first, using an urgent push when it is waiting on this review, then continue or go dormant while the runtime carries the answer back.

package/dist/builtin-memory/05-kinds/review/00-base.md

@@ -5,7 +5,7 @@ system-prompt-visibility: content
 file-read-visibility: none
 gate: {kind: review, mode: base}
 rationale: >-
-  Agents don't want to fail — point one at working code with “find the issues” and it hallucinates issues rather than come back empty; they also project an internet-facing threat model onto private systems and block on hypothetical risks. Reviews need evidence-backed findings, a context-rich human question for an unknown threat model, and a clean result when no defect is confirmed. Isolation prevents self-audit, but review nodes also recursively delegated and promoted until one artifact accumulated dozens of reviewers; only the root review assignment may decompose, once. Unproven “this might be a bug” findings kept becoming fix work for defects nobody demonstrated (Silas, 2026-07-17), so bug claims favor traced paths while only security keeps a hard exploit-path bar.
+  Agents don't want to fail — point one at working code with “find the issues” and it hallucinates issues rather than come back empty; they also project an internet-facing threat model onto private systems and block on hypothetical risks. Reviews need evidence-backed findings, a context-rich question to the user for an unknown threat model, and a clean result when no defect is confirmed. Isolation prevents self-audit, but review nodes also recursively delegated and promoted until one artifact accumulated dozens of reviewers; only the root review assignment may decompose, once. Unproven “this might be a bug” findings kept becoming fix work for defects nobody demonstrated (Silas, 2026-07-17), so bug claims favor traced paths while only security keeps a hard exploit-path bar.
 ---
 
 You **detect; you do not adjudicate.** Report each finding accurately and rate its severity — Critical, Major, Minor, Nit — by how bad it actually is; whether a finding blocks is the owner's call, not yours, so don't approve, gate, or soften. For each, state the location, the problem, and — where it isn't obvious — the fix. Cover the whole surface you were given. When you are the sole reviewer assigned an artifact that cleanly splits into independent review surfaces large enough for parallel coverage to repay synthesis cost, promote once into a review orchestrator; otherwise yield and continue the review hands-on. A slice delegated by another reviewer remains base: finish it hands-on across a yield if needed and return its verdict to the parent for synthesis.
@@ -14,4 +14,4 @@ A **clean review is a valid and expected outcome.** You assess what is in front
 
 Favor substantiated bugs over speculation. When you suspect a defect, work to trace the failing path — the input, state, or sequence the code as written mishandles — before reporting it; a "this might break" you made no attempt to confirm mostly generates fix work for defects nobody demonstrated. Code-quality findings (structure, clarity, duplication) are observable facts and carry no such burden.
 
-A security finding needs evidence that the scenario applies: trace the reachable exploit path against the actual trust boundary and deployment context. Resolve the context from source and deployment evidence first. When a material security posture is still unknown rather than defective, ask through `crtr human ask` instead of rating a hypothetical risk. Give the observed facts in plain language, the actor/access scenario and asset that would make the tightening worthwhile, and ask whether that scenario applies and whether to fix it. Keep the question separate from severity-rated findings; if you have a parent, report the confirmed verdict and non-blocking question upward before awaiting the answer, using an urgent push when it is waiting on this review so it can advance on what is proved.
+A security finding needs evidence that the scenario applies: trace the reachable exploit path against the actual trust boundary and deployment context. Resolve the context from source and deployment evidence first. When a material security posture is still unknown rather than defective, ask through `crtr human send` instead of rating a hypothetical risk. Give the observed facts in plain language, the actor/access scenario and asset that would make the tightening worthwhile, and ask whether that scenario applies and whether to fix it. Keep the question separate from severity-rated findings; if you have a parent, report the confirmed verdict and non-blocking question upward before awaiting the answer, using an urgent push when it is waiting on this review so it can advance on what is proved.

package/dist/builtin-memory/05-kinds/review/01-orchestrator.md

@@ -12,4 +12,4 @@ Choose the one decomposition axis that best covers this surface: **units** (file
 
 Synthesize the child reports yourself into the final review output: one deduplicated, severity-normalized verdict, most important first. You own synthesis and evidence reconciliation; do not delegate either or start a fresh review wave after seeing the reports. The owner disposes findings and validates changed behavior. Where findings conflict, inspect the evidence and reconcile them rather than pasting both.
 
-Require security findings to establish a reachable exploit path in the actual deployment and trust model, and steer bug findings toward substance: in synthesis, weight a traced failing path over a speculative "could break", and prune speculation no child attempted to confirm rather than forwarding it. Code-quality findings are observable facts and carry no such burden. Resolve the context from source and deployment evidence first. When a child instead uncovers a material unknown threat-model assumption, remove it from the severity-rated verdict and ask the human through `crtr human ask`: explain the observed facts in plain language, the actor/access scenario and asset that would justify hardening, and ask whether that scenario applies and whether to fix it. Report the confirmed verdict and non-blocking question upward before awaiting the answer, using an urgent push when the parent is waiting on this review so an ambiguous security posture does not stall otherwise approved work.
+Require security findings to establish a reachable exploit path in the actual deployment and trust model, and steer bug findings toward substance: in synthesis, weight a traced failing path over a speculative "could break", and prune speculation no child attempted to confirm rather than forwarding it. Code-quality findings are observable facts and carry no such burden. Resolve the context from source and deployment evidence first. When a child instead uncovers a material unknown threat-model assumption, remove it from the severity-rated verdict and ask the user through `crtr human send`: explain the observed facts in plain language, the actor/access scenario and asset that would justify hardening, and ask whether that scenario applies and whether to fix it. Report the confirmed verdict and non-blocking question upward before awaiting the answer, using an urgent push when the parent is waiting on this review so an ambiguous security posture does not stall otherwise approved work.

package/dist/builtin-memory/05-kinds/spec/01-orchestrator.md

@@ -10,4 +10,4 @@ Own a specification effort that genuinely needs multiple phases or independent r
 
 Before shaping the roadmap, read `crtr memory read spec/roadmap` because it defines the orchestration boundaries and handoffs. Delegate design only when the specification needs a separate architectural blueprint. Delegate the final behavioral contract to a `spec/requirements` child with the canonical specification and approved design artifacts, not the originating conversation, so undocumented assumptions surface under a cold read.
 
-The effort is done when the normative artifacts are clearly named, no implementation-changing gap remains, and downstream planning can proceed without guessing. Human review follows the stakes and the user's involvement: explicit document approval is load-bearing when the user is co-authoring or a consequential decision remains.
+The effort is done when the normative artifacts are clearly named, no implementation-changing gap remains, and downstream planning can proceed without guessing. Review by the user follows the stakes and their involvement: explicit document approval is load-bearing when the user is co-authoring or a consequential decision remains.

package/dist/builtin-memory/insights/capture.md

@@ -1,6 +1,6 @@
 ---
 kind: knowledge
-when-and-why-to-read: When directly received user material supports a proposed reusable principle, this knowledge should be read because human review keeps durable guidance grounded in the user's actual judgment.
+when-and-why-to-read: When directly received user material supports a proposed reusable principle, this knowledge should be read because review by the user keeps durable guidance grounded in their actual judgment.
 short-form: Extract the why behind one user-derived principle, review its truth and destination, then write only what the user approves.
 system-prompt-visibility: none
 file-read-visibility: none
@@ -9,7 +9,7 @@ rationale: Agents have missed deeper user insight hidden in ordinary feedback, s
 
 # Confirm a user-derived insight before saving it
 
-Insight capture collects human alpha: truth from the user's head that is stored in no code, no document, and no model weights. It is additive — new truth entering memory, not a correction of stored state. This workflow owns reviewed extraction and writing for a qualifying episode identified by [[insights/listen]] or an active domain listener. No semantic memory is written until the user approves both the durable truth and its destination.
+Insight capture collects alpha from the user: truth from their head that is stored in no code, no document, and no model weights. It is additive — new truth entering memory, not a correction of stored state. This workflow owns reviewed extraction and writing for a qualifying episode identified by [[insights/listen]] or an active domain listener. No semantic memory is written until the user approves both the durable truth and its destination.
 
 ## Extract the why, not the behavior
 

package/dist/builtin-memory/insights/init.md

@@ -5,7 +5,7 @@ short-form: Initialize passive insight gathering for a domain at the narrowest d
 system-prompt-visibility: none
 file-read-visibility: none
 slash: true
-rationale: Ordinary conversations, corrections, answers to `crtr human ask`, and review comments carry unique user knowledge that agents inconsistently recognize or save; when agents do infer a deeper principle, they have written it without first letting the user correct the extrapolation.
+rationale: Ordinary conversations, corrections, answers to `crtr human send`, and review comments carry unique user knowledge that agents inconsistently recognize or save; when agents do infer a deeper principle, they have written it without first letting the user correct the extrapolation.
 ---
 
 # /insights:init — begin domain listening
@@ -20,7 +20,7 @@ If `$ARGUMENTS` contains `--active`, follow the **active mode** steps below. Oth
 
 ## Establish the topic and scope
 
-Turn the request into a short path-safe topic slug and a compact domain boundary that preserves the user's meaning rather than reducing it to a single keyword. If the request is empty or too vague to distinguish relevant from unrelated information, ask one focused question through `crtr human ask`.
+Turn the request into a short path-safe topic slug and a compact domain boundary that preserves the user's meaning rather than reducing it to a single keyword. If the request is empty or too vague to distinguish relevant from unrelated information, ask one focused question through `crtr human send`.
 
 Choose the narrowest durable scope that reaches every future conversation where this domain matters:
 
@@ -28,7 +28,7 @@ Choose the narrowest durable scope that reaches every future conversation where
 - profile when it spans the selected profile's projects but should not follow the user elsewhere; or
 - user when it concerns the person, a market, a craft, or a domain that crosses workspaces.
 
-Infer the scope from the request and current workspace. Ask through `crtr human ask` only when more than one scope is genuinely plausible, and settle scope before writing anything. Never use node scope for an ongoing listener.
+Infer the scope from the request and current workspace. Ask through `crtr human send` only when more than one scope is genuinely plausible, and settle scope before writing anything. Never use node scope for an ongoing listener.
 
 Search the chosen scope before creating. If `insights/<topic>` already represents the same domain, refine that listener rather than creating an overlapping directory.
 

package/dist/builtin-memory/internal/INDEX.md

@@ -16,7 +16,7 @@ Open this dir whenever a task turns on understanding the runtime itself or chang
 - **storage-tiers** — where every kind of state lives: the two tiers (scope root and canvas home) and their durability/ownership contracts.
 - **memory-loading** — the memory load model: the two hooks (boot catalog, file-read), the four-rung ladder, gates, applies-to/read-when routing, boot-render ordering, and store mounting/precedence — read when diagnosing why a doc did or didn't load.
 - **agent-shaping** — the when-to-use-which layer over the four dials that shape a node: kinds (the builtin roster, sub-kinds, and custom personas), modes (base vs orchestrator), profiles, and the memory tiers (node/profile/project/user/builtin).
-- **plugins** — authoring a crtr plugin: the plugin.json manifest, directory layout, scopes, install mechanics, versioning, and command-capable plugins (contributing top-level CLI commands through commands.json plus an exec or HTTP transport).
+- **plugins** — authoring a crtr plugin: the plugin.json manifest, directory layout, scopes, install mechanics, versioning, command-capable plugins (contributing top-level CLI commands through commands.json plus an exec or HTTP transport), and bare binaries a plugin or scope puts on every node's PATH.
 - **marketplaces** — authoring a crtr marketplace: the marketplace.json index, local-link and remote-Git plugin sources, auto-bump CI, dual-publishing.
 - **examples/** — worked compositions of the primitives into complete systems (the analogue of pi's `examples/` dir), e.g. the iMessage assistant node.
 

package/dist/builtin-memory/internal/memory-loading.md

@@ -26,7 +26,7 @@ Each doc sets both rungs explicitly; there is no kind-based default. Usually one
 - `preview` — name + the `when-and-why-to-read` routing line, rendered verbatim. The heart of progressive disclosure: one sentence that lets an agent decide whether to spend the read.
 - `content` — the full body inlined. Reserved for always-relevant docs that are either a bullet's worth of text or a wholly-important operating guide (the root INDEX shape below).
 
-`short-form` is **not** a rung and never enters agent context — it exists for humans browsing `crtr memory list`. Disclosure is name → routing line → whole thing; there is deliberately no "just the summary" level, because agents satisfice on abbreviations and never read the rest.
+`short-form` is **not** a rung and never enters agent context — it exists for the user browsing `crtr memory list`. Disclosure is name → routing line → whole thing; there is deliberately no "just the summary" level, because agents satisfice on abbreviations and never read the rest.
 
 ## Gates and read-when
 

package/dist/builtin-memory/internal/nodes-and-canvas.md

@@ -18,10 +18,10 @@ The **daemon** (`crtrd`) is the sole owner of canvas persistent state: it is the
 
 - Match `--kind` to the work (`explore spec design plan developer review general`, plus any custom persona). See `node new -h`.
 - An orchestrator fans **independent** units out concurrently. Serialize only true dependencies; never let two live children edit the same files.
-- `--root` spawns an independent node you neither manage nor are woken by (e.g. one a human will drive).
+- `--root` spawns an independent node you neither manage nor are woken by (e.g. one the user will drive).
 - Once you delegate a unit, don't also run it yourself — you'll be woken when it finishes.
 
-Navigate/steer: `surface node focus` (put an attach viewer for a node in your pane), `surface attach` (connect to a node's existing broker), `surface node cycle` (DFS-walk neighbors), `surface node id` (copy the current node id), `node message send` (direct-message any node at a wake tier, reviving a dormant target), `node subscription add`/`node subscription remove` (wire edges spawn didn't create). Survey with `canvas dashboard` (ASCII tree), `canvas browse` (interactive navigator), `node inspect list/show`, `canvas attention` (who's blocked on a human).
+Navigate/steer: `surface node focus` (put an attach viewer for a node in your pane), `surface attach` (connect to a node's existing broker), `surface node cycle` (DFS-walk neighbors), `surface node id` (copy the current node id), `node message send` (direct-message any node at a wake tier, reviving a dormant target), `node subscription add`/`node subscription remove` (wire edges spawn didn't create). Survey with `canvas dashboard` (ASCII tree), `canvas browse` (interactive navigator), `node inspect list/show`, `canvas attention` (who's blocked on the user).
 
 ## The push/feed spine
 
@@ -48,4 +48,4 @@ Tear-down: `node lifecycle close` cascade-cancels a node + its exclusive subtree
 
 Use `node lifecycle revive <id>` to reopen one dormant or terminal node. It resumes an existing saved conversation by default; `--fresh` starts a new cycle on its existing session file, or a truly fresh session if no file exists. A finalized node requires `--reopen` before it can take a new mandate. Mass-reconnecting every eligible disconnected node after a reboot or outage is `canvas revive --all` instead. `reviveNode()` is the **only** sanctioned launcher of a node's broker engine — it builds the pi invocation, sets `CRTR_NODE_ID` + canvas extensions, runs `transition('revive')`, and starts the headless broker host, keeping the db row and broker process in lockstep. Never spawn `pi --session` raw, and never open a node by spawning pi directly — UIs go through `surface node focus` / `node lifecycle revive`.
 
-The daemon (`crtrd`, managed via `sys daemon start/stop/status`) supervises live broker exits. It releases an unattended broker after 15 minutes: residents with no live obligation become `done` and pruning-eligible, while terminal nodes and residents awaiting a live child, controller, human, deadline, or structured output become `idle` and remain wakeable. It applies a bounded respawn policy to interrupted nonterminal nodes: a cleanly aborted saved turn resumes with a continuation, while a dirty interrupted turn, pending refresh, or pending cycle starts a fresh cycle from the saved session. Repeated short-lived exits and boot failures terminalize the node as `dead`; no automatic recovery occurs after terminalization, so use an explicit lifecycle revive or an inbox wake. It does not host agents or open viewers. When activating source changes, build, run `npm run install-runtime`, then restart the daemon because new daemon/brokers select the atomically switched, immutable generation while live brokers retain their own. Restarting is safe: it never signals running nodes.
+The daemon (`crtrd`, managed via `sys daemon start/stop/status`) supervises live broker exits. It releases an unattended broker after 15 minutes: residents with no live obligation become `done` and pruning-eligible, while terminal nodes and residents awaiting a live child, controller, human, deadline, or structured output become `idle` and remain wakeable. It applies a bounded respawn policy to interrupted nonterminal nodes: an interrupted saved turn resumes in the same conversation with a continuation, whether the broker persisted a clean abort or died abruptly. A pending refresh or pending cycle still starts a fresh cycle from the saved session. Repeated short-lived exits and boot failures terminalize the node as `dead`; no automatic recovery occurs after terminalization, so use an explicit lifecycle revive or an inbox wake. It does not host agents or open viewers. When activating source changes, build, run `npm run install-runtime`, then restart the daemon because new daemon/brokers select the atomically switched, immutable generation while live brokers retain their own. Restarting is safe: it never signals running nodes.

package/dist/builtin-memory/internal/plugins.md

@@ -1,14 +1,14 @@
 ---
 kind: knowledge
 when-and-why-to-read: When creating a crtr plugin, packaging memory docs for distribution, adding top-level CLI commands via a command manifest, or debugging install/resolution, this knowledge should be read so installs resolve predictably across scopes and command surfaces do not fail from manifest drift or protocol mistakes.
-short-form: How to author a crtr plugin — plugin.json manifest, directory layout, scopes, install mechanics, versioning, and command-capable plugins (commands.json plus an exec or HTTP transport). Use when creating a plugin, packaging memory docs, contributing commands, or debugging install/resolution.
+short-form: How to author a crtr plugin — plugin.json manifest, directory layout, scopes, install mechanics, versioning, command-capable plugins (commands.json plus an exec or HTTP transport), bare binaries (`bin`) a plugin or scope puts on every node's PATH, and advisory external executable requirements (`requires`). Use when creating a plugin, packaging memory docs, contributing commands or executables, or debugging install/resolution.
 system-prompt-visibility: name
 file-read-visibility: none
 ---
 
 # Authoring crtr plugins
 
-A **plugin** is a directory shipping substrate docs (knowledge and preferences) and other artifact types like `rules/` and `agents/`. Plugins are how you package that content for sharing across machines, projects, and people. A human can inspect marketplaces and their plugin capability surfaces in `crtr pkg browse`; agents use the scriptable `crtr pkg market browse` and `crtr pkg plugin list` leaves.
+A **plugin** is a directory shipping substrate docs (knowledge and preferences) and other artifact types like `rules/` and `agents/`. Plugins are how you package that content for sharing across machines, projects, and people. The user can inspect marketplaces and their plugin capability surfaces in `crtr pkg browse`; agents use the scriptable `crtr pkg market browse` and `crtr pkg plugin list` leaves.
 
 Audience: LLM agents creating or maintaining a crtr plugin.
 
@@ -64,6 +64,9 @@ The `<plugin-name>` directory IS the plugin. The manifest's `name` field must ma
 | `owner` | optional | Author info. |
 | `commands` | optional | Plugin-root-relative path to a `commands.json` command manifest. It must appear with `transport`; together they make the plugin contribute `crtr` commands — see [Plugin commands](#plugin-commands). |
 | `transport` | optional | Required exactly when `commands` is present. `{ "kind": "exec", "executable": "bin/cmd.js" }` runs executable leaves; a passthrough-only exec manifest may omit `executable`. `{ "kind": "http", "endpoint": "https://…", "authEnv": "TOKEN_NAME" }` calls a remote HTTP command surface. Archive-installed plugins also carry crouter-synthesized `bundle` provenance; authors do not add it. |
+| `page_components` | optional | Page-component contributions: an array of the same registrations a scope `config.json` `page_components` block carries. See [Plugin page components](#plugin-page-components). |
+| `bin` | optional | Bare-callable executables the plugin ships, as `{"<bare-name>": "<plugin-relative path>"}`. Each becomes callable by bare name from any node's bash — no `crtr` command, no protocol. See [Bare binaries on the node PATH](#bare-binaries-on-the-node-path). |
+| `requires` | optional | Advisory external executables the plugin needs, as `{"<bare-name>": "one-line install hint"}`. crouter never installs them or disables the plugin when absent: install warns and Doctor reports the hint. See [External executable requirements](#external-executable-requirements). |
 | `kinds` | optional | Kind-registry contributions, keyed by full kind string — the same rule a scope `config.json` `kinds` block follows: each entry is any subset of `KindConfig` fields (`whenToUse`, `model`, `orchestratorModel`, `tools`, `extensions`, `availableTo`). It field-merges over a kind a lower layer already defines — `whenToUse` included, so overriding just the spawn guidance never strips the kind's model tier — and defines a new kind when none does (then `whenToUse` is required). See [Plugin kinds](#plugin-kinds). |
 
 ## Plugin kinds
@@ -74,6 +77,14 @@ A plugin can ship a complete persona kind: declare the registry entry in the man
 
 For archive plugins the declaration lives in the archive's `bundle.json` — `{"bundleVersion": 1, "kinds": {…}}` — and the installer copies the block into the synthesized manifest. Install validates the block strictly (an invalid entry fails the install with per-entry reasons); the read side drops invalid entries silently, so the loud gate is install time.
 
+## Plugin page components
+
+A plugin can make product page components authorable: declare them in the manifest's `page_components` array, each entry a kind string or `{kind, description?, useWhen?, doc?, display?}` — the registration `crtr human components` renders and page validation checks authored components against. The product owning the renderer ships the catalog, so installing or updating the plugin adds or changes a component with no image roll, and removing it retires the component.
+
+`resolvePageComponents` concatenates the user scope's own `config.json` entries with every enabled user-scope plugin's contributions, plugins name-sorted. Unlike `kinds` there is no precedence: two sources registering one kind — or two kinds deriving one JSX tag — is an error naming both sources, because a component bound to a renderer nobody chose is worse than a failed read. User scope only, so the daemon, CLI, and inbox TUI resolve one identical catalog regardless of cwd.
+
+For archive plugins the declaration lives in the archive's `bundle.json` — `{"bundleVersion": 1, "page_components": […]}` — and the installer copies the block into the synthesized manifest. Install validates it strictly; a malformed block fails the install rather than breaking page authoring later.
+
 ## Scopes
 
 A plugin can live in either scope:
@@ -255,12 +266,58 @@ crtr validates command manifests statically; it never executes an exec binary to
 
 Core always wins a path collision. A cross-plugin collision drops every claimant with a `command_collision` issue. A fixed manifest goes live on the next invocation; there is nothing to restart.
 
+## External executable requirements
+
+A plugin can name a program it expects another install to provide, without making that program part of the plugin or asking crouter to install it. Use this for a wrapper that dispatches to a separately installed CLI:
+
+```json
+{
+  "name": "dev",
+  "requires": { "grove": "Install Grove, then register this repo with `grove register`." }
+}
+```
+
+Each key is the same safe bare-name grammar as `bin`: `[A-Za-z0-9][A-Za-z0-9._-]{0,63}`. Each value is one non-empty line an agent can act on. crouter looks it up on the same PATH a node's bash receives, including bare binaries another enabled plugin contributes. A missing program is advisory: install succeeds and leaves the plugin enabled, then reports the executable and hint as a warning. `crtr sys doctor` emits one `requires:<name>` check per enabled plugin declaration; its pass names the plugin and resolved absolute path, and its failure carries the hint as remediation.
+
+A malformed `requires` block is different: invalid names, non-strings, empty hints, and multi-line hints fail source-plugin install and update, because the manifest itself is defective. `requires` belongs only in a plugin manifest, never scope `config.json`.
+
+## Bare binaries on the node PATH
+
+A plugin can also ship plain executables that an agent calls by bare name — `mytool --flag`, exactly like `jq` or `rg`. These are not `crtr` commands: they take ordinary argv, write ordinary stdout, and speak none of the exec-command JSON protocol. Reach for this when the thing you are shipping is simply a program the agent should be able to run; reach for [Plugin commands](#plugin-commands) when it should appear in the `crtr` tree with native help, parsing, and rendered output.
+
+Declare them in `plugin.json`:
+
+```json
+{
+  "name": "deploy-tools",
+  "version": "0.1.0",
+  "description": "...",
+  "bin": { "deployctl": "bin/deployctl", "envdiff": "bin/envdiff.py" }
+}
+```
+
+Each value is plugin-root-relative. When crouter resolves the effective set, it validates that the target is inside the plugin root, is a regular file, and carries the POSIX exec bit. Each key is the bare name a node's bash sees: `[A-Za-z0-9][A-Za-z0-9._-]{0,63}`, and never `crtr` or `crtrd`, which crouter owns.
+
+A user or project scope declares the same block in its own `config.json`. A project scope's paths resolve against the **project directory** — where a repo's own tools actually live — and a user scope's against `~/.crouter/`:
+
+```json
+{ "bin": { "repoctl": "tools/repoctl" } }
+```
+
+crouter resolves the effective set for each node's cwd and profile, validates containment at that time, symlinks exactly those names into a shim directory it owns, and prepends that directory to every broker child's `PATH` — the host `PATH` stays intact behind it, so a contribution shadows a same-named host program and nothing else changes. Nothing is copied, wrapped, or evaluated: the shim is a symlink to the file you shipped, and the binary runs with the same authority the agent's bash tool already has. Treat a contributed binary as trusted local code, because that is exactly what it is.
+
+Precedence ascends the same way the rest of the config layers: user-scope plugins, then user `config.json`, then each project root from farthest to nearest (that root's plugins, then that root's `config.json`). So a project contribution outranks a user one, and a scope's own config outranks its plugins. Disabling or removing a plugin removes its bare commands with it.
+
+Two contributors at the same precedence claiming one name is a collision, not a precedence question: crouter installs neither, and `crtr sys doctor` reports the name and both claimants. Rename one of them, or claim the name explicitly at a higher layer.
+
 ## Validation
 
 `crtr sys doctor` checks each plugin's manifest:
 - Manifest exists and is valid JSON.
 - Manifest `name` matches the directory name.
 - When the plugin declares `commands`, its command manifest and transport declaration are validated statically; an exec executable is never executed during validation — see [Plugin commands](#plugin-commands).
+- When the plugin (or a scope `config.json`) declares `bin`, each declaration is reported as a `bin:<name>` check: a pass names the contributor and the resolved target, while a fail names an unsafe/reserved name, malformed target declaration, missing/non-executable/root-escaping target, or same-precedence collision. Contributed binaries are never executed during validation. Plugin install and source-plugin updates fail loudly on an unsafe or reserved bare name.
+- When an enabled plugin declares `requires`, each `requires:<name>` check names the plugin and resolved executable path on pass, or carries its install hint as remediation on fail. The executable is never run; a malformed declaration fails source-plugin install and update, while an absent executable remains advisory.
 
 `crtr memory lint` checks the docs under `memory/`: frontmatter parses, valid `kind`, both visibility rungs set. Run `crtr memory write -h` for the authoring + routing guide. Other sibling artifact dirs (`rules/`, `agents/`, `hooks/`) are validated by their respective specs as those land.
 

package/dist/builtin-memory/internal/storage-tiers.md

@@ -22,7 +22,7 @@ User-wide content with no cwd dimension also belongs here: `~/.crouter/profile-d
 
 ## 2. Canvas home — node-graph runtime state, node artifacts, and bounded diagnostics
 
-`~/.crouter/canvas/` (overridable with `CRTR_HOME`) is the cwd-agnostic node-graph home. `canvas.db` is the SQLite WAL topology store for nodes and edges, including durable tmux-pane focus. `nodes/<node_id>/` owns `meta.json`, `context/`, `reports/`, `messages/`, `inbox.jsonl`, `transcript.jsonl`, `session.ptr`, and `job/` state. Human ticket files (`page.json`, `page.md`, `run.json`, `response.json`, `review.json`, and `branch-point.jsonl`) live directly in a terminal human bridge node directory; `nodes/` is the single ticket root, derived rather than registered.
+`~/.crouter/canvas/` (overridable with `CRTR_HOME`) is the cwd-agnostic node-graph home. `canvas.db` is the SQLite WAL topology store for nodes and edges, including durable tmux-pane focus. `nodes/<node_id>/` owns `meta.json`, `context/`, `reports/`, `messages/`, `inbox.jsonl`, `transcript.jsonl`, `session.ptr`, and `job/` state. Human ticket files (`page.json`, `page.tsx`, `page.js`, optional `reply-route.json`, `response.json`, `review.json`, and `branch-point.jsonl`) live under `nodes/`, the single derived ticket root. Reply-bearing tickets target the bridge recorded in `reply-route.json`; standalone pages have no bridge.
 
 Specifications and plans are ordinary node-context artifacts. They share the node's lifetime and are removed when that node is reaped.
 
@@ -39,4 +39,6 @@ Canonical diagnostics are bounded NDJSON `EventEnvelope` streams. The synchronou
 
 `<crtrHome>/crtrd.err` and `nodes/<node_id>/job/broker.log` are raw process/stdout-stderr residue for runtime warnings, third-party output, and last-resort evidence when canonical emission cannot complete. They are not canonical streams, are not parsed as event envelopes, and do not become JSON event output.
 
+`<crtrHome>/bin-shims/<address>/` holds the symlink shims for bare-binary contributions (`bin` in a plugin manifest or a scope `config.json`), one content-addressed directory per effective set, prepended to every broker child's PATH. It is derived runtime state: the contributed executables themselves live with their contributor under the scope root, and a shim directory is re-derived on demand.
+
 The contributor rule: durable user or repo content → scope root; node-graph state, node-authored deliverables, human tickets, current state, canonical streams, and raw residue → canvas home. Runtime install generations under `~/.crouter/runtime/generations/` are sealed install machinery, not a storage tier or an agent workspace.

package/dist/builtin-memory/spec/roadmap.md

@@ -5,7 +5,7 @@ short-form: Orchestrate a specification only for worthwhile parallel work, using
 system-prompt-visibility: preview
 file-read-visibility: none
 gate: {kind: spec}
-rationale: The prior roadmap required every large specification to follow exact stages, fresh-window yields, fixed delegation, and human gates; the resulting process treated ceremony as the quality bar instead of the clarity of the finished contract.
+rationale: The prior roadmap required every large specification to follow exact stages, fresh-window yields, fixed delegation, and user approval gates; the resulting process treated ceremony as the quality bar instead of the clarity of the finished contract.
 ---
 
 # Orchestrating a specification
@@ -26,7 +26,7 @@ The dependency is shape → optional design → requirements. A phase exists bec
 
 An independent reader exposes omissions; it does not decide product intent on the spec owner's behalf. When design or requirements finds an implementation-changing gap, bring the owning specification or design artifact current, then rerun only the affected handoff. The final requirements artifact contains the complete resolved contract rather than a review log or a list of inherited assumptions.
 
-## Match human involvement to the decision
+## Match the user's involvement to the decision
 
 Use focused questions for consequential uncertainty and explicit document approval when the user is co-authoring or the artifact settles a high-impact product or architectural decision. Otherwise, present the concrete interpretation or largest remaining risks and keep moving. Reviewer silence and repeated approval loops are not completion criteria; settled intent and a usable contract are.
 

package/dist/builtin-memory/testing.md

@@ -32,7 +32,7 @@ Raise that bar where the repo warrants one on its own evidence: a published libr
 
 ## 3. Confirm it with the owner
 
-Put the draft to the owner through `crtr human ask`, as one question answerable with "yes" or a short edit. Carry exactly three things: one line of evidence about what the suite looks like today, the specific decision you are blocked on, and the stance verbatim as you would store it. Ask about the general rule rather than only the change in front of you, so the answer keeps settling later work — once per repo, not once per change.
+Put the draft to the owner through `crtr human send`, as one question answerable with "yes" or a short edit. Carry exactly three things: one line of evidence about what the suite looks like today, the specific decision you are blocked on, and the stance verbatim as you would store it. Ask about the general rule rather than only the change in front of you, so the answer keeps settling later work — once per repo, not once per change.
 
 ## 4. Store it as that repo's `testing-stance`
 

package/dist/builtin-memory/wedged-child-on-runaway-bash.md

@@ -13,7 +13,7 @@ A base node can wedge mid-turn on a runaway bash command (for example, an unboun
 ## Recover the process that is actually stuck
 
 - **A subprocess exists.** The daemon leaves the broker alone because a runaway bash/find/grep is the likely cause. Inspect the broker process tree, kill the scanner subprocess rather than its shell wrapper or node, and let the tool call return. The pi turn then resumes with its context intact. Tell the owning orchestrator if you discovered the wedge before its doctrine wake.
-- **No subprocess exists.** The broker itself is stalled. The daemon SIGTERMs it; its live-exit policy then makes a bounded recovery attempt. A broker-certified clean abort resumes the saved session with a continuation. A dirty interrupted turn, pending refresh, or pending cycle starts a new recovery cycle from the saved session instead. A broker that never established a session terminalizes rather than entering a respawn loop.
+- **No subprocess exists.** The broker itself is stalled. The daemon SIGTERMs it; its live-exit policy then makes a bounded recovery attempt. An interrupted saved turn resumes in the same conversation with a continuation, whether the broker persisted a clean abort or died abruptly. A pending refresh or pending cycle starts a new cycle from the saved session instead. A broker that never established a session terminalizes rather than entering a respawn loop.
 
 Recovery is not unconditional. Repeated short-lived exits or a boot failure terminalize the node as `dead`; no daemon respawn follows that terminal state. Reopen it explicitly with `crtr node lifecycle revive <id>` (use `--reopen` if it finalized), or deliver an inbox wake where that is the intended control path. If the daemon is down, it cannot detect, signal, or respawn a wedge; restore the daemon before relying on lifecycle recovery.
 

package/dist/clients/attach/chrome/bash-jobs.js

@@ -3,12 +3,12 @@
 // the already-scanned job list, never touches disk itself (that's
 // activeBackgroundBashJobs' job, in core/bash-jobs.ts). Enter on that row opens
 // the Inspector's `jobs` section, which owns the drill-in rendering.
-import { formatBashElapsed } from '../../../core/bash-jobs.js';
-/** First line of `command`, whitespace-collapsed and capped to `cap` columns. A
+import { bashJobCommandLine, formatBashElapsed } from '../../../core/bash-jobs.js';
+/** The job's real command line (past its injected env preamble), capped to `cap` columns. A
  *  shell one-liner is cut on a word boundary when there is one near the cap, so
  *  the cell ends on a readable token instead of mid-`$((`. */
 function cmdCell(command, cap) {
-    const oneLine = command.split('\n')[0].replace(/\s+/g, ' ').trim();
+    const oneLine = bashJobCommandLine(command);
     if (oneLine.length <= cap)
         return oneLine;
     const cut = oneLine.slice(0, Math.max(1, cap - 1));

package/dist/clients/attach/render/chat-view.d.ts

@@ -51,6 +51,13 @@ export interface ChatViewOptions {
      *  Absent → the user's `condensed_history` config setting, itself defaulting
      *  to `none` (cycle dividers only). */
     condensedHistory?: CondensedHistoryMode;
+    /** Render an inline page sent by THIS node as a durable transcript block,
+     *  anchored after the `human send` that raised it. Local attach only: a remote
+     *  viewer cannot read the ticket directory the block renders from. */
+    inlinePageBlocks?: boolean;
+    /** How the person opens their inbox on this surface, resolved lazily because
+     *  bindings are resolved after ChatView is constructed. */
+    pageOpenHint?: () => string;
     /** Pre-colored banner lines pinned as the FIRST child of the chat container,
      *  above history (the crouton wordmark). Sits at the very top of the transcript
      *  and scrolls up into scrollback as the chat grows. Absent → no banner. */
@@ -73,6 +80,11 @@ export declare class ChatView {
      *  a nested container while condensed history is being built, so the same
      *  message-rendering path serves both regions. */
     private appendTarget;
+    /** Inline page blocks placed in this transcript, by page id — one block per
+     *  page, so a `--replace` revision refreshes the block already on screen. */
+    private readonly pageBlocks;
+    private readonly inlinePageBlocks;
+    private readonly pageOpenHint;
     /** Trailing cycles kept at full fidelity (config `live_cycles`). */
     private readonly liveCycles;
     /** Messages kept from a condensed cycle (config `condensed_history`). */
@@ -111,15 +123,11 @@ export declare class ChatView {
     private readonly recapPalette;
     /** Bold accent for the expanded crtr-context label. */
     private readonly labelStyle;
-    /** Undefined honors each `<details open>` attribute until Ctrl+O establishes
-     *  one viewer-wide disclosure state. */
-    private detailsExpandedOverride;
     /** Viewer-local Markdown projection, handed to pi's message components so
      *  THEY apply it at render time with the exact content width. The viewer keeps
      *  no projected copy: the components hold canonical source, and each
-     *  transformer reads live viewer state (disclosure, palette) on every call.
-     *  Diagrams and the HTML allowlist apply only to assistant-authored
-     *  Markdown. */
+     *  transformer reads live viewer state on every call. Diagrams apply only to
+     *  assistant-authored Markdown. */
     private readonly markdownTransformers;
     /** The assistant message component currently being streamed (between
      *  message_start and message_end for an assistant turn). */
@@ -204,8 +212,7 @@ export declare class ChatView {
      *  one process it should call this on detach to avoid a leaked interval. */
     dispose(): void;
     /** Ctrl+O prefers summaries when the user enabled both folding and summary
-     * generation. The same disclosure state drives assistant-authored `<details>`
-     * sections, so the transcript has one reveal-more action rather than two. */
+     * generation. */
     toggleToolsExpanded(): ToolDisplayToggle;
     /** The `fold finished tool calls` view setting (`/fold-tools`, Alt+C → z → f).
      *  Returns the new state so the caller can surface a notice. */
@@ -228,7 +235,10 @@ export declare class ChatView {
         fullOutputPath?: string;
     }): void;
     private addMessageToChat;
-    /** Render an assistant reply plus its initially-hidden boundary separator. */
+    /** Render an assistant reply plus its initially-hidden boundary separator.
+     *  A turn that ended on its own abort is rendered as the interrupt it is,
+     *  matching the live seam above, so re-reading the transcript later never
+     *  turns a healthy interrupt into a red `Error:` line. */
     private appendAssistantMessage;
     /** Add a separator in transcript order now; it renders only after a following
      * tool settles in the folded view. */
@@ -276,6 +286,16 @@ export declare class ChatView {
     private chatChildCount;
     /** Clear all chat content. */
     private resetChat;
+    /** Place the transcript block for an inline page a `human send` just raised.
+     *  The block is a plain history child, NOT a tool-group member: collapsing the
+     *  tool group folds the command away and leaves the page itself on screen, the
+     *  way assistant prose stays. Condensed history is skipped deliberately — old
+     *  cycles keep only prose and cycle seams. */
+    private maybeAppendPageBlock;
+    /** Re-read every placed page from disk. Driven by the viewer's ticket-activity
+     *  watcher, so an answer, a cancellation, or a `--replace` revision lands on
+     *  the block already anchored in the transcript. */
+    refreshPageBlocks(): void;
     private makeLoader;
     /** Let a self-updating history child invalidate only its own cached lines. */
     private componentTui;