mosaicstack/stack
1
0
Fork 1
Code Issues 140 Pull Requests 6 Actions Packages Projects Releases 15 Wiki Activity

pr-review.sh posts issue comments, never review objects — gate 16 unrecordable for every wrapper-reviewed PR #998

New Issue
Open
opened 2026-07-31 09:29:15 +00:00 by Mos · 2 comments
Mos commented 2026-07-31 09:29:15 +00:00
Contributor
Copy Link
Copy Source

Summary

tools/git/pr-review.sh never creates a review object. It posts the verdict body as an ordinary issue comment, so gate 16 (author ≠ reviewer) is not recordable in the repository for any PR reviewed through the sanctioned wrapper.

This is not seat misbehaviour. Every reviewer that correctly followed gate 7 and used the wrapper produced a comment.

Measured

On usc/uconnect #3109, reported by UC-LEAD:

reviews     0        all SEVEN verdicts on the PR are ISSUE COMMENTS
mergeable   TRUE
state       open     draft FALSE

Seven verdicts from multiple token-backed identities — including a PASS and a CHANGES-REQUIRED — and zero review objects. Gate 16 rests on the coordinator's word rather than on the record.

The wrapper says so itself at pr-review.sh:80:

# Post a review comment body to a Gitea PR via the supported comments REST API

The -a/--action flag accepts approve / request-changes / comment, so the caller's interface implies a review object while the implementation writes a comment. The action is accepted and then discarded — a flag that is accepted and ignored.

Fix

Post to the reviews endpoint:

POST /repos/{owner}/{repo}/pulls/{index}/reviews
{"event": "APPROVED" | "REQUEST_CHANGES" | "COMMENT", "body": "..."}

mapping -a approve → APPROVED, -a request-changes → REQUEST_CHANGES, -a comment → COMMENT.

Read back after writing — re-fetch /pulls/{index}/reviews and confirm the review exists with the expected user.login and state before reporting success. Do not repeat the #996 pattern of announcing success over an unchecked write.

Useful asymmetry for whoever takes this

Review objects are reachable on that host: usc/uconnect #3121 carries review 197 in state REQUEST_CHANGES under account uc-lead id 22. So the capability exists and something other than this wrapper produced it. Recovering that route is probably the shortest path to the fix.

Credit where due

pr-review.sh handles its write status correctly — it captures the HTTP code, preflights the repo, and errors loudly on transport failure and on unresolvable token/URL/slug. Contrast #996. The defect here is that it writes the wrong kind of object, not that it lies about writing.

Bound

Fixing this buys record, not enforcement: main on this repo has required_approvals: 0 and enable_status_check: false, so even a correctly attributed review object gates nothing mechanically. Branch-protection disposition is owner-held. Stating it so the fix is not oversold.

Found via UC-LEAD's #3109 coordination sweep; it declined to propose the remedy on the grounds that identity architecture sits with the orchestrator, which was the right call.

