migration: bind mightyETL handoff to an immutable owner release

[seonghobae]

Finding

The governed migration-handoff boundary records MIGHTY_ETL_REVISION = ba8911f50ed20a39927a0d51c0cf20f9b7c91820 as reviewed foreign-contract evidence. The revision is immutable, but a fresh ContextualWisdomLab/mightyETL release inventory on 2026-09-06 is still empty. That is not sufficient for Orgmetra's released-contract-only consumer rule.

By contrast, the paired MHTML ETL Gateway revision 779254927abb1e7cee80fd949907ccd03f9fc7be is the target of immutable release v0.4.0, so that side already has a release binding.

This is a dependency/acceptance finding, not permission to copy mightyETL source into Orgmetra, query its tables, weaken the boundary, or close the existing migration delta. PR #71 may retain the reviewed mightyETL revision as design/proposal evidence while Draft, but Orgmetra must not describe it as a published production owner contract or complete release acceptance until the canonical owner publishes an immutable contract release.

Canonical upstream release/provenance ownership remains ContextualWisdomLab/mightyETL#165. Fresh owner read confirms #165 is still open with status planned and explicitly keeps licensing, source identity, non-vacuous coverage, security/review and protected-head integration as prerequisites. Orgmetra must not create a competing mightyETL release path.

Required repair order

1. mightyETL canonical owner publishes an immutable release for the reviewed bounded-atomic-batch contract, with released API/schema and target commit unambiguous.
2. Orgmetra re-reads that release and binds migration handoff to the released version plus immutable revision/provenance; no mutable branch dependency.
3. Update ADR 0012, doctoring/traceability and code-level contract constants/validation so released identity is executable evidence rather than prose only.
4. Re-run migration-adapter 100% statement/branch suite and current protected Foundation/security/review gates on the exact consumer head.
5. Only then may a release-ready Orgmetra head claim the mightyETL execution boundary as a released dependency.

Current exact consumer evidence — 2026-09-06

• Orgmetra fix(migration): harden governed handoff runtime integrity #71 exact head: 883c4bc9dc62b712de5f2a355251d405d2810957, current protected base develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, open · Draft · mechanically mergeable.
• Foundation 34018193669: SUCCESS.
• SAST 34018193647: SUCCESS.
• Security 34018193696: SUCCESS.
• CodeQL 34018193653: FAILURE only after both Python and Actions shards successfully request current-head dispatch and then fail Release runner or enforce current-head CodeQL verdict; this wrapper result does not establish a source/SARIF defect.
• mightyETL published releases: 0.
• mightyETL feat(people): add assignment category correction provenance #165 remains the canonical release/provenance owner and is still prerequisite-gated.

The improved Orgmetra exact-head source/security evidence does not satisfy the missing upstream immutable-release contract and is not a reason to bypass CodeQL or approval governance.

[seonghobae]

Fresh canonical-owner lookup found ContextualWisdomLab/mightyETL#165 already owns reproducible release/provenance and is still open. Its current sequencing explicitly forbids publishing merely to manufacture a release before its licensing/source-identity/coverage/security prerequisites are satisfied. Therefore this Orgmetra issue is a consumer-side prerequisite, not a second release writer: wait for #165's normal protected-owner release, then bind Orgmetra to that immutable version/revision and rerun exact consumer acceptance. Do not create an Orgmetra-local substitute release or copy the owner contract.