6.8 KiB
description
| description |
|---|
| Task list template for feature implementation |
Tasks: [FEATURE NAME]
Input: Design documents from /specs/[###-feature-name]/
Prerequisites: plan.md (required), spec.md (required), research.md, data-model.md, contracts/, quickstart.md
Validation: Validation and evidence tasks are NOT optional. Every feature task set MUST include the applicable document validation, code validation, ledger-sync, and final-verdict tasks.
Organization: Tasks are grouped by user story so each slice can be completed, reviewed, and validated independently.
Format: [ID] [P?] [Story] Description
- [P]: Can run in parallel (different files, no dependencies)
- [Story]: Which user story this task belongs to (e.g., US1, US2, US3)
- Include exact file paths in descriptions
Path Conventions
- Formal workflow:
water-docs/ - Main documents:
docs/design/01_Overview/,docs/design/02_Detailed_Design/,docs/design/03_Technical_Design/ - Governance documents:
docs/design/00_Management/ - Feature artifacts:
specs/[###-feature]/ - Backend modules:
water-backend/... - Frontend modules:
water-frontend/...
Phase 1: Scope, Baseline & Source Confirmation
Purpose: Confirm the source-of-truth set, repo boundary, and code baselines before editing anything.
- T001 Confirm target documents, target repos, and exact chapters from
specs/[###-feature]/spec.md - T002 Confirm governing source-of-truth documents and allowed references from
specs/[###-feature]/plan.md - T003 [P] Record backend/frontend code baseline references in
specs/[###-feature]/plan.mdorspecs/[###-feature]/verification.md - T004 [P] Identify cross-document and cross-repo impacts: terminology, numbering, diagrams, links, contracts, ledger updates
Phase 2: Shared Foundation
Purpose: Establish the shared alignment baseline for docs, code evidence, and verification outputs.
- T005 Normalize key terms, interface IDs, module IDs, and state vocabulary in
specs/[###-feature]/plan.md - T006 Confirm the final validation command set in
specs/[###-feature]/quickstart.md - T007 Prepare verification output targets in
specs/[###-feature]/verification.mdorspecs/[###-feature]/final-verdict.md
Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP
Goal: [Brief description of the first independently reviewable outcome]
Independent Test: [How to verify this story on its own]
Implementation for User Story 1
- T008 [US1] Update target formal document in
water-docs/docs/design/... - T009 [US1] Sync impacted references, anchors, numbering, glossary terms, or contracts in
water-docs/... - T010 [US1] If required, inspect or update matching backend scope in
water-backend/... - T011 [US1] If required, inspect or update matching frontend scope in
water-frontend/... - T012 [US1] Run story-specific document validation and capture result in
specs/[###-feature]/quickstart.md - T013 [US1] Run story-specific code validation or evidence capture and record result in
specs/[###-feature]/verification.md
Checkpoint: User Story 1 is independently reviewable with both document and implementation evidence aligned.
Phase 4: User Story 2 - [Title] (Priority: P2)
Goal: [Brief description of the second independently reviewable outcome]
Independent Test: [How to verify this story on its own]
Implementation for User Story 2
- T014 [US2] Update target formal document in
water-docs/docs/design/... - T015 [US2] Sync affected references, diagrams, or traceability entries in
water-docs/... - T016 [US2] If required, inspect or update matching backend scope in
water-backend/... - T017 [US2] If required, inspect or update matching frontend scope in
water-frontend/... - T018 [US2] Run story-specific validation and capture result in
specs/[###-feature]/quickstart.md - T019 [US2] Record backend/frontend evidence or outcome in
specs/[###-feature]/verification.md
Checkpoint: User Story 2 is independently reviewable and validated.
Phase 5: User Story 3 - [Title] (Priority: P3)
Goal: [Brief description of the third independently reviewable outcome]
Independent Test: [How to verify this story on its own]
Implementation for User Story 3
- T020 [US3] Update target formal document or governance file in
water-docs/docs/design/... - T021 [US3] Sync affected supporting docs, contracts, or guidance files in
water-docs/... - T022 [US3] If required, inspect or update matching backend/frontend scope in
water-backend/...orwater-frontend/... - T023 [US3] Run story-specific validation and capture result in
specs/[###-feature]/quickstart.md - T024 [US3] Update
docs/design/00_Management/01_Project_Progress.mdanddocs/design/00_Management/03_Task_Checklist.mdif applicable
Checkpoint: All planned updates are independently reviewable and validated.
Final Phase: Verification & Closure
Purpose: Ensure repository-wide consistency, baseline traceability, and final verdict output.
- T025 [P] Re-check source-of-truth alignment across all modified files and touched repos
- T026 [P] Re-check relative links, stable anchors, and Mermaid consistency across all modified formal docs
- T027 [P] Re-check backend/frontend baseline SHAs and validation outputs in
specs/[###-feature]/verification.md - T028 Prepare final summary and verdict in
specs/[###-feature]/final-verdict.mdorspecs/[###-feature]/verification.md
Dependencies & Execution Order
Phase Dependencies
- Scope, Baseline & Source Confirmation: No dependencies; MUST finish before edits
- Shared Foundation: Depends on Phase 1 and MUST finish before story execution
- User Stories: Depend on confirmed scope, baseline, and validation plan
- Final Phase: Depends on all selected user stories being complete
Within Each User Story
- Update formal docs before syncing impacted support files
- Complete content edits before validation
- Complete validation before ledger updates are marked done
- Record backend/frontend evidence before final verdict
Parallel Opportunities
- Scope analysis tasks marked [P] can run in parallel
- Backend and frontend inspection tasks can run in parallel when they touch different repos
- Validation tasks for different files or repos can run in parallel when commands are independent
Notes
- Every task set MUST preserve the single-source-of-truth model in
water-docs - Archive is for verification and traceability, not direct formal output replacement
- backend/frontend do not own the official spec; they consume and evidence it
- Do not omit validation, evidence, or ledger tasks when they apply
- Avoid vague tasks; every task should name the file path, repo, and expected outcome