You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make a story the durable owner of conversation, workspace, engine sessions, Git state, and agent turns.
Domain model
The new model needs records for:
stories and their external issue or pull request identity
workspaces and their compute and volume references
conversations and ordered messages
native engine sessions
agent turns
artifacts such as commits, pull requests, screenshots, and reports
attention items raised by a waiting agent or recoverable system failure
idempotency for user requests, webhooks, and scheduled triggers
A story can come from an issue, a pull request event, an ad hoc request, or a recurring agent. A recurring agent without an issue gets a stable story keyed by project, agent, and trigger.
State rules
Only one workspace is current for a story. Only one turn can run at a time. Messages that arrive during a turn are queued in a visible order.
Story states are ready, working, attention, review, done, and archived. Workspace states are creating, running, sleeping, error, deleting, and deleted.
Merge can move a story to done. Archive changes visibility and can be reversed. Neither state transition deletes durable data.
Every turn records the selected agent and the resolved engine, model, manifest commit, and manifest hash. Every native session belongs to the workspace and remains addressable after another agent or model runs.
A turn result of needs_attention opens an attention item with a typed reason and message. Setup, runtime, engine, and preview failures open typed failure items. A successful retry resolves its failure item. A human reply resolves an agent-waiting item when the next turn starts. MCP and the UI may dismiss an item, but its creation and resolution remain in story history.
Concurrency and recovery
Use transaction-backed idempotency and a story lock. Repeated start calls return the same story and workspace. Repeated schedule or webhook delivery creates one turn. If a process dies after saving the user message, the worker can resume or mark that turn failed without dropping the message.
Acceptance criteria
Concurrent starts for the same external story return one story and one workspace.
A recurring trigger resolves to one stable story across several scheduled executions.
The model prevents two active turns for one story.
Queued messages remain ordered and visible to MCP and the UI.
Agent, model, engine, manifest revision, and native session references are stored per turn.
Changing agent or model leaves prior sessions addressable.
Agent waits and recoverable failures create typed attention items; reply, retry, and dismissal follow the stated resolution rules without deleting history.
Merge and archive do not create a storage deletion job.
Restore opens the same conversation, worktree, and engine sessions.
Only the explicit delete command can move a workspace into deletion.
Cross-project reads and writes fail without revealing story metadata.
Unit tests cover every state transition and invalid transition.
Goal
Make a story the durable owner of conversation, workspace, engine sessions, Git state, and agent turns.
Domain model
The new model needs records for:
A story can come from an issue, a pull request event, an ad hoc request, or a recurring agent. A recurring agent without an issue gets a stable story keyed by project, agent, and trigger.
State rules
Only one workspace is current for a story. Only one turn can run at a time. Messages that arrive during a turn are queued in a visible order.
Story states are
ready,working,attention,review,done, andarchived. Workspace states arecreating,running,sleeping,error,deleting, anddeleted.Merge can move a story to
done. Archive changes visibility and can be reversed. Neither state transition deletes durable data.Every turn records the selected agent and the resolved engine, model, manifest commit, and manifest hash. Every native session belongs to the workspace and remains addressable after another agent or model runs.
A turn result of
needs_attentionopens an attention item with a typed reason and message. Setup, runtime, engine, and preview failures open typed failure items. A successful retry resolves its failure item. A human reply resolves an agent-waiting item when the next turn starts. MCP and the UI may dismiss an item, but its creation and resolution remain in story history.Concurrency and recovery
Use transaction-backed idempotency and a story lock. Repeated start calls return the same story and workspace. Repeated schedule or webhook delivery creates one turn. If a process dies after saving the user message, the worker can resume or mark that turn failed without dropping the message.
Acceptance criteria