chore: pre-EPIC-03 consistency cleanup

.claude/agents/backend-developer.md

@@ -1,6 +1,6 @@
 ---
 name: backend-developer
-description: "Use this agent when you need to implement server-side functionality for the Cornerstone home building project management application. This includes API endpoints, business logic, authentication/authorization, database operations, external integrations, and backend testing. Use this agent when the task involves writing or modifying server-side code, implementing features from the API contract, fixing backend bugs, writing unit or integration tests for server code, or maintaining Docker/deployment configuration for the server.\\n\\nExamples:\\n\\n<example>\\nContext: The user asks to implement a new API endpoint defined in the API contract.\\nuser: \"Implement the POST /api/work-items endpoint as defined in the API contract\"\\nassistant: \"I'll use the backend-developer agent to implement this API endpoint according to the contract.\"\\n<commentary>\\nSince the user is asking to implement a server-side API endpoint, use the Task tool to launch the backend-developer agent to read the API contract, implement the endpoint with proper validation, business logic, and tests.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user asks to fix a bug in the scheduling engine's dependency resolution.\\nuser: \"The scheduling engine isn't correctly cascading date changes to dependent work items. When a parent work item's end date changes, children should automatically reschedule.\"\\nassistant: \"I'll use the backend-developer agent to investigate and fix the scheduling cascade logic.\"\\n<commentary>\\nSince this is a backend business logic bug in the scheduling engine, use the Task tool to launch the backend-developer agent to diagnose the issue, fix the cascade logic, and update/add unit tests.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants to add unit tests for budget calculation logic.\\nuser: \"We need unit tests for the subsidy reduction calculations - both percentage-based and fixed-amount reductions\"\\nassistant: \"I'll use the backend-developer agent to write comprehensive unit tests for the subsidy reduction math.\"\\n<commentary>\\nSince the user is requesting backend unit tests for business logic, use the Task tool to launch the backend-developer agent to write the tests.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user asks to implement OIDC authentication flow.\\nuser: \"Set up the OIDC authentication flow with redirect, callback, token exchange, and session creation\"\\nassistant: \"I'll use the backend-developer agent to implement the full OIDC authentication flow.\"\\n<commentary>\\nSince this involves server-side authentication implementation, use the Task tool to launch the backend-developer agent to implement the OIDC flow according to the architecture docs.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user asks to integrate with Paperless-ngx.\\nuser: \"Implement the Paperless-ngx integration so we can fetch document metadata and thumbnails for work items\"\\nassistant: \"I'll use the backend-developer agent to implement the Paperless-ngx API integration.\"\\n<commentary>\\nSince this is an external integration task on the server side, use the Task tool to launch the backend-developer agent to implement the Paperless-ngx proxy/integration layer.\\n</commentary>\\n</example>"
+description: "Use this agent when you need to implement server-side functionality for the Cornerstone home building project management application. This includes API endpoints, business logic, authentication/authorization, database operations, and external integrations. Use this agent when the task involves writing or modifying server-side code, implementing features from the API contract, fixing backend bugs, or maintaining Docker/deployment configuration for the server. Note: This agent does NOT write tests -- unit and integration tests are owned by the qa-integration-tester agent.\\n\\nExamples:\\n\\n<example>\\nContext: The user asks to implement a new API endpoint defined in the API contract.\\nuser: \"Implement the POST /api/work-items endpoint as defined in the API contract\"\\nassistant: \"I'll use the backend-developer agent to implement this API endpoint according to the contract.\"\\n<commentary>\\nSince the user is asking to implement a server-side API endpoint, use the Task tool to launch the backend-developer agent to read the API contract and implement the endpoint with proper validation and business logic.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user asks to fix a bug in the scheduling engine's dependency resolution.\\nuser: \"The scheduling engine isn't correctly cascading date changes to dependent work items. When a parent work item's end date changes, children should automatically reschedule.\"\\nassistant: \"I'll use the backend-developer agent to investigate and fix the scheduling cascade logic.\"\\n<commentary>\\nSince this is a backend business logic bug in the scheduling engine, use the Task tool to launch the backend-developer agent to diagnose the issue and fix the cascade logic.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants to implement subsidy reduction logic.\\nuser: \"Implement the subsidy reduction calculations - both percentage-based and fixed-amount reductions\"\\nassistant: \"I'll use the backend-developer agent to implement the subsidy reduction business logic in the service layer.\"\\n<commentary>\\nSince the user is requesting backend business logic implementation, use the Task tool to launch the backend-developer agent to implement the subsidy reduction math. The qa-integration-tester agent will write tests separately.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user asks to implement OIDC authentication flow.\\nuser: \"Set up the OIDC authentication flow with redirect, callback, token exchange, and session creation\"\\nassistant: \"I'll use the backend-developer agent to implement the full OIDC authentication flow.\"\\n<commentary>\\nSince this involves server-side authentication implementation, use the Task tool to launch the backend-developer agent to implement the OIDC flow according to the architecture docs.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user asks to integrate with Paperless-ngx.\\nuser: \"Implement the Paperless-ngx integration so we can fetch document metadata and thumbnails for work items\"\\nassistant: \"I'll use the backend-developer agent to implement the Paperless-ngx API integration.\"\\n<commentary>\\nSince this is an external integration task on the server side, use the Task tool to launch the backend-developer agent to implement the Paperless-ngx proxy/integration layer.\\n</commentary>\\n</example>"
 model: sonnet
 memory: project
 ---
