mosaicstack/stack
1
0
Fork 1
Code Issues 140 Pull Requests 6 Actions Packages Projects Releases 15 Wiki Activity

docs(remediation): bank D-22 — the registry would have verified the wrong artifact

Browse Source 
The gate that actually runs is the installed copy at ~/.config/mosaic/tools/git/;
a repo-scoped registry would test packages/mosaic/framework/tools/git/. Byte-identical
today (sha256 19cda2f7009c536e both) but nothing asserts it.

A registry that verifies the wrong artifact is worse than none — it manufactures
confidence, and the divergence would be invisible from every signal we have: registry
green, CI green, deployed gate arbitrarily different.

D-1/P-ACTIVATION applied to the enforcement mechanism itself rather than to config.

RM-02 gains: for every registered gate with a deployed counterpart, assert
repo-source == deployed-copy with a must-fail control; where none exists, record that
explicitly.

Found by design review before implementation — the only finding tonight not found by
execution, which is the design-first gate on keystone tasks paying for itself.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This commit is contained in:
mos-dt-0
2026-07-31 20:14:13 -05:00
co-authored by Claude Opus 5
parent e85a088f85
commit 8c496993e4
1 changed files with 29 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/remediation/TASKS.md
+29
View File
@@ -93,6 +93,35 @@ and must not be cited as merge evidence. Rely on reviewer clearance + real CI.
Three independent live instances in a single session — format gate, agent context reset, queue guard —
is the class confirmed, not anecdote.
### D-22 — the registry would have verified the wrong artifact
Surfaced while ruling RM-02's design. The gate that **actually runs** when the fleet invokes a wrapper is
the **installed** copy:
```
~/.config/mosaic/tools/git/ci-queue-wait.sh ← what executes
packages/mosaic/framework/tools/git/ci-queue-wait.sh ← what a repo-scoped registry would test
```
Checked: today they are byte-identical (`sha256 19cda2f7009c536e` both). **But nothing asserts that.**
There is no check, anywhere, that the deployed gate matches its source.
**A registry that verifies the wrong artifact is worse than no registry**, because it manufactures
confidence: every case would go green against a file that is not the one enforcing anything. Note this
would have been invisible from every signal we have — the registry's own tests would pass, CI would
pass, and the deployed gate could be arbitrarily different.
This is the **D-1 / P-ACTIVATION class applied to the gates themselves**: the same "committed config
that only works on one runtime" defect, one level up, where the _enforcement mechanism_ rather than the
config drifts from source.
**Requirement on RM-02.** For every registered gate with a deployed counterpart, a case asserting
**repo-source == deployed-copy**, with a must-fail control (mutate the deployed copy ⇒ detected). Where
a gate has no deployed counterpart, record that fact explicitly rather than leaving it ambiguous.
**Caught before implementation began** — the only finding tonight found by _design review_ rather than
by execution, which is an argument for the design-first gate on keystone tasks paying for itself.
### D-21 — a service step reports FAIL under an overall-success pipeline (normalised red)
Observed on pipelines **#2170** and **#2175** (not on #2158, #2167, or the manual #2171): the