feat/slug-budget-24
safeviewing older commit47ccfe3 · incrementalPR #320reviewed 2026-07-16 20:30 UTC0H · 0M · 1L · 6I- Purpose
- Enable isolated CDK preview stacks for branches with descriptive names — the old 17-char cap was too tight and regularly forced name conflicts or skipped CDK preview altogether.
- Goal
- Raise the branch-slug budget from 17 to 24 chars via a preview-only name abbreviation pass, with structural enforcement (BranchNameLengthAspect) and an audit script to verify no resource exceeds the budget.
- Sub-goals
- SG-1: token abbreviation map (helioscope, subscriber, schedule, coordinator, aggregator) + exact rename for helio-materialize-persist
- SG-2: MAX_BRANCH_NAME_LEN 17→24 + deterministic head18-<4hex> fallback for slugs >24
- SG-3: BranchNameLengthAspect — synth-time guard that fails with actionable error when a resource would exceed the budget
- SG-4: preview-provision.yml gate updated 17→24
- SG-5: CLAUDE.md + infra/cdk/CLAUDE.md documentation updated
- SG-6 (this commit): add powerradar→radar to the abbreviation map (new integration brand from int-base)
- What
- Added `powerradar: 'radar'` to BRANCH_TOKEN_ABBREV in naming.ts so branches containing the powerradar integration token fit within the 24-char slug budget.
- Why
- powerradar is a new device-integration brand (hoisted from the int-base branch). Without the abbreviation, a branch like 'feat/powerradar-collection' would use 10 chars on the token alone; with 'radar' (5 chars) the slug has more room. The BranchNameLengthAspect would fail synth if the unabbreviated form exceeded the budget on any real resource name.
- Areas
- .github/workflows/preview-provision.yml+13−8infra/cdk+220−16CLAUDE.md+1−1.gitignore+1−1
- Blast
- 9 files, +235/-26 across infra/cdk (naming, aspect, audit script, main.ts, CLAUDE.md), .github/workflows, CLAUDE.md, .gitignore. Preview-only — zero impact on deployed dev/stg/prod resources.
Findings · 8
correctness2
Future collision risk: 'radar' is now a reserved abbreviated form
infra/cdk/src/lib/naming.ts:35
BRANCH_TOKEN_ABBREV maps 'powerradar' → 'radar'. A future entry for a bare 'radar' token would conflict with the already-abbreviated form. No current bug — the whole-token matching (hyphen-bounded) ensures a hypothetical '-radar-' resource token is left untouched today. Worth noting in a comment that 'radar' is a reserved abbreviated form so future contributors don't unknowingly add a clashing entry.
Confirm 'powerradar' service names use this exact spelling (no internal hyphen)
infra/cdk/src/lib/naming.ts:35
The token 'powerradar' abbreviates only when it appears as an exact hyphen-bounded token (e.g. 'powerradar-collector'). If any CDK service or resource uses 'power-radar' (two tokens), the abbreviation silently does not apply. Verify the integration's vendor directory and CDK service name use 'powerradar' (one word) consistently.
security1
Abbreviation applied preview-only — no blast radius on deployed resources
infra/cdk/src/lib/naming.ts:36
The new entry is preview-only (branch slug present). Un-branched envs (main-dev/stg/prod) are unaffected. No IAM boundary or policy ARN concern arises.
conventions2
Ordering is consistent — 'powerradar' correctly follows 'helioscope' alphabetically within the brand group
infra/cdk/src/lib/naming.ts:36
Both helioscope and powerradar are integration brand names placed before the generic resource terms (subscriber, schedule, coordinator, aggregator). 'helioscope' < 'powerradar' alphabetically — ordering is correct within the implied group.
Abbreviation style is consistent with existing entries
infra/cdk/src/lib/naming.ts:36
'powerradar' → 'radar' follows the same prefix-truncation style as 'helioscope' → 'helio': drop the brand-qualifier prefix, keep the distinctive trailing word.
tests1
No dedicated unit test for powerradar→radar — not a gap given structural enforcement
infra/cdk/src/lib/naming.ts:36
The token-split + dictionary-lookup logic is already exercised by existing tests for other entries. BranchNameLengthAspect (synth-time enforcement) and the audit script cover the new entry structurally. A dedicated test would be purely redundant for a one-line dictionary addition.
improvement2
Selective abbreviation list is audit-driven but undocumented
infra/cdk/src/lib/naming.ts:33
Nothing in the code explains why e.g. 'apsystems' (9 chars) or 'fronius' (7 chars) are absent while 'powerradar' (10 chars) is present. A one-line comment such as '// Entries added on demand when BranchNameLengthAspect fails synth; other brands fit the 24-char budget without abbreviation' would prevent future contributors from adding unnecessary entries or assuming the list is comprehensive.
apsystems (9 chars) is the next plausible budget risk among un-abbreviated brands
infra/cdk/src/lib/naming.ts
Among un-abbreviated integration brands, 'apsystems' is the longest at 9 chars. The system is self-enforcing (BranchNameLengthAspect will catch any future violation), so no change is needed now. Informational only.