Files
fusion/packages
gsxdsm 8beba5f543 U7 E2E evidence: the planning lane, real PostgreSQL + real hold-release sweep (3/7 red without the guard) (#2611)
> Completion-bar **item 3** for my phase. Test-only, based on `main`, no
dependencies, no changeset.

## The gap this closes

The planning lane was the **one lifecycle lane with no E2E coverage**.
The existing live-E2E files cover the lifecycle spine, agent count,
agent link, lease rebound, the merge family and the rebound family —
**not one exercises a planning decision.** Every U7 fix shipped with the
caveat the other units already removed for their lanes: *"all evidence
is unit-level."*

That caveat matters more here than anywhere, because the planning fixes
are **guards that refuse things**, and a refusal is what unit tests are
worst at proving. Nine times on this program a planning test passed
without exercising its subject: a fake that ignored its predicate, a
store stub returning a non-promise into `.catch`, a fixture that
silently resolved to the default IR, a control that passed when it
should have failed.

## What is real

- a per-file **throwaway PostgreSQL** TaskStore (never the operator's)
- the **real `runHoldReleaseSweep`** — every guard, trait resolution,
reservation ordering, and the in-transaction `moveTaskIf` predicate
- **persisted rows** read back with the store's task cache defeated, so
an assertion can only have come from the row

Nothing about the AI is substituted, because none of these decisions
involve it — there is no seam here to script.

## The proof, which is the point

With **#2491's two approval guards removed** from `hold-release.ts`,
this file goes **3 of 7 red against real PostgreSQL**:

```
FAIL  does NOT release a card blocked on manual plan approval on a default board
FAIL  does NOT release a card blocked on manual plan approval on a renamed board
FAIL  holds a card parked for approval MID-SWEEP, after the snapshot was read
      Tests  3 failed | 4 passed (7)
```

Restored: **7/7**. So the file demonstrably exercises the guard rather
than merely observing that a sweep works — which the two control cases
(an ordinary held card **is** released, on both vocabularies) exist to
keep falsifiable.

## The case no unit test could honestly make

The **mid-sweep** case needs the in-transaction predicate enforced by a
real store. The hand-built fake that shipped with #2491 originally **did
not honour the predicate at all** — exactly what greptile caught. Here
PostgreSQL enforces it, and the sweep's own log confirms the refusal:

```
[scheduler] Hold release for FN-RACE skipped — task became paused or left todo
```

It parks the card inside `reserveSlot`, which runs *after* the snapshot
and *before* the move — the precise window the in-txn half exists for.

## Coverage

Both approval hold shapes (`status: "awaiting-approval"` and `paused` +
`pausedReason`), on **both** vocabularies, so no assertion can pass by
matching a legacy id. The renamed run's log shows the real sweep
releasing the control card to `building`, not `in-progress`.

## Lane

`.pg.test.ts`, skipped via `pgDescribe` when no PostgreSQL is reachable,
so **the merge gate is unaffected**. Throwaway per-file database, never
port 4040, no temp-root walk.

## Verification

| Check | Result |
|---|---|
| E2E suite (real PostgreSQL) | 7/7 |
| same suite with #2491's guards reverted | **3/7 fail** |
| `tsc --noEmit` (engine) | clean |
| `pnpm lint` | clean |
| `pnpm test:gate` | green (482 + 10 + 71) |

## Still owed on the completion bar for my lane

E2E for the other three U7 fixes — approved-plan recovery (#2593), the
spec-staleness exemption (#2583), and the discovery advancement guard
(#2576) — is **not** in this PR. Those need a driver for triage's own
poll/recovery path rather than the sweep, which is a different harness
shape; adding it here would have made this PR a harness project rather
than evidence. Taking that next.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-29 22:40:05 -07:00
..
2026-07-26 18:11:47 -07:00