From f338ddf57d9edf5508f15f1c4dbf368347b6d4cb Mon Sep 17 00:00:00 2001 From: John Coffey Date: Sat, 19 Sep 2026 21:36:10 -0700 Subject: [PATCH] Specs: point a stock ihasmail at the migrated server afterwards Asked for by John, 2026-09-19. Public ihasmail is Stalwart-facing and knows nothing about INBUXA, so running an unmodified one against the migrated server checks something the fork's own suites cannot: that a client written for upstream still works. Each difference it finds is one of two things, and the point is to say which: a regression against upstream's contract, which the fork's tests would not catch because they test the fork; or a feature that now expects INBUXA's own front ends, which belongs in the contract and the release notes rather than in a user's surprise. After mail is flowing, not as a gate. It informs the contract; it doesn't block a cutover. --- docs/spec/cutover.md | 27 ++++++++++++++++++++++++++- docs/spec/migration.md | 13 +++++++++++++ 2 files changed, 39 insertions(+), 1 deletion(-) diff --git a/docs/spec/cutover.md b/docs/spec/cutover.md index 543828b..a93c099 100644 --- a/docs/spec/cutover.md +++ b/docs/spec/cutover.md @@ -4,7 +4,9 @@ Status: draft, 2026-09-19. Nothing here has been rehearsed yet. SPEC.md §7 step 4. This run is also the first run of the migration tool INBUXA will ship (`migration.md`): what is done by hand here is what that -tool automates, including its rollback. Steps 1 to 3 are met: the fork builds and its suites pass +tool automates, including its rollback. + +Steps 1 to 3 are met: the fork builds and its suites pass (`container-tests.md`), and all eight compat tests pass against a copy of INBUXA's store (`compat-tests.md`). What is left is running it as the mail server. @@ -143,6 +145,29 @@ never been checked, and checking it is worth an hour beforehand rather than an argument at 2am. Until it is checked, treat the fork's store as forward-only. +## After: stock ihasmail against the fork + +Once the migration is done, point an **unmodified public ihasmail** +container at the new server — it can run on a laptop, since it talks JMAP +and OAuth over the network (SPEC.md §5.3) — and work through what it can +do. It needs an OAuth client it is allowed to use and a reachable URL for +the server, nothing else. + +This is the one check that comes from outside the fork's own world. Public +ihasmail is Stalwart-facing by design (SPEC.md §5) and knows nothing about +INBUXA, so whatever it can no longer do is one of two things, and both are +worth knowing: + +- a **regression**: the fork broke something upstream's clients rely on, + which the fork's own suites wouldn't catch because they test the fork; +- a **gap by design**: a feature that now needs INBUXA's own front ends, + which belongs in the contract (SPEC.md §5.2) and in the release notes + rather than being discovered by a user. + +Write down which of the two each difference is. Do it after mail is +flowing, not as a gate: it informs the contract, it doesn't block the +cutover. + ## The first week - **Certificate renewal.** The one thing that fails quietly and late. Watch diff --git a/docs/spec/migration.md b/docs/spec/migration.md index 0a08bf7..27107c4 100644 --- a/docs/spec/migration.md +++ b/docs/spec/migration.md @@ -83,6 +83,19 @@ The same checks as `cutover.md`, run by the tool rather than by hand: A failed check is a failed migration, and the tool rolls back rather than leaving a half-migrated server for the operator to reason about at 2am. +## After a migration: the stock client + +A migration that passes its own verification has proved the fork works for +the fork. Pointing an **unmodified public ihasmail** at the migrated server +proves something else: that a client which knows nothing about INBUXA still +works against it. It runs anywhere — JMAP and OAuth over the network — and +needs only an OAuth client it may use. + +Each difference it turns up is either a regression against upstream's +contract or a feature that now expects INBUXA's own front ends. The tool +doesn't run this; it belongs in the release notes and the contract +(SPEC.md §5.2). It is named here so the first migration doesn't skip it. + ## Rollback A first-class path, not an appendix.