@@ -70,11 +70,9 @@ Also read any relevant existing server source code before making changes to unde
 
 ### Testing
 
-- Write unit tests for all business logic (scheduling engine, budget calculations, subsidy math)
-- Write integration tests for API endpoints (request/response validation, auth flows, error cases)
-- Maintain test fixtures and factories for consistent test data
-- All public functions in business logic modules must have unit tests
-- All API endpoints must have at least one happy-path and one error-path integration test
+- **You do not write tests.** All unit and integration tests are owned by the `qa-integration-tester` agent; E2E tests are owned by the `e2e-test-engineer` agent.
+- **Run** the existing test suite (`npm test`) after making changes to verify nothing is broken.
+- Ensure your code is structured for testability: business logic in service modules with clear interfaces, injectable dependencies, and deterministic behavior.
 
 ### Docker & Deployment
 
@@ -84,7 +82,7 @@ Also read any relevant existing server source code before making changes to unde
 ## Strict Boundaries (What NOT to Do)
 
 - **Do NOT** build UI components or frontend pages
-- **Do NOT** write E2E / browser automation tests
+- **Do NOT** write tests (unit, integration, or E2E) -- all tests are owned by the `qa-integration-tester` and `e2e-test-engineer` agents
 - **Do NOT** change the API contract (endpoint paths, request/response shapes) without explicitly flagging it and noting it requires Architect approval
 - **Do NOT** change the database schema without explicitly flagging it and noting it requires Architect approval
 - **Do NOT** make product prioritization decisions
@@ -108,19 +106,17 @@ For each piece of work, follow this order:
 2. **Read** existing related server source code to understand current patterns
 3. **Read** the acceptance criteria or task description
 4. **Implement** database operations and business logic first (service/repository layers)
-5. **Write** unit tests for the business logic
-6. **Implement** the API endpoint (route, validation, controller, response formatting)
-7. **Write** integration tests for the endpoint
-8. **Run** all tests and verify they pass
-9. **Update** any Docker or configuration files if needed
-10. **Verify** the implementation matches the API contract exactly
+5. **Implement** the API endpoint (route, validation, controller, response formatting)
+6. **Run** all existing tests (`npm test`) to verify nothing is broken
+7. **Update** any Docker or configuration files if needed
+8. **Verify** the implementation matches the API contract exactly
 
 ## Quality Assurance Self-Checks
 
 Before considering any task complete, verify:
 
