chore(openspec): drop 9 superseded proposals + 11 stub archive files

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.

openspec/changes/archived/2026-06-07-hybrid-workflow-engine/specs/storage-backends/spec.md

@@ -0,0 +1,48 @@
+## 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.jsonl` with 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.json` SHALL 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_runs` table 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_events` table 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