chore: refresh managed node runtime #9

jercik · 2026-10-24T18:54:59Z

jercik commented

2026-10-24 18:54:59 +00:00

Refreshes managed Node pins to the published Align runtime, 26.12.1. Preserves the Node 24.15.0 compatibility check.

jercik added 1 commit

2026-10-24 18:54:59 +00:00

chore: refresh managed node runtime

Checks / pr-flow-canary (pull_request) Has been skipped

Details

Checks / reuse (pull_request) Successful in 5s

Details

commit-msg / commitlint (pull_request) Successful in 9s

Details

Checks / quality-checks (24.15.0) (pull_request) Successful in 43s

Details

Checks / quality-checks (26.12.1) (pull_request) Successful in 43s

Details

Review / Review (pull_request_target) Successful in 2m51s

Details

3101eb5462

forgejo-actions commented

2026-10-24 18:57:50 +00:00

Review 01M5QM8CRMYG75S33R18P2W68Q — head 3101eb54628340117f3d2d3a3ae133a67df0e008

Review — j4k-oss/askpplx @ `39e79a9463`

Scope: diff against base tree 0a867bf9a11c
Review finished: 10 succeeded, 0 failed
Triage: settled
Facts: current review-wide projection

Computed under:

{
  "abandonment": "abandonment-v1",
  "anchor_recipe": 1,
  "batch_policy": "batch-v1",
  "coverage": "coverage-v3",
  "dispatch_policy": "dispatch-v2",
  "grounder_version": 1,
  "grounding_read_rule": "grounding-read-v1",
  "promotion_policy": "promotion-v1",
  "report": "report-v5",
  "tally": "tally-v1",
  "triage_settle": "triage-settle-v2"
}

Findings (1)

medium — The current Node runtime is restated as a literal in checks.yml and commit-msg.yml instead of being read from .node-version

claim: 01M5QMB091E97QJZWTS4WEA0TQ
anchor: .forgejo/workflows/checks.yml (snippet)

        node: ["24.15.0", "26.12.1"]

lens: aposd-plain · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5QMBHY6SJW3RXJ778BS1MB5 · valid: Grounded anchor: checks.yml has the matrix 'node: ["24.15.0", "26.12.1"]'. The reviewer also reports node-version: "26.12.1" in commit-msg.yml's commitlint job, .node-version set to 26.12.1, and engines.node '>=24.15.0' in package.json. The reviewer says the three 26.5.0 lines changed together in this diff, so this change both edits the duplicated decision and shows its cost. Duplicated knowledge that must change in lockstep is information leakage (APoSD 2e §5.2), and the cost already lands on present code, which supports medium. The mechanism holds: if a later bump to .node-version misses checks.yml, CI keeps testing an undeclared runtime and the check stays green. The skill's limits don't excuse the checks.yml copy. On repository convention, the reviewer reports that release.yml and dedupe-check.yml already read the version through node-version-file, so the single-authority form is the established one. No test pins the coupling. The commit-msg pin may be deliberately separate, because node-version-file in a job that checks out the PR head would let the PR choose the runtime that parses its metadata. The reviewer flags this as unconfirmed and limits the fix there to stating the policy, so that open question doesn't weaken the checks.yml finding. The reviewer's hedge on whether Forgejo's setup-node accepts node-version-file through a matrix include is a remedy detail. If it doesn't, a smaller fix is a setup step that reads .node-version into an output.
disposition: none

Which Node runtime the project targets is one design decision, but it lives in three places. Because of that, this one-value bump had to edit three files in lockstep. If a later bump changes .node-version but misses one of the copies, nothing fails: CI keeps testing and parsing with a runtime the project no longer declares, and the green check gives no hint of it. This is information leakage in Ousterhout's sense: the version decision leaks out of its owning file into each workflow that needs it.

