Skip to content

[0.12] Store stories, conversations, worktrees, and engine sessions #276

Description

@adrian-lorenzo

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:

  • 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.
  • Postgres integration tests cover concurrent start, concurrent messages, webhook replay, schedule replay, and delete isolation.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions