chore: refresh managed Node runtime to 26.12.1 #8

jercik · 2026-10-24T18:21:05Z

jercik commented

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

Syncs the execution runtime with released Align 15.1.0 and preserves the Node 24.15.0 compatibility leg.

jercik added 1 commit

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

chore: refresh managed Node runtime to 26.12.1

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

Details

Checks / reuse (pull_request) Successful in 6s

Details

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

Details

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

Details

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

Details

Review / Review (pull_request_target) Successful in 3m2s

Details

cfe6f4d6a4

forgejo-actions commented

2026-10-24 18:24:06 +00:00

Review 01M5QJAA06JZ5CCCKSFYBYSMHA — head cfe6f4d6a442fcad7814a9fb28ec285468257fe4

Review — j4k-oss/conventional-commit-msg @ `6621da7a1b`

Scope: diff against base tree 67e5774b8f66
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 project's current Node version is hand-copied into commit-msg.yml and the checks.yml matrix instead of read from `.node-version`

claim: 01M5QJDKW5QKW3ZA9VD9QW70QW
anchor: .forgejo/workflows/commit-msg.yml (snippet)

          # Policy-pinned runtime for the refreshed PR metadata parser.
          node-version: "26.12.1"

lens: aposd-plain · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5QJDZ6R480XVSXCWK0G2GZK · valid: The anchor is grounded (exact): commit-msg.yml pins 'node-version: "26.12.1"' as a literal. The reviewer reports that the same diff bumps .node-version, this literal, and the second checks.yml matrix entry from 26.5.0 to 26.12.1 together. They also report that dedupe-check.yml and release.yml already read 'node-version-file: ".node-version"' and that nothing checks the copies agree. That is the Information Leakage / Repetition red flag: one decision, the project's current runtime, lives in three files that must change together. The cost is already visible, since this change had to edit all three. The 'Policy-pinned' comment is the only counterevidence. It gives no policy, and moving the pin in lockstep with .node-version undercuts the idea that it is independent. The claim says an actual recorded policy would refute only the commit-msg half. The checks.yml half (the matrix's current-runtime leg restating .node-version) holds either way. Medium fits, because the duplicated knowledge must already change together across files. Proposed remedy: read .node-version in commit-msg.yml; derive the matrix entry or add a comment tying it to .node-version.
disposition: none

Bumping the runtime takes three edits that must agree: .node-version, the literal in commit-msg.yml, and the second entry of the checks.yml matrix. This change makes all three edits (26.5.0 → 26.12.1 in each file). Nothing checks that they match, so a future bump that edits only .node-version leaves the commit-msg job and one CI matrix leg on the old runtime without any error. This is information leakage in Ousterhout's sense: one decision, the current runtime, is spread across several modules.

The repository already has a single source for this value. dedupe-check.yml and release.yml both use node-version-file: ".node-version". commit-msg.yml does not, and instead uses node-version: "26.12.1" under the comment # Policy-pinned runtime for the refreshed PR metadata parser. That comment calls the value an independent policy pin, but the change moves it in lockstep with .node-version. So either the comment is wrong, or there is a policy the tree does not record. checks.yml has node: ["24.15.0", "26.12.1"]. Its first entry matches the engines.node floor >=24.15.0 in package.json, and its second entry restates .node-version.

Correction: in commit-msg.yml, switch to node-version-file: ".node-version". That job already checks out the repository before setup-node, and dedupe-check.yml reads the same file under pull_request. Then delete the "Policy-pinned" comment, or rewrite it to give the real reason for a separate pin if one exists. For checks.yml, either read .node-version in a small upstream job and feed it into the matrix, or add a comment beside the matrix saying its last entry must match .node-version.

