Three coding agents, one codebase: how a phase of SocialHub was built in parallel

We did the shared work first and froze it. One foundation commit carried everything the three jobs had in common: a single migration with every table the phase needed, the entities and repositories, the provider interface, the per-network limits, the cross-module lookup contracts, the error codes, the audit actions and the frontend types. Each agent started from that commit and was told which of those files it could read but not change.

Each job then ran in isolation: its own git worktree and branch, its own database and its own port, so no agent could break a sibling's running system. Each had a reserved migration number in case it needed a schema change. One shared brief, prepended to every job's own instructions, set the conventions (layering, tenancy checks on every endpoint, the error envelope, pagination) and a definition of done: a clean backend test run, a clean frontend build, integration tests that include a tenancy-denial case, and a design note listing every limitation shipped.

The brief also said what to do when the contract was wrong: stop and report it, do not edit the shared file, because a sibling depends on its current shape. Shared documents such as the README were off limits and merged centrally. Integration was a separate, central step, verified by a scripted run through the browser: connect an account, upload media, attach it and publish.

It was not flawless, and the repository says so. In a later build a parallel session claimed a migration number another job had planned to use, and a merge once dropped a model setting from structured AI requests, a bug no response would have revealed. Both became rules: check the next free migration number at build time, and a test that asserts the setting survives onto the request.