**Unowned work, picked up.** `task-delete-notice.test.ts` was **21
failed / 13 passed** on main → now **34 passed**. Test-only. `pnpm
test:gate` green, `pnpm lint` clean.
## Cause
`deleteTaskImpl` and `deleteTaskIfImpl` are now **thin delegators**. The
SQLite arms were deleted in the PG cutover (`FNXC:SqliteDualPathCleanup
2026-07-26`) and both forward unconditionally to
`store.deleteTaskBackend` / `store.deleteTaskIf` — `deleteTaskImpl` is
literally *"throw if self-delete; return `store.deleteTaskBackend()`"*,
with **no `backendMode` branch left**.
The suite drove them against a `makeSqliteStore` fake providing neither
method, so every case threw `store.deleteTaskBackend is not a function`
**before reaching any notice logic**. All 21 failures were measuring a
crash, not a decision.
## Fixes
- the PG fake gains `deleteTaskBackend` / `deleteTaskIf`, wired to the
**real backend impls** rather than stubbed — so the delegating paths
still prove the delegation preserves the notice decision instead of
asserting against a mock;
- plus `withTaskLock` (`deleteTaskIf` wraps the conditional delete in
the per-task lock), running the body inline so the predicate and
short-circuit paths execute for real;
- every remaining `makeSqliteStore` call site retargeted, and the
now-dead factory **deleted** so it cannot rot back in.
## Corrected a claim the file was making
The header's Surface Enumeration said the three paths prove *"the
behavior cannot depend on backend mode"*. **There is one backend now.**
The enumeration is still worth driving — a caller reaching the public
entry point must get the same notice as one reaching the backend
directly, and these paths prove exactly that — but it is a different
claim, and the file now states it, with the two paths renamed from
`(SQLite)` to what they actually are.
## A bug in my own patch, caught by re-running
My first edit inserted the method assignments **after** the `return`, so
they were unreachable and the symptom didn't change. I only found it
because the failure count stayed identical and I checked the file
instead of assuming the edit had landed. Worth noting because "the patch
applied" and "the patch took effect" are different facts, and this
session has now produced three variants of that same mistake.
## Deliberately not fixed here
`task-delete-caller-attribution` (13 failed) and
`task-delete-nonblocking-cleanup` (2 failed) share the root cause, but
their `makeDeleteStore` fake carries `backendMode: false` and lacks the
PG surface the real backend impl needs (`asyncLayer` /
`transactionImmediate` / `rowToTask` …). Wiring them means either
building that surface out or re-pointing the suites at
`deleteTaskBackendImpl` directly — a judgement about what those suites
are *for*, and worth making deliberately rather than folding into this
fix. Whoever owns the PG cutover cleanup will know which; the diagnosis
above is the whole of it.
Verified no collateral: `task-merge` and `legacy-adoption` unaffected
(166 passed across the three files).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
bcb9782d3f