What I examined: the diff, which is limited to these three files; every node-version and node-version-file use under .forgejo/workflows; package.json engines; and scripts/, AGENTS.md and README.md. I found no consistency check and no documented policy for a separate commit-msg pin. I ran no workflows. If a security or policy reason requires commit-msg to ignore the checked-out .node-version, that would justify keeping the literal there. But the job's own comment says it already executes the PR's helper code, so it trusts PR content anyway. A recorded policy of that kind would refute the commit-msg half of this claim.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (0)
duplicate-of (0)
unadjudicated (1)
- 01M5QJD6BZ250MNTXKMB87KPY1 low — The runtime comment describes the parser by its revision history

Coverage

Coverage pass: 01M5QJAMBGGW0BJSMJTGC6QR0P
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** `01M5QJAA06JZ5CCCKSFYBYSMHA` — head `cfe6f4d6a442fcad7814a9fb28ec285468257fe4` # Review — j4k-oss/conventional-commit-msg @ 6621da7a1b9f Scope: diff against base tree `67e5774b8f66` 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 project's current Node version is hand-copied into commit-msg.yml and the checks.yml matrix instead of read from `.node-version` - claim: `01M5QJDKW5QKW3ZA9VD9QW70QW` - anchor: `.forgejo/workflows/commit-msg.yml` (snippet) ``` # Policy-pinned runtime for the refreshed PR metadata parser. node-version: "26.12.1" ``` - lens: aposd-plain · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5QJDZ6R480XVSXCWK0G2GZK` · valid: The anchor is grounded (exact): commit-msg.yml pins 'node-version: "26.12.1"' as a literal. The reviewer reports that the same diff bumps .node-version, this literal, and the second checks.yml matrix entry from 26.5.0 to 26.12.1 together. They also report that dedupe-check.yml and release.yml already read 'node-version-file: ".node-version"' and that nothing checks the copies agree. That is the Information Leakage / Repetition red flag: one decision, the project's current runtime, lives in three files that must change together. The cost is already visible, since this change had to edit all three. The 'Policy-pinned' comment is the only counterevidence. It gives no policy, and moving the pin in lockstep with .node-version undercuts the idea that it is independent. The claim says an actual recorded policy would refute only the commit-msg half. The checks.yml half (the matrix's current-runtime leg restating .node-version) holds either way. Medium fits, because the duplicated knowledge must already change together across files. Proposed remedy: read .node-version in commit-msg.yml; derive the matrix entry or add a comment tying it to .node-version. - disposition: none > Bumping the runtime takes three edits that must agree: `.node-version`, the literal in commit-msg.yml, and the second entry of the checks.yml matrix. This change makes all three edits (26.5.0 → 26.12.1 in each file). Nothing checks that they match, so a future bump that edits only `.node-version` leaves the commit-msg job and one CI matrix leg on the old runtime without any error. This is information leakage in Ousterhout's sense: one decision, the current runtime, is spread across several modules. > > The repository already has a single source for this value. dedupe-check.yml and release.yml both use `node-version-file: ".node-version"`. commit-msg.yml does not, and instead uses `node-version: "26.12.1"` under the comment `# Policy-pinned runtime for the refreshed PR metadata parser.` That comment calls the value an independent policy pin, but the change moves it in lockstep with `.node-version`. So either the comment is wrong, or there is a policy the tree does not record. checks.yml has `node: ["24.15.0", "26.12.1"]`. Its first entry matches the `engines.node` floor `>=24.15.0` in package.json, and its second entry restates `.node-version`. > > Correction: in commit-msg.yml, switch to `node-version-file: ".node-version"`. That job already checks out the repository before setup-node, and dedupe-check.yml reads the same file under `pull_request`. Then delete the "Policy-pinned" comment, or rewrite it to give the real reason for a separate pin if one exists. For checks.yml, either read `.node-version` in a small upstream job and feed it into the matrix, or add a comment beside the matrix saying its last entry must match `.node-version`. > > What I examined: the diff, which is limited to these three files; every `node-version` and `node-version-file` use under .forgejo/workflows; package.json `engines`; and scripts/, AGENTS.md and README.md. I found no consistency check and no documented policy for a separate commit-msg pin. I ran no workflows. If a security or policy reason requires commit-msg to ignore the checked-out `.node-version`, that would justify keeping the literal there. But the job's own comment says it already executes the PR's helper code, so it trusts PR content anyway. A recorded policy of that kind would refute the commit-msg half of this claim. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (1) - `01M5QJD6BZ250MNTXKMB87KPY1` low — The runtime comment describes the parser by its revision history ## Coverage Coverage pass: 01M5QJAMBGGW0BJSMJTGC6QR0P 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:24:06 +00:00

