v1.0.3 — a straight answer on trust

Documentation and presentation only. app.js, styles.css and the application markup are
byte-for-byte identical to v1.0.2 — the only code change is the version string in the footer.
Nothing about the crypto, the share format or the stored record moved, so there is no reason to
re-do a backup: shares written by any earlier version restore here unchanged, and shares written
here read back in the older ones.

A straight answer to "should I trust this with a seed phrase?"

The README now opens with it, because typing a recovery phrase into a web page is normally
terrible advice and the question deserves evidence rather than reassurance: that app.js contains
no fetch, no XMLHttpRequest, no WebSocket and no dynamic import, so after the page loads it
cannot make a network request at all; that nothing is written to localStorage, sessionStorage,
IndexedDB or a cookie; that there is no analytics and no third-party script; and that all of this
takes a minute to confirm with grep or the Network tab. It also states plainly what the tool
does not protect you from.

Why it is built the way it is

A new "Design philosophy" section explains the constraints — no dependencies, no package manager,
no build step, every line of JavaScript in one file — and the reasoning behind each. A dependency
you have not read is trust you have delegated, and a build step hides the artifact you actually
run. The cost is hand-written code proved against the official vectors; the benefit is that the
whole thing can be reviewed in an afternoon.

A demo, and clearer hardware guidance

The README now leads with a recording of a complete 2-of-3 backup, from entering a phrase through
writing three keys to the verified "Your backup is ready" screen. The firmware table has been
simplified to three rows with support marked directly, and the record-size figures were re-measured
and corrected against the real 900-byte cap.