chore: align with j4k-align 17.17.1 #17

jercik · 2026-11-04T06:47:37Z

jercik commented

2026-11-04 06:47:37 +00:00

Adds align 17.17's baked-Node guard before every actions/setup-node step in the Forgejo workflows. A job now stops with an error, instead of downloading Node from GitHub, when its image does not bake the version in .node-version (26.13.0).

The same repair syncs align's other managed files since 17.15.4: a readable PR-field parser in the commit-msg workflow, a scripts/check-msg.sh rejection message that lists the allowed types, and comment fixes in the workflows.

With the workflows current, align's audit of this repository passes clean. Align had refused the typed-lint conversion because of the drifted workflows, and the tsconfig drift and typecheck script findings that came with that refusal no longer appear.

Adds align 17.17's baked-Node guard before every `actions/setup-node` step in the Forgejo workflows. A job now stops with an error, instead of downloading Node from GitHub, when its image does not bake the version in `.node-version` (26.13.0). The same repair syncs align's other managed files since 17.15.4: a readable PR-field parser in the commit-msg workflow, a `scripts/check-msg.sh` rejection message that lists the allowed types, and comment fixes in the workflows. With the workflows current, align's audit of this repository passes clean. Align had refused the typed-lint conversion because of the drifted workflows, and the `tsconfig` drift and `typecheck` script findings that came with that refusal no longer appear.

jercik added 1 commit

2026-11-04 06:47:37 +00:00

chore: align with j4k-align 17.17.1

Checks / reuse (pull_request) Has been skipped

Details

commit-msg / same-repo-pr (pull_request) Has been skipped

Details

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

Details

Checks / quality-checks (pull_request) Successful in 49s

Details

Checks / qc-result (pull_request) Has been skipped

Details

Review / Review (pull_request_target) Successful in 16m59s

Details

0c5597a377

forgejo-actions commented

2026-11-04 07:04:43 +00:00

Review 01M6JN0Q5ZX3AW0PE8AC5ZXAKQ — head 0c5597a3776623b59407165b9ee69346d5544713

Review — j4k-oss/conventional-commit-msg @ `3deba9d392`

Scope: diff against base tree 47433b4d5ebc
Review finished: 6 succeeded, 0 failed, 4 skipped by dispatch
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 baked-Node step's REQUIRED_NODE_VERSION mode can never run, because the step's own env always sets REQUIRED_NODE_VERSION_FILE

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

          if [ -n "${REQUIRED_NODE_VERSION:-}" ] && [ -z "${REQUIRED_NODE_VERSION_FILE:-}" ]; then
            version="$REQUIRED_NODE_VERSION"
            pin="this workflow's Node pin"

lens: aposd-plain · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M6JNN864C6M5K0NMG4NTPPEX · valid: The grounded excerpt shows that the first branch runs only when REQUIRED_NODE_VERSION is set and REQUIRED_NODE_VERSION_FILE is empty. The anchor of the sibling claim 01M6JNKVJD5ZE6Z15M8F83Y3E2 is also grounded and shows the same step setting REQUIRED_NODE_VERSION_FILE: ".node-version" in its step-level env. Because that value is always non-empty, the literal-version branch can never run. If REQUIRED_NODE_VERSION were ever set elsewhere, the step would fail with the 'exactly one' error instead of using it. The reviewer's grep, which finds no REQUIRED_NODE_VERSION assignment in the tree, is consistent with this. Readers of each copy therefore parse a two-mode dispatch with only one reachable mode, which is the Special-General Mixture / Nonobvious Code red flag, and the reviewer quotes AGENTS.md's rule against options no caller passes. Remedy gap: if a j4k-align template renders these files, a local edit to read .node-version directly would be overwritten. The fix then belongs in the template, which should render only the applicable branch, as the reviewer also notes. Low severity is appropriate.
disposition: none

Every copy of the step opens with a two-mode dispatch: a literal version from REQUIRED_NODE_VERSION, a file from REQUIRED_NODE_VERSION_FILE, and an "exactly one of" error for anything else. But each copy sets REQUIRED_NODE_VERSION_FILE: ".node-version" in the step-level env:, and nothing in the repo sets REQUIRED_NODE_VERSION. So the first branch can never run. The only other reachable outcome is a misconfiguration error: if someone later sets REQUIRED_NODE_VERSION at workflow or job level, the step fails with "needs exactly one of" instead of using it. Readers of all three workflows still have to parse a 12-line dispatch and the pin="this workflow's Node pin" wording to learn that the step just reads .node-version. This is special-purpose flexibility mixed into a check that has one real input, and it breaks AGENTS.md's "Build for Requirements That Exist Today": "No parameter or option no caller passes".

