SDD with Spec-Kit

1.txt

# 1. สร้าง project ด้วย Spec-kit เพื่อสร้าง specification ขึ้นมา
$uvx --from git+https://github.com/github/spec-kit.git specify init demo-api

                  ███████╗██████╗ ███████╗ ██████╗██╗███████╗██╗   ██╗                  
                  ██╔════╝██╔══██╗██╔════╝██╔════╝██║██╔════╝╚██╗ ██╔╝                  
                  ███████╗██████╔╝█████╗  ██║     ██║█████╗   ╚████╔╝                   
                  ╚════██║██╔═══╝ ██╔══╝  ██║     ██║██╔══╝    ╚██╔╝                    
                  ███████║██║     ███████╗╚██████╗██║██║        ██║                     
                  ╚══════╝╚═╝     ╚══════╝ ╚═════╝╚═╝╚═╝        ╚═╝                     
                                                                                        
                            Spec-Driven Development Toolkit                             

╭────────────────────────────────╮
│ Specify Project Setup          │
│ Creating new project: demo-api │
╰────────────────────────────────╯

╭───────────────────────────── Choose your AI assistant: ──────────────────────────────╮
│                                                                                      │
│  ▶      copilot: GitHub Copilot                                                      │
│         claude: Claude Code                                                          │
│         gemini: Gemini CLI                                                           │
│                                                                                      │
│         Use ↑/↓ to navigate, Enter to select, Esc to cancel                          │
│                                                                                      │
╰──────────────────────────────────────────────────────────────────────────────────────╯

2.txt

                            Spec-Driven Development Toolkit                             

╭────────────────────────────────╮
│ Specify Project Setup          │
│ Creating new project: demo-api │
╰────────────────────────────────╯

Initialize Specify Project
├── ● Check required tools (ok)
├── ● Select AI assistant (copilot)
├── ● Fetch latest release (release v0.0.20 (22,712 bytes))
├── ● Download template (spec-kit-template-copilot-v0.0.20.zip)
├── ● Extract template
├── ● Archive contents (20 entries)
├── ● Extraction summary (4 top-level items)
├── ● Cleanup
├── ● Initialize git repository (initialized)
└── ● Finalize (project ready)

Project ready.

╭────────────────────────────────────────────── Next steps ───────────────────────────────────────────────╮
│                                                                                                         │
│  1. cd demo-api                                                                                         │
│  2. Open in Visual Studio Code and use /specify, /plan, /tasks commands with GitHub Copilot             │
│  3. Update CONSTITUTION.md with your project's non-negotiable principles                                │
│                                                                                                         │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────╯

plan.txt

# Implementation Plan: Order Management Web Application

**Branch**: `001-build-web-application` | **Date**: September 11, 2025 | **Spec**: [spec.md](./spec.md)
**Input**: Feature specification from `/specs/001-build-web-application/spec.md`

## Execution Flow (/plan command scope)
```
1. Load feature spec from Input path
   → If not found: ERROR "No feature spec at {path}"
2. Fill Technical Context (scan for NEEDS CLARIFICATION)
   → Detect Project Type from context (web=frontend+backend, mobile=app+api)
   → Set Structure Decision based on project type
3. Evaluate Constitution Check section below
   → If violations exist: Document in Complexity Tracking
   → If no justification possible: ERROR "Simplify approach first"
   → Update Progress Tracking: Initial Constitution Check
4. Execute Phase 0 → research.md
   → If NEEDS CLARIFICATION remain: ERROR "Resolve unknowns"
5. Execute Phase 1 → contracts, data-model.md, quickstart.md, agent-specific template file (e.g., `CLAUDE.md` for Claude Code, `.github/copilot-instructions.md` for GitHub Copilot, or `GEMINI.md` for Gemini CLI).
6. Re-evaluate Constitution Check section
   → If new violations: Refactor design, return to Phase 1
   → Update Progress Tracking: Post-Design Constitution Check
7. Plan Phase 2 → Describe task generation approach (DO NOT create tasks.md)
8. STOP - Ready for /tasks command
```

**IMPORTANT**: The /plan command STOPS at step 7. Phases 2-4 are executed by other commands:
- Phase 2: /tasks command creates tasks.md
- Phase 3-4: Implementation execution (manual or via tools)

