agents

.opencode/command/speckit.implement.md

@@ -1,5 +1,5 @@
 ---
-description: Execute the implementation plan by processing the active tasks.md for the Python/Svelte repository.
+description: Execute the implementation plan by processing the active tasks.md for the ss-tools repository (Python backend + Svelte frontend).
 handoffs:
   - label: Audit & Verify (Tester)
     agent: qa-tester
@@ -32,45 +32,41 @@ You **MUST** consider the user input before proceeding (if not empty).
    - `research.md`, `data-model.md`, `quickstart.md` when present
    - `.specify/memory/constitution.md`
    - `README.md`
-   - `docs/SEMANTIC_PROTOCOL_COMPLIANCE.md`
    - relevant `docs/adr/*.md`
 4. Parse tasks by phase, dependencies, story ownership, and guardrails.
 5. Execute implementation phase-by-phase with strict semantic and verification discipline.
 
 ## Repository Reality Rules
 
-- Default source paths are `backend/src/**/*.py`, `frontend/src/**/*.svelte`, `backend/tests/`, and `frontend/tests/`.
+- Source paths: `backend/src/**/*.py` and `frontend/src/**/*.svelte`.
 - Active feature docs always live under `specs/<feature>/...` and are discovered via the `.specify/scripts/bash/*` helpers.
-- Default verification stack is Python/Svelte-native and repository-real:
-  - `cd backend && pytest` (backend tests)
-  - `cd frontend && npm run test` (frontend vitest)
-  - `ruff check backend/` (Python linting)
-  - `cd frontend && npm run build` (Svelte build check)
-  - `python3 scripts/static_verify.py` (semantic static verification when available)
-- Do not fall back to `cargo`, `cargo test`, `cargo clippy`, `src/**/*.rs`, or Rust/MCP conventions unless the active feature genuinely introduces such a surface.
+- Default verification stack:
+  - Backend: `cd backend && source .venv/bin/activate && python -m pytest -v`
+  - Backend lint: `python -m ruff check backend/src/ backend/tests/`
+  - Frontend: `cd frontend && npm run test`
+  - Frontend build: `cd frontend && npm run build`
+- Do not fall back to Rust `cargo`/`src/server/` conventions — this is a Python/Svelte project.
 
 ## Semantic Execution Rules
 
-- Preserve and extend canonical `[DEF]` anchors and metadata.
-- Use correct comment-anchor syntax: `# [DEF:...]` for Python, `<!-- [DEF:...] -->` for Svelte markup, `// [DEF:...]` for Svelte script blocks.
+- Preserve and extend canonical anchor regions.
 - Match contract density to effective complexity.
 - Keep accepted-path and rejected-path memory intact.
 - Do not silently restore an ADR- or contract-rejected branch.
-- For C4/C5 Python orchestration flows, account for the belief runtime where required by repository norms and local contracts.
-- For C4/C5 Svelte components, ensure `@UX_STATE`, `@UX_FEEDBACK`, `@UX_RECOVERY`, `@UX_REACTIVITY` tags are satisfied.
+- For C4/C5 Python orchestration flows, account for the belief runtime (JSON structured logging via `reason()`, `reflect()`, `explore()`).
+- For C4/C5 Svelte components, account for belief runtime (console markers `[ComponentID][MARKER]`).
 - Treat pseudo-semantic markup as invalid.
 
 ## Progress and Acceptance
 
 - Mark tasks complete only after local verification succeeds.
 - Handoff to the tester must include touched files, declared complexity, contract expectations, ADR guardrails, and executed verifiers.
-- Final acceptance requires explicit evidence that the `speckit.test` workflow-equivalent verification was executed.
+- Final acceptance requires explicit evidence that verification was executed.
 - `.kilo/plans/*` may exist as internal assistant scratch context, but it is not part of the speckit feature output surface and must not replace `specs/<feature>/...` artifacts.
 
 ## Completion Gate
 
 No task batch is complete if any of the following remain in the touched scope:
-
 - broken or unclosed anchors
 - missing complexity-required metadata
 - unresolved critical contract gaps