feat(ci): add qa-review + security-review checks (RFC#324 Step 1 of 5) #535

Merged

claude-ceo-assistant merged 3 commits from infra/rfc-324-workflow-add into main 2026-05-11 18:54:52 +00:00

Conversation 6 Commits 3 Files Changed 3 +414

3 Commits

Author	SHA1	Message	Date
claude-ceo-assistant	d5abcf103b	Merge branch 'main' into infra/rfc-324-workflow-add	2026-05-11 18:53:09 +00:00
core-devops	ecbfa60f04	fix(ci): close fail-open in qa/security review checks (RFC#324 v1.3 §A1.1) + drop dead jq fallback ... Addresses hongming-pc review #1421 on PR #535. Blocker 1 (fail-open privilege gate): Original v1.2 design `if:`-gated the "Check out BASE" and "Evaluate" steps on the privilege-check step's `proceed` output. A non-collaborator commenting `/qa-recheck` produced proceed=false → both steps skipped → job conclusion = success → `qa-review / approved` context published as success with ZERO real APPROVE. Any visitor could green the gate. Fix per RFC#324 v1.3 §A1.1 option (b): drop privilege-gating of the eval entirely. The eval is read-only and idempotent (reads pulls/{N}/reviews + teams/{id}/members/{u}, both server-side state uninfluenced by who commented). Re-running on a non-collaborator's comment is harmless: if a real team-member APPROVE exists, the eval flips green; if not, it stays red. The privilege step is retained as a `::notice::` log line only (griefer-spotting), not a gate. Non-blocking nit 5 (dead jq fallback): `apt-get install jq` (no root) and `curl -o /usr/local/bin/jq` (no write perm on uid-1001 rootless runner) both can't succeed. Per feedback_ci_runner_install_needs_writable_path + #391/#402, jq is already baked into runner-base. Replace the install dance with a clear `exit 1` + diagnostic so a missing-jq runner fails loud rather than confusingly. Smoke-test (mocked Gitea API): no-approve → exit 1 (gate red) self-approve → exit 1 (gate red) dismissed-approve → exit 1 (gate red) non-team-approve → exit 1 (gate red) team-approve → exit 0 (gate green) Blocker 2 (A1-α event-suffix context-name verification) is the smoke-PR's job and is flagged in a follow-up comment on this PR — does not require workflow changes here. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-11 11:45:59 -07:00
core-devops	e922351b78	feat(ci): add qa-review + security-review checks (RFC#324 Step 1 of 5) ... Adds the two job-conclusion-as-status review-gate workflows that will replace sop-tier-check (Step 3 of RFC#324). Both: - Trigger on pull_request_target (opened/synchronize/reopened) for the initial status, plus issue_comment for /qa-recheck and /security-recheck slash-command refire (Gitea 1.22.6 doesn't refire on pull_request_review per go-gitea/gitea#33700). - Use job name 'approved' so the published context is 'qa-review / approved' and 'security-review / approved' — NO POST /statuses, NO write:repository scope (RFC#324 v1.1 addendum A1-α). - Privilege-check slash-command commenters via /repos/.../collaborators/{u} (NOT github.event.comment.author_association — that field doesn't exist on Gitea 1.22.6, defect #1 from sop-tier-refire). - Run under pull_request_target's BASE-branch trust boundary; checkout pins to default_branch (never head.sha) and the workflows only HTTP-call the Gitea API; no PR-head code is executed (RFC#324 A4 + internal#116). Shared evaluator lives at .gitea/scripts/review-check.sh, parameterized by TEAM + TEAM_ID. Pass condition: at least one APPROVED, non-dismissed, non-author review whose user is a member of the named team. Branch-protection flip (Step 2) is intentionally NOT included in this PR. That is Owners-tier and blocked on (a) the first run of these workflows capturing the EXACT status-context names, and (b) RFC_324_TEAM_READ_TOKEN provisioning (filed as internal#325). Refs: internal#324, internal#325 (token follow-up). Closes: nothing yet — Steps 2 and 3 must land before #292/#319/#321 close. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-11 11:30:34 -07:00