The first live run reported the reviewed PR's CI as "missing" while it was
actually green, and the model cited that as a reason to withhold approval.
Reading check-runs needs the App's checks:read permission, which the App did
not have, so the call 403'd and the fallback turned an authorization failure
into the factual claim "this PR has no CI". That is the exact failure this
runner exists to prevent, applied to a governance signal instead of a gate.
Distinguish the two: an unreadable signal is now recorded as "unknown", the
evidence report says unknown is not evidence of absent or failing CI, and the
skill tells the reviewer that a signal the runner could not read is not a
finding. Request checks:read at token mint so the signal is readable at all.
Also correct the App verification snippet in the README: listing an
installation's selected repositories needs the installation token, so the
documented /user/installations call does not work for an org admin.
Manually-dispatched GitHub Actions workflow that reviews SHOC pull requests in
a clean environment: exact-head checkout of shoc-frontend-new and shoc-backend,
clean build/test gates, a truthful evidence report, a single-shot Fireworks
review, deterministic output validation, and published artifacts. The runner
never writes to the product repositories or their pull requests.
The review checklists move here from the reviewers' local Cursor commands so
the instructions live outside both product repos.
Phase 1 does not provision a database, start either application, or run live
browser flows; the evidence report records those as NOT_RUN so a review cannot
claim them.
Security architecture: building a PR executes its author's code, so the
workflow is split. The gates job runs that code holding no Fireworks key and
revokes its App token first; the review job holds the key, executes no product
code, and re-checks out this repo fresh. Product checkouts live outside the
workspace, the App token is downscoped at mint time, gate results fail closed
on any duplicate key, changed files are read from git objects rather than the
filesystem, and the validator re-checks every claim against the gate table.
