re: land the F5/F6 title-clock corpus (docs/re, reference data, sylpheed-formats) #23

Merged
fabi merged 511 commits from auto/frame-blend-draw-path into main 2026-09-13 11:16:19 +00:00
Showing only changes of commit b2dd779fdc - Show all commits

View File

@@ -3384,3 +3384,42 @@ separately, because it is the actual discipline:
was preceded by a screenshot that was looked at. The navigation was wrong twice
and the measurement was never in doubt, because nothing downstream trusted the
button presses.
## A finding is only as portable as the tool that produced it, and a recipe that reads as complete is the dangerous kind
Four commits on Canary's `sylpheed-re` branch existed **only inside the container**
and were on no remote. Findings resting on them cited them the way one cites a
public reference — *"canary sylpheed-re `d90d14e02`, already built"* — a line that
reads as a complete recipe and is reachable from nowhere but that one box.
The exposure was not marginal:
| the commit adds | without it |
|---|---|
| `blend=` per draw | a draw log carries **no blend state at all**, so the 35-element oracle that decoded the blend bit — and let the port delete an authored map — could not be re-derived. Not approximately; not at all |
| vertex dump 8 → 64 | the log **silently drops** four quads of a six-quad batch, which is why four additive elements read as absent |
| RT state / resolves / PS constants | *"is there a post-process pass?"* cannot be asked, because it is a question about render targets |
| a texture **content** hash | a rotating triple buffer is **indistinguishable** from one decode per present — the confusion that cost two withdrawn positions on `units/second` in one day |
⚠️ **The failure is silent and delayed by design.** The recipe looks complete, so
nobody checks it; it fails only for someone on a different machine, long after the
person who wrote it could still say what the flag did. Nothing in the repository
disagrees with itself in the meantime, so no consistency check fires.
📌 **Citation checkers do not cover this class**, and it is worth knowing why: they
scan for *repository paths* that fail to resolve. An instrument living in another
container is not a path at all, so it never enters the check. The port's
`check-citations` catches a stale pointer to a committed artefact — the
*recoverable* case — and slides straight past an artefact that does not exist
outside a container.
**The discipline:** when a finding's reproduce recipe names a sha, a branch, a
binary or a flag, ask *where that lives*. If the answer is "this machine", the
finding is not reproducible and the fix is to export the thing, not to describe it
better. `tools/canary-patches/` exists for exactly that.
⚠️ **And the audit only works pointed at yourself.** Both agents ran the same audit
on the same day. One found a stale path to an artefact that *was* committed —
recoverable. The other found four artefacts that existed nowhere else — lost.
Neither could have found the other's, because each is invisible from the far side
of the wall.