The parity step in .github/workflows/main.yml:73-92 clones OO-LD/oold-schema at --depth 1 off the default branch and runs validate.mjs from it as the reference harness. Since #133 that step gates the build rather than merely reporting.
validate.mjs is being extracted to oold-js. When it moves, the clone has to move with it, and the move is the moment to change two things at once.
What has to change
- repoint the clone from
OO-LD/oold-schema to oold-js
- pin it to a released tag rather than tracking the default branch
Why the pin, given the clone deliberately tracks main today
Tracking main is right while the reference lives in oold-schema, and the comment in the workflow says so: it catches specification drift that the committed fixture snapshot cannot see. The specification and this validator are supposed to move together, so a disagreement is a real signal.
That argument does not survive the extraction. oold-js is a sibling implementation on its own release schedule, not the specification. Once the step gates, an unpinned clone means any commit landing in oold-js can turn this repository's CI red for a reason that has nothing to do with a change here, and the failure lands on whoever happens to push next. A tag makes the reference version an explicit, reviewable bump.
The cross-implementation check itself stays worth having after the move. Two independent ports agreeing is what catches an ambiguity in the specification rather than a bug in one of them. That value is unaffected by pinning; only the timing of when a disagreement surfaces changes, from "on someone else's push" to "when we bump the pin".
Acceptance
Blocked on the extraction actually happening. Recorded now so it is not discovered when CI breaks.
Raised by @simontaurus in #129.
The parity step in
.github/workflows/main.yml:73-92clonesOO-LD/oold-schemaat--depth 1off the default branch and runsvalidate.mjsfrom it as the reference harness. Since #133 that step gates the build rather than merely reporting.validate.mjsis being extracted tooold-js. When it moves, the clone has to move with it, and the move is the moment to change two things at once.What has to change
OO-LD/oold-schematooold-jsWhy the pin, given the clone deliberately tracks
maintodayTracking
mainis right while the reference lives inoold-schema, and the comment in the workflow says so: it catches specification drift that the committed fixture snapshot cannot see. The specification and this validator are supposed to move together, so a disagreement is a real signal.That argument does not survive the extraction.
oold-jsis a sibling implementation on its own release schedule, not the specification. Once the step gates, an unpinned clone means any commit landing inoold-jscan turn this repository's CI red for a reason that has nothing to do with a change here, and the failure lands on whoever happens to push next. A tag makes the reference version an explicit, reviewable bump.The cross-implementation check itself stays worth having after the move. Two independent ports agreeing is what catches an ambiguity in the specification rather than a bug in one of them. That value is unaffected by pinning; only the timing of when a disagreement surfaces changes, from "on someone else's push" to "when we bump the pin".
Acceptance
oold-jstag, not a branchBlocked on the extraction actually happening. Recorded now so it is not discovered when CI breaks.
Raised by @simontaurus in #129.