Compat: what the recording holds, and what two of the tests now prove

record-compat.py ran against the live server as a server-level
administrator: 8 accounts, which matches the dashboard, so it reached all
of them. One tenant with its quotas and members; no masked addresses, no
archived items.

The empty files are right rather than short. INBUXA has no masked
addresses and retention is off, so masked_email_compat and undelete_compat
iterate an empty list: they pass without comparing anything, which is worth
saying plainly, because a green run from either would otherwise read as
evidence of compatibility. That puts them where scim_compat and
per_domain_directory_compat already sit.

So one recording carries weight, expected.json, and it is made. SPEC §7's
cutover steps 2 and 3 come down to the tenant, the domains and the
accounts until either feature is switched on.

docs/spec/SPEC.md

@@ -534,7 +534,10 @@ before anything that could prompt that notice happens.
 2. INBUXA's data opens in the fork on a copy: tenants, masked addresses,
    archived items, every account.
 3. Masked addresses already handed out still deliver; archived items still
-   restore.
+   restore. Moot as things stand: INBUXA has no masked addresses and
+   retention is off (2026-09-19), so steps 2 and 3 come down to the tenant,
+   the domains and the accounts. It applies again the moment either feature
+   is switched on (`compat-tests.md`).
 4. Cutover on the running host, with the Enterprise build kept for rollback.
 5. Only then: public repository and announcement, with the INBUXA fork of
    ihasmail released alongside. Public ihasmail stays Stalwart-facing (§5).

docs/spec/compat-tests.md

@@ -129,11 +129,37 @@ plumbing before the day the copy exists. What that established:
 What it can't establish is anything about INBUXA's data: every run ended at
 the authentication check, since an empty store holds no such administrator.
 
+## What was recorded, 2026-09-19
+
+`record-compat.py` ran against the live Enterprise server as a server-level
+administrator and saw 8 accounts, which is what the dashboard reports, so it
+reached all of them. It recorded:
+
+| File | Contents |
+|---|---|
+| `expected.json` | 1 tenant, with its quotas and members. `tenantAdmins` empty: no `--tenant-admin` was passed |
+| `masks.json` | nothing |
+| `archived.json` | nothing |
+
+The two empty files are right, not a short recording: INBUXA has no masked
+addresses and deleted-mail retention is off (John, 2026-09-19). So
+`masked_email_compat` and `undelete_compat` iterate over an empty list.
+**They pass without comparing anything, and a green run from either proves
+nothing about compatibility** — the same standing as `scim_compat` and
+`per_domain_directory_compat`, which assert INBUXA uses neither feature.
+
+That leaves one recording that carries weight, `expected.json`, and it is
+made. Should either feature be switched on before the cutover, record again:
+the files are a picture of the day they were taken.
+
 ## What a failure means
 
-- `tenant_compat`, `masked_email_compat`, `undelete_compat`,
+- `tenant_compat`, `branding_compat`, `ai_compat`: the fork reads that data
-  `branding_compat`, `ai_compat`: the fork reads that data differently from
+  differently from the Enterprise server. Treat as a cutover blocker and fix
-  the Enterprise server. Treat as a cutover blocker and fix before moving.
+  before moving.
+- `masked_email_compat` and `undelete_compat` would mean the same, but as of
+  2026-09-19 they have nothing to read: see "What was recorded" above. They
+  can only fail once INBUXA has masked addresses or retention on.
 - `monitoring_compat`: old telemetry that can't be decoded is expected and
   is skipped; a failure here means the settings differ from what was
   observed.