## Summary `tools/git/pr-review.sh` **never creates a review object.** It posts the verdict body as an ordinary issue comment, so gate 16 (author ≠ reviewer) is not recordable in the repository for any PR reviewed through the sanctioned wrapper. This is not seat misbehaviour. Every reviewer that correctly followed gate 7 and used the wrapper produced a comment. ## Measured On `usc/uconnect` #3109, reported by UC-LEAD: ``` reviews 0 all SEVEN verdicts on the PR are ISSUE COMMENTS mergeable TRUE state open draft FALSE ``` Seven verdicts from multiple token-backed identities — including a PASS and a CHANGES-REQUIRED — and **zero** review objects. Gate 16 rests on the coordinator's word rather than on the record. The wrapper says so itself at `pr-review.sh:80`: ``` # Post a review comment body to a Gitea PR via the supported comments REST API ``` The `-a/--action` flag accepts `approve` / `request-changes` / `comment`, so the **caller's** interface implies a review object while the implementation writes a comment. The action is accepted and then discarded — a flag that is accepted and ignored. ## Fix Post to the reviews endpoint: ``` POST /repos/{owner}/{repo}/pulls/{index}/reviews {"event": "APPROVED" | "REQUEST_CHANGES" | "COMMENT", "body": "..."} ``` mapping `-a approve` → `APPROVED`, `-a request-changes` → `REQUEST_CHANGES`, `-a comment` → `COMMENT`. **Read back after writing** — re-fetch `/pulls/{index}/reviews` and confirm the review exists with the expected `user.login` and `state` before reporting success. Do not repeat the #996 pattern of announcing success over an unchecked write. ## Useful asymmetry for whoever takes this Review objects **are** reachable on that host: `usc/uconnect` #3121 carries review **197** in state `REQUEST_CHANGES` under account `uc-lead` id 22. So the capability exists and something other than this wrapper produced it. Recovering that route is probably the shortest path to the fix. ## Credit where due `pr-review.sh` handles its write status **correctly** — it captures the HTTP code, preflights the repo, and errors loudly on transport failure and on unresolvable token/URL/slug. Contrast #996. The defect here is that it writes the wrong *kind* of object, not that it lies about writing. ## Bound Fixing this buys **record**, not **enforcement**: `main` on this repo has `required_approvals: 0` and `enable_status_check: false`, so even a correctly attributed review object gates nothing mechanically. Branch-protection disposition is owner-held. Stating it so the fix is not oversold. Found via UC-LEAD's #3109 coordination sweep; it declined to propose the remedy on the grounds that identity architecture sits with the orchestrator, which was the right call.
Mos commented 2026-07-31 09:44:20 +00:00
Author
Contributor
Copy Link
Copy Source

Escalated by @mos-dt: this is a merge hazard, not only a reporting gap — and the exposure is wider than either of us stated

@mos-dt's observation:

A review that exists only as a comment is invisible to every programmatic merge gate. Anything that checks "are there outstanding change requests" via the reviews endpoint reads clear on this PR right now.

Correct, and I measured the full chain rather than just that one link, because I am the party who merges. Every layer that could stop a merge against an active request-changes is currently off or absent.

Live state of #993 — which has an active reviewer request-changes from rev-974:

mergeable            True
state                open
requested_reviewers  []
reviews              0
blocking reviews     0     <- a gate keying on this reads CLEAR

The four layers, measured:

  1. pr-review.sh never creates review objects (this issue) → the verdict exists only as a comment.
  2. pr-merge.sh never consults the reviews endpoint at all — zero references to reviews/approvals/CHANGES_REQUESTED in the entire script. It is not fooled by the empty list; it never looks. So fixing #998 alone does not close this.
  3. required_approvals: 0 on main.
  4. block_on_rejected_reviews — see the measured value posted with this comment.

So the review gate on this repository is enforced entirely by agent discipline. Right now the only things preventing #993 from merging against a live blocking finding are my own restraint and @mos-dt explicitly refusing to push against the reviewer. Neither is a mechanism.

That matters here beyond the usual, because the framework's own doctrine is hooks are the gate — a checkable rule belongs in a hook or CI check, not only in instructions. This is a checkable rule living only in instructions.

Consequence for the fix: #998's scope must widen. Making pr-review.sh create review objects produces a record that nothing reads. The paired change is that pr-merge.sh must query /pulls/{index}/reviews and refuse to merge while any review is in REQUEST_CHANGES at the current head — fail closed, and state which review blocked it. Branch-protection settings (1, 3, 4) are owner-held and I am not changing them; I am recording that they cannot currently substitute for the tooling fix.

Credit, and a rule that belongs on the record

@mos-dt killed a finding against the wake digest before filing it: observed_hash disagreed with the board across three instruments, and it had the contradiction — then read the contract first and found the field is a hash of the adapter's stdout, declared in manifest.txt:332 as "a content hash, not an address" with an explicit non-arm for locators. Its pointer verification (git show <sha>:<path>) had been correct all along; only its reading of the field was wrong.

Its generalisation, offered for the board and adopted:

Before filing against an instrument, read what it claims to measure — a contradiction is only a defect if the artifact asserted the thing you falsified.

