Team Split Assessment
Plan Under Review
Section titled “Plan Under Review”- File: specification.md
- Date: 2026-03-25
Complexity Analysis
Section titled “Complexity Analysis”| Factor | Value | Threshold | Assessment |
|---|---|---|---|
| Total tasks | 17 | 15 | Over |
| Distinct phases with sequential dependencies | 3 | 2 | Over |
| Distinct persona types needed | 3 (back-end, front-end, acceptance-test) | 4 | Under |
| Estimated working directories | 2 (ux-prototype worktree, hypothesis-mcp worktree) | 1 | Over |
| Cross-cutting concerns (handoffs, gates) | 2 (MCP extension before bridge, bridge before highlight layer) | 1 | Over |
| Tasks with external validation (builds, tests) | 4 (npm test, lint, Storybook build, manual verification) | 5 | Under |
Qualitative factors:
- Context window pressure: Moderate. The ux-prototype highlight layer (Component 5) is the largest single component and benefits from isolation. The hypothesis-mcp work is small but completely independent.
- Error blast radius: The hypothesis-mcp extension is a prerequisite for the bridge’s W3C-compliant target parameter. If it fails, the bridge can still function (just without CssSelector in the target) but the highlight layer loses its clean data path.
- Natural phase boundaries: Three clear checkpoints: (1) hypothesis-mcp extended and merged, (2) bridge infrastructure (proxy, transform, sidebar embed) working, (3) highlight layer rendering badges.
Recommendation
Section titled “Recommendation”Split into 2 runs — Run 1 handles the independent hypothesis-mcp repository (small, self-contained, has its own PR/merge lifecycle), and Run 2 handles all ux-prototype work (proxy, transform, bridge, sidebar, highlights). The ux-prototype work is internally sequential but belongs in a single run because a single front-end engineer can work through Components 1-5 without context loss.
Splitting the ux-prototype work further would add coordination overhead without meaningful benefit — the components are tightly coupled (bridge uses transform, highlights use the proxy, sidebar embed is a single file).
Proposed Runs
Section titled “Proposed Runs”| Run | Directory | Description | Tasks | Personas | Est. Duration |
|---|---|---|---|---|---|
| 1 | run-1-hypothesis-mcp/ | Extend hypothesis-mcp with target/CssSelector support, run tests, push, create PR, monitor | 6 | back-end-engineer | 0.5 day |
| 2 | run-2-ux-prototype/ | Proxy, transform, bridge integration, sidebar embed, highlight layer, testing, checks | 11 | front-end-engineer | 4.5 days |
Artifact Flow
Section titled “Artifact Flow”- Run 1 produces: Extended hypothesis-mcp with
targetparameter support (merged PR onmain). This enables the bridge in Run 2 to create annotations with W3C-compliantCssSelectortargets. - Run 2 consumes: The hypothesis-mcp API contract (not the package directly — the bridge calls the Hypothesis REST API, not the MCP). Run 2 can proceed in parallel with Run 1 since the bridge can POST annotations without the
targetfield; the CssSelector target is a progressive enhancement.
Parallelization: Run 1 and Run 2 can execute concurrently. Run 2 does not depend on Run 1’s completion — it uses the Hypothesis REST API directly. The target parameter is optional; the bridge works without it (annotations just lack the CssSelector in the target array, relying on the selector: tag instead).
Risk Analysis
Section titled “Risk Analysis”Benefits of splitting:
- hypothesis-mcp has its own PR/merge lifecycle (PR review, checks, CHANGELOG). Isolating it prevents the ux-prototype work from blocking on PR review.
- If the hypothesis-mcp PR has review comments, they can be addressed without disrupting the ux-prototype agent.
- Different repositories, different base branches, different worktrees — natural isolation.
Coordination overhead:
- Minimal. The two runs are largely independent. The only coupling is that Run 2’s transform module should eventually use the
targetparameter once Run 1 is merged. This can be added as a follow-up task or conditional code path.
Open Questions and Decisions
Section titled “Open Questions and Decisions”| # | Question | Options | Recommendation | Decision |
|---|---|---|---|---|
| 1 | Should Run 2 wait for Run 1 to merge before adding CssSelector to target? | (A) Wait and add after merge; (B) Add immediately with conditional fallback; (C) Skip target entirely, rely on selector tag | (B) Add the target field unconditionally — the Hypothesis API accepts it regardless of whether the MCP supports it | Pending |
| 2 | Storybook 10 middleware.ts format — is Express middleware still supported? | (A) Use middleware.ts; (B) Use Vite plugin; (C) Use Vercel serverless function | (A) Try middleware.ts first, verify during Run 2 implementation | Pending |
Copyright: © Arda Systems 2025-2026, All rights reserved