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

chore: refresh managed Node runtime to 26.12.1 #8

Merged
jercik merged 1 commit from chore/align-runtime-26-12-1 into main 2026-10-24 18:26:43 +00:00
Conversation 2 Commits 1 Files changed 3 +3 -3
jercik commented 2026-10-24 18:21:10 +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 5s
Details
commit-msg / commitlint (pull_request) Successful in 8s
Details
Checks / quality-checks (24.15.0) (pull_request) Successful in 29s
Details
Checks / quality-checks (26.12.1) (pull_request) Successful in 37s
Details
Review / Review (pull_request_target) Successful in 2m37s
Details
2b7cbdb826
forgejo-actions commented 2026-10-24 18:23:46 +00:00

Review 01M5QJAFNWG927V5RW4ZPE001B — head 2b7cbdb826a1458c67d8a5c2db9df3781711506b

Review — j4k-oss/worktree-remove @ 91e8cbbb7e

Scope: diff against base tree 54b0025df426
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 Node runtime version is hard-coded in commit-msg.yml and the checks.yml matrix instead of read from .node-version, so every runtime bump has to edit three files

  • claim: 01M5QJCSR7HJ0XKSP67V0XVZ22
  • 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 01M5QJDGCX47DXBQTAZK9JWZ7K · valid: Grounded (exact match): commit-msg.yml pins setup-node with the literal node-version "26.12.1" and the comment '# Policy-pinned runtime for the refreshed PR metadata parser.' The rest comes from the reviewer and hangs together: .node-version holds 26.12.1, the checks.yml matrix lists ["24.15.0", "26.12.1"], and dedupe-check.yml and release.yml already read node-version-file: ".node-version". So one decision, the current Node runtime, lives in three places with no check that they agree. The diff had to edit all three together, which is the change amplification the claim describes. This matches the APoSD Information Leakage and Repetition red flags. The sibling workflows show a single-source form is already the repo's idiom. The reviewer also says dedupe-check runs PR-controlled code under the same guard, so a trust boundary doesn't explain the separate literal. The best objection is the word 'Policy-pinned', which could mean a deliberate decoupling. But the comment names no policy and no reason. The pinned value equals .node-version and moved with it in this change. And per principle 13 the comment fails to explain the non-obvious choice. If a real policy exists, the defect turns into a comment that has to state that policy. The checks.yml current-version leg stands either way, since the minimum leg tracks engines.node and is a separate fact. Medium fits: the duplicated value must already change in lockstep across modules. The proposed fix (node-version-file in commit-msg, plus a matrix include entry that reads .node-version for the current leg) keeps the minimum-version leg, so nothing is lost.
  • disposition: none

The repository's current Node runtime is one decision, but this change had to write it into three places: .node-version (26.12.1), the node-version: "26.12.1" literal in commit-msg.yml, and the newest entry in checks.yml's node: ["24.15.0", "26.12.1"] matrix. Nothing checks that they agree. A future bump that misses one copy leaves commit-msg or the quality-checks matrix on an older runtime than the rest of CI, and no failure reports it. This is the information-leakage / change-amplification red flag: a design decision that every module restates.

The repository already has the single-source form. dedupe-check.yml and release.yml both configure actions/setup-node@v6 with node-version-file: ".node-version". dedupe-check.yml also checks out and runs PR-controlled code, under the same fork/AGit guard as commit-msg, so trust does not explain why commit-msg carries its own literal. The comment above the literal, # Policy-pinned runtime for the refreshed PR metadata parser., names no policy and gives no reason the pin must differ from .node-version. In this change it moved in lockstep with .node-version, which suggests it just tracks that file.

Correction: in commit-msg.yml, replace the literal with node-version-file: ".node-version" and delete the vague comment. If some policy really requires a separate pin, the comment should say what that policy is and when the pin may differ from .node-version. In checks.yml, keep only the minimum supported version as a literal, because it tracks engines.node (>=24.15.0) and not .node-version. Let the current-version matrix leg read .node-version, for example with an include entry that sets node-version-file in place of node-version.

What I examined: the diff, which touches exactly these three files. I read commit-msg.yml in full, checks.yml up to the quality-checks setup-node step, the setup-node steps in dedupe-check.yml and release.yml, and package.json engines. A repo-wide grep for node-version and 26.12 found no consistency check and no script that keeps the copies in sync. I could not see commit history, so I can't rule out an earlier decision that deliberately decoupled commit-msg's runtime. A documented reason for that pin would refute the commit-msg half of this claim. The checks.yml half would still stand.

