Data Model and Storage

Planned entities

erDiagram
  %%{init: {"theme":"base","themeVariables":{"primaryColor":"#1e293b","primaryTextColor":"#f8fafc","primaryBorderColor":"#38bdf8","lineColor":"#64748b","attributeBackgroundColor":"#1e293b","attributeTextColor":"#f8fafc"}}}%%
  USER ||--o{ THREAD : owns
  THREAD ||--o{ FILE : contains
  THREAD ||--o{ RUN : has
  RUN ||--o{ ARTIFACT : produces
  THREAD ||--o| SANDBOX_SESSION : maps
  THREAD {
    uuid thread_id
    uuid owner_id
  }
  FILE {
    uuid file_id
    string object_key
    string purpose
  }
  SANDBOX_SESSION {
    string sandbox_session_id
    string executor_base_url
  }

Object model

One MinIO bucket uses threads/{thread_id}/uploads/... and threads/{thread_id}/artifacts/... prefixes. Postgres stores file metadata, ownership, content type, size, creator, and source run. MinIO credentials stay server-side; the product backend mints short-lived presigned URLs after authorization.

Executor persistence

The checked-in executor supports local storage and SQLite metadata behind interfaces. The plan calls for MinioSessionStorage and PostgresMetadataStore, preserving service semantics while making workspaces and job metadata durable across processes.