v0.6.0

The release in which you can prove it comes back. After restoring from a backup, the
ledger can be checked by its contents, not its row count — the counts can agree while
every target has moved, and then every identifier is broken.

The check used to be SQL pasted into a runbook. A mis-paste still reads as "they
match", so it is a command now.

Alongside it, a restore and a point-in-time recovery were actually carried out, and the
procedure, the daily and monthly backups, and how to notice that backups have stopped are
written down in Deployment. The
recommended architecture and the redundancy decisions are there too — each one exercised
before it was written.

Added

• arkhe fingerprint — prove a restore by its contents, not its row count. Run it on
  the restored ledger and compare against the value from before: the counts can agree
  while every target has moved, and then every identifier is broken.

  arks       c5e54e5af778420832800a7dc9104eee  53 rows
  withdrawn  e3b0c44298fc1c149afbf4c8996fb924  0 rows
  

  Two lines, because blending them hides where the difference is. Losing withdrawn
  (the names never to be assigned again) does not stop minting: with a single number
  you would never see it, and half of what makes NR hold would be gone while everything
  appeared to work.

  Holds are excluded on purpose. They change on their own as deadlines pass, so a
  difference would not mean "broken" — an alarm that is always ringing stops being
  read. Titles and descriptions are excluded too: losing them hurts, but not in the
  way an identifier pointing elsewhere hurts, and mixing them flattens a grave
  difference and a mild one into the same value.

  Deployment used to carry the
  md5(string_agg(...)) SQL inline. A mis-pasted check still reads as "they match",
  so it is a command now — and one that does not depend on the database's dialect.

---

日本語の変更履歴
· Full Changelog: v0.5.1...v0.6.0