# Land pull requests that always collide one at a time

If two open pull requests in your repository will always conflict, tell ampm in `.ampm/serializing-paths.json`. ampm then lands them one after the other instead of letting both reach the merge gate and finding the conflict there.

## Declare a group

A migration numbering scheme is the usual case. Two branches that both add a `db/migrations/00NN_*.ts` file and both append to a migration registry conflict at whichever merges second.

```json .ampm/serializing-paths.json
{
  "version": 1,
  "groups": [
    {
      "name": "migrations",
      "paths": [
        "db/migrations/**",
        "db/migrations/index.ts"
      ]
    }
  ]
}
```

Each **group** lists path patterns that always conflict with each other. `**` crosses directories, `*` stays within one path segment, and anything else must match exactly. When two open tasks both touch a path in the same group, ampm orders their landing: one merges, then the other.

## What the order hint does

This is a landing-order hint and nothing more. It never stops the two tasks from being built in parallel, never creates a dependency between them, and never delays either one reaching ready to merge. It only changes which of two already-ready pull requests merges first. A wrongly declared or stale group costs at most one extra turn in the merge queue, and never a blocked implement turn.

An absent or malformed file changes nothing: ampm behaves as if you had declared no groups. This file is structured data, so the 16 KiB soft cap from the [guidance files page](/docs/guidance-files#limits) matters more here. An oversized file is cut off into invalid JSON, which degrades the same way, to no declared groups, rather than a partly applied declaration. Keep the group list short and specific.

## Collisions ampm finds without a declaration

ampm orders two colliding pull requests from their own diffs, with no file required. Two shapes count as a collision:

- Both pull requests change the same file.
- Both pull requests add a file with the same numeric prefix in the same folder.

The migration numbering case above is the second shape, so most repositories never need to write a group for it. The board says which kind applies: "declared group …" for a group from your file, or "both change …" or "both add a `NNNN` file in …" for one ampm inferred from the diff.

Your file still matters for a collision a diff can't show, such as two files that conflict for a reason outside their paths. You can't yet tell ampm that an inferred collision is a false one.

## Collisions ampm learns from a past conflict

When the merge gate sends a pull request back for a genuine conflict, ampm remembers which files were live on both branches. The next pair of open pull requests that carry one of those files lands one at a time, with no declaration needed.

This covers a case the diff rules can't see. They look at each pull request's own diff against the base branch at review time. A third pull request that lands in between can bring two already-reviewed ones into conflict, and neither one's diff shows it. The merge gate catches that the first time it happens, and ampm remembers the pairing for next time. The board names this kind "learned from a past conflict between …".

Learned pairs expire after 60 days. Like the rest of this page, they only affect landing order, and never block a build, a review or reaching ready to merge.