release: 1.0.0: Public 1.0 image; delivery log; docs and SECURITY.md (incl. 1.0.1)

[1.0.0]
Added:
  - A **Delivery log** on each delivery's page (`/deliveries/{id}`): the
  - A **History** block on the same page: the journal's two timestamps stated as
Fixed:
  - Postfix config: copy TLS cert/key from the (often `:ro`, host-owned) mount
  - Postfix config: allow `maillog_file` under `/data` via
  - E2e: read `/data/setup-token` via `docker compose exec` (file is `0600`
  - Entrypoint: check `SELFPOST_HOSTNAME` before `/data` setup (so a bad identity
  - E2e gate: wait for host-published `/healthz` before panel setup, and stop
  … (3 more in CHANGELOG)
Changed:
  - Document what `.spbk` and `.spde` stand for (SelfPost backup / SelfPost domain
  - Docs aligned with the code: setup URL is `/setup/<token>` (README and
  - Full backups no longer carry `/data/log`. It is Postfix's raw log plus its
  - Monitoring screens (status, mail queue, system log, deliveries) use adaptive
  - Documentation package consolidated into `docs/development.md`: Documentation
  … (4 more in CHANGELOG)
[1.0.1]
A documentation and packaging release: no change to the mail path, the database, or the on-disk layout. Upgrading is a tag bump.
Added:
  - `SECURITY.md` — how to report a vulnerability privately (GitHub private
  - [docs/plans/](docs/plans/) — one document per agreed extension: the optional
Changed:
  - The panel's **Account** entry is now called **Settings** — nav link, page
  - The signed-in name in the panel's nav is now labelled `User:`, so it reads as
  - [docs/product.md](docs/product.md) reframes the future line: the inbound
  - [docs/security.md](docs/security.md) is now in English, matching the rest of
  - The README documentation table now points at `SECURITY.md` for reporting a
  … (2 more in CHANGELOG)
Fixed:
  - The panel's static assets are served with a content ETag and

Squashed CHANGELOG sections: [1.0.0], [1.0.1].

Full detail: CHANGELOG.md (1.0.0, 1.0.1).

docs/plans/web-split.md

@@ -0,0 +1,56 @@
+# Plan: web-split (splitting `internal/web`)
+
+**Status:** agreed  
+**Version:** `1.x`; an internal refactor, it does not force a break on its own.
+
+---
+
+## What this is
+
+`internal/web` is the project's largest package: ~50 files (templates and
+static assets included), ~25 `.go` files and ~4000 lines of Go, with the
+handlers for every panel section, sessions, security headers, origin checking,
+form validation and template rendering all sitting in one flat namespace.
+
+The candidates to split out are `web/handlers` and `web/auth`, or a cut along
+the panel's own domains.
+
+## Why now
+
+At its current size the flat package reads fine: the file names
+(`handlers_domains.go`, `handlers_apps.go`, `handlers_monitor.go`) do the work
+directories would, and splitting would force exporting what is package-private
+today — widening the internal API for cosmetics.
+
+It starts to pay off once the package grows: **domain-admin** and
+**inbound-relay** both add code to it — the role brings authorisation into
+every handler, the inbound relay brings its own pages and handlers for inbound
+domains. The refactor is cheaper before that growth than after it.
+
+## Recommended order
+
+**web-split → domain-admin → inbound-relay** (see the
+[roadmap](../roadmap.md)).
+
+1. **web-split** — lay down the package structure (including a place for
+   `web/auth`) while there are no cross-cutting edits from the role and no new
+   inbound handlers.
+2. **domain-admin** — authorisation in every handler builds on a package layout
+   already chosen.
+3. **inbound-relay** — a new vertical slice; easier to add to an already split
+   package than to refactor alongside the two features before it.
+
+The order is a recommendation, not a blocker.
+
+## Done when
+
+The decision is made deliberately when the work starts — either the package is
+split along the chosen scheme, or it is settled that it stays flat. After a
+split: `build`/`vet`/`test` green, the panel's behaviour unchanged.
+
+## Risks
+
+- Splitting too early — a superfluous internal API and churn with nothing to
+  show for it;
+- leaving it until after the growth — a harder refactor, tangled up with the
+  features.