Repository navigation
migration: bind mightyETL handoff to an immutable owner release #256
Description
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
- mightyETL canonical owner publishes an immutable release for the reviewed bounded-atomic-batch contract, with released API/schema and target commit unambiguous.
- Orgmetra re-reads that release and binds migration handoff to the released version plus immutable revision/provenance; no mutable branch dependency.
- Update ADR 0012, doctoring/traceability and code-level contract constants/validation so released identity is executable evidence rather than prose only.
- Re-run migration-adapter 100% statement/branch suite and current protected Foundation/security/review gates on the exact consumer head.
- 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 basedevelop@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 failRelease 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.
Activity
seonghobae commentedon Sep 6, 2026
Fresh canonical-owner lookup found
ContextualWisdomLab/mightyETL#165already 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.