v1.0.1

Patch release. One damaged file no longer takes the app down with it.

Fixed

A corrupt wiki file could stop Waikiki from starting entirely (#71). If the
default wiki's database was damaged, startup failed and every other wiki —
however healthy — became unreachable. Wikis are supposed to be isolated, and now
they behave that way:

• The app starts. The damaged wiki explains itself on a page that names the file,
  says what is wrong with it, and links the others.
• Manage wikis stays usable and is where you recover from: it lists the
  healthy wikis normally, badges the damaged one with the reason and its size on
  disk, and shows where your backups are and the three steps to restore one.
• Nothing touches the file. A corrupt database is your data in a damaged
  state and may still be recoverable, so Waikiki never deletes, truncates or
  "repairs" it — it is left byte-for-byte as it was.
• The MCP switch_wiki tool refuses an unreadable wiki with the same reason, so
  an agent gets the same answer you do.

The distinction that makes this safe: SQLite refusing a file is treated as
damage, while a fault in Waikiki's own code still raises loudly. A missing table
or a bug in our code is not corruption and is not silently swallowed.

Two more found on the way:

• A single unreadable wiki aborted the whole scheduled backup run and deleted
  the half-written snapshot — so one bad file meant no backup for any wiki. It
  now skips that wiki and reports it.
• Lock contention on open could surface as a database error rather than a wait,
  because the busy timeout was set too late. Contention is not damage.

Install

brew tap VerinFast/waikiki && brew install --cask waikiki

or pipx install waikiki for the server and MCP endpoint on any platform.
Installed copies update themselves.