feat/powerradar

accounts[targetEnv].slice(-4) on empty string produces empty suffix — both stacks consistently wrong but never mismatched

infra/cdk/src/stacks/services/utility/bills/csv-export/lambda.stack.ts:73

If a BatuConfig accidentally carries an empty account ID for an env, accountSuffix is '' and s3BucketName() produces a malformed bucket name. Storage would fail at creation time (CFN rejects the name), so Lambda would never deploy either. Both stacks use identical expressions so they remain in sync even in the degenerate case. Low because it only manifests on misconfiguration, not in normal operation.

First post-merge deploy will emit a CFN Delete on the old BucketParam SSM resource — expected, not an error

infra/cdk/src/stacks/services/utility/bills/csv-export/storage.stack.ts:75

The StringParameter (logical ID BucketParam) was a managed CFN resource in CsvExportStorageStack. Removing it from CDK produces a changeset that deletes the AWS::SSM::Parameter. This is intended and safe — the Lambda stack no longer reads it — but operators should expect to see a Delete action in cdk diff output on the first deploy.

addDependency bypassed by --exclusively in preview phases — comment is accurate but the guarantee is procedural, not structural

infra/cdk/src/app/main.ts:304

The comment correctly acknowledges this. If the phase ordering in preview-provision.yml ever changes, the physical-existence guarantee disappears silently — there is no synth-time enforcement.

No CDK synth test guards the naming invariant between the two stacks

infra/cdk/src/stacks/services/utility/bills/csv-export/lambda.stack.ts:74

The fix rests on both stacks independently computing the same s3BucketName(). A future refactor that changes service name or slice length in only one stack would produce a silently mismatched bucket name at runtime. A minimal aws-cdk-lib/assertions Template test asserting both outputs match would structurally prevent this. Absent from current practice — consistent with the repo's no-CDK-tests norm — but the introduced two-party naming invariant is exactly the kind of thing a synth test cheaply protects.

Two independent NameParts locals with different names (nameParts vs parts) — silent divergence risk

infra/cdk/src/stacks/services/utility/bills/csv-export/lambda.stack.ts:53

Lambda stack uses `nameParts`, Storage uses `parts`, both with identical field values. No compile-time coupling between them. A shared helper (e.g. csvExportNameParts(cfg, env)) would make the single-source explicit and eliminate the copy-paste surface.

Storage stack NOTE comment should cross-reference lambda.stack.ts so a reader doesn't re-add the SSM param

infra/cdk/src/stacks/services/utility/bills/csv-export/storage.stack.ts:75

The comment explains the removal well but doesn't say where the bucket name is now consumed. A reader maintaining Storage in isolation might re-add the param as a convenience. Adding '— see lambda.stack.ts' would make the coupling explicit.

--exclusively in comment needs context about preview-provision phase ordering

infra/cdk/src/app/main.ts:302

A reader unfamiliar with the preview deploy workflow won't know what 'an earlier phase' means. Could expand to name that preview-provision.yml deploys CsvExportStorage in Phase 1 before CsvExportLambda in Phase 2, making the comment self-contained.