Other claims

  • grounding-pending (0)
  • ungrounded (0)
  • rejected (0)
  • duplicate-of (0)
  • unadjudicated (0)

Coverage

Coverage pass: 01M5QJAFP07W934YKHZQF06MK9
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 no-claims 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** `01M5QJAFNWG927V5RW4ZPE001B` — head `2b7cbdb826a1458c67d8a5c2db9df3781711506b` # Review — j4k-oss/worktree-remove @ 91e8cbbb7e94 Scope: diff against base tree `54b0025df426` 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 Node runtime version is hard-coded in commit-msg.yml and the checks.yml matrix instead of read from `.node-version`, so every runtime bump has to edit three files - claim: `01M5QJCSR7HJ0XKSP67V0XVZ22` - 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 `01M5QJDGCX47DXBQTAZK9JWZ7K` · valid: Grounded (exact match): commit-msg.yml pins setup-node with the literal node-version "26.12.1" and the comment '# Policy-pinned runtime for the refreshed PR metadata parser.' The rest comes from the reviewer and hangs together: .node-version holds 26.12.1, the checks.yml matrix lists ["24.15.0", "26.12.1"], and dedupe-check.yml and release.yml already read node-version-file: ".node-version". So one decision, the current Node runtime, lives in three places with no check that they agree. The diff had to edit all three together, which is the change amplification the claim describes. This matches the APoSD Information Leakage and Repetition red flags. The sibling workflows show a single-source form is already the repo's idiom. The reviewer also says dedupe-check runs PR-controlled code under the same guard, so a trust boundary doesn't explain the separate literal. The best objection is the word 'Policy-pinned', which could mean a deliberate decoupling. But the comment names no policy and no reason. The pinned value equals .node-version and moved with it in this change. And per principle 13 the comment fails to explain the non-obvious choice. If a real policy exists, the defect turns into a comment that has to state that policy. The checks.yml current-version leg stands either way, since the minimum leg tracks engines.node and is a separate fact. Medium fits: the duplicated value must already change in lockstep across modules. The proposed fix (node-version-file in commit-msg, plus a matrix include entry that reads .node-version for the current leg) keeps the minimum-version leg, so nothing is lost. - disposition: none > The repository's current Node runtime is one decision, but this change had to write it into three places: `.node-version` (`26.12.1`), the `node-version: "26.12.1"` literal in commit-msg.yml, and the newest entry in checks.yml's `node: ["24.15.0", "26.12.1"]` matrix. Nothing checks that they agree. A future bump that misses one copy leaves commit-msg or the quality-checks matrix on an older runtime than the rest of CI, and no failure reports it. This is the information-leakage / change-amplification red flag: a design decision that every module restates. > > The repository already has the single-source form. dedupe-check.yml and release.yml both configure `actions/setup-node@v6` with `node-version-file: ".node-version"`. dedupe-check.yml also checks out and runs PR-controlled code, under the same fork/AGit guard as commit-msg, so trust does not explain why commit-msg carries its own literal. The comment above the literal, `# Policy-pinned runtime for the refreshed PR metadata parser.`, names no policy and gives no reason the pin must differ from `.node-version`. In this change it moved in lockstep with `.node-version`, which suggests it just tracks that file. > > Correction: in commit-msg.yml, replace the literal with `node-version-file: ".node-version"` and delete the vague comment. If some policy really requires a separate pin, the comment should say what that policy is and when the pin may differ from `.node-version`. In checks.yml, keep only the minimum supported version as a literal, because it tracks `engines.node` (`>=24.15.0`) and not `.node-version`. Let the current-version matrix leg read `.node-version`, for example with an include entry that sets `node-version-file` in place of `node-version`. > > What I examined: the diff, which touches exactly these three files. I read commit-msg.yml in full, checks.yml up to the quality-checks setup-node step, the setup-node steps in dedupe-check.yml and release.yml, and package.json `engines`. A repo-wide grep for `node-version` and `26.12` found no consistency check and no script that keeps the copies in sync. I could not see commit history, so I can't rule out an earlier decision that deliberately decoupled commit-msg's runtime. A documented reason for that pin would refute the commit-msg half of this claim. The checks.yml half would still stand. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (0) ## Coverage Coverage pass: 01M5QJAFP07W934YKHZQF06MK9 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 | no-claims | 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:23:46 +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"
forgejo-actions commented 2026-10-24 18:23:46 +00:00

medium — The project's Node runtime version is hard-coded in commit-msg.yml and the checks.yml matrix instead of read from .node-version, so every runtime bump has to edit three files

