chore: sync managed files with align 17.3.0 #17

jercik · 2026-10-27T11:49:20Z

jercik commented

2026-10-27 11:49:20 +00:00

Syncs managed files with @j4k/align 17.3.0 (j4k-align --fix). Changed checks.yml, dedupe-check.yml and release.yml.

🤖 Generated with Claude Code

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

jercik added 1 commit

2026-10-27 11:49:20 +00:00

chore: sync managed files with align 17.3.0

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 3s

Details

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

Details

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

Details

Checks / qc-result (pull_request) Has been skipped

Details

Review / Review (pull_request_target) Successful in 3m23s

Details

23f335b092

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

forgejo-actions commented

2026-10-27 11:52:42 +00:00

Review 01M5YK36K2TFHD503HYNJDC9AD — head 23f335b09273e6062b9ebbc516ee3da66b65d092

Review — j4k-oss/fta-check @ `afc0f14f39`

Scope: diff against base tree 22371fc6baba
Review finished: 4 succeeded, 0 failed, 6 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 (3)

medium — reuse job comment restates the 24-hour cutoff that the lookup step defines

claim: 01M5YK5YCCSA2K7NCFYEFGX5BG
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 01M5YK6GT6BRTF59EK2D0Z1A4J · valid: The grounded excerpt both points to the authority ('limit and cutoff in the lookup step') and copies its value ('within the last 24 hours'). The rubric's pointer exception covers only the pointer, not a value stated beside it. The reviewer quotes the authority, cutoff="$(date -u -d '24 hours ago' +%s)". Following the pointer means reading one plain line, so the copy serves no separate reader task: a reader of a job-level comment needs to know only that candidates must be recent. The copy agrees with the code today, so this is a maintenance defect, not a false statement. The fix is to say 'recent' and keep the pointer. One caveat: this is a single duplicated value, not a member list or count, so I would rate it low rather than medium.
disposition: none

The comment above the reuse job says a candidate run must be 'created within the last 24 hours (limit and cutoff in the lookup step)'. The age window is defined by the code in the lookup step: cutoff="$(date -u -d '24 hours ago' +%s)" (and the page size by limit=20 in the runs URL). The comment both points at limit and cutoff and copies the value they hold, so changing the window means editing two places, and the comment goes stale silently if only the code changes. Today the copy agrees with the code (24 hours in both), so this is a maintenance defect, not yet a false statement. The pointer already serves the reader who needs the exact window; the reader of a job-level comment needs to know that candidates are recent. Correction: write 'created within a recent window (limit and cutoff in the lookup step)', or drop the number and keep the pointer. This also keeps the comment from contradicting the step if the cutoff is retuned. I read the whole reuse job in checks.yml; the base side of the comment (30 days) is in the diff, which shows the value has already changed once, so the copy is plausibly edited again.

low — Comment restates the 20-second timeouts that sit on the calls it describes

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

# The candidate loop stops at this deadline; each network call below is bounded to 20 seconds.

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5YK6GT6BRTF59EK2D0Z1A4J · valid: The grounded comment copies the literal '20 seconds'. The reviewer reports three separate places that set it: timeout 20 in fetch_commit and --max-time 20 on two curl calls. The comment has no authority of its own, so retuning any one call silently makes it wrong. That duplicated value is a supported low-severity defect. The proposed remedy goes too far, though. The clause 'each network call below is bounded' records an invariant: the deadline check only bounds the loop's runtime if every call in it has its own timeout, and a maintainer adding a call needs to know that. Under the comment guidelines that invariant should stay. A suitable correction keeps the invariant and drops the number, for example 'The candidate loop stops at this deadline; every network call below must carry its own timeout so the job finishes inside timeout-minutes.'
disposition: none

The comment says 'each network call below is bounded to 20 seconds'. The bound is set in code by timeout 20 in fetch_commit and --max-time 20 on both curl calls (the runs listing and qc_executed). The comment makes a completeness claim ('each network call') about a set the code defines and copies its value, so adding a call or retuning a timeout makes it wrong without any failing check. It agrees with the code today. The reader's useful fact is why the deadline exists: the loop must not run past the job's timeout-minutes: 3 because of slow calls, with the 60-second deadline leaving room for one more bounded call. Correction: 'The candidate loop stops at this deadline so the job finishes inside its timeout.' and let the timeout 20 and --max-time 20 arguments speak for themselves. I read the reuse job and counted the network calls (one git fetch helper, two curl calls); I did not run the workflow.