## Summary
Primary requirement: Web-based order management system for e-commerce shops with search by order ID and paginated display (10 orders per page). Technical approach: Vite + React frontend with minimal dependencies, using vanilla HTML/CSS/JavaScript where possible, backend API for order data management.

## Technical Context
**Language/Version**: JavaScript ES2022, Node.js 18+  
**Primary Dependencies**: Vite (build tool), React 18+ (minimal usage), minimal additional libraries  
**Storage**: RESTful backend API with JSON data format (specific backend storage TBD)  
**Testing**: Vitest for unit/integration tests, React Testing Library for component tests  
**Target Platform**: Modern web browsers (Chrome 90+, Firefox 88+, Safari 14+)
**Project Type**: web - determines frontend + backend structure  
**Performance Goals**: <300ms page load, <100ms search response, 60fps UI interactions  
**Constraints**: Minimal dependencies, prefer vanilla JS/CSS over libraries, progressive enhancement  
**Scale/Scope**: Support 1000+ orders per shop, 10-50 concurrent users, responsive design

**Additional Context from Arguments**: Create web application with Vite and React with minimal number of libraries and use vanilla HTML, CSS, and JavaScript as much as possible

## Constitution Check
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*

**Simplicity**:
- Projects: 2 (frontend, backend) - meets max 3 requirement
- Using framework directly? Yes - Vite and React used directly, no wrapper classes
- Single data model? Yes - Order entity with minimal DTOs for API serialization only
- Avoiding patterns? Yes - direct API calls, no unnecessary Repository/UoW patterns

**Architecture**:
- EVERY feature as library? Yes - order-search, pagination, order-display as separate modules
- Libraries listed: order-api-client (API communication), order-search (search logic), pagination-ui (reusable pagination)
- CLI per library: order-api-client --help, pagination-ui --version --format
- Library docs: llms.txt format planned for each module

**Testing (NON-NEGOTIABLE)**:
- RED-GREEN-Refactor cycle enforced? Yes - tests written before implementation
- Git commits show tests before implementation? Required workflow
- Order: Contract→Integration→E2E→Unit strictly followed? Yes
- Real dependencies used? Yes - actual API endpoints, real browser environment
- Integration tests for: new libraries, API contract changes, shared schemas? Yes
- FORBIDDEN: Implementation before test, skipping RED phase - strictly enforced

**Observability**:
- Structured logging included? Yes - frontend errors logged to browser console and backend
- Frontend logs → backend? Yes - error reporting API endpoint planned
- Error context sufficient? Yes - user actions, order IDs, search terms included

**Versioning**:
- Version number assigned? 1.0.0 (initial implementation)
- BUILD increments on every change? Yes - automated via CI
- Breaking changes handled? Yes - API versioning strategy planned

## Project Structure

### Documentation (this feature)
```
specs/[###-feature]/
├── plan.md              # This file (/plan command output)
├── research.md          # Phase 0 output (/plan command)
├── data-model.md        # Phase 1 output (/plan command)
├── quickstart.md        # Phase 1 output (/plan command)
├── contracts/           # Phase 1 output (/plan command)
└── tasks.md             # Phase 2 output (/tasks command - NOT created by /plan)
```

### Source Code (repository root)
```
# Option 1: Single project (DEFAULT)
src/
├── models/
├── services/
├── cli/
└── lib/

tests/
├── contract/
├── integration/
└── unit/

# Option 2: Web application (when "frontend" + "backend" detected)
backend/
├── src/
│   ├── models/
│   ├── services/
│   └── api/
└── tests/

frontend/
├── src/
│   ├── components/
│   ├── pages/
│   └── services/
└── tests/

# Option 3: Mobile + API (when "iOS/Android" detected)
api/
└── [same as backend above]

ios/ or android/
└── [platform-specific structure]
```

**Structure Decision**: Option 2: Web application (frontend + backend detected) - Vite/React frontend with RESTful API backend

## Phase 0: Outline & Research
1. **Extract unknowns from Technical Context** above:
   - For each NEEDS CLARIFICATION → research task
   - For each dependency → best practices task
   - For each integration → patterns task

