[jinxi97]

Second PR of the task API, on top of #215 (merged), which added tasks to the store.

Routes

Route	Does	Answers
POST /v1/tasks	Creates a session on the agent config and starts its run with the task's content, in one store transaction (createTask)	201 with the task, including the sessionId it started
GET /v1/tasks/:id	Reads the task back	200, or 404 if the task is unknown or in another namespace
POST /v1/tasks/:id/cancel	Forwards to the session's requestCancel	202, 404 as above, or 409 if the session is archived

• Body of POST /v1/tasks: { namespace?, agentConfigId, agentConfigVersion?, content, metadata? }.
  • namespace defaults the same way it does on sessions.
  • content can be a plain string or an array of content blocks, like a session message's.
• Errors match POST /v1/sessions: 400 for an unknown or foreign config or version, 409 for an archived config.
• The task's session is ordinary. Follow-up messages, entries, usage and archive all work under /v1/sessions/:sessionId.

Also

• The string-or-array content handling that POST /v1/sessions/:id/messages did inline moved to common.ts (WireContent). Tasks and messages now share it, and the message route behaves the same as before.
• New README section, "Tasks", with a curl example.

Tests

• apps/api/test/tasks.test.ts, run over the real store (PGlite + the pg adapter), checks:
  • the session, its first entry and its ready item after a create
  • a plain-string content, the default namespace, and an explicit version
  • a follow-up message to the session queues
  • 400 for an unknown, foreign or bad-version config, and for missing or malformed content
  • 409 for an archived config
  • 404 for an unknown or foreign task on read and on cancel; a foreign cancel leaves the owned task's log alone
  • cancel appends a control entry, and gets 409 once the session is archived
• pnpm typecheck, pnpm format:check and pnpm test pass.

🤖 Generated with Claude Code