Fix .cursor skills consistency: flow resolution, tracker-agnostic refs, report naming, error recovery

- Rewrite autopilot flow resolution to 4 deterministic rules based on source code + docs + state file presence
- Replace all hard-coded Jira references with tracker-agnostic terminology across 30+ files
- Move project-management.mdc to _project.md (project-specific, not portable with .cursor)
- Rename FINAL_implementation_report.md to context-dependent names (implementation_report_tests/features/refactor)
- Remove "acknowledged tech debt" option from test-run — failing tests must be fixed or removed
- Add debug/error recovery protocol to protocols.md
- Align directory paths: metrics -> 06_metrics/, add 05_security/, reviews/, 02_task_plans/ to README
- Add missing skills (test-spec, test-run, new-task, ui-design) to README
- Use language-appropriate comment syntax for Arrange/Act/Assert in coderule + testing rules
- Copy updated coderule.mdc to parent suite/.cursor/rules/
- Raise max task complexity from 5 to 8 points in decompose
- Skip test-spec Phase 4 (script generation) during planning context
- Document per-batch vs post-implement test run as intentional
- Add skill-internal state cross-check rule to state.md

.cursor/skills/autopilot/protocols.md

@@ -51,12 +51,11 @@ Rules:
 
 ## Work Item Tracker Authentication
 
-Several workflow steps create work items (epics, tasks, links). The system supports **Jira MCP** and **Azure DevOps MCP** as interchangeable backends. Detect which is configured by listing available MCP servers.
+Several workflow steps create work items (epics, tasks, links). The system requires some task tracker MCP as interchangeable backend.
 
 ### Tracker Detection
 
-1. Check for available MCP servers: Jira MCP (`user-Jira-MCP-Server`) or Azure DevOps MCP (`user-AzureDevops`)
-2. If both are available, ask the user which to use (Choose format)
+1. If there is no task tracker MCP or it is not authorized, ask the user about it
 3. Record the choice in the state file: `tracker: jira` or `tracker: ado`
 4. If neither is available, set `tracker: local` and proceed without external tracking
 
@@ -294,6 +293,71 @@ For steps that produce `_docs/` artifacts (problem, research, plan, decompose, d
 3. **Git safety net**: artifacts are committed with each autopilot step completion. To roll back: `git log --oneline _docs/` to find the commit, then `git checkout <commit> -- _docs/<folder>/`
 4. **State file rollback**: when rolling back artifacts, also update `_docs/_autopilot_state.md` to reflect the rolled-back step (set it to `in_progress`, clear completed date)
 
+## Debug / Error Recovery Protocol
+
+When the implement skill's auto-fix loop fails (code review FAIL after 2 auto-fix attempts) or an implementer subagent reports a blocker, the user is asked to intervene. This protocol guides the recovery process.
+
+### Structured Debugging Workflow
+
+When escalated to the user after implementation failure:
+
+1. **Classify the failure** — determine the category:
+   - **Missing dependency**: a package, service, or module the task needs but isn't available
+   - **Logic error**: code runs but produces wrong results (assertion failures, incorrect output)
+   - **Integration mismatch**: interfaces between components don't align (type errors, missing methods, wrong signatures)
+   - **Environment issue**: Docker, database, network, or configuration problem
+   - **Spec ambiguity**: the task spec is unclear or contradictory
+
+2. **Reproduce** — isolate the failing behavior:
+   - Run the specific failing test(s) in isolation
+   - Check whether the failure is deterministic or intermittent
+   - Capture the exact error message, stack trace, and relevant file:line
+
+3. **Narrow scope** — focus on the minimal reproduction:
+   - For logic errors: trace the data flow from input to the point of failure
+   - For integration mismatches: compare the caller's expectations against the callee's actual interface
+   - For environment issues: verify Docker services are running, DB is accessible, env vars are set
+
+4. **Fix and verify** — apply the fix and confirm:
+   - Make the minimal change that fixes the root cause
+   - Re-run the failing test(s) to confirm the fix
+   - Run the full test suite to check for regressions
+   - If the fix changes a shared interface, check all consumers
+
+5. **Report** — update the batch report with:
+   - Root cause category
+   - Fix applied (file:line, description)
+   - Tests that now pass
+
+### Common Recovery Patterns
+
+| Failure Pattern | Typical Root Cause | Recovery Action |
+|----------------|-------------------|----------------|
+| ImportError / ModuleNotFoundError | Missing dependency or wrong path | Install dependency or fix import path |
+| TypeError on method call | Interface mismatch between tasks | Align caller with callee's actual signature |
+| AssertionError in test | Logic bug or wrong expected value | Fix logic or update test expectations |
+| ConnectionRefused | Service not running | Start Docker services, check docker-compose |
+| Timeout | Blocking I/O or infinite loop | Add timeout, fix blocking call |
+| FileNotFoundError | Hardcoded path or missing fixture | Make path configurable, add fixture |
+
+### Escalation
+
+If debugging does not resolve the issue after 2 focused attempts:
+
+```
+══════════════════════════════════════
+ DEBUG ESCALATION: [failure description]
+══════════════════════════════════════
+ Root cause category: [category]
+ Attempted fixes: [list]
+ Current state: [what works, what doesn't]
+══════════════════════════════════════
+ A) Continue debugging with more context
+ B) Revert this batch and skip the task (move to backlog)
+ C) Simplify the task scope and retry
+══════════════════════════════════════
+```
+
 ## Status Summary
 
 On every invocation, before executing any skill, present a status summary built from the state file (with folder scan fallback). Use the Status Summary Template from the active flow file (`flows/greenfield.md` or `flows/existing-code.md`).