low — release.yml points to an ADR file that does not exist in this repository

claim: 01M5YK5XWMFR14805F587MSSCZ
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 01M5YK6GT6BRTF59EK2D0Z1A4J · valid: The grounded excerpt shows the release.yml header comment pointing to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md. That comment is the only place given for the rationale behind the reuse gate. Two separate lenses report a tree listing with no docs/ directory and a grep that finds the path only in this comment. Nothing in the batch suggests the file exists. The comment uses a repo-relative path, so a maintainer who follows it in this repository finds nothing, even if a template repository holds the ADR. The remedy is sound: name the real location, add the ADR, or drop the parenthetical and keep the sentence that already states the behavior. Low severity fits.
duplicates: 01M5YK6A5NRSJNXWCYDPPRYRHZ (general-bug)
disposition: none

The header comment of release.yml sends the reader to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md for the reasoning behind the release gate's reuse of a pull request pass. The unpacked tree has no docs/ directory at all (top level: AGENTS.md, CLAUDE.md, README.md, bin, scripts, src, config files), and grepping the tree for 'same-tree' or 'reuse' finds the path only in this comment. A maintainer who wants to know why the gate may skip quality-checks, or what the 24-hour and same-tree rules protect against, follows the pointer and finds nothing. The pointer is the only place the comment names for the rationale, so the reader task (understand why the gate can skip the checks) is left unserved. Correction: if the ADR lives in another repository or is rendered here by the alignment tool, name that location (repository plus path) or add the ADR to this repository; if no ADR exists, delete the parenthetical and keep the sentence 'it runs the managed quality suite, or reuses a pull request pass on the same tree', which already states the behavior. I examined the full diff of the three workflow files and the tree listing; I could not check whether the ADR exists in a template source repository (proof gap), which is why the severity is low.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (0)
duplicate-of (1)
- 01M5YK6A5NRSJNXWCYDPPRYRHZ low — release.yml cites an ADR file that does not exist in the repository → 01M5YK5XWMFR14805F587MSSCZ
unadjudicated (1)
- 01M5YK6AFFANJT1XVS16927PHR low — qc_executed assumes the run-jobs endpoint returns a bare array with status==success; a different shape silently disables reuse

Coverage

Coverage pass: 01M5YK36MY7E8E43DWJET74A30
Accounting: complete (all slots terminal; see slot results for failures)
Slot health: healthy

lens	part	arm	unit status	runs	loss
general-bug	whole	default	claims-emitted	1	no
writing-quality	whole	default	claims-emitted	1	no
project-docs	whole	default	no-claims	1	no
restated-sets	whole	default	no-claims	1	no

test-trimming — skipped-by-dispatch: no tests changed
unix-cli — skipped-by-dispatch: only CI workflow YAML changed; no CLI interface
use-effect — skipped-by-dispatch: no React code changed
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

