rule-cited-by-title-proposes-work-the-ledger-says-is-built

A rule cited by title proposes work the ledger says is already built

Problem

A repo keeps its standing decisions and its deliverables in one hand-edited, machine-parseable ledger — a tracker data.js, a registry, a manifest, a decisions table. Decisions have ids. Artifacts have rows with a status. Both are read by every session, which is the point of keeping them there.

A session reads a rule by its id:

d-the-threshold-is-charted-before-it-moves

That id is a complete sentence and it sounds like the whole rule. The session concludes: any change to the threshold needs a chart of the outputs at each candidate value, and nobody has charted them — so it writes the owner an option card offering to build exactly that.

Two things were never read.

The rule's own body, which said the charts are required and already commissioned:

"ruling": "A change to the threshold ships with the outputs charted at each candidate
           value, reviewed by me before the value moves. Commissioned 2026-08-30."

The artifact rows, which carried the deliverable twice:

{"id": "a-threshold-chart-2026-08-30", "path": "docs/deliverables/threshold_chart_2026-08-30.html",
 "status": "open"}
{"id": "a-threshold-chart-2026-09-05",  "path": "docs/deliverables/threshold_chart_2026-09-05.html",
 "status": "open"}

Both files exist. Both are built. "status": "open" in that ledger means built and not yet reviewed — the ledger's own header says so. Read as issue vocabulary it means the opposite: nothing has happened yet. So the one row that proves the work is done is the row that reads as proof it is not.

The cost is not a wasted hour. It is an option card asking the owner to authorise work they already paid for, which spends the scarcest thing in the loop — their attention — and invites a second artifact answering a question that already has one. A human who answers that card has been misled by you, persuasively, because you quoted a real rule.