Correction: read the pin directly, e.g. version="$(cat .node-version)", with pin=.node-version, and drop the dispatch and the "exactly one" error. That shrinks each copy by about a third and leaves the version-shape check and the tool-cache lookup as they are. If a template serves other repos that pin Node inline, the template should render only the branch that applies to each repo instead of shipping both.

What I examined: grep -rn REQUIRED_NODE_VERSION over the subject tree. Its only hits are the three step bodies in checks.yml, release.yml and dedupe-check.yml, each with the REQUIRED_NODE_VERSION_FILE: ".node-version" env entry and no REQUIRED_NODE_VERSION assignment at step, job or workflow level. I did not check runner-level environment. Runner-provided REQUIRED_NODE_VERSION is the one setting that would make the branch reachable, and then it would hit the error branch, not the version branch. Whether an upstream j4k-align template uses the other mode for other repos is outside this tree and unverified.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (0)
duplicate-of (0)
unadjudicated (1)
- 01M6JNKVJD5ZE6Z15M8F83Y3E2 medium — The 30-line baked-Node check is pasted verbatim into checks.yml, release.yml and dedupe-check.yml

Coverage

Coverage pass: 01M6JN0Q64DHFV7MQ34X70F2EK
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
restated-sets	whole	default	no-claims	1	no
unix-cli	whole	default	no-claims	1	no
module-design	whole	default	no-claims	1	no
aposd-plain	whole	default	claims-emitted	1	no

test-trimming — skipped-by-dispatch: no tests changed
project-docs — skipped-by-dispatch: no project documentation changed
use-effect — skipped-by-dispatch: no React code; changes are CI workflow YAML and a shell script
react — skipped-by-dispatch: no React code; changes are CI workflow YAML and a shell script

**Review** `01M6JN0Q5ZX3AW0PE8AC5ZXAKQ` — head `0c5597a3776623b59407165b9ee69346d5544713` # Review — j4k-oss/conventional-commit-msg @ 3deba9d39260 Scope: diff against base tree `47433b4d5ebc` Review finished: 6 succeeded, 0 failed, 4 skipped by dispatch 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 baked-Node step's REQUIRED_NODE_VERSION mode can never run, because the step's own env always sets REQUIRED_NODE_VERSION_FILE - claim: `01M6JNM899KQGFZ7RBGSAFRG6G` - anchor: `.forgejo/workflows/checks.yml` (snippet) ``` if [ -n "${REQUIRED_NODE_VERSION:-}" ] && [ -z "${REQUIRED_NODE_VERSION_FILE:-}" ]; then version="$REQUIRED_NODE_VERSION" pin="this workflow's Node pin" ``` - lens: aposd-plain · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M6JNN864C6M5K0NMG4NTPPEX` · valid: The grounded excerpt shows that the first branch runs only when REQUIRED_NODE_VERSION is set and REQUIRED_NODE_VERSION_FILE is empty. The anchor of the sibling claim 01M6JNKVJD5ZE6Z15M8F83Y3E2 is also grounded and shows the same step setting REQUIRED_NODE_VERSION_FILE: ".node-version" in its step-level env. Because that value is always non-empty, the literal-version branch can never run. If REQUIRED_NODE_VERSION were ever set elsewhere, the step would fail with the 'exactly one' error instead of using it. The reviewer's grep, which finds no REQUIRED_NODE_VERSION assignment in the tree, is consistent with this. Readers of each copy therefore parse a two-mode dispatch with only one reachable mode, which is the Special-General Mixture / Nonobvious Code red flag, and the reviewer quotes AGENTS.md's rule against options no caller passes. Remedy gap: if a j4k-align template renders these files, a local edit to read .node-version directly would be overwritten. The fix then belongs in the template, which should render only the applicable branch, as the reviewer also notes. Low severity is appropriate. - disposition: none > Every copy of the step opens with a two-mode dispatch: a literal version from `REQUIRED_NODE_VERSION`, a file from `REQUIRED_NODE_VERSION_FILE`, and an "exactly one of" error for anything else. But each copy sets `REQUIRED_NODE_VERSION_FILE: ".node-version"` in the step-level `env:`, and nothing in the repo sets `REQUIRED_NODE_VERSION`. So the first branch can never run. The only other reachable outcome is a misconfiguration error: if someone later sets `REQUIRED_NODE_VERSION` at workflow or job level, the step fails with "needs exactly one of" instead of using it. Readers of all three workflows still have to parse a 12-line dispatch and the `pin="this workflow's Node pin"` wording to learn that the step just reads `.node-version`. This is special-purpose flexibility mixed into a check that has one real input, and it breaks AGENTS.md's "Build for Requirements That Exist Today": "No parameter or option no caller passes". > > Correction: read the pin directly, e.g. `version="$(cat .node-version)"`, with `pin=.node-version`, and drop the dispatch and the "exactly one" error. That shrinks each copy by about a third and leaves the version-shape check and the tool-cache lookup as they are. If a template serves other repos that pin Node inline, the template should render only the branch that applies to each repo instead of shipping both. > > What I examined: `grep -rn REQUIRED_NODE_VERSION` over the subject tree. Its only hits are the three step bodies in checks.yml, release.yml and dedupe-check.yml, each with the `REQUIRED_NODE_VERSION_FILE: ".node-version"` env entry and no `REQUIRED_NODE_VERSION` assignment at step, job or workflow level. I did not check runner-level environment. Runner-provided `REQUIRED_NODE_VERSION` is the one setting that would make the branch reachable, and then it would hit the error branch, not the version branch. Whether an upstream j4k-align template uses the other mode for other repos is outside this tree and unverified. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (1) - `01M6JNKVJD5ZE6Z15M8F83Y3E2` medium — The 30-line baked-Node check is pasted verbatim into checks.yml, release.yml and dedupe-check.yml ## Coverage Coverage pass: 01M6JN0Q64DHFV7MQ34X70F2EK 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 | | restated-sets | whole | default | no-claims | 1 | no | | unix-cli | whole | default | no-claims | 1 | no | | module-design | whole | default | no-claims | 1 | no | | aposd-plain | whole | default | claims-emitted | 1 | no | - test-trimming — skipped-by-dispatch: no tests changed - project-docs — skipped-by-dispatch: no project documentation changed - use-effect — skipped-by-dispatch: no React code; changes are CI workflow YAML and a shell script - react — skipped-by-dispatch: no React code; changes are CI workflow YAML and a shell script