.forgejo/workflows/commit-msg.yml

Lines 32-33

					
				@ -35,7 +35,7 @@ jobs:

				        uses: actions/setup-node@v6

				        with:

				          # Policy-pinned runtime for the refreshed PR metadata parser.

				          node-version: "26.5.0"

				          node-version: "26.12.1"

medium — The project's current Node version is hand-copied into commit-msg.yml and the checks.yml matrix instead of read from .node-version

Bumping the runtime takes three edits that must agree: .node-version, the literal in commit-msg.yml, and the second entry of the checks.yml matrix. This change makes all three edits (26.5.0 → 26.12.1 in each file). Nothing checks that they match, so a future bump that edits only .node-version leaves the commit-msg job and one CI matrix leg on the old runtime without any error. This is information leakage in Ousterhout's sense: one decision, the current runtime, is spread across several modules.

The repository already has a single source for this value. dedupe-check.yml and release.yml both use node-version-file: ".node-version". commit-msg.yml does not, and instead uses node-version: "26.12.1" under the comment # Policy-pinned runtime for the refreshed PR metadata parser. That comment calls the value an independent policy pin, but the change moves it in lockstep with .node-version. So either the comment is wrong, or there is a policy the tree does not record. checks.yml has node: ["24.15.0", "26.12.1"]. Its first entry matches the engines.node floor >=24.15.0 in package.json, and its second entry restates .node-version.

Correction: in commit-msg.yml, switch to node-version-file: ".node-version". That job already checks out the repository before setup-node, and dedupe-check.yml reads the same file under pull_request. Then delete the "Policy-pinned" comment, or rewrite it to give the real reason for a separate pin if one exists. For checks.yml, either read .node-version in a small upstream job and feed it into the matrix, or add a comment beside the matrix saying its last entry must match .node-version.

What I examined: the diff, which is limited to these three files; every node-version and node-version-file use under .forgejo/workflows; package.json engines; and scripts/, AGENTS.md and README.md. I found no consistency check and no documented policy for a separate commit-msg pin. I ran no workflows. If a security or policy reason requires commit-msg to ignore the checked-out .node-version, that would justify keeping the literal there. But the job's own comment says it already executes the PR's helper code, so it trusts PR content anyway. A recorded policy of that kind would refute the commit-msg half of this claim.

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

