Team Split Assessment

Plan Under Review

Specifications: Phase 1-4 specifications in the multi-pdf-print-and-bugs project directory
Date: 2026-04-07

Complexity Analysis

Factor	Value	Threshold	Assessment
Total tasks	28	15	Over
Sequential phases with dependencies	4	2	Over
Distinct persona types	4 (back-end, front-end, acceptance-test, technical-writer)	4	At limit
Working directories (repositories)	4 (operations, arda-frontend-app, api-test, documentation)	1	Over
Cross-cutting concerns	3 (response shape, config propagation, doc updates)	1	Over
Tasks with external validation	8+ (Gradle builds, Jest, Playwright E2E, Bruno API tests, doc build)	5	Over

Qualitative factors:

Context window pressure: High — Phase 2 involves coordinated changes across 3 modules in operations plus frontend. A single agent tracking all of this would exhaust context.
Error blast radius: Each phase has a natural checkpoint where all work is committed and validated. Failure in Phase 2 should not invalidate Phase 1’s bug fixes.
Natural phase boundaries: The 4 phases have strict sequential dependencies — each phase’s entry criteria require the previous phase to be complete and passing.

Recommendation

Split into 5 runs aligned with the existing phases. Each run is a self-contained unit with its own entry/exit criteria, agent assignments, and validation script. The phases are strictly sequential — no parallelism between runs.

Within runs, parallelism is possible:

Run 1: Backend and frontend tasks can run in parallel (different repos)
Run 2: PdfRenderService changes must complete before calling-service refactoring, but frontend work can start once the response shape is defined
Run 3: All backend changes are in operations (no repo parallelism), but the work is small enough for a single agent
Run 4: All work is in api-test (single repo, single agent)

Proposed Runs

Run	Directory	Description	Tasks	Personas	Agent Count
1	`run-1-bug-fixes/`	Fix notes mapping, add unmark-as-printed, frontend unmark action	7	back-end-engineer, front-end-engineer, technical-writer	2-3
2	`run-2-multi-template/`	Composite response, PdfRenderService.renderGroups(), calling service refactor, frontend handling	9	back-end-engineer, front-end-engineer, technical-writer	2-3
3	`run-3-diagnostics/`	Debug, dry-run, live-print parameters across all print endpoints	6	back-end-engineer, technical-writer	1-2
4	`run-4-api-tests/`	Bruno API tests for all print endpoint changes	6	acceptance-test-engineer	1
5	`run-5-api-proxy/`	Update TypeScript proxy types and methods	4	typescript-engineer	1

Runs 4 and 5 can execute in parallel after Run 3 (independent repositories).

Artifact Flow

Run 1 (Bug Fixes)
  Produces:
  - Fixed KanbanCardPrinter.kt (notes mapping)
  - New UNMARK event type + endpoint
  - Frontend unmark action
  - Updated design docs (Item Module, Kanban Cards)
  Commits to: operations (jmpicnic/multi-pdf-print-and-bugs)
              arda-frontend-app (jmpicnic/multi-pdf-print-and-bugs)
              documentation (jmpicnic/multi-pdf-print-and-bugs)
    ↓
Run 2 (Multi-Template)
  Consumes: Phase 1 committed code (notes fix, print status)
  Produces:
  - CompositeRenderResult + GroupRenderResult types
  - PdfRenderService.renderGroups() with batching/parallelism
  - Simplified ItemPrintingService + PrintLifecycleImpl
  - Frontend composite response handling
  - Updated design docs (PDF Render Module, Item Module)
  Commits to: operations, arda-frontend-app, documentation
    ↓
Run 3 (Diagnostics)
  Consumes: Phase 2 committed code (refactored pipeline)
  Produces:
  - debug/dry-run parameters on all print endpoints
  - PdfRenderService diagnostic passthrough
  - OpenAPI descriptions
  - Updated design docs
  Commits to: operations, documentation
    ↓
Run 4 (API Tests)                          ┐
  Consumes: Phases 1-3 deployed to local   │ parallel
  Produces: Updated Bruno test files        │ after
  Commits to: api-test                      │ Run 3
                                            │
Run 5 (API Proxy)                           │
  Consumes: Phases 1-3 API contracts        │
  Produces: Updated TypeScript types/methods│
  Commits to: api-proxy                     ┘

Risk Analysis

Risk	Mitigation
Phase 2 response shape change breaks frontend	Phase 2 includes frontend as a task; single-item prints also use composite shape for consistency
Parallel Documint calls overwhelm service	Semaphore-limited concurrency (default 3); configurable
Phase 4 tests require deployed code	Entry criteria explicitly require deployment; tests use `live-print=false` to avoid quota
Context window exhaustion in Phase 2 (largest phase)	Limit to 2-3 agents; PdfRenderService changes must complete before calling-service tasks start

Open Questions and Decisions

#	Question	Options	Recommendation	Decision
1	Should Run 1 and Run 2 share a worktree or use separate worktrees?	A) Shared (sequential commits) B) Separate (merge into integration branch)	A — runs are sequential, no parallel work between them. Same branch, sequential commits.	Agreed, Option A.
2	Should Run 4 deploy to local K8s or dev environment?	A) Local (requires helmInstallToLocal) B) Dev (requires merge + CI deploy)	A for development iteration, B for final validation. Run 4 spec should support both.	Agreed. Dev deployment gated on user prompt. CHANGELOG uses `[X.Y.Z-jmpicnic-MMDD]` format for pre-merge dev deploys.
3	Should documentation updates be a separate agent or folded into each backend/frontend agent?	A) Separate technical-writer agent B) Folded into implementation agents	B — doc updates are small and tightly coupled to the code changes. Separate agent adds coordination overhead for little value.	Agreed, Option B.