v0.2.0

Bellbook 0.2.0 is the first public release. It implements Bellbook spec
version 0.2, the first published compatibility epoch.

A tamper-evident, replay-verifiable record of captured agent activity:
typed records in an append-only, hash-chained log, each judged by a
deterministic verifier and replayable from genesis or a checkpoint.

Added

• Twelve typed record kinds (requests, actions, responses, results,
  authority, approvals, refusals, plans, usage, summaries, retractions,
  deterministic verdicts).
• RFC 8785 JSON canonicalization and SHA-256 content-addressed record ids.
• Typed Cause, Use, Require, Replace references between records.
• Deterministic record and full-log verification: gap-free logical time,
  subject/verdict pairing, verdict re-derivation, author-role enforcement,
  request lifecycle checks, and authority resolution.
• Five evidence classes with weakest-link derivation and configurable
  per-kind thresholds.
• Strict Ed25519 signatures with actor key pinning and a version-specific
  signing domain.
• Append-only retractions with transitive taint through epistemic
  dependencies.
• A crash-safe, exclusively locked file writer with verified open,
  bounded loading, pair-atomic commits, recovery, deterministic batches,
  and idempotent compare-and-append.
• Portable receipts and the bellbook validate CLI for bounded offline
  validation from genesis.
• Trusted checkpoints and canonical head attestations for external
  anchoring.
• Deterministic context selection and verified state construction.
• Versioned canonical test vectors, including signed-record vectors.
• CI across Linux, macOS, and Windows, Rust 1.75 checks, documentation
  checks, scheduled RustSec scanning, and Dependabot updates.

Security

• Record ids bind completed signatures; removing or substituting a
  signature changes the id and every dependent reference or anchored head.
• Signature input is domain-separated (bellbook.record-signature.v0.2),
  preventing cross-protocol and cross-version replay.
• Strict decoding: unknown fields, duplicate logical keys, and
  non-canonical payloads reject.
• Receipt and persistent-log input is resource-bounded before verification.
• Replay recomputes record ids and stored verdicts, including full verdict
  envelope validation.
• Checkpoints cannot arrive through receipts; only the explicit
  trusted-checkpoint API accepts them.
• Persistent commits reserve and recover the complete subject/verdict pair.
• Key-pinned actors must sign every record; actor identities are bound to
  configured roles.
• Actions name the exact capability and approval that authorized them;
  retracted authority no longer authorizes later actions.

Known limitations

• Proves consistency of captured activity, not capture completeness.
• Integrity, not confidentiality: records and receipts may contain
  sensitive payloads.
• A storage owner can replace an unanchored log from genesis; key-pinned
  signatures and externally stored head attestations limit that threat.
• Receipt status is evaluated under the embedded verifier rules; consumers
  compare rules_hash against rules they trust.

See SPEC.md for normative behavior and SECURITY.md
for the threat model.

Full details: CHANGELOG.md