Rebuild, don't operate in place
Every tool that edits precious files chooses between two approaches, and the choice matters more than any feature. In-place editing opens the file and modifies its bytes directly — efficient, immediate, and carrying a catastrophic failure mode: interrupt it mid-write, or get one offset wrong, and the file dies in a way no undo can reach. Rebuilding reads once, edits a working copy, and writes an entirely new file. Slower in theory. Boring in practice. Boring is the feature.
Why databases punish in-place edits hardest
A database file is a web of self-references — pages pointing at pages, offsets promising "the row lives 3,847 bytes in." In-place edits have to update every promise consistently, mid-flight, often while keeping a b-tree balanced. Real engines manage it with journals, write-ahead logs and decades of hardening; that machinery is most of what a database engine is. A lightweight editor attempting the same surgery without the machinery is a corruption generator with a nice UI — and the wreckage shows up silently, weeks later, when some untouched-looking table turns out to share a page with the edit. That's why our reader refuses to write anything at all, and why the editor rebuilds rather than reaches in.
The rebuild contract
The contract has three clauses. The original is read-only — not by policy but by code path; no write ever targets it, so the worst possible outcome of any bug here is a bad export, never a damaged source. The copy is the workspace — grid edits, SQL mutations, undo and redo all run on memory, checkpointed and reversible. Every save is a full rebuild — the writer lays out every page fresh, which incidentally explains why exports often shrink (no dead pages, no fragmentation) and why each one can face the official engine's integrity check anew. In-place editing asks you to trust the surgeon's hands; rebuilding only asks you to inspect the new file before you rely on it — and it hands you the inspection report, stamped, with every export.