Таски готовы

.kilocode/workflows/speckit.implement.md

@@ -1,9 +1,13 @@
 ---
 description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
-handoffs: 
-  - label: Verify Changes
-    agent: speckit.test
-    prompt: Verify the implementation of...
+handoffs:
+  - label: Audit & Verify (Tester)
+    agent: tester
+    prompt: Perform semantic audit, algorithm emulation, and unit test verification for the completed tasks.
+    send: true
+  - label: Orchestration Control
+    agent: orchestrator
+    prompt: Review Tester's feedback and coordinate next steps.
     send: true
 ---
 
@@ -122,6 +126,7 @@ You **MUST** consider the user input before proceeding (if not empty).
      - Include `@TIER` and define contracts (`@PRE`, `@POST`).
      - For Svelte components, use `@UX_STATE`, `@UX_FEEDBACK`, `@UX_RECOVERY`, and explicitly declare reactivity with `@UX_REATIVITY: State: $state, Derived: $derived`.
      - **Molecular Topology Logging**: Use prefixes `[EXPLORE]`, `[REASON]`, `[REFLECT]` in logs to trace logic.
+   - **Self-Audit**: The Coder MUST use `axiom-core` tools (like `audit_contracts_tool`) to verify semantic compliance before completion.
    - **CRITICAL Contracts**: If a task description contains a contract summary (e.g., `CRITICAL: PRE: ..., POST: ...`), these constraints are **MANDATORY** and must be strictly implemented in the code using guards/assertions (if applicable per protocol).
    - **Setup first**: Initialize project structure, dependencies, configuration
    - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
@@ -130,18 +135,32 @@ You **MUST** consider the user input before proceeding (if not empty).
    - **Polish and validation**: Unit tests, performance optimization, documentation
 
 8. Progress tracking and error handling:
-   - Report progress after each completed task
-   - Halt execution if any non-parallel task fails
-   - For parallel tasks [P], continue with successful tasks, report failed ones
-   - Provide clear error messages with context for debugging
-   - Suggest next steps if implementation cannot proceed
-   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
+   - Report progress after each completed task.
+   - Halt execution if any non-parallel task fails.
+   - For parallel tasks [P], continue with successful tasks, report failed ones.
+   - Provide clear error messages with context for debugging.
+   - Suggest next steps if implementation cannot proceed.
+   - **IMPORTANT** For completed tasks, mark as [X] only AFTER local verification and self-audit.
 
-9. Completion validation:
-   - Verify all required tasks are completed
-   - Check that implemented features match the original specification
-   - Validate that tests pass and coverage meets requirements
-   - Confirm the implementation follows the technical plan
-   - Report final status with summary of completed work
+9. **Handoff to Tester (Audit Loop)**:
+   - Once a task or phase is complete, the Coder hands off to the Tester.
+   - Handoff includes: File paths, expected contracts (@PRE/@POST), and logic overview.
+
+10. **Tester Verification & Orchestrator Gate**:
+   - Tester MUST:
+     - Perform mandatory semantic audit (using `audit_contracts_tool`).
+     - Emulate algorithms "in mind" step-by-step to ensure logic consistency.
+     - Verify unit tests match the declared contracts.
+   - If Tester finds issues:
+     - Emit `[AUDIT_FAIL: reason]` and notify the Orchestrator.
+     - Orchestrator redirects the feedback to the Coder for remediation.
+   - Acceptance (Final mark [X]):
+     - Only after the Tester is satisfied with semantics, emulation, and tests.
+
+11. Completion validation:
+    - Verify all required tasks are completed and accepted by the Tester.
+    - Check that implemented features match the original specification.
+    - Confirm the implementation follows the technical plan and GRACE standards.
+    - Report final status with summary of completed and audited work.
 
 Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/speckit.tasks` first to regenerate the task list.