docs(lane): withdraw the unverified CI cache analogue

The local false compile red remains a machine-local artifact-state
hazard with no CI occurrence. If the same fragments ever appear in CI,
that run is a new incident and must be recorded under its actual job
and flavor, not the local bare-cargo flavor.

Withdraw the rust-cache explanation: workspace crates are not cached by
default and GitHub cache visibility is scoped. Neither replace it with
the equally unmeasured claim that CI builds fresh.
This commit is contained in:
Levi Neuwirth 2026-09-01 20:21:55 +02:00
parent 7a534eeeca
commit a0705399e2
No known key found for this signature in database
1 changed files with 9 additions and 4 deletions

View File

@ -397,10 +397,15 @@ 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.
CI, that is a new incident and belongs in the registry under the
actual job and flavor that observed it** — not under this local
flavor. This evidence neither predicts nor excludes such an
occurrence. An earlier correction tried to keep that possibility open
by pointing at `Swatinem/rust-cache@v2`, but that mechanism was not
verified: the action's default does not cache workspace crates, and
GitHub cache visibility is scoped rather than shared indiscriminately
across branches. The unsupported mechanism is withdrawn instead of
being replaced with the equally unverified claim that CI builds fresh.
It has now fired **twice in this lane**.