# Reconcile two releases sharing a migration

Illustrative planning brief; no automatic product import.

Illustrative planning case: Two branches propose the same database migration number with different content.

## Decision

Resolve migration identity before either release enters deployment.

## Owned work

- Compare conflicting files
  - Owner role: Release investigator
  - Acceptance evidence: Migration numbers and content digests are retained.
- Choose canonical sequence
  - Owner role: Migration engineer
  - Acceptance evidence: Each schema change receives one stable ordered identity.
- Verify both upgrade paths
  - Owner role: Release reviewer
  - Acceptance evidence: Deploying either branch cannot apply conflicting content.

## Workflow

1. Compare both migration files, identifiers, content digests and known applied history.
2. Agree a canonical ordered sequence with unique identities and a compatible dependency boundary.
3. Validate both supported upgrade paths and escalate any history showing the same identity already applied with different content.

## Judgment

Stop if recorded migration history disagrees with file content.


## Filled illustrative release coordination record

The synthetic branches both contain migration 104: one adds a column and one adds an index. The agreed sequence assigns 104 to the column and 105 to the index, with both branches rebuilt against it. Renaming a file after one version was applied would require a separate reconciliation; the plan does not erase already-recorded migration history.
Decision: Resolve migration identity before either release enters deployment.
Review boundary: Stop if recorded migration history disagrees with file content.
This example uses synthetic conditions. Replace its observations with project evidence and record any changed assumptions before adopting the plan.


## Working artifact

- Canonical 104 / Column change owns this identity / Revisit if already applied differently
- Canonical 105 / Index follows compatible column state / Revisit on dependency change
- History preserved / Applied digests remain inspectable / Escalate conflicting recorded content


## Workflow questions

### Can one branch simply rename its migration?

Only before application; an already-applied identity must be reconciled against recorded database history.

### What proves the branches are aligned?

Both upgrade fixtures produce the same schema and migration ledger from the same starting state.

## Product connection

Use the manual work brief to discuss task ownership, review evidence and next actions in TeamBoost. Release execution remains a separate project workflow; the download performs no deployment or import.

Confirm account availability before adopting this manual outline.