chore: update review wrapper pin #50

Merged

jercik merged 1 commit from chore/review-wrapper-65f9120 into main

2026-10-05 12:47:03 +00:00

jercik commented

2026-10-05 12:39:50 +00:00

Owner

Moves the review workflow's wrapper pin from a79cfbe to 65f9120.

With the new wrapper, a push that leaves the pull request's diff unchanged, such as a rebase onto a newer main, reuses the review that diff already has. The run finishes in seconds and reposts the earlier findings on the new head. A push that changes the diff still gets a new review, and a manual dispatch still runs the lenses again.

The change is the one pinned line. This PR's own review ran the old wrapper, because the workflow runs from the base branch.

Wrapper changes between the pins: a79cfbe103...65f9120042

🤖 Generated with Claude Code

Moves the review workflow's wrapper pin from `a79cfbe` to `65f9120`. With the new wrapper, a push that leaves the pull request's diff unchanged, such as a rebase onto a newer `main`, reuses the review that diff already has. The run finishes in seconds and reposts the earlier findings on the new head. A push that changes the diff still gets a new review, and a manual dispatch still runs the lenses again. The change is the one pinned line. This PR's own review ran the old wrapper, because the workflow runs from the base branch. Wrapper changes between the pins: https://code.j4k.dev/j4k-oss/review-wrapper/compare/a79cfbe103b223d9d626e0fc3a033ba9639a71e2...65f91200423c1ab20699b156c8f5fcac67324c59 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jercik added 1 commit

2026-10-05 12:39:50 +00:00

chore: update review wrapper pin

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

Details

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

Details

Review / Review (pull_request_target) Successful in 5m21s

Details

598f162b95

Moves the review workflow's wrapper pin from a79cfbe to 65f9120, so a push
that leaves the pull request's diff unchanged reuses the review that diff
already has.

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

forgejo-actions commented

2026-10-05 12:45:11 +00:00

Review 01M4617TP7Z73R6QPBRZ6CJ06C — head 598f162b958fc8dc9aa6c45a009c57b8cfb1b4ce

Review — j4k-oss/review-wrapper @ `53f33d0ed0`

Scope: diff against base tree 9533ee7a6f0b
Status: dispatched — coverage complete (5/5 slots terminal)
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-v4",
  "tally": "tally-v1",
  "triage_settle": "triage-settle-v2"
}

Findings (1)

medium — The recursion guard restates the wrapper’s forge-write set

claim: 01M461EC37YVYREW8H1GJX9XRZ
anchor: .forgejo/workflows/review.yml (snippet)

# Recursion guard: every wrapper write is an issue/review comment or a
# conversation resolution — none fires the pull_request_target family. Any
# trigger widening must re-prove this.

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M461FKNQEDJYNMNXTDNPFHVY · valid: The exact-match grounded comment presents issue comments, review comments, and conversation resolutions as every wrapper write. The reviewer supplies the defining source path, src/forge/client.ts, and the six createForgeClient methods, with a concrete comparison showing that the source and copied categories currently agree. This satisfies the restated-sets standard: the exhaustive prose inventory must be maintained separately when the implementation changes. It is not an adjacent-code description or another applicable exception. The proposed source pointer preserves both the current pull_request_target recursion guarantee and the obligation to re-prove it when widening triggers, so it loses no necessary constraint. Medium is appropriate because no current mismatch is reported. I reassessed the earlier matching claim; its rationale supplies no refutation of the current allegation.
disposition: none

The workflow comment copies the wrapper’s complete forge-write set into a second repository’s template. It currently agrees with the implementation, but adding a write operation requires finding and updating this separate inventory; otherwise maintainers assessing recursion can silently rely on an incomplete summary. The writing standard’s “One Idea, One Place” guidance and the restated-sets rule call for a pointer to the authoritative implementation.

createForgeClient in src/forge/client.ts defines createIssueComment and editIssueComment (issue comments), createInlineReview and addReviewComment (review comments), and resolveConversation and unresolveConversation (conversation resolution state). The copy covers issue comments, review comments, and conversation resolution, and “every wrapper write” presents those categories as exhaustive. At that category level the source and copy agree: neither contains a category absent from the other.

Correct templates/workflows/review-forgejo.yml.hbs in j4k-align, named by the workflow’s rendering header, and regenerate this file. Replace the anchored comment with: “Recursion guard: the forge write operations in createForgeClient (src/forge/client.ts) do not fire the pull_request_target family. Re-prove this before widening the triggers.” This preserves the current recursion guarantee and the trigger-change obligation without maintaining a duplicate inventory.

