cdk-cost-analyzer 0.1.1

package/.kiro/specs/github-actions-ci/design.md

@@ -0,0 +1,281 @@
+# Design Document: GitHub Actions CI/CD Integration
+
+## Overview
+
+This design implements a GitHub Actions workflow that automatically runs tests, linting, and type checking whenever code is pushed to the repository or a pull request is created. The workflow ensures code quality by validating all changes before they are merged.
+
+The system uses GitHub Actions' native YAML-based workflow configuration to define a CI pipeline that mirrors the local development environment. The workflow leverages caching mechanisms to optimize execution time and runs tests in parallel where possible.
+
+## Architecture
+
+### Workflow Structure
+
+```
+GitHub Event (push/PR)
+    ↓
+Workflow Trigger
+    ↓
+Setup Environment
+    ├── Checkout Code
+    ├── Setup Node.js
+    └── Restore Cache
+    ↓
+Install Dependencies
+    ↓
+Quality Checks (parallel)
+    ├── Linting (ESLint)
+    ├── Type Checking (TypeScript)
+    └── Build Verification
+    ↓
+Test Execution
+    ├── Unit Tests
+    └── Property-Based Tests
+    ↓
+Report Results
+```
+
+### Workflow File Location
+
+The workflow will be defined in `.github/workflows/ci.yml` following GitHub Actions conventions.
+
+### Runner Environment
+
+- **Platform**: Ubuntu latest (ubuntu-latest)
+- **Node.js Version**: 18.x (matching project minimum requirement)
+- **Package Manager**: npm (default for the project)
+
+## Components and Interfaces
+
+### 1. Workflow Configuration
+
+**File**: `.github/workflows/ci.yml`
+
+**Triggers**:
+- `push`: All branches
+- `pull_request`: All branches targeting any base branch
+
+**Jobs**:
+- `test`: Main job that runs all quality checks and tests
+
+**Steps**:
+1. Checkout repository code
+2. Setup Node.js environment
+3. Cache node_modules
+4. Install dependencies
+5. Run linting
+6. Run type checking
+7. Build project
+8. Run test suite
+
+### 2. Caching Strategy
+
+**Cache Key**: Based on `package-lock.json` hash
+**Cache Path**: `node_modules`
+**Restore Keys**: Fallback to most recent cache if exact match not found
+
+### 3. Test Execution
+
+**Command**: `npm run test:silent`
+**Framework**: Vitest
+**Test Types**:
+- Unit tests (`.test.ts` files)
+- Property-based tests (`.property.test.ts` files)
+
+### 4. Quality Checks
+
+**Linting**: `npm run eslint`
+**Type Checking**: `npm run lint` (runs `tsc --noEmit`)
+**Build**: `npm run build`
+
+## Data Models
+
+### Workflow Configuration Schema
+
+```yaml
+name: string              # Workflow name
+on: object               # Trigger events
+  push: object
+    branches: string[]
+  pull_request: object
+    branches: string[]
+jobs: object
+  [jobName]: object
+    runs-on: string      # Runner platform
+    strategy: object     # Matrix strategy (optional)
+      matrix: object
+        node-version: number[]
+    steps: array
+      - name: string
+        uses: string     # Action to use
+        with: object     # Action inputs
+```
+
+### Cache Configuration
+
+```typescript
+interface CacheConfig {
+  path: string;          // Path to cache
+  key: string;           # Cache key with hash
+  restore-keys: string;  # Fallback keys
+}
+```
+
+## Correctness Properties
+
+*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
+
+### Property Reflection
+
+Analyzing the acceptance criteria for redundancy:
+
+**1.1-1.5**: Workflow execution basics - 1.1 and 1.5 are testable, 1.2 overlaps with step ordering, 1.3 is command verification, 1.4 is GitHub's built-in behavior
+**2.1-2.4**: PR behavior - only 2.1 is testable (trigger config), rest is GitHub's built-in behavior
+**3.1-3.4**: Environment consistency - 3.1 and 3.3 are properties about matching configurations, 3.2 and 3.4 are examples
+**4.1-4.4**: Performance - 4.1 is example (cache exists), 4.2 is property (step ordering), 4.3-4.4 are runtime behavior
+**5.1-5.4**: Quality checks - 5.1 is property (step ordering), 5.2 is example (step exists), 5.3-5.4 are tool/GitHub behavior
+**6.1-6.4**: Multi-version - 6.1 is property (matrix config), rest is GitHub's built-in matrix behavior
+
+After reflection, we consolidate into focused properties that avoid redundancy and focus on what we can actually test in the workflow configuration.
+
+### Property 1: Dependencies install before tests
+*For any* workflow configuration, dependency installation steps should appear before test execution steps in the step sequence
+**Validates: Requirements 1.2**
+
+### Property 2: Test failures are not suppressed
+*For any* test step in the workflow, it should not have continue-on-error enabled, ensuring failures propagate correctly
+**Validates: Requirements 1.5**
+
+### Property 3: Node.js version matches project requirements
+*For any* workflow configuration, the Node.js version specified should be compatible with the minimum version in package.json
+**Validates: Requirements 3.1**
+
+### Property 4: Test command matches package.json
+*For any* workflow configuration, the test command used should match the test script defined in package.json
+**Validates: Requirements 3.3**
+
+### Property 5: Cache restores before dependency installation
+*For any* workflow configuration with caching enabled, the cache restore step should appear before the dependency installation step
+**Validates: Requirements 4.2**
+
+### Property 6: Quality checks precede tests
+*For any* workflow configuration, linting and type checking steps should appear before test execution steps in the step sequence
+**Validates: Requirements 5.1**
+
+### Property 7: Matrix versions are valid
+*For any* workflow configuration with matrix strategy, all specified Node.js versions should be valid and supported versions
+**Validates: Requirements 6.1**
+
+## Error Handling
+
+### Workflow Failures
+
+**Dependency Installation Failure**:
+- Cause: Network issues, invalid package-lock.json
+- Handling: Workflow fails immediately, no subsequent steps run
+- User Action: Check package-lock.json integrity, retry workflow
+
+**Linting Failures**:
+- Cause: Code style violations
+- Handling: Workflow fails, reports specific violations
+- User Action: Fix linting errors locally, push fixes
+
+**Type Checking Failures**:
+- Cause: TypeScript compilation errors
+- Handling: Workflow fails, reports type errors
+- User Action: Fix type errors locally, push fixes
+
+**Build Failures**:
+- Cause: Compilation errors, missing dependencies
+- Handling: Workflow fails, reports build errors
+- User Action: Fix build errors locally, verify with `npm run build`
+
+**Test Failures**:
+- Cause: Failing unit or property-based tests
+- Handling: Workflow fails, reports test failures with details
+- User Action: Fix failing tests locally, verify with `npm test`
+
+### Cache Failures
+
+**Cache Miss**:
+- Cause: First run or cache expired
+- Handling: Install dependencies from scratch
+- Impact: Slower workflow execution
+
+**Cache Corruption**:
+- Cause: Interrupted previous workflow
+- Handling: Fallback to fresh installation
+- Impact: Slower workflow execution
+
+## Testing Strategy
+
+### Unit Tests
+
+Unit tests will verify the workflow configuration structure:
+
+1. **Workflow file exists**: Verify `.github/workflows/ci.yml` exists
+2. **Trigger configuration**: Verify push and pull_request triggers are configured
+3. **Node.js version**: Verify correct Node.js version is specified
+4. **Required steps**: Verify all required steps are present in correct order
+5. **Cache configuration**: Verify cache paths and keys are correctly configured
+
+### Property-Based Tests
+
+Property-based tests will verify universal properties of the workflow configuration:
+
+1. **Property 1 Test**: Generate various GitHub event payloads, verify workflow triggers
+2. **Property 2 Test**: Parse workflow file, verify environment matches package.json requirements
+3. **Property 3 Test**: Verify cache configuration includes restore-keys for fallback
+4. **Property 4 Test**: Verify quality check steps appear before test steps in workflow
+5. **Property 5 Test**: Verify test step includes failure detection
+6. **Property 6 Test**: Verify all required quality check steps are present
+
+### Integration Testing
+
+The workflow itself serves as an integration test:
+- Each push/PR will validate the workflow works end-to-end
+- GitHub Actions UI provides detailed logs for debugging
+- Failed workflows prevent merging (when branch protection is enabled)
+
+### Testing Framework
+
+- **Framework**: Vitest (already configured in project)
+- **Property Testing Library**: fast-check (already in devDependencies)
+- **Test Location**: `test/github-actions/` directory
+- **Minimum Iterations**: 100 per property test
+
+## Implementation Notes
+
+### Projen Integration
+
+The project uses Projen for configuration management. However, since Projen has `github: false` configured, we will manually create the GitHub Actions workflow file. This is intentional as the project primarily uses GitLab CI but wants to add GitHub Actions support.
+
+### Multi-Version Testing (Optional)
+
+The design supports testing on multiple Node.js versions using GitHub Actions matrix strategy:
+
+```yaml
+strategy:
+  matrix:
+    node-version: [18.x, 20.x, 22.x]
+```
+
+This is optional and can be enabled based on project requirements.
+
+### Branch Protection
+
+While not part of this implementation, teams should consider enabling GitHub branch protection rules to:
+- Require status checks to pass before merging
+- Require pull request reviews
+- Prevent force pushes to protected branches
+
+### Performance Considerations
+
+- **Caching**: Reduces dependency installation time from ~2-3 minutes to ~30 seconds
+- **Parallel Execution**: Quality checks can run in parallel with proper job configuration
+- **Silent Test Mode**: Using `test:silent` reduces log output and speeds up execution
+
+### Security Considerations
+
+- **Dependency Scanning**: Consider adding `npm audit` step
+- **Secret Management**: Use GitHub Secrets for any required credentials
+- **Permissions**: Workflow runs with default GITHUB_TOKEN permissions