**Review** `01M5YK36K2TFHD503HYNJDC9AD` — head `23f335b09273e6062b9ebbc516ee3da66b65d092` # Review — j4k-oss/fta-check @ afc0f14f3941 Scope: diff against base tree `22371fc6baba` Review finished: 4 succeeded, 0 failed, 6 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 (3) ### medium — reuse job comment restates the 24-hour cutoff that the lookup step defines - claim: `01M5YK5YCCSA2K7NCFYEFGX5BG` - 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 `01M5YK6GT6BRTF59EK2D0Z1A4J` · valid: The grounded excerpt both points to the authority ('`limit` and `cutoff` in the lookup step') and copies its value ('within the last 24 hours'). The rubric's pointer exception covers only the pointer, not a value stated beside it. The reviewer quotes the authority, cutoff="$(date -u -d '24 hours ago' +%s)". Following the pointer means reading one plain line, so the copy serves no separate reader task: a reader of a job-level comment needs to know only that candidates must be recent. The copy agrees with the code today, so this is a maintenance defect, not a false statement. The fix is to say 'recent' and keep the pointer. One caveat: this is a single duplicated value, not a member list or count, so I would rate it low rather than medium. - disposition: none > The comment above the reuse job says a candidate run must be 'created within the last 24 hours (`limit` and `cutoff` in the lookup step)'. The age window is defined by the code in the lookup step: `cutoff="$(date -u -d '24 hours ago' +%s)"` (and the page size by `limit=20` in the runs URL). The comment both points at `limit` and `cutoff` and copies the value they hold, so changing the window means editing two places, and the comment goes stale silently if only the code changes. Today the copy agrees with the code (24 hours in both), so this is a maintenance defect, not yet a false statement. The pointer already serves the reader who needs the exact window; the reader of a job-level comment needs to know that candidates are recent. Correction: write 'created within a recent window (`limit` and `cutoff` in the lookup step)', or drop the number and keep the pointer. This also keeps the comment from contradicting the step if the cutoff is retuned. I read the whole reuse job in checks.yml; the base side of the comment (30 days) is in the diff, which shows the value has already changed once, so the copy is plausibly edited again. ### low — Comment restates the 20-second timeouts that sit on the calls it describes - claim: `01M5YK5YWGC7ZBMK1MS025KEWR` - anchor: `.forgejo/workflows/checks.yml` (snippet) ``` # The candidate loop stops at this deadline; each network call below is bounded to 20 seconds. ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5YK6GT6BRTF59EK2D0Z1A4J` · valid: The grounded comment copies the literal '20 seconds'. The reviewer reports three separate places that set it: `timeout 20` in fetch_commit and `--max-time 20` on two curl calls. The comment has no authority of its own, so retuning any one call silently makes it wrong. That duplicated value is a supported low-severity defect. The proposed remedy goes too far, though. The clause 'each network call below is bounded' records an invariant: the deadline check only bounds the loop's runtime if every call in it has its own timeout, and a maintainer adding a call needs to know that. Under the comment guidelines that invariant should stay. A suitable correction keeps the invariant and drops the number, for example 'The candidate loop stops at this deadline; every network call below must carry its own timeout so the job finishes inside timeout-minutes.' - disposition: none > The comment says 'each network call below is bounded to 20 seconds'. The bound is set in code by `timeout 20` in `fetch_commit` and `--max-time 20` on both `curl` calls (the runs listing and `qc_executed`). The comment makes a completeness claim ('each network call') about a set the code defines and copies its value, so adding a call or retuning a timeout makes it wrong without any failing check. It agrees with the code today. The reader's useful fact is why the deadline exists: the loop must not run past the job's `timeout-minutes: 3` because of slow calls, with the 60-second deadline leaving room for one more bounded call. Correction: 'The candidate loop stops at this deadline so the job finishes inside its timeout.' and let the `timeout 20` and `--max-time 20` arguments speak for themselves. I read the reuse job and counted the network calls (one git fetch helper, two curl calls); I did not run the workflow. ### low — release.yml points to an ADR file that does not exist in this repository - claim: `01M5YK5XWMFR14805F587MSSCZ` - 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 `01M5YK6GT6BRTF59EK2D0Z1A4J` · valid: The grounded excerpt shows the release.yml header comment pointing to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md. That comment is the only place given for the rationale behind the reuse gate. Two separate lenses report a tree listing with no docs/ directory and a grep that finds the path only in this comment. Nothing in the batch suggests the file exists. The comment uses a repo-relative path, so a maintainer who follows it in this repository finds nothing, even if a template repository holds the ADR. The remedy is sound: name the real location, add the ADR, or drop the parenthetical and keep the sentence that already states the behavior. Low severity fits. - duplicates: `01M5YK6A5NRSJNXWCYDPPRYRHZ` (general-bug) - disposition: none > The header comment of release.yml sends the reader to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md for the reasoning behind the release gate's reuse of a pull request pass. The unpacked tree has no docs/ directory at all (top level: AGENTS.md, CLAUDE.md, README.md, bin, scripts, src, config files), and grepping the tree for 'same-tree' or 'reuse' finds the path only in this comment. A maintainer who wants to know why the gate may skip quality-checks, or what the 24-hour and same-tree rules protect against, follows the pointer and finds nothing. The pointer is the only place the comment names for the rationale, so the reader task (understand why the gate can skip the checks) is left unserved. Correction: if the ADR lives in another repository or is rendered here by the alignment tool, name that location (repository plus path) or add the ADR to this repository; if no ADR exists, delete the parenthetical and keep the sentence 'it runs the managed quality suite, or reuses a pull request pass on the same tree', which already states the behavior. I examined the full diff of the three workflow files and the tree listing; I could not check whether the ADR exists in a template source repository (proof gap), which is why the severity is low. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (1) - `01M5YK6A5NRSJNXWCYDPPRYRHZ` low — release.yml cites an ADR file that does not exist in the repository → `01M5YK5XWMFR14805F587MSSCZ` - unadjudicated (1) - `01M5YK6AFFANJT1XVS16927PHR` low — qc_executed assumes the run-jobs endpoint returns a bare array with status==success; a different shape silently disables reuse ## Coverage Coverage pass: 01M5YK36MY7E8E43DWJET74A30 Accounting: complete (all slots terminal; see slot results for failures) Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | general-bug | whole | default | claims-emitted | 1 | no | | writing-quality | whole | default | claims-emitted | 1 | no | | project-docs | whole | default | no-claims | 1 | no | | restated-sets | whole | default | no-claims | 1 | no | - test-trimming — skipped-by-dispatch: no tests changed - unix-cli — skipped-by-dispatch: only CI workflow YAML changed; no CLI interface - use-effect — skipped-by-dispatch: no React code changed - 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

