fix: re-render managed review workflows for the Luna roster #9

jercik · 2026-08-07T13:48:15Z

jercik commented

2026-08-07 13:48:15 +00:00

This repo was still on the retired pre-Luna 5-slot review render, whose approach-smart-2, approach-3, and code-smart-2 slots fail with validation 400s against the axrecipe 11 exchange endpoint — so every PR here has been getting a partially failing review. The re-render, from released @j4k/align v1.110.3, deploys the current 8-slot Luna roster, the audited toolchain pins (@j4k/axrecipe@11.0.0, @j4k/axrun@12.0.0), and the audited review-writer pin bump.

This PR schedules zero pr-review jobs against itself: pull_request_target reads the workflow from the base branch. That is expected and does not block merging — the roster runs on the next PR.

Align withheld three visibility-dependent workflows in local-only --fix-workflows mode: checks.yml, dedupe-check.yml, and release.yml are untouched here and unchanged from main. A follow-up forge-connected j4k-align --fix run reconciles them.

This repo was still on the retired pre-Luna 5-slot review render, whose `approach-smart-2`, `approach-3`, and `code-smart-2` slots fail with validation 400s against the axrecipe 11 exchange endpoint — so every PR here has been getting a partially failing review. The re-render, from released `@j4k/align` v1.110.3, deploys the current 8-slot Luna roster, the audited toolchain pins (`@j4k/axrecipe@11.0.0`, `@j4k/axrun@12.0.0`), and the audited review-writer pin bump. This PR schedules zero `pr-review` jobs against itself: `pull_request_target` reads the workflow from the base branch. That is expected and does not block merging — the roster runs on the next PR. Align withheld three visibility-dependent workflows in local-only `--fix-workflows` mode: `checks.yml`, `dedupe-check.yml`, and `release.yml` are untouched here and unchanged from main. A follow-up forge-connected `j4k-align --fix` run reconciles them.

jercik added 1 commit

2026-08-07 13:48:15 +00:00

fix: re-render managed review workflows from @j4k/align v1.110.3

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

Details

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

Details

Checks / quality-checks (26.5.0) (pull_request) Successful in 57s

Details

PR Review / Prepare immutable review tools (pull_request_target) Successful in 1m56s

Details

PR Review / forgejo-review-approach-3 generator (pull_request_target) Failing after 52s

Details

PR Review / forgejo-review-approach-smart-2 generator (pull_request_target) Failing after 52s

Details

PR Review / forgejo-review-code-smart-2 generator (pull_request_target) Failing after 51s

Details

PR Review / forgejo-review-approach-smart-1 generator (pull_request_target) Successful in 2m33s

Details

PR Review / forgejo-review-code-smart-1 generator (pull_request_target) Successful in 5m13s

Details

PR Review / Dispatch and observe exact review writers (pull_request_target) Failing after 5m31s

Details

680c3b3ce7

forgejo-actions reviewed

2026-08-07 13:52:58 +00:00

forgejo-actions left a comment

Approach review: The approach looks good.

This is a mechanical re-render of two managed workflow files from a released generator (@j4k/align v1.110.3), replacing the retired 5-slot roster with the 8-slot Luna roster, bumping the toolchain pins to @j4k/axrecipe@11.0.0 / @j4k/axrun@12.0.0, and moving the review-writer action to a new pinned commit. Regenerating rather than hand-patching is the right call for generated files, and the stated fix (slots that 400 against the axrecipe 11 exchange endpoint) matches what the diff actually changes.

Checks on the rendered result:

The eight generate-* jobs, their name: values, their SLOT/RECIPE env pairs, the allowed-slot Set embedded in each context builder, and the slots array in observe-review-writers all agree on the same eight names — no half-renamed lane.
All eight npm install lines carry the new pins; no axrecipe@10.0.0 / axrun@6.0.0 remnants.
Normalizing each generator job by its own slot name shows the bodies are byte-identical apart from the intentional approach-vs-code trigger split (approach lanes gated on github.event.action == 'opened', code lanes on any same-repository event), which is preserved from the previous render rather than introduced here.
No stale approach-smart-2 / approach-3 / code-smart-2 references remain anywhere in the tree.

The body's note that pull_request_target reads the workflow from the base branch is correct, so this PR exercising the old roster is expected and not evidence of a bad render.

One observation, deliberately not filed as a comment: the file now carries roughly eight near-identical ~620-line job bodies, so per-lane edits scale linearly with roster size. Collapsing them into a matrix or reusable workflow is plausible in principle but constrained — the exact job name: strings are load-bearing for the observer's name matching and for the per-recipe OIDC binding — and in any case that design belongs in the upstream generator, not in a hand-edit of generated output here. Nothing in this PR should change on that account.

Approach review by Claude Code Opus (opus)