The value 26.12.1 appears in .node-version, in the quality-checks matrix in .forgejo/workflows/checks.yml (node: ["24.15.0", "26.12.1"]), and as node-version: "26.12.1" in the commitlint job of .forgejo/workflows/commit-msg.yml. The matrix's other entry, 24.15.0, restates the engines.node floor ">=24.15.0" in package.json. The repository already uses the single-authority form elsewhere: release.yml and dedupe-check.yml both run actions/setup-node@v6 with node-version-file: ".node-version".

Fix: have checks.yml read the current runtime from the file. One way is a matrix include with one entry for the engines floor and one that sets node-version-file: .node-version, passing whichever is set to setup-node. commit-msg.yml has a reason to differ. Its comment reads # Policy-pinned runtime for the refreshed PR metadata parser., and that job checks out the PR head, so node-version-file there would let the PR choose the runtime that parses PR metadata while GITHUB_TOKEN is in scope. If that is the policy, the comment should say so and say whether the pin must track .node-version. As written, the comment names a policy without stating it, and the value has moved in lockstep with .node-version.

The base side's three 26.5.0 lines (old .node-version, old matrix entry, old commit-msg pin) all changed together in this diff, which is why I say the copies are maintained by hand. I grepped the tree for 26.12, 24.15 and node-version and found no other copies. Static reading only: I did not run the workflows. Two things are unconfirmed. First, whether the commit-msg pin is intentionally separate from .node-version; an owner's statement of that policy would settle it. Second, whether Forgejo's setup-node accepts node-version-file from a matrix include.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (0)
duplicate-of (0)
unadjudicated (1)
- 01M5QMA3T00C15QP07ZW66XF55 low — The runtime comment carries transient parser revision history

Coverage

Coverage pass: 01M5QM8CSXDY5G4SMYEZ6NASJN
Accounting: complete (all slots terminal; see slot results for failures)
Slot health: healthy

lens	part	arm	unit status	runs	loss
general-bug	whole	default	no-claims	1	no
writing-quality	whole	default	claims-emitted	1	no
test-trimming	whole	default	no-claims	1	no
restated-sets	whole	default	no-claims	1	no
project-docs	whole	default	no-claims	1	no
unix-cli	whole	default	no-claims	1	no
use-effect	whole	default	no-claims	1	no
module-design	whole	default	no-claims	1	no
aposd-plain	whole	default	claims-emitted	1	no
react	whole	default	no-claims	1	no

