v0.3.0

Bellbook 0.3.0 implements spec version 0.3, the evolution epoch, layered
over the unchanged v0.2 trust kernel. Published to crates.io as
bellbook 0.3.0.

Added

• Three record kinds for software evolution. Candidate binds a Git
  source state (reported or canonical-manifest binding), Evaluation judges
  one candidate under one criterion (decode-bounded scores), and Selection
  records a set-valued decision over candidates — with a full per-kind rule
  battery and six new reason codes.
• Standing — a replay-derived lineage dimension. When an evaluation is
  retracted and taint reaches the selections that used it, the replay report
  marks every descendant candidate of those selections compromised,
  transitively, at any depth; one reaffirming selection on surviving evidence
  restores the line. Standing is re-derived by every validator like the taint
  set — never embedded in a receipt, never merged into kernel taint or
  evidence.
• Selection approval binding, canonical manifest v1, and a
  recording CLI (candidate / eval / select / lineage).
• Flagship worked example — cargo run --example broken_benchmark runs
  the whole story end to end and prints the standing section changing across
  the retraction and the recovery.
• Independent, from-scratch Python validator reproduces the vectors and
  the entire v0.3 conformance corpus, confirming cross-implementation
  agreement on canonical forms, ids, hashes, decisions, and the standing
  section — byte for decision.

Compatibility

• Spec v0.2 remains a frozen, still-valid epoch: its artifacts are
  byte-frozen, the published 0.2.0 crate stays their validator (a CI epoch
  check confirms the frozen v0.2 receipts validate identically under it), and
  this validator rejects a v0.2 receipt with a clear unsupported-version
  report.

Limitations (what the verifier does not claim)

• Proves consistency of captured activity, not capture completeness.
• Integrity, not confidentiality — records and receipts may hold
  sensitive payloads.
• Lineage, standing, and taint are conditional on producer recording
  discipline: basis, parent, and refs are producer claims a verifier
  cannot check against intent. A receipt carries no source contents — a
  reported binding is a verifiable record of an unverified claim; a manifest
  binding lets a party holding the tree recompute and compare.
• "Clean" is relative to the rules embedded in the receipt.

See CHANGELOG.md
and SPEC.md §13
for full detail.