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/implement/SKILL.md

@@ -85,7 +85,7 @@ For each task in the batch:
 
 ### 5. Update Tracker Status → In Progress
 
-For each task in the batch, transition its ticket status to **In Progress** via the configured work item tracker (Jira MCP or Azure DevOps MCP — see `protocols.md` for detection) before launching the implementer. If `tracker: local`, skip this step.
+For each task in the batch, transition its ticket status to **In Progress** via the configured work item tracker (see `protocols.md` for tracker detection) before launching the implementer. If `tracker: local`, skip this step.
 
 ### 6. Launch Implementer Subagents
 
@@ -132,12 +132,13 @@ Track `auto_fix_attempts` count in the batch report for retrospective analysis.
 
 - Read and execute `.cursor/skills/test-run/SKILL.md` (detect runner, run suite, diagnose failures, present blocking choices)
 - Test failures are a **blocking gate** — do not proceed to commit until the test-run skill completes with a user decision
+- Note: the autopilot also runs a separate full test suite after all implementation batches complete (greenfield Step 7, existing-code Steps 6/10). This is intentional — per-batch tests are regression checks, the post-implement run is final validation.
 
 ### 11. Commit and 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 (Jira IDs, ADO 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 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
 
 ### 12. Update Tracker Status → In Testing
@@ -155,7 +156,13 @@ Move each completed task file from `TASKS_DIR/todo/` to `TASKS_DIR/done/`.
 
 ## Batch Report Persistence
 
-After each batch completes, save the batch report to `_docs/03_implementation/batch_[NN]_report.md`. Create the directory if it doesn't exist. When all tasks are complete, produce `_docs/03_implementation/FINAL_implementation_report.md` with a summary of all batches.
+After each batch completes, save the batch report to `_docs/03_implementation/batch_[NN]_report.md`. Create the directory if it doesn't exist. When all tasks are complete, produce a FINAL implementation report with a summary of all batches. The filename depends on context:
+
+- **Test implementation** (tasks from test decomposition): `_docs/03_implementation/implementation_report_tests.md`
+- **Feature implementation**: `_docs/03_implementation/implementation_report_{feature_slug}.md` where `{feature_slug}` is derived from the batch task names (e.g., `implementation_report_core_api.md`)
+- **Refactoring**: `_docs/03_implementation/implementation_report_refactor_{run_name}.md`
+
+Determine the context from the task files being implemented: if all tasks have test-related names or belong to a test epic, use the tests filename; otherwise derive the feature slug from the component names.
 
 ## Batch Report
 
@@ -172,7 +179,7 @@ After each batch, produce a structured report:
 
 | Task | Status | Files Modified | Tests | Issues |
 |------|--------|---------------|-------|--------|
-| [JIRA-ID]_[name] | Done | [count] files | [pass/fail] | [count or None] |
+| [TRACKER-ID]_[name] | Done | [count] files | [pass/fail] | [count or None] |
 
 ## Code Review Verdict: [PASS/FAIL/PASS_WITH_WARNINGS]
 ## Auto-Fix Attempts: [0/1/2]