# Phase 02 — Reviews can never go live

**Blocker:** blockers.md § "Reviews."
**Depends on:** [01-admin-rbac.md](01-admin-rbac.md) — same root cause, no separate code fix.

---

**Root cause.** Same broken policy as phase 01, nothing else. `AdminReviewsController.cs:20` (the moderation
queue) and `ReviewsController.cs:33` (the `PATCH {reviewId}/status` publish action) are both gated by
`[Authorize(ConstantPolicies.DynamicPermission)]` → the same `CanAccess` check.

**The fix:** none needed beyond phase 01 — once `moderation`/`super_admin` pass `CanAccess`, both endpoints
become reachable immediately.

## Two secondary things worth doing in the same pass (not required to "unstick" reviews)

- `ReviewModerationStatus.Rejected` is currently unreachable end-to-end even after the RBAC fix — the
  submit-time banned-word path maps to `Hidden`, not `Rejected` (`SubmitReviewCommand.Handler.cs:77`), and the
  only other producer of `Rejected` is the admin PATCH. Once RBAC is fixed this stops being a dead state (an
  admin really can reject a review), so no code change is actually required — just noting the client's
  `rejected` chip (`review/page.tsx:48`) was previously unreachable and will start being exercised.
- **Flag, don't guess:** should `Seams:ReviewModeration:AutoApproveClean` be turned on so reviews aren't stuck
  pending an admin action that may not happen promptly? That's a product call, not inferable from code.