chore: refresh managed runtime workflows #10

jercik · 2026-10-24T19:13:50Z

jercik commented

2026-10-24 19:13:50 +00:00

Refreshes managed runtime workflows from Align 15.2.1: Node 26.12.1 for checks and the published commit-msg setup removal. Preserves the Node 24.15.0 compatibility check.

jercik added 1 commit

2026-10-24 19:13:50 +00:00

chore: refresh managed runtime workflows

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

Details

Checks / reuse (pull_request) Successful in 4s

Details

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

Details

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

Details

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

Details

Review / Review (pull_request_target) Successful in 3m7s

Details

f90be7fe0d

forgejo-actions commented

2026-10-24 19:16:55 +00:00

Review 01M5QNAWXHR28YZYASFMSV5VZY — head f90be7fe0d51e89c9b7ffb9f6af6ec92ad655cda

Review — j4k-oss/perplexity-agent-mcp @ `50cdebfad0`

Scope: diff against base tree 11518dc7a71d
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)

low — The checks matrix hard-codes the current Node version from `.node-version`, so each runtime bump needs a matching hand edit in `checks.yml`

claim: 01M5QNDZGYD9EHTCCJN9FH01VW
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 01M5QNER50GGJJVPSBMN18V6QZ · valid: Grounded exact: checks.yml has node: ["24.15.0", "26.12.1"]. The reviewer reports that .node-version holds 26.12.1, that dedupe-check.yml and release.yml read it through node-version-file, and that this diff had to edit both .node-version and this matrix line for one bump. That is the Information Leakage / Repetition red flag: one design decision, the current runtime, is encoded in two files that must change together. The batch's own evidence shows the cost is real. Per the sibling claim, the commit-msg.yml copy had already drifted to 26.5.0 before this change removed it. The two values agree today, so low severity fits. The floor entry 24.15.0 is a deliberate test of engines.node, as the claim itself grants. Fix: derive the current leg from .node-version, either with a node-version-file leg or a matrix emitted from the file, or add a drift check.
disposition: none

The quality-checks matrix spells out "26.12.1", the same value .node-version holds. .node-version is the authority: dedupe-check.yml and release.yml read it through node-version-file. This change had to edit both files to bump one runtime. If a later bump touches only .node-version, the PR gate keeps testing the old Node while release builds on the new one, and nothing reports the drift. The minimum entry "24.15.0" also repeats engines.node (">=24.15.0") in package.json, but there the matrix is testing a stated floor, so that copy is easier to defend.

The two values agree in this subject. The cost is the parallel edit on every bump, which the deleted node-version: "26.5.0" in commit-msg.yml shows: that copy was still on 26.5.0 until this change.

Correction: derive the current entry from .node-version so there is one place to change it. One option is a short job that reads the file and emits the matrix as JSON, which quality-checks consumes with fromJSON. Another is to keep one matrix entry explicit for the floor and give a second leg node-version-file: ".node-version". If the hard-coded value stays, add a check that fails when it differs from .node-version.

What I examined: checks.yml (the matrix and its setup-node step), .node-version, package.json engines, the setup-node steps in dedupe-check.yml and release.yml, and the diff, which edits both .node-version and this matrix line. I could not see repository history to tell how often these values have drifted before, apart from the commit-msg.yml copy this change removes.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (1)
- 01M5QNDP7EBYGB5PCH6H02ZTT1 medium — commit-msg drops its Node setup step, so the PR metadata parser runs on whatever node the runner image ships instead of the repo's pinned runtime
duplicate-of (0)
unadjudicated (0)

Coverage