forgejo-actions reviewed

2026-10-27 11:52:42 +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 — reuse job comment restates the 24-hour cutoff that the lookup step defines

The comment above the reuse job says a candidate run must be 'created within the last 24 hours (limit and cutoff in the lookup step)'. The age window is defined by the code in the lookup step: cutoff="$(date -u -d '24 hours ago' +%s)" (and the page size by limit=20 in the runs URL). The comment both points at limit and cutoff and copies the value they hold, so changing the window means editing two places, and the comment goes stale silently if only the code changes. Today the copy agrees with the code (24 hours in both), so this is a maintenance defect, not yet a false statement. The pointer already serves the reader who needs the exact window; the reader of a job-level comment needs to know that candidates are recent. Correction: write 'created within a recent window (limit and cutoff in the lookup step)', or drop the number and keep the pointer. This also keeps the comment from contradicting the step if the cutoff is retuned. I read the whole reuse job in checks.yml; the base side of the comment (30 days) is in the diff, which shows the value has already changed once, so the copy is plausibly edited again.

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

**medium** — reuse job comment restates the 24-hour cutoff that the lookup step defines > The comment above the reuse job says a candidate run must be 'created within the last 24 hours (`limit` and `cutoff` in the lookup step)'. The age window is defined by the code in the lookup step: `cutoff="$(date -u -d '24 hours ago' +%s)"` (and the page size by `limit=20` in the runs URL). The comment both points at `limit` and `cutoff` and copies the value they hold, so changing the window means editing two places, and the comment goes stale silently if only the code changes. Today the copy agrees with the code (24 hours in both), so this is a maintenance defect, not yet a false statement. The pointer already serves the reader who needs the exact window; the reader of a job-level comment needs to know that candidates are recent. Correction: write 'created within a recent window (`limit` and `cutoff` in the lookup step)', or drop the number and keep the pointer. This also keeps the comment from contradicting the step if the cutoff is retuned. I read the whole reuse job in checks.yml; the base side of the comment (30 days) is in the diff, which shows the value has already changed once, so the copy is plausibly edited again. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5YK5YCCSA2K7NCFYEFGX5BG` of review `01M5YK36K2TFHD503HYNJDC9AD`

.forgejo/workflows/checks.yml

					
				@ -73,12 +78,15 @@ jobs:

				              exit 0

				              ;;

				          esac

				          # The candidate loop stops at this deadline; each network call below is bounded to 20 seconds.

low — Comment restates the 20-second timeouts that sit on the calls it describes

The comment says 'each network call below is bounded to 20 seconds'. The bound is set in code by timeout 20 in fetch_commit and --max-time 20 on both curl calls (the runs listing and qc_executed). The comment makes a completeness claim ('each network call') about a set the code defines and copies its value, so adding a call or retuning a timeout makes it wrong without any failing check. It agrees with the code today. The reader's useful fact is why the deadline exists: the loop must not run past the job's timeout-minutes: 3 because of slow calls, with the 60-second deadline leaving room for one more bounded call. Correction: 'The candidate loop stops at this deadline so the job finishes inside its timeout.' and let the timeout 20 and --max-time 20 arguments speak for themselves. I read the reuse job and counted the network calls (one git fetch helper, two curl calls); I did not run the workflow.

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

**low** — Comment restates the 20-second timeouts that sit on the calls it describes > The comment says 'each network call below is bounded to 20 seconds'. The bound is set in code by `timeout 20` in `fetch_commit` and `--max-time 20` on both `curl` calls (the runs listing and `qc_executed`). The comment makes a completeness claim ('each network call') about a set the code defines and copies its value, so adding a call or retuning a timeout makes it wrong without any failing check. It agrees with the code today. The reader's useful fact is why the deadline exists: the loop must not run past the job's `timeout-minutes: 3` because of slow calls, with the 60-second deadline leaving room for one more bounded call. Correction: 'The candidate loop stops at this deadline so the job finishes inside its timeout.' and let the `timeout 20` and `--max-time 20` arguments speak for themselves. I read the reuse job and counted the network calls (one git fetch helper, two curl calls); I did not run the workflow. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5YK5YWGC7ZBMK1MS025KEWR` of review `01M5YK36K2TFHD503HYNJDC9AD`

