refactor(simulation): scope Drive lifecycle with Effect

[kitlangton]

What

Make OpenCode Drive simulation lifecycle ownership Effect-native across the backend, TUI frontend, renderer, recording timeline, control WebSockets, manifest loading, and simulated provider boundary.

Drive still exercises the real OpenCode model request/response pipeline. Only the provider network boundary is simulated, through a scoped SimulatedProvider service that streams provider response events supplied by Drive.

The screenshot path also bundles Commit Mono in compiled binaries and renders block glyphs geometrically so terminal borders remain continuous.

Before / After

Before: simulation state and control servers were split across process-global route/provider registries and imperative WebSocket ownership. Renderer, recording, pending invocation, and socket cleanup could outlive their run. Compiled screenshot rendering depended on runtime font resolution and block glyph side bearings produced visible seams.

After: each simulation run owns its network routes, request log, provider invocations, bounded queues, control servers, renderer, and recording timeline in one Effect scope. Shutdown interrupts control workers and attachments before renderer/timeline finalization. Drive reconnects replay pending invocations, the latest attached controller replaces the previous one, and consumer interruption releases backpressured provider responses. Compiled screenshots load embedded Commit Mono assets on demand and fill block geometry without gaps.

How

• packages/simulation/src/backend/simulated-provider.ts defines the high-level provider stream service and scoped Drive adapter.
• packages/simulation/src/control-server.ts provides the shared bounded, sequential JSON-RPC WebSocket server used by backend and frontend control surfaces.
• packages/simulation/src/backend/network.ts makes route and log state local to each acquired run and timestamps through Effect Clock.
• packages/simulation/src/backend/openai.ts converts provider response events into schema-checked OpenAI SSE while preserving the real LLM pipeline.
• packages/simulation/src/manifest.ts resolves manifests through Config, FileSystem, and Schema with typed failures.
• packages/simulation/src/frontend/{simulation,renderer,server,actions}.ts scope renderer, timeline, control server, actions, and filesystem writes.
• packages/tui/src/app.tsx acquires Drive rendering through the application Effect scope.
• packages/simulation/src/frontend/png.ts embeds Commit Mono and renders █, ▀, and ▄ as exact cell geometry.

Scope

• Keeps ui as Drive's low-level protocol-compatible control API.
• Does not add a semantic OpenCode-specific Drive DSL.
• Does not add backend LLM convenience commands to the CLI protocol.
• Multiple simultaneous controllers remain out of scope; the latest llm.attach wins.

Testing

• Pre-push monorepo typecheck: 32 packages passed.
• bun test && bun run typecheck in packages/simulation: 19 tests, 57 assertions.
• bun run test && bun run typecheck in packages/server: 9 tests passed after merging current v2.
• bun run test && bun run typecheck in packages/tui: 230 passed, 1 skipped, 0 failed.
• bun run typecheck in packages/cli.
• Real Drive walkthrough verified streamed reasoning/text, screenshots, recording export, provider cleanup, and process cleanup.
• Regression coverage includes late attachment replay, controller replacement, stream interruption, backpressure cancellation, explicit disconnect, malformed JSON, OpenAI SSE encoding, run-local network state, manifest failures, and renderer finalization.

Demo

This screenshot was produced through the compiled Drive screenshot path with embedded Commit Mono and continuous block edges.

Flow

sequenceDiagram
    participant Drive
    participant UI as TUI control server
    participant Backend as Backend control server
    participant Provider as SimulatedProvider
    participant LLM as OpenCode LLM pipeline

    Drive->>UI: ui action / prompt
    UI->>LLM: normal application request
    LLM->>Provider: stream(provider request)
    Provider-->>Drive: llm.request
    Drive->>Backend: llm.chunk / llm.finish
    Backend-->>Provider: bounded response events
    Provider-->>LLM: provider stream
    LLM-->>UI: normal session events
    UI-->>Drive: rendered state / screenshot / recording

Loading