Plattform-Hosts bereitstellen — `pwa` aufgenommen, aber nur hinter dem Freischalt-Schalter
Zweite Haelfte von Auftrag 1 des Briefes `white-label-anmelde-host-form-b-umsetzen`.
Die Route kann einen Plattform-Host seit 2026-08-21 (`shared/hostRouting.ts`); was
fehlte, war der getrennte Freischalt-Schalter aus CEO-Entscheid 3 vom 2026-08-19.
Er steht seit `aYOUneResellers.platformHostEnabled` (interfaces 2026.452.0) im
Vertrag, also ist die Reihenfolge des Auftrags jetzt erfuellt.
`SERVABLE_SERVICE_TYPES` traegt jetzt `pwa` — und das ist NUR zusammen mit dem
neuen `shared/platformHostGate.ts` richtig. Die Liste ist fuer `pwa` ab jetzt eine
VORAUSWAHL, kein Praedikat; erlaubt ist ein Host nur, wenn BEIDES gilt:
1. sein Wiederverkaeufer traegt `platformHostEnabled: true` (die Entscheidung), UND
2. sein Name liegt als bekanntes Etikett (`login.`/`app.`, genau EINE Ebene)
direkt unter dessen `domain` (die Zuordnung).
Das Tor steht an VIER Stellen, und die vierte ist die massgebliche:
- `startup/reconcileDomains.ts` — kein Auftrag, der ohnehin abbricht
- `jobs/checkDomainHealth.ts` — sonst Dauer-Alarm alle fuenf Minuten fuer
einen Zustand, der die richtige Antwort ist
- `jobs/provisionDomain.ts` (Geschwister) — 🔴 ohne diese Stelle waere die
Negativ-Kontrolle des Auftrags NICHT erfuellt: `resolveFeatureHosts` laedt
art-blind, ein `app.kunde.de` reiste deshalb als Geschwister einer ganz
normalen `consumer`-Domaene als SAN ins Zertifikat UND als Regel in die
Route — ohne eigenen Auftrag und ohne Freischaltung. Genau der Befund
"Tor und Zertifikat tragen einen pwa-Host BEREITS" der Messung vom 08-19.
- `jobs/provisionDomain.ts` (Auftrag) — fail-closed, egal wie ein Auftrag
entstanden ist (Abgleich, `verifyDomain`, Wiederholung von Hand). Ein
Ausschluss nur am Abgleich waere eine Zusage mit Luecke.
Die Ladung des Datensatzes wandert dafuer VOR den docker-compose-Zweig — jener
setzt `tls.provisioned` und beendet den Auftrag, ohne den `try` je zu betreten.
Fail-closed in jeder Richtung: keine Datenbank, kein Treiber, ein Wurf, ein leeres
Feld ergeben die LEERE Menge und damit keinen Plattform-Host — Byte fuer Byte das
Verhalten von vorher. Der schlimmste Ausgang eines Ausfalls ist, dass ein
freigeschalteter Host wartet, nie dass ein nicht freigeschalteter einen bekommt.
⚠ ZWILLING, bewusst benannt: `platform/auth/src/lib/platformHostOrigins.ts` stellt
dieselbe Frage fuer die Herkunfts-Erlaubnis. Zwei Kopien einer Regel, die
entscheidet OB eine Domaene angefasst werden darf, laufen auseinander — dieselbe
Erfahrung, die `MANUALLY_MANAGED_ZONES` in den Kern gehoben hat. Der Hub ist als
eigener Auftrag angemeldet (er braucht einen Fundament-Platz, den dieser Brief
nicht haelt).
Proben: neue `shared/platformHostGate.test.mjs` 35/35 (beide Richtungen am
Auftrag selbst: OHNE Schalter kein Zertifikat/Tor/Route, MIT Schalter alle drei;
Fail-closed bei Wurf; Sicherheits-Grenze `app.boesekunde.example` gegen
`kunde.example`). `servableServiceTypes.test.mjs` mitgezogen und um eine
Flip-Probe erweitert (25/25) — die Behauptung zu `pwa` wurde UMGEDREHT statt
gestrichen, damit die Zwei-Stufigkeit sichtbar bleibt. Volle Reihe exit 0.
Die Route kann einen Plattform-Host seit 2026-08-21 (`shared/hostRouting.ts`); was
fehlte, war der getrennte Freischalt-Schalter aus CEO-Entscheid 3 vom 2026-08-19.
Er steht seit `aYOUneResellers.platformHostEnabled` (interfaces 2026.452.0) im
Vertrag, also ist die Reihenfolge des Auftrags jetzt erfuellt.
`SERVABLE_SERVICE_TYPES` traegt jetzt `pwa` — und das ist NUR zusammen mit dem
neuen `shared/platformHostGate.ts` richtig. Die Liste ist fuer `pwa` ab jetzt eine
VORAUSWAHL, kein Praedikat; erlaubt ist ein Host nur, wenn BEIDES gilt:
1. sein Wiederverkaeufer traegt `platformHostEnabled: true` (die Entscheidung), UND
2. sein Name liegt als bekanntes Etikett (`login.`/`app.`, genau EINE Ebene)
direkt unter dessen `domain` (die Zuordnung).
Das Tor steht an VIER Stellen, und die vierte ist die massgebliche:
- `startup/reconcileDomains.ts` — kein Auftrag, der ohnehin abbricht
- `jobs/checkDomainHealth.ts` — sonst Dauer-Alarm alle fuenf Minuten fuer
einen Zustand, der die richtige Antwort ist
- `jobs/provisionDomain.ts` (Geschwister) — 🔴 ohne diese Stelle waere die
Negativ-Kontrolle des Auftrags NICHT erfuellt: `resolveFeatureHosts` laedt
art-blind, ein `app.kunde.de` reiste deshalb als Geschwister einer ganz
normalen `consumer`-Domaene als SAN ins Zertifikat UND als Regel in die
Route — ohne eigenen Auftrag und ohne Freischaltung. Genau der Befund
"Tor und Zertifikat tragen einen pwa-Host BEREITS" der Messung vom 08-19.
- `jobs/provisionDomain.ts` (Auftrag) — fail-closed, egal wie ein Auftrag
entstanden ist (Abgleich, `verifyDomain`, Wiederholung von Hand). Ein
Ausschluss nur am Abgleich waere eine Zusage mit Luecke.
Die Ladung des Datensatzes wandert dafuer VOR den docker-compose-Zweig — jener
setzt `tls.provisioned` und beendet den Auftrag, ohne den `try` je zu betreten.
Fail-closed in jeder Richtung: keine Datenbank, kein Treiber, ein Wurf, ein leeres
Feld ergeben die LEERE Menge und damit keinen Plattform-Host — Byte fuer Byte das
Verhalten von vorher. Der schlimmste Ausgang eines Ausfalls ist, dass ein
freigeschalteter Host wartet, nie dass ein nicht freigeschalteter einen bekommt.
⚠ ZWILLING, bewusst benannt: `platform/auth/src/lib/platformHostOrigins.ts` stellt
dieselbe Frage fuer die Herkunfts-Erlaubnis. Zwei Kopien einer Regel, die
entscheidet OB eine Domaene angefasst werden darf, laufen auseinander — dieselbe
Erfahrung, die `MANUALLY_MANAGED_ZONES` in den Kern gehoben hat. Der Hub ist als
eigener Auftrag angemeldet (er braucht einen Fundament-Platz, den dieser Brief
nicht haelt).
Proben: neue `shared/platformHostGate.test.mjs` 35/35 (beide Richtungen am
Auftrag selbst: OHNE Schalter kein Zertifikat/Tor/Route, MIT Schalter alle drei;
Fail-closed bei Wurf; Sicherheits-Grenze `app.boesekunde.example` gegen
`kunde.example`). `servableServiceTypes.test.mjs` mitgezogen und um eine
Flip-Probe erweitert (25/25) — die Behauptung zu `pwa` wurde UMGEDREHT statt
gestrichen, damit die Zwei-Stufigkeit sichtbar bleibt. Volle Reihe exit 0.