75 lines
3.1 KiB
Markdown
75 lines
3.1 KiB
Markdown
---
|
|
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
|
|
prompt: Perform semantic audit, executable verification, and contract checks for the completed task batch.
|
|
send: true
|
|
- label: Orchestration Control
|
|
agent: swarm-master
|
|
prompt: Review tester feedback and coordinate next steps.
|
|
send: true
|
|
---
|
|
|
|
## User Input
|
|
|
|
```text
|
|
$ARGUMENTS
|
|
```
|
|
|
|
You **MUST** consider the user input before proceeding (if not empty).
|
|
|
|
## Outline
|
|
|
|
1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` and locate the active feature artifacts.
|
|
2. If `checklists/` exists, evaluate checklist completion status before implementation proceeds.
|
|
3. Load implementation context from:
|
|
- `tasks.md`
|
|
- `plan.md`
|
|
- `spec.md`
|
|
- `ux_reference.md`
|
|
- `contracts/modules.md` when present
|
|
- `research.md`, `data-model.md`, `quickstart.md` when present
|
|
- `.specify/memory/constitution.md`
|
|
- `README.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
|
|
|
|
- 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:
|
|
- 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 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 (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 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
|
|
- rejected-path regression
|
|
- required verification not executed
|