🚀 1

forgejo-actions reviewed

2026-11-04 07:04:43 +00:00

.forgejo/workflows/checks.yml

Lines 189-191

					
				@ -184,0 +186,6 @@

				          REQUIRED_NODE_VERSION_FILE: ".node-version"

				        run: |

				          set -eu

				          if [ -n "${REQUIRED_NODE_VERSION:-}" ] && [ -z "${REQUIRED_NODE_VERSION_FILE:-}" ]; then

				            version="$REQUIRED_NODE_VERSION"

				            pin="this workflow's Node pin"

low — The baked-Node step's REQUIRED_NODE_VERSION mode can never run, because the step's own env always sets REQUIRED_NODE_VERSION_FILE

Every copy of the step opens with a two-mode dispatch: a literal version from REQUIRED_NODE_VERSION, a file from REQUIRED_NODE_VERSION_FILE, and an "exactly one of" error for anything else. But each copy sets REQUIRED_NODE_VERSION_FILE: ".node-version" in the step-level env:, and nothing in the repo sets REQUIRED_NODE_VERSION. So the first branch can never run. The only other reachable outcome is a misconfiguration error: if someone later sets REQUIRED_NODE_VERSION at workflow or job level, the step fails with "needs exactly one of" instead of using it. Readers of all three workflows still have to parse a 12-line dispatch and the pin="this workflow's Node pin" wording to learn that the step just reads .node-version. This is special-purpose flexibility mixed into a check that has one real input, and it breaks AGENTS.md's "Build for Requirements That Exist Today": "No parameter or option no caller passes".

Correction: read the pin directly, e.g. version="$(cat .node-version)", with pin=.node-version, and drop the dispatch and the "exactly one" error. That shrinks each copy by about a third and leaves the version-shape check and the tool-cache lookup as they are. If a template serves other repos that pin Node inline, the template should render only the branch that applies to each repo instead of shipping both.

What I examined: grep -rn REQUIRED_NODE_VERSION over the subject tree. Its only hits are the three step bodies in checks.yml, release.yml and dedupe-check.yml, each with the REQUIRED_NODE_VERSION_FILE: ".node-version" env entry and no REQUIRED_NODE_VERSION assignment at step, job or workflow level. I did not check runner-level environment. Runner-provided REQUIRED_NODE_VERSION is the one setting that would make the branch reachable, and then it would hit the error branch, not the version branch. Whether an upstream j4k-align template uses the other mode for other repos is outside this tree and unverified.

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

