fix: re-render the managed review workflows onto the Luna roster #50

jercik · 2026-08-07T13:47:57Z

jercik commented

2026-08-07 13:47:57 +00:00

This repo was still on the retired pre-Luna five-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 reviews on every PR here have been partially failing. Re-rendering from released @j4k/align v1.110.3 deploys the current eight-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, so the change only takes effect for PRs opened after it merges. That absence is expected and does not block merging.

This repo was still on the retired pre-Luna five-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 reviews on every PR here have been partially failing. Re-rendering from released `@j4k/align` v1.110.3 deploys the current eight-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, so the change only takes effect for PRs opened after it merges. That absence is expected and does not block merging.

jercik added 1 commit

2026-08-07 13:47:57 +00:00

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

Node tests / node:test (pull_request) Successful in 10s

Details

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

Details

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

Details

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

Details

PR Review / forgejo-review-approach-smart-2 generator (pull_request_target) Failing after 3m50s

Details

PR Review / forgejo-review-code-smart-2 generator (pull_request_target) Failing after 3m50s

Details

PR Review / forgejo-review-approach-smart-1 generator (pull_request_target) Successful in 4m18s

Details

PR Review / forgejo-review-code-smart-1 generator (pull_request_target) Successful in 6m11s

Details

PR Review / Dispatch and observe exact review writers (pull_request_target) Failing after 6m30s

Details

35bb164daf

forgejo-actions reviewed

2026-08-07 13:54:26 +00:00

forgejo-actions left a comment

Approach review: Sound. Re-rendering the managed workflows from released @j4k/align v1.110.3 is the right move — hand-patching the three failing slot names in a generated artifact would be reverted by the next render, and the alternative of pinning the repo to the retired five-slot roster just keeps the 400s.

I verified the render is internally consistent against the working tree rather than trusting the diff alone:

All 8 generator jobs exist and each one's job key, name:, SLOT:, and RECIPE: agree (approach-smart-1, approach-luna-1/2/3, code-smart-1, code-luna, code-luna-2, code-luna-3). The unsuffixed code-luna is consistent everywhere it appears, so it reads as an intentional roster name, not a dropped -1.
The embedded slots allowlist in the context builder is identical in all 8 jobs and matches the roster; the observe-review-writers slot/generatorName table matches it too, so no generator can finalize into a slot the observer will not watch.
The toolchain pin is @j4k/axrecipe@11.0.0 @j4k/axrun@12.0.0 in all 8 install sites with no 10.0.0/6.0.0 left in the file.
pr-review-post.yml only bumps the review-writer pin; it passes slot straight through and carries no roster of its own, so nothing there needed updating.

The PR body's note that this schedules zero pr-review jobs against itself is correct — pull_request_target resolves the workflow from the base branch — so the absent checks here are expected and not evidence of a broken render.

One non-blocking observation, and it belongs upstream in @j4k/align's renderer rather than in this PR: normalizing the slot string out, the 8 generator jobs are byte-identical bodies of ~620 lines each, which is why adding 3 slots grew this file by ~1,900 lines to 5,358. A strategy.matrix over the slot list with name: ${{ matrix.slot }} generator would express the same roster once, and the observer's exact-name matching would still work since each matrix leg gets its own named check run. I am not suggesting that change here — this file is generated, so a hand-edit would be lost at the next render, and the duplication is inherited rather than introduced by this PR.

No material alternative for the change as scoped.

Approach review by Claude Code Opus (opus)