The repository's current Node runtime is one decision, but this change had to write it into three places: .node-version (26.12.1), the node-version: "26.12.1" literal in commit-msg.yml, and the newest entry in checks.yml's node: ["24.15.0", "26.12.1"] matrix. Nothing checks that they agree. A future bump that misses one copy leaves commit-msg or the quality-checks matrix on an older runtime than the rest of CI, and no failure reports it. This is the information-leakage / change-amplification red flag: a design decision that every module restates.

The repository already has the single-source form. dedupe-check.yml and release.yml both configure actions/setup-node@v6 with node-version-file: ".node-version". dedupe-check.yml also checks out and runs PR-controlled code, under the same fork/AGit guard as commit-msg, so trust does not explain why commit-msg carries its own literal. The comment above the literal, # Policy-pinned runtime for the refreshed PR metadata parser., names no policy and gives no reason the pin must differ from .node-version. In this change it moved in lockstep with .node-version, which suggests it just tracks that file.

Correction: in commit-msg.yml, replace the literal with node-version-file: ".node-version" and delete the vague comment. If some policy really requires a separate pin, the comment should say what that policy is and when the pin may differ from .node-version. In checks.yml, keep only the minimum supported version as a literal, because it tracks engines.node (>=24.15.0) and not .node-version. Let the current-version matrix leg read .node-version, for example with an include entry that sets node-version-file in place of node-version.

What I examined: the diff, which touches exactly these three files. I read commit-msg.yml in full, checks.yml up to the quality-checks setup-node step, the setup-node steps in dedupe-check.yml and release.yml, and package.json engines. A repo-wide grep for node-version and 26.12 found no consistency check and no script that keeps the copies in sync. I could not see commit history, so I can't rule out an earlier decision that deliberately decoupled commit-msg's runtime. A documented reason for that pin would refute the commit-msg half of this claim. The checks.yml half would still stand.

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

<!-- review:claim:01M5QJCSR7HJ0XKSP67V0XVZ22 --> **medium** — The project's Node runtime version is hard-coded in commit-msg.yml and the checks.yml matrix instead of read from `.node-version`, so every runtime bump has to edit three files > The repository's current Node runtime is one decision, but this change had to write it into three places: `.node-version` (`26.12.1`), the `node-version: "26.12.1"` literal in commit-msg.yml, and the newest entry in checks.yml's `node: ["24.15.0", "26.12.1"]` matrix. Nothing checks that they agree. A future bump that misses one copy leaves commit-msg or the quality-checks matrix on an older runtime than the rest of CI, and no failure reports it. This is the information-leakage / change-amplification red flag: a design decision that every module restates. > > The repository already has the single-source form. dedupe-check.yml and release.yml both configure `actions/setup-node@v6` with `node-version-file: ".node-version"`. dedupe-check.yml also checks out and runs PR-controlled code, under the same fork/AGit guard as commit-msg, so trust does not explain why commit-msg carries its own literal. The comment above the literal, `# Policy-pinned runtime for the refreshed PR metadata parser.`, names no policy and gives no reason the pin must differ from `.node-version`. In this change it moved in lockstep with `.node-version`, which suggests it just tracks that file. > > Correction: in commit-msg.yml, replace the literal with `node-version-file: ".node-version"` and delete the vague comment. If some policy really requires a separate pin, the comment should say what that policy is and when the pin may differ from `.node-version`. In checks.yml, keep only the minimum supported version as a literal, because it tracks `engines.node` (`>=24.15.0`) and not `.node-version`. Let the current-version matrix leg read `.node-version`, for example with an include entry that sets `node-version-file` in place of `node-version`. > > What I examined: the diff, which touches exactly these three files. I read commit-msg.yml in full, checks.yml up to the quality-checks setup-node step, the setup-node steps in dedupe-check.yml and release.yml, and package.json `engines`. A repo-wide grep for `node-version` and `26.12` found no consistency check and no script that keeps the copies in sync. I could not see commit history, so I can't rule out an earlier decision that deliberately decoupled commit-msg's runtime. A documented reason for that pin would refute the commit-msg half of this claim. The checks.yml half would still stand. lens `aposd-plain` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5QJCSR7HJ0XKSP67V0XVZ22` of review `01M5QJAFNWG927V5RW4ZPE001B`
👎 1
jercik commented 2026-10-24 18:24:48 +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:188770 --> 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 merged commit e5448867bb into main 2026-10-24 18:26:43 +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/worktree-remove!8
No description provided.