.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).

low — release.yml points to an ADR file that does not exist in this repository

The header comment of release.yml sends the reader to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md for the reasoning behind the release gate's reuse of a pull request pass. The unpacked tree has no docs/ directory at all (top level: AGENTS.md, CLAUDE.md, README.md, bin, scripts, src, config files), and grepping the tree for 'same-tree' or 'reuse' finds the path only in this comment. A maintainer who wants to know why the gate may skip quality-checks, or what the 24-hour and same-tree rules protect against, follows the pointer and finds nothing. The pointer is the only place the comment names for the rationale, so the reader task (understand why the gate can skip the checks) is left unserved. Correction: if the ADR lives in another repository or is rendered here by the alignment tool, name that location (repository plus path) or add the ADR to this repository; if no ADR exists, delete the parenthetical and keep the sentence 'it runs the managed quality suite, or reuses a pull request pass on the same tree', which already states the behavior. I examined the full diff of the three workflow files and the tree listing; I could not check whether the ADR exists in a template source repository (proof gap), which is why the severity is low.

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

**low** — release.yml points to an ADR file that does not exist in this repository > The header comment of release.yml sends the reader to docs/adr/0004-forgejo-checks-reuse-same-tree-passes.md for the reasoning behind the release gate's reuse of a pull request pass. The unpacked tree has no docs/ directory at all (top level: AGENTS.md, CLAUDE.md, README.md, bin, scripts, src, config files), and grepping the tree for 'same-tree' or 'reuse' finds the path only in this comment. A maintainer who wants to know why the gate may skip quality-checks, or what the 24-hour and same-tree rules protect against, follows the pointer and finds nothing. The pointer is the only place the comment names for the rationale, so the reader task (understand why the gate can skip the checks) is left unserved. Correction: if the ADR lives in another repository or is rendered here by the alignment tool, name that location (repository plus path) or add the ADR to this repository; if no ADR exists, delete the parenthetical and keep the sentence 'it runs the managed quality suite, or reuses a pull request pass on the same tree', which already states the behavior. I examined the full diff of the three workflow files and the tree listing; I could not check whether the ADR exists in a template source repository (proof gap), which is why the severity is low. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5YK5XWMFR14805F587MSSCZ` of review `01M5YK36K2TFHD503HYNJDC9AD`