swyxio/skills

Forge

Forge offre deux surfaces au-dessus de Cloudflare :

• Dépôts : hébergement Git, tickets, pull requests, Actions, transcriptions, et agents de dépôt.
• Deploy / Sites : un SHA poussé exact devient une prévisualisation et peut ensuite devenir l'application de production.

Cloudflare reste l'exécuteur/fournisseur. Ne pas substituer un autre produit Git ou d'hébergement lorsque Forge est la destination demandée, et ne pas supposer qu'une application hébergée hérite de l'authentification Forge ou Cloudflare Access.

Limiter le périmètre de la tâche

Classifiez le résultat demandé avant de charger plus de processus :

• Opération sur un dépôt : utiliser Git standard plus l'authentification Forge.
• Déploiement d'une application client : utiliser Forge Deploy et son ledger de publication.
• Réparation d'infrastructure Forge : utiliser le plus petit chemin de publication sain ; le plan de contrôle réparé ne doit pas déployer son propre correctif.
• Travail source uniquement, CLI, documentation, analyse ou interface utilisateur : ne pas ajouter de barrières de publication en production sauf si l'utilisateur demande également un déploiement.

Les maintiens locaux de thread et les publications non liées ne sont pas des prérequis globaux. Appliquez uniquement les vérifications qui atténuent un risque concret dans l'action demandée, et arrêtez-vous lorsque ce résultat est prouvé. Enregistrez les constats non liés comme des suivis.

Résoudre le comportement actuel

Forge évolue. Utilisez la CLI installée, le dépôt cible, l'interface utilisateur/API actuelle, et seulement la documentation propriétaire pertinente routée par la carte source Forge. La documentation ne prouve pas l'éligibilité actuelle du compte, les limites ou l'état de publication.

Inspectez la syntaxe avant de construire des commandes :

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

Identifiez le compte, le dépôt, la branche par défaut et, pour Deploy, la racine du projet. Préservez un remote GitHub existant sauf si l'utilisateur demande à le remplacer.

Authentification au dépôt

Un navigateur connecté à Forge n'est pas une information d'identification Git locale. Utilisez le flux d'informations d'identification limitées de Forge sans exposer son jeton :

sf auth status
sf auth git-credential <propriétaire>/<dépôt>
git ls-remote <remote-forge> HEAD

Gardez credential.useHttpPath activé. N'extrayez jamais les jetons du stockage du navigateur ou du trousseau d'une autre application, et ne les placez pas dans les remotes, le code source, l'historique du shell ou la sortie. Ne forcez pas les pushs, ne remplacez pas origin, ne modifiez pas la visibilité et n'élargissez pas les portées d'identification sans l'autorisation requise.

Pour la migration depuis GitHub, utilisez le flux d'importation actuel de Forge. Préservez le gestionnaire de paquets et gérez Git LFS séparément ; l'importation de l'historique ne copie pas les objets LFS hébergés.

Contrat Forge Deploy

Forge publie un SHA poussé exact, pas la copie de travail locale. La source, la construction, la prévisualisation, la publication par le fournisseur, l'activation en production et la vérification en direct sont des états distincts.

Chaque projet a besoin d'un forgeBuild.ts v1 ne contenant que des données, dans sa racine configurée. Lisez la source du manifeste actuel depuis la carte source, puis validez :

npx smolforge deploy check

• Omettre build n'exécute aucune commande de construction du dépôt.
• forgeBuild.ts est évalué statiquement ; n'utilisez pas de configuration exécutable, d'imports dynamiques ou de forge.yml/forge.yaml.
• Une application a besoin d'un point d'entrée HTTP, d'actifs, ou des deux. Utilisez un fallback SPA uniquement pour le routage côté navigateur.
• .forge/config.json peut mapper des projets et proposer des liaisons ; il ne crée pas de projets, n'applique pas d'état du fournisseur et n'octroie pas d'autorité DNS.
• Les liaisons Wrangler importées peuvent exposer des ressources de production aux prévisualisations.

La création ou l'activation d'un projet, l'acceptation des conditions de service, la promotion, le rollback, la désactivation, les routes et l'application du fournisseur sont des changements d'état externes distincts. Les URL de prévisualisation sont non répertoriées et noindex, pas privées ; n'y mettez jamais de secrets ni de données privées.

Publication et récupération

Utilisez Forge Deploy pour les applications client. Pour l'infrastructure Forge, privilégiez la voie canonique tant qu'elle est saine et proportionnée. Wrangler direct est une voie opérateur autorisée lorsque cette voie est indisponible, malsaine, impliquée dans l'incident ou obstrue matériellement la réparation limitée ; ce n'est pas un raccourci contournant le ledger de publication d'une application client.

Pour une réparation directe de l'infrastructure, délimitez un composant exact, enregistrez le SHA source, les versions actuelle et de rollback, ainsi que toute migration ou modification de liaison, puis vérifiez le trafic, la santé/les dépendances et une reproduction. N'exigez pas de prévisualisations non liées, de réconciliation de portefeuille, de preuve exhaustive ou de coordination avec des tâches qui ne peuvent pas muter le même composant ou schéma.

Avant de réessayer une publication bloquée, identifiez le dernier état prouvé et un diagnostic ciblé. Vérifiez le SHA exact, la racine du projet, la branche et les paramètres de construction/d'actifs effectifs. Ne réessayez que lorsque la cible immuable et les conditions d'idempotence sont claires.

Références

Utilisez la carte source Forge pour charger uniquement le document propriétaire qui possède la question en cours.