diff --git a/cc-ci-plan/upstream/mattermost-lts.md b/cc-ci-plan/upstream/mattermost-lts.md
index 6e7eada..19a2a6f 100644
--- a/cc-ci-plan/upstream/mattermost-lts.md
+++ b/cc-ci-plan/upstream/mattermost-lts.md
@@ -6,9 +6,12 @@
 | postgres | postgres                                  | https://github.com/postgres/postgres              | https://www.postgresql.org/docs/release/                          |
 
 ## Standing notes
-- mattermost-lts tracks the **10.x LTS series** — do NOT bump to 11.x (major version, breaking changes).
-  The latest 10.x tag is on `mattermost/mattermost-team-edition` e.g. `10.11.x`; check release notes
-  at https://docs.mattermost.com/about/mattermost-changelog.html.
+- mattermost-lts tracks the **10.11 ESR (Extended Support Release)**. Release calendar:
+  - **10.11** = current ESR, supported through **2026-08-15**; latest patch: **10.11.19** (2026-05-27)
+  - **10.12** = innovation release, support **EXPIRED December 2025** — do NOT target
+  - **11.7** = next ESR (supported through 2027-05-15) — future major upgrade, separate planning needed
+  - Check the release lifecycle at https://endoflife.date/mattermost before each upgrade run.
+  The `release-10.11` Docker Hub floating tag always points to the latest 10.11.x patch.
 - postgres: stay on **15-alpine** for now. The upgrade to 16-alpine requires a major-version migration
   (pg_upgrade or dump/restore with operator involvement) because the stack runs with a persistent
   postgres_data volume. A 16 container against pg15 PGDATA crashes on startup. Major pg bump is a
@@ -18,3 +21,6 @@
   could exec into the OLD postgres container (pre-config-update) during the upgrade lifecycle. Inline
   commands eliminate this dependency — the backupbot reads labels from the Docker service API
   (always current), and pg_dump/psql/createdb are present in any postgres:alpine container.
+- Backup format (as of 2.1.12+10.11.19): gzip-compressed `backup.sql` in the postgres_data volume.
+  The restore hook properly terminates connections, drops + recreates the DB, then gunzips + restores.
+  `DROP DATABASE WITH (FORCE)` requires PostgreSQL 13+ — safe on postgres:15-alpine.