#214's gate package is void: its 4 UPDATEs target codes with zero rows in production #225

The package would write nothing and report success

docs/gates/coa-scoped-apply-2026-10-19.md (merged in #214, d0ce80a) states "4 UPDATE, 0 INSERT" over scope {"codes": ['5015','5025','5055','6050']}, with:

WHERE tenant_id IS NULL AND code IN ('5015', '5025', '5055', '6050')

Read live against production (solitary-rice-14149088, read-only) today:

total_rows              80
with_parent_code        62
target_codes_present     0      <-- all four
has_is_header_col        0

All four UPDATEs match zero rows. The apply would complete, touch nothing, and report success. Nothing has executed — the write is operator-gated and that gate held — but the package is not a valid basis for one.

The drift is the opposite shape to what the package assumes

Production is a strict subset of the authoritative document: comparing docs/CHART-OF-ACCOUNTS.md against the live code set, zero production codes are absent from the document, while a set of document codes is absent from production — including all four targets.

So the defect is missing accounts, not wrong values. The corrective statement is INSERT, not UPDATE. A scoped UPDATE over a code that does not exist cannot move the projection toward the document, which is the stated §1 purpose.

Count, with the method's limits stated (§10)

A naive extraction of 4-digit codes from the document yields 106 vs 80 live, i.e. 26 absent. That number is not trustworthy as an account count and I am not asserting it:

• 8825 is the IRS form number appearing in a table header (| Code | Name | 8825 | Sch E I (direct) | Note |), not an account.
• 5190, 5290, 5390, 5490 appear in a rollup/parent column (e.g. | 5100 | Utilities - Electric | … | 5190 |), so they may be referenced parents rather than rows of their own.

Defensible: the four #214 targets are in the document and have zero rows in production, and at least ~21 further document accounts are absent. An exact figure needs a parse that distinguishes account rows from rollup references and headers — that parse is the first task here, not an aside.

Two further inaccuracies in the package's own text

• It reasons about "a human reading ninety-five rows". Production has 80.
• Its §4 snapshot and §7 rollback are both scoped to the same four codes, so on today's data the snapshot captures zero rows and the rollback restores nothing — a rollback recipe that cannot fail because it does nothing is not a rollback.

Why the gates did not catch it

The package was compiled by drizzle against a recording client and its tests assert the compiled SQL. That is §2 working as written — "verify the statement that will execute" — and the statements are correct SQL. Nothing asserted that the target rows exist. A scoped apply whose scope selects an empty set is indistinguishable, at the SQL level, from one that is about to do the right thing.

Same shape as the day's other findings: the check was accurate about what it checked, and silent about the thing that mattered.

Recommended disposition

1. Mark the package void in place (do not delete — it is the audit trail for a decision that was made), stating that its target rows do not exist.
2. Re-derive the drift as INSERTs from the document, after the code-extraction parse above.
3. Keep it operator-gated. This is a production financial write, and nothing here changes that.
4. Supersedes the "four prod rows hold wrong tax_deductible" premise entirely: there are no such rows to hold a wrong value.

Related: #133 targets 6050, which is one of the absent codes — that issue's premise needs the same correction.

🤖 Generated with Claude Code