v1.0.0 release evidence

Prepared on 2026-08-24. This receipt belongs to the source commit tagged v1.0.0. The publication gate completed successfully on 2026-08-24.

Contract identity

The generated schema, every example, stable-contract checker, migration path, CLI JSON, and protocol fixtures agree with those values. cargo-semver-checks runs against the latest published crate in the tag workflow; 1.0.0 is the documented major-version boundary for the frozen public contract.

Local release-candidate evidence

• 237 Rust tests passed: 160 library, 10 binary, 36 CLI, 25 integration, and 6 rustdoc tests.
• cargo fmt --check, strict all-target/all-feature Clippy, missing-doc and broken-link rustdoc lints, and the Rust 1.88.0 all-feature check passed.
• cargo package and cargo publish --dry-run packaged and verified 120 files at 1.7 MiB without uploading.
• All 17 document examples passed 21 parity checks with zero failures. Ubuntu CI owns the exact 26-page Linux baseline comparison.
• Compatibility covers 31 capabilities and every one of the 23 public block variants. Stable, accessibility, security, benchmark, integration, Action, playground, contributor, and site contracts passed.
• RustSec found no vulnerability or unsoundness rejection. The two allowed unmaintained warnings for rustybuzz and ttf-parser remain documented in the dated security review.
• Two isolated aarch64-apple-darwin release builds were byte-identical at SHA-256 14a9a31c37ff7772d7eafa54ffeaf90b5279bb3d985799cdc013d139a13f58e8. The tag workflow repeats this on Linux x64, macOS Intel, macOS Apple Silicon, and Windows x64.
• The checksum-verifying Unix installer fixture installed and executed rusdox 1.0.0 from a release-shaped archive.
• Mobile browser QA at the controlled 390 CSS-pixel viewport found zero horizontal overflow and zero console errors on the homepage and signed v1 registry. All three registry previews loaded with meaningful alt text and linked to their versioned parity evidence.

Registry continuity

The byte-identical legacy registry and its discarded signing key remain at registry/index.json for 0.1.1 clients. RusDox 1.x pins registry/v1/index.json and a distinct Ed25519 public key. Its three templates declare >=1.0.0,<2.0.0, every asset hash verifies, and each report contains 21 passing checks generated by RusDox 1.0.0. The v1 private key was generated only in memory and discarded after signing.

Published receipts

• Tag v1.0.0 resolves to source commit c74a0f44bf03065fe5ca4d4d215bd78cac59f8b5.
• The final branch CI and CodeQL run passed before the tag moved to the release commit. The dependency-backed security audit also passed on the release candidate.
• The final release workflow passed its SemVer scan, all four clean reproducibility jobs, signed release, crates.io OIDC publication, and installer smoke tests on Linux, macOS, and Windows.
• The public GitHub Release contains four archives, four reproducibility receipts, SHA256SUMS, and an SPDX JSON SBOM. It is neither a draft nor a prerelease.
• rusdox 1.0.0 on crates.io installed from the public registry with --locked, executed as rusdox 1.0.0, and verified the default signed HTTPS registry containing invoice, proposal, and board-report.
• rusdox 1.0.0 on docs.rs serves the public library documentation.
• The Pages site and immutable v1 registry are published from Pages commit a8b847fc9f60580f97087ac93b5f4401336d46f3.

Reproducible binary receipts

Every receipt records two builds, locked dependencies, disabled incremental compilation, SOURCE_DATE_EPOCH, a cleaned stable target path, and identical bytes. Independent post-release verification downloaded every asset, passed all eight entries in SHA256SUMS, and verified GitHub provenance attestations for all four archives.

The first tag candidate failed closed on Windows before a release or crate existed. That evidence led to a permanent branch gate and explicit MSVC reproducible linking; the tag was moved only after the repaired commit passed the three-OS branch proof.

The Windows target explicitly enables the MSVC linker's reproducible mode. A byte mismatch fails the job and retains both executables for seven days as a diagnostic artifact; the workflow never converts a mismatch into a warning.