cdk-cost-analyzer 0.1.1

package/.kiro/steering/documentation-style.md

@@ -0,0 +1,151 @@
+# Documentation Style Guide
+
+## Writing Style
+
+Write documentation with a professional, technical tone similar to AWS documentation:
+
+- **Professional and clear** - Direct, informative language without casual expressions
+- **Action-oriented** - Use active voice and imperative mood for instructions
+- **Concise** - Get to the point quickly, avoid unnecessary words
+- **Practical** - Focus on what users need to do, not just theory
+
+## Tone Guidelines
+
+### Do Use
+
+- Clear, direct language: "Configure the IAM role" not "You might want to configure the IAM role"
+- Active voice: "Deploy the stack" not "The stack should be deployed"
+- Present tense: "The function returns" not "The function will return"
+- Second person for instructions: "You configure" or imperative "Configure"
+- Technical precision: Use exact AWS service names and terminology
+
+### Don't Use
+
+- Emojis or emoticons (❌ 🎉 😊)
+- Exclamation marks for emphasis
+- Casual expressions: "awesome", "cool", "super easy"
+- Vague qualifiers: "pretty much", "basically", "kind of"
+- Marketing language: "revolutionary", "game-changing", "best-in-class"
+- Overused adjectives: "comprehensive" (use specific descriptions instead)
+
+## Structure
+
+### Headers
+
+- Use descriptive, action-oriented headers
+- "Configuring IAM Roles" not "IAM Roles Configuration"
+- "What You'll Do" for overview sections
+- Avoid stacked headings (heading immediately followed by another heading)
+
+### Content Organization
+
+- Start with overview/context
+- Use tables for structured comparisons
+- Use bullet lists for related items
+- Use numbered lists for sequential steps
+- Include code examples with proper syntax highlighting
+
+### Examples and Code
+
+- Provide complete, working examples
+- Include comments explaining key concepts
+- Use realistic placeholder values
+- Show both the command and expected output when relevant
+
+## Formatting
+
+### Emphasis
+
+- **Bold** for UI elements, important terms, and key concepts
+- `Code formatting` for commands, file names, and technical values
+- Use admonitions (warning, info, note) for important callouts
+
+### Lists
+
+- Use bullet points for unordered information
+- Use numbered lists only for sequential steps
+- Keep list items parallel in structure
+- Start list items with capital letters
+
+### Code Blocks
+
+Always specify the language for syntax highlighting:
+
+```yaml
+# Good - with language specified
+variables:
+  AWS_REGION: eu-central-1
+```
+
+## Language
+
+- **US English spelling** - "behavior" not "behaviour", "optimize" not "optimise"
+- **Consistent terminology** - Use AWS service names exactly as documented
+- **Avoid jargon** - Explain technical terms when first introduced
+- **Active voice preferred** - "Configure the role" not "The role should be configured"
+
+## AWS-Specific Guidelines
+
+### Service Names
+
+- Use official AWS service names: "AWS Secrets Manager" not "Secrets Manager"
+- First mention: full name, subsequent: short name if clear from context
+- Capitalize properly: "Amazon S3", "AWS Lambda", "Amazon RDS"
+
+### Resource References
+
+- Use exact ARN formats
+- Include region and account placeholders: `<ACCOUNT>`, `<REGION>`
+- Show complete resource names in examples
+
+### Best Practices
+
+- Reference official AWS documentation when appropriate
+- Include security considerations
+- Mention cost implications when relevant
+- Provide troubleshooting guidance
+
+## Examples
+
+### Good Example
+
+```markdown
+## Configuring Secret Rotation
+
+Enable automatic rotation for database credentials:
+
+1. Navigate to AWS Secrets Manager console
+2. Select your secret
+3. Choose "Edit rotation"
+4. Configure rotation schedule
+
+**Important:** Ensure your Lambda function has network access to the database.
+```
+
+### Avoid
+
+```markdown
+## Secret Rotation 🔄
+
+Let's set up rotation! It's super easy:
+
+- Just go to Secrets Manager
+- Click around until you find rotation settings
+- Turn it on! 🎉
+
+Pretty cool, right?
+```
+
+## Checklist
+
+Before submitting documentation:
+
+- [ ] Professional tone throughout
+- [ ] No emojis or casual language
+- [ ] Active voice used for instructions
+- [ ] US English spelling
+- [ ] Code blocks have language specified
+- [ ] Headers are descriptive and action-oriented
+- [ ] Examples are complete and realistic
+- [ ] AWS service names are correct
+- [ ] Security and cost considerations mentioned where relevant

package/.kiro/steering/git-best-practices.md