**Approach review:** Sound. Re-rendering the managed workflows from released `@j4k/align` v1.110.3 is the right move — hand-patching the three failing slot names in a generated artifact would be reverted by the next render, and the alternative of pinning the repo to the retired five-slot roster just keeps the 400s. I verified the render is internally consistent against the working tree rather than trusting the diff alone: - All 8 generator jobs exist and each one's job key, `name:`, `SLOT:`, and `RECIPE:` agree (`approach-smart-1`, `approach-luna-1/2/3`, `code-smart-1`, `code-luna`, `code-luna-2`, `code-luna-3`). The unsuffixed `code-luna` is consistent everywhere it appears, so it reads as an intentional roster name, not a dropped `-1`. - The embedded `slots` allowlist in the context builder is identical in all 8 jobs and matches the roster; the `observe-review-writers` slot/`generatorName` table matches it too, so no generator can finalize into a slot the observer will not watch. - The toolchain pin is `@j4k/axrecipe@11.0.0 @j4k/axrun@12.0.0` in all 8 install sites with no `10.0.0`/`6.0.0` left in the file. - `pr-review-post.yml` only bumps the review-writer pin; it passes `slot` straight through and carries no roster of its own, so nothing there needed updating. The PR body's note that this schedules zero `pr-review` jobs against itself is correct — `pull_request_target` resolves the workflow from the base branch — so the absent checks here are expected and not evidence of a broken render. One non-blocking observation, and it belongs upstream in `@j4k/align`'s renderer rather than in this PR: normalizing the slot string out, the 8 generator jobs are byte-identical bodies of ~620 lines each, which is why adding 3 slots grew this file by ~1,900 lines to 5,358. A `strategy.matrix` over the slot list with `name: ${{ matrix.slot }} generator` would express the same roster once, and the observer's exact-name matching would still work since each matrix leg gets its own named check run. I am not suggesting that change here — this file is generated, so a hand-edit would be lost at the next render, and the duplication is inherited rather than introduced by this PR. No material alternative for the change as scoped. _Approach review by Claude Code Opus (opus)_

forgejo-actions reviewed

2026-08-07 13:56:18 +00:00

forgejo-actions left a comment

Summary: No actionable defects found; 1 informational note.

This is a mechanical re-render of the two managed review workflows. I verified the render is internally consistent and that the new writer pin actually supports the new roster:

Roster consistency. All eight slots (approach-smart-1, approach-luna-1/2/3, code-smart-1, code-luna, code-luna-2, code-luna-3) agree across every place they appear: the eight generate-* job ids, each job's name:, each job's SLOT/RECIPE env pair, the slots allowlist embedded in all eight context-builder scripts, and the coordinator's slots dispatch table in observe-review-writers. No stale approach-smart-2, approach-3, or code-smart-2 reference survives anywhere in the repository.
Generator bodies. Diffing each generator job against the first, normalized on its slot name, yields zero drift apart from the intended lane difference: code lanes keep the broader if: (every same-repository update) while approach lanes keep the github.event.action == 'opened' gate. Nothing was hand-edited into the four new blocks.
Toolchain pins. @j4k/axrecipe@11.0.0 @j4k/axrun@12.0.0 is applied uniformly in all eight generators (eight occurrences, one per job); the prepare-review-tools artifact build is untouched. I could not verify those versions exist or that their CLI surfaces are unchanged — the @j4k registry returns 401 unauthenticated — so the unchanged axrecipe forgejo-actions exchange and axrecipe run flag sets rest on the audit asserted in the PR description.
Writer pin. forgejo-review-writer@2e31dcf54ddcf737be53712c5d60108dd65fd5dd resolves, is the current head of that repository's main, and its commit is "feat: accept expanded Luna review slots". Its action.yml declares exactly the nine inputs pr-review-post.yml passes, and its REVIEW_SLOTS allowlist matches this roster byte-for-byte — including the asymmetric forgejo-review-code-luna with no -1 suffix, which is therefore intentional rather than a render slip.
Both files parse as YAML, and the workflow still declares ten jobs as expected.

The PR description's claim that this schedules zero pr-review jobs against itself is consistent with the workflow triggering on pull_request_target.

Code review by Claude Code Opus (opus)

