Hainrixz/all-deploy

Que fait all-deploy ?

Détecte, audite et déploie des projets vers l'hébergeur approprié avec un flux confirmé d'aperçu → production. La valeur unique est détecter → auditer → router vers la bonne CLI, pas encapsuler la CLI.

Configuration (modifiez ces lignes pour changer le comportement par défaut)

CONFIRMATION_MODE: ask_at_start
  # ask_at_start (défaut) : le skill demande au début de chaque déploiement cloud
  #                         s'il faut fonctionner en mode entièrement automatique
  #                         ou pas à pas.
  # full_auto :             ignorer la question. Audit → aperçu → production avec
  #                         une fenêtre d'arrêt de 5 secondes avant la production.
  # always_ask :            ignorer la question. Exiger un « oui » explicite avant la production.
VISUAL_VERIFY: false           # true → aperçu par capture d'écran via chrome-bridge-automation (frontend uniquement)
ALLOW_DIRTY_TREE: false        # true → ignorer la vérification d'intégrité de l'arbre de travail

Le mode par défaut ask_at_start convient aussi bien aux auteurs individuels qu'aux utilisateurs de la communauté — le choix du mode est déplacé à l'exécution. Fixer full_auto ou always_ask n'est utile que lorsque le skill est intégré dans une automatisation qui ne peut pas répondre à la question de manière interactive.

