mrwulf
f8de7d9e6f
Round-15 reconciliation: both reviewers ran the mandated rendered-PDF
gate (all 22 pages each, acts stated). They CONFLICTED on one checkable
fact: GPT found the transport figure's s label on the wrong node (the
computed [4,8) parent instead of the consumed [6,8) proof value); the
Fable reviewer certified 'dashed consumed s over [6,8)'. Adjudicated
against the tikz source: GPT RIGHT — my drawing contradicted its own
caption; Fable's script verified the instance's mathematics but misread
the label placement. Fixed (s -> p67 dashed; q47 -> plain computed
node) and CONFIRMED BY RE-RENDER.
GPT's second blocker also real and fixed: Definition 2(i) claimed
'unique accepted opening' (witness uniqueness) where Game PB proves
leaf-value binding — clause (i) now 'an authentic signed view and a
uniquely determined leaf value at its claimed position'; Appendix A row
aligned ('authentic opening with a position-bound leaf value').
Layout (all confirmed by rendered inspection): figure relocated after
the transport introduction (no longer floats between Theorem 4's
statement and proof); Lemma 4's full statement held together
(samepage); Appendix C given its own page — heading + scope warning +
complete code + Appendix D on p23 (clearpage; 22 -> 23 pages).
GPT optionals adopted: abstract 'one project-specific uninterpreted
SHA-256 boundary axiom'; adaptive-oracle sentence defining Q; corollary
overhead phrasing; PB-vs-mirror bridge sentence in the mapping
paragraph; 'bespoke bar' lead-in dropped; Table 1 ragged-right columns.
Declined with reasons recorded: Lemma-4 sub-case itemization and
renaming the composition theorem (both reviewers' optional-only notes;
churn risk at the frozen gate outweighs gain).
Gate status by the reviewers' own words: Fable round 15 'nothing
blocks' x3 with full evidence discipline; GPT 'after the two
correctness fixes and the three layout fixes ... nothing blocks
submission on correctness or readability grounds' — all five applied
and render-verified. 0 overfull, suite 115 green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| src/pacta_provider | ||
| pyproject.toml | ||
| README.md | ||
PACTA Proof Check Provider
This nested project is a prototype third-party proof-checking service. It reuses host Lean/Aeneas infrastructure, runs portable PACTA replay/audit checks, and emits signed attestation certificates.
It does not modify anything outside this repository. It may read configured toolchains such as /Users/oho/GitClone/ClaudeCodeProjects/your-lean-project/aeneas-toolchain/env.sh.
It can also maintain a local transparency log. The log is an RFC 9162-style Merkle accumulator over signed attestations. It emits Signed Tree Heads with Ed25519 today and records an ML-DSA/FIPS 204 signature slot as unavailable unless a real backend is present. Agents that require both signatures must reject such receipts.
Commands
PYTHONPATH=src:provider/src python -m pacta_provider discover
PYTHONPATH=src:provider/src python -m pacta_provider init-key --key-dir provider/state/demo-provider
PYTHONPATH=src:provider/src python -m pacta_provider check \
--config examples/repos.yaml \
--repo-name dalek-ed25519-verified \
--repo repos/dalek-ed25519-verified \
--provider local-pacta-provider \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub \
--out provider/out/dalek.attestation.yaml
Transparency log:
PYTHONPATH=src:provider/src python -m pacta_provider log-init \
--log-dir provider/state/transparency-log \
--provider local-pacta-provider \
--public-key provider/state/demo-provider/provider.ed25519.pub
PYTHONPATH=src:provider/src python -m pacta_provider log-append \
--log-dir provider/state/transparency-log \
--attestation provider/out/dalek.attestation.yaml \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub \
--out provider/out/dalek.receipt.yaml
PYTHONPATH=src:provider/src python -m pacta_provider log-sth \
--log-dir provider/state/transparency-log \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub
The resulting certificate can be consumed by pacta with --attestation, --trust-attestation-provider, and --attestation-public-key.
The receipt can be consumed with --transparency-receipt, --transparency-log-public-key, and --require-transparency-receipt.
The private key must remain provider-side. Downstream agents only need the public key, the inclusion receipt, and a policy decision that the provider name/log key is trusted.