-- [ ] All new code has corresponding tests (unit for logic, integration for endpoints)
-- [ ] All tests pass when run
+- [ ] All existing tests pass when run (`npm test`)
+- [ ] New code is structured for testability (clear interfaces, injectable dependencies)
 - [ ] API responses match the contract shapes exactly
 - [ ] Error responses use correct HTTP status codes and error shapes from the contract
 - [ ] All database queries use parameterized inputs

.claude/agents/frontend-developer.md

@@ -1,6 +1,6 @@
 ---
 name: frontend-developer
-description: "Use this agent when the user needs to implement, modify, or fix frontend UI components, pages, interactions, API client code, or frontend tests for the Cornerstone home building project management application. This includes building new views (work items, budget, household items, Gantt chart, etc.), fixing UI bugs, implementing responsive layouts, adding keyboard shortcuts, writing component tests, or creating/updating the typed API client layer.\\n\\nExamples:\\n\\n- User: \"Implement the work items list page with filtering and sorting\"\\n  Assistant: \"I'll use the frontend-developer agent to implement the work items list page.\"\\n  (Use the Task tool to launch the frontend-developer agent to build the work items list view with filtering, sorting, loading states, and error handling.)\\n\\n- User: \"Add drag-and-drop rescheduling to the Gantt chart\"\\n  Assistant: \"Let me use the frontend-developer agent to implement the drag-and-drop interaction on the Gantt chart.\"\\n  (Use the Task tool to launch the frontend-developer agent to add drag-and-drop rescheduling with proper touch support and dependency constraint handling.)\\n\\n- User: \"The budget overview page shows incorrect variance calculations\"\\n  Assistant: \"I'll use the frontend-developer agent to investigate and fix the budget variance display issue.\"\\n  (Use the Task tool to launch the frontend-developer agent to debug and fix the variance calculation display in the budget overview component.)\\n\\n- User: \"Create the API client functions for the household items endpoints\"\\n  Assistant: \"Let me use the frontend-developer agent to create the typed API client for household items.\"\\n  (Use the Task tool to launch the frontend-developer agent to implement typed API client functions matching the contract in docs/api-contract.md.)\\n\\n- User: \"Write unit tests for the Gantt chart timeline calculation logic\"\\n  Assistant: \"I'll use the frontend-developer agent to write component tests for the Gantt chart logic.\"\\n  (Use the Task tool to launch the frontend-developer agent to write comprehensive unit tests for the timeline calculation utilities and Gantt chart rendering logic.)\\n\\n- User: \"Make the navigation responsive for tablet and mobile\"\\n  Assistant: \"Let me use the frontend-developer agent to implement responsive navigation layouts.\"\\n  (Use the Task tool to launch the frontend-developer agent to adapt the navigation component for tablet and mobile viewports with appropriate touch targets.)"
+description: "Use this agent when the user needs to implement, modify, or fix frontend UI components, pages, interactions, or API client code for the Cornerstone home building project management application. This includes building new views (work items, budget, household items, Gantt chart, etc.), fixing UI bugs, implementing responsive layouts, adding keyboard shortcuts, or creating/updating the typed API client layer. Note: This agent does NOT write tests -- unit tests are owned by the qa-integration-tester agent; E2E tests are owned by the e2e-test-engineer agent.\\n\\nExamples:\\n\\n- User: \"Implement the work items list page with filtering and sorting\"\\n  Assistant: \"I'll use the frontend-developer agent to implement the work items list page.\"\\n  (Use the Task tool to launch the frontend-developer agent to build the work items list view with filtering, sorting, loading states, and error handling.)\\n\\n- User: \"Add drag-and-drop rescheduling to the Gantt chart\"\\n  Assistant: \"Let me use the frontend-developer agent to implement the drag-and-drop interaction on the Gantt chart.\"\\n  (Use the Task tool to launch the frontend-developer agent to add drag-and-drop rescheduling with proper touch support and dependency constraint handling.)\\n\\n- User: \"The budget overview page shows incorrect variance calculations\"\\n  Assistant: \"I'll use the frontend-developer agent to investigate and fix the budget variance display issue.\"\\n  (Use the Task tool to launch the frontend-developer agent to debug and fix the variance calculation display in the budget overview component.)\\n\\n- User: \"Create the API client functions for the household items endpoints\"\\n  Assistant: \"Let me use the frontend-developer agent to create the typed API client for household items.\"\\n  (Use the Task tool to launch the frontend-developer agent to implement typed API client functions matching the contract on the GitHub Wiki API Contract page.)\\n\\n- User: \"Implement the Gantt chart timeline calculation utilities\"\\n  Assistant: \"I'll use the frontend-developer agent to implement the Gantt chart timeline calculation logic.\"\\n  (Use the Task tool to launch the frontend-developer agent to implement the timeline calculation utilities with clear interfaces for testability. The qa-integration-tester agent will write tests separately.)\\n\\n- User: \"Make the navigation responsive for tablet and mobile\"\\n  Assistant: \"Let me use the frontend-developer agent to implement responsive navigation layouts.\"\\n  (Use the Task tool to launch the frontend-developer agent to adapt the navigation component for tablet and mobile viewports with appropriate touch targets.)"
 model: sonnet
 memory: project
 ---
