Таски готовы

.kilocode/rules/specify-rules.md

@@ -51,6 +51,10 @@ Auto-generated from all feature plans. Last updated: 2025-12-19
 - Existing auth database (`AUTH_DATABASE_URL`) with a dedicated per-user preference entity (024-user-dashboard-filter)
 - Python 3.9+ (Backend), Node.js 18+ / Svelte 5.x (Frontend) + FastAPI, SQLAlchemy, APScheduler (Backend) | SvelteKit, Tailwind CSS, existing UI components (Frontend) (026-dashboard-health-windows)
 - PostgreSQL / SQLite (existing database for `ValidationRecord` and new `ValidationPolicy`) (026-dashboard-health-windows)
+- Python 3.9+ backend, Node.js 18+ frontend with Svelte 5 / SvelteKit + FastAPI, SQLAlchemy, Pydantic, existing [SupersetClient](../../backend/src/core/superset_client.py), existing frontend API wrapper patterns, Svelte runes, existing task/websocket stack (027-dataset-llm-orchestration)
+- Existing application databases plus filesystem-backed uploaded semantic sources; reuse current configuration and task persistence stores (027-dataset-llm-orchestration)
+- Python 3.9+ backend, Node.js 18+ frontend, Svelte 5 / SvelteKit frontend runtime + FastAPI, SQLAlchemy, Pydantic, existing `TaskManager`, existing `SupersetClient`, existing LLM provider stack, SvelteKit, Tailwind CSS, frontend `requestApi`/`fetchApi` wrappers (027-dataset-llm-orchestration)
+- Existing application databases for persistent session/domain entities; existing tasks database for async execution metadata; filesystem for optional uploaded semantic sources/artifacts (027-dataset-llm-orchestration)
 
 - Python 3.9+ (Backend), Node.js 18+ (Frontend Build) (001-plugin-arch-svelte-ui)
 
@@ -71,9 +75,9 @@ cd src; pytest; ruff check .
 Python 3.9+ (Backend), Node.js 18+ (Frontend Build): Follow standard conventions
 
 ## Recent Changes
+- 027-dataset-llm-orchestration: Added Python 3.9+ backend, Node.js 18+ frontend, Svelte 5 / SvelteKit frontend runtime + FastAPI, SQLAlchemy, Pydantic, existing `TaskManager`, existing `SupersetClient`, existing LLM provider stack, SvelteKit, Tailwind CSS, frontend `requestApi`/`fetchApi` wrappers
+- 027-dataset-llm-orchestration: Added Python 3.9+ backend, Node.js 18+ frontend with Svelte 5 / SvelteKit + FastAPI, SQLAlchemy, Pydantic, existing [SupersetClient](../../backend/src/core/superset_client.py), existing frontend API wrapper patterns, Svelte runes, existing task/websocket stack
 - 026-dashboard-health-windows: Added Python 3.9+ (Backend), Node.js 18+ / Svelte 5.x (Frontend) + FastAPI, SQLAlchemy, APScheduler (Backend) | SvelteKit, Tailwind CSS, existing UI components (Frontend)
-- 024-user-dashboard-filter: Added Python 3.9+ (backend), Node.js 18+ + SvelteKit (frontend) + FastAPI, SQLAlchemy, Pydantic, existing auth stack (`get_current_user`), existing dashboards route/service, Svelte runes (`$state`, `$derived`, `$effect`), Tailwind CSS, frontend `api` wrapper
-- 020-clean-repo-enterprise: Added Python 3.9+ (backend scripts/services), Shell (release tooling) + FastAPI stack (existing backend), ConfigManager, TaskManager, файловые утилиты, internal artifact registries
 
 
 <!-- MANUAL ADDITIONS START -->

.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.

.kilocode/workflows/speckit.plan.md

@@ -73,13 +73,23 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Entity name, fields, relationships, validation rules.
 
 2. **Design & Verify Contracts (Semantic Protocol)**:
-   - **Drafting**: Define `[DEF:id:Type]` Headers, Contracts, and closing `[/DEF:id:Type]` for all new modules based on `.ai/standards/semantics.md`.
-   - **TIER Classification**: Explicitly assign `@TIER: [CRITICAL|STANDARD|TRIVIAL]` to each module.
-   - **CRITICAL Requirements**: For all CRITICAL modules, define full `@PRE`, `@POST`, and (if UI) `@UX_STATE` contracts. **MUST** also define testing contracts: `@TEST_CONTRACT`, `@TEST_FIXTURE`, `@TEST_EDGE`, and `@TEST_INVARIANT`.
+   - **Drafting**: Define semantic headers, metadata, and closing anchors for all new modules strictly from `.ai/standards/semantics.md`.
+   - **Complexity Classification**: Classify each contract with `@COMPLEXITY: [1|2|3|4|5]` or `@C:`. Treat `@TIER` only as a legacy compatibility hint and never as the primary rule source.
+   - **Adaptive Contract Requirements**:
+     - **Complexity 1**: anchors only; `@PURPOSE` optional.
+     - **Complexity 2**: require `@PURPOSE`.
+     - **Complexity 3**: require `@PURPOSE` and `@RELATION`; UI also requires `@UX_STATE`.
+     - **Complexity 4**: require `@PURPOSE`, `@RELATION`, `@PRE`, `@POST`, `@SIDE_EFFECT`; Python modules must define a meaningful `logger.reason()` / `logger.reflect()` path or equivalent belief-state mechanism.
+     - **Complexity 5**: require full level-4 contract plus `@DATA_CONTRACT` and `@INVARIANT`; Python modules must require `belief_scope`; UI modules must define UX contracts including `@UX_STATE`, `@UX_FEEDBACK`, `@UX_RECOVERY`, and `@UX_REACTIVITY`.
+   - **Relation Syntax**: Write dependency edges in canonical GraphRAG form: `@RELATION: [PREDICATE] ->[TARGET_ID]`.
+   - **Context Guard**: If a target relation, DTO, or required dependency cannot be named confidently, stop generation and emit `[NEED_CONTEXT: target]` instead of inventing placeholders.
+   - **Testing Contracts**: Add `@TEST_CONTRACT`, `@TEST_SCENARIO`, `@TEST_FIXTURE`, `@TEST_EDGE`, and `@TEST_INVARIANT` when the design introduces audit-critical or explicitly test-governed contracts, especially for Complexity 5 boundaries.
    - **Self-Review**:
