Promote conversational surface to core: /chat/ws + ChatSession DO + terminal CLI

[stackbilt-admin]

Why

The AEGIS terminal client (Phase 0 CLI, daemon aegis#629) and its backend live entirely in the daemon, so downstream @stackbilt/aegis-core consumers get no conversational surface and no CLI. Core only exposes a /chat stub page (web/src/auth.ts:9, web/src/dashboard.ts:505) — no WebSocket, no Durable Object.

Same daemon→core porting pattern as #34 (grounding-layer) and the kernel-shadow collapse (daemon aegis#436/#437): capabilities that every variant should inherit belong in core, not forked in the daemon.

Current state (daemon-only)

• web/src/routes/chat-ws.ts — GET /chat/ws WebSocket upgrade (subprotocol aegis-chat)
• web/src/durable-objects/chat-session.ts — ChatSession DO (streaming kernel dispatch, per-user conversation history); exported from daemon index.ts:267
• web/src/durable-objects/chat-session-auth.ts — auth gate
• cli/aegis.mjs — zero-dependency terminal REPL over /chat/ws (now with banner + executor picker + spinner); cli/README.md specs the Phase 1/2 local-actuator roadmap

Core (@stackbilt/aegis-core) has none of these.

Proposal

Phase A — promote the server surface into core. Move chat-ws route + ChatSession DO (+ chat-session-auth) into aegis-core so createAegisApp() wires /chat/ws and the DO export. Consumers add the DO binding + migration in their wrangler.toml and get a streaming conversational endpoint for free. The DO drives dispatch() (already core), so this is mostly relocation + a binding contract. Coordinate with the kernel-shadow collapse so the daemon's copy is removed, not duplicated.

Phase B — ship the terminal client. Port cli/aegis.mjs as either cli/ in this repo or a published @stackbilt/aegis-cli (zero-dep, generic over any aegis-core deployment's /chat/ws via AEGIS_HOST/AEGIS_TOKEN). It's already deployment-agnostic — the only coupling is the endpoint contract (/chat/ws, aegis-chat subprotocol, message/start/delta/done/error frames), which Phase A makes a core contract.

Later — actuator (Phase 1/2). Local agent loop + local tools + the WS tool_call/tool_result extension (see daemon cli/README.md). Out of scope here; tracked once A/B land.

Acceptance

A fresh @stackbilt/aegis-core consumer that adds the DO binding gets a working /chat/ws and can drive it with the aegis CLI — no daemon-specific code.

Notes / risks

• DO requires a wrangler.toml binding + migration in each consumer — document the contract.
• Auth gate (chat-session-auth) must travel with the route.
• /chat/ws frame schema becomes a stability contract once core-owned; version it.
• Daemon keeps its richer surfaces (/console, /overworld, /lite) on top; only the base chat-ws + DO + CLI move.

Filed by AEGIS. Reference implementation + Bildy-style CLI are live in the daemon (aegis#629); this tracks promoting the reusable core of it to OSS.

[stackbilt-admin]

Phase A is landed in #57.

Done:

• /chat/ws core route mounted in both standalone Worker and createAegisApp()
• ChatSession Durable Object exported for Worker bindings
• conversation UUID validation and D1 ownership guard
• optional client eventId dedup through web_events
• history, start, delta, done, and error WebSocket frames
• grounded metadata included in stored/returned assistant metadata
• Wrangler DO binding/migration and existing-D1 user_id migration docs
• focused route/auth/DO tests

Validation:

• npm run typecheck
• npx vitest run tests/chat-session.test.ts tests/chat-session-auth.test.ts tests/chat-ws.test.ts
• npm test
• Charter CI and Test & Typecheck CI passed on feat: add chat session websocket primitive #57

Leaving this issue open for Phase B: terminal CLI/demo packaging and any demo-path trust hardening needed before launch.