**Approach review:** The approach looks good. This is a mechanical re-render of two managed workflow files from a released generator (`@j4k/align` v1.110.3), replacing the retired 5-slot roster with the 8-slot Luna roster, bumping the toolchain pins to `@j4k/axrecipe@11.0.0` / `@j4k/axrun@12.0.0`, and moving the review-writer action to a new pinned commit. Regenerating rather than hand-patching is the right call for generated files, and the stated fix (slots that 400 against the axrecipe 11 exchange endpoint) matches what the diff actually changes. Checks on the rendered result: - The eight `generate-*` jobs, their `name:` values, their `SLOT`/`RECIPE` env pairs, the allowed-slot `Set` embedded in each context builder, and the `slots` array in `observe-review-writers` all agree on the same eight names — no half-renamed lane. - All eight `npm install` lines carry the new pins; no `axrecipe@10.0.0` / `axrun@6.0.0` remnants. - Normalizing each generator job by its own slot name shows the bodies are byte-identical apart from the intentional approach-vs-code trigger split (approach lanes gated on `github.event.action == 'opened'`, code lanes on any same-repository event), which is preserved from the previous render rather than introduced here. - No stale `approach-smart-2` / `approach-3` / `code-smart-2` references remain anywhere in the tree. The body's note that `pull_request_target` reads the workflow from the base branch is correct, so this PR exercising the old roster is expected and not evidence of a bad render. One observation, deliberately not filed as a comment: the file now carries roughly eight near-identical ~620-line job bodies, so per-lane edits scale linearly with roster size. Collapsing them into a matrix or reusable workflow is plausible in principle but constrained — the exact job `name:` strings are load-bearing for the observer's name matching and for the per-recipe OIDC binding — and in any case that design belongs in the upstream generator, not in a hand-edit of generated output here. Nothing in this PR should change on that account. _Approach review by Claude Code Opus (opus)_

forgejo-actions reviewed

2026-08-07 13:55:38 +00:00

forgejo-actions left a comment

Summary: No blocking defects. The re-render is internally consistent; 1 low and 1 informational note.

What I verified mechanically against the working tree (both files are @j4k/align output, so any fix belongs upstream in the renderer, not as a hand edit here):

Both workflows parse as valid YAML; pr-review.yml has 10 unique jobs (prepare + 8 generators + observer).
All 8 generator job bodies are byte-identical to the pre-existing forgejo-review-approach-smart-1 block apart from the slot string, so the new lanes inherit the same OIDC-teardown, private-registry, setpriv, and supervisor handling.
For each lane, the job key, name:, SLOT:, RECIPE:, and the observer's slot/generatorName pair agree exactly; the observer matches on full string equality, so forgejo-review-code-luna cannot collide with forgejo-review-code-luna-2.
The allow-list Set in the context builder is identical across all 8 copies and in the observer, and lists exactly the 8 rendered slots.
No stale approach-smart-2 / approach-3 / code-smart-2 / axrecipe@10.0.0 / axrun@6.0.0 references remain anywhere in the repo; the new pins appear 8 times, once per generator.
Lane gating is preserved: approach lanes stay opened-only, code lanes rerun on every same-repository update, and the observer's waitForGenerator returns early on a skipped generator, so the 3 new approach lanes do not hang the observer on synchronize.
observe-review-writers inherits the fork guard transitively via needs: prepare-review-tools, and its 95-minute timeout still covers the unchanged 60-minute generator wait plus the 30-minute publication window.

The forgejo-review-writer pin bump and the @j4k/axrecipe@11 / @j4k/axrun@12 bump are opaque here (network-pinned SHA and private registry); I took the PR body's audit claim at face value rather than verifying them.

Code review by Claude Code Opus (opus)

**Summary:** No blocking defects. The re-render is internally consistent; 1 low and 1 informational note. What I verified mechanically against the working tree (both files are `@j4k/align` output, so any fix belongs upstream in the renderer, not as a hand edit here): - Both workflows parse as valid YAML; `pr-review.yml` has 10 unique jobs (prepare + 8 generators + observer). - All 8 generator job bodies are byte-identical to the pre-existing `forgejo-review-approach-smart-1` block apart from the slot string, so the new lanes inherit the same OIDC-teardown, private-registry, setpriv, and supervisor handling. - For each lane, the job key, `name:`, `SLOT:`, `RECIPE:`, and the observer's `slot`/`generatorName` pair agree exactly; the observer matches on full string equality, so `forgejo-review-code-luna` cannot collide with `forgejo-review-code-luna-2`. - The allow-list `Set` in the context builder is identical across all 8 copies and in the observer, and lists exactly the 8 rendered slots. - No stale `approach-smart-2` / `approach-3` / `code-smart-2` / `axrecipe@10.0.0` / `axrun@6.0.0` references remain anywhere in the repo; the new pins appear 8 times, once per generator. - Lane gating is preserved: approach lanes stay `opened`-only, code lanes rerun on every same-repository update, and the observer's `waitForGenerator` returns early on a `skipped` generator, so the 3 new approach lanes do not hang the observer on `synchronize`. - `observe-review-writers` inherits the fork guard transitively via `needs: prepare-review-tools`, and its 95-minute timeout still covers the unchanged 60-minute generator wait plus the 30-minute publication window. The `forgejo-review-writer` pin bump and the `@j4k/axrecipe@11` / `@j4k/axrun@12` bump are opaque here (network-pinned SHA and private registry); I took the PR body's audit claim at face value rather than verifying them. _Code review by Claude Code Opus (opus)_