**Summary:** No actionable defects found; 1 informational note. This is a mechanical re-render of the two managed review workflows. I verified the render is internally consistent and that the new writer pin actually supports the new roster: - **Roster consistency.** All eight slots (`approach-smart-1`, `approach-luna-1/2/3`, `code-smart-1`, `code-luna`, `code-luna-2`, `code-luna-3`) agree across every place they appear: the eight `generate-*` job ids, each job's `name:`, each job's `SLOT`/`RECIPE` env pair, the `slots` allowlist embedded in all eight context-builder scripts, and the coordinator's `slots` dispatch table in `observe-review-writers`. No stale `approach-smart-2`, `approach-3`, or `code-smart-2` reference survives anywhere in the repository. - **Generator bodies.** Diffing each generator job against the first, normalized on its slot name, yields zero drift apart from the intended lane difference: code lanes keep the broader `if:` (every same-repository update) while approach lanes keep the `github.event.action == 'opened'` gate. Nothing was hand-edited into the four new blocks. - **Toolchain pins.** `@j4k/axrecipe@11.0.0 @j4k/axrun@12.0.0` is applied uniformly in all eight generators (eight occurrences, one per job); the `prepare-review-tools` artifact build is untouched. I could not verify those versions exist or that their CLI surfaces are unchanged — the `@j4k` registry returns 401 unauthenticated — so the unchanged `axrecipe forgejo-actions exchange` and `axrecipe run` flag sets rest on the audit asserted in the PR description. - **Writer pin.** `forgejo-review-writer@2e31dcf54ddcf737be53712c5d60108dd65fd5dd` resolves, is the current head of that repository's `main`, and its commit is "feat: accept expanded Luna review slots". Its `action.yml` declares exactly the nine inputs `pr-review-post.yml` passes, and its `REVIEW_SLOTS` allowlist matches this roster byte-for-byte — including the asymmetric `forgejo-review-code-luna` with no `-1` suffix, which is therefore intentional rather than a render slip. - Both files parse as YAML, and the workflow still declares ten jobs as expected. The PR description's claim that this schedules zero `pr-review` jobs against itself is consistent with the workflow triggering on `pull_request_target`. _Code review by Claude Code Opus (opus)_

.forgejo/workflows/pr-review.yml

					
				@ -3293,0 +5176,4 @@

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

				            },

				            {

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

ℹ️ Info: Growing the roster from five slots to eight tightens the finalized-writer publication margin, and nothing else in this change compensates.

pr-review-post.yml serializes every writer for a PR through concurrency: pr-review-post-${number} with cancel-in-progress: false. Dispatch itself is not serialized — publish fires all eight workflow_dispatch calls concurrently — but waitForRun then holds each slot to publicationDeadline = generator finalization + 30 minutes while the queue drains one post-review job at a time. Because the four code lanes start together and finish at broadly similar times, their 30-minute windows overlap heavily, so the queue must retire roughly eight runs inside one window rather than five: about 3.75 minutes per run of budget, down from about 6. Each run carries a 3-minute job timeout plus runner queue time that the timeout explicitly excludes (see the comment at pr-review-post.yml:45-48).

That still fits if writers land near their typical cold-start-plus-post duration, and the writer independently rejects expired work, so this is not a defect in the render — the failure mode is a coordinator review writer did not finish inside the publication window on the tail slot, not a bad review. Worth watching on the first few post-merge runs; if it bites, the fix belongs upstream in the @j4k/align template (a wider publication window or a partitioned concurrency group), not in this repository.

ℹ️ **Info:** Growing the roster from five slots to eight tightens the finalized-writer publication margin, and nothing else in this change compensates. `pr-review-post.yml` serializes every writer for a PR through `concurrency: pr-review-post-${number}` with `cancel-in-progress: false`. Dispatch itself is not serialized — `publish` fires all eight `workflow_dispatch` calls concurrently — but `waitForRun` then holds each slot to `publicationDeadline = generator finalization + 30 minutes` while the queue drains one `post-review` job at a time. Because the four code lanes start together and finish at broadly similar times, their 30-minute windows overlap heavily, so the queue must retire roughly eight runs inside one window rather than five: about 3.75 minutes per run of budget, down from about 6. Each run carries a 3-minute job timeout plus runner queue time that the timeout explicitly excludes (see the comment at `pr-review-post.yml:45-48`). That still fits if writers land near their typical cold-start-plus-post duration, and the writer independently rejects expired work, so this is not a defect in the render — the failure mode is a coordinator `review writer did not finish inside the publication window` on the tail slot, not a bad review. Worth watching on the first few post-merge runs; if it bites, the fix belongs upstream in the `@j4k/align` template (a wider publication window or a partitioned concurrency group), not in this repository.