**Review** `01M5QM8CRMYG75S33R18P2W68Q` — head `3101eb54628340117f3d2d3a3ae133a67df0e008` # Review — j4k-oss/askpplx @ 39e79a946334 Scope: diff against base tree `0a867bf9a11c` Review finished: 10 succeeded, 0 failed Triage: settled Facts: current review-wide projection Computed under: ```json { "abandonment": "abandonment-v1", "anchor_recipe": 1, "batch_policy": "batch-v1", "coverage": "coverage-v3", "dispatch_policy": "dispatch-v2", "grounder_version": 1, "grounding_read_rule": "grounding-read-v1", "promotion_policy": "promotion-v1", "report": "report-v5", "tally": "tally-v1", "triage_settle": "triage-settle-v2" } ``` ## Findings (1) ### medium — The current Node runtime is restated as a literal in checks.yml and commit-msg.yml instead of being read from .node-version - claim: `01M5QMB091E97QJZWTS4WEA0TQ` - anchor: `.forgejo/workflows/checks.yml` (snippet) ``` node: ["24.15.0", "26.12.1"] ``` - lens: aposd-plain · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5QMBHY6SJW3RXJ778BS1MB5` · valid: Grounded anchor: checks.yml has the matrix 'node: ["24.15.0", "26.12.1"]'. The reviewer also reports node-version: "26.12.1" in commit-msg.yml's commitlint job, .node-version set to 26.12.1, and engines.node '>=24.15.0' in package.json. The reviewer says the three 26.5.0 lines changed together in this diff, so this change both edits the duplicated decision and shows its cost. Duplicated knowledge that must change in lockstep is information leakage (APoSD 2e §5.2), and the cost already lands on present code, which supports medium. The mechanism holds: if a later bump to .node-version misses checks.yml, CI keeps testing an undeclared runtime and the check stays green. The skill's limits don't excuse the checks.yml copy. On repository convention, the reviewer reports that release.yml and dedupe-check.yml already read the version through node-version-file, so the single-authority form is the established one. No test pins the coupling. The commit-msg pin may be deliberately separate, because node-version-file in a job that checks out the PR head would let the PR choose the runtime that parses its metadata. The reviewer flags this as unconfirmed and limits the fix there to stating the policy, so that open question doesn't weaken the checks.yml finding. The reviewer's hedge on whether Forgejo's setup-node accepts node-version-file through a matrix include is a remedy detail. If it doesn't, a smaller fix is a setup step that reads .node-version into an output. - disposition: none > Which Node runtime the project targets is one design decision, but it lives in three places. Because of that, this one-value bump had to edit three files in lockstep. If a later bump changes `.node-version` but misses one of the copies, nothing fails: CI keeps testing and parsing with a runtime the project no longer declares, and the green check gives no hint of it. This is information leakage in Ousterhout's sense: the version decision leaks out of its owning file into each workflow that needs it. > > The value `26.12.1` appears in `.node-version`, in the `quality-checks` matrix in `.forgejo/workflows/checks.yml` (`node: ["24.15.0", "26.12.1"]`), and as `node-version: "26.12.1"` in the `commitlint` job of `.forgejo/workflows/commit-msg.yml`. The matrix's other entry, `24.15.0`, restates the `engines.node` floor `">=24.15.0"` in `package.json`. The repository already uses the single-authority form elsewhere: `release.yml` and `dedupe-check.yml` both run `actions/setup-node@v6` with `node-version-file: ".node-version"`. > > Fix: have checks.yml read the current runtime from the file. One way is a matrix `include` with one entry for the `engines` floor and one that sets `node-version-file: .node-version`, passing whichever is set to setup-node. commit-msg.yml has a reason to differ. Its comment reads `# Policy-pinned runtime for the refreshed PR metadata parser.`, and that job checks out the PR head, so `node-version-file` there would let the PR choose the runtime that parses PR metadata while `GITHUB_TOKEN` is in scope. If that is the policy, the comment should say so and say whether the pin must track `.node-version`. As written, the comment names a policy without stating it, and the value has moved in lockstep with `.node-version`. > > The base side's three `26.5.0` lines (old `.node-version`, old matrix entry, old commit-msg pin) all changed together in this diff, which is why I say the copies are maintained by hand. I grepped the tree for `26.12`, `24.15` and `node-version` and found no other copies. Static reading only: I did not run the workflows. Two things are unconfirmed. First, whether the commit-msg pin is intentionally separate from `.node-version`; an owner's statement of that policy would settle it. Second, whether Forgejo's setup-node accepts `node-version-file` from a matrix `include`. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (1) - `01M5QMA3T00C15QP07ZW66XF55` low — The runtime comment carries transient parser revision history ## Coverage Coverage pass: 01M5QM8CSXDY5G4SMYEZ6NASJN Accounting: complete (all slots terminal; see slot results for failures) Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | general-bug | whole | default | no-claims | 1 | no | | writing-quality | whole | default | claims-emitted | 1 | no | | test-trimming | whole | default | no-claims | 1 | no | | restated-sets | whole | default | no-claims | 1 | no | | project-docs | whole | default | no-claims | 1 | no | | unix-cli | whole | default | no-claims | 1 | no | | use-effect | whole | default | no-claims | 1 | no | | module-design | whole | default | no-claims | 1 | no | | aposd-plain | whole | default | claims-emitted | 1 | no | | react | whole | default | no-claims | 1 | no |

🚀 1

forgejo-actions reviewed

2026-10-24 18:57:50 +00:00

.forgejo/workflows/checks.yml

					
				@ -125,3 +125,3 @@

				    strategy:

				      matrix:

				        node: ["24.15.0", "26.5.0"]

				        node: ["24.15.0", "26.12.1"]

