SmolPaws · OpenHands group · live tracker

SmolPaws SDK-swap board

Where the SDK swap actually stands. The seven-step migration plan mapped to the real work — beads (bd) and PRs — so this group has one glanceable to-do instead of re-deriving it each time. Hand-maintained; refreshed when state changes.

Last updated 2026-07-13 · source of truth: beads in the smolpaws / openhands-agent repos + the message-work ADR

The swap, step by step

1. Swap in openhands-agent for the old SDK → next

   Point the server at @smolpaws/openhands-agent instead of the old @smolpaws/agent-sdk — the new SDK becomes the engine. Doing this first surfaces exactly what the server actually relies on, which then scopes step 2. Not begun; the SDK it depends on is landing (dispatcher merged, persistence in review).

   unblocks: scope of step 2
2. Agent-server parity (ish) ◐ in progress

   Transpile the upstream openhands-agent-server to TS so the new SDK has a server to run on. First slices landed — event/conversation routers, event & conversation services, pubSub, sockets, OpenAPI, plus bash/git/file routers. Durability now flows through the SDK's EventLog (server is a thin wrapper, like upstream). Still ahead: remaining routers (P2/P3) and one narrow deterministic-append extension; external queue state stays out of this package.

   pkg: smolpaws/packages/openhands-agent-server verified green: 227 SDK tests · server build/test/openapi ✓
3. Build durable message work around agent-server ◐ ADR proposed

   The seam is chosen: one shared SQLite-backed Message Work Coordinator in the bridge runtime, outside agent-server. Adapters compute lanes and accept/deliver through it. For webhook ingress, Cloudflare Queue is an edge spool; a local HTTP-pull adapter acknowledges only after SQLite acceptance. No webhook tunnel is required.

   message-work ADR + crash matrix coordinator/store implementation: not started existing BaseBridgeAdapter: transport seam, not coordinator smolpaws-e4j · -109 · -7dj · -6qo
4. Swap agent-server + WhatsApp (keep the lifeline) ○ not started

   Smallest end-to-end slice: migrate the legacy WhatsApp SQLite/poll monolith into a platform adapter around the coordinator, preserving individual message boundaries. Everything after this happens with the lifeline intact.

   depends on: steps 2–3
5. Then Discord, GitHub, Email ○ not started

   Migrate each transport onto the same coordinator seam. Discord already uses the base adapter; Slack is half-migrated; GitHub already has a CF Queue but its Worker consumer still calls the runner; email dispatches directly. GitHub/email become Worker → Queue → local pull adapters, while connected transports stay local.

   smolpaws-3iy GitHub webhook dedup smolpaws-z3l whitelisted-thread listen
6. Slack-via-Chrome should keep working untouched ○ verify later

   The heartbeat Slack reading goes through the browser, not the agent-server, so the swap shouldn't touch it. Confirm once the new stack is live.

7. Retest / adapt / redeploy paws (standalone Slack app) ○ not started

   The separate Slack bot app rides the agent-server via the bridge adapter. Not in active use yet, but it will be; it goes last and carefully.

   smolpaws-c6q Slack ingress smolpaws-c6s Socket Mode delivery smolpaws-c6r / c6t / c6u scaffold · context · ops

Transpile PRs & sub-work

PR #2 currently addressing a fresh AI-review round (lock edge cases). Nothing merged past #1 — merges are Engel's call.

Surrounding backlog (in this group, not the swap itself)

Real work tracked in beads that lives in the OpenHands group but sits outside the migration chain. Grouped, not sequenced.