docs(adr): ADR-011 records the Express migration, and corrects its own Standard claim (E7)

[mahmutkaya]

Summary

• ADR-011 gains its Express amendment (slice E7), and corrects a factual slip in its own 2026-09-04 amendment.
• Status line now names both amendments, and the ADR's open "TWINT availability matrix / Connect Express in CH" verification item is closed by measurement rather than deleted.

Issue / plan link

• Plan: ADR-011 amendment, slice E7 (E1 feat(payments): persist the connected account we mint, before the registry PR (E1) #227 · E2 feat(payments): mint a tenant Express connected account, prefilled (E2) #228 · E3 feat(payments): the platform mints the connected account, so one registry PR carries both halves (E3) #229 · E4 feat(payments): the restaurant's own onboarding page, minting a fresh Stripe link per request (E4) #230 · E6-sofra feat(payments): the control plane says what Express actually does (E6-sofra) #231 · E5 feat(payments): learn from Stripe when a restaurant finishes onboarding (E5) #232 · E7a feat(payments): the registry entry carries the tenant payments link, finished (E7a) #233).

Type

• docs

The correction this ADR owed itself

The 2026-09-04 amendment calls the mechanism "the existing Connect Standard direct charge". The throwaway account that measurement actually ran against — acct_1UC065FfnKu8VnLM, still in the test platform — is type: none, with controller.losses.payments = application and controller.requirement_collection = application. That is the same loss model as Express, and not Standard at all. Which is good news rather than embarrassing: the NL→CH application fee was already proven on a platform-loss-liable account, so this migration inherits a result instead of needing a new one.

What the amendment records, all measured 2026-09-05 in TEST mode

Platform acct_1TpwTNCAHTt6eZ8i (NL), CH Express accounts created and then deleted — GET on each afterwards returns 403, and GET /v1/accounts?limit=20 lists only the two pre-existing accounts.

• TWINT on CH Express works, and our automation is the correct mechanism — same two payment-method configurations, exactly one with parent: null, flip returns available: true. provision-tenant.sh:1001-1058 needs no change. This was the single highest provisioning-break risk of the migration, because that shape had only ever been measured on Standard.
• The platform still cannot accept ToS — the 400 names "Standard and Express accounts", so Express shortens the sitting rather than removing it.
• Prefill is real and create-only — 16 → 13 → 6 currently_due, and 403 oauth_not_supported on update.
• An address is not a neutral prefill — individual[…] without business_type is a hard 400, and business_type cannot be corrected afterwards. With no such knowledge we send neither and take 13 over a permanent wrong.
• The commission mechanism survives untouched — PI and Checkout both 200 with application_fee_amount on an Express account.
• Account Links have a 300-second fuse, two calls give two URLs, account_update links are refused on Express, and a login link is refused before onboarding finishes.
• What Express costs is recorded as accepted (platform loss liability, the 180-day reserve, no Managed Risk), along with the mitigation it grants (settings.payouts.schedule).
• Three owner-side prerequisites, none of them code: platform profile, CH Express onboarding enabled per-country, and Connect → write on the control plane's key — never the box's.
• Still UNVERIFIED, and marked so: twint_payments reaching active; CH Express fee rates; livemode deletability.

NFR triage

• D10 conventions: rule 8 — the doc is fixed by the change that found it wrong. The amendment is appended in the ADR's own voice and the earlier amendment is corrected in place rather than rewritten, so the record still shows what was believed on 2026-09-04.
• Rest: n/a because documentation only — no code, no schema, no strings.

Test plan

• check-single-file --all green (docs are length-checked too)
• Every number in the amendment traces to a probe in this migration's PRs; nothing is repeated from documentation without being labelled as such
• The companion workspace-repo edits (runbook §2b rewritten, BACKLOG's ToS line corrected, the now-taken "platform-created Stripe accounts" decision removed, plus four new follow-up entries) land in the meta-repo, which is ungated by design.

Deploy notes

• Migration one-off required: no. New env vars: none. Rollout risk: none — documentation.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud