Issue Workflow Lifecycle

This page describes how issue workflow execution is modeled and processed in Sealant.

Goal

Run issue-to-PR work in isolated environments while keeping lifecycle, events, artifacts, and reporting reproducible.

A product/API surface submits issue workflow context and execution preferences.
The control plane validates inputs and persists workflow + execution state.
The system composes execution environment requirements (shared with sandbox composition model).
Worker-side execution runs the workflow and records lifecycle events.
Outputs such as summaries, diff metadata, and pull-request links are persisted.
Product surfaces read structured state for progress and reporting.

@sealant/db
- persists issue workflow entities and execution lineage
- stores execution events, validation results, diff files, summaries, artifacts, and PR links

@sealant/source-integrations
- resolves provider data and access details (GitHub support today)
- supports repository selection/reference handling used by workflow execution

@sealant/workspace-composition
- normalizes execution environment intent
@sealant/os-integration-buildkit
- compiles environment image artifacts
@sealant/workspace-build-queue
- queues build jobs when an execution requires image build orchestration
@sealant/registry-integration
- publishes resulting OCI images
@sealant/runtime-adapters-api
- launches isolated runtime sessions for workflow execution

@sealant/ai-harness-integrations
- provides harness install/launch contracts used when execution runs in a harness-driven sandbox

Issue workflow persistence (in @sealant/db) includes:

This is the core of auditability and reproducibility for issue workflows.

Database-level issue workflow modeling is already substantial.
Runtime and worker orchestration for end-to-end issue workflows is still evolving.
The architecture is intentionally shared with sandbox lifecycle to reduce duplicated execution plumbing.