Version. 0.1 · Date. 2026-08-09 · Author. Claude Code.
Found by. CR-2026-194 Step 1 (B-60). Companion to. standing-notes/loomworks-standing-note-observe-the-failure-before-trusting-the-check — the same family: a statement that reads as reassurance while carrying no information.
src/loomworks/api/routers/uploads.py:821 carried this, from Phase 59 until CR-2026-194:
> per_step_provenance ← left empty in v1; the executor's dict shape doesn't trivially map to the model's PerStepProvenance fields (skill_name/version/timestamps) — that enrichment is a follow-on
Every word of it is true. It is still the reason B-60 sat mis-sized for five phases.
The phrase doesn't trivially map covers two problems that are not the same kind of thing:
| Named field | Actual state | Work to close |
|---|---|---|
| skill_name | Maps exactly. All ten skills emit it. | None. |
| skill_version | Maps exactly. All ten skills emit it. | None. |
| started_at | No source anywhere. The executor does not import datetime. | A decision, then a change. |
| completed_at | No source anywhere. Same. | A decision, then a change. |
Two-thirds of the list was already done. The remaining third was not hard-to-map — it did not exist. Averaging them produced one word, trivially, that described neither: too pessimistic for the solved part, far too optimistic for the unsolved part.
The average is what gets read. Nobody re-derives a comment's components. "Doesn't trivially map" reads as fiddly but mechanical, and that reading is what sized B-60 on the build list: a small carry-through, the sort of thing a spare hour closes.
It sized the item wrong in the direction that hides work. Had the comment said the timestamps were never observed, B-60 would have been visibly a decision — capture, relax the schema, or fabricate — rather than a chore. The decision was always there. The comment made it invisible by burying it next to two non-problems.
> And the plausible build was the wrong one. Believing the comment, the natural move is to map the fields that map and fill the two that don't from the value nearest to hand — the event's own now. That produces a populated field, a green suite, and a fabricated observation written into an append-only log on every upload from that day forward. The comment did not cause that; it removed the signal that would have stopped it.
When a comment explains why something is deferred, name each blocker separately and say what each would take. One phrase covering several unlike problems will be read at the average, and the average is always kinder than the worst item in the list.
In particular, distinguish these three — they read alike and are not alike:
A deferral note that does not say which one it is has not recorded a reason. It has recorded a feeling about the reason.
A useful test: could a reader size the work from the comment alone? If the answer needs the code, the comment is decoration. skill_name/version/timestamps in one parenthesis fails this test — the reader cannot tell that two of the three are already done.
The comment is replaced by one that separates them, states that the first two mapped all along, and records that the executor now measures the other two. (CR-2026-194, tag cr-2026-194-b60-provenance-to-memory.)
DUNIN7 — Done In Seven LLC — Miami, Florida A comment that averages two problems hides the harder one — v0.1 — 2026-08-09