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/skills/test-spec/SKILL.md

@@ -147,7 +147,7 @@ If TESTS_OUTPUT_DIR already contains files:
 
 ## Progress Tracking
 
-At the start of execution, create a TodoWrite with all three phases. Update status as each phase completes.
+At the start of execution, create a TodoWrite with all four phases. Update status as each phase completes.
 
 ## Workflow
 
@@ -209,7 +209,7 @@ Based on all acquired data, acceptance_criteria, and restrictions, form detailed
 - [ ] Expected results use comparison methods from `.cursor/skills/test-spec/templates/expected-results.md`
 - [ ] Positive and negative scenarios are balanced
 - [ ] Consumer app has no direct access to system internals
-- [ ] Docker environment is self-contained (`docker compose up` sufficient)
+- [ ] Test environment matches project constraints (see Docker Suitability Assessment below)
 - [ ] External dependencies have mock/stub services defined
 - [ ] Traceability matrix has no uncovered AC or restrictions
 
@@ -337,11 +337,53 @@ When coverage ≥ 70% and all remaining tests have validated data AND quantifiab
 
 ---
 
+### Docker Suitability Assessment (BLOCKING — runs before Phase 4)
+
+Docker is the **preferred** test execution environment (reproducibility, isolation, CI parity). Before generating scripts, check whether the project has any constraints that prevent easy Docker usage.
+
+**Disqualifying factors** (any one is sufficient to fall back to local):
+- Hardware bindings: GPU, MPS, TPU, FPGA, accelerators, sensors, cameras, serial devices, host-level drivers (CUDA, Metal, OpenCL, etc.)
+- Host dependencies: licensed software, OS-specific services, kernel modules, proprietary SDKs not installable in a container
+- Data/volume constraints: large files (> 100MB) that would be impractical to copy into a container, databases that must run on the host
+- Network/environment: tests that require host networking, VPN access, or specific DNS/firewall rules
+- Performance: Docker overhead would invalidate benchmarks or latency-sensitive measurements
+
+**Assessment steps**:
+1. Scan project source, config files, and dependencies for indicators of the factors above
+2. Check `TESTS_OUTPUT_DIR/environment.md` for environment requirements
+3. Check `_docs/00_problem/restrictions.md` and `_docs/01_solution/solution.md` for constraints
+
+**Decision**:
+- If ANY disqualifying factor is found → recommend **local test execution** as fallback. Present to user using Choose format:
+
+```
+══════════════════════════════════════
+ DECISION REQUIRED: Test execution environment
+══════════════════════════════════════
+ Docker is preferred, but factors preventing easy
+ Docker execution detected:
+ - [list factors found]
+══════════════════════════════════════
+ A) Local execution (recommended)
+ B) Docker execution (constraints may cause issues)
+══════════════════════════════════════
+ Recommendation: A — detected constraints prevent
+ easy Docker execution
+══════════════════════════════════════
+```
+
+- If NO disqualifying factors → use Docker (preferred default)
+- Record the decision in `TESTS_OUTPUT_DIR/environment.md` under a "Test Execution" section
+
+---
+
 ### Phase 4: Test Runner Script Generation
 
+**Skip condition**: If this skill was invoked from the `/plan` skill (planning context, no code exists yet), skip Phase 4 entirely. Script creation should instead be planned as a task during decompose — the decomposer creates a task for creating these scripts. Phase 4 only runs when invoked from the existing-code flow (where source code already exists) or standalone.
+
 **Role**: DevOps engineer
 **Goal**: Generate executable shell scripts that run the specified tests, so the autopilot and CI can invoke them consistently.
-**Constraints**: Scripts must be idempotent, portable across dev/CI, and exit with non-zero on failure.
+**Constraints**: Scripts must be idempotent, portable across dev/CI, and exit with non-zero on failure. Respect the Docker Suitability Assessment decision above.
 
 #### Step 1 — Detect test infrastructure
 
@@ -350,7 +392,9 @@ When coverage ≥ 70% and all remaining tests have validated data AND quantifiab
    - .NET: `dotnet test` (*.csproj, *.sln)
    - Rust: `cargo test` (Cargo.toml)
    - Node: `npm test` or `vitest` / `jest` (package.json)
-2. Identify docker-compose files for integration/blackbox tests (`docker-compose.test.yml`, `e2e/docker-compose*.yml`)
+2. Check Docker Suitability Assessment result:
+   - If **local execution** was chosen → do NOT generate docker-compose test files; scripts run directly on host
+   - If **Docker execution** was chosen → identify/generate docker-compose files for integration/blackbox tests
 3. Identify performance/load testing tools from dependencies (k6, locust, artillery, wrk, or built-in benchmarks)
 4. Read `TESTS_OUTPUT_DIR/environment.md` for infrastructure requirements
 
@@ -360,10 +404,11 @@ Create `scripts/run-tests.sh` at the project root using `.cursor/skills/test-spe
 
 1. Set `set -euo pipefail` and trap cleanup on EXIT
 2. Optionally accept a `--unit-only` flag to skip blackbox tests
-3. Run unit tests using the detected test runner
-4. If blackbox tests exist: spin up docker-compose environment, wait for health checks, run blackbox test suite, tear down
-5. Print a summary of passed/failed/skipped tests
-6. Exit 0 on all pass, exit 1 on any failure
+3. Run unit/blackbox tests using the detected test runner:
+   - **Local mode**: activate virtualenv (if present), run test runner directly on host
+   - **Docker mode**: spin up docker-compose environment, wait for health checks, run test suite, tear down
+4. Print a summary of passed/failed/skipped tests
+5. Exit 0 on all pass, exit 1 on any failure
 
 #### Step 3 — Generate `scripts/run-performance-tests.sh`
 
@@ -371,7 +416,7 @@ Create `scripts/run-performance-tests.sh` at the project root. The script must:
 
 1. Set `set -euo pipefail` and trap cleanup on EXIT
 2. Read thresholds from `_docs/02_document/tests/performance-tests.md` (or accept as CLI args)
-3. Spin up the system under test (docker-compose or local)
+3. Start the system under test (local or docker-compose, matching the Docker Suitability Assessment decision)
 4. Run load/performance scenarios using the detected tool
 5. Compare results against threshold values from the test spec
 6. Print a pass/fail summary per scenario