Roadmap

Verified live

• ✓Durable approval — approve, deny, approve-with-edit
• ✓Cascade-skip (two pending items in one batch, one denied → sibling auto-skipped)
• ✓Durable question (system_ask_user) end to end
• ✓DeepSeek reasoning_content round-tripped through multi-turn tool-calling resumes

Next up

• Wrong-kind guard, live

  Hitting /pending-approvals/:id/resolve for a question's pendingId (or vice versa) — the 400 path exists in code, never actually exercised.

• editedArgs validation-error path, live

  A malformed edit should leave the checkpoint untouched and retryable — only the valid-edit happy path has been run for real.

• Redis-backed checkpoint/session store, live

  Everything verified so far used the file-backed store. RedisCheckpointStore/RedisSessionStore are unit-tested in isolation, not exercised end to end (webhook → Redis checkpoint → resolve → resume).

Known gaps, deliberately open

• Slack / Lark notifier channels

  SlackNotifier / LarkNotifier have never hit a real Slack or Lark app — reasoned through against documented API shapes only.

• Email magic-link channel

  Code reviewed and explained, never actually sent or clicked live.

• Anthropic extended-thinking support

  Deliberately deferred — no ANTHROPIC_API_KEY available to test against. Anthropic's thinking block needs a signature field preserved byte-for-byte, a stricter contract than DeepSeek's plain reasoning_content string.

• Magic-link revocation

  Email approval/answer links are time-bound (signed, expiring token) but not actively revocable — if a decision is made through another channel first, the other link still exists until it expires.

• Per-agent webhook discovery for a background dispatcher

  How a cron/queue worker calling runAgent() directly (no adapters/http.ts in the picture) discovers which webhook target to use, if it wants one different from the live HTTP path's own default. Treated as ordinary application wiring, not a protocol concept — untested because no real dispatcher has been built yet.