.forgejo/workflows/pr-review.yml

					
				@ -355,2 +355,3 @@

				            "forgejo-review-approach-luna-3",

				            "forgejo-review-code-smart-1",

				            "forgejo-review-code-smart-2",

				            "forgejo-review-code-luna",

ℹ️ Info: The code lanes render as forgejo-review-code-luna, -luna-2, -luna-3, while the approach lanes render as -luna-1, -luna-2, -luna-3. The unsuffixed first code lane is used consistently in all six places it appears (allow-list, job key, name:, SLOT:, RECIPE:, observer entry), so nothing is internally inconsistent — but RECIPE is sent verbatim to axrecipe forgejo-actions exchange --slot and axrecipe run <recipe>.

If the deployed axrecipe 11 roster actually names that recipe forgejo-review-code-luna-1, this lane fails with exactly the validation 400 the PR is fixing, and the asymmetry is the kind of thing that hides such a typo. Worth a one-time confirmation against the server-side roster before this lands; no change needed if forgejo-review-code-luna is the real recipe id.

ℹ️ **Info:** The code lanes render as `forgejo-review-code-luna`, `-luna-2`, `-luna-3`, while the approach lanes render as `-luna-1`, `-luna-2`, `-luna-3`. The unsuffixed first code lane is used consistently in all six places it appears (allow-list, job key, `name:`, `SLOT:`, `RECIPE:`, observer entry), so nothing is internally inconsistent — but `RECIPE` is sent verbatim to `axrecipe forgejo-actions exchange --slot` and `axrecipe run <recipe>`. If the deployed axrecipe 11 roster actually names that recipe `forgejo-review-code-luna-1`, this lane fails with exactly the validation 400 the PR is fixing, and the asymmetry is the kind of thing that hides such a typo. Worth a one-time confirmation against the server-side roster before this lands; no change needed if `forgejo-review-code-luna` is the real recipe id.

.forgejo/workflows/pr-review.yml

					
				@ -3290,3 +5170,2 @@

				            {

				              slot: "forgejo-review-code-smart-2",

				              generatorName: "forgejo-review-code-smart-2 generator",

				              slot: "forgejo-review-code-luna",

🟢 Low: The roster grows 5 → 8 slots, but the writer-side windows it feeds are unchanged, and pr-review-post.yml serializes every slot for one PR (concurrency.group: pr-review-post-<number>, cancel-in-progress: false, queue enabled) with timeout-minutes: 3 per run.

publish anchors both latestSafeDispatchDeadline (27 min) and publicationDeadline (30 min) at the moment its own generator finalizes. Generators start together and share a 30-minute cap, so simultaneous finalization is the normal case, not the pathological one: all 8 dispatches then land in one serialized queue. If runs approach their 3-minute budget, the 8th completes ~24 minutes after the first starts — inside the 30-minute window, but with ~6 minutes of headroom against runner queue latency, versus ~15 minutes of tail (and double the headroom) at 5 slots. The retry in publish appends a 9th run to the same queue. Overrunning surfaces as review writer did not finish inside the publication window and fails the observer even though every generator succeeded.

No action in this file (it is generated). Worth confirming upstream in @j4k/align that the 27/30-minute constants were re-derived for an 8-slot roster, or that the writer concurrency group fans out per slot (pr-review-post-<number>-<slot>) so the tail no longer scales with roster size.

🟢 **Low:** The roster grows 5 → 8 slots, but the writer-side windows it feeds are unchanged, and `pr-review-post.yml` serializes every slot for one PR (`concurrency.group: pr-review-post-<number>`, `cancel-in-progress: false`, queue enabled) with `timeout-minutes: 3` per run. `publish` anchors both `latestSafeDispatchDeadline` (27 min) and `publicationDeadline` (30 min) at the moment *its own* generator finalizes. Generators start together and share a 30-minute cap, so simultaneous finalization is the normal case, not the pathological one: all 8 dispatches then land in one serialized queue. If runs approach their 3-minute budget, the 8th completes ~24 minutes after the first starts — inside the 30-minute window, but with ~6 minutes of headroom against runner queue latency, versus ~15 minutes of tail (and double the headroom) at 5 slots. The retry in `publish` appends a 9th run to the same queue. Overrunning surfaces as `review writer did not finish inside the publication window` and fails the observer even though every generator succeeded. No action in this file (it is generated). Worth confirming upstream in `@j4k/align` that the 27/30-minute constants were re-derived for an 8-slot roster, or that the writer concurrency group fans out per slot (`pr-review-post-<number>-<slot>`) so the tail no longer scales with roster size.