ss-tools/speckit.tasks.md at a7fb06cd8edaeb525562ac48cbf6e9105d46b9bf

busya/ss-tools

Fork 0

Files

busya a7fb06cd8e tasks ready 1

2026-06-09 09:43:34 +03:00

8.7 KiB

Raw Blame History

description, handoffs

description

handoffs

Generate an actionable, dependency-ordered tasks.md for the active ss-tools feature (Python backend + Svelte frontend).

label	agent	prompt	send
Analyze For Consistency	speckit.analyze	Run a cross-artifact consistency analysis for the feature	true

label	agent	prompt	send
Implement Project	speckit.implement	Start implementation in phases for the feature	true

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Outline

Setup: Run .specify/scripts/bash/check-prerequisites.sh --json from repo root and parse FEATURE_DIR and AVAILABLE_DOCS.
- FEATURE_DIR under specs/<feature>/ is the only valid output location for tasks.md.
Load design documents from FEATURE_DIR:
- Required: plan.md, spec.md, ux_reference.md
- Optional: data-model.md, contracts/, research.md, quickstart.md
- Required when referenced by plan: ADR artifacts under docs/adr/ or feature-local planning docs
Build the task model:
- Extract user stories and priorities from spec.md
- Extract repository structure, tool/resource scope, verification stack, and semantic constraints from plan.md
- Extract accepted-path and rejected-path memory from ADRs and contracts/modules.md
- Map entities to stories
- Generate tasks grouped by story and ordered by dependency
- Validate that no task schedules an ADR-rejected path
Generate tasks.md using .specify/templates/tasks-template.md as the structure:
- Phase 1: Setup
- Phase 2: Foundational work
- Phase 3+: one phase per user story in priority order
- Final phase: polish and cross-cutting verification
- Every task must use the strict checklist format and include exact file paths
- Write the final document to FEATURE_DIR/tasks.md, never to .kilo/plans/ or other side folders
Report the generated path and summarize:
- total task count
- task count per user story
- parallel opportunities
- story-level independent verification criteria
- inherited ADR/guardrail coverage

Task Generation Rules

Story Organization

Tasks MUST be grouped by user story so each story can be implemented and verified independently.

Required Format

Every task MUST follow:

- [ ] T001 [P] [US1] Description with exact file path

Rules:

- [ ] checkbox is mandatory
sequential task IDs (T001, T002, ...)
[P] only for truly parallelizable tasks
[USx] required only for user-story phases
exact file paths required in the description

ss-tools Pathing

Prefer real repository paths such as:

