blocker fix phases added

2026-08-02 20:37:14 +03:30
parent fb58ca54e1
commit 42f38f5a72
17 changed files with 661 additions and 0 deletions
@@ -0,0 +1,23 @@
+# 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.