refactor(workflows): unify workflow state with the RuntimeEvent stream

[lespaceman]

Problem

The workflow state machine (`idle → starting → running → completing → done`, ~2.4k LOC in `src/core/workflows/`) is persisted as a separate state stream from `RuntimeEvent`s. The SQLite schema has both:

• `runtime_events` / `feed_events` — the canonical event log, replayed by `FeedMapper.bootstrap()` on resume.
• `workflow_runs` — workflow metadata and `latest_state` snapshots, written via `persistRunState(snapshot)` from `workflowRunner`.

On resume, `useWorkflowSessionController` must manually `getLatestRun()` and hydrate the runner separately from the event stream. Run identity (in `RunLifecycle`) and workflow identity (in `workflowRunner`) are tracked by two parallel state machines.

Why this matters

• Two-tier state model: cannot trivially answer "what is the active workflow context for this permission request?" without reading from two modules.
• Workflow-aware features (sub-run branching, workflow-aware permissions, automatic retry-on-permission-deny) hit this seam.
• A future agent reading the codebase has to learn two persistence stories; one would be enough.

Proposal sketch (needs grilling)

• Define new `RuntimeEvent` kinds: `workflow.start`, `workflow.transition`, `workflow.iteration`, `workflow.end`.
• `workflowRunner` shifts from imperative `persistRunState(snapshot)` to declarative event emission via the `RuntimeEvent` channel.
• `FeedMapper` adds an internal seam (`WorkflowLifecycle`?) that owns workflow state derivation alongside `RunLifecycle`.
• The `workflow_runs` table is either removed (state derived from events) or becomes a read-only projection.

Files involved

• `src/core/workflows/workflowRunner.ts` (~320 LOC)
• `src/infra/sessions/store.ts` (~450 LOC)
• `src/infra/sessions/schema.ts` (~273 LOC)
• `src/app/providers/RuntimeProvider.tsx`
• `src/core/feed/internals/` (new `workflowLifecycle.ts`?)

Open questions

• Is workflow state truly derivable from events, or are there imperative-only transitions (timer-driven, external signals) that don't fit?
• Schema migration: keep `workflow_runs` as a denormalized cache, or fully eliminate it?
• Does `WorkflowLifecycle` belong in `FeedMapper` (today event normalization, not business logic)?

Blast radius

Large. SQLite schema changes ripple to all resume paths; `FeedMapper` learns a new responsibility; bootstrap path is touched.

Pre-req

Recommended to land #5 (RelayCoordinator) first — the workflow runner also fires relay-shaped requests and would benefit from the coordinator existing.

Provenance

Surfaced by `/improve-codebase-architecture` + `/zoom-out` analysis. Ranked #2 of three candidates.

[lespaceman]

This was generated by AI during triage.

Human-Implementation Brief

Category: enhancement
Summary: Unify workflow state with the RuntimeEvent stream so resume hydration has a single source of truth.

Why this can't be delegated to an AFK agent:

Three judgment calls sit at the centre of this work, and each one is a one-way door:

1. Are all workflow transitions derivable from events? Today, workflowRunner writes imperative latest_state snapshots. To eliminate the parallel persistence path, every transition must be expressible as a RuntimeEvent. If any transition is timer-driven, externally-signalled, or otherwise non-event-shaped, the unification breaks down. This requires auditing the runner's full transition table and deciding what to do with anything that doesn't fit — that's a maintainer call, not a mechanical refactor.

2. Does workflow state belong inside FeedMapper? CONTEXT.md defines the mapper as event normalization; its six existing seams (RunLifecycle, ToolCorrelation, DecisionCorrelation, AgentMessageStream, RootPlanTracker, SubagentTracker) all derive timeline state from events. A new WorkflowLifecycle seam would import workflow business logic into a module currently scoped to projection. The alternative — workflow state derives from events but lives outside the mapper — is a domain-shape decision that affects the conceptual model documented in CONTEXT.md.

3. Schema migration: drop workflow_runs, or keep as read-only projection? Either choice is irreversible for existing session DBs. A migration plan needs to consider how the bootstrap path reads workflow state today and whether projection-only access is fast enough on resume.

Current behavior:
Workflow state lives in two parallel persistence paths. The canonical event log (runtime_events / feed_events) is replayed by FeedMapper.bootstrap() on resume. Workflow metadata and latest_state snapshots live in workflow_runs, written imperatively via persistRunState(snapshot) from workflowRunner. On resume, the session UI controller calls getLatestRun() and hydrates the runner separately from the event stream. Run identity (in RunLifecycle) and workflow identity (in workflowRunner) are tracked by two parallel state machines.

Desired behavior:
A single event stream is the source of truth for workflow state. workflowRunner emits new RuntimeEvent kinds (sketch: workflow.start, workflow.transition, workflow.iteration, workflow.end) instead of imperative snapshots. Resume hydrates workflow state by replaying events, not by reading a separate snapshot table. The workflow_runs table is either eliminated or demoted to a read-only projection.

Key interfaces:

• RuntimeEvent — extended with workflow lifecycle kinds; their payloads must be sufficient to reconstruct workflow state from a fresh replay.
• WorkflowRunner — its persistRunState path is replaced (or supplemented) by an event-emission path through the existing RuntimeEvent channel.
• FeedMapper — gains workflow-state derivation, either as a 7th internal seam or as a sibling collaborator (see judgment call 2).
• SessionStore schema — workflow_runs is removed or converted to a projection. Schema version bumps from 5 → 6 with a migration.
• useWorkflowSessionController — its bootstrap path no longer calls getLatestRun() directly; workflow state arrives through the same channel as feed state.

Acceptance criteria:

• Workflow state on resume is reconstructed by replaying RuntimeEvents, with no read from a separate latest_state column.
• All workflow transitions visible in the existing state machine (idle → starting → running → completing → done, plus iteration counters, completion markers, blocker detection) are reproducible from the event log alone.
• Schema migration upgrades existing session DBs without data loss; resume of a pre-migration session produces the same workflow state as before.
• CONTEXT.md is updated to reflect whether workflow state is a FeedMapper seam or a separate collaborator.
• An ADR captures the architectural decision (mapper-internal vs. sibling) so the rationale is durable.

Out of scope:

• Sub-run branching, workflow-aware permissions, or retry-on-permission-deny — those are downstream features that benefit from this unification but should not land in the same change.
• Behavioral changes to the workflow state machine itself (states, transitions, completion logic) — this is a persistence/representation refactor, not a semantics change.

Pre-requisite: #9 (relay coordinator seams). The workflow runner fires relay-shaped requests and benefits from that coordinator existing first.

Provenance: Surfaced by /improve-codebase-architecture + /zoom-out analysis. Ranked #2 of three candidates.