2. **Generate and dispatch research agents**:
   ```
   For each unknown in Technical Context:
     Task: "Research {unknown} for {feature context}"
   For each technology choice:
     Task: "Find best practices for {tech} in {domain}"
   ```

3. **Consolidate findings** in `research.md` using format:
   - Decision: [what was chosen]
   - Rationale: [why chosen]
   - Alternatives considered: [what else evaluated]

**Output**: research.md with all NEEDS CLARIFICATION resolved

## Phase 1: Design & Contracts
*Prerequisites: research.md complete*

1. **Extract entities from feature spec** → `data-model.md`:
   - Entity name, fields, relationships
   - Validation rules from requirements
   - State transitions if applicable

2. **Generate API contracts** from functional requirements:
   - For each user action → endpoint
   - Use standard REST/GraphQL patterns
   - Output OpenAPI/GraphQL schema to `/contracts/`

3. **Generate contract tests** from contracts:
   - One test file per endpoint
   - Assert request/response schemas
   - Tests must fail (no implementation yet)

4. **Extract test scenarios** from user stories:
   - Each story → integration test scenario
   - Quickstart test = story validation steps

5. **Update agent file incrementally** (O(1) operation):
   - Run `/scripts/update-agent-context.sh [claude|gemini|copilot]` for your AI assistant
   - If exists: Add only NEW tech from current plan
   - Preserve manual additions between markers
   - Update recent changes (keep last 3)
   - Keep under 150 lines for token efficiency
   - Output to repository root