Coverage pass: 01M5QNAWXPF519KEKJFAY1Z7J4
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** `01M5QNAWXHR28YZYASFMSV5VZY` — head `f90be7fe0d51e89c9b7ffb9f6af6ec92ad655cda` # Review — j4k-oss/perplexity-agent-mcp @ 50cdebfad0ef Scope: diff against base tree `11518dc7a71d` 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) ### low — The checks matrix hard-codes the current Node version from `.node-version`, so each runtime bump needs a matching hand edit in `checks.yml` - claim: `01M5QNDZGYD9EHTCCJN9FH01VW` - 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 `01M5QNER50GGJJVPSBMN18V6QZ` · valid: Grounded exact: checks.yml has node: ["24.15.0", "26.12.1"]. The reviewer reports that .node-version holds 26.12.1, that dedupe-check.yml and release.yml read it through node-version-file, and that this diff had to edit both .node-version and this matrix line for one bump. That is the Information Leakage / Repetition red flag: one design decision, the current runtime, is encoded in two files that must change together. The batch's own evidence shows the cost is real. Per the sibling claim, the commit-msg.yml copy had already drifted to 26.5.0 before this change removed it. The two values agree today, so low severity fits. The floor entry 24.15.0 is a deliberate test of engines.node, as the claim itself grants. Fix: derive the current leg from .node-version, either with a node-version-file leg or a matrix emitted from the file, or add a drift check. - disposition: none > The `quality-checks` matrix spells out `"26.12.1"`, the same value `.node-version` holds. `.node-version` is the authority: `dedupe-check.yml` and `release.yml` read it through `node-version-file`. This change had to edit both files to bump one runtime. If a later bump touches only `.node-version`, the PR gate keeps testing the old Node while release builds on the new one, and nothing reports the drift. The minimum entry `"24.15.0"` also repeats `engines.node` (`">=24.15.0"`) in `package.json`, but there the matrix is testing a stated floor, so that copy is easier to defend. > > The two values agree in this subject. The cost is the parallel edit on every bump, which the deleted `node-version: "26.5.0"` in `commit-msg.yml` shows: that copy was still on `26.5.0` until this change. > > Correction: derive the current entry from `.node-version` so there is one place to change it. One option is a short job that reads the file and emits the matrix as JSON, which `quality-checks` consumes with `fromJSON`. Another is to keep one matrix entry explicit for the floor and give a second leg `node-version-file: ".node-version"`. If the hard-coded value stays, add a check that fails when it differs from `.node-version`. > > What I examined: `checks.yml` (the matrix and its `setup-node` step), `.node-version`, `package.json` `engines`, the `setup-node` steps in `dedupe-check.yml` and `release.yml`, and the diff, which edits both `.node-version` and this matrix line. I could not see repository history to tell how often these values have drifted before, apart from the `commit-msg.yml` copy this change removes. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (1) - `01M5QNDP7EBYGB5PCH6H02ZTT1` medium — commit-msg drops its Node setup step, so the PR metadata parser runs on whatever `node` the runner image ships instead of the repo's pinned runtime - duplicate-of (0) - unadjudicated (0) ## Coverage Coverage pass: 01M5QNAWXPF519KEKJFAY1Z7J4 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 19:16:56 +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"]

low — The checks matrix hard-codes the current Node version from .node-version, so each runtime bump needs a matching hand edit in checks.yml

The quality-checks matrix spells out "26.12.1", the same value .node-version holds. .node-version is the authority: dedupe-check.yml and release.yml read it through node-version-file. This change had to edit both files to bump one runtime. If a later bump touches only .node-version, the PR gate keeps testing the old Node while release builds on the new one, and nothing reports the drift. The minimum entry "24.15.0" also repeats engines.node (">=24.15.0") in package.json, but there the matrix is testing a stated floor, so that copy is easier to defend.

The two values agree in this subject. The cost is the parallel edit on every bump, which the deleted node-version: "26.5.0" in commit-msg.yml shows: that copy was still on 26.5.0 until this change.

Correction: derive the current entry from .node-version so there is one place to change it. One option is a short job that reads the file and emits the matrix as JSON, which quality-checks consumes with fromJSON. Another is to keep one matrix entry explicit for the floor and give a second leg node-version-file: ".node-version". If the hard-coded value stays, add a check that fails when it differs from .node-version.

What I examined: checks.yml (the matrix and its setup-node step), .node-version, package.json engines, the setup-node steps in dedupe-check.yml and release.yml, and the diff, which edits both .node-version and this matrix line. I could not see repository history to tell how often these values have drifted before, apart from the commit-msg.yml copy this change removes.

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

