j4k-oss/fta-check
Watch
2
0
Fork
You've already forked fta-check
 0
Code Issues Pull requests Releases 5 Packages 1 Activity Actions

chore: refresh managed Node runtime to 26.12.1 #13

Merged
jercik merged 1 commit from chore/align-runtime-26-12-1 into main 2026-10-24 18:28:01 +00:00
Conversation 3 Commits 1 Files changed 3 +3 -3
jercik commented 2026-10-24 18:21:07 +00:00
Owner

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

Syncs the execution runtime with released Align 15.1.0 and preserves the Node 24.15.0 compatibility leg.
chore: refresh managed Node runtime to 26.12.1
All checks were successful
Checks / pr-flow-canary (pull_request) Has been skipped
Details
Checks / reuse (pull_request) Successful in 7s
Details
commit-msg / commitlint (pull_request) Successful in 10s
Details
Checks / quality-checks (24.15.0) (pull_request) Successful in 40s
Details
Checks / quality-checks (26.12.1) (pull_request) Successful in 42s
Details
Review / Review (pull_request_target) Successful in 3m51s
Details
6bc9ecb4ba
forgejo-actions commented 2026-10-24 18:24:57 +00:00

Review 01M5QJACSZMSHGHM14W8EMR1CT — head 6bc9ecb4ba1e29ad29568e985cee4df687dcbcf8

Review — j4k-oss/fta-check @ 7fec3b4ec8

Scope: diff against base tree 071316b10e6a
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.js version is hard-coded in commit-msg.yml and checks.yml instead of read from .node-version, so one version decision needs three matching edits

  • claim: 01M5QJEFW73QTN7K4KY982QZJQ
  • 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 01M5QJEWTRSFSXVRW4NGP4BANV · valid: The grounded anchor confirms the literal 'node-version: "26.12.1"' under the 'Policy-pinned' comment in commit-msg.yml. The reviewer quotes the other copies: .node-version, and the checks.yml matrix 'node: ["24.15.0", "26.12.1"]'. The reviewer also reports that release.yml and dedupe-check.yml already read 'node-version-file: ".node-version"' with actions/setup-node@v6, and dedupe-check.yml does so on pull_request. This account is specific and consistent. The cost is visible in this change: one decision, the current runtime, needed three matching edits, and nothing checks that the copies agree. That is the information-leakage and repetition red flag, with change amplification landing on present code, and the changed lines are in scope. The checks.yml current leg is the clearest case. The 24.15.0 leg matches engines.node and is a separate decision, but the second leg repeats the value that .node-version defines for release.yml. For commit-msg.yml, the word 'Policy-pinned' may record a deliberate choice not to run the token-bearing node step on a runtime chosen by the PR head. A deliberate choice like that is not a defect just because an alternative exists. The claim covers this case: if the pin is deliberate, the comment should say why, and keeping it still does not justify the checks.yml copy. No limit from the module-design skill rescues that copy. I would rate this low to medium: medium for the checks.yml duplication, and less if the commit-msg pin is confirmed as policy.
  • disposition: none

Bumping Node.js to 26.12.1 took identical edits in three files: .node-version, the node-version: "26.12.1" literal in commit-msg.yml, and the second matrix entry in checks.yml (node: ["24.15.0", "26.12.1"]). Nothing checks that the three agree. A later bump that edits only .node-version leaves the commit-msg job and the newer quality-checks leg on the old runtime without any error. In APOSD terms this is information leakage and repetition: one design decision, "the current runtime", is spread across several modules.

The repository already has a single authority for this value. release.yml and dedupe-check.yml both use node-version-file: ".node-version" with actions/setup-node@v6. dedupe-check.yml runs on pull_request against the PR checkout, so reading .node-version from a PR head is already accepted practice here.

Fix: have commit-msg.yml use node-version-file: ".node-version". In checks.yml, keep the 24.15.0 minimum-supported leg, which matches package.json engines.node: ">=24.15.0", and source the current leg from .node-version. One way is a matrix entry that sets node-version-file instead of node-version. If commit-msg.yml has to stay independent of the PR head's .node-version, because its token-bearing node -e step must not run on a runtime the PR chooses, the comment # Policy-pinned runtime for the refreshed PR metadata parser. should say so. As written, it gives no reason the pin cannot follow .node-version, so the next maintainer will either miss it during a bump or "clean it up".

What I examined: the diff (three one-line edits), the full checks.yml, commit-msg.yml, dedupe-check.yml, and the setup-node steps in release.yml, plus a repository-wide grep for node-version and the version strings. I could not find any policy document defining "policy-pinned". Such a document, requiring the commit-msg runtime to be fixed in the base workflow, would justify keeping that copy, but it would still call for a comment explaining why. It would not justify the copy in checks.yml.

