Таски готовы

.specify/templates/plan-template.md

@@ -31,7 +31,7 @@
 
 *GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
 
-[Gates determined based on constitution file]
+[Evaluate against constitution.md and semantics.md. Explicitly confirm semantic protocol compliance, complexity-driven contract coverage, UX-state compatibility, async boundaries, API-wrapper rules, RBAC/security constraints, and any required belief-state/logging constraints for Complexity 4/5 Python modules.]
 
 ## Project Structure
 
@@ -94,6 +94,22 @@ ios/ or android/
 **Structure Decision**: [Document the selected structure and reference the real
 directories captured above]
 
+## Semantic Contract Guidance
+
+> Use this section to drive Phase 1 artifacts, especially `contracts/modules.md`.
+
+- Classify each planned module/component with `@COMPLEXITY: 1..5` or `@C:`.
+- Use `@TIER` only if backward compatibility is needed; never use it as the primary contract rule.
+- Match contract density to complexity:
+  - Complexity 1: anchors only, `@PURPOSE` optional
+  - Complexity 2: `@PURPOSE`
+  - Complexity 3: `@PURPOSE`, `@RELATION`; UI also `@UX_STATE`
+  - Complexity 4: `@PURPOSE`, `@RELATION`, `@PRE`, `@POST`, `@SIDE_EFFECT`; Python also meaningful `logger.reason()` / `logger.reflect()` path
+  - Complexity 5: level 4 + `@DATA_CONTRACT`, `@INVARIANT`; Python also `belief_scope`; UI also `@UX_FEEDBACK`, `@UX_RECOVERY`, `@UX_REACTIVITY`
+- Write relations only in canonical form: `@RELATION: [PREDICATE] ->[TARGET_ID]`
+- If any relation target, DTO, or contract dependency is unknown, emit `[NEED_CONTEXT: target]` instead of inventing placeholders.
+- Preserve medium-appropriate anchor/comment syntax for Python, Svelte markup, and Svelte script contexts.
+
 ## Complexity Tracking
 
 > **Fill ONLY if Constitution Check has violations that must be justified**

.specify/templates/tasks-template.md

@@ -8,7 +8,7 @@ description: "Task list template for feature implementation"
 **Input**: Design documents from `/specs/[###-feature-name]/`
 **Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/
 
-**Tests**: The examples below include test tasks. Tests are OPTIONAL - only include them if explicitly requested in the feature specification.
+**Tests**: Include test tasks whenever required by the feature specification, the semantic contracts, or any Complexity 5 / audit-critical boundary. Test work must trace to contract requirements, not only to implementation details.
 
 **Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.
 
@@ -249,3 +249,7 @@ With multiple developers:
 - Commit after each task or logical group
 - Stop at any checkpoint to validate story independently
 - Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence
+- Derive implementation tasks from semantic contracts in `contracts/modules.md`, especially `@PRE`, `@POST`, `@SIDE_EFFECT`, `@DATA_CONTRACT`, and UI `@UX_*` tags
+- For Complexity 4/5 Python modules, include tasks for belief-state logging paths with `logger.reason()`, `logger.reflect()`, and `belief_scope` where required
+- For Complexity 5 or explicitly test-governed contracts, include tasks that cover `@TEST_CONTRACT`, `@TEST_SCENARIO`, `@TEST_FIXTURE`, `@TEST_EDGE`, and `@TEST_INVARIANT`
+- Never create tasks from legacy `@TIER` alone; complexity is the primary execution signal

.specify/templates/test-docs-template.md

@@ -21,7 +21,9 @@ description: "Test documentation template for feature implementation"
 - [ ] Unit Tests (co-located in `__tests__/` directories)
 - [ ] Integration Tests (if needed)
 - [ ] E2E Tests (if critical user flows)
-- [ ] Contract Tests (for API endpoints)
+- [ ] Contract Tests (for API endpoints and semantic contract boundaries)
+- [ ] Semantic Contract Verification (`@PRE`, `@POST`, `@SIDE_EFFECT`, `@DATA_CONTRACT`, `@TEST_*`)
+- [ ] UX Contract Verification (`@UX_STATE`, `@UX_FEEDBACK`, `@UX_RECOVERY`, `@UX_REACTIVITY`)
 
 ---
 
@@ -72,12 +74,14 @@ description: "Test documentation template for feature implementation"
 
 ### ✅ DO
 
-1. Write tests BEFORE implementation (TDD approach)
+1. Write tests BEFORE implementation when the workflow permits it
 2. Use co-location: `src/module/__tests__/test_module.py`
 3. Use MagicMock for external dependencies (DB, Auth, APIs)
-4. Include semantic annotations: `# @RELATION: VERIFIES -> module.name`
+4. Trace tests to semantic contracts and DTO boundaries, not just filenames
 5. Test edge cases and error conditions
-6. **Test UX states** for Svelte components (@UX_STATE, @UX_FEEDBACK, @UX_RECOVERY)
+6. **Test UX contracts** for Svelte components (`@UX_STATE`, `@UX_FEEDBACK`, `@UX_RECOVERY`, `@UX_REACTIVITY`)
+7. For Complexity 5 boundaries, verify `@DATA_CONTRACT`, invariants, and declared `@TEST_*` metadata
+8. For Complexity 4/5 Python flows, verify behavior around guards, side effects, and belief-state-driven logging paths where applicable
 
 ### ❌ DON'T
 
@@ -86,7 +90,8 @@ description: "Test documentation template for feature implementation"
 3. Test implementation details, not behavior
 4. Use real external services in unit tests
 5. Skip error handling tests
-6. **Skip UX contract tests** for CRITICAL frontend components
+6. **Skip UX contract tests** for critical frontend components
+7. Treat legacy `@TIER` as sufficient proof of test scope without checking actual complexity and contract metadata
 
 ---
 

.specify/templates/ux-reference-template.md

@@ -39,15 +39,23 @@ $ command --flag value
 *   **Key Elements**:
     *   **[Button Name]**: Primary action. Color: Blue.
     *   **[Input Field]**: Placeholder text: "Enter your name...". Validation: Real-time.
+*   **Contract Mapping**:
+    *   **`@UX_STATE`**: Enumerate the explicit UI states that must appear later in `contracts/modules.md`
+    *   **`@UX_FEEDBACK`**: Define visible system reactions for success, validation, and failure
+    *   **`@UX_RECOVERY`**: Define what the user can do after failure or degraded state
+    *   **`@UX_REACTIVITY`**: Note expected Svelte rune bindings with `$state`, `$derived`, `$effect`, `$props`
 *   **States**:
-    *   **Default**: Clean state, waiting for input.
+    *   **Idle/Default**: Clean state, waiting for input.
     *   **Loading**: Skeleton loader replaces content area.
-    *   **Success**: Toast notification appears top-right: "Saved!" (Green).
+    *   **Success**: Toast notification appears top-right and state is recoverable without reload.
+    *   **Error/Degraded**: Visible failure state with explicit recovery path.
 
 ## 4. The "Error" Experience
 
 **Philosophy**: Don't just report the error; guide the user to the fix.
 
+**Semantic Requirement**: Every documented failure path here should map to `@UX_RECOVERY` and, where relevant, `@UX_FEEDBACK` in the generated component contracts.
+
 ### Scenario A: [Common Error, e.g. Invalid Input]
 
 *   **User Action**: Enters "123" in a text-only field.