medium — The current Node runtime is restated as a literal in checks.yml and commit-msg.yml instead of being read from .node-version

Which Node runtime the project targets is one design decision, but it lives in three places. Because of that, this one-value bump had to edit three files in lockstep. If a later bump changes .node-version but misses one of the copies, nothing fails: CI keeps testing and parsing with a runtime the project no longer declares, and the green check gives no hint of it. This is information leakage in Ousterhout's sense: the version decision leaks out of its owning file into each workflow that needs it.

The value 26.12.1 appears in .node-version, in the quality-checks matrix in .forgejo/workflows/checks.yml (node: ["24.15.0", "26.12.1"]), and as node-version: "26.12.1" in the commitlint job of .forgejo/workflows/commit-msg.yml. The matrix's other entry, 24.15.0, restates the engines.node floor ">=24.15.0" in package.json. The repository already uses the single-authority form elsewhere: release.yml and dedupe-check.yml both run actions/setup-node@v6 with node-version-file: ".node-version".

Fix: have checks.yml read the current runtime from the file. One way is a matrix include with one entry for the engines floor and one that sets node-version-file: .node-version, passing whichever is set to setup-node. commit-msg.yml has a reason to differ. Its comment reads # Policy-pinned runtime for the refreshed PR metadata parser., and that job checks out the PR head, so node-version-file there would let the PR choose the runtime that parses PR metadata while GITHUB_TOKEN is in scope. If that is the policy, the comment should say so and say whether the pin must track .node-version. As written, the comment names a policy without stating it, and the value has moved in lockstep with .node-version.

The base side's three 26.5.0 lines (old .node-version, old matrix entry, old commit-msg pin) all changed together in this diff, which is why I say the copies are maintained by hand. I grepped the tree for 26.12, 24.15 and node-version and found no other copies. Static reading only: I did not run the workflows. Two things are unconfirmed. First, whether the commit-msg pin is intentionally separate from .node-version; an owner's statement of that policy would settle it. Second, whether Forgejo's setup-node accepts node-version-file from a matrix include.

lens aposd-plain · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5QMB091E97QJZWTS4WEA0TQ of review 01M5QM8CRMYG75S33R18P2W68Q

**medium** — The current Node runtime is restated as a literal in checks.yml and commit-msg.yml instead of being read from .node-version > Which Node runtime the project targets is one design decision, but it lives in three places. Because of that, this one-value bump had to edit three files in lockstep. If a later bump changes `.node-version` but misses one of the copies, nothing fails: CI keeps testing and parsing with a runtime the project no longer declares, and the green check gives no hint of it. This is information leakage in Ousterhout's sense: the version decision leaks out of its owning file into each workflow that needs it. > > The value `26.12.1` appears in `.node-version`, in the `quality-checks` matrix in `.forgejo/workflows/checks.yml` (`node: ["24.15.0", "26.12.1"]`), and as `node-version: "26.12.1"` in the `commitlint` job of `.forgejo/workflows/commit-msg.yml`. The matrix's other entry, `24.15.0`, restates the `engines.node` floor `">=24.15.0"` in `package.json`. The repository already uses the single-authority form elsewhere: `release.yml` and `dedupe-check.yml` both run `actions/setup-node@v6` with `node-version-file: ".node-version"`. > > Fix: have checks.yml read the current runtime from the file. One way is a matrix `include` with one entry for the `engines` floor and one that sets `node-version-file: .node-version`, passing whichever is set to setup-node. commit-msg.yml has a reason to differ. Its comment reads `# Policy-pinned runtime for the refreshed PR metadata parser.`, and that job checks out the PR head, so `node-version-file` there would let the PR choose the runtime that parses PR metadata while `GITHUB_TOKEN` is in scope. If that is the policy, the comment should say so and say whether the pin must track `.node-version`. As written, the comment names a policy without stating it, and the value has moved in lockstep with `.node-version`. > > The base side's three `26.5.0` lines (old `.node-version`, old matrix entry, old commit-msg pin) all changed together in this diff, which is why I say the copies are maintained by hand. I grepped the tree for `26.12`, `24.15` and `node-version` and found no other copies. Static reading only: I did not run the workflows. Two things are unconfirmed. First, whether the commit-msg pin is intentionally separate from `.node-version`; an owner's statement of that policy would settle it. Second, whether Forgejo's setup-node accepts `node-version-file` from a matrix `include`. lens `aposd-plain` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5QMB091E97QJZWTS4WEA0TQ` of review `01M5QM8CRMYG75S33R18P2W68Q`

