Skip to content

Store WorkflowRuns and filtered journals in SQLite #291

Description

@taras

Story

As a workflow user, I want a WorkflowRun and its filtered journal retained in one local SQLite database, so another process can find the run by ID and resume from durable data rather than an agent transcript or Git sidecar ref.

Scope

Build the first production persistence boundary from the identity contract merged in #289 / PR #341.

Each WorkflowRun owns one SQLite database. This issue owns:

  • creation and lookup by public run ID;
  • immutable definition identity, base pin, normalized props, execution attempts, status, and stop reason;
  • append and replay of already-filtered durable journal events;
  • schema versioning and explicit compatibility errors; and
  • the storage interfaces used contextually by shared production code.

The database is the physical retention boundary for later versioned filesystem roots, Repository/Worktree metadata, and Agent-session mappings, but those remain logical stores implemented by their own stories. Arbitrary Workspace file content is not journal or training data merely because it shares a database file.

No required state lives only in an Agent transcript, process memory, branch name, document path, or refs/xmd/runs.

Acceptance

  • A host-generated or authorized caller-selected run ID creates exactly one WorkflowRun.
  • A later process finds the run by ID without consulting the document path or current Git branch.
  • Definition identity, base pin, normalized props, attempts, status, and stop reason survive restart.
  • Filtered journal entries append and replay in order with stable event identity.
  • Existing journal secret filtering runs before insertion; this story adds no second filtering policy.
  • Schema mismatch or corrupt storage fails explicitly and never creates an empty replacement while claiming continuation.
  • Shared modules use contextual storage APIs and contain no SQLite or runtime detection.
  • Tests cover creation, compatible lookup, incompatible ID reuse, restart, append failure, corruption, and concurrent ownership attempts.

Intentionally excluded

Dependencies

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions