Team Split Assessment: Backend Services

Plan Under Review

Project: Backend Services for Item Image Upload
Specification: specification.md
Date: 2026-03-31

Complexity Analysis

Factor	Value	Threshold	Assessment
Total tasks	9 (T-1 through T-9)	15	Under
Sequential phases with dependencies	3 (Phase 0 → 2a → 2b → Release)	2	Over
Distinct persona types needed	2 (back-end-engineer, quality-reviewer)	4	Under
Working directories	3 (common-module, operations, documentation worktrees)	1	Over
Cross-cutting concerns	2 (cross-repo Gradle dependency, release ordering)	1	Over
Tasks with external validation	4 (`make clean build` × 2 repos, Helm lint, PR CI)	5	Under

Qualitative factors:

Natural phase boundary: Phase 2a (common-module) must complete before Phase 2b (operations) can begin — operations consumes the new common-module classes via Gradle includeBuild. This is a hard code dependency, not just a build dependency.
Error blast radius: A broken S3AssetService API in common-module would invalidate all operations work (endpoint, validator, module wiring). Isolating common-module in its own run ensures its API is stable and tested before operations work begins.
Context window pressure: Each run involves a single repository with focused concerns. Run 1 is pure library code; Run 2 is endpoint + validation + infrastructure wiring + release coordination. Separating them keeps each team focused.
Release ordering: common-module must be merged and published before operations can consume it from GitHub Packages (rather than local includeBuild). This release gate is a natural run boundary.

Recommendation

Split into 2 runs. The Gradle dependency between common-module and operations creates a hard phase boundary. Run 1 implements and tests the shared library; Run 2 consumes it for endpoint and validation work, then handles release coordination for both repositories.

Proposed Runs

Run	Directory	Description	Tasks	Personas	Est. Unique Files
1	`run-1-common-module/`	Phase 0 baseline + Phase 2a: `AssetKeyGenerator`, `CdnUrlResolver`, `S3AssetService`, CSV refactoring	T-1, T-2, T-3, T-4, T-5	back-end-engineer, quality-reviewer	~6 new/modified + ~6 test files
2	`run-2-operations/`	Phase 2b: CloudFormation, Helm, Module wiring, endpoint, validator + Release: CHANGELOGs, PRs, version catalog	T-6, T-7, T-8, T-9	back-end-engineer, quality-reviewer	~8 new/modified + ~4 test files

Artifact Flow

Run 1 produces:
  - AssetKeyGenerator.kt + AssetKeyGeneratorTest.kt
  - CdnUrlResolver.kt + CdnUrlResolverTest.kt
  - S3AssetService.kt + S3AssetServiceTest.kt
  - Refactored CsvS3ObjectDirectService.kt (CsvS3BucketDirectAccess)
  - Passing `make clean build` for common-module
  - Committed code on branch jmpicnic/item-image-upload-backend

Run 2 consumes:
  - common-module classes via Gradle includeBuild
    (AssetKeyGenerator, CdnUrlResolver, S3AssetService)
  - S3AssetService API contract (constructor signature, method signatures)

Run 2 produces:
  - Updated pre-install.cfn.yml, configmap.yaml, Module.kt
  - ImageUploadEndpoint + tests
  - Modified ItemValidator + tests
  - CHANGELOGs for both repositories
  - PRs for both repositories (common-module first, operations second)
  - Version catalog bump in operations

Run 2 cannot start implementation until Run 1’s exit gate passes — the common-module classes must compile and all tests must pass.

Risk Analysis

Risk	Mitigation via Split
S3AssetService API changes break operations code	Run 1 stabilizes the API before Run 2 begins; no parallel development against a moving target
CSV refactoring (T-5) introduces regressions	Isolated in Run 1; existing tests validate before operations work starts
AWS SDK presigned POST unavailability	Discovered in Run 1 (T-4); alternative approach chosen before Run 2 depends on it
Release ordering error (operations merged before common-module)	Run 2 handles both PRs with explicit sequencing; common-module PR created first
operations CI fails due to unpublished common-module	Expected behavior — user re-triggers after common-module is published

Coordination overhead is minimal: one handoff between runs, verified by a build gate. Both runs use the same worktrees and branches — no worktree creation needed between runs.

Open Questions and Decisions

#	Question	Options	Recommendation	Decision
1	Parallelism within Run 1: T-2 and T-3 are independent new files	(a) 2 back-end-engineers with intra-repo worktrees, (b) 1 back-end-engineer sequentially	(b) — files are small, worktree overhead exceeds time savings	Decided: (b)
2	Parallelism within Run 2: T-7 and T-8 are independent after T-6	(a) 2 back-end-engineers, (b) 1 back-end-engineer sequentially	(b) — same repo, both modify Module.kt, worktree merge risk	Decided: (b)
3	Quality review timing	(a) After each task, (b) After all implementation tasks in each run	(b) — single review pass per run is efficient for small task counts	Decided: (b)