**Output**: data-model.md, /contracts/*, failing tests, quickstart.md, agent-specific file

## Phase 2: Task Planning Approach
*This section describes what the /tasks command will do - DO NOT execute during /plan*

**Task Generation Strategy**:
- Load `/templates/tasks-template.md` as base
- Generate tasks from Phase 1 design docs (contracts, data model, quickstart)
- Each contract → contract test task [P]
- Each entity → model creation task [P] 
- Each user story → integration test task
- Implementation tasks to make tests pass

**Ordering Strategy**:
- TDD order: Tests before implementation 
- Dependency order: Models before services before UI
- Mark [P] for parallel execution (independent files)

**Estimated Output**: 25-30 numbered, ordered tasks in tasks.md

**IMPORTANT**: This phase is executed by the /tasks command, NOT by /plan

## Phase 3+: Future Implementation
*These phases are beyond the scope of the /plan command*

**Phase 3**: Task execution (/tasks command creates tasks.md)  
**Phase 4**: Implementation (execute tasks.md following constitutional principles)  
**Phase 5**: Validation (run tests, execute quickstart.md, performance validation)

## Complexity Tracking
*Fill ONLY if Constitution Check has violations that must be justified*

| Violation | Why Needed | Simpler Alternative Rejected Because |
|-----------|------------|-------------------------------------|
| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |


## Progress Tracking
*This checklist is updated during execution flow*

**Phase Status**:
- [x] Phase 0: Research complete (/plan command)
- [ ] Phase 1: Design complete (/plan command)
- [ ] Phase 2: Task planning complete (/plan command - describe approach only)
- [ ] Phase 3: Tasks generated (/tasks command)
- [ ] Phase 4: Implementation complete
- [ ] Phase 5: Validation passed

**Gate Status**:
- [x] Initial Constitution Check: PASS
- [ ] Post-Design Constitution Check: PASS
- [ ] All NEEDS CLARIFICATION resolved
- [ ] Complexity deviations documented

---
*Based on Constitution v2.1.1 - See `/memory/constitution.md`*

spec.txt

# Feature Specification: Order Management Web Application

**Feature Branch**: `001-build-web-application`  
**Created**: September 11, 2025  
**Status**: Draft  
**Input**: User description: "Build web application to manage order in each shops in e-commerce system that can search by order id and display with paging (size =10)"

## Execution Flow (main)
```
1. Parse user description from Input
   → If empty: ERROR "No feature description provided"
2. Extract key concepts from description
   → Identify: actors, actions, data, constraints
3. For each unclear aspect:
   → Mark with [NEEDS CLARIFICATION: specific question]
4. Fill User Scenarios & Testing section
   → If no clear user flow: ERROR "Cannot determine user scenarios"
5. Generate Functional Requirements
   → Each requirement must be testable
   → Mark ambiguous requirements
6. Identify Key Entities (if data involved)
7. Run Review Checklist
   → If any [NEEDS CLARIFICATION]: WARN "Spec has uncertainties"
   → If implementation details found: ERROR "Remove tech details"
8. Return: SUCCESS (spec ready for planning)
```

---

## ⚡ Quick Guidelines
- ✅ Focus on WHAT users need and WHY
- ❌ Avoid HOW to implement (no tech stack, APIs, code structure)
- 👥 Written for business stakeholders, not developers

### Section Requirements
- **Mandatory sections**: Must be completed for every feature
- **Optional sections**: Include only when relevant to the feature
- When a section doesn't apply, remove it entirely (don't leave as "N/A")

### For AI Generation
When creating this spec from a user prompt:
1. **Mark all ambiguities**: Use [NEEDS CLARIFICATION: specific question] for any assumption you'd need to make
2. **Don't guess**: If the prompt doesn't specify something (e.g., "login system" without auth method), mark it
3. **Think like a tester**: Every vague requirement should fail the "testable and unambiguous" checklist item
4. **Common underspecified areas**:
   - User types and permissions
   - Data retention/deletion policies  
   - Performance targets and scale
   - Error handling behaviors
   - Integration requirements
   - Security/compliance needs

---

## User Scenarios & Testing *(mandatory)*

### Primary User Story
Shop managers and administrators need to efficiently manage and track orders within their e-commerce system. They require the ability to quickly locate specific orders by ID and browse through all orders with pagination to handle large volumes of order data effectively.

### Acceptance Scenarios
1. **Given** a user is on the order management interface, **When** they enter a valid order ID in the search field, **Then** the system displays the specific order details
2. **Given** a user is viewing the order list, **When** they navigate through pages, **Then** the system displays 10 orders per page with proper pagination controls
3. **Given** a user searches for a non-existent order ID, **When** the search is performed, **Then** the system displays an appropriate "order not found" message
4. **Given** there are more than 10 orders in the system, **When** a user views the order list, **Then** pagination controls are displayed allowing navigation to next/previous pages

### Edge Cases
- What happens when the order database is empty?
- How does the system handle invalid or malformed order ID searches?
- What occurs when a user tries to access a page number that doesn't exist?
- How does the system behave with very large order datasets (performance considerations)?

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST provide a web-based interface for order management
- **FR-002**: System MUST allow users to search for orders by order ID
- **FR-003**: System MUST display search results showing order details when a valid order ID is found
- **FR-004**: System MUST display orders in a paginated list with exactly 10 orders per page
- **FR-005**: System MUST provide pagination controls (next, previous, page numbers) for navigating through order lists
- **FR-006**: System MUST display appropriate feedback when no orders are found for a search query
- **FR-007**: System MUST handle and display error messages for invalid search inputs
- **FR-008**: Users MUST be able to view order details [NEEDS CLARIFICATION: what specific order details should be displayed - status, items, customer info, dates, amounts?]
- **FR-009**: System MUST authenticate users [NEEDS CLARIFICATION: authentication method not specified - login required? user roles?]
- **FR-010**: System MUST restrict access to orders [NEEDS CLARIFICATION: access control - can users see all shop orders or only their own shop's orders?]
- **FR-011**: System MUST handle concurrent user access [NEEDS CLARIFICATION: performance requirements for number of simultaneous users not specified]

### Key Entities *(include if feature involves data)*
- **Order**: Represents a customer purchase transaction with unique identifier, contains order details, status, and associated shop information
- **Shop**: Represents individual stores in the e-commerce system, contains shop information and associated orders
- **User**: Represents system users who can access and manage orders, with potential role-based permissions
- **OrderDetails**: Contains specific information about items, quantities, prices, dates, and customer information associated with each order

---

## Review & Acceptance Checklist
*GATE: Automated checks run during main() execution*

### Content Quality
- [ ] No implementation details (languages, frameworks, APIs)
- [ ] Focused on user value and business needs
- [ ] Written for non-technical stakeholders
- [ ] All mandatory sections completed

### Requirement Completeness
- [ ] No [NEEDS CLARIFICATION] markers remain
- [ ] Requirements are testable and unambiguous  
- [ ] Success criteria are measurable
- [ ] Scope is clearly bounded
- [ ] Dependencies and assumptions identified

---

## Execution Status
*Updated by main() during processing*

- [x] User description parsed
- [x] Key concepts extracted
- [x] Ambiguities marked
- [x] User scenarios defined
- [x] Requirements generated
- [x] Entities identified
- [ ] Review checklist passed (pending clarifications)

---

task.txt

# Tasks: Order Management Web Application

**Input**: Design documents from `/specs/001-build-web-application/`
**Prerequisites**: plan.md (required), research.md, data-model.md, contracts/

## Execution Flow (main)
```
1. Load plan.md from feature directory
   → If not found: ERROR "No implementation plan found"
   → Extract: tech stack, libraries, structure
2. Load optional design documents:
   → data-model.md: Extract entities → model tasks
   → contracts/: Each file → contract test task
   → research.md: Extract decisions → setup tasks
3. Generate tasks by category:
   → Setup: project init, dependencies, linting
   → Tests: contract tests, integration tests
   → Core: models, services, CLI commands
   → Integration: DB, middleware, logging
   → Polish: unit tests, performance, docs
4. Apply task rules:
   → Different files = mark [P] for parallel
   → Same file = sequential (no [P])
   → Tests before implementation (TDD)
5. Number tasks sequentially (T001, T002...)
6. Generate dependency graph
7. Create parallel execution examples
8. Validate task completeness:
   → All contracts have tests?
   → All entities have models?
   → All endpoints implemented?
9. Return: SUCCESS (tasks ready for execution)
```

## Format: `[ID] [P?] Description`
- **[P]**: Can run in parallel (different files, no dependencies)
- Include exact file paths in descriptions

## Path Conventions
- **Web app**: `backend/src/`, `frontend/src/` (per implementation plan)
- Backend structure: `backend/src/models/`, `backend/src/services/`, `backend/src/routes/`
- Frontend structure: `frontend/src/components/`, `frontend/src/pages/`, `frontend/src/services/`

## Phase 3.1: Setup
- [ ] T001 Create project structure with backend/ and frontend/ directories per implementation plan
- [ ] T002 Initialize backend Node.js project with Express, Vitest, and minimal dependencies in backend/
- [ ] T003 Initialize frontend Vite project with React, Vitest, React Testing Library in frontend/
- [ ] T004 [P] Configure ESLint and Prettier for backend in backend/.eslintrc.json
- [ ] T005 [P] Configure ESLint and Prettier for frontend in frontend/.eslintrc.json
- [ ] T006 [P] Setup backend package.json scripts for dev, test, build, start
- [ ] T007 [P] Setup frontend package.json scripts for dev, test, build, preview

## Phase 3.2: Tests First (TDD) ⚠️ MUST COMPLETE BEFORE 3.3
**CRITICAL: These tests MUST be written and MUST FAIL before ANY implementation**

### Backend Contract Tests
- [ ] T008 [P] Contract test GET /api/orders in backend/tests/contract/orders-list.test.js
- [ ] T009 [P] Contract test GET /api/orders/:id in backend/tests/contract/orders-detail.test.js
- [ ] T010 [P] Contract test GET /api/orders/search in backend/tests/contract/orders-search.test.js
- [ ] T011 [P] Contract test POST /api/auth/login in backend/tests/contract/auth-login.test.js
- [ ] T012 [P] Contract test POST /api/auth/logout in backend/tests/contract/auth-logout.test.js

### Frontend Component Tests
- [ ] T013 [P] Component test OrderList with pagination in frontend/tests/components/OrderList.test.jsx
- [ ] T014 [P] Component test OrderSearch functionality in frontend/tests/components/OrderSearch.test.jsx
- [ ] T015 [P] Component test OrderDetail view in frontend/tests/components/OrderDetail.test.jsx
- [ ] T016 [P] Component test Pagination controls in frontend/tests/components/Pagination.test.jsx
- [ ] T017 [P] Component test LoginForm in frontend/tests/components/LoginForm.test.jsx

### Integration Tests
- [ ] T018 [P] Integration test browse orders workflow in backend/tests/integration/browse-orders.test.js
- [ ] T019 [P] Integration test search orders workflow in backend/tests/integration/search-orders.test.js
- [ ] T020 [P] Integration test authentication flow in backend/tests/integration/auth-flow.test.js
- [ ] T021 [P] Integration test frontend-backend API communication in frontend/tests/integration/api-client.test.js

## Phase 3.3: Core Implementation (ONLY after tests are failing)

### Backend Data Models
- [ ] T022 [P] Order model with validation in backend/src/models/Order.js
- [ ] T023 [P] OrderItem model with validation in backend/src/models/OrderItem.js
- [ ] T024 [P] Shop model with validation in backend/src/models/Shop.js
- [ ] T025 [P] User model with validation in backend/src/models/User.js

### Backend Services
- [ ] T026 [P] OrderService with CRUD operations in backend/src/services/OrderService.js
- [ ] T027 [P] AuthService with session management in backend/src/services/AuthService.js
- [ ] T028 [P] PaginationService utility in backend/src/services/PaginationService.js

### Backend API Routes
- [ ] T029 GET /api/orders endpoint with pagination in backend/src/routes/orders.js
- [ ] T030 GET /api/orders/:id endpoint in backend/src/routes/orders.js
- [ ] T031 GET /api/orders/search endpoint in backend/src/routes/orders.js
- [ ] T032 [P] POST /api/auth/login endpoint in backend/src/routes/auth.js
- [ ] T033 [P] POST /api/auth/logout endpoint in backend/src/routes/auth.js

### Frontend Services
- [ ] T034 [P] API client service for orders in frontend/src/services/OrderAPI.js
- [ ] T035 [P] API client service for authentication in frontend/src/services/AuthAPI.js
- [ ] T036 [P] Browser storage service for session in frontend/src/services/StorageService.js

### Frontend Components
- [ ] T037 [P] OrderList component with vanilla CSS in frontend/src/components/OrderList.jsx
- [ ] T038 [P] OrderSearch component in frontend/src/components/OrderSearch.jsx
- [ ] T039 [P] OrderDetail component in frontend/src/components/OrderDetail.jsx
- [ ] T040 [P] Pagination component in frontend/src/components/Pagination.jsx
- [ ] T041 [P] LoginForm component in frontend/src/components/LoginForm.jsx

### Frontend Pages
- [ ] T042 [P] OrdersPage with search and list in frontend/src/pages/OrdersPage.jsx
- [ ] T043 [P] OrderDetailPage in frontend/src/pages/OrderDetailPage.jsx
- [ ] T044 [P] LoginPage in frontend/src/pages/LoginPage.jsx

## Phase 3.4: Integration
- [ ] T045 Express app setup with middleware in backend/src/app.js
- [ ] T046 Backend data storage layer (JSON files) in backend/src/storage/DataStore.js
- [ ] T047 Session middleware and authentication in backend/src/middleware/auth.js
- [ ] T048 Error handling middleware in backend/src/middleware/errorHandler.js
- [ ] T049 CORS configuration for frontend origin in backend/src/middleware/cors.js
- [ ] T050 Frontend router setup with React Router in frontend/src/App.jsx
- [ ] T051 Frontend authentication context in frontend/src/contexts/AuthContext.jsx
- [ ] T052 Frontend error boundary component in frontend/src/components/ErrorBoundary.jsx

## Phase 3.5: Polish
- [ ] T053 [P] Unit tests for Order model validation in backend/tests/unit/Order.test.js
- [ ] T054 [P] Unit tests for pagination logic in backend/tests/unit/PaginationService.test.js
- [ ] T055 [P] Unit tests for OrderAPI service in frontend/tests/unit/OrderAPI.test.js
- [ ] T056 [P] CSS modules for responsive design in frontend/src/styles/
- [ ] T057 Performance optimization and lazy loading in frontend/src/components/
- [ ] T058 [P] Test data seeding script in backend/scripts/seed-data.js
- [ ] T059 [P] API documentation generation from OpenAPI spec
- [ ] T060 [P] Build and deployment configuration
- [ ] T061 Validate quickstart guide execution in /specs/001-build-web-application/quickstart.md

## Dependencies
- Setup (T001-T007) before all other phases
- Tests (T008-T021) before implementation (T022-T052)
- Models (T022-T025) before Services (T026-T028)
- Services before API Routes (T029-T033)
- Frontend services (T034-T036) before Components (T037-T041)
- Components before Pages (T042-T044)
- Core implementation before Integration (T045-T052)
- Integration before Polish (T053-T061)

## Parallel Execution Examples

### Contract Tests Phase (can run simultaneously):
```bash
# Backend contract tests
Task: "Contract test GET /api/orders in backend/tests/contract/orders-list.test.js"
Task: "Contract test GET /api/orders/:id in backend/tests/contract/orders-detail.test.js"
Task: "Contract test GET /api/orders/search in backend/tests/contract/orders-search.test.js"
Task: "Contract test POST /api/auth/login in backend/tests/contract/auth-login.test.js"
Task: "Contract test POST /api/auth/logout in backend/tests/contract/auth-logout.test.js"

# Frontend component tests
Task: "Component test OrderList with pagination in frontend/tests/components/OrderList.test.jsx"
Task: "Component test OrderSearch functionality in frontend/tests/components/OrderSearch.test.jsx"
Task: "Component test OrderDetail view in frontend/tests/components/OrderDetail.test.jsx"
```

### Models Phase (independent entities):
```bash
Task: "Order model with validation in backend/src/models/Order.js"
Task: "OrderItem model with validation in backend/src/models/OrderItem.js"
Task: "Shop model with validation in backend/src/models/Shop.js"
Task: "User model with validation in backend/src/models/User.js"
```

### Frontend Components Phase:
```bash
Task: "OrderList component with vanilla CSS in frontend/src/components/OrderList.jsx"
Task: "OrderSearch component in frontend/src/components/OrderSearch.jsx"
Task: "OrderDetail component in frontend/src/components/OrderDetail.jsx"
Task: "Pagination component in frontend/src/components/Pagination.jsx"
Task: "LoginForm component in frontend/src/components/LoginForm.jsx"
```

## Notes
- All [P] tasks are in different files with no dependencies
- Backend routes tasks T029-T031 are NOT parallel as they modify the same file (backend/src/routes/orders.js)
- Verify ALL tests fail before implementing features
- Commit after each task completion
- Follow TDD: RED (failing test) → GREEN (minimal implementation) → REFACTOR
- Use minimal dependencies as specified in implementation plan

## Task Generation Rules Applied
*Applied during execution*

1. **From Contracts (api-spec.yaml)**:
   - GET /api/orders → T008 contract test, T029 implementation
   - GET /api/orders/:id → T009 contract test, T030 implementation
   - GET /api/orders/search → T010 contract test, T031 implementation
   - POST /api/auth/login → T011 contract test, T032 implementation
   - POST /api/auth/logout → T012 contract test, T033 implementation
   
2. **From Data Model**:
   - Order entity → T022 model creation, T026 service
   - OrderItem entity → T023 model creation
   - Shop entity → T024 model creation
   - User entity → T025 model creation, T027 auth service
   
3. **From User Stories (quickstart.md)**:
   - Browse orders workflow → T018 integration test
   - Search orders workflow → T019 integration test
   - Authentication flow → T020 integration test

4. **From Implementation Plan**:
   - Vite + React frontend → T003, T037-T044
   - Express backend → T002, T022-T033
   - Minimal dependencies → vanilla CSS, direct API usage

## Validation Checklist Completed
*Verified before task generation*

- [x] All contracts have corresponding tests (T008-T012)
- [x] All entities have model tasks (T022-T025)
- [x] All tests come before implementation (Phase 3.2 before 3.3)
- [x] Parallel tasks are truly independent (different files, no shared dependencies)
- [x] Each task specifies exact file path
- [x] No [P] task modifies same file as another [P] task
- [x] TDD workflow enforced (tests must fail before implementation)
- [x] All quickstart scenarios have corresponding tasks