Team Split Assessment

Plan Under Review

File: 3-frontend-implementation/specification.md
Date: 2026-04-07

Complexity Analysis

Factor	Value	Threshold	Assessment
Total tasks	~50 (7 phases × 6-12 tasks each)	15	Over
Distinct phases with sequential dependencies	8 (3.1, 3.2, 3.3a, 3.3b, 3.4, 3.5, 3.6, 3.7)	2	Over
Distinct persona types needed	3 (front-end-engineer, typescript-engineer, technical-writer)	4	Under
Estimated working directories	4 (api-proxy, ux-prototype, arda-frontend-app, documentation)	1	Over
Cross-cutting concerns (handoffs, gates)	7 (review gates between every phase + package publishes)	1	Over
Tasks with external validation (builds, tests)	8+ (npm publish, make check, npm run build, make pr-checks per phase)	5	Over

Qualitative factors:

Context window pressure: High — each phase introduces new types, hooks, and wiring. A single team lead tracking all 50+ tasks, their intermediate outputs, and 4 repos would exhaust context by Phase 3.5.
Error blast radius: Each phase has a review gate that validates output before the next phase begins. Natural isolation points exist at every gate.
Natural phase boundaries: Strong — each phase produces a published artifact (npm package) or committed/tested code that is consumed by the next phase. The phases are already designed as sequential handoffs.

Recommendation

Split — 5 factors exceed thresholds, context window pressure is high, and the project has 7 natural phase boundaries with explicit review gates. Each run maps to one or two specification phases, keeping the scope manageable for a single agent session.

The user has decided on strictly sequential execution with a single agent per run. Parallelization may be introduced at execution time if schedules require it — the run boundaries support this since Runs 1 and 2 operate on different repositories.

Proposed Runs

Run	Directory	Phases	Repository	Tasks	Persona	Description
1	`run-1-api-proxy-publish/`	3.1	api-proxy	7	typescript-engineer	Publish `@arda-cards/api-proxy` with RequestContext, image upload method
2	`run-2-lifecycle-framework/`	3.2	ux-prototype + documentation	7	front-end-engineer	Lifecycle types, `useDraft<T>` hook, architecture documentation
3	`run-3a-component-updates/`	3.3a	ux-prototype	6	front-end-engineer	Update 5 image components (pre-infrastructure#439)
4	`run-3b-cors-integration/`	3.3b	ux-prototype	2	front-end-engineer	`crossOrigin` canvas support (requires infrastructure#439)
5	`run-4-design-system-publish/`	3.4	ux-prototype	7	front-end-engineer	Build, verify, publish `@arda-cards/design-system`
6	`run-5-bff-routes/`	3.5	arda-frontend-app + documentation	10	front-end-engineer	BFF routes, SSRF validator, CDN signer, rate limiter
7	`run-6-spa-integration/`	3.6	arda-frontend-app + documentation	12	front-end-engineer	TanStack hooks, CDN cookies, grid/form wiring
8	`run-7-release/`	3.7	all repos	8	front-end-engineer	CHANGELOGs, PRs, merge ordering, cleanup

Artifact Flow

Run 1 (api-proxy)
  └─ produces: @arda-cards/api-proxy published to GitHub Packages
       └─ consumed by: Run 6 (BFF routes import api-proxy)

Run 2 (lifecycle framework)
  └─ produces: lifecycle types + useDraft<T> in ux-prototype canary
       └─ consumed by: Run 3a (component updates use lifecycle types)

Run 3a (component updates, pre-infra)
  └─ produces: 5 updated components (minus crossOrigin)
       └─ consumed by: Run 3b (adds crossOrigin to the same components)

Run 3b (CORS integration)
  └─ requires: infrastructure#439 deployed
  └─ produces: complete component updates with crossOrigin support
       └─ consumed by: Run 5 (design system publish includes all changes)

Run 5 (design system publish)
  └─ produces: @arda-cards/design-system published to GitHub Packages
       └─ consumed by: Run 7 (SPA imports design system)

Run 6 (BFF routes)
  └─ produces: src/server/ with 4 BFF routes + 3 utilities
       └─ consumed by: Run 7 (SPA hooks call BFF routes)

Run 7 (SPA integration)
  └─ produces: TanStack hooks, CDN cookies, grid/form wiring
       └─ consumed by: Run 8 (release)

Run 8 (release)
  └─ produces: PRs, CHANGELOGs, merged code

Risk Analysis

Splitting mitigates:

Context exhaustion — each run has a focused scope (one repo, one concern)
Blast radius — a failure in Run 6 (BFF routes) doesn’t corrupt Run 2 (lifecycle framework) work
Review quality — review gates between runs allow focused review of one concern at a time

Coordination overhead:

Minimal — strictly sequential execution means no inter-agent coordination
Artifact handoff is via published npm packages (Runs 1, 5) or committed code (all others)
The documentation worktree accumulates commits across all runs; a single PR is created in Run 8

Run 3a/3b split risk:

The split at infrastructure#439 boundary means Run 3b might wait for infrastructure deployment
Mitigation: Run 3a completes and validates all non-CORS work; Run 3b is small (2 tasks) and can execute as soon as infrastructure is ready
If infrastructure is already deployed when Run 3a completes, Runs 3a and 3b can merge into a single execution

Open Questions and Decisions

#	Question	Options	Recommendation	Decision
1	Merge Run 3a + 3b if infrastructure#439 is already deployed?	A: always run separately, B: merge if infra ready	B (avoids unnecessary overhead)	Decided: B
2	Run 1 uses typescript-engineer vs front-end-engineer?	A: typescript-engineer (api-proxy is a library), B: front-end-engineer	A (api-proxy is a Node.js library, not React)	Decided: A