I read the complete workflow and traced the actual forge writes through src/main.ts, the wrapper orchestrator, and the summary, inline, and disposition reconcilers to createForgeClient. This is a documentation-maintenance finding established by source trace, not a reproduced recursion failure. The upstream template and Forgejo implementation are absent, so I could not verify their contents or independently confirm event emission. Evidence that this passage itself defines the allowed write set would refute the duplication finding; the reviewed code instead obtains its write behavior from the client implementation.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (0)
duplicate-of (0)
unadjudicated (0)

Coverage

Coverage pass: 01M4617TR7745G6BKT87V9RARX
Accounting: complete
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
test-trimming	whole	default	no-claims	1	no
restated-sets	whole	default	no-claims	1	no
project-docs	whole	default	no-claims	1	no

**Review** `01M4617TP7Z73R6QPBRZ6CJ06C` — head `598f162b958fc8dc9aa6c45a009c57b8cfb1b4ce` # Review — j4k-oss/review-wrapper @ 53f33d0ed000 Scope: diff against base tree `9533ee7a6f0b` Status: dispatched — coverage complete (5/5 slots terminal) 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-v4", "tally": "tally-v1", "triage_settle": "triage-settle-v2" } ``` ## Findings (1) ### medium — The recursion guard restates the wrapper’s forge-write set - claim: `01M461EC37YVYREW8H1GJX9XRZ` - anchor: `.forgejo/workflows/review.yml` (snippet) ``` # Recursion guard: every wrapper write is an issue/review comment or a # conversation resolution — none fires the pull_request_target family. Any # trigger widening must re-prove this. ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M461FKNQEDJYNMNXTDNPFHVY` · valid: The exact-match grounded comment presents issue comments, review comments, and conversation resolutions as every wrapper write. The reviewer supplies the defining source path, src/forge/client.ts, and the six createForgeClient methods, with a concrete comparison showing that the source and copied categories currently agree. This satisfies the restated-sets standard: the exhaustive prose inventory must be maintained separately when the implementation changes. It is not an adjacent-code description or another applicable exception. The proposed source pointer preserves both the current pull_request_target recursion guarantee and the obligation to re-prove it when widening triggers, so it loses no necessary constraint. Medium is appropriate because no current mismatch is reported. I reassessed the earlier matching claim; its rationale supplies no refutation of the current allegation. - disposition: none > The workflow comment copies the wrapper’s complete forge-write set into a second repository’s template. It currently agrees with the implementation, but adding a write operation requires finding and updating this separate inventory; otherwise maintainers assessing recursion can silently rely on an incomplete summary. The writing standard’s “One Idea, One Place” guidance and the restated-sets rule call for a pointer to the authoritative implementation. > > `createForgeClient` in `src/forge/client.ts` defines `createIssueComment` and `editIssueComment` (issue comments), `createInlineReview` and `addReviewComment` (review comments), and `resolveConversation` and `unresolveConversation` (conversation resolution state). The copy covers issue comments, review comments, and conversation resolution, and “every wrapper write” presents those categories as exhaustive. At that category level the source and copy agree: neither contains a category absent from the other. > > Correct `templates/workflows/review-forgejo.yml.hbs` in j4k-align, named by the workflow’s rendering header, and regenerate this file. Replace the anchored comment with: “Recursion guard: the forge write operations in `createForgeClient` (`src/forge/client.ts`) do not fire the pull_request_target family. Re-prove this before widening the triggers.” This preserves the current recursion guarantee and the trigger-change obligation without maintaining a duplicate inventory. > > I read the complete workflow and traced the actual forge writes through `src/main.ts`, the wrapper orchestrator, and the summary, inline, and disposition reconcilers to `createForgeClient`. This is a documentation-maintenance finding established by source trace, not a reproduced recursion failure. The upstream template and Forgejo implementation are absent, so I could not verify their contents or independently confirm event emission. Evidence that this passage itself defines the allowed write set would refute the duplication finding; the reviewed code instead obtains its write behavior from the client implementation. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (0) ## Coverage Coverage pass: 01M4617TR7745G6BKT87V9RARX Accounting: complete 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 | | test-trimming | whole | default | no-claims | 1 | no | | restated-sets | whole | default | no-claims | 1 | no | | project-docs | whole | default | no-claims | 1 | no |

🚀 1

jercik merged commit 9f272a522e into main

2026-10-05 12:47:03 +00:00

jercik deleted branch chore/review-wrapper-65f9120

2026-10-05 12:47:03 +00:00

jercik referenced this pull request from a commit

2026-10-05 12:47:04 +00:00

chore: update review wrapper pin (#50)