Repository navigation
fix(OMN-15418): add-only honesty supersession — attestation framing + compose-file fact correction - #5945
Conversation
… compose-file fact correction OCC #5937 merged at 622c78f (2026-08-02T05:43:46Z) with two false statements in landed history, both about the appended dod-deploy-assessment-falsifiable entry: (a) FRAMING — the entry's id and prose claim its pinned-ref content probe escapes the OMN-14443 unfalsifiable class ("falsifiability was demonstrated rather than asserted"). False. A content grep at an immutable 40-hex commit pin exits 0 unconditionally at that pin; it is frozen-true forever. The rc=1-at-the-parent demo proves CONTENT DISCRIMINATION, a strictly weaker property, and the prose conflated the two. (b) FACT — the entry states "#2548 changed 130 files and NOT ONE of them is a compose file". False: #2548 ADDED docker/application-acl-proof/compose.yml and docker/domain-adapter-proof/compose.yml (both status "added"). The true, narrower, load-bearing half — docker/docker-compose.e2e.yml, the one path the dead generated probe greps for, is absent from those 130 paths — stands. Repaired ADD-ONLY, because the defective entry and its receipt are merged and immutable under validator_occ_append_only: a new entry dod-deploy-assessment-merged-tree-attestation carries evidence_artifact: supersedes_dod_evidence:dod-deploy-assessment-falsifiable with the corrected framing and the corrected fact. Its probe body is BYTE-IDENTICAL to the superseded entry's — the defect was the claim about the probe, never the probe. No existing contract entry or receipt line is edited or deleted. Gates: validator_occ_append_only vs origin/dev -> ok:true; all seven pre-existing per-entry hashes unchanged; pre-commit (yamlfmt contamination ratchet, yamlfmt, validate-yaml, lint_contract_check_values, receipt honesty, substance floor, DoD-authoring hygiene, receipt hardening, Evidence-Commit SHA gate) green; all four active (non-superseded) checks execute PASS from the OCC repo root.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 3 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
Comment |
… corrections
Second half of the add-only honesty supersession.
1. occ-self-bind-pr-5945 (contract entry + receipt) — binds OMN-15418 to
THIS PR so occ-preflight eligibility resolves a PASS receipt from the
PR's own checkout (OCC in-repo invariant I3). Mirrors the
occ-self-bind-pr-5937 precedent one PR upstream. Binding stamp only;
adjudicates nothing, flips no Linear status.
2. Two net-new command.supersede.5945.yaml records — the only sanctioned
add-only correction primitive for a merged receipt
(validator_occ_append_only rejects M/D/R on any receipt file):
- dod-deploy-assessment-falsifiable/command.supersede.5945.yaml
withdraws that receipt's two false claims: "#2548 changed 130 files
and none is a compose file" (#2548 ADDED two compose files), and
"RED-proven ... the check therefore discriminates" read as
falsifiability (an immutable-ref content grep exits 0 unconditionally
at its pin; rc=1-at-parent proves discrimination, not falsifiability).
- occ-self-bind-pr-5937/command.supersede.5945.yaml corrects the same
compose-file framing and re-points "substantive evidence" at
dod-deploy-assessment-merged-tree-attestation. Its probe was re-run
live and now reads state MERGED where the base receipt recorded OPEN.
Both replacements keep the superseded item's check_value UNCHANGED —
the bar is not weakened, only the prose about it is made true. Both
merged base receipts stay byte-for-byte intact.
Gates: validator_occ_append_only vs origin/dev -> ok:true (all four receipt
diffs are 'A'); OMN-15459 supersession corpus 2344 violations vs baseline
2344, exact match (no new S1/S2 violations); resolve_supersession returns
both records cleanly with no error and no tombstone; pre-commit green;
all five active checks execute PASS; uv run pytest tests/ -> 4345 passed,
47 skipped.
1 participant
OMN-15418 — add-only honesty supersession of landed OCC evidence
OCC #5937 merged at
622c78f631bdc4110064dd41c10158430eb4ea04(2026-08-02T05:43:46Z). Two statements it landed are false. Both are about the entry it appended,dod-deploy-assessment-falsifiable. This PR corrects both add-only; it edits and deletes nothing.What was false
(a) Framing — the entry claims a falsifiability it does not have.
The entry is named
-falsifiableand its description says "falsifiability was demonstrated rather than asserted", presenting it as escaping the OMN-14443 unfalsifiable class. It does not. Its probe greps file content at an immutable 40-hex commit pin (3863623e…). At that pin it exits 0 unconditionally — frozen-true forever; no change to product source, deploy surface, or runtime can move it. Therc=1-at-the-first-parent demonstration proves content discrimination (the probe reads real bytes rather than passing vacuously), which is strictly weaker than falsifiability at its own pin. The merged prose conflated the two.(b) Fact — the compose-file claim is wrong.
The entry and its receipt state: "#2548 changed 130 files and NOT ONE of them is a compose file." False. PR
OmniNode-ai/omnibase_infra#2548ADDED two compose files:(re-verified 2026-08-02 against the live 130-path list from
repos/OmniNode-ai/omnibase_infra/pulls/2548/files).The load-bearing half is true and survives: the one path the dead generated
dod-deploy-assessmentprobe greps for —docker/docker-compose.e2e.yml— is absent from those 130 paths (grep -Fxover the live list returns rc=1). That absence, not a blanket "no compose files", is why the generated probe is permanently RED.What is now stated
New contract entry
dod-deploy-assessment-merged-tree-attestation, carryingevidence_artifact: supersedes_dod_evidence:dod-deploy-assessment-falsifiable:3863623e4844dc9b0db69ceb4e77942737fbca32carries the OMN-15418 deliverable — the application-relation ownership validator definition and the exactly-one-owner enforcement call site — both insrc/omnibase_infra/validation/application_relation_ownership.py.rc=1-at-parent demo shows discrimination, not falsifiability at the pin.The probe body is byte-identical to the superseded entry's. The defect was the claim about the probe, never the probe.
Why append-only
#5937merged mid-remediation. A mergeddod_evidenceentry is immutable:validator_occ_append_onlycompares every base-side entry'scompute_contract_entry_sha256against head and rejects any edit or removal, and the merged receipt pins that hash. An in-place rewrite of the honest prose would have been rejected by the gate and would have invalidated the receipt binding. So the correction is a net-new appended entry plus a net-new receipt directory — zero edits, zero deletions to any existing line.Seam
dod-deploy-assessment(generated, permanently RED)dod-deploy-assessment-falsifiabledod-deploy-assessment-falsifiable(honest probe, dishonest framing)dod-deploy-assessment-merged-tree-attestationChain:
dod-deploy-assessment→dod-deploy-assessment-falsifiable→dod-deploy-assessment-merged-tree-attestation.node_dod_verify's_terminal_supersederwalks it and resolves the attestation as the terminal carrier; both upstream entries resolve tosupersededand their checks are not executed._supersession_is_in_effectrequires the terminal carrier to be VERIFIED in its own right — it is (see gates below), so the supersession removes a false red rather than manufacturing a green.Gates run before push
validator_occ_append_only --base-ref origin/dev→{"ok": true, "detail": "No append-only violations: existing entries and receipts unchanged."}contract_entry_sha256values recomputed and unchanged (HEADER_FIELDS = ('ticket_id','schema_version'); appending does not disturb prior entries). New entry hashsha256:18c56f32b23e55675a6dd55ae63b1594d5e6c293e44d613a0fe60309d64bed76is bound by the new receipt.pre-commit run --files: yamlfmt contamination ratchet, yamlfmt, validate-yaml (ModelTicketContract),lint_contract_check_values,dod-evidence-required, Receipt Honesty Gate, Contract Substance Floor, DoD-authoring hygiene, Receipt Hardening Gate (incl. OMN-15459 S1/S2), Evidence-Commit SHA gate, normalization-symmetry — all Passed.dod-occ-evidence-admissibility-validator,occ-self-bind-pr-5635-merged,occ-self-bind-pr-5937,dod-deploy-assessment-merged-tree-attestation.Receipt-prose corrections (commit 2), also add-only
validator_occ_append_onlyrejectsM/D/Ron any file underdrift/dod_receipts/<TICKET>/— a merged receipt is immutable. The sanctioned correction primitive is a net-new higher-token<check_type>.supersede.<NNNN>.yaml, so two were added at token5945:dod-deploy-assessment-falsifiable/command.supersede.5945.yamlocc-self-bind-pr-5937/command.supersede.5945.yamlstate: MERGEDwhere the base receipt recordedOPENBoth replacements keep the superseded item's
check_valueunchanged — the bar is not weakened, only the prose about it is made true. Both merged base receipts stay byte-for-byte intact.resolve_supersessionreturns each record cleanly (no error, no tombstone).occ-self-bind-pr-5945(contract entry + receipt) binds OMN-15418 to this PR per the OCC in-repo invariant I3, mirroringocc-self-bind-pr-5937.Gates run before push (commit 2)
validator_occ_append_only --base-ref origin/dev→ok:true; all four receipt diffs areA(add), noneM/D/R.resolve_supersessionon both keys → record parsed, no error, not tombstoned.uv run pytest tests/→ 4345 passed, 47 skipped.Scope notes
no_source_change: trueon the receipt.