@@ -0,0 +1,37 @@
+---
+title: Git Best Practices
+inclusion: always
+---
+
+# Git Best Practices
+
+## Commit Messages
+- Use conventional commit format: `type(scope): description`
+- Types: feat, fix, docs, style, refactor, test, chore
+- Keep first line under 50 characters
+- Use imperative mood ("Add feature" not "Added feature")
+- Include body for complex changes
+
+## Branching
+- Use feature branches for new development
+- Keep main/master branch stable and deployable
+- Use descriptive branch names (feature/user-auth, fix/login-bug)
+- Delete merged branches to keep repository clean
+
+## Workflow
+- Pull latest changes before starting work
+- Commit frequently with logical chunks
+- Use interactive rebase to clean up history before merging
+- Review code before merging (pull requests)
+
+## Repository Management
+- Use .gitignore to exclude build artifacts and secrets
+- Keep repository size manageable (use Git LFS for large files)
+- Tag releases with semantic versioning
+- Document branching strategy in README
+
+## Security
+- Never commit secrets, API keys, or passwords
+- Use environment variables for configuration
+- Review commits for sensitive information
+- Use signed commits when possible

package/.kiro/steering/mcp-best-practices.md

@@ -0,0 +1,95 @@
+---
+title: MCP (Model Context Protocol) Best Practices
+inclusion: always
+---
+
+# MCP (Model Context Protocol) Best Practices
+
+## Server Configuration
+- Use workspace-level config (`.kiro/settings/mcp.json`) for project-specific servers
+- Use user-level config (`~/.kiro/settings/mcp.json`) for global/cross-workspace servers
+- Workspace config takes precedence over user config for server name conflicts
+- Always specify exact versions or use `@latest` for stability
+
+## Installation and Setup
+- Use `uvx` command for Python-based MCP servers (requires `uv` package manager)
+- Install `uv` via pip, homebrew, or follow: https://docs.astral.sh/uv/getting-started/installation/
+- No separate installation needed for uvx servers - they download automatically
+- Test servers immediately after configuration, don't wait for issues
+
+## Security and Auto-Approval
+- Use `autoApprove` sparingly and only for trusted, low-risk tools
+- Review tool capabilities before adding to auto-approve list
+- Regularly audit auto-approved tools for security implications
+- Consider environment-specific auto-approve settings
+
+## Error Handling and Debugging
+- Set `FASTMCP_LOG_LEVEL: "ERROR"` to reduce noise in logs
+- Use `disabled: false` to temporarily disable problematic servers
+- Servers reconnect automatically on config changes
+- Use MCP Server view in Kiro feature panel for manual reconnection
+
+## Common MCP Server Examples
+```json
+{
+  "mcpServers": {
+    "aws-docs": {
+      "command": "uvx",
+      "args": ["awslabs.aws-documentation-mcp-server@latest"],
+      "env": {
+        "FASTMCP_LOG_LEVEL": "ERROR"
+      },
+      "disabled": false,
+      "autoApprove": []
+    },
+    "filesystem": {
+      "command": "uvx",
+      "args": ["mcp-server-filesystem@latest"],
+      "env": {
+        "FASTMCP_LOG_LEVEL": "ERROR"
+      },
+      "disabled": false,
+      "autoApprove": ["read_file", "list_directory"]
+    }
+  }
+}
+```
+
+## Testing MCP Tools
+- Test MCP tools immediately after configuration
+- Don't inspect configurations unless facing specific issues
+- Use sample calls to verify tool behavior
+- Test with various parameter combinations
+- Document working examples for team reference
+
+## Performance Optimization
+- Disable unused servers to improve startup time
+- Use specific tool names in auto-approve rather than wildcards
+- Monitor server resource usage and adjust as needed
+- Consider server-specific environment variables for optimization
+
+## Development Workflow
+- Add MCP servers incrementally, test each addition
+- Use version pinning for production environments
+- Document server purposes and usage in team documentation
+- Create project-specific server collections for different use cases
+
+## Troubleshooting
+- Check server logs in Kiro's MCP Server view
+- Verify `uv` and `uvx` installation if Python servers fail
+- Test server connectivity outside of Kiro if needed
+- Use command palette "MCP" commands for server management
+- Restart servers via MCP Server view rather than restarting Kiro
+
+## Best Practices for Tool Usage
+- Understand tool capabilities before first use
+- Use descriptive prompts when calling MCP tools
+- Handle tool errors gracefully in workflows
+- Combine multiple MCP tools for complex tasks
+- Cache results when appropriate to avoid repeated calls
+
+## Development Integration
+- Use Context7 MCP server to verify dependency compatibility before adding libraries
+- Leverage AWS-Knowledge MCP server for current AWS documentation and best practices
+- Use aws-api-mcp-server for AWS API interactions and validation
+- Reference official sources through MCP servers when available in documentation