**low** — The checks matrix hard-codes the current Node version from `.node-version`, so each runtime bump needs a matching hand edit in `checks.yml` > The `quality-checks` matrix spells out `"26.12.1"`, the same value `.node-version` holds. `.node-version` is the authority: `dedupe-check.yml` and `release.yml` read it through `node-version-file`. This change had to edit both files to bump one runtime. If a later bump touches only `.node-version`, the PR gate keeps testing the old Node while release builds on the new one, and nothing reports the drift. The minimum entry `"24.15.0"` also repeats `engines.node` (`">=24.15.0"`) in `package.json`, but there the matrix is testing a stated floor, so that copy is easier to defend. > > The two values agree in this subject. The cost is the parallel edit on every bump, which the deleted `node-version: "26.5.0"` in `commit-msg.yml` shows: that copy was still on `26.5.0` until this change. > > Correction: derive the current entry from `.node-version` so there is one place to change it. One option is a short job that reads the file and emits the matrix as JSON, which `quality-checks` consumes with `fromJSON`. Another is to keep one matrix entry explicit for the floor and give a second leg `node-version-file: ".node-version"`. If the hard-coded value stays, add a check that fails when it differs from `.node-version`. > > What I examined: `checks.yml` (the matrix and its `setup-node` step), `.node-version`, `package.json` `engines`, the `setup-node` steps in `dedupe-check.yml` and `release.yml`, and the diff, which edits both `.node-version` and this matrix line. I could not see repository history to tell how often these values have drifted before, apart from the `commit-msg.yml` copy this change removes. lens `aposd-plain` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5QNDZGYD9EHTCCJN9FH01VW` of review `01M5QNAWXHR28YZYASFMSV5VZY`

👎 1

The duplicate literal is real and remains in this PR. These are managed outputs rendered together by published @j4k/align 15.2.1, rather than independently maintained runtime authorities. I am retaining that released matrix, including the supported Node 24.15.0 leg; this PR does not redesign the producer's runtime policy.

The assertion that nothing detects drift is incorrect. I ran the installed 15.2.1 analyzeSetupNodeSteps checker against this exact checks.yml: the accepted matrix produces no findings; replacing only its current leg with 26.5.0 in memory produces an ambiguous Node selector finding at line 142. No repository file was changed by that reproduction. The full managed audit and renderer idempotence also passed for f90be7fe0d.

The six-line commit-msg setup removal matches the separately published 15.2.1 template. Its exact-head remote run 43 passed both Read the current pull request and Validate commit title and subjects on the configured runner. This establishes that run's parser/checker execution, not a pinned remote Node version.

Disposition: retain the intentional managed duplication; reject the undetected-drift/manual-maintenance premise. No duplication redesign is included or claimed fixed.

The duplicate literal is real and remains in this PR. These are managed outputs rendered together by published @j4k/align 15.2.1, rather than independently maintained runtime authorities. I am retaining that released matrix, including the supported Node 24.15.0 leg; this PR does not redesign the producer's runtime policy. The assertion that nothing detects drift is incorrect. I ran the installed 15.2.1 analyzeSetupNodeSteps checker against this exact checks.yml: the accepted matrix produces no findings; replacing only its current leg with 26.5.0 in memory produces an ambiguous Node selector finding at line 142. No repository file was changed by that reproduction. The full managed audit and renderer idempotence also passed for f90be7fe0d51e89c9b7ffb9f6af6ec92ad655cda. The six-line commit-msg setup removal matches the separately published 15.2.1 template. Its exact-head remote run 43 passed both Read the current pull request and Validate commit title and subjects on the configured runner. This establishes that run's parser/checker execution, not a pinned remote Node version. Disposition: retain the intentional managed duplication; reject the undetected-drift/manual-maintenance premise. No duplication redesign is included or claimed fixed.

jercik marked this conversation as resolved

jercik merged commit 2f0bb53f66 into main

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

jercik referenced this pull request from a commit

2026-10-24 19:23:28 +00:00

chore: refresh managed runtime workflows (#10)

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/perplexity-agent-mcp!10

Rows
Columns

chore: refresh managed runtime workflows #10

Review — j4k-oss/perplexity-agent-mcp @ 50cdebfad0

Findings (1)

low — The checks matrix hard-codes the current Node version from .node-version, so each runtime bump needs a matching hand edit in checks.yml

Other claims

Coverage

Review — j4k-oss/perplexity-agent-mcp @ `50cdebfad0`

low — The checks matrix hard-codes the current Node version from `.node-version`, so each runtime bump needs a matching hand edit in `checks.yml`