👎 1

The duplicated literals are present, but they are generated displays of the released Align policy, not independent hand-maintained decisions. This PR used Align15.2.0's actual trait/context renderer for all three full files; regeneration is byte-identical. That release defines execution26.12.1 and compatibility24.15.0 centrally in dist/alignment/policy.js.

The assertion that missing one copy is undetected does not hold for the managed audit. I passed in-memory stale versions of checks.yml and commit-msg.yml to the released analyzeSetupNodeSteps implementation. It reports a runtime finding for each; no repository file was changed. The clean committed checkout also passed the complete15.2.0 audit. Evidence is retained in cohort5-detector-reproduction.json and cohort5-askpplx-audit-final.json.

The literal matrix and commit-msg pin are the shipped template contract. Reading the file dynamically is a different shared-template design, not a missing part of this mechanical refresh. This PR retains that contract and the24.15.0 compatibility leg. No claim is made that CI itself runs Align or automatically rejects every future drift; the existing managed checker and renderer detect it. No policy redesign or wording change is included.

The duplicated literals are present, but they are generated displays of the released Align policy, not independent hand-maintained decisions. This PR used Align15.2.0's actual trait/context renderer for all three full files; regeneration is byte-identical. That release defines execution26.12.1 and compatibility24.15.0 centrally in dist/alignment/policy.js. The assertion that missing one copy is undetected does not hold for the managed audit. I passed in-memory stale versions of checks.yml and commit-msg.yml to the released analyzeSetupNodeSteps implementation. It reports a runtime finding for each; no repository file was changed. The clean committed checkout also passed the complete15.2.0 audit. Evidence is retained in cohort5-detector-reproduction.json and cohort5-askpplx-audit-final.json. The literal matrix and commit-msg pin are the shipped template contract. Reading the file dynamically is a different shared-template design, not a missing part of this mechanical refresh. This PR retains that contract and the24.15.0 compatibility leg. No claim is made that CI itself runs Align or automatically rejects every future drift; the existing managed checker and renderer detect it. No policy redesign or wording change is included.

jercik marked this conversation as resolved

jercik commented

2026-10-24 18:59:05 +00:00

For unadjudicated claim 01M5QMA3T00C15QP07ZW66XF55 (low, transient parser revision history): the unchanged generated comment says "refreshed PR metadata parser". That wording can be clearer and more durable; it is not fixed by this runtime-only refresh. The released Align15.2.0 template renders the existing wording unchanged, and the full output is byte-identical on regeneration. This PR keeps the authorized runtime substitution only. Shared wording or pinning-policy redesign is outside this delivery scope; no new policy or follow-up framework is introduced, and no wording fix is claimed.

For unadjudicated claim `01M5QMA3T00C15QP07ZW66XF55` (low, transient parser revision history): the unchanged generated comment says "refreshed PR metadata parser". That wording can be clearer and more durable; it is not fixed by this runtime-only refresh. The released Align15.2.0 template renders the existing wording unchanged, and the full output is byte-identical on regeneration. This PR keeps the authorized runtime substitution only. Shared wording or pinning-policy redesign is outside this delivery scope; no new policy or follow-up framework is introduced, and no wording fix is claimed.

🚀 1

jercik merged commit 6d46c5d2bc into main

2026-10-24 19:04:26 +00:00

Sign in to join this conversation.

No reviewers

No labels

No milestone

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

j4k-oss/askpplx!9

Rows
Columns