shoc-pr-review-runner/templates/review-request.md

# Review request template

Fill in and use as the `review_notes` input when dispatching the workflow, or as
a checklist before dispatch.

- Review type: frontend | backend | paired
- Frontend PR: <number or URL, if in scope>
- Backend PR: <number or URL, if in scope>
- Ticket: <SH-### or URL>
- Context the reviewer should know: <stack position, paired-PR expectations,
  acceptance criteria emphasis, known limitations>
feat: SHOC PR review runner, phase 1 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. 2026-07-29 12:04:27 -04:00			`# Review request template`

			Fill in and use as the `review_notes` input when dispatching the workflow, or as
			`a checklist before dispatch.`

			`- Review type: frontend \| backend \| paired`
			`- Frontend PR: <number or URL, if in scope>`
			`- Backend PR: <number or URL, if in scope>`
			`- Ticket: <SH-### or URL>`
			`- Context the reviewer should know: <stack position, paired-PR expectations,`
			`acceptance criteria emphasis, known limitations>`