Safety model

The write APIs touch your git — so they’re fenced in, by construction. Two of them exist: the comments API, which writes the store, and the in-page editor, which writes your Markdown source. The rules below cover both; the editor adds one of its own.

• Dev-only. The write path only exists under notabene dev. In build/preview mutations return 403, and a public build doesn’t contain the routes at all.
• Loopback by default. The server binds 127.0.0.1; the write API is not reachable from your network unless you opt in with --host / NOTABENE_HOST=1 — trusted networks only.
• Every write is gated beyond the bind: cross-origin requests are refused (anti-CSRF), a non-loopback Host header is refused in loopback mode (anti-DNS-rebinding), and — when you set NOTABENE_TOKEN — each write must carry a matching x-notabene-token. Setting a token is recommended with --host.
• The editor refuses to write untracked files. It edits your content, not just the store, so git is the only undo it can offer — and notabene dev does not require a repository. A file git isn’t tracking is refused, loudly, with the remedy. Opt out with edit: { requireGit: false }, or turn the editor off entirely with edit: { enabled: false }.
• Identity per person. On a non-loopback host, each visitor is asked to set their name (+ optional email) before browsing, so comments attribute to real people rather than the repo owner’s git default.
• The agent never commits without asking and never bulk-deletes the store — that’s part of the protocol.
• The CLI is a separate surface. The rules above fence the HTTP write API. The store-writing commands (comments done / reopen, journal add) are local commands you — or an agent in your terminal — run deliberately: no server, no port, no network. They write atomically, touch one comment at a time, and comments verify audits the result.

The public artifact is the mirror image: no write API, no store data, no identity — nothing to gate, because nothing is built.