Team Split Assessment

Plan Under Review

Project: AWS Infrastructure for Item Image Upload
Specification: specification.md
Date: 2026-03-30

Complexity Analysis

Factor	Value	Threshold	Assessment
Total file changes	20	15	Over
Sequential phases with dependencies	2 (Phase 0 → Phase 1)	2	At threshold
Distinct persona types needed	2 (devops-engineer, quality-reviewer)	4	Under
Working directories	1 (infrastructure repo)	1	At threshold
Cross-cutting concerns	2 (root account deploy, CI integration)	1	Over
Tasks with external validation	5 (cdk synth, deploy-root, amm.sh, verify-image-cdn, npm test)	5	At threshold

Qualitative factors:

Natural phase boundary: Phase 0 (DNS) must be deployed and verified before Phase 1 (partition resources) can use the assets hosted zone and certificate. This is a hard deployment gate — not just a code dependency.
Error blast radius: A root account deployment error affects all infrastructures; isolating it in its own run limits blast radius.
Context window: The two phases use different stack files, different deployment commands, and different verification methods. Separating them keeps each run focused.

Recommendation

Split into 2 runs. The deployment gate between Phase 0 (root + infra DNS) and Phase 1 (partition CDK constructs) is a natural boundary. Run 1 modifies shared global infrastructure (root account, infrastructure stacks); Run 2 creates new partition-scoped constructs and tests. Separating them limits the blast radius of root account changes and enables independent validation.

Proposed Runs

Run	Directory	Description	Files	Personas	Est. Tasks
1	`run-1-dns-foundation/`	Phase 0: Root zone, infra subdomain zone + cert, deploy-root.sh, ci-root-check.js, ari-configuration	6 modified/new	devops-engineer	8
2	`run-2-partition-resources/`	Phase 1: CDK constructs, stacks, partition wiring, tests, CI, verification script, multi-env deployment	16 modified/new	devops-engineer, quality-reviewer	23

Artifact Flow

Run 1 produces:
  - assets.arda.cards hosted zone (deployed to root account)
  - <infra>.assets.arda.cards subdomain zone + ACM cert (deployed to infra account)
  - deploy-root.sh script
  - ASSETS_DOMAIN constant + assetsDomain() function in ari-configuration.ts
  - Updated ImportingStack with assetsHostedZone + assetsCertificateArn

Run 2 consumes:
  - assetsHostedZone and assetsCertificateArn from ImportingStack
    (available via cross-stack imports after Run 1 deployment)
  - assetsDomain() for CDN custom domain construction

Run 2 cannot start implementation until Run 1 is deployed (not just coded) — the hosted zone and certificate must exist in AWS for the CDN construct to create DNS records and use the certificate.

However, Run 2 can start coding constructs and tests against LocalStack or mocked values before Run 1 is deployed. The deployment gate applies only to integration testing and the verification script.

Risk Analysis

Risk	Mitigation via Split
Root account deployment failure blocks all work	Run 1 is small (5 files); failure is diagnosed quickly before Run 2 begins
ACM certificate DNS validation fails (slow propagation)	Isolated in Run 1; Run 2 doesn’t wait for cert issuance to start coding
New constructs break existing stacks	Run 2’s snapshot tests and ci-check catch regressions before deployment
Root account has no CI automation	Run 1 includes deploy-root.sh; manual execution is acceptable for a one-time setup

Coordination overhead is minimal: one handoff between runs, verified by a deployment gate (not a code review gate).

Open Questions and Decisions

#	Question	Options	Recommendation	Decision
1	Should Run 2 start coding before Run 1 is deployed?	(a) Wait for full deployment, (b) Start coding against mocked imports	(b) — constructs can be developed and unit-tested independently; only integration testing needs live infrastructure	Pending
2	Worktree strategy	(a) Single worktree per run, (b) Shared worktree	(a) — each run gets its own branch for clean PRs	Pending