-     - *Completeness*: Do `@PRE`/`@POST` cover edge cases identified in Research? Are test contracts present for CRITICAL?
-     - *Connectivity*: Do `@RELATION` tags form a coherent graph?
-     - *Compliance*: Does syntax match `[DEF:id:Type]` exactly and is it closed with `[/DEF:id:Type]`?
+     - *Complexity Fit*: Does each contract include exactly the metadata and contract density required by its complexity level?
+     - *Completeness*: Do `@PRE`/`@POST`, `@SIDE_EFFECT`, `@DATA_CONTRACT`, and UX tags cover the edge cases identified in Research and UX Reference?
+     - *Connectivity*: Do `@RELATION` tags form a coherent graph using canonical `@RELATION: [PREDICATE] ->[TARGET_ID]` syntax?
+     - *Compliance*: Are all anchors properly opened and closed, and does the chosen comment syntax match the target medium?
+     - *Belief-State Requirements*: Do Complexity 4/5 Python modules explicitly account for `logger.reason()`, `logger.reflect()`, and `belief_scope` requirements?
    - **Output**: Write verified contracts to `contracts/modules.md`.
 
 3. **Simulate Contract Usage**:

.kilocode/workflows/speckit.tasks.md

@@ -70,11 +70,12 @@ The tasks.md should be immediately executable - each task must be specific enoug
 
 **Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.
 
-### UX Preservation (CRITICAL)
+### UX & Semantic Preservation (CRITICAL)
 
-- **Source of Truth**: `ux_reference.md` is the absolute standard for the "feel" of the feature.
-- **Violation Warning**: If any task would inherently violate the UX (e.g. "Remove progress bar to simplify code"), you **MUST** flag this to the user immediately.
-- **Verification Task**: You **MUST** add a specific task at the end of each User Story phase: `- [ ] Txxx [USx] Verify implementation matches ux_reference.md (Happy Path & Errors)`
+- **Source of Truth**: `ux_reference.md` for UX, `.ai/standards/semantics.md` for Code.
+- **Violation Warning**: If any task violates UX or GRACE standards, flag it immediately.
+- **Verification Task (UX)**: Add a task at the end of each Story phase: `- [ ] Txxx [USx] Verify implementation matches ux_reference.md (Happy Path & Errors)`
+- **Verification Task (Audit)**: Add a mandatory audit task at the end of each Story phase: `- [ ] Txxx [USx] Acceptance: Perform semantic audit & algorithm emulation by Tester`
 
 ### Checklist Format (REQUIRED)
 

.kilocode/workflows/speckit.test.md

@@ -14,7 +14,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 ## Goal
 
-Execute full testing cycle: analyze code for testable modules, write tests with proper coverage, maintain test documentation, and ensure no test duplication or deletion.
+Execute semantic audit and full testing cycle: verify contract compliance, emulate logic, ensure maximum coverage, and maintain test quality.
 
 ## Operating Constraints
 
@@ -56,13 +56,24 @@ Create coverage matrix:
 |--------|------|-----------|------|----------------------|
 | ... | ... | ... | ... | ... |
 
-### 4. Write Tests (TDD Approach)
+### 4. Semantic Audit & Logic Emulation (CRITICAL)
+
+Before writing tests, the Tester MUST:
+1. **Run `axiom-core.audit_contracts_tool`**: Identify semantic violations.
+2. **Emulate Algorithm**: Step through the code implementation in mind.
+   - Verify it adheres to the `@PURPOSE` and `@INVARIANT`.
+   - Verify `@PRE` and `@POST` conditions are correctly handled.
+3. **Validation Verdict**:
+   - If audit fails: Emit `[AUDIT_FAIL: reason]` and notify Orchestrator.
+   - If audit passes: Proceed to writing/verifying tests.
+
+### 5. Write Tests (TDD Approach)
 
 For each module requiring tests:
 
-1. **Check existing tests**: Scan `__tests__/` for duplicates
-2. **Read TEST_FIXTURE**: If CRITICAL tier, read @TEST_FIXTURE from semantics header
-3. **Write test**: Follow co-location strategy
+1. **Check existing tests**: Scan `__tests__/` for duplicates.
+2. **Read TEST_FIXTURE**: If CRITICAL tier, read @TEST_FIXTURE from semantics header.
+3. **Write test**: Follow co-location strategy.
    - Python: `src/module/__tests__/test_module.py`
    - Svelte: `src/lib/components/__tests__/test_component.test.js`
 4. **Use mocks**: Use `unittest.mock.MagicMock` for external dependencies