chore: sync managed files with align 17.3.0 #12

jercik · 2026-10-27T11:56:23Z

jercik commented

2026-10-27 11:56:23 +00:00

Syncs managed files with @j4k/align 17.3.0 (j4k-align --fix).

It updates the checks.yml, dedupe-check.yml and release.yml workflows.

🤖 Generated with Claude Code

Syncs managed files with `@j4k/align` 17.3.0 (`j4k-align --fix`). It updates the `checks.yml`, `dedupe-check.yml` and `release.yml` workflows. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jercik added 1 commit

2026-10-27 11:56:23 +00:00

chore: sync managed files with align 17.3.0

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

Details

Checks / qc-result (pull_request) Has been skipped

Details

Checks / reuse (pull_request) Has been skipped

Details

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

Details

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

Details

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

Details

Review / Review (pull_request_target) Successful in 3m58s

Details

991ff0bdae

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

forgejo-actions commented

2026-10-27 12:00:20 +00:00

Review 01M5YKG50YK357NQXPEKAKMS0W — head 991ff0bdae25ba66ceafca2dcd74e8b92598ac7e

Review — j4k-oss/worktree-remove @ `b3e2e4ab50`

Scope: diff against base tree c4f01b0bb4c7
Review finished: 5 succeeded, 0 failed, 5 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 (2)

medium — The reuse header comment restates the 24-hour window that `cutoff` defines

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

within the last 24 hours (`limit` and `cutoff` in the lookup step)

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5YKMSQ9Z5A955RVECTPFSCS · valid: The grounded snippet 'within the last 24 hours (limit and cutoff in the lookup step)' states the age value and also points to the variables that hold it. According to the reviewer's quote, the authority is cutoff="$(date -u -d '24 hours ago' +%s)" in the same file's lookup step. Under the writing skill's 'One Idea, One Place' rule, the pointer alone lets a reader find the value, so the number is a second copy that must be edited along with cutoff and goes stale silently otherwise. The values agree today. The header's reader needs freshness, not the exact figure, so the proposed 'recent ... (count and age bounds are limit and cutoff)' keeps the meaning and loses no constraint. The defect is real but I would rate it low, not medium: the copy sits in the same file a short distance from the code, and it does not yet disagree.
disposition: none

The comment states the candidate age window as a number while pointing at the variables that set it, so changing the window means editing two places, and the comment goes stale silently if only the code changes.

The comment says a candidate is "a successful pull request run of this file created within the last 24 hours (limit and cutoff in the lookup step)". The authority is cutoff="$(date -u -d '24 hours ago' +%s)" in the lookup step (and limit=20 in the runs query). The two agree at this revision, so this is a copy that still agrees, not a contradiction. The comment is also internally odd: limit is a run count (20), not an age, so the parenthetical names both variables but only cutoff is the age.

Correction: keep the reader-useful meaning (candidates are recent pull request runs, bounded by count and age) and drop the number: "A candidate is a recent successful pull request run of this file (the count and age bounds are limit and cutoff in the lookup step) whose quality-checks jobs ran and all succeeded...". The same applies to the sibling comment "each network call below is bounded to 20 seconds" next to deadline=$((SECONDS + 60)) and the timeout 20 / --max-time 20 flags, though those sit beside the code they describe and are lower value.

Examined: the full reuse job in checks.yml as unpacked, including the cutoff and limit lines.

medium — release.yml points to an ADR file that does not exist in the repository

claim: 01M5YKJTXDDKJCHC9V9MA368PP
anchor: .forgejo/workflows/release.yml (snippet)