**medium** — The project's current Node version is hand-copied into commit-msg.yml and the checks.yml matrix instead of read from `.node-version` > Bumping the runtime takes three edits that must agree: `.node-version`, the literal in commit-msg.yml, and the second entry of the checks.yml matrix. This change makes all three edits (26.5.0 → 26.12.1 in each file). Nothing checks that they match, so a future bump that edits only `.node-version` leaves the commit-msg job and one CI matrix leg on the old runtime without any error. This is information leakage in Ousterhout's sense: one decision, the current runtime, is spread across several modules. > > The repository already has a single source for this value. dedupe-check.yml and release.yml both use `node-version-file: ".node-version"`. commit-msg.yml does not, and instead uses `node-version: "26.12.1"` under the comment `# Policy-pinned runtime for the refreshed PR metadata parser.` That comment calls the value an independent policy pin, but the change moves it in lockstep with `.node-version`. So either the comment is wrong, or there is a policy the tree does not record. checks.yml has `node: ["24.15.0", "26.12.1"]`. Its first entry matches the `engines.node` floor `>=24.15.0` in package.json, and its second entry restates `.node-version`. > > Correction: in commit-msg.yml, switch to `node-version-file: ".node-version"`. That job already checks out the repository before setup-node, and dedupe-check.yml reads the same file under `pull_request`. Then delete the "Policy-pinned" comment, or rewrite it to give the real reason for a separate pin if one exists. For checks.yml, either read `.node-version` in a small upstream job and feed it into the matrix, or add a comment beside the matrix saying its last entry must match `.node-version`. > > What I examined: the diff, which is limited to these three files; every `node-version` and `node-version-file` use under .forgejo/workflows; package.json `engines`; and scripts/, AGENTS.md and README.md. I found no consistency check and no documented policy for a separate commit-msg pin. I ran no workflows. If a security or policy reason requires commit-msg to ignore the checked-out `.node-version`, that would justify keeping the literal there. But the job's own comment says it already executes the PR's helper code, so it trusts PR content anyway. A recorded policy of that kind would refute the commit-msg half of this claim. lens `aposd-plain` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5QJDKW5QKW3ZA9VD9QW70QW` of review `01M5QJAA06JZ5CCCKSFYBYSMHA`

👎 1

The duplicated literals are present, but they are generated outputs of released Align 15.1.0's single nodeExecutionVersionPolicy, not independent repository decisions. I reproduced the existing detector on in-memory copies of both workflows with only 26.12.1 changed to 26.5.0: analyzeSetupNodeSteps reports a finding for each. The full released Align audit of this exact head exits 0, and rendering all three files again is idempotent. Thus the assertion that nothing detects a missed copy is false. This PR retains the published generated contract and the 24.15.0 compatibility leg. A different template design is outside this bounded runtime refresh; no claim is made that the duplicated literals were removed.

The duplicated literals are present, but they are generated outputs of released Align 15.1.0's single nodeExecutionVersionPolicy, not independent repository decisions. I reproduced the existing detector on in-memory copies of both workflows with only 26.12.1 changed to 26.5.0: analyzeSetupNodeSteps reports a finding for each. The full released Align audit of this exact head exits 0, and rendering all three files again is idempotent. Thus the assertion that nothing detects a missed copy is false. This PR retains the published generated contract and the 24.15.0 compatibility leg. A different template design is outside this bounded runtime refresh; no claim is made that the duplicated literals were removed.

jercik marked this conversation as resolved

jercik commented

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

Claim 01M5QJD6BZ250MNTXKMB87KPY1 (low): I checked the unchanged generated comment, Policy-pinned runtime for the refreshed PR metadata parser. The word refreshed is a revision reference that could be clearer, but it adds no wrong runtime requirement or missing operational step. This optional wording improvement remains unfixed: this PR is limited to the shipped three-file runtime refresh, and its comment is generated by released Align 15.1.0. No repository-specific template divergence or policy change is included.

Claim `01M5QJD6BZ250MNTXKMB87KPY1` (low): I checked the unchanged generated comment, `Policy-pinned runtime for the refreshed PR metadata parser.` The word `refreshed` is a revision reference that could be clearer, but it adds no wrong runtime requirement or missing operational step. This optional wording improvement remains unfixed: this PR is limited to the shipped three-file runtime refresh, and its comment is generated by released Align 15.1.0. No repository-specific template divergence or policy change is included.

🚀 1

jercik merged commit 9559435b9d into main

2026-10-24 18:27:56 +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/conventional-commit-msg!8

Rows
Columns

chore: refresh managed Node runtime to 26.12.1 #8

Review — j4k-oss/conventional-commit-msg @ 6621da7a1b

Findings (1)

medium — The project's current Node version is hand-copied into commit-msg.yml and the checks.yml matrix instead of read from .node-version

Other claims

Coverage

Review — j4k-oss/conventional-commit-msg @ `6621da7a1b`

medium — The project's current Node version is hand-copied into commit-msg.yml and the checks.yml matrix instead of read from `.node-version`