1 files changed, 19 insertions, 3 deletions
diff --git a/REVIEWER_ROLE.md b/REVIEWER_ROLE.md
index ca3baa4..c4574bb 100644
--- a/REVIEWER_ROLE.md
+++ b/REVIEWER_ROLE.md
@@ -73,6 +73,22 @@
 *   **Execution:** Use Bash to run tests (`go test ./...`, `go test -cover ./...`).
 *   **Reporting:** Use Write to publish `review_feedback.md` and Edit to update `SESSION_STATE.md`.
 
-**Self-Improvement:**
-*   **Reflection:** After a review cycle, ask: "Did my feedback help the Implementor improve the code, or did it just create busy work?"
-*   **Calibration:** Periodically check `ARCHITECT_ROLE.md` to ensure your quality standards align with the architectural vision.
+**Self-Improvement Cycle:**
+
+After completing each review cycle (when marking `[APPROVED]` or `[NEEDS_FIX]`), perform this cycle:
+
+1.  **Reflect (mandatory):** Answer these questions honestly:
+    *   Did my feedback help the Implementor improve the code, or did it just create busy work?
+    *   Did I catch real issues, or did I nitpick style preferences that don't affect correctness?
+    *   Were there bugs or quality issues I missed that surfaced later in production?
+    *   Did the `[NEEDS_FIX]` → `[REVIEW_READY]` cycle resolve quickly, or did it ping-pong?
+
+2.  **Improve (1-3 actions):** Based on reflection, perform at least one concrete improvement:
+    *   **Review checklist:** If you missed an issue category (e.g., HTMX targeting, CSRF in new pages, nil pointer risks), add it to the Test Quality Analysis or Critique sections of this file.
+    *   **Feedback template:** If your feedback was unclear and caused a bad fix, refine the `review_feedback.md` structure (e.g., add a "Reproduction Steps" field for bugs, add "Suggested Fix" for critical issues).
+    *   **Quality standards:** If the Architect's vision evolved (new patterns, deprecated approaches), update the Critique checklist to match. Re-read `ARCHITECT_ROLE.md` and recent ADRs.
+    *   **Coverage gaps:** If you found that a whole category of code lacks tests (e.g., API clients, middleware), flag it in `SESSION_STATE.md` under "Known Gaps" for future work.
+    *   **False positives:** If you raised issues that were intentional design choices, note them as "Accepted Patterns" in this file to avoid re-flagging them.
+    *   **Tooling:** If manual review steps could be automated (e.g., checking for missing CSRF tokens, verifying HTMX targets), propose a linter rule or test helper.
+
+3.  **Record:** Note what was improved and why in `SESSION_STATE.md` under a "Process Improvements" section so the team can track review quality over time.