amagnatema/ship-cloudflare-sites

Ship Cloudflare Sites v1.1

Arbeite auf Basis von Repository-Beweisen und der vom Benutzer angeforderten Reichweite. Eine Anfrage zum Deployment autorisiert den normalen Deployment-Workflow für die genannte Umgebung; frage nur nach, wenn eine zusätzliche destruktive, irreversible oder materiell breitere Änderung nötig wird. Leite niemals ein Produktionsziel aus einer nicht spezifizierten Umgebung ab.

Projekt entdecken

1. Lese Repository-Anweisungen und inspiziere den aktuellen Arbeitsbaum vor der Bearbeitung.
2. Führe scripts/audit-cloudflare-project.sh <Projekt-Root> aus und inspiziere jeden gemeldeten Blocker.
3. Ermittle Framework, Paketmanager, Adapter, Worker-Einstieg, Wrangler-Konfiguration, Umgebungen, Bindungen, Migrationen, Domains, CI-Pfad und Secret-Namen aus Dateien – nicht aus dem Gedächtnis.
4. Verwende das repository-pinned CLI. Überprüfe veränderliches Cloudflare/OpenNext-Verhalten in lokaler --help und aktueller offizieller Dokumentation vor Remote-Änderungen.
5. Lese nur die relevanten Referenzen:
   • Lese references/release-workflow.md für Release, Rollback oder Versioniteration.
   • Lese references/cloudflare-resources.md für die Bereitstellung oder Änderung von D1, R2, Secrets, Domains, Caching, Umgebungen oder Observability.

Betriebsmodus wählen

• Audit/Plan: bleibe schreibgeschützt. Gib Beweise, Blocker, Risiken und genaue nächste Aktionen zurück.
• Entwicklung/Konfiguration: bearbeite und verifiziere lokal. Erstelle Remote-Ressourcen nur, wenn der Benutzer die Bereitstellung angefordert hat oder das Deployment sie benötigt.
• Provisionierung: bestätige Konto, Zone, Umgebung, Namen und beabsichtigte Eigentümerschaft. Erstelle nur fehlende Ressourcen und persistiere zurückgegebene IDs in der gewählten Konfiguration.
• Release: baue einmal, dann deploye dieses verifizierte Artefakt. Verwende direktes Deployment für risikoarme Releases, wenn angefordert; verwende Version-Upload plus kontrollierte Promotion für riskante oder explizit schrittweise Releases.
• Recovery: wähle eine bekannte funktionierende Worker-Version, behandle dann D1- und R2-Zustand separat. Worker-Versionen enthalten keinen Speicherzustand.

Invariante Sicherheitsvorkehrungen anwenden

• Unterscheide lokale, Preview/Staging- und Produktionsressourcen. Mache das Ziel jedes Remote-Befehls explizit.
• Halte Secret-Werte aus Quellcode, Ausgabe, Screenshots und Shell-Argumenten fern. Melde nur Namen und Vorhandensein.
• Überprüfe einen verschmutzten Worktree vor dem Release. Verwerfe, committe oder versende nicht zusammenhängende Benutzeränderungen nicht.
• Modelliere D1-Änderungen als geordnete Migrationen und bevorzuge Expand/Backfill/Contract über Releases hinweg.
• Verwende unveränderliche oder versionierte R2-Schlüssel für langlebige Cache-Assets. Behandle Überschreiben, Löschen, CORS-Änderung und Cache-Leeren als eine koordinierte Änderung.
• Behandle Worker Custom Domains und R2 Custom Domains als separate Ressourcen. Überprüfe Apex, www, kanonische Weiterleitungen, Zertifikate und Asset-Hostname unabhängig.
• Bezeichne einen Upload nicht als erfolgreichen Release. Verifiziere den öffentlichen Hostnamen, kritische Routen, D1-gestütztes Verhalten, ein repräsentatives R2-Objekt und Logs nach dem Deployment.

Einen Release-Nachweis erstellen

Zurückgeben:

• Release-ID, Git-Commit, Umgebung, Worker- und Speicher-Ressourcennamen;
• ausgelieferte Quell-/Konfigurationsänderungen und ausgeschlossene Worktree-Änderungen;
• lokale Prüfungen und ihre Ergebnisse;
• D1-Migrationen plus Recovery-Lesezeichen/Export und Kompatibilitätsreihenfolge;
• R2-/Domain-/Cache-/Secret-Änderungen ohne Secret-Werte;
• Worker-Version/Deployment-ID und Traffic-Prozentsatz, wenn verfügbar;
• Smoke-Test-URLs und Ergebnisse;
• Rollback-Ziel, Speicher-Caveats und verbleibende manuelle Aktionen.

Wenn eine Prüfung fehlschlägt, stoppe vor der unsicheren Grenze, bewahre die Beweise auf und teile mit, was noch übrig ist. Schwäche keine Prüfung stillschweigend ab.