Laissez un agent faire l'installation

Vous pouvez déléguer la partie ennuyeuse

Ce dépôt a été écrit pour qu'un agent de code puisse le lire. Il embarque un fichier de carte (llms.txt), un fichier de règles (AGENTS.md), un runbook pas à pas (docs/agent-setup.md) et un prompt tout prêt (prompts/agent-setup.md). Au lieu d'apprendre chaque commande d'installation vous-même, vous collez un prompt et l'agent suit le runbook sur votre ordinateur.

Déléguer la frappe ne veut pas dire sauter les vérifications. L'agent travaille dans votre copie du dépôt et doit rapporter ce qu'il a fait avec des preuves. Les sections ci-dessous montrent à quoi ressemble un bon rapport, pour que vous restiez maître du résultat.

Une limite honnête : ce parcours automatisé installe l'app Web et son backend — le serveur qui gère les comptes et les données. Le prompt et le runbook sont livrés avec le dépôt Web et avec le monorepo All Platforms. Les checkouts Mobile-seul et Desktop-seul embarquent plutôt leur propre llms.txt ciblé et des guides d'installation par plateforme.

• Installez l'app Mobile en local
• Exécutez l'app Desktop

Ce qu'il vous faut d'abord

Terminez d'abord le guide de préparation : Node.js, Git et un éditeur installés, l'invitation GitHub acceptée et le dossier supastack téléchargé sur votre ordinateur. L'agent travaille dans ce dossier, donc tout ce qui figure dans Avant de commencer s'applique toujours.

Il vous faut aussi un outil capable d'agir comme agent de code — un éditeur avec un agent de code IA intégré (un IDE IA), ou un agent qui tourne dans votre terminal (un CLI d'agent). Tout outil récent capable d'agir en agent convient ; le prompt précise déjà ce qu'il doit lire et exécuter, vous n'avez donc pas à rédiger les instructions vous-même.

Enfin, il vous faut l'une des deux façons d'exécuter l'app : Node.js 22 ou plus récent installé sur votre ordinateur — le chemin que le guide de préparation a mis en place — ou un outil de conteneurs comme Docker ou Podman, qui exécute l'app dans des conteneurs et n'a pas besoin de Node.js installé. Vous en choisissez un dans le prompt, et l'agent le suit.

Copiez le prompt, remplissez deux blancs, collez

Ouvrez prompts/agent-setup.md dans l'éditeur — il vit dans le dossier prompts au niveau le plus haut du dossier supastack, à côté de llms.txt. Sélectionnez tout son texte et copiez-le.

Deux placeholders attendent vos choix. Remplacez <SETUP_PATH: docker | podman | host> par docker, podman ou host — host exécute l'app directement sur votre ordinateur avec le Node.js que vous avez installé ; docker ou podman l'exécute dans des conteneurs. Remplacez <DEPLOY_TARGET: coolify | vps-docker | local-only> par l'endroit où l'app doit aboutir — local-only l'exécute sur cet ordinateur et ne déploie rien, ce qui est le bon choix pour un premier aperçu.

Collez le texte édité dans le chat de l'agent et envoyez-le. La première ligne remplie ci-dessous montre les choix docker plus local-only ; les étapes numérotées sous cette ligne restent exactement comme le fichier les livre.

Stand up this supastack checkout end to end for **docker**
and deploy it to **local-only**.

Ce que l'agent fait avec le prompt

Le prompt pointe l'agent vers le runbook et les règles de sécurité, puis lui dit de les parcourir dans l'ordre et de prouver chaque phase. En termes simples, l'agent :

• Lit la carte du dépôt (llms.txt), les règles du projet (AGENTS.md) et les règles de gestion des identifiants (docs/agent-security.md) avant de toucher quoi que ce soit.
• Crée les fichiers de configuration .env avec node scripts/setup-env.mjs. L'utilitaire ne copie que depuis .env.example, donc l'agent n'invente jamais de noms de réglages, et il préserve les secrets que vous avez déjà au lieu de les écraser.
• Démarre Postgres — la base de données où l'app garde les comptes et les enregistrements — et l'app elle-même, en conteneurs pour le chemin docker ou podman, ou avec des commandes sur votre ordinateur pour le chemin host.
• Exécute les migrations de la base — les commandes qui créent les tables de l'app — avant la première vraie connexion, parce qu'un compte créé avant que les tables existent est un compte cassé.
• Vérifie chaque phase à un point de contrôle et finit par un rapport marquant chaque vérification PASS, FAIL, BLOCKED ou NOT RUN, avec la sortie qui l'étaye.

Ce que vous vérifiez dans le rapport de l'agent

Un bon rapport montre des preuves, pas des affirmations. Cherchez la vraie réponse de santé et la sortie de commande derrière chaque PASS — pas une phrase comme « tout fonctionne ».

Le prompt dit à l'agent de s'arrêter et de rapporter après que la même étape a échoué deux fois — pas de contourner l'échec — et de vous demander avant toute action destructive, comme vider une base de données. Si votre agent continue d'improviser après des échecs répétés, arrêtez-le et portez la première erreur au guide de dépannage.

Deux choses ne doivent jamais apparaître : une fonctionnalité de sécurité désactivée pour faire taire une erreur, et une valeur secrète comme un mot de passe ou une clé imprimée dans le chat ou le rapport. Si vous voyez l'une des deux, traitez l'exécution comme échouée.

Gardez la démo et une vraie connexion séparées dans votre tête. Le flux de référence local de la démo /dashboard n'a pas besoin de base de données, donc il peut réussir seul ; créer un compte sur /auth ne fonctionne qu'après l'exécution des migrations. « La démo a marché » n'est pas encore « les comptes marchent ».

Si vous préférez le faire à la main

Chaque étape ci-dessus existe aussi en tutoriel clic par clic. Exécutez le guide Web de cinq minutes pour la première démo, puis Installation locale pour l'environnement local complet avec une vraie base de données.

Un agent reste utile après l'installation même quand il n'a pas fait l'installation — le guide du workflow agent couvre les tâches quotidiennes comme les nouveaux écrans, le re-styling et les relectures.