feat: add commit-docs-reminder hook to enforce checklist before commits

Adds a PreToolUse Bash hook that reminds AI agents to verify
status-update-checklist.md before running git commit. Also adds
the corresponding constraint to RULES.md section 3.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

RULES.md

@@ -31,8 +31,8 @@ conflict.
 4. **Prefer minimal, surgical changes.** Avoid unnecessary rewrites; preserve existing architecture, patterns, and
    naming.
 5. **Respect security and privacy.**
-    - Never include secrets, tokens, or API keys in code or output.
-    - Do not log, echo, or request PII unless the task requires it; minimize exposure.
+   - Never include secrets, tokens, or API keys in code or output.
+   - Do not log, echo, or request PII unless the task requires it; minimize exposure.
 6. **Avoid destructive actions without consent.** Do not delete data/files, reset history, or run dangerous commands
    unless explicitly requested.
 7. **Do not add dependencies lightly.** Introduce new packages/tools only with clear justification and after checking
@@ -61,6 +61,7 @@ conflict.
 2. **Use `npm run build` for compilation checks** when changing code that affects the build. Re‑run after meaningful
    changes.
 3. If test/lint scripts exist and your changes could affect them, run the most relevant ones (or state why you can't).
+4. **Before committing** — if changes affect project status, audit findings, or phase progress, read and follow `.claude/status-update-checklist.md` to synchronize all documentation files in one commit.
 
 ---
 
@@ -68,10 +69,10 @@ conflict.
 
 - Agent profiles live in `agents/` and define role‑specific behavior (metadata + detailed instructions).
 - Before starting a task:
-    1. Scan available profiles in `agents/`.
-    2. Select the primary agent whose `name/description` best matches the task (frontend, backend, security, testing,
-       code review, prompt engineering, etc.).
-    3. Apply that profile in addition to these core rules.
+  1. Scan available profiles in `agents/`.
+  2. Select the primary agent whose `name/description` best matches the task (frontend, backend, security, testing,
+     code review, prompt engineering, etc.).
+  3. Apply that profile in addition to these core rules.
 - If a task spans domains, follow Section 5 for coordination.
 
 ---
@@ -80,10 +81,10 @@ conflict.
 
 1. Identify all relevant domains/agents.
 2. Choose a primary agent based on the main intent:
-    - **Design/architecture** → architect‑type agent.
-    - **Implementation** → domain architect (frontend/backend).
-    - **Review/audit** → reviewer/security agent.
-    - **Prompt/workflow** → prompt‑engineer agent.
+   - **Design/architecture** → architect‑type agent.
+   - **Implementation** → domain architect (frontend/backend).
+   - **Review/audit** → reviewer/security agent.
+   - **Prompt/workflow** → prompt‑engineer agent.
 3. Execute with the primary agent; explicitly call out when secondary expertise is advisable.
 4. If the request mixes distinct phases (e.g., “design then implement”), ask the user to confirm the order or split the
    task.