a pull request pass on the same tree (docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md).

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5YKMSQ9Z5A955RVECTPFSCS · valid: The grounded exact snippet shows the release.yml header comment pointing to the rationale with a repo-relative path, docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md. The reviewer reports that the unpacked tree has no docs directory, that find -ipath 'adr' returns nothing, and that the diff touches only checks.yml, dedupe-check.yml and release.yml. A maintainer who follows the pointer to learn why release may skip the quality suite therefore reaches nothing, which fails the writing skill's rule that a pointer must let the reader get the answer. Nothing in the batch contradicts this. The sibling claim notes one more, unrelated docs/adr string in scripts/check-dts-tsc.ts, which does not affect the conclusion. If the ADR lives in the j4k-align template repository, the repo-relative path still does not resolve here. The proposed remedy is sound: add the ADR, drop the parenthetical, or name the other repository and path. Because the workflow is rendered by j4k-align, the fix belongs in that template. Medium severity is reasonable because the pointer is the only route to the rationale for a release-gate bypass.
disposition: none

The header comment sends the reader to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md for the rationale behind the release gate's same-tree reuse. A maintainer who wants to know why a release can skip the quality suite follows the pointer and finds nothing, so the rationale for skipping release checks is unreachable.

The comment reads: "the release gate verifies the merged revision before publishing: it runs the managed quality suite, or reuses a pull request pass on the same tree (docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md)." The unpacked subject tree has no docs directory at all; find . -ipath '*adr*' returns nothing and the only mention of docs/adr anywhere in the tree is this line. The file list of the diff (checks.yml, dedupe-check.yml, release.yml) adds no ADR either.

Correction: either add the ADR in this change, or drop the parenthetical and keep the sentence, which already states the current behavior. If the ADR lives in another repository (this workflow is rendered by j4k-align, so the template repository may hold it), name that repository and path rather than a repo-relative path that does not resolve here. The pointer is a task-serving one (why reuse is safe), so keep it only if it resolves.

Examined: full diff, the unpacked tree listing, a grep for docs/adr and 0004. Not verified: whether the ADR exists in another repository; the history is not available to me.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (1)
- 01M5YKJQVH2T90FKYTFBW10QAY low — release.yml points to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md, which does not exist in the tree
duplicate-of (0)
unadjudicated (1)
- 01M5YKK5CCJ7G77NTJK76RHW1K low — The out-of-step error names j4k-align --fix without the --path argument other repository messages require

Coverage

Coverage pass: 01M5YKG5K5FZGX7A06FB50QM7S
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
restated-sets	whole	default	no-claims	1	no
project-docs	whole	default	claims-emitted	1	no
unix-cli	whole	default	no-claims	1	no

test-trimming — skipped-by-dispatch: no tests changed
use-effect — skipped-by-dispatch: no React code changed; only CI workflow YAML
module-design — skipped-by-dispatch: no code changed; only CI workflow YAML
aposd-plain — skipped-by-dispatch: no code changed; only CI workflow YAML
react — skipped-by-dispatch: no React components changed; only CI workflow YAML

