Repository navigation
Record protected publication authority evidence - #37
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 27 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 (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Canonical-main follow-up after the evidence ledger mergePR #37 merged as
The evidence ledger is therefore healthy on current canonical |
Summary
evidence/2semantic.Change class
Select one:
Affected trust boundary: no runtime boundary changes. This PR records the exact evidence produced by the already-merged receipt-bound publication-authority gate.
TDD evidence
Red evidence: documentation-only evidence capture after the protected run. No production implementation changed.
Green evidence: the exact merged main CI and protected publication runs passed; the downloaded artifact and a separately downloaded ZIP passed independent hash and semantic audits.
Commands and results:
cargo fmt --all -- --checkgit diff --check.work/audit-authority-run.pyagainst run29726693055— 72 files, 25 roles, 24 unique final hashes, 8 empty stderr files, and exact canonicalevidence/2passedgh apiartifact ZIP download — SHA-256 exactly matched GitHub's archive digestMathematical verification
Verifier and result: one exact protected
lean_kernel_proofis accepted and authoritative for the named formalization version. No source-claim truth is asserted, and no protected refutation example is claimed.Provenance and licensing
Provenance references: PR #36, issue #21, main CI run
29726693096, protected publication run29726693055, and artifact8454565233.Risk and recovery
Known limitations: receipt-bound semantic/CAS revalidation is not the typed-action plus event-chain replay required by SPEC section 16.6. The broader replay box remains open. The proof/refutation box also remains open until a protected refutation artifact exists.
Rollback or recovery plan: revert this documentation-only commit if an identity is disproved. The retained GitHub artifact and issue/PR evidence comments remain independently inspectable.
Follow-up work: implement the separate derived-status gate from exact current authority plus exact current verified fidelity, then complete Pilot A through the real CLI/MCP paths.
Review readiness
Records the final durable evidence for #21. MathOS 1.0 is not complete.