Skip to content

contract: vendor the machine-snapshot checksum manifest and assert it here too (#208) - #210

Merged
Mikecranesync merged 1 commit into
mainfrom
fix/208-vendor-checksums
Aug 2, 2026
Merged

contract: vendor the machine-snapshot checksum manifest and assert it here too (#208)#210
Mikecranesync merged 1 commit into
mainfrom
fix/208-vendor-checksums

Conversation

@Mikecranesync

Copy link
Copy Markdown
Owner

Closes #208.

contracts/machine_snapshot/ is vendored verbatim in two repositories — FactoryLM (producer) and MIRA (consumer) — and MIRA PRD #3048 calls it "the compatibility boundary between repositories; both projects must test against the exact same payload."

A checksum guard on one side does not protect a boundary. The failure mode is a one-sided edit, and the repo that edits its own copy keeps passing against it — neither goes red. MIRA added CHECKSUMS.sha256 + an integrity test in #3060, so until now the guard covered MIRA only.

CHECKSUMS.sha256 is vendored byte-identical from MIRA. All six fixtures were verified byte-identical across both repos immediately before vendoring, so this passes with no fixture changes.

The part that would have made the guard useless

The workflow's paths filter was services/plc-modbus/** only. A PR editing only a file under contracts/machine_snapshot/ never triggered the job — which is exactly the one-sided edit the guard exists to catch. It would have sat silent for its own purpose.

contracts/machine_snapshot/** added to the filter, with a comment saying why so nobody prunes it later as noise.

Evidence

Proven by execution, not asserted:

8 passed
→ append a newline to snapshot_v1_valid.json
→ FAILED: "snapshot_v1_valid.json changed without updating CHECKSUMS.sha256"
→ restore
→ 212 passed   (204 on main + 8 new)

The guard also asserts every fixture on disk is listed, so a new unguarded fixture can't slip in behind a green check.

Note on the mechanism

Checksums detect drift; they don't prevent two copies existing. #208's step 2 — a real shared source (single-source + CI sync check, submodule/subtree, or a published contract package) — is still open and deliberately not attempted here. This is the floor, not the destination.

… here too (#208)

contracts/machine_snapshot/ is vendored verbatim in TWO repos -- FactoryLM
(producer) and MIRA (consumer) -- and MIRA PRD #3048 calls it the compatibility
boundary both projects must test the exact same payload against.

A checksum guard on ONE side does not protect a boundary. The failure mode is a
one-sided edit, and the repo that edits its own copy keeps passing against it;
neither goes red. MIRA added CHECKSUMS.sha256 + an integrity test in #3060, so
until now the guard covered MIRA only.

CHECKSUMS.sha256 is vendored byte-identical from MIRA. All six fixtures were
verified byte-identical across both repos before vendoring, so this passes with
no fixture changes.

ALSO -- and this is what would have made the guard useless: the workflow's
paths filter was services/plc-modbus/** only, so a PR editing ONLY a file under
contracts/machine_snapshot/ never triggered the job. That is precisely the
one-sided edit the guard exists to catch; it would have sat silent for its own
purpose. contracts/machine_snapshot/** added.

Proven by execution: 8 pass -> append a newline to snapshot_v1_valid.json ->
the checksum test fails with the regeneration instructions -> restore -> 212
passed (204 on main + 8 new).
@Mikecranesync
Mikecranesync merged commit d3f753e into main Aug 2, 2026
2 checks passed
@Mikecranesync
Mikecranesync deleted the fix/208-vendor-checksums branch August 2, 2026 16:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

contract: vendor the machine-snapshot checksum manifest, then replace vendoring with a real shared source

1 participant