Strata — Two Agents Build a Web App

A 291-line PRD, cpk init, and the codepakt board managing two agents building a complete narrative web application. The board decomposes the PRD into 15 tasks across 5 epics, wires dependencies, and agents pick up work via cpk task pickup. Review from the dashboard catches bugs, and the agents fix them in a second pass.

Result: A production-quality Astro web app managed through the codepakt board. 15 tasks, two agents, zero conflicts. Dashboard review found 4 real bugs, and the board tracked the fix cycle. View source on GitHub →

Why This Case Study Matters

The earlier case studies showed codepakt managing single-file browser projects. Strata tests whether the board handles a real multi-file web app:

Multiple files — 11 source files across pages, components, layouts, content, and styles
Framework complexity — Astro 5 with content collections, Zod schema validation, MDX rendering, dynamic routes
Real product — not a toy. Archive browsing, filtering, search, structured authoring, responsive design
Larger PRD — 291 lines with 20 sections covering information architecture, user flows, experience requirements, and exit criteria

This tests whether codepakt’s task board, dependency graph, and review workflow hold up on a project that actually matters.

The Setup

Goal: Build a narrative web app where each case study captures the decision, not just the outcome. Structured MDX authoring, archive with search and filters, detail pages with timeline and artifact components, responsive reading experience.

PRD: 291 lines covering product vision, user jobs, information architecture, functional requirements, experience requirements, success metrics, and milestone plan.

Initialization:

cpk server start
cpk init --name strata --prd ./PRD.md

An agent decomposed the PRD into 15 tasks across 5 epics with dependencies.

The Agents

Agent	Role	Tasks assigned
claude	Schema design, design system, content pipeline, detail page, timeline/artifact components, about page, filters, search, responsive polish, authoring docs	10
codex	App shell initialization, case study template + sample content, archive card component, archive homepage, search implementation	5

Task Breakdown

All 15 tasks from the actual codepakt board:

Task	Title	Priority	Agent	Epic
T-001	Initialize Strata app shell with static editorial stack	P0	codex	Foundation
T-002	Define case study schema and validation rules	P0	claude	Authoring
T-003	Create reusable case study template and seeded sample case	P0	codex	Authoring
T-004	Establish editorial design system and shared layout primitives	P0	claude	Reading Experience
T-005	Implement content loading and archive sorting pipeline	P0	claude	Archive
T-006	Build archive card component with case metadata	P1	codex	Archive
T-007	Ship archive homepage route	P1	codex	Archive
T-008	Implement case detail route and structured narrative rendering	P1	claude	Case Detail
T-009	Build timeline component for decision evolution	P1	claude	Case Detail
T-010	Build artifact media component with captions	P1	claude	Case Detail
T-011	Add archive filters and dedicated tag route	P1	claude	Discovery
T-012	Implement full-text local search across case content	P1	codex	Discovery
T-013	Create about page for product framing and methodology	P1	claude	Foundation
T-014	Document authoring workflow and publish path	P2	claude	Authoring
T-015	Polish responsive reading and discovery flows	P2	claude	Reading Experience

How Coordination Worked

Session 1: Foundation + Core Build (17:03–19:34)

17:03 — 15 tasks created from PRD decomposition.

17:05 — Codex picked up T-001 (app shell). Created the Astro project with MDX support, static output mode, base layout, and global CSS.

17:09 — T-001 completed. Dependency resolver unlocked T-002 (schema) and T-004 (design system). Claude started both in parallel.

17:14 — Claude completed T-002 (content collection schema with Zod validation — title, summary, date, tags, status, domain, outcome, timeline events, artifacts). This unlocked T-003 (template) and T-005 (content pipeline).

17:14–19:22 — The heavy lifting. Claude worked on T-004 (design system) and T-005 (archive pipeline) concurrently. These were the largest tasks — archive cards with outcome badges, case detail page layout, timeline component, artifact rendering, content loading and sorting. Both completed around 19:22.

19:23 — The interesting part. When Claude picked up T-008 (case detail route), T-006 (archive card), T-009 (timeline), and T-010 (artifacts), it found they were already implemented as part of T-004 and T-005. Instead of rebuilding, Claude verified the existing work matched the requirements and marked them complete instantly. Four tasks resolved in seconds.

19:24–19:34 — Claude knocked out the remaining tasks: T-013 (about page), T-011 (archive filters + tag routes), T-012 (search), T-014 (authoring docs in README), and T-015 (responsive polish with 720px and 480px breakpoints).

Session 2: Bug Fixes (19:41–19:45)

After review, Claude returned to fix real issues discovered during testing:

T-003: Artifact references pointed to .png files that didn’t exist. Created actual SVG placeholder artifacts.
T-007: Archive cards used nested <a> tags (invalid HTML — <a> inside <a>). Replaced with <div> cards + JS click handlers.
T-012: Search only indexed frontmatter fields. Added raw MDX body text to the search index.
T-006: Archive cards were missing the status badge (published/revisited). Added it.

Four targeted bug fixes, each addressing a real issue that would have broken the production site.

What Shipped

A complete editorial web application:

Archive homepage — card grid sorted by date, filterable by tag/domain/outcome, with full-text search
Case detail pages — structured narrative rendering with metadata header, timeline visualization, inline artifacts with captions
Content schema — Zod-validated MDX frontmatter with 7 required fields + 4 optional fields
Tag routes — /tags/:tag filtered archive views
About page — product framing, framework explanation, methodology
Design system — editorial typography, outcome badges, status indicators, tonal surface hierarchy
Responsive — 720px and 480px breakpoints for reading on any device
Authoring workflow — documented template, copy-and-fill pattern, validation at build time
Seeded content — “Dropping GraphQL for REST” sample case study exercising all schema fields
~1,200 lines of Astro/TypeScript/CSS across 11 source files

By the Numbers

Metric	Value
Total active build time	~30 minutes
Agents	2 (Claude, Codex)
Tasks created	15
Tasks completed	15
Tasks auto-resolved	4 (work already done by earlier tasks)
Bug-fix pass	4 targeted fixes
Merge conflicts	0
Task collisions	0
Source files	11 (pages, components, layouts, content, styles)
Lines of code	~1,200
PRD size	291 lines, 20 sections

Takeaways

The board manages real web apps, not just toys. Codepakt’s task board tracked 15 tasks across a project with content collections, Zod validation, dynamic routes, MDX rendering, and responsive breakpoints. The dependency graph enforced correct build order across 11 source files — no manual sequencing needed.

Review catches what agents miss. The first pass built the app. Dashboard review found four real bugs (invalid HTML, missing assets, incomplete search index, missing UI elements). The bugs went back on the board, agents fixed them surgically. This review-and-fix cycle is the core value of the loop — the board makes it structured, not ad hoc.

Task overlap resolves cleanly on the board. Four tasks were already done when agents picked them up — earlier tasks had absorbed the work. Agents verified and closed them. Codepakt’s granular task tracking means you see exactly what happened: no hidden work, no ambiguity about what’s done.

cpk init --prd turns a 291-line spec into a managed project. The PRD produced 15 well-scoped tasks across 5 epics with correct dependencies. The board became the single source of truth — monitor progress, review completions, and steer the build from one place.

The dependency graph scales to multi-file projects. Unlike single-file projects, Strata has 11 source files. The board’s dependency graph serialized access to shared abstractions (schema, layout, design tokens) and parallelized independent work (about page, search, filters). No manual coordination — the board handled it.