Implement the following feature: $ARGUMENTS
This is a full-feature workflow that touches every layer. Follow the team's standards at each step.
Phase 1 — Plan (Sofia Nakamura)
- •Define the user story: who needs this, what it does, why it matters
- •Read existing code to understand where the feature fits in the architecture
- •Identify every file that needs to change or be created
- •List acceptance criteria — what "done" looks like
- •Present the plan before writing any code
Phase 2 — Schema & Config (Daniel Okoye + Marcus Chen)
- •Add any new typed schemas (see stack concepts) to the models/schemas file
- •Explicit types on every field — no untyped/any fields
- •Validation constraints where applicable (see stack concepts)
- •Add any new settings to the config file with the project's env prefix
- •Document new settings in the env example file with description and default
Phase 3 — Core Layer (Alex Rivera)
Skip if the feature doesn't touch the core/device layer.
- •If new behavior is needed, extend the primary protocol/interface
- •Implement in both the real and mock implementations — both must stay in sync
- •Use typed exceptions from the exception hierarchy
- •Document any protocol-specific commands with clear comments
Phase 4 — Service Logic (Alex Rivera + Janet Moore)
- •Add business logic to the service layer
- •Thread-safe: wrap external resource access in the lock mechanism
- •Rollback on partial failure for multi-entity operations
- •Audit log via the project's audit logger for any state changes
- •Typed exceptions for error conditions
Phase 5 — API Endpoints (Daniel Okoye)
- •Add routes to the appropriate router (see project config)
- •Thin handlers — delegate to the service class
- •Auth-protected DI dependency for protected endpoints
- •Public DI dependency for unauthenticated endpoints
- •Full OpenAPI metadata: response schema, summary, description, responses (see stack concepts)
- •Static routes before parameterized routes
- •Map domain exceptions to HTTP status codes per project config
Phase 6 — Security (Janet Moore)
- •Verify new endpoints respect auth when API key is configured
- •Verify error responses use the error response model — no stack traces or internals
- •Verify input validation via typed schemas (see stack concepts) — no raw input trusted
- •If handling secrets: use timing-safe comparison (see stack concepts), never equality operator
Phase 7 — Tests (Priya Sharma)
- •Write tests for each new endpoint: success, validation error, device/service error
- •Write tests for new service methods: happy path, edge cases, error conditions
- •If state changes: test audit log output via log capture mechanism (see stack concepts)
- •If multi-entity operations: test rollback on partial failure
- •Add to corresponding test file (see test file mapping in project config)
Phase 8 — Verify (All)
Run the test command and the type-check command (see project config). Both MUST pass with zero errors.
Phase 9 — Documentation (Sofia Nakamura)
- •Update project documentation — API endpoints table, configuration table, examples
- •Update app factory description if the feature changes API capabilities
- •Verify OpenAPI docs reflect all new endpoints