busya
ec6421de35
- Replace all occurrences of 'ss-tools' with 'superset-tools' in 104 files - Rename git bundle file ss-tools.bundle → superset-tools.bundle - Update .gitignore pattern accordingly - Preserve variable names (hasSsTools etc.) and code identifiers
202 lines
8.7 KiB
Markdown
202 lines
8.7 KiB
Markdown
---
|
||
description: Generate an actionable, dependency-ordered tasks.md for the active superset-tools feature (Python backend + Svelte frontend).
|
||
handoffs:
|
||
- label: Analyze For Consistency
|
||
agent: speckit.analyze
|
||
prompt: Run a cross-artifact consistency analysis for the feature
|
||
send: true
|
||
- label: Implement Project
|
||
agent: speckit.implement
|
||
prompt: Start implementation in phases for the feature
|
||
send: true
|
||
---
|
||
|
||
## User Input
|
||
|
||
```text
|
||
$ARGUMENTS
|
||
```
|
||
|
||
You **MUST** consider the user input before proceeding (if not empty).
|
||
|
||
## Outline
|
||
|
||
1. **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`.
|
||
|
||
2. **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
|
||
|
||
3. **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
|
||
|
||
4. **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
|
||
|
||
5. **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:
|
||
|
||
```text
|
||
- [ ] T001 [P] [US1] Description with exact file path
|
||
```
|
||
|
||
Rules:
|
||
1. `- [ ]` checkbox is mandatory
|
||
2. sequential task IDs (`T001`, `T002`, ...)
|
||
3. `[P]` only for truly parallelizable tasks
|
||
4. `[USx]` required only for user-story phases
|
||
5. exact file paths required in the description
|
||
|
||
### superset-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+):**
|
||
|
||
```text
|
||
- [ ] 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`:
|
||
|
||
```text
|
||
- [ ] 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:**
|
||
```text
|
||
- [ ] 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:**
|
||
```text
|
||
- [ ] 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/
|
||
```
|
||
|
||
**Rules:**
|
||
- Materialization tasks are [P] (parallel, different directories)
|
||
- Materialize BEFORE test-writing tasks — tests import fixtures
|
||
- Fixtures are copied as-is from canonical source — no adaptation at this stage
|
||
- If canonical fixture shape doesn't match test framework expectations, create a separate adapter task
|
||
- Every fixture in `manifest.md` gets exactly one materialization task
|