f0410d592d
The web host now composes the sandboxed product path (sandbox-local + sandbox-policy behind bash-sandbox/fs-sandbox, with user-approval and permission on top); BootHostOptions.sandbox carries the deployment defaults (workspace-write + ask). createApiProxy owns the approval pending registry: a ctx.approval ask becomes an answerable approval/requested mux frame with a stable rpcId, replayed verbatim on every mux open until settled; respond routes by the echoed rpcId, validates the ApprovalResponsePayload audit correlation, and broadcasts approval/resolved; the ask's abort signal withdraws the question as cancelled. session.permissions / session.setPermission project ctx.permission into a protocol-owned PermissionOption select; idle switches are held last-write-wins and flushed into the next prompted turn (the ACP bridge's anchoring pattern). The shared hasOpenTurn fold moved to dsh-session, deduplicating the private copies in user-approval, the ACP bridge, and the proxy. Client, per the designer draft: a pending approval takes over the composer (ApprovalPanel replaces the InputBar — amber strip, justification headline, paired command, one-shot refuse/allow, keyed by rpcId so a queued second approval remounts live; the resolved frame restores the composer); the sidebar session row shows an amber waiting-approval dot that outranks the running ring (manager-tracked approvalId set, idempotent under mux-open replays, cleared per connection generation, lit for uninstantiated sessions too); the permission selector is a composer bottom-row chip over an invisible native select, with a presentation-only title-case transform (workspace-write renders as Workspace Write; wire names untouched). Question placeholders stay in the message flow. The connection fixture mirrors the host behavior for keyless browser acceptance.
core/ — product API spine
The session log, system-prompt assembly, tool registry, agent vocabulary, and concrete loop that form the harness's default control spine. These are product packages — the stable surface plugins and consumers build against.
| Package | Role | ctx key |
|---|---|---|
scope/ |
Scoped-context registration primitive (scope tags, scope-filtered dispatch) | (library — no ctx key) |
session/ |
Event-sourced session log + in-memory store | ctx.sessions |
system-prompt/ |
Prompt-section + tool-schema assembly registry | ctx.systemPrompt |
tools/ |
Scoped tool registry + pre-policy, guards, around-dispatch, post-policy, and final-result observation | ctx.tools |
agent/ |
Agent interface, live registry, process-local initiator scope, agent/* event vocabulary |
ctx.agents |
agent-loop/ |
Concrete plugin implementing the public Agent contract and owning the loop driver |
ctx.agentLoop |
scope/ is the one non-service package here: a dependency-free library (createScope/scopeOf/scopeTarget) the registries and the loop build per-agent scoping on — it sits below session/ and system-prompt/ in the module graph precisely so they can consume it without a cycle.
agent-loop is the one concrete implementation of the agent seam and lives here because it is the harness's default product loop. It runs each driver inside ctx.agents.withInitiator(). Extension plugins depend on agent, including when they need the initiating Agent, and never on agent-loop directly, so the loop stays swappable.
The default composition that wires this spine into a runnable agent lives in examples/agent-spine-demo: one bundle plugin that loads the control spine plus selected default capabilities (timer + llm + sessions + fallback session titles + system-prompt + tools + agents + invariants + the local skill family + tool-bash + workspace-context + agent-loop) and forwards agent-loop's agents list as its own config. It sits in examples/ — ready-to-run demo/reference bundles — not in core/: core/ ships the swappable spine pieces, while a demo bundle picks one concrete composition of them and adds a front door.