package/.kiro/steering/python-best-practices.md

@@ -0,0 +1,48 @@
+---
+title: Python Best Practices
+inclusion: fileMatch
+fileMatchPattern: '*.py'
+---
+
+# Python Best Practices
+
+## Code Style
+- Follow PEP 8 style guide
+- Use meaningful variable and function names
+- Use snake_case for variables and functions
+- Use PascalCase for classes
+- Use UPPER_SNAKE_CASE for constants
+- Limit line length to 88 characters (Black formatter)
+
+## Type Hints
+- Use type hints for function parameters and return values
+- Import types from `typing` module when needed
+- Use `Optional` for nullable values
+- Use `Union` for multiple possible types
+
+## Error Handling
+- Use specific exception types
+- Handle exceptions at appropriate levels
+- Use context managers (`with` statements) for resource management
+- Log errors with appropriate detail
+
+## Code Organization
+- Use virtual environments for dependencies
+- Create requirements.txt or use poetry/pipenv
+- Organize code into modules and packages
+- Use `__init__.py` files appropriately
+
+## Testing
+- Write unit tests using pytest
+- Use descriptive test function names
+- Mock external dependencies
+- Aim for high test coverage
+- Use fixtures for test setup
+- Run tests with minimal output: `pytest -q` or `python -m pytest --tb=short -q`
+- Filter specific tests: `pytest -k "test_name"` to avoid running full suites
+
+## Performance
+- Use list comprehensions over loops when appropriate
+- Use generators for large datasets
+- Profile code before optimizing
+- Use appropriate data structures (sets, dicts, etc.)

package/.kiro/steering/react-best-practices.md

@@ -0,0 +1,44 @@
+---
+title: React Best Practices
+inclusion: fileMatch
+fileMatchPattern: '*.tsx,*.jsx,*react*'
+---
+
+# React Best Practices
+
+## Component Structure
+- Use functional components with hooks
+- Keep components small and focused (single responsibility)
+- Use TypeScript for all React components
+- Prefer named exports over default exports
+
+## Hooks
+- Use `useState` for local component state
+- Use `useEffect` for side effects
+- Use `useMemo` and `useCallback` for performance optimization
+- Create custom hooks for reusable logic
+- Follow the rules of hooks (only call at top level)
+
+## Props and State
+- Define prop types with TypeScript interfaces
+- Use destructuring for props
+- Avoid deeply nested state objects
+- Use state updater functions for complex state updates
+
+## Performance
+- Use React.memo for expensive components
+- Implement proper key props for lists
+- Avoid creating objects/functions in render
+- Use lazy loading for large components
+
+## Styling
+- Use CSS modules or styled-components
+- Avoid inline styles for complex styling
+- Use consistent naming conventions
+- Implement responsive design patterns
+
+## Testing
+- Test component behavior, not implementation
+- Use React Testing Library
+- Test user interactions and accessibility
+- Mock external dependencies

package/.kiro/steering/security-best-practices.md

@@ -0,0 +1,41 @@
+---
+title: Security Best Practices
+inclusion: always
+---
+
+# Security Best Practices
+
+## Code Security
+- Never hardcode secrets, API keys, or passwords
+- Use environment variables for configuration
+- Validate all user inputs
+- Use parameterized queries to prevent SQL injection
+- Implement proper authentication and authorization
+
+## Dependency Management
+- Keep dependencies updated
+- Use dependency scanning tools
+- Review third-party packages before adding
+- Use lock files (package-lock.json, poetry.lock)
+- Remove unused dependencies
+
+## Data Protection
+- Encrypt sensitive data at rest and in transit
+- Use HTTPS for all web communications
+- Implement proper session management
+- Use secure headers (HSTS, CSP, etc.)
+- Follow OWASP guidelines
+
+## Infrastructure Security
+- Use least privilege principle for IAM
+- Enable logging and monitoring
+- Use network segmentation
+- Implement proper backup strategies
+- Regular security audits and penetration testing
+
+## Development Practices
+- Use static code analysis tools
+- Implement security testing in CI/CD
+- Code reviews for security issues
+- Security training for developers
+- Incident response procedures

package/.kiro/steering/testing-best-practices.md

