Wayfinder map: bb 全栈上 Cloudflare Workers（server+frontend+worker agent provider） #1

Destination

A locked, sequenced build plan for moving bb's frontend + server onto Cloudflare Workers and shipping a first-party worker agent provider (agent loop in a Durable Object on workerd, tool execution on enrolled machines via host RPC — zero container). The plan resolves every architectural decision needed before implementation tickets can be written: server-on-Workers (D1/DO) cutover design, the worker-agent loop specification, the daemon tool-exec command surface, and the bb↔worker-agent bridge protocol shape. Exit criterion: no remaining open decision tickets; the map's Decisions-so-far is sufficient for someone to write execution tickets.

Notes

• Domain: bb monorepo (apps/server, apps/app, apps/host-daemon, apps/connect, apps/ai-gateway, packages/{db,agent-runtime,provider-bridge-protocol,host-daemon-contract,tunnel-contract,plugin-sdk}). Evidence base for current state: upstream/main @ c65a47f, read-only worktree /tmp/bb-upstream-main (gone on reboot — re-create with git worktree add --detach /tmp/bb-upstream-main upstream/main).
• Analysis sessions 2026-10-02 established: (1) app is a same-origin Vite SPA served by the server — Workers Static Assets with the server on the same worker domain needs zero app code changes; (2) server is Node-bound at better-sqlite3 (packages/db/src/connection.ts), NotificationHub in-memory maps (ws/hub.ts), periodic sweeps, and secret-file storage; (3) provider model is artifact/plugin-based with digest-verified bridge artifacts spawned per-process over stdio JSONL JSON-RPC v2 (PROVIDER_BRIDGE_PROTOCOL_VERSION = 2), HOST_DAEMON_PROTOCOL_VERSION = 224 on upstream; (4) Cloudflare precedents already in repo: apps/connect TunnelDO + tunnel-contract binary frame muxing, apps/ai-gateway (D1 + cron + rate limiter), apps/web (TanStack Start full-stack on Workers), packages/connect-db (drizzle on D1 + wrangler d1 migrations), plugins/environment-modal-sandbox (machine-provider plugin precedent).
• Core product idea (user, 2026-10-02): the worker agent is a network provider — loop runs in a DO, tool calls route server → enrolled host daemon (existing host.* onlineRpc commands), daemon stays a pure tool executor. ProviderId and environmentId are already separate axes in the data model.
• Constraints: daemon is outbound-WS only (no inbound listeners); workerd has no fs/pty/child_process; RTT budget for tool calls through server ~20-100ms per call; HOST_DAEMON_PROTOCOL_VERSION bumps are required for any daemon wire change; repo convention is one commit per describable behavior with tests in the same commit.
• Sessions should consult skills per ticket labels; grilling tickets are HITL with the repo owner.

Decisions so far

Not yet specified

• Server-on-Workers internals once SQLite→D1 and hub→DO are decided in principle: migration of ws/hub.ts lease/heartbeat/coalesce timers to DO alarms, per-server vs per-host DO topology, D1 schema/migration cutover plan, R2 for plugin artifacts, secret-file replacement. Graduate after the "server on Workers?" decision.
• Worker agent loop specifics once the loop model is chosen: tool schemas, compaction, permission gating, streaming shape, cost/turn limits, delta grammar production. Graduate after the loop tickets resolve.
• bb connect integration shape: whether worker agents register as servers/machines in connect-db or ride a separate auth path.
• Provider-side capability story: how a worker agent declares permissionModes/fork/archive/rename given no CLI underneath.
• Rollout/compatibility: how a mixed fleet (local daemon + cloud server + worker agents) behaves while server is mid-migration.

Out of scope

AGENT GENERATED: by newapi/kimi-k3