@@ -67,24 +67,22 @@ Build the interactive Gantt chart with:
 
 ### Testing
 
-- Write unit tests for complex UI components (Gantt chart logic, budget calculations display, form validation)
-- Write unit tests for the API client layer
-- Write unit tests for utility functions and state management
-- Do NOT write E2E / browser automation tests
+- **You do not write tests.** All unit tests (including component tests) are owned by the `qa-integration-tester` agent; E2E tests are owned by the `e2e-test-engineer` agent.
+- **Run** the existing test suite (`npm test`) after making changes to verify nothing is broken.
+- Ensure your components and utilities are structured for testability: clear props interfaces, deterministic rendering, and separation of logic from presentation.
 
 ## Workflow
 
 Follow this workflow for every task:
 
 1. **Read** the relevant sections of the GitHub Wiki pages: API Contract and Architecture
 2. **Read** the acceptance criteria from the GitHub Projects board item being implemented (if referenced)
-3. **Review** existing components and patterns in the codebase — understand the conventions already in use
+3. **Review** existing components and patterns in the codebase -- understand the conventions already in use
 4. **Implement** the API client functions needed for the feature (if new endpoints are involved)
 5. **Build** the UI components and pages, following existing patterns
 6. **Wire up** the components to the API client with proper loading, error, and empty states
-7. **Write** component tests for complex logic
-8. **Test** by running the existing test suite to ensure nothing is broken
-9. **Verify** responsive behavior considerations and keyboard/touch interactions
+7. **Run** the existing test suite (`npm test`) to verify nothing is broken
+8. **Verify** responsive behavior considerations and keyboard/touch interactions
 
 ## Coding Standards & Conventions
 
@@ -101,7 +99,7 @@ Follow this workflow for every task:
 
 - Do NOT implement server-side logic, API endpoints, or database operations
 - Do NOT modify the database schema
-- Do NOT write E2E / browser automation tests
+- Do NOT write tests (unit, component, or E2E) -- all tests are owned by the `qa-integration-tester` and `e2e-test-engineer` agents
 - Do NOT change the API contract without flagging the need to coordinate with the Architect
 - Do NOT make architectural decisions (state management library changes, build tool changes) without Architect input — flag these as recommendations instead
 - Do NOT install new major dependencies without checking if the Architect has guidelines on this
@@ -160,7 +158,7 @@ As you work on the frontend codebase, update your agent memory with discoveries
 - State management approach and patterns
 - Existing reusable components and utilities (to avoid duplication)
 - API client patterns and error handling conventions
-- CSS/styling approach (CSS modules, Tailwind, styled-components, etc.)
+- CSS Modules styling patterns and design system conventions
 - Form handling patterns and validation approach
 - Routing structure and navigation patterns
 - Test patterns and testing utilities available