[AZ-240] Update product implementation and task decomposition processes

- Refined task decomposition steps to ensure implementation tasks are atomic and complexity does not exceed 5 points.
- Enhanced the product implementation process with a completeness gate to verify task outcomes against architecture promises before proceeding to testing.
- Updated dependencies table to reflect new tasks and their relationships, ensuring all test tasks are linked to product remediation tasks.
- Adjusted workflow documentation to clarify entry points for task decomposition and implementation contexts.

Co-authored-by: Cursor <cursoragent@cursor.com>

_docs/04_refactoring/01-testability-refactoring/testability_assessment.md

@@ -0,0 +1,56 @@
+# Code Testability Assessment
+
+**Date**: 2026-05-04
+**Autodev step**: Greenfield Step 8 — Code Testability Revision
+**Outcome**: Code is testable — no changes needed
+
+## Scope Reviewed
+
+- Test specifications in `_docs/02_document/tests/`
+- Traceability matrix in `_docs/02_document/tests/traceability-matrix.md`
+- Runtime source under `src/`
+- Existing unit tests under `tests/`
+- Product implementation report `_docs/03_implementation/implementation_report_product_runtime_cycle1.md`
+
+## Testability Result
+
+The implemented product runtime can support the planned tests without a testability-focused refactor.
+
+- Runtime components expose public package-level APIs through `__init__.py`, `types.py`, and `interfaces.py`.
+- Component behavior is expressed through data models and class/protocol boundaries that can be constructed directly in tests.
+- External systems are represented as boundary objects or planned black-box fixtures, not hardwired network calls.
+- No direct filesystem, environment, subprocess, socket, HTTP, global singleton, or wall-clock usage was found in `src/` that would block deterministic tests.
+- Planned hardware, SITL, Jetson, and dataset dependencies belong in test harness tasks and can report `blocked` when prerequisites are unavailable.
+
+## Scenario Review
+
+| Scenario Area | Testability Assessment |
+|---------------|------------------------|
+| Unit/component tests | Current public classes and DTOs are directly constructible and already covered by 49 passing tests. |
+| Black-box replay | The planned harness can drive public frame, telemetry, cache, MAVLink, status, and FDR boundaries without importing runtime internals. |
+| VIO and anchor replay | Heavy BASALT, FAISS, and matcher dependencies can be represented by test harness fixtures or backend boundaries in test tasks. |
+| SITL/MAVLink tests | The MAVLink/GCS gateway exposes validation and status behavior without requiring live hardware for unit-level coverage. |
+| Jetson/resource tests | Hardware-specific release gates are environment-dependent and do not require runtime refactoring before test-task implementation. |
+| Security/cache tests | Cache, freshness, no-fetch, and generated-tile trust behavior is exposed through public component methods. |
+
+## Reviewed Test Artifacts
+
+- `_docs/02_document/tests/blackbox-tests.md`
+- `_docs/02_document/tests/e2e-test-suite.md`
+- `_docs/02_document/tests/environment.md`
+- `_docs/02_document/tests/performance-tests.md`
+- `_docs/02_document/tests/resilience-tests.md`
+- `_docs/02_document/tests/resource-limit-tests.md`
+- `_docs/02_document/tests/security-tests.md`
+- `_docs/02_document/tests/test-data.md`
+- `_docs/02_document/tests/traceability-matrix.md`
+
+## Verification
+
+- `.venv/bin/python -m black --check src tests e2e/replay` passed.
+- `.venv/bin/python -m ruff check src tests e2e/replay` passed.
+- `.venv/bin/python -m pytest` passed: 49 tests.
+
+## Next Step
+
+Proceed to Greenfield Step 9, Decompose Tests.