Generalize tracker references, restructure refactor skill, and strengthen coding rules

- Replace all Jira-specific references with generic tracker/work-item
  terminology (TRACKER-ID, work item epics); delete project-management.mdc
  and mcp.json.example
- Restructure refactor skill: extract 8 phases (00–07) and templates into
  separate files; add guided mode for pre-built change lists
- Add Step 3 "Code Testability Revision" to existing-code workflow
  (renumber steps 3–12 → 3–13)
- Simplify autopilot state file to minimal current-step pointer
- Strengthen coding rules: AAA test comments per language, test failures as
  blocking gates, dependency install policy
- Add Docker Suitability Assessment to test-spec and test-run skills
  (local vs Docker execution)
- Narrow human-attention sound rule to human-input-needed only
- Add AskQuestion fallback to plain text across skills
- Rename FINAL_implementation_report to implementation_report_*
- Simplify cursor-meta (remove _docs numbering table, quality thresholds)
- Make techstackrule alwaysApply, add alwaysApply:false to openapi

.cursor/rules/coderule.mdc

@@ -5,18 +5,21 @@ alwaysApply: true
 # Coding preferences
 - Always prefer simple solution
 - Generate concise code
-- Do not put comments in the code
+- Do not put comments in the code, except in tests: every test must use the Arrange / Act / Assert pattern with language-appropriate comment syntax (`# Arrange` for Python, `// Arrange` for C#/Rust/JS/TS). Omit any section that is not needed (e.g. if there is no setup, skip Arrange; if act and assert are the same line, keep only Assert)
 - Do not put logs unless it is an exception, or was asked specifically
 - Do not put code annotations unless it was asked specifically 
 - Write code that takes into account the different environments: development, production
 - You are careful to make changes that are requested or you are confident the changes are well understood and related to the change being requested
 - Mocking data is needed only for tests, never mock data for dev or prod env
 - When you add new libraries or dependencies make sure you are using the same version of it as other parts of the code
+- When a test fails due to a missing dependency, install it — do not fake or stub the module system. For normal packages, add them to the project's dependency file (requirements-test.txt, package.json devDependencies, test csproj, etc.) and install. Only consider stubbing if the dependency is heavy (e.g. hardware-specific SDK, large native toolchain) — and even then, ask the user first before choosing to stub.
 
 - Focus on the areas of code relevant to the task
 - Do not touch code that is unrelated to the task
 - Always think about what other methods and areas of code might be affected by the code changes
-- When you think you are done with changes, run tests and make sure they are not broken
+- When you think you are done with changes, run the full test suite. Every failure — including pre-existing ones, collection errors, and import errors — is a **blocking gate**. Never silently ignore, skip, or proceed past a failing test. On any failure, stop and ask the user to choose one of:
+  - **Investigate and fix** the failing test or source code
+  - **Remove the test** if it is obsolete or no longer relevant
 - Do not rename any databases or tables or table columns without confirmation. Avoid such renaming if possible.
 
 - Make sure we don't commit binaries, create and keep .gitignore up to date and delete binaries after you are done with the task

.cursor/rules/cursor-meta.mdc

@@ -17,26 +17,11 @@ globs: [".cursor/**"]
 ## Agent Files (.cursor/agents/)
 - Must have `name` and `description` in frontmatter
 
-## _docs/ Directory Numbering Convention
-| Prefix | Content |
-|--------|---------|
-| `00_` | Problem definition, research artifacts |
-| `01_` | Solution drafts |
-| `02_` | Documentation, tasks |
-| `03_` | Implementation reports |
-| `04_` | Deploy, refactoring |
-| `05_` | Security audit |
-| `06_` | Metrics / retrospective |
+## User Interaction
+- Use the AskQuestion tool for structured choices (A/B/C/D) when available — it provides an interactive UI. Fall back to plain-text questions if the tool is unavailable.
 
-## Quality Thresholds (project-wide)
-| Metric | Target | Used by |
-|--------|--------|---------|
-| Test coverage (black-box) | >= 70% of acceptance criteria | test-spec |
-| Test coverage (refactor safety net) | >= 75% line, 90% critical paths | refactor |
-| CI pipeline coverage gate | >= 75% | deploy |
-
-## Work Item Tracker
-Skills reference Jira MCP by default. Azure DevOps MCP is an equal alternative. The autopilot protocols handle authentication for whichever is configured.
+## Execution Safety
+- Never run test suites, builds, Docker commands, or other long-running/resource-heavy/security-risky operations without asking the user first - unlsess it is explicilty stated in skill or agent, or user already asked to do so.
 
 ## Security
 - All `.cursor/` files must be scanned for hidden Unicode before committing (see cursor-security.mdc)

.cursor/rules/git-workflow.mdc

@@ -1,8 +1,8 @@
 ---
-description: "Git workflow: work on dev branch, commit message format with Jira IDs"
+description: "Git workflow: work on dev branch, commit message format with tracker IDs"
 alwaysApply: true
 ---
 # Git Workflow
 
 - Work on the `dev` branch
-- Commit message format: `[JIRA-ID-1] [JIRA-ID-2] Summary of changes`
+- Commit message format: `[TRACKER-ID-1] [TRACKER-ID-2] Summary of changes`

.cursor/rules/human-attention-sound.mdc

@@ -1,12 +1,10 @@
 ---
-description: "Play a notification sound when the AI agent needs human input or when AI generation is finished"
+description: "Play a notification sound whenever the AI agent needs human input, confirmation, or approval"
 alwaysApply: true
 ---
-# Sound Notification for Human Attention
+# Sound Notification on Human Input
 
-Play a notification sound whenever human attention is needed. This includes waiting for input AND completing generation.
-
-## Commands by OS
+Whenever you are about to ask the user a question, request confirmation, present options for a decision, or otherwise pause and wait for human input, you MUST first run the appropriate shell command for the current OS:
 
 - **macOS**: `afplay /System/Library/Sounds/Glass.aiff &`
 - **Linux**: `paplay /usr/share/sounds/freedesktop/stereo/bell.oga 2>/dev/null || aplay /usr/share/sounds/freedesktop/stereo/bell.oga 2>/dev/null || echo -e '\a' &`
@@ -14,15 +12,13 @@ Play a notification sound whenever human attention is needed. This includes wait
 
 Detect the OS from the user's system info or by running `uname -s` if unknown.
 
-## When to play the sound
-
+This applies to:
 - Asking clarifying questions
 - Presenting choices (e.g. via AskQuestion tool)
 - Requesting approval for destructive actions
 - Reporting that you are blocked and need guidance
 - Any situation where the conversation will stall without user response
-- **When AI generation is complete** — play the sound as the very last action before ending your turn, so the user knows the response is ready
+- Completing a task (final answer / deliverable ready for review)
 
-## When NOT to play the sound
-
-- In the middle of executing a multi-step task and just providing a status update (more tool calls will follow)
+Do NOT play the sound when:
+- You are in the middle of executing a multi-step task and just providing a status update

.cursor/rules/openapi.mdc

@@ -1,6 +1,7 @@
 ---
 description: "OpenAPI/Swagger API documentation standards — applied when editing API spec files"
 globs: ["**/openapi*", "**/swagger*"]
+alwaysApply: false
 ---
 # OpenAPI
 

.cursor/rules/project-management.mdc

@@ -1,7 +0,0 @@
-# Project Management
-
-- This project uses **Jira ONLY** for work item tracking (NOT Azure DevOps)
-- Jira project key: `AZ` (AZAION)
-- Jira cloud ID: `1598226f-845f-4705-bcd1-5ed0c82d6119`
-- Use the `user-Jira-MCP-Server` MCP server for all Jira operations
-- Never use Azure DevOps MCP for this project's work items

.cursor/rules/techstackrule.mdc

@@ -1,6 +1,6 @@
 ---
-description: "Technology stack preferences for new code: Postgres DB, .NET/Python/Rust backend, React/Tailwind frontend, OpenAPI for APIs. Apply when creating new projects, choosing frameworks, or making technology decisions."
-alwaysApply: false
+description: "Defines required technology choices: Postgres DB, .NET/Python/Rust backend, React/Tailwind frontend, OpenAPI for APIs"
+alwaysApply: true
 ---
 # Tech Stack
 - Prefer Postgres database, but ask user

.cursor/rules/testing.mdc

@@ -4,7 +4,7 @@ globs: ["**/*test*", "**/*spec*", "**/*Test*", "**/tests/**", "**/test/**"]
 ---
 # Testing
 
-- Structure every test with `//Arrange`, `//Act`, `//Assert` comments
+- Structure every test with Arrange / Act / Assert section comments using language-appropriate syntax (`# Arrange` for Python, `// Arrange` for C#/Rust/JS/TS)
 - One assertion per test when practical; name tests descriptively: `MethodName_Scenario_ExpectedResult`
 - Test boundary conditions, error paths, and happy paths
 - Use mocks only for external dependencies; prefer real implementations for internal code