Update coding standards and testing rules; enhance clarity on coverage thresholds and test data requirements. Adjust commit message guidelines for better readability and enforce sound notifications for user interactions.

.cursor/skills/implement/SKILL.md

@@ -28,7 +28,7 @@ The `implementer` agent is the specialist that writes all the code — it receiv
 - **Integrated review**: `/code-review` skill runs automatically after each batch
 - **Auto-start**: batches launch immediately — no user confirmation before a batch
 - **Gate on failure**: user confirmation is required only when code review returns FAIL
-- **Commit and push per batch**: after each batch is confirmed, commit and push to remote
+- **Commit per batch**: after each batch is confirmed, commit. Ask the user whether to push to remote unless the user previously opted into auto-push for this session.
 
 ## Context Resolution
 
@@ -134,25 +134,38 @@ Only proceed to Step 9 when every AC has a corresponding test.
 
 ### 10. Auto-Fix Gate
 
-Auto-fix loop with bounded retries (max 2 attempts) before escalating to user:
+Bounded auto-fix loop — only applies to **mechanical** findings. Critical and Security findings are never auto-fixed.
 
-1. If verdict is **PASS** or **PASS_WITH_WARNINGS**: show findings as info, continue automatically to step 11
-2. If verdict is **FAIL** (attempt 1 or 2):
-   - Parse the code review findings (Critical and High severity items)
-   - For each finding, attempt an automated fix using the finding's location, description, and suggestion
-   - Re-run `/code-review` on the modified files
-   - If now PASS or PASS_WITH_WARNINGS → continue to step 11
-   - If still FAIL → increment retry counter, repeat from (2) up to max 2 attempts
-3. If still **FAIL** after 2 auto-fix attempts: present all findings to user (**BLOCKING**). User must confirm fixes or accept before proceeding.
+**Auto-fix eligibility matrix:**
 
-Track `auto_fix_attempts` count in the batch report for retrospective analysis.
+| Severity | Category | Auto-fix? |
+|----------|----------|-----------|
+| Low | any | yes |
+| Medium | Style, Maintainability, Performance | yes |
+| Medium | Bug, Spec-Gap, Security | escalate |
+| High | Style, Scope | yes |
+| High | Bug, Spec-Gap, Performance, Maintainability | escalate |
+| Critical | any | escalate |
+| any | Security | escalate |
 
-### 11. Commit and Push
+Flow:
+
+1. If verdict is **PASS** or **PASS_WITH_WARNINGS**: show findings as info, continue to step 11
+2. If verdict is **FAIL**:
+   - Partition findings into auto-fix-eligible and escalate (using the matrix above)
+   - For eligible findings, attempt fixes using location/description/suggestion, then re-run `/code-review` on modified files (max 2 rounds)
+   - If all remaining findings are auto-fix-eligible and re-review now passes → continue to step 11
+   - If any non-eligible finding exists at any point → stop auto-fixing, present the full list to the user (**BLOCKING**)
+3. User must explicitly approve each non-auto-fix finding (accept, request manual fix, mark as out-of-scope) before proceeding.
+
+Track `auto_fix_attempts` and `escalated_findings` in the batch report for retrospective analysis.
+
+### 11. Commit (and optionally Push)
 
 - After user confirms the batch (explicitly for FAIL, implicitly for PASS/PASS_WITH_WARNINGS):
   - `git add` all changed files from the batch
   - `git commit` with a message that includes ALL task IDs (tracker IDs or numeric prefixes) of tasks implemented in the batch, followed by a summary of what was implemented. Format: `[TASK-ID-1] [TASK-ID-2] ... Summary of changes`
-  - `git push` to the remote branch
+  - Ask the user whether to push to remote, unless the user previously opted into auto-push for this session
 
 ### 12. Update Tracker Status → In Testing