backend/src/api/*.py (FastAPI routes)
backend/src/core/**/*.py (business logic, plugins)
backend/src/models/*.py (SQLAlchemy models)
backend/src/services/*.py (service layer)
backend/src/schemas/*.py (Pydantic schemas)
backend/tests/*.py (pytest)
frontend/src/routes/**/*.svelte (SvelteKit pages)
frontend/src/lib/components/*.svelte (UI components)
frontend/src/lib/stores/*.js (Svelte stores)
frontend/src/lib/api/*.js (API client)
frontend/src/lib/**/__tests__/*.test.js (vitest)
docs/adr/*.md (architecture decisions)
specs/<feature>/contracts/*.md (design contracts)

Do NOT generate default tasks for Rust/MCP paths (src/server/, *.rs, cargo).

Verification Discipline

Each story phase must end with:

a verification task against ux_reference.md interpreted as the operator/caller interaction contract
a semantic audit / verification task tied to repository validators and touched contracts

Typical verification tasks may include:

cd backend && source .venv/bin/activate && python -m pytest backend/tests/test_*.py -v
cd backend && python -m ruff check .
cd frontend && npm run lint
cd frontend && npm run test
cd frontend && npm run build

Only include the commands that are truly required by the feature scope.

Contract and ADR Propagation

If a task implements a function with a pre-generated contract in contracts/modules.md, inline the contract's key execution constraints directly into the task description. This eliminates cross-file navigation — the implementing agent sees the contract in the task.

Function contract inlining format (C3+):

- [ ] T017 [US1] Implement Core.Auth.Login in backend/src/services/auth_service.py
      @PRE: credentials valid, DB connected
      @POST: AuthResponse(access_token, refresh_token, user_id)
      @DATA_CONTRACT: LoginRequest → AuthResponse
      @TEST_EDGE: invalid_credentials→401, locked_account→423, missing_fields→422

- [ ] T018 [US1] Implement UserListModel.search in frontend/src/lib/models/UserListModel.svelte.ts
      @ACTION search(query): full-text, resets pagination
      @POST: page=1, screenState="loading"
      @SIDE_EFFECT: GET /api/users?q={query}
      @TEST_EDGE: empty_query→screenState="idle", network_fail→screenState="error"

Rules:

Only inline for C3+ functions with pre-generated contracts in contracts/modules.md.
C1/C2 functions do NOT get inlined constraints — their task is just the file path.
Inline ALL @PRE, @POST, @SIDE_EFFECT, @DATA_CONTRACT, @TEST_EDGE from the contract.
Keep each constraint on one comma-separated line for CSA 4× density.
@TEST_EDGE format: scenario→outcome (compact, survives pooling).
Task still uses the standard checkbox format on the first line.

ADR guardrail format (decision memory only):

If a task depends on a guarded decision but has no function contract, append only @RATIONALE/@REJECTED:

- [ ] T021 [US1] Implement dashboard migration in backend/src/core/migration/service.py
      RATIONALE: full scan ensures consistency
      REJECTED: incremental-only update leaves stale entries

Component Reuse Mandate

Every frontend task MUST reference existing components from the design system before creating new ones. The component inventory from contracts/modules.md (populated during /speckit.plan) drives task generation:

Reuse Level	Task Wording Rule
Existing component (e.g. `<Button>`)	Task says: "...using `<Button>` from `$lib/ui/Button.svelte` (existing)"
Existing pattern (e.g. badge, skeleton)	Task says: "...inline Tailwind: `rounded-full px-2.5 py-0.5 text-xs font-medium bg-{color}-100` (matches DashboardHub badge convention)"
New component required	Task says: "Implement new `ComponentName.svelte`" — only when inventory confirms no reusable asset

Before writing any frontend task, verify: does an existing component or page already do this? If contracts/modules.md maps a @RELATION DEPENDS_ON -> [ExistingComponent], the task MUST use it. Never schedule "build a custom dropdown" when <Select> exists; never schedule "create a toast system" when addToast() is wired.

Test Tasks

Tests are optional only when the feature truly has no new verification surface. Test tasks are usually expected for:

new API endpoints
new database models or queries
C4/C5 semantic contracts
runtime evidence / belief-state behavior
rejected-path regression coverage

Decision-Memory Validation Gate

Before finalizing tasks.md, verify that:

blocking ADRs are inherited into setup/foundational or downstream story tasks
no task text schedules a rejected path
story tasks remain executable within the actual Python/Svelte project structure
at least one explicit verification task protects against rejected-path regression

Fixture Materialization Tasks

If /speckit.plan generated canonical fixtures in specs/<feature>/fixtures/, create materialization tasks that copy them into the repo-native test directories before writing test code:

Backend fixtures:

- [ ] TXXX [P] [US1] Materialize fixtures from specs/<feature>/fixtures/api/ into backend/tests/fixtures/<domain>/
      Source: fixtures/api/auth_login_*.json
      Target: backend/tests/fixtures/auth/
      Each fixture → one JSON file. Do NOT modify fixture content — copy as-is.

Frontend fixtures:

- [ ] TXXX [P] [US1] Materialize fixtures from specs/<feature>/fixtures/model/ into frontend/src/lib/models/__fixtures__/<model>/
      Source: fixtures/model/migration_*.json
      Target: frontend/src/lib/models/__fixtures__/migration/