Règles strictes (ne jamais violer — c'est le contrat de sécurité)

1. Ne jamais contourner ou assouplir l'audit. L'audit est la seule barrière entre l'intention de l'utilisateur et l'infrastructure en production en mode full_auto. Si une vérification ne peut pas être exécutée, cela constitue en soi un blocage, pas une raison pour l'ignorer.
2. Ne jamais déployer en production avant un aperçu réussi avec une vérification de santé 2xx/3xx. Aperçu → résumé → production. Pas de production sans un aperçu vert dans la même session. (Certaines cibles statiques n'ont pas d'environnement d'aperçu — GitHub Pages, un téléchargement via navigateur. Dans ce cas, l'artefact vert est une exécution locale de python3 -m http.server du répertoire de publication exact, vérifiée de la même manière. La barrière reste obligatoire ; seul l'endroit où elle est servie change.)
3. Ne jamais valider, imprimer ou enregistrer des secrets. Si un secret est trouvé dans des fichiers suivis, interrompre et guider la suppression + la réécriture de l'historique comme une étape distincte approuvée par l'utilisateur. Les valeurs des secrets n'apparaissent jamais dans les résumés, les journaux ou les messages de validation.
4. Ne jamais installer ou authentifier automatiquement des CLI tierces. Donner à l'utilisateur la commande avec le préfixe ! (par exemple, ! vercel login, ! railway login).
5. Ne jamais encapsuler une CLI cible dans un script personnalisé qui cache les drapeaux. Les fichiers de référence documentent les commandes réelles que l'utilisateur peut lire et vérifier.
6. Ne jamais modifier le code pour faire passer l'audit sans d'abord montrer la différence. .gitignore, .env.example, le squelette Dockerfile, les corrections de liaison de port — tout doit être montré et approuvé avant l'application.
7. Ne jamais déployer à partir d'un arbre de travail sale à moins que ALLOW_DIRTY_TREE: true ne soit défini. Les modifications non validées compliquent le retour en arrière.
8. Respectez « attendez. » Entre l'aperçu et la production, toute parole de l'utilisateur ressemblant à une hésitation (attends/stop/encore pas/annule) annule proprement l'étape de production.

Deux modes

Décidez en amont à partir du libellé de l'utilisateur :

• Déploiement cloud (par défaut) — Phases 0 à 6 ci-dessous. Déclencheurs : « deploy », « ship », « push to prod », « get it online », « /all-deploy ».
• Exécution locale — Phases 0, 1, 2, puis une étape d'exécution locale. Déclencheurs : « run it locally », « corre esto localmente », « /all-deploy local », « just run it », ou --local.

Classe de projet (décidée à l'intérieur du déploiement cloud, pas un troisième mode)

Le déploiement cloud couvre deux formes, et la classe est détectée — jamais demandée :

• app (par défaut) — un service avec un exécuteur, une commande de démarrage et un port.
• static — un site web : un dossier de fichiers qu'un hébergeur copie sur un CDN. Pas de serveur, pas de port, pas d'exécuteur. Classifié dans la phase 0.0 ci-dessous. Les phases 0, 2, 3.2, 4, 4.5, 5 et 6 changent ; lisez references/static-sites.md pour l'ensemble complet des ajustements.

En mode exécution locale, exécutez un audit ciblé — uniquement les secrets dans les fichiers suivis, l'existence de la commande de démarrage, et la liaison de port correcte. Ignorez : dépôt distant git, HEAD propre, npm audit/pip-audit, l'exhaustivité de .env.example et la livraison des variables d'environnement (pas de dépôt distant pour livrer). Ensuite, exécutez la commande de démarrage détectée (npm run dev / uvicorn main:app --reload --host 0.0.0.0 --port $PORT / docker compose up etc.) au premier plan, en diffusant la sortie via Monitor. Si l'utilisateur demande également d'exposer le serveur local, enchaînez avec references/targets/cloudflared-tunnel.md. Tout le reste de ce fichier concerne le déploiement cloud.

Workflow de déploiement cloud

Sélection du mode (s'exécute avant la phase 0 en mode ask_at_start)

Résoudre le CONFIRMATION_MODE effectif pour cette exécution :

1. Si l'invocation de l'utilisateur contient un marqueur de mode explicite, l'adopter et ignorer la question :

   • Déclencheurs full_auto : « auto », « full auto », « auto deploy », « deploy auto », « /all-deploy auto », « yolo ».
   • Déclencheurs always_ask : « step », « step by step », « one at a time », « confirm each step », « paso a paso », « /all-deploy step ».

2. Sinon, si CONFIRMATION_MODE est fixé à full_auto ou always_ask dans le bloc de configuration ci-dessus, utiliser celui-ci et ignorer la question.

3. Sinon (ask_at_start, par défaut), demander à l'utilisateur une fois, avant l'exécution de la phase 0 :

   « Avant de commencer — comment dois-je effectuer le déploiement ?

   1. Entièrement automatique — j'exécute l'audit → l'aperçu → la promotion en production en séquence. La production est lancée après une fenêtre d'arrêt de 5 secondes. 2. Pas à pas — je m'arrête pour votre accord entre l'audit, l'aperçu et la production.

   Répondez 'auto' ou 'step'. »

Le mode choisi s'applique uniquement à cette exécution — une future invocation demande à nouveau (à moins que l'utilisateur n'accepte explicitement via une phrase déclencheuse ou que le bloc de configuration ne soit fixé).

« Attends » / « stop » / « tiens » à tout moment annule toujours l'étape de production dans les deux modes (règle stricte 8). La différence est de savoir si vous obtenez une fenêtre d'arrêt de 5 secondes (full_auto) ou une pause exigeant un « oui » explicite (always_ask) avant l'exécution de la commande de production.

Phase 0.0 — Classe de projet (s'exécute en premier, avant les prérequis)

Définir PROJECT_CLASS: static s'il y a un fichier HTML — à la racine ou dans dist/, _site/, public/, build/, out/, site/ — et aucun des fichiers package.json, pyproject.toml, requirements.txt, Pipfile, Dockerfile, docker-compose.yml, Procfile, go.mod, Gemfile à la racine. Sinon PROJECT_CLASS: app.

Le test de manifeste est ce qui maintient un dépôt Vite/Next/Astro — qui a aussi un index.html — sur le pipeline d'application. Si static, lisez references/static-sites.md maintenant ; son tableau de phases régit tout ce qui suit.

Cette phase s'exécute avant la phase 0 intentionnellement. Vérifier les prérequis en premier était ce qui causait le rejet d'un dossier de HTML pour absence de dépôt distant git dont il n'avait jamais besoin.

Phase 0 — Prérequis (indépendants de la cible)

Vérifier dans l'ordre. Chaque échec interrompt avec une commande ! pour l'utilisateur.

1. Dépôt Git. Exécuter git rev-parse --is-inside-work-tree. Si ce n'est pas un dépôt, interrompre sauf si le mode est « exécution locale » (qui ne nécessite pas git) ou PROJECT_CLASS: static — un site statique peut être déployé depuis un simple dossier. Dire qu'il n'y a pas de dépôt et continuer ; la décision vient à la phase 3.2. Ne jamais exécuter git init non demandé.
2. Dépôt distant git (déploiement cloud uniquement). Exécuter git remote -v. Si aucun dépôt distant n'est configuré, interrompre sauf si la cible sera docker-vps (déployable sans dépôt distant), ou PROJECT_CLASS: static et la cible n'est pas GitHub Pages ou Render — le téléchargement direct Cloudflare Pages et Netlify Drop n'ont besoin d'aucun dépôt. Cette deuxième clause est réévaluée après la phase 3.
3. Limite de langage. v1 identifie les écosystèmes Node et Python. Si le langage principal est Go, Rust, Ruby, Elixir, Bun ou Deno, quitter avec : « v1 détecte uniquement les écosystèmes Node/Python. Exécutez la CLI cible directement (vercel, railway, flyctl, docker). Le support de ce langage est prévu dans v2. » Non applicable lorsque PROJECT_CLASS: static — HTML/CSS/JS est toujours dans le périmètre, avec ou sans étape de build.

L'authentification de la CLI cible est vérifiée dans la phase 3.5 (ci-dessous), après le choix de la cible.

Phase 0.5 — Amorçage des invites de permission (première exécution uniquement)

Dire à l'utilisateur : « Exécutez le skill fewer-permission-prompts une fois sur ce projet pour amorcer .claude/settings.json avec une liste d'autorisation de déploiement — sinon chaque étape demandera une confirmation. » Indication uniquement. Ne jamais modifier les paramètres de l'utilisateur ici.

Phase 1 — Détection

Lire references/project-types.md (chemin relatif au skill — Claude le résout par rapport au répertoire d'installation du skill) pour le tableau complet d'identification. Inspecter :

• Gestionnaires de paquets et manifestes : package.json, pnpm-lock.yaml, yarn.lock, package-lock.json, bun.lockb, pyproject.toml, requirements.txt, poetry.lock, uv.lock, Pipfile.
• Signaux de framework : next.config.*, vite.config.*, astro.config.*, remix.config.*, nuxt.config.*, svelte.config.*, app/ vs pages/, main.py avec FastAPI(), Flask(), app = FastAPI(), server.py, index.html à la racine.
• Version d'exécution : .nvmrc, .node-version, engines dans package.json, .python-version, python_version dans pyproject.toml. Si une cible de longue durée est choisie et qu'aucun exécuteur n'est fixé, l'audit bloque.
• Dépendances BD / avec état : imports de sqlalchemy, psycopg, prisma, mongoose, redis, ioredis, sqlmodel. Si trouvés, afficher « ce service a besoin d'une base de données — provisionnez-en une avant la production » avec la commande d'add-on Railway issue de la référence Railway.
• Port + commande de démarrage : uvicorn, gunicorn, next start, node server.js, python -m .... Vérifier la liaison 0.0.0.0 et l'utilisation de $PORT. La liaison localhost uniquement bloque pour les cibles de longue durée.
• Monorepo : pnpm-workspace.yaml, turbo.json, nx.json, lerna.json, ou "workspaces" dans le package.json racine → énumérer les paquets et demander lequel déployer. Ne pas deviner.
• Bibliothèque / CLI (pas un déploiement web) : Signal Node — champ bin: présent dans package.json OU (tableau files: présent ET pas de scripts.start ET pas d'imports de framework HTTP comme express, fastify, hono, next, koa). Signal Python — [project.scripts] / console_scripts dans pyproject.toml ET pas de uvicorn/gunicorn/flask/fastapi dans les scripts ou imports déclarés. Ne pas utiliser main: seul comme signal de bibliothèque — presque toutes les applications web Node définissent aussi main:. Quitter proprement : « Cela ressemble à un paquet — /all-deploy cible les services web, pas les publications npm/PyPI. »
• Configuration de déploiement existante : vercel.json, railway.toml, fly.toml, Dockerfile, render.yaml — respecter, auditer, ne pas régénérer sans demande explicite.
• Liaison de projet existante : .vercel/project.json → réutiliser cet ID de projet Vercel. railway.toml avec champ project → réutiliser. Le redéploiement est le cas courant ; les projets frais nécessitent un « partir de zéro » explicite.

Lorsque PROJECT_CLASS: static, ignorer l'identification du framework/exécuteur/port/BD/monorepo. Détecter seulement trois choses : le répertoire de publication (le dossier contenant index.html — ., dist/, _site/, public/, build/, out/, site/), si une étape de build existe, et si un dépôt git existe. Le tableau des répertoires de publication se trouve dans references/static-sites.md ; se tromper est la cause la plus courante d'un site en direct qui retourne 404 à /.

Sortie : un bloc de classification et une liste classée de cibles candidates avec une ligne de justification chacune. Voir references/project-types.md pour la grille complète de classement des cibles.

Phase 2 — Audit (strict, bloquant)

Exécuter le script d'audit fourni avec ce skill (scripts/audit.py) dans le répertoire du projet actuel. Claude résout le chemin du skill au moment du chargement — l'invocation ressemble à :

python3 <CHEMIN_SKILL>/scripts/audit.py <chemin-projet>

Lorsque PROJECT_CLASS: static :

python3 <CHEMIN_SKILL>/scripts/audit.py <chemin-projet> --profile static --publish-dir <rép> [--target <nom>]

Cela ignore toutes les vérifications qui supposent un arbre de dépendances, une commande de démarrage, un port ou un dépôt distant git — celles-ci émettent des critiques erronées sur un simple dossier de HTML — et exécute scripts/static_check.py à la place. Passer --target github-pages lorsque c'est la cible choisie : c'est la seule cible statique qui a vraiment besoin d'un dépôt distant, et la seule où .nojekyll et les chemins relatifs à la racine importent. Liste de vérification dans references/static-sites.md.

Où <CHEMIN_SKILL> est l'emplacement d'installation du skill (typiquement ~/.claude/skills/all-deploy/) et <chemin-projet> est généralement .. Le script vérifie chaque élément de references/audit-checklist.md : secrets dans les fichiers suivis, couverture de .gitignore, cohérence du fichier de verrouillage, exhaustivité de .env.example (via scripts/env_extract.py), existence des scripts de build/démarrage, liaison de port, HEAD propre, correspondance du dépôt distant, npm audit --production --audit-level=high ou pip-audit.

Tout échec interrompt. Pour chaque problème, montrer le correctif sous forme de diff (si applicable) et attendre l'accord de l'utilisateur avant d'appliquer. Le mode automatique ne contourne pas l'audit.

L'analyse des secrets dans l'historique git est exécutée par l'utilisateur, pas automatiquement. Dans la sortie d'audit, afficher : trufflehog git file://. ou git log -p -S 'sk_' -S 'AKIA' -S 'ghp_' comme une étape distincte. Le skill ne réécrit jamais l'historique git.

Phase 3 — Sélection de la cible

Présenter les candidates classées de la phase 1 avec une ligne de justification chacune. L'utilisateur choisit ou accepte le premier choix avec « ok ». C'est seulement maintenant que la référence de la cible est chargée :

• references/targets/vercel.md — Next, Vite, Astro, Remix, Nuxt, SvelteKit, statique
• references/targets/railway.md — FastAPI, Flask, Express, workers Python, MCP HTTP, Claude Agent SDK
• references/targets/docker-vps.md — tout Dockerfile, charges de travail avec état, auto-hébergé
• references/targets/cloudflared-tunnel.md — exposer le développement local, démonstration rapide
• references/targets/cloudflare-pages.md — sites statiques ; le choix par défaut lorsque quelqu'un est payé
• references/targets/netlify.md — sites statiques nécessitant un formulaire ; glisser-déposer
• references/targets/github-pages.md — portfolio, documentation, démos déjà sur GitHub
• references/targets/render.md — sites statiques, faible trafic

Pour PROJECT_CLASS: static, lire references/static-hosting.md avant de présenter les candidates. Il contient la comparaison, les limites du niveau gratuit et la matrice d'utilisation commerciale — et la question qui détermine réellement le classement : « quelqu'un est-il payé en relation avec cette page ? » Un oui retire Vercel Hobby (« recevoir un paiement pour créer, mettre à jour ou héberger le site » est une utilisation commerciale selon ses conditions d'utilisation équitable) et généralement GitHub Pages aussi.