Drop 9 batch proposals that are superseded by the boocode-lift-analysis (boocontext-audit, conductor upgrades, self-healing/verify-gate skills): add-3tier-memory, import-llm-evaluator, import-pregel-engine, plugin-platform, conductor-evolution, code-intelligence-upgrade, dev-workflow, ui-overhaul, agent-reliability. Delete 11 stub archive files (49-66B each, 'Status: Shipped. Archived.' only) that provide zero documentation value over the existing CHANGELOG.md + git tags.
2.2 KiB
2.2 KiB
ADDED Requirements
Requirement: IWorkflowStore interface
All storage backends SHALL implement the IWorkflowStore interface providing run lifecycle, event persistence, and node output retrieval.
Scenario: Store provides run CRUD
- WHEN a workflow run is created
- THEN
createWorkflowRun()SHALL persist the run and return it - WHEN a workflow run status is updated
- THEN
updateWorkflowRun()SHALL persist the status change
Scenario: Store provides event persistence
- WHEN a workflow event is created
- THEN
createWorkflowEvent()SHALL append it to the event log
Scenario: Store provides completed node outputs
- WHEN a workflow is resumed
- THEN
getCompletedDagNodeOutputs()SHALL return all completed node outputs keyed by node ID
Requirement: Filesystem backend
The filesystem backend SHALL store each workflow run as files in a directory: {artifactsDir}/{runId}/.
Scenario: Filesystem stores events as JSONL
- WHEN events are created using the filesystem backend
- THEN each run SHALL have
events.jsonlwith newline-delimited JSON - THEN node outputs SHALL be stored as individual JSON files
Scenario: Filesystem stores run metadata
- WHEN a run is created using the filesystem backend
- THEN
run.jsonSHALL contain the run metadata
Requirement: SQLite backend
The SQLite backend SHALL store workflow data in a SQLite database with tables for runs, events, and node outputs.
Scenario: SQLite stores runs table
- WHEN using the SQLite backend
- THEN a
workflow_runstable SHALL exist with columns for id, workflow_name, status, user_message, created_at, updated_at
Scenario: SQLite stores events table
- WHEN using the SQLite backend
- THEN a
workflow_eventstable SHALL exist with columns for run_id, sequence, event_type, timestamp, payload
Requirement: Postgres backend
The Postgres backend SHALL use a PostgreSQL database with the same schema as SQLite, accessed via the IWorkflowStore interface.
Scenario: Postgres uses same interface
- WHEN switching from SQLite to Postgres
- THEN no workflow engine code SHALL change — only the store implementation