Other claims

  • grounding-pending (0)
  • ungrounded (0)
  • rejected (0)
  • duplicate-of (0)
  • unadjudicated (1)
    • 01M5QJE1Q67RV3B1AAM6PP44M5 low — The runtime comment carries an unnecessary parser revision reference

Coverage

Coverage pass: 01M5QJAT70880KWSTZAZCGYF8W
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:summary --> **Review** `01M5QJACSZMSHGHM14W8EMR1CT` — head `6bc9ecb4ba1e29ad29568e985cee4df687dcbcf8` # Review — j4k-oss/fta-check @ 7fec3b4ec8a3 Scope: diff against base tree `071316b10e6a` 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.js version is hard-coded in commit-msg.yml and checks.yml instead of read from `.node-version`, so one version decision needs three matching edits - claim: `01M5QJEFW73QTN7K4KY982QZJQ` - 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 `01M5QJEWTRSFSXVRW4NGP4BANV` · valid: The grounded anchor confirms the literal 'node-version: "26.12.1"' under the 'Policy-pinned' comment in commit-msg.yml. The reviewer quotes the other copies: .node-version, and the checks.yml matrix 'node: ["24.15.0", "26.12.1"]'. The reviewer also reports that release.yml and dedupe-check.yml already read 'node-version-file: ".node-version"' with actions/setup-node@v6, and dedupe-check.yml does so on pull_request. This account is specific and consistent. The cost is visible in this change: one decision, the current runtime, needed three matching edits, and nothing checks that the copies agree. That is the information-leakage and repetition red flag, with change amplification landing on present code, and the changed lines are in scope. The checks.yml current leg is the clearest case. The 24.15.0 leg matches engines.node and is a separate decision, but the second leg repeats the value that .node-version defines for release.yml. For commit-msg.yml, the word 'Policy-pinned' may record a deliberate choice not to run the token-bearing node step on a runtime chosen by the PR head. A deliberate choice like that is not a defect just because an alternative exists. The claim covers this case: if the pin is deliberate, the comment should say why, and keeping it still does not justify the checks.yml copy. No limit from the module-design skill rescues that copy. I would rate this low to medium: medium for the checks.yml duplication, and less if the commit-msg pin is confirmed as policy. - disposition: none > Bumping Node.js to 26.12.1 took identical edits in three files: `.node-version`, the `node-version: "26.12.1"` literal in `commit-msg.yml`, and the second matrix entry in `checks.yml` (`node: ["24.15.0", "26.12.1"]`). Nothing checks that the three agree. A later bump that edits only `.node-version` leaves the commit-msg job and the newer quality-checks leg on the old runtime without any error. In APOSD terms this is information leakage and repetition: one design decision, "the current runtime", is spread across several modules. > > The repository already has a single authority for this value. `release.yml` and `dedupe-check.yml` both use `node-version-file: ".node-version"` with `actions/setup-node@v6`. `dedupe-check.yml` runs on `pull_request` against the PR checkout, so reading `.node-version` from a PR head is already accepted practice here. > > Fix: have `commit-msg.yml` use `node-version-file: ".node-version"`. In `checks.yml`, keep the `24.15.0` minimum-supported leg, which matches `package.json` `engines.node: ">=24.15.0"`, and source the current leg from `.node-version`. One way is a matrix entry that sets `node-version-file` instead of `node-version`. If `commit-msg.yml` has to stay independent of the PR head's `.node-version`, because its token-bearing `node -e` step must not run on a runtime the PR chooses, the comment `# Policy-pinned runtime for the refreshed PR metadata parser.` should say so. As written, it gives no reason the pin cannot follow `.node-version`, so the next maintainer will either miss it during a bump or "clean it up". > > What I examined: the diff (three one-line edits), the full `checks.yml`, `commit-msg.yml`, `dedupe-check.yml`, and the setup-node steps in `release.yml`, plus a repository-wide grep for `node-version` and the version strings. I could not find any policy document defining "policy-pinned". Such a document, requiring the commit-msg runtime to be fixed in the base workflow, would justify keeping that copy, but it would still call for a comment explaining why. It would not justify the copy in `checks.yml`. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (1) - `01M5QJE1Q67RV3B1AAM6PP44M5` low — The runtime comment carries an unnecessary parser revision reference ## Coverage Coverage pass: 01M5QJAT70880KWSTZAZCGYF8W 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:58 +00:00
.forgejo/workflows/commit-msg.yml
Lines 37-38
@ -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"
forgejo-actions commented 2026-10-24 18:24:58 +00:00

medium — The current Node.js version is hard-coded in commit-msg.yml and checks.yml instead of read from .node-version, so one version decision needs three matching edits

