## What was red
`task-delete-caller-attribution` (13 failed) and
`task-delete-nonblocking-cleanup` (2 failed) on clean `origin/main` —
**15 failed / 8 passed**. Every case threw the same thing:
```
TypeError: store.deleteTaskBackend is not a function
```
`deleteTaskImpl` / `deleteTaskIfImpl` are now **thin delegators** onto
the PostgreSQL backend; the SQLite arms both fakes modelled were deleted
(`FNXC:SqliteDualPathCleanup 2026-07-26`). One fake was matching raw SQL
strings (`UPDATE tasks SET "column" = 'archived'`). Nothing reached the
logic under test.
Rewritten onto the PG path using the same three mocked persistence seams
`task-delete-notice.test.ts` already uses — that file is green on main,
so this is the established pattern here, not a new one. The **real**
backend impls are wired in rather than stubbed, so the delegation is
what carries the behaviour.
## Measured
| Check | Before | After |
|---|---|---|
| the two files | 15 failed / 8 passed | **21 + 3 passed** |
| all 6 core delete/archive files | — | **67 passed** |
| `pnpm test:gate` | — | **726 passed** |
| `pnpm lint`, core `tsc --noEmit` | — | clean |
**Load-bearing, not decorative:** removing the lineage gate from
`deleteTaskBackendImpl` makes the gate test fail. My first attempt at
that proof was worthless and I caught it — the patch didn't apply
because the block appears twice in the file, so the "3 passed" I got
back proved nothing. Retargeted to the occurrence inside
`deleteTaskBackendImpl` and it failed correctly.
## Deleted rather than repaired
`task-delete-nonblocking-cleanup`'s two original cases asserted that
delete **schedules branch cleanup**. That behaviour no longer exists:
`_scheduleDeleteBranchCleanup` has exactly **one** reference in the tree
— its own definition — and the only live `store.cleanupBranchForTask`
call is the **archive** path (`archive-lifecycle-2.ts:306`).
Reshaping the fake until those passed would have pinned behaviour the
product does not have. The file now covers the gates that *did* survive:
idempotent re-delete, the lineage-child gate, and exactly one
`task:deleted` audit row.
The dead `_scheduleDeleteBranchCleanup` is left in place — deleting
source is a separate change from fixing tests, and it is already
unreferenced so it is inert. Flagged for whoever wants the cleanup.
## FLAGGED, not guessed — a possibly-lost safety gate
The removed version asserted `TaskHasDependentsError` when deleting a
task that other live tasks depend on. **That error is neither imported
nor thrown anywhere in `archive-lifecycle-2.ts`** — the PG backend
raises only `TaskHasLineageChildrenError`, `TaskNotFoundError`, and
`TaskSelfDeleteError`.
Two readings, and it is a product question rather than a test fix:
1. the delete path now **rewrites** dependency references (there is a
`removeDependencyReferences` option and a `rewriteDependentsForRemoval`
impl) and blocking was dropped deliberately; or
2. the gate was **lost in the cutover**, and a task can now be
soft-deleted out from under its dependents.
Asserting either shape would encode a guess, so the question is recorded
in-file next to the tests. If it is (2), that is a data-integrity
regression worth its own fix — I did not want to bury it in a
test-repair PR.
## One of my own assumptions, corrected in-file
I asserted `deleted.deletedAt` was populated on the returned task and it
failed. The PG backend returns the **pre-delete snapshot** — its own
comment says so, because the lifecycle emit and the audit row both need
the previous column. The comment now records that, so nobody "fixes" the
impl to satisfy the wrong expectation.
Census unchanged (722) — test files are not scanned.
af058b0276