|
| 1 | +# CLAUDE.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +## Essential Commands |
| 6 | + |
| 7 | +### Testing |
| 8 | + |
| 9 | +- **Run tests for affected projects**: `yarn test` |
| 10 | +- **Run tests for all projects**: `yarn test:all` |
| 11 | +- **Run a single test file**: `npx vitest run path/to/test.spec.ts` |
| 12 | +- **Run tests in watch mode**: `npx vitest watch` |
| 13 | +- **Run tests for specific project**: `npx nx test @libs/cdk-utils` |
| 14 | +- **Run specific test file with Nx**: `npx nx test @libs/cdk-utils -- path/to/test.spec.ts` |
| 15 | + |
| 16 | +### Code Quality |
| 17 | + |
| 18 | +- **Lint affected projects**: `yarn lint` |
| 19 | +- **Lint all projects**: `yarn lint:all` |
| 20 | +- **Type check affected projects**: `yarn typecheck` |
| 21 | +- **Type check all projects**: `yarn typecheck:all` |
| 22 | + |
| 23 | +### Service Management |
| 24 | + |
| 25 | +- **Generate new service**: `npx nx g service <service-name>` |
| 26 | +- **Generate notification service**: `npx nx g service <service-name> notification` |
| 27 | +- **Deploy service to AWS**: `npx nx deploy <service-name> -- -s <stage> --aws-profile <profile>` |
| 28 | +- **Remove service from AWS**: `npx nx run <service-name>:remove -- -s <stage> --aws-profile <profile>` |
| 29 | + |
| 30 | +### CDK Deployment |
| 31 | + |
| 32 | +- **Deploy all stacks**: `cd applications/core && cdk deploy` |
| 33 | +- **Deploy staging stacks**: `cd applications/core && cdk deploy stg/**` |
| 34 | +- **Deploy production stacks**: `cd applications/core && cdk deploy prd/**` |
| 35 | +- **View CDK diff**: `cd applications/core && cdk diff` |
| 36 | + |
| 37 | +### API Client Generation |
| 38 | + |
| 39 | +- **Generate typed API client**: `npx nx g client <client-name>` |
| 40 | + |
| 41 | +## Architecture Overview |
| 42 | + |
| 43 | +This is an AWS microservices template using: |
| 44 | + |
| 45 | +- **Nx monorepo** structure with services in `services/` and libraries in `libs/` |
| 46 | +- **AWS CDK v2** for infrastructure as code (recently migrated from Serverless Framework) |
| 47 | +- **TypeScript** with strict type checking extending @aligent/ts-code-standards |
| 48 | +- **Node.js 22.14.0** runtime |
| 49 | + |
| 50 | +### Key Architecture Patterns |
| 51 | + |
| 52 | +1. **Service-Based Architecture** |
| 53 | + |
| 54 | + - Each service is a separate CDK Stack defined in `services/<service-name>/src/index.ts` |
| 55 | + - Services export a Stack class that extends `aws-cdk-lib.Stack` |
| 56 | + - Services are imported and instantiated in `ApplicationStage` inside `applications/core/bin/main.ts` |
| 57 | + |
| 58 | +2. **CDK Application Structure** |
| 59 | + |
| 60 | + - Entry point: `applications/core/bin/main.ts` creates CDK App and stages |
| 61 | + - Stages (dev/stg/prd) are created as ApplicationStage instances directly in `main.ts` |
| 62 | + - Stage-specific configuration is applied via property injectors and aspects |
| 63 | + - Each stage automatically configures resources based on deployment environment |
| 64 | + |
| 65 | +3. **Lambda and Step Functions** |
| 66 | + |
| 67 | + - Lambda functions are in `services/<service>/src/lambda/` |
| 68 | + - Step Functions use YAML definitions in `services/<service>/src/step-functions/` |
| 69 | + - Shared constructs in `services/<service>/src/lib/constructs/` |
| 70 | + - Step Functions use JSONata for output transformations |
| 71 | + - Automatic versioning and aliasing applied via VersionFunctionsAspect |
| 72 | + - Stage-specific configuration applied via property injectors |
| 73 | + |
| 74 | +4. **Property Injection Architecture** |
| 75 | + |
| 76 | + - Configuration-based defaults applied via property injectors: |
| 77 | + - **NodeJsFunctionDefaultsInjector**: Bundling configuration (sourceMap, esm, minify) |
| 78 | + - **LogGroupDefaultsInjector**: Duration-based retention (SHORT/MEDIUM/LONG) |
| 79 | + - **StepFunctionDefaultsInjector**: Automatic logging for EXPRESS workflows |
| 80 | + - **BucketDefaultsInjector**: Auto-cleanup policies for S3 buckets |
| 81 | + - Cross-cutting concerns handled by aspects (VersionFunctionsAspect for automatic versioning) |
| 82 | + - Configuration can be customized per stage or globally |
| 83 | + - Uses CDK's built-in property injection system - no custom constructs needed |
| 84 | + |
| 85 | +5. **CDK Constructs and Utilities** |
| 86 | + |
| 87 | + - **S3Bucket**: Lifecycle management with duration-based rules (SHORT/MEDIUM/LONG/PERMANENT) |
| 88 | + - **SsmParameterGroup**: Abstract class for grouping and managing SSM parameters |
| 89 | + - **StepFunctionFromFile**: Load Step Function definitions from YAML/JSON files |
| 90 | + |
| 91 | +6. **Testing Strategy** |
| 92 | + - Vitest for unit testing with coverage reports |
| 93 | + - Test files colocated with source files as `*.spec.ts` or `*.test.ts` |
| 94 | + - Workspace-level Vitest configuration in `vitest.workspace.ts` |
| 95 | + |
| 96 | +## Important Context |
| 97 | + |
| 98 | +### CDK Migration Notes |
| 99 | + |
| 100 | +- Project migrated from Serverless Framework to CDK using property injection pattern |
| 101 | +- CDK construct IDs are critical - changing them will replace resources |
| 102 | +- Lambda versions and aliases are automatically created via VersionFunctionsAspect |
| 103 | +- Step Functions use `LambdaInvoke` resource with automatic retry blocks |
| 104 | +- Task outputs are nested in `Payload` property - use JSONata to transform |
| 105 | +- Stage-specific resource configuration handled by property injectors |
| 106 | + |
| 107 | +### Configuration |
| 108 | + |
| 109 | +- Update brand name in `nx.json` generators section before first use |
| 110 | +- Package name in `package.json` should follow `@<brand>-int/integrations` format |
| 111 | +- Services are tagged with STAGE and SERVICE tags automatically |
| 112 | + |
| 113 | +### Development Workflow |
| 114 | + |
| 115 | +1. Always run lint and type checks before committing |
| 116 | +2. Use Nx affected commands to optimize CI/CD performance |
| 117 | +3. Follow existing code patterns and conventions in the codebase |
| 118 | +4. Check `CDK-MIGRATION-NOTES.md` for CDK-specific guidance |
| 119 | + |
| 120 | +## AI Helpers |
| 121 | + |
| 122 | +The `docs/ai-helpers/` folder contains documentation templates to assist AI code assistants in creating consistent and comprehensive documentation: |
| 123 | + |
| 124 | +### Recommended MCP Servers |
| 125 | + |
| 126 | +When using Claude Code or other MCP-compatible tools, the following MCP servers are recommended for this repository: |
| 127 | + |
| 128 | +- **context7**: Provides up-to-date documentation for libraries and frameworks |
| 129 | +- **eslint**: Enables linting capabilities for code quality checks |
| 130 | +- **nx**: Offers Nx-specific commands and workspace insights |
| 131 | + |
| 132 | +These servers should be used when available to enhance development capabilities. |
| 133 | + |
| 134 | +### Available Templates |
| 135 | + |
| 136 | +- **`APPLICATION_ARCHITECTURE_FORMAT.md`**: Template for creating comprehensive architecture diagrams for AWS CDK services |
| 137 | + - Provides guidelines for analyzing CDK application structure |
| 138 | + - Includes Mermaid diagram formats with consistent color palettes |
| 139 | + - Shows how to map Step Function workflows and Lambda functions |
| 140 | + - Contains common architectural patterns and best practices |
| 141 | + |
| 142 | +- **`SERVICE_README_FORMAT.md`**: Template for creating service-specific README documentation |
| 143 | + - Standardized format for service documentation |
| 144 | + - Context diagram template showing external system interactions |
| 145 | + - Sections for workflows, critical information, and operational details |
| 146 | + - Consistent color palette for system visualization |
| 147 | + |
| 148 | +### When to Use |
| 149 | + |
| 150 | +Reference these templates when: |
| 151 | +- Creating new architecture documentation (`ARCHITECTURE.md`) |
| 152 | +- Documenting a new service with a README |
| 153 | +- Updating existing service documentation |
| 154 | +- Generating visual representations of service interactions |
| 155 | +- Ensuring consistency across all service documentation |
0 commit comments