11 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 for user stories), research.md, data-model.md, contracts/
Tests: The examples below include test tasks. Tests are OPTIONAL - only include them if explicitly requested in the feature specification.
Organization: Tasks are grouped by user story to enable independent implementation and testing of each story.
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
- Single project:
src/,tests/at repository root - Web app:
backend/src/,frontend/src/ - Mobile:
api/src/,ios/src/orandroid/src/ - Paths shown below assume single project - adjust based on plan.md structure
Phase 1: Setup (Shared Infrastructure)
Purpose: Project initialization and basic structure
- T001 Create project structure per implementation plan (internal/, pkg/, cmd/)
- T002 Initialize Go project with Fiber + GORM + Viper + Zap + Asynq dependencies
- T003 [P] Configure linting (golangci-lint) and formatting tools (gofmt/goimports)
- T004 [P] Setup unified error codes in pkg/errors/
- T005 [P] Setup unified API response in pkg/response/
Phase 2: Foundational (Blocking Prerequisites)
Purpose: Core infrastructure that MUST be complete before ANY user story can be implemented
⚠️ CRITICAL: No user story work can begin until this phase is complete
Foundational tasks for 君鸿卡管系统 tech stack:
- T006 Setup PostgreSQL database connection via GORM with connection pool (MaxOpenConns=25, MaxIdleConns=10)
- T007 Setup Redis connection with connection pool (PoolSize=10, MinIdleConns=5)
- T008 [P] Setup database migrations framework (golang-migrate or GORM AutoMigrate)
- T009 [P] Implement Fiber routing structure in internal/router/
- T010 [P] Implement Fiber middleware (authentication, logging, recovery, validation) in internal/handler/middleware/
- T011 [P] Setup Zap logger with Lumberjack rotation in pkg/logger/
- T012 [P] Setup Viper configuration management in pkg/config/
- T013 [P] Setup Asynq task queue client and server in pkg/queue/
- T014 [P] Setup Validator integration in pkg/validator/
- T015 Create base Store structure with transaction support in internal/store/
- T016 Create base Service structure with dependency injection in internal/service/
- T017 Setup sonic JSON as default serializer for Fiber
Checkpoint: Foundation ready - user story implementation can now begin in parallel
Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP
Goal: [Brief description of what this story delivers]
Independent Test: [How to verify this story works on its own]
Tests for User Story 1 (REQUIRED per Constitution - Testing Standards) ⚠️
NOTE: Write these tests FIRST, ensure they FAIL before implementation
- T020 [P] [US1] Unit tests for Service layer business logic in internal/service/[service]_test.go
- T021 [P] [US1] Integration tests for API endpoints in internal/handler/[handler]_test.go
- T022 [P] [US1] Transaction rollback tests for Store layer in internal/store/[store]_test.go
Implementation for User Story 1
- T023 [P] [US1] Create [Entity1] model with GORM tags in internal/model/[entity1].go
- T024 [P] [US1] Create [Entity2] model with GORM tags in internal/model/[entity2].go
- T025 [P] [US1] Create DTOs and request/response structs in internal/model/dto/[feature].go
- T026 [US1] Implement Store methods with GORM in internal/store/postgres/[store].go (depends on T023, T024)
- T027 [US1] Implement Service business logic in internal/service/[service].go (depends on T026)
- T028 [US1] Implement Fiber Handler in internal/handler/[handler].go (depends on T027)
- T029 [US1] Register routes in internal/router/router.go
- T030 [US1] Add validation rules using Validator in Handler
- T031 [US1] Add unified error handling using pkg/errors/ and pkg/response/
- T032 [US1] Add Zap logging with structured fields
- T033 [US1] Add database indexes for queries (if needed)
- T034 [US1] Create Asynq tasks for async operations (if needed) in internal/task/[task].go
Checkpoint: At this point, User Story 1 should be fully functional and testable independently
Phase 4: User Story 2 - [Title] (Priority: P2)
Goal: [Brief description of what this story delivers]
Independent Test: [How to verify this story works on its own]
Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️
- T018 [P] [US2] Contract test for [endpoint] in tests/contract/test_[name].py
- T019 [P] [US2] Integration test for [user journey] in tests/integration/test_[name].py
Implementation for User Story 2
- T020 [P] [US2] Create [Entity] model in src/models/[entity].py
- T021 [US2] Implement [Service] in src/services/[service].py
- T022 [US2] Implement [endpoint/feature] in src/[location]/[file].py
- T023 [US2] Integrate with User Story 1 components (if needed)
Checkpoint: At this point, User Stories 1 AND 2 should both work independently
Phase 5: User Story 3 - [Title] (Priority: P3)
Goal: [Brief description of what this story delivers]
Independent Test: [How to verify this story works on its own]
Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️
- T024 [P] [US3] Contract test for [endpoint] in tests/contract/test_[name].py
- T025 [P] [US3] Integration test for [user journey] in tests/integration/test_[name].py
Implementation for User Story 3
- T026 [P] [US3] Create [Entity] model in src/models/[entity].py
- T027 [US3] Implement [Service] in src/services/[service].py
- T028 [US3] Implement [endpoint/feature] in src/[location]/[file].py
Checkpoint: All user stories should now be independently functional
[Add more user story phases as needed, following the same pattern]
Phase N: Polish & Quality Gates
Purpose: Improvements that affect multiple user stories and final quality checks
- TXXX [P] Documentation updates in docs/
- TXXX Code cleanup and refactoring
- TXXX Performance optimization and load testing (verify P95 < 200ms, P99 < 500ms)
- TXXX [P] Additional unit tests to reach 70%+ coverage (90%+ for core business)
- TXXX Security audit (SQL injection, XSS, command injection prevention)
- TXXX Run quickstart.md validation
- TXXX Quality Gate: Run
go test ./...(all tests pass) - TXXX Quality Gate: Run
gofmt -l .(no formatting issues) - TXXX Quality Gate: Run
go vet ./...(no issues) - TXXX Quality Gate: Run
golangci-lint run(no issues) - TXXX Quality Gate: Verify test coverage with
go test -cover ./... - TXXX Quality Gate: Check no TODO/FIXME remains (or documented in issues)
- TXXX Quality Gate: Verify database migrations work correctly
- TXXX Quality Gate: Verify API documentation updated (if API changes)
Dependencies & Execution Order
Phase Dependencies
- Setup (Phase 1): No dependencies - can start immediately
- Foundational (Phase 2): Depends on Setup completion - BLOCKS all user stories
- User Stories (Phase 3+): All depend on Foundational phase completion
- User stories can then proceed in parallel (if staffed)
- Or sequentially in priority order (P1 → P2 → P3)
- Polish (Final Phase): Depends on all desired user stories being complete
User Story Dependencies
- User Story 1 (P1): Can start after Foundational (Phase 2) - No dependencies on other stories
- User Story 2 (P2): Can start after Foundational (Phase 2) - May integrate with US1 but should be independently testable
- User Story 3 (P3): Can start after Foundational (Phase 2) - May integrate with US1/US2 but should be independently testable
Within Each User Story
- Tests (if included) MUST be written and FAIL before implementation
- Models before services
- Services before endpoints
- Core implementation before integration
- Story complete before moving to next priority
Parallel Opportunities
- All Setup tasks marked [P] can run in parallel
- All Foundational tasks marked [P] can run in parallel (within Phase 2)
- Once Foundational phase completes, all user stories can start in parallel (if team capacity allows)
- All tests for a user story marked [P] can run in parallel
- Models within a story marked [P] can run in parallel
- Different user stories can be worked on in parallel by different team members
Parallel Example: User Story 1
# Launch all tests for User Story 1 together (if tests requested):
Task: "Contract test for [endpoint] in tests/contract/test_[name].py"
Task: "Integration test for [user journey] in tests/integration/test_[name].py"
# Launch all models for User Story 1 together:
Task: "Create [Entity1] model in src/models/[entity1].py"
Task: "Create [Entity2] model in src/models/[entity2].py"
Implementation Strategy
MVP First (User Story 1 Only)
- Complete Phase 1: Setup
- Complete Phase 2: Foundational (CRITICAL - blocks all stories)
- Complete Phase 3: User Story 1
- STOP and VALIDATE: Test User Story 1 independently
- Deploy/demo if ready
Incremental Delivery
- Complete Setup + Foundational → Foundation ready
- Add User Story 1 → Test independently → Deploy/Demo (MVP!)
- Add User Story 2 → Test independently → Deploy/Demo
- Add User Story 3 → Test independently → Deploy/Demo
- Each story adds value without breaking previous stories
Parallel Team Strategy
With multiple developers:
- Team completes Setup + Foundational together
- Once Foundational is done:
- Developer A: User Story 1
- Developer B: User Story 2
- Developer C: User Story 3
- Stories complete and integrate independently
Notes
- [P] tasks = different files, no dependencies
- [Story] label maps task to specific user story for traceability
- Each user story should be independently completable and testable
- Verify tests fail before implementing
- Commit after each task or logical group
- Stop at any checkpoint to validate story independently
- Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence