0.7.1i: bind API migrations to the release lineage (api-migrations registry)

[GionaGranchelli]

Problem

The api-architecture check was red on the 0.7.1 → release/0.7.0 promotion (#440) with 13 failure-severity diagnostics in two classes:

1. 6 modules changed without an exact hash-bound migration entry — the real 0.7.0 → 0.7.1 API transitions had no registry entry against the release lineage.
2. 7 migration entries from a branch-only lineage that is no longer authoritative.

ApiCompatibilityVerifier accepts an entry in exactly two states: ACTIVE (from == base dump, to == current dump, version match) or retained history — which walks from the entry's toSha256 forward to the base dump hash. The 7 stale entries point at intermediate API states of the epic lineage that never landed in release/0.7.0, so their targets cannot reach that base by any chain. A linear successor chain cannot express a merge of two divergent API lineages, and the release lineage is the authoritative one.

Change

One file: config/quality/api-migrations.yml (+33 / −39).

• Added 6 ACTIVE entries, one per changed module, fromSha256 = release/0.7.0's committed dump, toSha256 = this line's dump, targetVersion: 0.7.0:
  :tramai-control-plane, :tramai-engine, :tramai-persistence-file, :tramai-persistence-jdbc, :tramai-spring-boot-starter-sovereign-ops, :tramai-spring-boot-starter-sovereign-persistence-jdbc.
• Removed the 7 non-authoritative entries. Git preserves their history; no retire-with-record mechanism, no DAG, no registry redesign.

Rule this establishes: api-migrations.yml describes the authoritative released API lineage, not every development branch that ever existed.

Not touched

• No module architecture change, no catalog reclassification.
• The 5 pre-existing stability inversions (:tramai-platform preview → :tramai-server internal) need no exemption and no follow-up: verifyStabilityInversions already emits those with DiagnosticSeverity.WARNING when the descriptor is present in the base dump — the existing base-dump comparison is the mechanism. No new baseline, no new abstraction.
• No production code, no gate, no analyzer, no workflow, no baseline.

Verification

• ./gradlew verify060Architecture -PchangePolicyBase=origin/release/0.7.0 — PASS, 10/10 checks, 0 failure-severity diagnostics (this is the exact Epic/0.7.1 control plane authority #440 base that was failing).
• ./gradlew verify060Architecture -PchangePolicyBase=2ba0fe46 (this PR's base) — PASS, 10/10, 0 failures.
• ./gradlew spotlessCheck verifyStaticAnalysis verifyStaticSafetyGuards — BUILD SUCCESSFUL.
• ./gradlew verifyChangePolicy -PchangePolicyBase=2ba0fe46 — PASSED, 1 changed file, no violations.
• Entry set verified semantically: 11 entries, all 6 new ACTIVE targets present, zero stale hashes remaining.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Correctness hinges entirely on the fromSha256 bindings to the release/0.7.0 base dumps, which are not accessible in this environment, and this gate-registry change for a release promotion warrants human verification of the base-dump hashes.

Review effort: Balanced
Findings: None

What changed in this PR

This PR rebinds the api-architecture quality gate's migration registry (config/quality/api-migrations.yml) to the authoritative release/0.7.0 lineage so the 0.7.1 → release/0.7.0 promotion (#440) passes. The registry authorizes each exact preview/experimental API transition via SHA‑256 hash pairs (fromSha256 = base-branch dump, toSha256 = current committed dump); the prior entries targeted intermediate epic-branch API states that never landed on release/0.7.0, so their targets could not reach the real base dump and failed ApiCompatibilityVerifier's ACTIVE/retained-history check.

Changes:

• Rebinds 6 changed modules to single ACTIVE entries whose fromSha256 is release/0.7.0's committed dump and toSha256 is this line's dump, all targetVersion: 0.7.0.
• Removes the non-authoritative branch-only lineage entries (including the chained two-step :tramai-control-plane history and the old :tramai-engine entry) and relocates the unchanged :tramai-scheduler entry.
• Rewrites the rationale/migration prose for the rebound entries to describe the cumulative 0.7.0 → 0.7.1 transition.

File	Description
config/​quality/​api-migrations.yml	Replaces branch-lineage migration entries with 6 release-lineage ACTIVE entries (control-plane, engine, persistence-file, persistence-jdbc, sovereign-ops, sovereign-persistence-jdbc) and removes stale entries so the architecture gate passes against release/0.7.0.

Verification performed during review: all eight toSha256 values (the six rebound modules plus the unchanged :tramai-scheduler/:tramai-orchestration) hash-match their current committed api/*.api dumps exactly; the file contains 11 entries with no duplicate (module, from, to) triples and no remnants of the removed stale hashes. The fromSha256 values bind to origin/release/0.7.0 dumps, which are not present in this review snapshot and therefore could not be independently confirmed.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.