Field Kit

The validator still expected the old count

Updating a source of truth is unfinished until every cached count, static list and generated map derived from it is updated to match.

What happened

On 2026-07-07, an assistant refreshed a central data registry and the production build failed, because a downstream validator still expected the old number of product ids.

2026-07-07 a source-of-truth registry · build-time validator scripts measured: none recorded

3 prompts, in order

Map every consumer of the registry You changed a central config or registry file. The build broke downstream, or you want to know what else holds a copy.
Update the stale snapshots to match The audit found validators, counts or static maps that still describe the registry's previous contents.
Prove the count guard still fires The build is green again and you want evidence the validator actually checks the registry.

1Map every consumer of the registry

Run it when: You changed a central config or registry file. The build broke downstream, or you want to know what else holds a copy.
It asks you for: The path to the changed registry, the production build command, and the repository root to search.
You get back: The registry's current item count. A table of every file that reads or copies that data. The first build failure, quoted.
It refuses if: The build command is unknown, or a file's role cannot be determined by opening it.

copy this into a model

<stance>
The registry is the source of truth, and the build trusts copies of it. Act as an auditor of data drift. Hardcoded counts, enum lists, fixture arrays and documentation tables all go stale quietly. They break the build later, far from the edit that caused it. The reasonable-sounding answer, that one file changed so one file matters, reads well and is wrong here. Report only files you have opened and quoted.
</stance>

1. The path to the registry or config file that changed.
2. The command that runs the production build.
3. The repository root to search.
If an answer is missing, ask for it. Do not guess a path. Wait for the reply.
</inputs>

1. Read the changed file. Count the items it now defines. Record the exact number.
2. Search the repository for the file's name. List every file that imports or reads it.
3. Search for identifiers drawn from the registry, such as ids or keys. Note any static copy.
4. Search for numeric literals matching the old count and the new count. Open every hit.
5. Classify each hit by role. Use live reader, static snapshot, documentation, or test fixture.
6. If a file's role stays unclear after reading it, mark it unknown. Do not call it safe.
7. Run the build command. Capture the first failure and the file path it names.
8. If the build passes, say so plainly. Report that this run does not prove drift is absent.

</method>

- Current item count in the registry, with the lines it came from
- Consumer table: path, role, how it was found
- Unknown-role files, listed separately
- Build result, including the first failure line verbatim

</deliver>

Do not list a file you have not opened. Do not infer a consumer from its name alone.
If a search returns nothing, report that it returned nothing. Do not fill the gap from memory.
If the build command is missing, stop and ask for it.
Do not edit any file during this step. This step reads only.
If the item count is ambiguous, name the ambiguous definition and stop there.

</refuse>

2Update the stale snapshots to match

Run it when: The audit found validators, counts or static maps that still describe the registry's previous contents.
It asks you for: The consumer inventory, the registry's current item list, the build command, and whether any item was removed.
You get back: One edit per file, each with its old value, new value and source line, plus the build result.
It refuses if: A snapshot has a generator script that cannot be run, or a validator's count looks like a deliberate cap.

copy this into a model

<stance>
A validator that counts items is a promise about the data. Keeping that promise is the work here. Static snapshots must be rebuilt from the registry, not nudged until the build turns green. Editing a number to silence a failure hides the real question, which is whether the new item belongs at all. Change the minimum. Justify every edit by quoting the registry lines it came from.
</stance>

1. The consumer inventory from the audit step.
2. The registry file path and its current item list.
3. The production build command.
4. Whether any registry item was removed rather than added.
If the inventory is missing, ask for it. Do not reconstruct it by guessing. Wait for the reply.
</inputs>

1. For each static snapshot, derive the correct value from the registry file directly. Quote those lines.
2. Check whether a generator script produces the snapshot. Prefer running the generator over editing by hand.
3. Update counts, lists and maps one file at a time. Keep each edit separate.
4. After each edit, state the old value and the new value.
5. If an item was removed, search for remaining references to it. Report every orphan you find.
6. If an expected count looks like a deliberate cap, stop. Ask before changing it.
7. Run the build command. Report a pass, or the first failure line verbatim.
8. If the build fails somewhere new, do not widen the edit. Report the new failure and stop.

</method>

- Per-file change summary: path, old value, new value, source line
- Snapshots regenerated by script versus edited by hand
- Orphaned references to removed items
- Build result, quoted

</deliver>

Do not change the registry to match a validator. The registry is the source.
Do not delete a validator or weaken an assertion to make the build pass.
If a snapshot is generated and its generator cannot run, say so. Do not hand-edit it silently.
If the inventory names a file you cannot open, stop and report that path.
Do not report success without quoting the build's final line or exit status.

</refuse>

3Prove the count guard still fires

Run it when: The build is green again and you want evidence the validator actually checks the registry.
It asks you for: The validator file path, the old expected value, the new value, and the build command.
You get back: Two build runs, one green with the fix and one red with the old value restored, each quoted.
It refuses if: The old value cannot be restored safely, or the build stays green with the old value in place.

copy this into a model

<stance>
A guard that never fails proves nothing about the data behind it. Treat the green build as a claim to be tested. The repair is only confirmed when putting the old value back turns the build red again. Reverting one number is cheap and decisive. Keep a backup copy of any file touched. Restore the fix before reporting anything.
</stance>

1. The path to the validator or snapshot that was updated.
2. The old expected value and the new expected value.
3. The command that runs the production build.
4. Confirmation that uncommitted work elsewhere is saved.
If the user cannot confirm their work is saved, stop. Wait for that confirmation.
</inputs>

1. Copy the validator file to a backup path. State the backup path in full.
2. Run the build command with the fix in place. Record pass or fail, and quote the final line.
3. If this run fails, stop. The repair is not complete, so report the failure.
4. Edit the validator to hold the old expected value again. Change nothing else.
5. Run the build command again. Record the result and quote the failure message.
6. Confirm the failure names this validator and the count it expected. If it does not, say so.
7. Restore the file from the backup. Run the build a third time to confirm it is green.
8. If the build stayed green with the old value, report that the guard does not read the registry.

</method>

- Backup path, written in full
- Run 1: fix in place, result, quoted final line
- Run 2: old value restored, result, quoted failure message
- Run 3: fix restored, result
- Verdict: does this guard detect drift in the registry

</deliver>

Do not run this without confirmation that other work is saved.
Do not leave the old value in place. Restore the file and prove the restore with a third run.
Do not call the guard effective because the code appears to compare a count. Only a red run shows that.
If the build cannot run at all, stop and report why.
Do not summarise build output from memory. Quote the lines the command printed.

</refuse>

How you know it worked

Run the project's build command and confirm it completes clean. Then set one validator's expected count back to the old value. Run the build again. The failure message names that validator and the count it expected.

← every Field Kit