Serialize or allocate repository-global migration namespaces

[willwashburn]

Problem

Factory dispatches independent schema-changing issues in parallel even when they allocate from a serialized global migration namespace (for example, Drizzle migration numbers). Each branch chooses “the next” number; whichever PR lands first invalidates the others and forces repeated renumber/merge repair.

This is not a dependency-ordering problem. The issues can be logically unrelated and have no declared prerequisite edge; they merely contend for the same exclusive namespace.

Observed cost

Evidence comes from head-of-experiments’ survey of the 2026-07-18/19 Factory run in AgentWorkforce/hoopsheet:

• nine migration-renumbering commits, including 0012→0013, 0013→0015 (“0013 taken by emoji reactions”), and 0014→0015 (“0014 taken by @mentions”);
• merge rounds 1/2/3/final on PR feat(fleet): dispatch the relay backend through @agent-relay/sdk placement #71 and four additional merge rounds on PR feat(fleet): roster-reconciliation exit detection for the relay backend #72;
• 22 of 54 commits (41% of the run) performed integration repair rather than product work;
• workload commit 533a33a added speculative migration-journal entries as a workaround for a conflict the orchestrator should prevent.

Emoji reactions and @mentions are independent features. Their collision is proof that prerequisite graphs cannot model the shared counter.

Not a duplicate of #133

Factory #133, “Dependency-aware dispatch ordering,” handled declared prerequisite chains: issue B consumes issue A’s output, so they should not dispatch together. It cannot see independent issues contending for a shared migration namespace, and closed on 2026-07-20 without covering resource allocation or schema-merge serialization.

Expected behavior

Factory should prevent parallel work from racing an exclusive, repository-global migration namespace, without requiring fake dependency edges between unrelated issues.

Fix directions

Either:

1. allocate/reserve migration identifiers centrally at merge time, or
2. detect schema/migration-touching changes and serialize their merge/rebase queue while allowing implementation to proceed in parallel.

Whichever mechanism is chosen should be reusable for other exclusive repository resources, observable in run reports, and covered by a test with two independent issues that both create the next migration.

[willwashburn]

The renumbering defect produces a worse side effect: hand-edited migration metadata

Two observations from AgentWorkforce/hoopsheet, both verified independently:

1. 533a33a wrote speculative entries into drizzle/meta/_journal.json — "preempt: add 0015 (standings) and 0016 (custom-domains) to journal to avoid future merge conflict" — to dodge a collision this issue describes.
2. origin/main currently carries 19 migrations and 18 snapshots. drizzle/meta/0018_snapshot.json does not exist, while _journal.json does register idx 18 → 0018_targeted_player_invites. The e2e PR that added 0018 hand-authored the migration without generating its snapshot.

Consequence of (2): the next drizzle-kit generate diffs schema.ts against the 0017 snapshot and re-emits the invites DDL as a duplicate migration. That DDL is ALTER TABLE invites ADD COLUMN ×2 plus three ADD CONSTRAINT with no IF NOT EXISTS, so a duplicate errors on the first statement rather than double-applying — deploys break loudly rather than corrupting data.

Why this belongs on this issue

These are not two unrelated mistakes. When renumbering is routine, hand-editing drizzle's bookkeeping becomes routine — and the bookkeeping is precisely what must not be hand-edited. The serialized-namespace collision described above is the upstream cause; hand-maintained _journal.json and meta/*.json are the downstream habit it creates.

So the fix is broader than allocating migration numbers:

Never require a human or an agent to edit _journal.json or meta/*.json by hand.

Suggested addition to acceptance criteria:

• Migration metadata (journal + snapshots) is always tool-generated, never hand-authored, on any factory-produced change.
• A schema-touching change that lands without its generated snapshot fails the verification gate rather than merging.
• The number-allocation fix must not leave metadata reconciliation as a manual step — removing the manual step is the fix, not documenting it better.

Evidence credit: head-of-experiments' hoopsheet survey and its project lead.