feat: track shipping runtime pins in the drift check

[kyle-sexton]

Summary

Follow-up to #125, addressing its Codex review finding: the removed canary-runtime drift block was incidentally the only watch on runtime pins that still ship. The daily drift check now watches those pins directly:

• Reads the canonical pins from the tree: root global.json (.NET SDK), markdown action's node-version default, ruff action's python-version default.
• Fails closed if any family's pins diverge across the tree (biome/tsc node defaults; pyright/check-jsonschema python defaults; dotnet-build/dotnet-format/dependabot-lock-regen fallback SDK pins vs global.json).
• Compares each agreed pin against the upstream first-party release index within its reviewed major/minor line (same latest_dotnet_sdk/latest_node_runtime/latest_python_runtime lookups the canary block used).
• Absorb-procedure guidance updated to say runtime bumps update every matching default in lockstep.

No linked issue.

Related

• feat!: remove the ci-runner canary and production HA-proof apparatus #125 (canary apparatus removal that orphaned these pins)

Verification

• node --test .github/scripts/*.test.cjs: 191/191 locally.
• actionlint: clean.
• Consistency logic dry-run against the current tree: all families agree (dotnet 10.0.302, node 24.18.0, python 3.14).

🤖 Generated with Claude Code

https://claude.ai/code/session_01TPPLWAtX5BWyEmghrKkYYF

[claude]

Review in progress

• Gather context
• Read changed file
• Review for correctness, security, and guideline alignment
• Post findings

View job run

[claude]

Review complete

• Gather context
• Understand the request
• Read changed files
• Review for correctness, security, and guideline alignment
• Post findings

---

This is a clean, well-structured follow-up. The fail-closed consistency check (diverging sibling pins → hard error before upstream comparison) is exactly the right design; it prevents the drift check from silently picking a stale or incorrect baseline. The test bump from 3→6 curl_small_json calls correctly accounts for the three new runtime fetch functions. One minor correctness issue and two low-priority observations below.

Findings

1. Unescaped dots in grep regex pattern — minor correctness

Line 217:

if ! grep -q "dotnet-version: ${dotnet_current}$" "$file"; then

grep interprets the pattern as a BRE, so . in dotnet_current (e.g. 10.0.302) matches any character — dotnet-version: 10X0Y302 would be a (contrived) false positive. The trailing $ end-of-line anchor is useful to prevent prefix matches, so -F alone isn't a straight swap. The cleanest fix is to escape the dots before interpolating:

if ! grep -q "dotnet-version: ${dotnet_current//./\\.}$" "$file"; then

In practice version strings won't trigger this, but it's a latent correctness gap that's cheap to close. Fix this →

---

2. latest_node_runtime silently skips pre-LTS majors — low priority

Lines 174–181: the jq filter is select(.lts != false and ...). Node 24 entered LTS in October 2025 so this is correct today. But if the canonical pin is ever advanced to a newly-released major before it enters LTS (typically the 6-month window before the October cut), [...] | last would produce null, jq -er would exit non-zero, || latest='' would fire, and the check would silently emit a warning and skip instead of flagging drift. The degradation is graceful (no false alarm, no broken run) but invisible. A comment noting this behaviour — and suggesting the operator should expect the warning during that window — would make the intent explicit.

---

3. Push trigger doesn't include runtime action files — low priority / likely intentional

The new runtime consistency check reads markdown/action.yml, ruff/action.yml, biome/action.yml, tsc/action.yml, pyright/action.yml, check-jsonschema/action.yml, dotnet-build/action.yml, dotnet-format/action.yml, and dependabot-lock-regen.yml. None of these appear in the push: paths: trigger. A pin bump that touches only those files would catch drift at the next daily run rather than on push. If that's intentional (keeping the push trigger scoped to the workflow's own integrity files), it's fine — the daily schedule is the primary cadence anyway. Just noting it in case the intent was broader push coverage.

---

Summary

The core logic is correct and the design choices are sound. Finding #1 is the only concrete correctness gap (unescaped regex metacharacters); findings #2 and #3 are informational. No security concerns — new code does not expand credential scope, does not reach for privileged context, and the three new curl_small_json calls are all read-only fetches to first-party release indexes over HTTPS.

View job run