**Review** `01M5YKG50YK357NQXPEKAKMS0W` — head `991ff0bdae25ba66ceafca2dcd74e8b92598ac7e` # Review — j4k-oss/worktree-remove @ b3e2e4ab50a9 Scope: diff against base tree `c4f01b0bb4c7` Review finished: 5 succeeded, 0 failed, 5 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 (2) ### medium — The reuse header comment restates the 24-hour window that `cutoff` defines - claim: `01M5YKK4ZEG06TP88EC32JFB27` - anchor: `.forgejo/workflows/checks.yml` (snippet) ``` within the last 24 hours (`limit` and `cutoff` in the lookup step) ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5YKMSQ9Z5A955RVECTPFSCS` · valid: The grounded snippet 'within the last 24 hours (`limit` and `cutoff` in the lookup step)' states the age value and also points to the variables that hold it. According to the reviewer's quote, the authority is cutoff="$(date -u -d '24 hours ago' +%s)" in the same file's lookup step. Under the writing skill's 'One Idea, One Place' rule, the pointer alone lets a reader find the value, so the number is a second copy that must be edited along with cutoff and goes stale silently otherwise. The values agree today. The header's reader needs freshness, not the exact figure, so the proposed 'recent ... (count and age bounds are `limit` and `cutoff`)' keeps the meaning and loses no constraint. The defect is real but I would rate it low, not medium: the copy sits in the same file a short distance from the code, and it does not yet disagree. - disposition: none > The comment states the candidate age window as a number while pointing at the variables that set it, so changing the window means editing two places, and the comment goes stale silently if only the code changes. > > The comment says a candidate is "a successful pull request run of this file created within the last 24 hours (`limit` and `cutoff` in the lookup step)". The authority is `cutoff="$(date -u -d '24 hours ago' +%s)"` in the lookup step (and `limit=20` in the runs query). The two agree at this revision, so this is a copy that still agrees, not a contradiction. The comment is also internally odd: `limit` is a run count (20), not an age, so the parenthetical names both variables but only `cutoff` is the age. > > Correction: keep the reader-useful meaning (candidates are recent pull request runs, bounded by count and age) and drop the number: "A candidate is a recent successful pull request run of this file (the count and age bounds are `limit` and `cutoff` in the lookup step) whose quality-checks jobs ran and all succeeded...". The same applies to the sibling comment "each network call below is bounded to 20 seconds" next to `deadline=$((SECONDS + 60))` and the `timeout 20` / `--max-time 20` flags, though those sit beside the code they describe and are lower value. > > Examined: the full `reuse` job in checks.yml as unpacked, including the `cutoff` and `limit` lines. ### medium — release.yml points to an ADR file that does not exist in the repository - claim: `01M5YKJTXDDKJCHC9V9MA368PP` - anchor: `.forgejo/workflows/release.yml` (snippet) ``` a pull request pass on the same tree (docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md). ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5YKMSQ9Z5A955RVECTPFSCS` · valid: The grounded exact snippet shows the release.yml header comment pointing to the rationale with a repo-relative path, docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md. The reviewer reports that the unpacked tree has no docs directory, that find -ipath '*adr*' returns nothing, and that the diff touches only checks.yml, dedupe-check.yml and release.yml. A maintainer who follows the pointer to learn why release may skip the quality suite therefore reaches nothing, which fails the writing skill's rule that a pointer must let the reader get the answer. Nothing in the batch contradicts this. The sibling claim notes one more, unrelated docs/adr string in scripts/check-dts-tsc.ts, which does not affect the conclusion. If the ADR lives in the j4k-align template repository, the repo-relative path still does not resolve here. The proposed remedy is sound: add the ADR, drop the parenthetical, or name the other repository and path. Because the workflow is rendered by j4k-align, the fix belongs in that template. Medium severity is reasonable because the pointer is the only route to the rationale for a release-gate bypass. - disposition: none > The header comment sends the reader to `docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md` for the rationale behind the release gate's same-tree reuse. A maintainer who wants to know why a release can skip the quality suite follows the pointer and finds nothing, so the rationale for skipping release checks is unreachable. > > The comment reads: "the release gate verifies the merged revision before publishing: it runs the managed quality suite, or reuses a pull request pass on the same tree (docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md)." The unpacked subject tree has no `docs` directory at all; `find . -ipath '*adr*'` returns nothing and the only mention of `docs/adr` anywhere in the tree is this line. The file list of the diff (checks.yml, dedupe-check.yml, release.yml) adds no ADR either. > > Correction: either add the ADR in this change, or drop the parenthetical and keep the sentence, which already states the current behavior. If the ADR lives in another repository (this workflow is rendered by `j4k-align`, so the template repository may hold it), name that repository and path rather than a repo-relative path that does not resolve here. The pointer is a task-serving one (why reuse is safe), so keep it only if it resolves. > > Examined: full diff, the unpacked tree listing, a grep for `docs/adr` and `0004`. Not verified: whether the ADR exists in another repository; the history is not available to me. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (1) - `01M5YKJQVH2T90FKYTFBW10QAY` low — release.yml points to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md, which does not exist in the tree - duplicate-of (0) - unadjudicated (1) - `01M5YKK5CCJ7G77NTJK76RHW1K` low — The out-of-step error names `j4k-align --fix` without the `--path` argument other repository messages require ## Coverage Coverage pass: 01M5YKG5K5FZGX7A06FB50QM7S 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 | | restated-sets | whole | default | no-claims | 1 | no | | project-docs | whole | default | claims-emitted | 1 | no | | unix-cli | whole | default | no-claims | 1 | no | - test-trimming — skipped-by-dispatch: no tests changed - use-effect — skipped-by-dispatch: no React code changed; only CI workflow YAML - module-design — skipped-by-dispatch: no code changed; only CI workflow YAML - aposd-plain — skipped-by-dispatch: no code changed; only CI workflow YAML - react — skipped-by-dispatch: no React components changed; only CI workflow YAML