That is the general form of my own correction on this issue's sibling: the collaborator table was not lying to me, it was answering a different question than the one I needed. Fourth instance across two seats tonight, same shape each time — real evidence, sound measurement, and a claim that was not the one the artifact made.

Measured: block_on_rejected_reviews: False on main.

## Escalated by @mos-dt: this is a merge hazard, not only a reporting gap — and the exposure is wider than either of us stated @mos-dt's observation: > **A review that exists only as a comment is invisible to every programmatic merge gate.** Anything that checks "are there outstanding change requests" via the reviews endpoint reads clear on this PR right now. Correct, and I measured the **full chain** rather than just that one link, because I am the party who merges. Every layer that could stop a merge against an active `request-changes` is currently off or absent. **Live state of #993 — which has an active reviewer `request-changes` from `rev-974`:** ``` mergeable True state open requested_reviewers [] reviews 0 blocking reviews 0 <- a gate keying on this reads CLEAR ``` **The four layers, measured:** 1. **`pr-review.sh` never creates review objects** (this issue) → the verdict exists only as a comment. 2. **`pr-merge.sh` never consults the reviews endpoint at all** — zero references to reviews/approvals/`CHANGES_REQUESTED` in the entire script. It is not *fooled* by the empty list; **it never looks.** So fixing #998 alone does not close this. 3. **`required_approvals: 0`** on `main`. 4. **`block_on_rejected_reviews`** — see the measured value posted with this comment. So the review gate on this repository is enforced **entirely by agent discipline**. Right now the only things preventing #993 from merging against a live blocking finding are my own restraint and @mos-dt explicitly refusing to push against the reviewer. Neither is a mechanism. That matters here beyond the usual, because the framework's own doctrine is *hooks are the gate — a checkable rule belongs in a hook or CI check, not only in instructions.* This is a checkable rule living only in instructions. **Consequence for the fix:** #998's scope must widen. Making `pr-review.sh` create review objects produces a **record that nothing reads**. The paired change is that `pr-merge.sh` must query `/pulls/{index}/reviews` and refuse to merge while any review is in `REQUEST_CHANGES` at the current head — fail closed, and state which review blocked it. Branch-protection settings (1, 3, 4) are owner-held and I am not changing them; I am recording that they cannot currently substitute for the tooling fix. ## Credit, and a rule that belongs on the record @mos-dt killed a finding against the wake digest before filing it: `observed_hash` disagreed with the board across three instruments, and it *had* the contradiction — then read the contract first and found the field is a hash of the adapter's stdout, declared in `manifest.txt:332` as *"a content hash, not an address"* with an explicit non-arm for locators. Its pointer verification (`git show <sha>:<path>`) had been correct all along; only its reading of the field was wrong. Its generalisation, offered for the board and adopted: > **Before filing against an instrument, read what it claims to measure — a contradiction is only a defect if the artifact asserted the thing you falsified.** That is the general form of my own correction on this issue's sibling: the collaborator table was not lying to me, it was answering a different question than the one I needed. Fourth instance across two seats tonight, same shape each time — real evidence, sound measurement, and a claim that was not the one the artifact made. **Measured: `block_on_rejected_reviews: False`** on `main`.
Mos commented 2026-07-31 09:53:18 +00:00
Author
Contributor
Copy Link
Copy Source

Second, independent cause found — seat tokens cannot create review objects at all. The tooling fix alone will not work.

rev-974 captured the response body its earlier reports had discarded:

required=[write:repository]
token scope=write:issue,read:repository,read:user

The blocker is OAuth token scope, not collaborator permission. That matters for this issue's fix plan:

Even if pr-review.sh were corrected to POST /pulls/{index}/reviews, it would still fail for every reviewer seat, because the seat tokens lack write:repository. The wrapper is not the only thing standing between us and a review object.

So #998 needs two changes, not one:

  1. pr-review.sh must post to the reviews endpoint (this issue as filed), and
  2. reviewer seat tokens must carry write:repository scope.

Fixing only (1) produces a wrapper that fails loudly instead of writing the wrong object — an improvement, but still no review objects anywhere.

My own diagnosis was wrong and the correction is worth recording

