ci: gate spacecraft.css against the canonical palette - #37
Conversation
This repository's HTML output embeds spacecraft.css verbatim — `texi2any --css-include=spacecraft.css` — so a colour that drifts from steelbore.toml is a wrong colour in the published document, with the build still passing and nothing anywhere reporting it. The file is the palette's third mirror, after steelbore.scm and the palette prose, and was the only one with no drift gate in either repository that carries it. The checker and the canonical palette both live in Construct, which the skill-refs job already checks out read-only for check-skill-refs.py. This step reuses that checkout and follows the same dependency direction: the Standard cites the catalogue, so the Standard validates against it. This copy is compared to the same steelbore.toml the skills use, and to Construct's own copy — all three copies are byte-identical by design, so divergence between them is drift in its own right. The Construct side, which adds check-palette-css.py itself, is a separate PR on that repository. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eacd61243e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # which is already checked out above; this copy is compared against the same | ||
| # steelbore.toml the skills use, and against Construct's own copy, which is | ||
| # byte-identical by design. | ||
| - name: spacecraft.css matches the canonical palette |
There was a problem hiding this comment.
Commit 69241b339f58611e55f09fc668d322559905acf1 has no gpgsig header, so GitHub cannot mark this revision Verified. Recreate the commit with a valid cryptographic signature before merging.
AGENTS.md reference: AGENTS.md:L83-L90
Useful? React with 👍 / 👎.
| - name: spacecraft.css matches the canonical palette | ||
| run: | | ||
| python3 .construct/.github/check-palette-css.py \ | ||
| --toml .construct/steelbore-color-palette/assets/steelbore.toml \ | ||
| spacecraft.css \ | ||
| .construct/steelbore-color-palette/assets/spacecraft.css |
There was a problem hiding this comment.
Update the documented CI gate list
This adds a required check to every PR and main push, but the authoritative AGENTS.md CI section still says the workflow has only the REUSE and configuration-validation gates. Update that section and its workflow summary so contributors are told about the external Construct dependency and the new palette check.
AGENTS.md reference: AGENTS.md:L54-L59
Useful? React with 👍 / 👎.
Why
This repository's HTML output embeds
spacecraft.cssverbatim —texi2any --css-include=spacecraft.css. A colour that drifts fromsteelbore.tomlis therefore a wrong colour in the published document, with the build still passing and nothing anywhere reporting it.The file is the palette's third mirror, after
steelbore.scmand the palette prose, and was the only one with no drift gate — in either repository that carries it.How
The checker and the canonical palette both live in Construct, which the
skill-refsjob already checks out read-only forcheck-skill-refs.py. This step reuses that checkout and follows the same dependency direction the job comment already states: the Standard cites the catalogue, so the Standard validates against it.Both copies are passed, not just this one. All three copies across the two repos (
spacecraft-texinfo-documentships one too) are byte-identical by design —b80aa99e…— so divergence between them is drift in its own right, separate from divergence from the TOML.Verified locally
Simulating the exact CI invocation against a real Construct checkout:
And the three drift classes the checker catches, each fault-injected on the Construct side: a changed value, a renamed custom property, and a literal outside a
var(--…)declaration — all exit 1.The workflow was parsed with PyYAML to confirm the new step lands in the
skill-refsjob and is structurally well-formed; an earlier attempt inserted it inside the preceding step, which the parse caught.🤖 Generated with Claude Code