SmolPaws · OpenHands group · live tracker
SmolPaws SDK-swap board
What we still need to assemble for a live test of the new SmolPaws — the one that runs on the transpiled TypeScript stack instead of the old bespoke runner. Component by component, honest status. The plan is the seven-step migration; this board is where each piece actually stands. Hand-maintained; refreshed when state changes.
Last updated 2026-08-27 · source of truth: beads (epic smolpaws-zlo) + the pins on
smolpaws/smolpaws and smolpaws/openhands-agent main
The one-line status: the engine (transpiled agent-server) is at parity and pinned to upstream
v1.36.0; upstream has since moved to v1.44.0, so the pin needs to walk forward
eight release intervals (one bounded PR each, built by sibling agents on the Daytona cabin). The Slack
paws bridge — the low-risk guinea pig for the cutover — is substantially built. The new WhatsApp
bridge is the last big piece and hasn't started. Nothing is live-swapped yet; WhatsApp still runs the old stack.
Components needed for a live test
Each row is a thing that has to work before we can run the new SmolPaws end-to-end. Ordered roughly by the cutover sequence — engine first, one channel to prove it, then the primary channel.
| Component | What it is | Status |
|---|---|---|
| Transpiled agent-server the engine |
Upstream openhands-agent-server rebuilt in TypeScript, running on the new SDK.
Routers, services, sockets, OpenAPI all ported; CI green.
smolpaws-b1r |
✓ at parity |
| SDK pin currency keep up with upstream |
Both repos pinned to upstream v1.36.0 (56ac317). Upstream is now
v1.44.0 — eight release intervals to walk forward, one bounded PR each, built by
sibling agents on the Daytona cabin.
next: v1.36.0 → v1.37.0 |
◐ 8 intervals behind |
| Delivery queue / turns upstream-compatible |
The design that replaces the old bespoke "turns" with an upstream-shaped delivery queue, plus the written cutover + rollback plan. smolpaws-b1r.20 b1r.24 | ◐ design |
| Message Relay + Dispatcher durable, shared |
One SQLite-backed coordinator outside the agent-server that every bridge accepts/delivers through.
Implementation exists (src/coordinator/messageRelay.ts, outbound relay) and drives the Slack app.
message-work ADR |
◐ in progress |
Slack bridge pawsthe guinea pig |
Standalone Slack Socket Mode app (apps/slack, v2.0.0) on the Relay + Dispatcher path — the
low-risk channel we prove the new stack on before touching WhatsApp. Adapter, handler, live canary present.
smolpaws-c6q c6s |
→ prove end-to-end |
| New WhatsApp bridge the primary channel |
Today WhatsApp is the root process in src/, not a bridge. Needs to become a real
apps/whatsapp adapter around the Relay, carrying its extra concerns (SQLite store,
scope/permission model, scheduler, media). Not started.
smolpaws-kxa · kxa.1–.5 |
○ not started |
| Other bridges Discord · Email · GitHub |
Scaffolded under apps/ (adapters + dispatch), riding the same agent-server. Not on the
critical path for the first live test. |
◐ scaffolded |
| Slack-via-Chrome (heartbeat) the lifeline reader |
The daily heartbeat reads Slack through the browser Web API, not the agent-server — so the swap should not touch it. Confirm once the new stack is live. | ✓ unaffected |
The transpile pin, interval by interval
The engine advances one upstream release per bounded PR. SDK repo first, then the agent-server re-vendors + ports the same interval. Both currently sit at v1.36.0.
| Interval | SDK openhands-agent | Server smolpaws vendor |
|---|---|---|
| … → v1.36.0 (56ac317) | ✓ merged | ✓ merged |
| v1.36.0 → v1.37.0 (next) | → next | ○ after SDK |
| v1.37.0 → v1.44.0 (catch-up) | ○ 7 more | ○ 7 more |
Sibling agents run the bounded "hash-interval" prompt on the Daytona cabin (red/green, PR no-merge). Merges are Engel's call.
The honest read: the engine is done and correct — the real remaining work is (1) walking the
pin forward eight releases so we're current with upstream, and (2) the message-delivery spine: finish the Relay +
Dispatcher, prove it through the Slack paws guinea pig, then build the new WhatsApp bridge and swap
it in with a rollback path. Nothing is live-swapped yet; the primary WhatsApp cat still runs the old stack, which
is the whole point of proving on Slack first.