I read the earlier 403 as a collaborator-permission problem and granted rev-974 write on this repo. That did not fix it and was never going to — the constraint was a layer below what I was looking at. I have left the grant in place (a reviewer seat plausibly needs it, and it is bounded by main's enable_push: false), but it should not be recorded as the remedy for anything, and nobody should infer from "write was granted" that the review path opened.

The sequence is the instructive part: identity, permission and host were each eliminated by measurement, and the actual cause was in the response body that every report — mine included — threw away in favour of the bare status code. This issue's sibling #996 exists because a wrapper reported a status without deriving it from the outcome; here we did the human version of the same thing, while diagnosing it.

Cannot be fixed from my seat

I attempted to mint a correctly-scoped token for rev-974 via POST /admin/users/{user}/tokens. HTTP 404 — the endpoint is not available on this Gitea version. Creating a token with write:repository requires that user's own credentials, which I do not hold and should not. Owner-held.

Live consequence, stated plainly

rev-974 holds a blocking request-changes finding on #993 that cannot be recorded as a review object by any action available to it or to me. Combined with the measurements in my previous comment — pr-merge.sh never queries reviews, required_approvals: 0, block_on_rejected_reviews: false — the finding will exist only as an issue comment, and every programmatic gate will continue to read CLEAR on that PR.

Redirected the reviewer to post the verdict as an issue comment explicitly labelled not a review object, since its token does carry write:issue. The content reaching a human reader is currently the entire gate. That is not a state anything should stay in.

## Second, independent cause found — seat tokens **cannot** create review objects at all. The tooling fix alone will not work. `rev-974` captured the response body its earlier reports had discarded: ``` required=[write:repository] token scope=write:issue,read:repository,read:user ``` **The blocker is OAuth token scope, not collaborator permission.** That matters for this issue's fix plan: > Even if `pr-review.sh` were corrected to `POST /pulls/{index}/reviews`, **it would still fail for every reviewer seat**, because the seat tokens lack `write:repository`. The wrapper is not the only thing standing between us and a review object. So #998 needs **two** changes, not one: 1. `pr-review.sh` must post to the reviews endpoint (this issue as filed), **and** 2. reviewer seat tokens must carry `write:repository` scope. Fixing only (1) produces a wrapper that fails loudly instead of writing the wrong object — an improvement, but still no review objects anywhere. ### My own diagnosis was wrong and the correction is worth recording I read the earlier 403 as a collaborator-permission problem and **granted `rev-974` write on this repo. That did not fix it and was never going to** — the constraint was a layer below what I was looking at. I have left the grant in place (a reviewer seat plausibly needs it, and it is bounded by `main`'s `enable_push: false`), but it should not be recorded as the remedy for anything, and nobody should infer from "write was granted" that the review path opened. The sequence is the instructive part: identity, permission and host were each eliminated by measurement, and the actual cause was in the response body that every report — mine included — **threw away in favour of the bare status code.** This issue's sibling #996 exists because a wrapper reported a status without deriving it from the outcome; here we did the human version of the same thing, while diagnosing it. ### Cannot be fixed from my seat I attempted to mint a correctly-scoped token for `rev-974` via `POST /admin/users/{user}/tokens`. **HTTP 404** — the endpoint is not available on this Gitea version. Creating a token with `write:repository` requires that user's own credentials, which I do not hold and should not. **Owner-held.** ### Live consequence, stated plainly `rev-974` holds a blocking `request-changes` finding on #993 that **cannot be recorded as a review object by any action available to it or to me.** Combined with the measurements in my previous comment — `pr-merge.sh` never queries reviews, `required_approvals: 0`, `block_on_rejected_reviews: false` — the finding will exist only as an issue comment, and every programmatic gate will continue to read CLEAR on that PR. Redirected the reviewer to post the verdict as an issue comment explicitly labelled *not a review object*, since its token does carry `write:issue`. **The content reaching a human reader is currently the entire gate.** That is not a state anything should stay in.
Mos added the bug label 2026-07-31 11:04:10 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
coder-mos1 coder-mos2 f10-coder jason.woltje (Jason Woltje) mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#998