Design-Paritaet 1.4 -> 1.5: neuer Warnpunkt in der Vergleichsschleife.
Bevor man eine Rueckmeldung "immer noch nicht behoben" fuer bare Muenze
nimmt, gehoeren die Response-Header geprueft. Ohne config.cache_period
liefert TYPO3 seinen Core-Default von einem Jahr als max-age aus, und
config.sendCacheHeaders = 1 (von t3bootstrap gesetzt) reicht ihn an
Browser und Proxys weiter. Eine erteilte Frist ist nicht widerrufbar,
ein serverseitiges cache:flush erreicht solche Clients also nie. Da
Erweiterungen ihre Konfiguration teils als Inline-JS in die Seite
schreiben, reproduziert eine alte Kopie laengst behobene Fehler exakt.
Cutover 1.0 -> 1.1: derselbe Punkt als Go-live-Pruefung in Phase 2.
Dort wiegt er schwerer, weil nach dem Livegang jeder Besucher mit einer
bereits erteilten Jahresfrist festhaengt.
Beides stammt aus einem realen Fall: Rueckmeldungen aus dem Kundennetz
meldeten Fehler weiter, die im Agenturnetz nachweislich behoben waren.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Das Go-live ist eine eigene Aufgabe, nicht der letzte Schritt des
Staging-Deployments: oeffentlich, schwer umkehrbar, anderes Risiko.
Phasen: Cutover-Modell waehlen; aufraeumen, was nicht mit auf live darf
(DB-Dumps, Einmal-Skripte, .bak-Configs, Fehlerlogs); umgebungsabhaengige
Konfiguration (trustedHostsPattern, displayErrors, site base, DB-Zugang,
Mail); Staging-Sperren entfernen (Basic-Auth, noindex, Testkonten);
Redirects/Scheduler/Sprachpakete/SSL; Verifikation und Rueckweg.
Die Beispiele stammen aus einem realen Staging-Account: ~26 MB Dumps und
Ticket-Sicherungen im Home, eine .bak-Config im Projektbaum, Basic-Auth
in public/.htaccess, displayErrors=1 und ein auf die Staging-Domain
gepinntes trustedHostsPattern.
Die konsoleH-Deploy-Skill (jetzt 1.1) verweist am Ende darauf und benennt
die beiden Artefakte, die sie selbst erzeugt und die nicht mitwandern
duerfen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
melnicenkoandClaude Opus 5