Caryndcarter aws-infrastructure .cursorrules file for TypeScript

## Instruction
When user specifies an implementation, first consider if there is a simpler approach.
Always favor best practices and standard approaches within the technology stack.
Always favor the most modern approach.

## Responses
Do not begin responses with "Certainly!" or "Understood."
Do not end responses with "Here is the code," or "Here's the modified version."
Only state what you will update and print code without saying you are printing code.
Do not output a summary after the last code block; I want to immediately apply the changes without waiting for a summary. Only say "What else?"

## Interactions
When copying and adapting a series of files for a new use case, after the first file, the user will only respond with the next file to replicate.

## Editing
Do not remove "TODO" or documentation comments.
Do not remove console.log unless the user is deleting console.log lines.
Remember to return the accumulator (return acc) in array reduce functions.
Never remove "// ~" comments, these are the user's current train of thought.

## Repository
AWS meta infrastructure management via CDK
### Scope
CDK stack should focus on shared infrastructure.
Application-specific resources should be managed in separate repositories.
### Technology
AWS CDK in TypeScript; 
jest for testing.
Original template and .cursorrules published by Finlayson Studio under the MIT license.
### Paths
CDK stack in `lib/cdk-stack.ts`
CDK entrypoint in `bin/cdk.js`
Documentation in `README.md`
GitHub Actions in `.github/workflows/cdk-deploy.yml`
Tests in `test/cdk.spec.ts`

## Testing
Tests are named `test/<subject>.spec.<js|ts>`.
Each file should have one top-level `describe` block.
Organize tests in one of seven second-level describe block sections in this order:
1. Base Cases - it is the type we expect ("It is a Function"). For functions, the simplest possible call works and returns not undefined ("It Works"). For objects, the expected shape.
2. Error Conditions - any error handling the code performs
3. Security - any security checks the code performs
4. Observability - any logging the code performs
5. Happy Paths - The most common use case
6. Features - Features in addition to the happy path
7. Specific Scenarios - Special cases
Omit describe blocks for sections that are not applicable or empty.
Whenever possible, especially when refactoring, write the test first so the user can confirm the expected behavior passes/fails.

## Style
Use double quotes, trailing commas, and semicolons.
Whenever a hard-coded value like `site: "datadoghq.com"` is used, define a constant at the top of the file, `const DATADOG_SITE = "datadoghq.com"`, and reference that throughout.
Alphabetize as much as possible.
### Linting
Do not delete `// eslint-disable-next-line no-shadow` comments; add when shadowing variables, especially `error` in catch blocks.
### Markdown
When linking files, use the filename including extension as the link text and the relative path as the target (e.g., `[cdk-deploy.yml](.github/workflows/cdk-deploy.yml)`).