Context
PR #311 ships a committed compiled artifact: scripts/check-ts-allowlist.deno.js, generated by affinescript compile --deno-esm from scripts/check-ts-allowlist.affine. The workflow now invokes the .deno.js directly instead of running the AS toolchain in CI.
The same pattern is established in hyperpolymath/affinescript/tests/codegen-deno/*.deno.js (committed golden files). It's the right call for CI ergonomics — but it introduces a drift risk: if someone edits the .affine source without re-running the compiler and committing the resulting .deno.js, the workflow keeps executing stale generated code.
Proposed lint
Add a just check-ts-allowlist-drift recipe + non-blocking CI step:
# Verify scripts/check-ts-allowlist.deno.js matches what compiling
# the .affine source would produce. Run after editing the .affine.
check-ts-allowlist-drift:
affinescript compile --deno-esm -o /tmp/_drift.deno.js scripts/check-ts-allowlist.affine
diff -u scripts/check-ts-allowlist.deno.js /tmp/_drift.deno.js
rm /tmp/_drift.deno.js
Wire as a non-blocking CI step (matrix-style if more committed-artifact pairs land later):
- name: check-ts-allowlist source/compile drift
continue-on-error: true # non-blocking — informational until pattern stabilises
run: just check-ts-allowlist-drift
Why non-blocking initially
- AS compiler output isn't yet declared deterministic across compiler bumps (the compiler stamps
Generated by AffineScript compiler header, which is a moving target as the codegen evolves).
- Until the compile output is hash-pinned per compiler version, drift = "someone touched the .affine without recompiling" OR "compiler bump changed the canonical output" — second case shouldn't block PRs.
- Promotion to blocking happens after a compiler-version pin lands (separate concern).
Scope
- This issue: just the recipe + CI step for
check-ts-allowlist.{affine,deno.js}.
- Future: generalise to any
*.affine/*.deno.js pair under scripts/ (probably automate via a find loop in the justfile recipe).
Acceptance
Refs #283 (.affine seed), #310 (compile fixes), #311 (workflow swap), #239 / #241 (TS→AffineScript umbrella).
Context
PR #311 ships a committed compiled artifact:
scripts/check-ts-allowlist.deno.js, generated byaffinescript compile --deno-esmfromscripts/check-ts-allowlist.affine. The workflow now invokes the.deno.jsdirectly instead of running the AS toolchain in CI.The same pattern is established in
hyperpolymath/affinescript/tests/codegen-deno/*.deno.js(committed golden files). It's the right call for CI ergonomics — but it introduces a drift risk: if someone edits the.affinesource without re-running the compiler and committing the resulting.deno.js, the workflow keeps executing stale generated code.Proposed lint
Add a
just check-ts-allowlist-driftrecipe + non-blocking CI step:Wire as a non-blocking CI step (matrix-style if more committed-artifact pairs land later):
Why non-blocking initially
Generated by AffineScript compilerheader, which is a moving target as the codegen evolves).Scope
check-ts-allowlist.{affine,deno.js}.*.affine/*.deno.jspair underscripts/(probably automate via a find loop in the justfile recipe).Acceptance
just check-ts-allowlist-driftworks locally (exits 0 when in sync, non-zero with diff output when drifted)governance-reusable.ymlnear the existing TS-allowlist run, or a sibling workflow)scripts/check-ts-allowlist.affineheader pointing maintainers at the recipeRefs #283 (.affine seed), #310 (compile fixes), #311 (workflow swap), #239 / #241 (TS→AffineScript umbrella).