Fleet phase. Claimed `packages/core/src/task-store/project-store-ops.ts`
— the largest census file with no branch, worktree, or open PR against
it. Claim published by pushing the branch **before** starting work.
## Census before / after
| | total | this file | deliberate |
|---|---|---|---|
| before | **104** | 2 | 130 |
| after | **102** | 0 | 130 |
`--strict` exits 0, baseline re-recorded in the same commit.
**Reclassification, not conversion** — the line is unchanged.
## The site was already audited today, in prose the tool cannot read
```
FNXC:WorkflowLifecycleColumns 2026-07-31-02:45 (audited — DEAD SYNC PATH, do not convert):
… It is the SQLite-mode twin. The live path is `dequeueMergeQueueOnColumnExitInTransaction`
… and it is ALREADY converted … This body reaches for `store.db.prepare`, which throws in
PostgreSQL backend mode …
```
The reasoning is sound and I did not second-guess it: the live path is
converted, this twin cannot execute in production, and converting it
would mean threading a lane set into a function whose first statement
throws.
The problem is purely mechanical — **the note is prose, and the census
reads markers.** So the site stayed in `byFile` looking like unconverted
debt, and each fleet pass pays to re-derive the same conclusion. Adding
`DELIBERATE-LITERAL` moves it to `deliberateByFile`, where a
reviewed-and-kept literal belongs.
## This is the second one, which makes it a pattern
Same shape as #3056 (`async-mission-store-queries.ts`, fallback arms).
Across the files I have checked this phase — `agent-store`,
`github-tracking-state`, `planner-overseer`, `auto-merge-finalization`,
`async-mission-store-queries`, and this one — **every site was either a
fallback arm or an already-documented deliberate leave**, and
`agent-store.ts:236` carries its own "FLAGGED AND LEFT COUNTED" note
from today.
So the count is not a work queue, and the gap is not judgement —
previous passes reached the right answer. They recorded it where only a
human reader would find it. Two lines of marker per site closes that,
and the number then means "conversions owed", which is how every worker
reads it when picking a cluster.
## Verification
- `census --strict` exit 0; `tsc --noEmit` **0 errors**
- `check:fnxc-future-dates`, `check:lane-wiring`,
`check:sql-column-literals`, `check:inert-flag-seams` — all exit 0
- No behaviour change: only a comment added
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
39e6891c93