neuwirth
/
pmacs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(lane): the registry does hold local reds --- fix the stated reason 

3bd9ad1 justified keeping the shared-target false red out of
docs/ci-red-signatures.md by asserting the registry is for CI reds and
that a row would have to invent a job and flavor. Both halves are false.
The registry carries many `local (Linux)` rows with precise invocation
flavors --- one of them flavored "with sibling worktrees building
concurrently", which is adjacent to this very mechanism --- and this
incident's truthful flavor is plainly statable: local, bare
`cargo test -p pmacs-gpu`, globally shared target.

I asserted a property of a file I had not read. The conclusion happened
to survive; the reason did not, and a reason that cannot be checked is
the part that goes on to be reused.

The entry now keeps it here for the reason that actually holds --- a
machine-local artifact-state hazard with no CI occurrence, every one of
them from bypassing scripts/gate --- and records that a CI appearance
would belong in the registry with that flavor. It also declines the
easy immunity claim: CI restores artifacts through rust-cache from a
cache shared across branches, so the same mixing has a plausible CI
analogue that has simply never been observed. The superseded reasoning
is named in place rather than quietly replaced.
This commit is contained in:
Levi Neuwirth 2026-09-01 19:59:38 +02:00
parent 3bd9ad14e7
commit 7a534eeeca
No known key found for this signature in database
1 changed files with 20 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/active-work.md
View File

@ -383,11 +383,26 @@ the next lane does not rediscover them at review.
### A local false compile red from the shared target directory ### A local false compile red from the shared target directory
Not a CI signature, so it is **not** in `docs/ci-red-signatures.md` — Kept here rather than in `docs/ci-red-signatures.md` because it is a
that registry is for CI reds, and a row there would claim a job and **machine-local artifact-state hazard with no CI occurrence** — not
flavor this has never had. It is a hazard of running a bare cargo because the registry cannot represent local reds. It plainly can: it
command instead of `scripts/gate`, and it has now fired **twice in this carries many `local (Linux)` rows with precise invocation flavors, one
lane**. of them (the `04-lib-crdt` pair) even flavored *"with sibling worktrees
building concurrently."* This incident's truthful flavor would be
**local, bare `cargo test -p pmacs-gpu`, globally shared target**, and a
row could state it exactly. An earlier draft of this entry claimed the
registry was for CI reds only and that a row would have to invent a job
and flavor; that was false, and review caught it.
What actually keeps it out is that the registry is live triage policy
for judging a red *run*, and every occurrence of this one has been on
this machine, from bypassing `scripts/gate`. **If it ever appears in
CI it belongs in the registry**, flavored as above — and that is not
impossible: CI restores artifacts through `Swatinem/rust-cache@v2` from
a cache shared across branches, so the same mixing has a plausible CI
analogue. It has simply never been observed there.
It has now fired **twice in this lane**.
**Signature.** From `cargo test -p pmacs-gpu`, four errors against the **Signature.** From `cargo test -p pmacs-gpu`, four errors against the
bin `pmacs-gpu` test target: bin `pmacs-gpu` test target: