Compat: all eight pass against a copy of INBUXA's data

Run from a copy of the stopped server's RocksDB store. Eight green lines,
which are worth reading carefully: six carry weight, and masked_email and
undelete carry none, because there are no masked addresses and retention is
off, so they iterate an empty list. tenant_compat checked the tenant, its
quotas and its members, but not what a tenant administrator can see, which
needs a --tenant-admin recording.

ai_compat is the one that might have looked vacuous and isn't: the twelve
LLM_ tags are there with the scores that were observed.

Three things had to be fixed first, each failing all eight identically and
none about the data: listener names, privileged ports, pending tasks. The
next import's copy will bring the same three, so they are written down.

SPEC §7: cutover steps 1 to 3 are met. Step 4 remains.

docs/spec/SPEC.md

@@ -539,6 +539,12 @@ before anything that could prompt that notice happens.
    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.
+
+Steps 1 to 3 are met as of 2026-09-19: the fork builds and its suites pass
+(`container-tests.md`), and all eight compat tests pass against a copy of
+INBUXA's store, with the caveat that two of them have nothing to read and
+the tenant administrators' own view is not yet recorded
+(`compat-tests.md`). What remains is step 4.
 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

@@ -1,6 +1,7 @@
 # Running the compat tests against a copy of INBUXA's data
 
-Status: 2026-09-19 (dry run below; still unrun against INBUXA data).
+Status: 2026-09-19. All eight run against a copy of INBUXA's data; see
+"The first run".
 
 Each feature spec has one **(compat)** acceptance test: the check that
 INBUXA's own data opens in inbuxa-server and reads back as it did on the
@@ -200,6 +201,33 @@ 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.
 
+## The first run, 2026-09-19
+
+All eight ran against a copy of INBUXA's RocksDB store, taken from the
+stopped server, with `run-compat.sh` and `john@linuxexperts.net` as the
+administrator. **All eight pass.** SPEC.md §7's cutover steps 2 and 3 are
+met: INBUXA's data opens in the fork and reads back as it did.
+
+What each one actually proved, which is not the same as eight green lines:
+
+| Test | What the pass means |
+|---|---|
+| `tenant_compat` | The tenant, its quotas and its members read back unchanged. `tenantAdmins` was empty, so **what each tenant administrator can see is still unchecked** |
+| `branding_compat` | Every domain's logo answered, and the stored templates read back |
+| `ai_compat` | The twelve `LLM_*` tags are there with the scores observed: real, not vacuous |
+| `monitoring_compat` | Retention and stores read back; old history in the stripped encoding was skipped rather than erroring, and went after one purge |
+| `scim_compat`, `per_domain_directory_compat` | Confirm INBUXA still uses neither feature |
+| `masked_email_compat`, `undelete_compat` | **Nothing.** No masked addresses, retention off: they iterate an empty list |
+
+So six of the eight carry weight today, and one of those six is only
+half-checked until a tenant administrator's view is recorded
+(`--tenant-admin`, "Recording the three files").
+
+Three things had to be fixed before any of this ran, each of which failed
+every test identically and none of which was about the data: the copy's
+listener names, its privileged ports, and its pending tasks. They are
+described below, because the next import's copy will bring the same three.
+
 ## What a failure means
 
 - `tenant_compat`, `branding_compat`, `ai_compat`: the fork reads that data