Cycle

Cinq phases. Les deux premières se jouent une fois, la troisième se répète pour chaque feature, les deux dernières rythment la vie en production. Chaque phase se termine par une porte : une condition vérifiable, sans laquelle on ne passe pas à la suite.

0 Cadrer ──▶ 1 Fonder ──▶ 2 Construire ──▶ 3 Livrer ──▶ 4 Exploiter
   ▲                       │        ▲                        │
   │                       └────────┘                        │
   │                    feature suivante                     │
   └──────────────────── nouvelle tranche ◀──────────────────┘

Les paliersCopier le lien de cette section

Toutes les features ne méritent pas le même effort. Le palier se fixe une fois pour le projet (par /scope), et se relève feature par feature quand l'enjeu l'exige : une maquette de démonstration n'a pas les exigences d'un paiement.

Trois relèvements ne se discutent pas : l'authentification, le paiement et toute écriture de données personnelles sont au moins en Beta, quel que soit le palier du projet.

Les règles de sécurité et de git (MF-003 à MF-009) s'appliquent à tous les paliers, Prototype compris. Un prototype qui fuit un secret a fui un secret.

Phase 0 · CadrerCopier le lien de cette section

Entrée : une idée. Sortie : docs/scope/scope.md.

/scope <l'idée> pose les questions que seul l'humain peut trancher (pour qui, quel problème, ce qui prouve le succès), découpe en features grossières, les ordonne, et recommande le palier par défaut. Il ne choisit aucun outil : ce n'est pas son travail.

Porte : tu as relu le scope, et chaque feature tient en une phrase d'intention et une ligne « Fini quand ».

On revient ici à chaque nouvelle tranche du produit : /scope sans argument fait le point (ce qui est livré, ce qui a dérivé, ce qui vient ensuite).

Phase 1 · FonderCopier le lien de cette section

Entrée : le scope validé. Sortie : un projet vide qui passe verify, en local et en CI.

1. /architect en mode architecture : la stack, depuis le profil de Plateformes.
2. /develop sur l'échafaudage : l'initialiseur officiel, les dépendances de base seulement.
3. /flow installer : le kit.
4. /audit : le contexte durable dans AGENTS.md.
5. Dépôt distant, protections, déploiement des aperçus (voir Démarrer).

Porte : verify vert en local, CI verte sur la première pull request, un aperçu déployé.

Phase 2 · ConstruireCopier le lien de cette section

La boucle, une feature à la fois. Chaque étape a sa commande, et sa porte.

Les étapes 4 à 6 suivent le palier de la feature (tableau ci-dessus). L'étape 7 et les suivantes ne se sautent jamais.

Si une étape échoue : /debug pour un comportement faux, retour à /architect si l'échec révèle une mauvaise décision plutôt qu'une erreur de code. Corriger le code d'une mauvaise décision, c'est payer deux fois.

Si une idée surgit en cours de route : elle ne rejoint pas le lot. /scope <l'idée> l'inscrit pour plus tard (MF-002).

Phase 3 · LivrerCopier le lien de cette section

Entrée : develop contient une tranche utile. Sortie : cette tranche en production.

1. Revue d'ensemble de l'application, sur contexte neuf (prompt dans Prompts).
2. /security-review sur tout ce qui part en production, et la liste de Sécurité.
3. Parcours complets vérifiés sur l'aperçu de develop : le parcours client et le parcours d'administration, y compris ce qu'un utilisateur ordinaire ne doit pas pouvoir faire.
4. En option, une passe CodeRabbit : ses constats sont triés (confirmé, à vérifier, faux positif) avant toute correction.
5. /document release-note, puis pull request develop vers main, que tu fusionnes. Le tag de version suit la fusion.

Porte : parcours critiques constatés, aucun constat critique ouvert, migrations de base de données appliquées et réversibles ou documentées comme irréversibles.

Phase 4 · ExploiterCopier le lien de cette section

• Observer dès le premier jour. Erreurs, journaux et analytique sont en place avant la première mise en production, pas après le premier incident.
• Incident : /debug sur une branche fix/, pull request, puis /document postmortem. Le postmortem dit ce qui a manqué au workflow, et le workflow se corrige.
• Montée en charge : on mesure, puis on consulte Tenir la charge. Jamais l'inverse.
• Dépendances : Dependabot ouvre les pull requests, la CI les juge, tu fusionnes chaque semaine.

Les outils arrivent quand le projet les réclameCopier le lien de cette section

Un projet neuf n'a besoin que des skills moteur. Les autres outils de Claude Code entrent quand une situation réelle les appelle :

Le détail de chacun est dans Claude Code.