forgejo-actions reviewed

2026-10-27 12:00:20 +00:00

.forgejo/workflows/checks.yml

					
				@ -50,0 +46,4 @@

				  # pull request, the release gate skips quality-checks. Only release callers

				  # (workflow_call with release_gate) look; pull requests always run the full

				  # checks. A candidate is a successful pull request run of this file created

				  # within the last 24 hours (`limit` and `cutoff` in the lookup step) whose

medium — The reuse header comment restates the 24-hour window that cutoff defines

The comment states the candidate age window as a number while pointing at the variables that set it, so changing the window means editing two places, and the comment goes stale silently if only the code changes.

The comment says a candidate is "a successful pull request run of this file created within the last 24 hours (limit and cutoff in the lookup step)". The authority is cutoff="$(date -u -d '24 hours ago' +%s)" in the lookup step (and limit=20 in the runs query). The two agree at this revision, so this is a copy that still agrees, not a contradiction. The comment is also internally odd: limit is a run count (20), not an age, so the parenthetical names both variables but only cutoff is the age.

Correction: keep the reader-useful meaning (candidates are recent pull request runs, bounded by count and age) and drop the number: "A candidate is a recent successful pull request run of this file (the count and age bounds are limit and cutoff in the lookup step) whose quality-checks jobs ran and all succeeded...". The same applies to the sibling comment "each network call below is bounded to 20 seconds" next to deadline=$((SECONDS + 60)) and the timeout 20 / --max-time 20 flags, though those sit beside the code they describe and are lower value.

Examined: the full reuse job in checks.yml as unpacked, including the cutoff and limit lines.

lens writing-quality · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5YKK4ZEG06TP88EC32JFB27 of review 01M5YKG50YK357NQXPEKAKMS0W