@@ -0,0 +1,59 @@
+---
+title: Testing Best Practices
+inclusion: always
+---
+
+# Testing Best Practices
+
+## Test Execution
+- Always run tests with minimal verbosity to prevent session timeouts
+- Use `--silent` or `--quiet` flags when available
+- Filter tests with grep/pattern matching for focused testing
+- Avoid running full test suites in automated contexts unless necessary
+
+## Common Test Commands
+```bash
+# NPM/Yarn - Use silent mode
+npm test -- --silent
+yarn test --silent
+
+# Jest - Minimal output
+npm test -- --verbose=false --silent
+npx jest --silent --passWithNoTests
+
+# Pytest - Quiet mode
+pytest -q
+python -m pytest --tb=short -q
+
+# Mocha - Minimal reporter
+npx mocha --reporter min
+
+# Filtering specific tests
+npm test -- --grep "specific test"
+npx jest --testNamePattern="specific test"
+pytest -k "test_specific"
+```
+
+## Output Management
+- Use summary reporters instead of verbose output
+- Capture detailed logs only when tests fail
+- Use `--bail` or `--maxfail=1` to stop on first failure
+- Redirect verbose output to files when needed: `npm test > test-results.log 2>&1`
+
+## Test Organization
+- Group related tests to enable selective running
+- Use test tags/categories for filtering
+- Keep test names descriptive but concise
+- Separate unit, integration, and e2e tests
+
+## Performance
+- Run tests in parallel when possible (`--parallel`, `--maxWorkers`)
+- Use test caching mechanisms
+- Mock external dependencies to speed up tests
+- Skip slow tests in development with appropriate flags
+
+## CI/CD Considerations
+- Use different verbosity levels for local vs CI environments
+- Capture test artifacts (coverage, reports) separately from console output
+- Use test result formatters that work well with CI systems
+- Consider splitting large test suites across multiple jobs

package/.kiro/steering/typescript-best-practices.md

@@ -0,0 +1,40 @@
+---
+title: TypeScript Best Practices
+inclusion: always
+---
+
+# TypeScript Best Practices
+
+## Code Style
+- Use strict TypeScript configuration (`strict: true`)
+- Prefer `const` over `let`, avoid `var`
+- Use meaningful variable and function names
+- Use PascalCase for classes and interfaces
+- Use camelCase for variables and functions
+- Use UPPER_SNAKE_CASE for constants
+
+## Type Safety
+- Always define return types for functions
+- Use union types instead of `any`
+- Prefer interfaces over type aliases for object shapes
+- Use generic types for reusable components
+- Enable `noImplicitAny` and `strictNullChecks`
+
+## Error Handling
+- Use Result/Either patterns for error handling
+- Prefer throwing typed errors over generic Error
+- Use optional chaining (`?.`) and nullish coalescing (`??`)
+
+## Imports/Exports
+- Use named exports over default exports
+- Group imports: external libraries first, then internal modules
+- Use absolute imports with path mapping when possible
+
+## Testing
+- Write unit tests for all public functions
+- Use descriptive test names
+- Mock external dependencies
+- Aim for high test coverage (>80%)
+- Run tests with minimal verbosity to avoid session timeouts
+- Use grep/filter options to run specific tests when debugging
+- Prefer `npm test -- --silent` or `yarn test --silent` for automated runs

package/CHANGELOG.md

@@ -0,0 +1,49 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Security
+- Improved command execution security in CDK synthesis by using `shell: false` to prevent command injection vulnerabilities
+
+## [0.1.0] - 2024-12-10
+
+### Added
+- Initial public release with core cost analysis functionality
+- CONTRIBUTING.md with contribution guidelines
+- SECURITY.md with security policy and vulnerability reporting
+- GitHub issue templates for bug reports and feature requests
+- Pull request template for standardized contributions
+- Enhanced package metadata (homepage, bug tracker URLs)
+- Support for multiple AWS resource types
+- CloudFormation template parsing and comparison
+- Cost estimation using AWS Pricing API
+- CLI interface for local and CI/CD usage
+- GitLab integration for merge request comments
+- Configuration file support
+- Threshold enforcement
+- Multi-stack CDK application support
+- Automatic CDK synthesis
+- Pricing data caching
+- Property-based testing for core components
+
+### Supported Resources
+- AWS::Lambda::Function
+- AWS::S3::Bucket
+- AWS::DynamoDB::Table
+- AWS::RDS::DBInstance
+- AWS::EC2::Instance
+- AWS::ECS::Service
+- AWS::ApiGateway::RestApi
+- AWS::EC2::NatGateway
+- AWS::ElasticLoadBalancingV2::LoadBalancer (ALB/NLB)
+- AWS::CloudFront::Distribution
+- AWS::ElastiCache::CacheCluster
+- AWS::EC2::VPCEndpoint
+
+[Unreleased]: https://github.com/buildinginthecloud/cdk-cost-analyzer/compare/v0.1.0...HEAD
+[0.1.0]: https://github.com/buildinginthecloud/cdk-cost-analyzer/releases/tag/v0.1.0