**low** — The baked-Node step's REQUIRED_NODE_VERSION mode can never run, because the step's own env always sets REQUIRED_NODE_VERSION_FILE > Every copy of the step opens with a two-mode dispatch: a literal version from `REQUIRED_NODE_VERSION`, a file from `REQUIRED_NODE_VERSION_FILE`, and an "exactly one of" error for anything else. But each copy sets `REQUIRED_NODE_VERSION_FILE: ".node-version"` in the step-level `env:`, and nothing in the repo sets `REQUIRED_NODE_VERSION`. So the first branch can never run. The only other reachable outcome is a misconfiguration error: if someone later sets `REQUIRED_NODE_VERSION` at workflow or job level, the step fails with "needs exactly one of" instead of using it. Readers of all three workflows still have to parse a 12-line dispatch and the `pin="this workflow's Node pin"` wording to learn that the step just reads `.node-version`. This is special-purpose flexibility mixed into a check that has one real input, and it breaks AGENTS.md's "Build for Requirements That Exist Today": "No parameter or option no caller passes". > > Correction: read the pin directly, e.g. `version="$(cat .node-version)"`, with `pin=.node-version`, and drop the dispatch and the "exactly one" error. That shrinks each copy by about a third and leaves the version-shape check and the tool-cache lookup as they are. If a template serves other repos that pin Node inline, the template should render only the branch that applies to each repo instead of shipping both. > > What I examined: `grep -rn REQUIRED_NODE_VERSION` over the subject tree. Its only hits are the three step bodies in checks.yml, release.yml and dedupe-check.yml, each with the `REQUIRED_NODE_VERSION_FILE: ".node-version"` env entry and no `REQUIRED_NODE_VERSION` assignment at step, job or workflow level. I did not check runner-level environment. Runner-provided `REQUIRED_NODE_VERSION` is the one setting that would make the branch reachable, and then it would hit the error branch, not the version branch. Whether an upstream j4k-align template uses the other mode for other repos is outside this tree and unverified. lens `aposd-plain` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M6JNM899KQGFZ7RBGSAFRG6G` of review `01M6JN0Q5ZX3AW0PE8AC5ZXAKQ`

👎 1

This repeats a finding already settled in this rollout: j4k/sorcery-rules-skill#28 (comment).

The REQUIRED_NODE_VERSION branch has a caller in align itself: templates/workflows/credential-contract-forgejo.yml.hbs in j4k/align at 7a2b6118 sets it. The step body is one shared script, BAKED_NODE_CHECK_SCRIPT in src/template-scripts/baked-node-check-script.ts, rendered into every managed workflow that runs setup-node. These workflows are j4k-align --fix output, so the proposed local edit would be drift that the next audit reports and --fix reverts. Rendering only the applicable branch per workflow is a change for j4k/align's template, and I am reporting it there.

This repeats a finding already settled in this rollout: https://code.j4k.dev/j4k/sorcery-rules-skill/pulls/28#issuecomment-230700. The `REQUIRED_NODE_VERSION` branch has a caller in align itself: `templates/workflows/credential-contract-forgejo.yml.hbs` in j4k/align at `7a2b6118` sets it. The step body is one shared script, `BAKED_NODE_CHECK_SCRIPT` in `src/template-scripts/baked-node-check-script.ts`, rendered into every managed workflow that runs setup-node. These workflows are `j4k-align --fix` output, so the proposed local edit would be drift that the next audit reports and `--fix` reverts. Rendering only the applicable branch per workflow is a change for j4k/align's template, and I am reporting it there.

jercik marked this conversation as resolved

jercik commented

2026-11-04 07:06:07 +00:00

Replying to comment #230714

Unadjudicated claim 01M6JNKVJD5ZE6Z15M8F83Y3E2 (medium, the baked-Node check repeated in checks.yml, release.yml and dedupe-check.yml): not a defect in this PR. It repeats a claim settled in this rollout at j4k/sorcery-rules-skill#28 (comment).

These workflows are j4k-align --fix output. Each align template emits the step with {{templateScript "baked-node-check" 10}}, whose single source is BAKED_NODE_CHECK_SCRIPT in src/template-scripts/baked-node-check-script.ts (j4k/align at 7a2b6118). A hand edit to one copy shows up as a drifted managed artifact in the next align audit, so the copies cannot diverge silently.

> Replying to comment #230714 Unadjudicated claim `01M6JNKVJD5ZE6Z15M8F83Y3E2` (medium, the baked-Node check repeated in `checks.yml`, `release.yml` and `dedupe-check.yml`): not a defect in this PR. It repeats a claim settled in this rollout at https://code.j4k.dev/j4k/sorcery-rules-skill/pulls/28#issuecomment-230698. These workflows are `j4k-align --fix` output. Each align template emits the step with `{{templateScript "baked-node-check" 10}}`, whose single source is `BAKED_NODE_CHECK_SCRIPT` in `src/template-scripts/baked-node-check-script.ts` (j4k/align at `7a2b6118`). A hand edit to one copy shows up as a drifted managed artifact in the next align audit, so the copies cannot diverge silently.

jercik merged commit 82cb601b0a into main

2026-11-04 07:06:29 +00:00

jercik deleted branch chore/align-17-17-1

2026-11-04 07:06:29 +00:00

jercik referenced this pull request from a commit

2026-11-04 07:06:31 +00:00

chore: align with j4k-align 17.17.1 (#17)

Sign in to join this conversation.

No reviewers

No labels

No milestone