package/.kiro/specs/github-actions-ci/requirements.md

@@ -0,0 +1,86 @@
+# Requirements Document
+
+## Introduction
+
+This feature implements automated testing through GitHub Actions CI/CD pipeline. When code is pushed to the GitHub repository, the system will automatically run all tests to ensure code quality and catch issues early in the development cycle.
+
+## Glossary
+
+- **GitHub Actions**: GitHub's built-in CI/CD platform that automates workflows
+- **Workflow**: An automated process defined in YAML that runs on specific GitHub events
+- **CI/CD**: Continuous Integration/Continuous Deployment - automated testing and deployment practices
+- **Test Suite**: The collection of all unit tests, property-based tests, and integration tests
+- **Push Event**: A Git push operation that triggers the workflow
+- **Pull Request**: A proposed code change that can trigger validation workflows
+- **Runner**: The virtual machine environment where GitHub Actions workflows execute
+- **Job**: A set of steps that execute on the same runner
+- **Node.js Environment**: The runtime environment required to execute TypeScript tests
+
+## Requirements
+
+### Requirement 1
+
+**User Story:** As a developer, I want tests to run automatically on every push to GitHub, so that I can catch bugs early and maintain code quality.
+
+#### Acceptance Criteria
+
+1. WHEN a developer pushes code to any branch THEN the system SHALL trigger the test workflow automatically
+2. WHEN the workflow executes THEN the system SHALL install all project dependencies before running tests
+3. WHEN the workflow runs tests THEN the system SHALL execute the complete test suite including unit tests and property-based tests
+4. WHEN tests complete THEN the system SHALL report the test results in the GitHub Actions interface
+5. WHEN tests fail THEN the system SHALL mark the workflow run as failed with exit code non-zero
+
+### Requirement 2
+
+**User Story:** As a developer, I want to see test results for pull requests, so that I can verify changes before merging.
+
+#### Acceptance Criteria
+
+1. WHEN a pull request is created THEN the system SHALL trigger the test workflow automatically
+2. WHEN a pull request is updated with new commits THEN the system SHALL re-run the test workflow
+3. WHEN tests complete on a pull request THEN the system SHALL display the test status on the pull request page
+4. WHEN tests fail on a pull request THEN the system SHALL prevent merging until tests pass or checks are overridden
+
+### Requirement 3
+
+**User Story:** As a developer, I want the CI environment to match my local development environment, so that tests behave consistently.
+
+#### Acceptance Criteria
+
+1. WHEN the workflow initializes THEN the system SHALL use the Node.js version specified in the project configuration
+2. WHEN the workflow installs dependencies THEN the system SHALL use the same package manager as local development
+3. WHEN the workflow runs tests THEN the system SHALL use the same test commands as documented in package.json
+4. WHEN the workflow executes THEN the system SHALL set environment variables consistent with test requirements
+
+### Requirement 4
+
+**User Story:** As a developer, I want fast feedback from CI tests, so that I can iterate quickly on my code.
+
+#### Acceptance Criteria
+
+1. WHEN the workflow runs THEN the system SHALL cache Node.js dependencies between runs
+2. WHEN dependencies are cached THEN the system SHALL restore the cache before installing new dependencies
+3. WHEN the workflow completes THEN the system SHALL finish within a reasonable time limit for the test suite size
+4. WHEN tests run THEN the system SHALL execute tests in parallel where possible
+
+### Requirement 5
+
+**User Story:** As a team lead, I want to enforce code quality standards, so that all merged code meets our quality bar.
+
+#### Acceptance Criteria
+
+1. WHEN a workflow is defined THEN the system SHALL include linting checks before running tests
+2. WHEN a workflow is defined THEN the system SHALL include type checking for TypeScript code
+3. WHEN quality checks fail THEN the system SHALL report specific failures with actionable error messages
+4. WHEN all checks pass THEN the system SHALL mark the workflow as successful
+
+### Requirement 6
+
+**User Story:** As a developer, I want to test on multiple Node.js versions, so that I can ensure compatibility across environments.
+
+#### Acceptance Criteria
+
+1. WHERE multiple Node.js versions are specified THEN the system SHALL run tests on each version in parallel
+2. WHEN testing on multiple versions THEN the system SHALL report results separately for each version
+3. WHEN any version fails THEN the system SHALL mark the overall workflow as failed
+4. WHEN all versions pass THEN the system SHALL mark the overall workflow as successful

