**Completion bar #3 for my phases.** Test-only, no production changes,
no guard-count movement — the two live-PG E2E suites I held during the
freeze.
## Why these exist
Every U11 slice I shipped closed with the same caveat: *all evidence is
unit-level*. Three claims in particular were argued from reading code,
and each is the kind a mock would happily confirm:
1. #2515 left `triage` a legal id but removed it from the default
lineage.
2. #2603 — `createTask` resolves the workflow's intake column, and an
explicit `column` **overrides** it. Nine write sites were removed on
that reasoning.
3. #2591 — a card stranded on a legacy planner id is admitted by
planning discovery, which is what lets it heal with no data migration.
Both suites drive a **real PostgreSQL TaskStore** (per-file throwaway
database) and the **real shipped workflows**, not fixture IRs. Claim 3
goes through the real `discoverReadyPlanningTasks` — the method the poll
calls. Every assertion is on **observed persisted state** (fresh
`getTask` after clearing the task cache), the rule inherited from
`workflow-lifecycle-live-e2e.pg.test.ts`, because "a function was
called" is exactly what has passed falsely on this program before.
## Two things the E2E found that unit tests did not
**The shared fixture's "merged" shape was not #2515's.** Omitting
`separateIntake` leaves the hold column with *no* intake trait, so the
resolver reports `undefined` — "I have no intake to name" — whereas the
shipped merged lineage carries intake **and** hold on one column and
reports `[]` — "intake exists and *is* the hold column". Callers treat
those differently: `undefined` keeps their legacy default, `[]`
positively asserts no dedicated planner lane. Assuming the plain shape
was the merged shape is how a test appears to cover #2515 while covering
something else. Added an opt-in `mergedIntake` to model the real thing;
the third shape is now asserted explicitly.
**`insertWorkflowDefinitionSync` throws in backend mode** — it's the
SQLite path. The suites use `createWorkflowDefinition` +
`writeTaskWorkflowSelection` like the other live E2Es, including binding
to the id the *store* allocated rather than the one passed in, which the
lifecycle suite documents as a way a renamed-workflow fixture silently
resolves to the default IR.
## Fixture changes are opt-in
Both new options follow the existing `mergeOrchestration` precedent:
seven suites build on this builder and a shared fixture must not
silently change an existing suite's subject.
## Naming
`workflow-planner-lane-**resolution**-live-e2e` deliberately, to stay
distinguishable from #2611's `workflow-planning-lane-live-e2e`.
Different subjects — that one drives the real hold-release sweep, this
one drives the resolvers the lane guards consume. Near-identical names
would invite someone to delete one as a duplicate.
## Verification
- 8 new tests green against a real PG store
- **Mutation-verified:** disabling the #2591 rescue in
`discoverReadyPlanningTasks` fails claim 3, and only claim 3
- Merge gate green (482 + 132 + 10), engine tsc clean, lint clean
**Pre-existing failures, not from this PR:** the full live-E2E sweep is
82 tests / 2 failed, both in `workflow-lifecycle-live-e2e.pg.test.ts`.
Verified by swapping main's `_workflow-vocabulary-fixture.ts` in and
re-running: 2 failed either way, identical. They are main's, and they
appeared since my earlier clean run of that suite — worth a look against
bar #2.
## What this does not cover
Neither suite runs a planning **session** — that lane is the AI,
substituted here as `testMode` does in production. So this proves a card
is *admitted* and re-homable, not that a full plan-and-release round
trip happens. The release half is covered by the existing lifecycle E2E.
No changeset: `@fusion/engine` is private and this is test-only.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
be63e72f10