Skip to content

v1.7.1 — stage migrations in the feature folder, promote at implement#2

Merged
genkovich merged 2 commits into
mainfrom
fix/stage-migrations-promote-at-implement
May 29, 2026
Merged

v1.7.1 — stage migrations in the feature folder, promote at implement#2
genkovich merged 2 commits into
mainfrom
fix/stage-migrations-promote-at-implement

Conversation

@genkovich
Copy link
Copy Markdown
Owner

Problem

data-model (backbone step 5) wrote shippable .up.sql/.down.sql straight into the live migrations/ tree during the design stage — four steps before implement. A stray migrate up (CI, a teammate's loop, a deploy) could apply a half-designed schema to a real DB, and the global sequence number was grabbed early, colliding with other in-flight features.

Fix — stage, then promote at build time

  • data-model stages the pair under docs/features/<slug>/migrations/<NN>_*.{up,down}.sql (feature-local ordinal). It detects the repo's convention but does not pick the global number or touch the live tree. (Mirrors the existing _drift/ staging discipline.)
  • implement's layer: migration task promotes each staged file into the live migrations/ — next free number / fresh timestamp, in ordinal order, SQL copied verbatim — then applies + reverts it. Integration tests run against the promoted schema. The number is assigned at promote-time → no early-grab collisions across concurrent features.
  • tasks — a migration task's files_hint is the staged path; DoD = «promoted, then applies/reverts cleanly».

Touched

data-model/SKILL.md + migrations-baseline.md; implement/SKILL.md + inputs.md / team-exec.md / workflow-exec.md; tasks/SKILL.md + task.md; README.md; manifests → v1.7.1.

Seed fixtures («NOT in migrations/») and the greenfield scaffold (which legitimately creates the live migrations/ infra) are unaffected.

Verification

validate_plugin.py: 177 checks PASS (manifests agree on 1.7.1); markdown link sweep clean.

🤖 Generated with Claude Code

genkovich and others added 2 commits May 29, 2026 12:57
…mplement

data-model wrote shippable .up.sql/.down.sql straight into the LIVE migrations/
tree during the design stage — four steps before implement. A stray `migrate up`
(CI, a teammate's loop, a deploy) could then apply a half-designed schema to a real
DB, and the global sequence number was grabbed early, colliding with other in-flight
features. Both are removed by staging.

- data-model now writes the pair under docs/features/<slug>/migrations/<NN>_*.{up,down}.sql
  (feature-local ordinal); it detects the repo's convention but does NOT pick the global
  number or touch the live tree. Mirrors the existing _drift/ staging discipline.
- implement's layer:migration task PROMOTES each staged file into the live migrations/
  (next free number / fresh timestamp, in ordinal order), copies the SQL verbatim, then
  applies + reverts it; the feature's integration tests run against the promoted schema.
  Number assigned at promote-time → no early-grab collisions across concurrent features.
- tasks: a migration task's files_hint is the staged path; DoD = promoted, then applies/reverts.
- Updated: data-model SKILL + migrations-baseline template, implement SKILL + inputs/team-exec/
  workflow-exec, tasks SKILL + task template, README flow rows.

validate_plugin.py: 177 checks PASS; markdown link sweep clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@genkovich genkovich merged commit b9b1d00 into main May 29, 2026
1 check passed
@genkovich genkovich deleted the fix/stage-migrations-promote-at-implement branch May 29, 2026 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant