Small tasks from Lesson 44.2 make parallel work tempting: run three agents at once and finish three times faster. But small tasks allow parallel work only after dependencies are visible. More agents are not a plan. Without explicit relationships, two agents edit the same assumption in opposite directions and both "succeed" into a broken whole.

Three relationship types

Every pair of tasks stands in one of three relationships. Name it before assigning work:

Independent tasks are genuinely separable — different files, no shared assumptions. Contract-dependent tasks can proceed side by side only once the interface between them is written down: field name, type, null behavior, and who owns each side. Shared-risk tasks look parallelizable but are not: two writers on auth, a migration, or environment variables will collide. Give them a single implementation owner and let everyone else read, review, or prepare tests.

The costly error is treating contract-dependent or shared-risk work as independent. That is how the API returns publishedAt: null while the UI assumes a string is always present — each branch passes its own checks and the product still breaks.

The integration owner

The integration owner is the person — or explicitly designated agent session — authorized to combine accepted work, run end-to-end checks, update the roadmap, and decide whether a branch is ready for PR or merge. This is a coordination role, not a seniority prize. It goes to whoever is explicitly named for this slice, and the naming happens in writing on the task board.

Concretely, the integration owner:

• Collects finished task branches and validates the combined user flow, not just each task's checks.
• Runs the real response through the real interface — actual API output rendered in the actual UI.
• Returns small, specific fix tasks to the appropriate owner when contracts mismatch.
• Records the resolved contract and updates the roadmap and decision log.
• Says "not yet" to merges that pass locally but fail together.

Nobody else merges across lanes. That single gate prevents the "both done, nothing works" outcome.

Branches, worktrees, and task state

Reuse the branch-and-worktree setup from Class 41 — one named branch (and, when working in parallel, one worktree) per task — and now add task-level state so no agent must infer priority, dependency, or owner. A simple Markdown table or a basic issue tracker is enough at first; tooling can grow later, but visibility cannot wait.

Track at minimum: task ID, branch, owner, status, dependency, evidence, and blocking question.

| ID | Task | Branch | Owner | Status | Depends on | Evidence | Blocker |
| --- | --- | --- | --- | --- | --- | --- | --- |
| T1 | Show source dates on cards | task/source-dates | Amara | In review | Contract C1 | Component test + preview note | None |
| T2 | Draft summary from approved sources | task/draft-summary | Ben | Blocked | T1, Contract C1 | — | Needs final `publishedAt` null rule |
| T3 | Empty-state copy variants | task/empty-copy | Chidi | Ready | None | 3 copy options in docs | None |

T1 and T3 sit in separate parallel lanes; T2 cannot safely start its build until the contract it depends on settles. The board says so plainly, so no agent has to guess.

Do not merge just because it is done

A task is complete only in its own context until integration validates the combined flow. This is the "do-not-merge-until-integration" rule: an individual green check is necessary but not sufficient. The integration owner pulls the branches together, exercises the real user path, and only then approves PRs or merges.

The research-dashboard scenario shows why. An API branch adds publishedAt and its tests pass. A UI branch renders dates and its tests pass with mocked data. Combined, the real API returns null for two providers — a case the mock never included — and the UI crashes on a formatting call. The integration owner catches this by running a real response through the UI, returns one small task ("handle null publishedAt per contract C1") to the UI owner, and records the resolved contract: null renders as "Date unavailable," never as an empty crash. Two passing branches plus one honest integration check beat any number of isolated greens.

Practical exercise: build the board

Create a TASK-BOARD.md file with:

1. Three tasks with IDs, branches, and owners. 2. One dependency between two of them (contract-dependent or blocked). 3. One parallel lane of genuinely independent work. 4. One named integration owner at the top of the file.

Then ask an AI (or a friend) with only the board to answer: which tasks cannot safely start yet, and why? The board passes if the answer matches your intent with no extra explanation from you.

Finish line: a TASK-BOARD.md where no agent needs to infer priority, dependency, or owner — plus one correct "cannot start yet" identification.

Verify: pick any task on the board and confirm you can answer in ten seconds: who owns it, what blocks it, and what evidence will prove it. If any answer requires opening a chat transcript, the board is missing state.

Common failure mode: listing tasks without dependencies ("all three in progress") while two of them share an unwritten interface. If two tasks assume the same field, write the contract first and mark the dependency.

Check your understanding

1. Describe each of the three relationship types and the working rule for each. 2. What is the integration owner authorized to do, and why is the role about coordination rather than seniority? 3. Which seven pieces of task state should be visible, and why is a Markdown table enough at first? 4. Why is "both branches pass, so merge" unsafe? Use the null-date mismatch in your answer. 5. On a three-task board with one dependency, how do you decide which lane runs in parallel?