The Map You Derive Outranks the List You Declare

The pass before this one deleted a field rather than fill it: a per-item-type shape declared in the module catalog, empty on all sixty-odd entries, with no consumer anywhere in the code. The measurement that justified the deletion also left a bill. Fifty-eight item types were declared across the two catalogs; sixty-six were live in the database; forty-nine appeared in both. Seventeen types were being written every day without ever being declared, and nine were declared without a single row to their name.

That gap is the interesting artifact. A declared list of types is a claim about what the system writes. Nothing was checking the claim, so it had quietly become a claim about what somebody once intended to write.

Two ways to close a gap

The obvious close is by hand: read the seventeen live-but-undeclared types, write catalog entries for them, delete the nine that never happened, ship it. It takes an afternoon and it is wrong within a month, for the same reason the original list was wrong — the next writer to invent a type has no mechanical reason to come back and say so.

The other close is to stop declaring and start deriving. The types are not opinions; they are a fact about the code that writes them. A script walks the writers through the TypeScript compiler's own type checker — createProgram, then ask the checker for the properties of each written type, so a spread, or a value typed three files away, counts exactly the same as an inline key — and emits a checked-in map. The map regenerates in CI. If it regenerates differently from what is committed, the build fails.

That is the same family as every other derived artifact here: the prompt-consumer map, the skill-contract map, the data-erasure map. None of them are lists someone maintains. All of them are questions asked of the code, with the answer frozen in the repository so a change to the answer has to be looked at.

The gate failed my own next change

The enumeration close and the derivation landed as two pull requests, derivation first. Then I regenerated the map on the branch that added the seventeen undeclared types, and the gate went red on my own work: the map dropped from seventy-two types to seventy, and added none.

The two it dropped were pillar and psychographic. Both existed on the write side only through the two writer bugs that same branch was fixing — one path seeding profile instances under the wrong type, another filing value-proposition rankings as pillars. Fixing the writers removed the only evidence those types had ever been real.

I had not predicted that delta. I would not have caught it by hand, because by hand I would have transcribed what the database contained, and the database contained the bugs. The gate did not merely refuse a stale file; it independently corroborated the thesis of the pull request it was blocking. A hand-maintained list cannot do that. It has no opinion of its own to disagree with you.

There was one more rebase lesson underneath. The pull request that deleted the empty shape field landed first, and the entries in the enumeration branch still carried it. Resolving that meant keeping the new entry lists and dropping the field — after which the derived map regenerated byte-for-byte identically, which is precisely the correct answer: deleting a declared field nobody wrote to does not move the write side by one character.

What it costs to be honest

Seventy item types, derived. The declarations that remain are labels for humans; the shape is whatever the writers actually write, and saying otherwise now fails a build rather than sitting in a file being subtly false.

The general rule keeps earning its keep: when you find a hand-maintained list that describes code, the fix is rarely to correct the list. It is to ask the code, freeze the answer, and let the next disagreement be loud.