package/.kiro/specs/github-actions-ci/tasks.md

@@ -0,0 +1,115 @@
+# Implementation Plan
+
+- [x] 1. Create GitHub Actions workflow directory structure
+  - Create `.github/workflows/` directory
+  - _Requirements: 1.1, 2.1_
+
+- [x] 2. Implement basic CI workflow configuration
+  - [x] 2.1 Create workflow file with triggers for push and pull_request events
+    - Define workflow name and trigger events
+    - Configure to run on all branches
+    - _Requirements: 1.1, 2.1_
+  
+  - [x] 2.2 Configure job with Ubuntu runner
+    - Set up job to run on ubuntu-latest
+    - _Requirements: 3.1_
+  
+  - [x] 2.3 Add checkout step
+    - Use actions/checkout@v4 to clone repository
+    - _Requirements: 1.2_
+  
+  - [x] 2.4 Add Node.js setup step
+    - Use actions/setup-node@v4
+    - Configure Node.js version 18.x
+    - _Requirements: 3.1_
+  
+  - [x] 2.5 Write property test for Node.js version matching
+    - **Property 3: Node.js version matches project requirements**
+    - **Validates: Requirements 3.1**
+
+- [x] 3. Implement dependency caching
+  - [x] 3.1 Add cache configuration step
+    - Use actions/cache@v4 or setup-node caching
+    - Configure cache key based on package-lock.json
+    - Set cache path to node_modules
+    - _Requirements: 4.1, 4.2_
+  
+  - [x] 3.2 Write property test for cache step ordering
+    - **Property 5: Cache restores before dependency installation**
+    - **Validates: Requirements 4.2**
+
+- [x] 4. Add dependency installation step
+  - [x] 4.1 Add npm ci command
+    - Use npm ci for clean installation
+    - _Requirements: 1.2, 3.2_
+  
+  - [x] 4.2 Write property test for dependency installation ordering
+    - **Property 1: Dependencies install before tests**
+    - **Validates: Requirements 1.2**
+
+- [x] 5. Implement quality check steps
+  - [x] 5.1 Add linting step
+    - Run npm run eslint
+    - _Requirements: 5.1_
+  
+  - [x] 5.2 Add type checking step
+    - Run npm run lint (tsc --noEmit)
+    - _Requirements: 5.2_
+  
+  - [x] 5.3 Add build verification step
+    - Run npm run build
+    - _Requirements: 5.1_
+  
+  - [x] 5.4 Write property test for quality checks ordering
+    - **Property 6: Quality checks precede tests**
+    - **Validates: Requirements 5.1**
+
+- [x] 6. Implement test execution step
+  - [x] 6.1 Add test step with silent mode
+    - Run npm run test:silent
+    - _Requirements: 1.3, 3.3_
+  
+  - [x] 6.2 Write property test for test command matching
+    - **Property 4: Test command matches package.json**
+    - **Validates: Requirements 3.3**
+  
+  - [x] 6.3 Write property test for test failure propagation
+    - **Property 2: Test failures are not suppressed**
+    - **Validates: Requirements 1.5**
+
+- [x] 7. Add optional matrix strategy for multi-version testing
+  - [x] 7.1 Add matrix configuration (optional)
+    - Configure matrix with Node.js versions [18.x, 20.x, 22.x]
+    - Update setup-node step to use matrix.node-version
+    - _Requirements: 6.1_
+  
+  - [x] 7.2 Write property test for matrix version validity
+    - **Property 7: Matrix versions are valid**
+    - **Validates: Requirements 6.1**
+
+- [x] 8. Create workflow validation tests
+  - [x] 8.1 Write unit test for workflow file existence
+    - Verify .github/workflows/ci.yml exists
+    - _Requirements: 1.1_
+  
+  - [x] 8.2 Write unit test for trigger configuration
+    - Verify push and pull_request triggers are configured
+    - _Requirements: 1.1, 2.1_
+  
+  - [x] 8.3 Write unit test for required steps presence
+    - Verify all required steps are present
+    - _Requirements: 5.2_
+
+- [x] 9. Documentation and finalization
+  - [x] 9.1 Update README with CI badge and information
+    - Add GitHub Actions status badge
+    - Document CI workflow behavior
+    - _Requirements: 1.4_
+  
+  - [x] 9.2 Add workflow documentation
+    - Create docs/GITHUB_ACTIONS.md explaining the CI setup
+    - Document how to run checks locally
+    - _Requirements: 3.3_
+
+- [x] 10. Checkpoint - Ensure all tests pass
+  - Ensure all tests pass, ask the user if questions arise.