Bumping Node.js to 26.12.1 took identical edits in three files: .node-version, the node-version: "26.12.1" literal in commit-msg.yml, and the second matrix entry in checks.yml (node: ["24.15.0", "26.12.1"]). Nothing checks that the three agree. A later bump that edits only .node-version leaves the commit-msg job and the newer quality-checks leg on the old runtime without any error. In APOSD terms this is information leakage and repetition: one design decision, "the current runtime", is spread across several modules.

The repository already has a single authority for this value. release.yml and dedupe-check.yml both use node-version-file: ".node-version" with actions/setup-node@v6. dedupe-check.yml runs on pull_request against the PR checkout, so reading .node-version from a PR head is already accepted practice here.

Fix: have commit-msg.yml use node-version-file: ".node-version". In checks.yml, keep the 24.15.0 minimum-supported leg, which matches package.json engines.node: ">=24.15.0", and source the current leg from .node-version. One way is a matrix entry that sets node-version-file instead of node-version. If commit-msg.yml has to stay independent of the PR head's .node-version, because its token-bearing node -e step must not run on a runtime the PR chooses, the comment # Policy-pinned runtime for the refreshed PR metadata parser. should say so. As written, it gives no reason the pin cannot follow .node-version, so the next maintainer will either miss it during a bump or "clean it up".

What I examined: the diff (three one-line edits), the full checks.yml, commit-msg.yml, dedupe-check.yml, and the setup-node steps in release.yml, plus a repository-wide grep for node-version and the version strings. I could not find any policy document defining "policy-pinned". Such a document, requiring the commit-msg runtime to be fixed in the base workflow, would justify keeping that copy, but it would still call for a comment explaining why. It would not justify the copy in checks.yml.

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

<!-- review:claim:01M5QJEFW73QTN7K4KY982QZJQ --> **medium** — The current Node.js version is hard-coded in commit-msg.yml and checks.yml instead of read from `.node-version`, so one version decision needs three matching edits > Bumping Node.js to 26.12.1 took identical edits in three files: `.node-version`, the `node-version: "26.12.1"` literal in `commit-msg.yml`, and the second matrix entry in `checks.yml` (`node: ["24.15.0", "26.12.1"]`). Nothing checks that the three agree. A later bump that edits only `.node-version` leaves the commit-msg job and the newer quality-checks leg on the old runtime without any error. In APOSD terms this is information leakage and repetition: one design decision, "the current runtime", is spread across several modules. > > The repository already has a single authority for this value. `release.yml` and `dedupe-check.yml` both use `node-version-file: ".node-version"` with `actions/setup-node@v6`. `dedupe-check.yml` runs on `pull_request` against the PR checkout, so reading `.node-version` from a PR head is already accepted practice here. > > Fix: have `commit-msg.yml` use `node-version-file: ".node-version"`. In `checks.yml`, keep the `24.15.0` minimum-supported leg, which matches `package.json` `engines.node: ">=24.15.0"`, and source the current leg from `.node-version`. One way is a matrix entry that sets `node-version-file` instead of `node-version`. If `commit-msg.yml` has to stay independent of the PR head's `.node-version`, because its token-bearing `node -e` step must not run on a runtime the PR chooses, the comment `# Policy-pinned runtime for the refreshed PR metadata parser.` should say so. As written, it gives no reason the pin cannot follow `.node-version`, so the next maintainer will either miss it during a bump or "clean it up". > > What I examined: the diff (three one-line edits), the full `checks.yml`, `commit-msg.yml`, `dedupe-check.yml`, and the setup-node steps in `release.yml`, plus a repository-wide grep for `node-version` and the version strings. I could not find any policy document defining "policy-pinned". Such a document, requiring the commit-msg runtime to be fixed in the base workflow, would justify keeping that copy, but it would still call for a comment explaining why. It would not justify the copy in `checks.yml`. lens `aposd-plain` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5QJEFW73QTN7K4KY982QZJQ` of review `01M5QJACSZMSHGHM14W8EMR1CT`
👎 1
jercik commented 2026-10-24 18:25:41 +00:00
Author
Owner

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.

<!-- gh-feedback:reply-to:188777 --> 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:06 +00:00
Author
Owner

Claim 01M5QJE1Q67RV3B1AAM6PP44M5 (low): I checked the unchanged generated comment, Policy-pinned runtime for the refreshed PR metadata parser. The word refreshed is an unnecessary revision reference, 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 `01M5QJE1Q67RV3B1AAM6PP44M5` (low): I checked the unchanged generated comment, `Policy-pinned runtime for the refreshed PR metadata parser.` The word `refreshed` is an unnecessary revision reference, 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 a1c7e8d702 into main 2026-10-24 18:28:01 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
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/fta-check!13
No description provided.