**medium** — The reuse header comment restates the 24-hour window that `cutoff` defines > The comment states the candidate age window as a number while pointing at the variables that set it, so changing the window means editing two places, and the comment goes stale silently if only the code changes. > > The comment says a candidate is "a successful pull request run of this file created within the last 24 hours (`limit` and `cutoff` in the lookup step)". The authority is `cutoff="$(date -u -d '24 hours ago' +%s)"` in the lookup step (and `limit=20` in the runs query). The two agree at this revision, so this is a copy that still agrees, not a contradiction. The comment is also internally odd: `limit` is a run count (20), not an age, so the parenthetical names both variables but only `cutoff` is the age. > > Correction: keep the reader-useful meaning (candidates are recent pull request runs, bounded by count and age) and drop the number: "A candidate is a recent successful pull request run of this file (the count and age bounds are `limit` and `cutoff` in the lookup step) whose quality-checks jobs ran and all succeeded...". The same applies to the sibling comment "each network call below is bounded to 20 seconds" next to `deadline=$((SECONDS + 60))` and the `timeout 20` / `--max-time 20` flags, though those sit beside the code they describe and are lower value. > > Examined: the full `reuse` job in checks.yml as unpacked, including the `cutoff` and `limit` lines. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5YKK4ZEG06TP88EC32JFB27` of review `01M5YKG50YK357NQXPEKAKMS0W`

.forgejo/workflows/release.yml

					
				@ -5,1 +4,3 @@

				# managed quality suite on the merged revision before publishing.

				# Required PR status checks are intentionally disabled, so the release gate verifies

				# the merged revision before publishing: it runs the managed quality suite, or reuses

				# a pull request pass on the same tree (docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md).

medium — release.yml points to an ADR file that does not exist in the repository

The header comment sends the reader to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md for the rationale behind the release gate's same-tree reuse. A maintainer who wants to know why a release can skip the quality suite follows the pointer and finds nothing, so the rationale for skipping release checks is unreachable.

The comment reads: "the release gate verifies the merged revision before publishing: it runs the managed quality suite, or reuses a pull request pass on the same tree (docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md)." The unpacked subject tree has no docs directory at all; find . -ipath '*adr*' returns nothing and the only mention of docs/adr anywhere in the tree is this line. The file list of the diff (checks.yml, dedupe-check.yml, release.yml) adds no ADR either.

Correction: either add the ADR in this change, or drop the parenthetical and keep the sentence, which already states the current behavior. If the ADR lives in another repository (this workflow is rendered by j4k-align, so the template repository may hold it), name that repository and path rather than a repo-relative path that does not resolve here. The pointer is a task-serving one (why reuse is safe), so keep it only if it resolves.

Examined: full diff, the unpacked tree listing, a grep for docs/adr and 0004. Not verified: whether the ADR exists in another repository; the history is not available to me.

lens writing-quality · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5YKJTXDDKJCHC9V9MA368PP of review 01M5YKG50YK357NQXPEKAKMS0W

**medium** — release.yml points to an ADR file that does not exist in the repository > The header comment sends the reader to `docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md` for the rationale behind the release gate's same-tree reuse. A maintainer who wants to know why a release can skip the quality suite follows the pointer and finds nothing, so the rationale for skipping release checks is unreachable. > > The comment reads: "the release gate verifies the merged revision before publishing: it runs the managed quality suite, or reuses a pull request pass on the same tree (docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md)." The unpacked subject tree has no `docs` directory at all; `find . -ipath '*adr*'` returns nothing and the only mention of `docs/adr` anywhere in the tree is this line. The file list of the diff (checks.yml, dedupe-check.yml, release.yml) adds no ADR either. > > Correction: either add the ADR in this change, or drop the parenthetical and keep the sentence, which already states the current behavior. If the ADR lives in another repository (this workflow is rendered by `j4k-align`, so the template repository may hold it), name that repository and path rather than a repo-relative path that does not resolve here. The pointer is a task-serving one (why reuse is safe), so keep it only if it resolves. > > Examined: full diff, the unpacked tree listing, a grep for `docs/adr` and `0004`. Not verified: whether the ADR exists in another repository; the history is not available to me. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5YKJTXDDKJCHC9V9MA368PP` of review `01M5YKG50YK357NQXPEKAKMS0W`

jercik merged commit 1e3cd8d1a5 into main

2026-10-27 12:19:07 +00:00

jercik referenced this pull request from a commit

2026-10-27 12:19:08 +00:00

chore: sync managed files with align 17.3.0 (#12)

jercik deleted branch chore/align-17-3-0

2026-10-27 12:19:08 +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/worktree-remove!12

Rows
Columns

chore: sync managed files with align 17.3.0 #12

Review — j4k-oss/worktree-remove @ b3e2e4ab50

Findings (2)

medium — The reuse header comment restates the 24-hour window that cutoff defines

medium — release.yml points to an ADR file that does not exist in the repository

Other claims

Coverage

Review — j4k-oss/worktree-remove @ `b3e2e4ab50`

medium — The reuse header comment restates the 24-hour window that `cutoff` defines