package/.kiro/specs/nlb-calculator-test-coverage/design.md

@@ -0,0 +1,190 @@
+# Design Document: NLBCalculator Test Coverage Enhancement
+
+## Overview
+
+This design outlines a comprehensive testing strategy for the NLBCalculator class to improve test coverage from 15.82% to over 90%. The approach focuses on unit testing all public methods, private method behavior through public interfaces, and property-based testing for mathematical calculations.
+
+## Architecture
+
+### Testing Framework Stack
+- **Jest**: Primary testing framework (already configured in project)
+- **fast-check**: Property-based testing library for mathematical property validation
+- **TypeScript**: Maintain type safety in test code
+
+### Test Organization
+```
+test/pricing/calculators/
+├── NLBCalculator.test.ts          # Main unit tests
+└── NLBCalculator.property.test.ts # Property-based tests
+```
+
+## Components and Interfaces
+
+### Test Doubles and Mocks
+
+#### MockPricingClient
+```typescript
+interface MockPricingClient extends PricingClient {
+  getPrice(params: PriceQuery): Promise<number | null>;
+  // Configure responses for different scenarios
+  setHourlyRate(rate: number | null): void;
+  setNLCURate(rate: number | null): void;
+  setError(error: Error): void;
+}
+```
+
+#### Test Resource Factory
+```typescript
+interface TestResourceFactory {
+  createNetworkLoadBalancer(properties?: Partial<any>): ResourceWithId;
+  createApplicationLoadBalancer(): ResourceWithId;
+  createGenericResource(type: string): ResourceWithId;
+}
+```
+
+### Test Categories
+
+#### 1. Method Coverage Tests
+- `supports()` method with various resource types
+- `calculateCost()` with different load balancer configurations
+- Region normalization and prefix generation methods
+
+#### 2. Calculation Logic Tests
+- NLCU calculation from different usage metrics
+- Cost combination logic (hourly + NLCU costs)
+- Default parameter application
+
+#### 3. Error Scenario Tests
+- Null pricing responses
+- Network/API errors
+- Invalid resource configurations
+
+#### 4. Integration Tests
+- End-to-end cost calculation with realistic scenarios
+- Multiple region testing
+- Custom parameter combinations
+
+## Data Models
+
+### Test Data Structures
+
+#### PricingScenario
+```typescript
+interface PricingScenario {
+  name: string;
+  region: string;
+  hourlyRate: number | null;
+  nlcuRate: number | null;
+  expectedResult: Partial<MonthlyCost>;
+  shouldThrow?: boolean;
+}
+```
+
+#### UsageParameters
+```typescript
+interface UsageParameters {
+  newConnectionsPerSecond?: number;
+  activeConnectionsPerMinute?: number;
+  processedBytesGB?: number;
+}
+```
+
+#### RegionTestCase
+```typescript
+interface RegionTestCase {
+  regionCode: string;
+  expectedNormalizedName: string;
+  expectedPrefix: string;
+}
+```
+
+## Testing Strategy
+
+### Unit Testing Approach
+- **Isolated Testing**: Mock PricingClient to control responses
+- **Boundary Testing**: Test edge cases for NLCU calculations
+- **Error Path Testing**: Verify graceful error handling
+- **State Testing**: Verify constructor parameter handling
+
+### Property-Based Testing Configuration
+- **Library**: fast-check for generating test inputs
+- **Iterations**: Minimum 100 iterations per property test
+- **Generators**: Custom generators for realistic AWS usage patterns
+
+## Error Handling
+
+### Test Error Scenarios
+1. **Pricing API Failures**: Network timeouts, service errors
+2. **Invalid Responses**: Null rates, malformed data
+3. **Resource Validation**: Non-NLB resources, missing properties
+4. **Region Handling**: Unsupported regions, invalid region codes
+
+### Expected Behaviors
+- Zero cost returned for error scenarios
+- Descriptive error messages in assumptions
+- No exceptions thrown from public methods
+- Graceful degradation with confidence level "unknown"
+
+## Correctness Properties
+
+*A property is a characteristic or behavior that should hold true across all valid executions of a system—essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
+
+### Property 1: Resource Type Rejection
+*For any* resource type string that is not "AWS::ElasticLoadBalancingV2::LoadBalancer", the supports method should return false
+**Validates: Requirements 1.2**
+
+### Property 2: Valid MonthlyCost Structure
+*For any* network load balancer resource with valid pricing data, calculateCost should return a MonthlyCost object with non-negative amount, "USD" currency, and non-empty assumptions array
+**Validates: Requirements 1.3**
+
+### Property 3: Non-NLB Resource Zero Cost
+*For any* resource with Type property that is not "network" or undefined, calculateCost should return zero cost with appropriate assumptions
+**Validates: Requirements 1.4**
+
+### Property 4: New Connections NLCU Calculation
+*For any* positive number of new connections per second, the NLCU calculation should equal the connections divided by 800
+**Validates: Requirements 2.1**
+
+### Property 5: Active Connections NLCU Calculation
+*For any* positive number of active connections per minute, the NLCU calculation should equal the connections divided by 100,000
+**Validates: Requirements 2.2**
+
+### Property 6: Processed Bytes NLCU Calculation
+*For any* positive number of processed GB per month, the NLCU calculation should equal the GB divided by 730 (converting to hourly)
+**Validates: Requirements 2.3**
+
+### Property 7: Maximum NLCU Selection
+*For any* set of NLCU values calculated from different metrics, the billing NLCU should equal the maximum value from the set
+**Validates: Requirements 2.4**
+
+### Property 8: Custom Parameter Override
+*For any* valid custom usage parameters provided to the constructor, those parameters should be used instead of the corresponding default values in calculations
+**Validates: Requirements 2.5, 5.4**
+
+### Property 9: Unsupported Region Passthrough
+*For any* region string not in the supported regions map, normalizeRegion should return the original string unchanged
+**Validates: Requirements 3.2**
+
+### Property 10: Unsupported Region Empty Prefix
+*For any* region string not in the supported regions map, getRegionPrefix should return an empty string
+**Validates: Requirements 3.4**
+
+### Property 11: Exception Handling
+*For any* exception thrown by the pricing client, calculateCost should return zero cost with the error message included in assumptions
+**Validates: Requirements 4.3**
+
+### Property 12: Successful Calculation Structure
+*For any* valid pricing data (non-null hourly and NLCU rates), calculateCost should return a cost with detailed breakdown in assumptions and "medium" confidence
+**Validates: Requirements 4.4, 6.4**
+
+### Property 13: Cost Addition
+*For any* valid hourly cost and NLCU cost, the total cost should equal their sum
+**Validates: Requirements 6.1**
+
+### Property 14: Hourly Cost Calculation
+*For any* positive hourly rate, the monthly hourly cost should equal the rate multiplied by 730
+**Validates: Requirements 6.2**
+
+### Property 15: NLCU Cost Calculation
+*For any* positive NLCU rate and NLCU per hour, the monthly NLCU cost should equal rate × NLCU per hour × 730
+**Validates: Requirements 6.3**