Repository navigation
evidence(OMN-18081): union-resolve — bind OMN-18081 to omniweb#364 - #8800
Merged
Merged
Conversation
Hand-bound OCC companion for OmniNode-ai/omniweb#364, binding AC1, AC2 and AC3. Hand-minted because the occ-companion-effect job could not publish. On run 34355977342 it failed with "the lane declares security_protocol=SASL_PLAINTEXT / sasl_mechanism=SCRAM-SHA-256, but KAFKA_SASL_USERNAME and/or KAFKA_SASL_PASSWORD are not set in this job's environment", which is the autobind outage OMN-18073 records. Without a companion, #364 has no receipt to cite and fails the Receipt Gate on the missing citation rather than on anything wrong with the change. Same union-resolve shape as OCC#8760 (omninode_infra#1266) and OCC#8787 (omninode_infra#1274). AC4 is deliberately NOT bound: it is the staging readback on dev.app after delivery, and it cannot be proven before this merges and reaches onex-dev. Rule 24 is stated rather than implied in the contract summary — the .201 compose dev lane runs no dashboard, so there is no lab surface for this change and no lab pass is claimed. Receipts carry real probe output, not asserted output. The behavior-proof receipt records the RED control taken in-lane: 10 of 17 fail at acec8de, 17/17 pass at the pushed head, and the 7 that pass in BOTH states are the OMN-18011 protection pins, which is the correct result for a change that must preserve them. Rule 22 respected: no credential was rotated, re-issued, revoked or minted; no secret value was read, printed or decoded; no cluster object was mutated.
occ-preflight eligibility and verify/verify both failed on the same cause, missing_occ_self_bind: the OMN-18081 evidence verified (receipts PASS, hashes bound) but nothing bound a receipt to the OCC PR carrying the contract. Appends `occ-self-bind-pr-8800` and its PASS receipt. The entry is APPENDED, never edited into an existing one, so both existing entries keep their contract_entry_sha256 byte-for-byte — recomputed and confirmed identical (9ea64111... and 9c56e1ea...), which is the OMN-13888 property that makes a later append non-destructive. The whole-file hash does move on an append, so contract_sha256 is recomputed on the three receipts from 48c7f629... to 79ef9bbf.... That is legal here and is not the add-only violation the OMN-18056 lane recorded: those three receipts are NEW in this same unmerged PR, not merged evidence being rewritten. The Receipt Honesty Gate checks contract_sha256 against the CURRENT contract unconditionally on pr_number, so leaving them stale would have traded one red gate for another. No binds_ac on the self-bind entry: it is an infrastructure binding, not evidence for an acceptance criterion, matching the landed precedents (OMN-18048 #8783, OMN-18026 #8791). Probe run for real, not asserted: `gh pr view 8800` returns state OPEN on headRefName jonah/omn-18081-occ-companion-pr-364, exit 0. All four receipts re-validated against the contract with the core hash functions, plus a negative control proving two entries do not share an entry hash. Companion for omniweb#364 (OMN-18081). Autobind is down this window (OMN-18073).
jonahgabriel
added a commit
that referenced
this pull request
Sep 9, 2026
The eligibility gate refused with reason=missing_occ_self_bind, and it was right: it verified every receipt and every hash binding for OMN-18081, then found no receipt binding to THIS evidence PR. A companion that cannot resolve a PASS receipt for itself is not admissible, whatever it proves about the product PR. A SECOND self-bind exists because OCC#8800 merged before the server half of this ticket was written, so OMN-18081's two halves arrive on two evidence PRs rather than one. occ-self-bind-pr-8800 is left exactly as merged and keeps its own per-entry hash. Whole-file contract_sha256 is refreshed on the three receipts THIS branch owns. The two inherited from #8800 keep their merged bytes untouched: their binding is contract_entry_sha256, whole-file is only the fallback consulted when a receipt carries no entry hash, and rewriting a merged receipt to chase a fallback field would be editing evidence rather than adding it. yamlfmt was run BEFORE the hashes were computed rather than after, so the committed bytes are the formatted bytes and the whole-file hash cannot be stale the moment it lands. All four pre-existing per-entry hashes were recomputed after the reflow and are byte-identical, which is the property the per-entry hash is defined over parsed YAML to have. No credential was rotated, re-issued, revoked or minted; no secret value was read or printed; no cluster object was mutated.
jonahgabriel
added a commit
that referenced
this pull request
Sep 9, 2026
…nfra#1280 (#8805) * evidence(OMN-18081): union-resolve — bind the server half, omninode_infra#1280 The operator clarified the intent at ~14:27Z: "It seems like the input is fine but it should be for the label for the API key so that people can mint more than one API key." That reframes OMN-18081 from "the input is missing" (it was not) to "can a customer actually hold several labelled keys", and the ticket's scope item 3 asked the SERVER to be read rather than assumed. Three suspects, one real. There is no per-tenant key cap — MAX_API_KEY_LIMIT is a pagination bound enforced in list_api_keys, not in the mint. Nothing on the create path revokes or replaces an incumbent. So a key with a DISTINCT label was never blocked, which is the headline intent and already worked. The third was real. uq_tenant_api_keys_tenant_id_name_active correctly refuses a second ACTIVE key under the same name, but that refusal reached the customer as a bare 500: it raised ApiKeyValidationError, the router caught nothing, and there is no add_exception_handler for any ApiKeyError in the service, so omniweb rendered its no-detail fallback. omninode_infra#1280 makes it a typed 409. Appended, never edited — and verified empirically rather than asserted. The two existing entries' contract_entry_sha256 values were recomputed after the append AND after the yaml hook's reflow of the new entry, and both are byte-identical to the values already carried by the receipts merged on this branch. That is the append-stability OMN-13888 exists for, and the reflow is exactly the case the per-entry hash is defined over parsed YAML to survive. The new receipts' whole-file contract_sha256 is recomputed for the post-reflow bytes. The older receipts' copies of that field are now stale, which is harmless and expected: it is only ever the FALLBACK, consulted when a receipt carries no entry hash, and both of those carry one. Union-resolve on the same ticket, as OCC#8760 did for omninode_infra#1266: autobind is not minting companions in this window (OMN-18073), so both halves of OMN-18081 bind here rather than to two companions that would collide on the same contract path. Both receipts carry real probe output, run at c911a5d0. AC4c and the staging readback are deliberately NOT bound — they cannot be proven before this merges and reaches onex-dev. No credential was rotated, re-issued, revoked or minted; no secret value was read or printed; no cluster object was mutated. * evidence(OMN-18081): self-bind the server-half companion to OCC PR #8805 The eligibility gate refused with reason=missing_occ_self_bind, and it was right: it verified every receipt and every hash binding for OMN-18081, then found no receipt binding to THIS evidence PR. A companion that cannot resolve a PASS receipt for itself is not admissible, whatever it proves about the product PR. A SECOND self-bind exists because OCC#8800 merged before the server half of this ticket was written, so OMN-18081's two halves arrive on two evidence PRs rather than one. occ-self-bind-pr-8800 is left exactly as merged and keeps its own per-entry hash. Whole-file contract_sha256 is refreshed on the three receipts THIS branch owns. The two inherited from #8800 keep their merged bytes untouched: their binding is contract_entry_sha256, whole-file is only the fallback consulted when a receipt carries no entry hash, and rewriting a merged receipt to chase a fallback field would be editing evidence rather than adding it. yamlfmt was run BEFORE the hashes were computed rather than after, so the committed bytes are the formatted bytes and the whole-file hash cannot be stale the moment it lands. All four pre-existing per-entry hashes were recomputed after the reflow and are byte-identical, which is the property the per-entry hash is defined over parsed YAML to have. No credential was rotated, re-issued, revoked or minted; no secret value was read or printed; no cluster object was mutated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hand-bound OCC companion (union-resolve) for OmniNode-ai/omniweb#364, ticket OMN-18081.
Binds AC1, AC2 and AC3.
Why this is hand-minted
The
occ-companion-effectjob on #364 did not merely fail to bind — it could not publishat all. Run
34355977342ended with:That is the autobind outage OMN-18073 records, and it reproduced on the second push
(run
34357009812). Without a companion, #364 has no receipt to cite. Same union-resolveshape as OCC#8760 (omninode_infra#1266) and OCC#8787 (omninode_infra#1274).
What the product PR fixes, and the finding that matters
The operator reported from the dev dashboard that "users cannot actually add in a label
for the key anymore".
Nothing had been removed. Read-only at
origin/devacec8de— the sha deployed toonex-dev— the label input still rendered,resolveKeyLabelstill returned a typed labelverbatim,
action-logicforwarded it,api-clientPOSTed it as{ name }, and thegateway's
ApiKeyCreateBodyrequires and stores that name. Noomninode_infrachange was needed and none was made.
The operator-visible outcome came from three compounding things, none of them a removal:
panel's own first-visit backfill.
New API keytoggle with nothing hinting it existed.a statement about the whole panel.
#364 opens the create form permanently, scopes the header's claim to the credential while
stating the label is the customer's to give, and captions an auto-named key as auto-named.
The caption is the ticket's own stated alternative to a rename: the gateway exposes no
PATCH /v1/api-keys/{id}(post, get and delete only), so a rename is not buildable.Both protections OMN-18011 bought are preserved and now pinned rather than left to
inspection — the submit control is never gated on an empty label (operator ruling
2026-09-06), and an
onxk_-prefixed label is still refused.Evidence carried here
dod-OmniNode-ai-omniweb-pr-364dod-occ-diff-derived-behavior-proofacec8deocc-self-bind-pr-<n>The behavior-proof receipt records the RED control taken in-lane, not asserted: 10 of 17
fail at
acec8de, 17/17 pass at the pushed head, and the 7 that pass in both states arethe OMN-18011 protection pins — the correct result for a change that must preserve them.
Not bound here, deliberately
AC4 is the staging readback on
dev.appafter delivery. It cannot be proven before #364merges and reaches
onex-dev, so it is not claimed. Rule 24 is stated rather than implied inthe contract summary: the
.201compose dev lane runs no dashboard, so there is no labsurface for this change and no lab pass is claimed.
Rule 22 respected: no credential was rotated, re-issued, revoked or minted; no secret value
was read, printed or decoded; no cluster object was mutated.