swyxio/skills

Forge

Forge bietet zwei Oberflächen auf Cloudflare:

• Repositories: Git-Hosting, Issues, Pull Requests, Actions, Transkripte und Repository-Agenten.
• Deploy / Sites: Ein exakt gepushter SHA wird zu einer Vorschau und kann später zur Produktionsanwendung werden.

Cloudflare bleibt die Laufzeit/der Anbieter. Ersetzen Sie kein anderes Git- oder Hosting-Produkt, wenn Forge das angeforderte Ziel ist, und gehen Sie nicht davon aus, dass eine gehostete App die Authentifizierung von Forge oder Cloudflare Access erbt.

Aufgabenumfang begrenzen

Klassifizieren Sie das angeforderte Ergebnis, bevor Sie weitere Prozesse laden:

• Repository-Operation: Verwenden Sie normales Git mit Forge-Authentifizierung.
• Kundenanwendungs-Deployment: Verwenden Sie Forge Deploy und dessen Release-Ledger.
• Forge-Infrastruktur-Reparatur: Verwenden Sie den kleinstmöglichen gesunden Release-Pfad; die reparierte Steuerungsebene muss nicht ihren eigenen Fix deployen.
• Nur-Code, CLI, Dokumentation, Analyse oder UI-Arbeit: Fügen Sie keine Produktions-Release-Gates hinzu, es sei denn, der Benutzer hat auch ein Deployment angefordert.

Thread-lokale Haltepunkte und nicht zusammenhängende Releases sind keine globalen Voraussetzungen. Wenden Sie nur die Prüfungen an, die ein konkretes Risiko in der angeforderten Aktion mindern, und hören Sie auf, wenn dieses Ergebnis nachgewiesen ist. Notieren Sie nicht zusammenhängende Erkenntnisse als Folgemaßnahmen.

Aktuelles Verhalten ermitteln

Forge entwickelt sich weiter. Verwenden Sie die installierte CLI, das Ziel-Repository, die aktuelle UI/API und nur die relevante Erstanbieter-Quelle, die über die Forge-Quellkarte geleitet wird. Die Dokumentation beweist nicht die aktuelle Kontoberechtigung, Limits oder den Release-Status.

Prüfen Sie die Syntax vor dem Erstellen von Befehlen:

sf help
sf commands --json
sf schema --json
sf <command> --help

Identifizieren Sie das Konto, das Repository, den Standard-Branch und für Deploy das Projekt-Root. Behalten Sie einen vorhandenen GitHub-Remote bei, es sei denn, der Benutzer bittet um dessen Ersatz.

Repository-Authentifizierung

Ein angemeldeter Forge-Browser ist kein lokales Git-Credential. Verwenden Sie den gescopedten Credential-Fluss von Forge, ohne dessen Token offenzulegen:

sf auth status
sf auth git-credential <owner>/<repo>
git ls-remote <forge-remote> HEAD

Behalten Sie credential.useHttpPath aktiviert. Extrahieren Sie niemals Tokens aus dem Browserspeicher oder der Schlüsselbund einer anderen Anwendung, und setzen Sie sie nicht in Remotes, Quellcode, Shell-Verlauf oder Ausgabe. Führen Sie keinen Force-Push durch, ersetzen Sie nicht origin, ändern Sie nicht die Sichtbarkeit und erweitern Sie keine Credential-Bereiche ohne die erforderliche Autorisierung.

Für die Migration von GitHub verwenden Sie den aktuellen Import-Fluss von Forge. Behalten Sie den Paketmanager bei und behandeln Sie Git LFS separat; das Importieren von Verlauf kopiert keine gehosteten LFS-Objekte.

Forge Deploy-Vertrag

Forge veröffentlicht einen exakt gepushten SHA, nicht den lokalen Checkout. Quelle, Build, Vorschau, Provider-Veröffentlichung, Produktionsaktivierung und Live-Verifizierung sind unterschiedliche Zustände.

Jedes Projekt benötigt ein reines Daten-forgeBuild.ts v1 in seinem konfigurierten Root. Lesen Sie die aktuelle Manifest-Quelle aus der Quellkarte und validieren Sie dann:

npx smolforge deploy check

• Das Weglassen von build führt keinen Repository-Build-Befehl aus.
• forgeBuild.ts wird statisch ausgewertet; verwenden Sie keine ausführbare Konfiguration, dynamische Imports oder forge.yml/forge.yaml.
• Eine App benötigt einen HTTP-Einstiegspunkt, Assets oder beides. Verwenden Sie einen SPA-Fallback nur für clientseitiges Routing.
• .forge/config.json kann Projekte zuordnen und Bindungen vorschlagen; es erstellt keine Projekte, wendet keine Provider-Zustände an oder gewährt DNS-Autorität.
• Importierte Wrangler-Bindungen können Produktionsressourcen für Vorschauen offenlegen.

Das Erstellen oder Aktivieren eines Projekts, das Akzeptieren von Servicebedingungen, die Promotion, der Rollback, die Deaktivierung, Routen und die Provider-Anwendung sind separate externe Zustandsänderungen. Vorschau-URLs sind nicht gelistet und noindex, aber nicht privat; legen Sie niemals Geheimnisse oder private Daten darin ab.

Release und Wiederherstellung

Verwenden Sie Forge Deploy für Kundenanwendungen. Für Forge-Infrastruktur bevorzugen Sie den kanonischen Pfad, solange er gesund und verhältnismäßig ist. Direktes Wrangler ist ein autorisierter Operator-Pfad, wenn dieser Pfad nicht verfügbar, ungesund, in den Vorfall verwickelt ist oder die abgegrenzte Reparatur wesentlich behindert; es ist keine Abkürzung um das Release-Ledger einer Kundenanwendung herum.

Für eine direkte Infrastruktur-Reparatur beschränken Sie sich auf eine genaue Komponente, notieren Sie den Quell-SHA, die aktuellen und Rollback-Versionen sowie alle Migrations- oder Bindungsänderungen, und überprüfen Sie dann Traffic, Gesundheit/Abhängigkeiten und eine Reproduktion. Verlangen Sie keine nicht zusammenhängenden Vorschauen, Portfolio-Abstimmung, erschöpfende Beweise oder Koordination mit Aufgaben, die nicht dieselbe Komponente oder dasselbe Schema mutieren können.

Bevor Sie einen blockierten Release erneut versuchen, identifizieren Sie den letzten nachgewiesenen Zustand und die gezielte Diagnose. Überprüfen Sie den genauen SHA, das Projekt-Root, den Branch und die effektiven Build/Asset-Einstellungen. Wiederholen Sie den Versuch nur, wenn die unveränderlichen Ziel- und Idempotenz-Bedingungen klar sind.

Referenzen

Verwenden Sie die Forge-Quellkarte, um nur das Erstanbieter-Dokument zu laden, das die aktuelle Frage besitzt.