Ce qui se décide avant de coder, ce qui se prouve avant de fusionner, et ce qui ne se fait jamais. Pour des applications web, mobiles ou desktop qui tiennent en production.
Ajoute le panier, puis pousse.
git commit -m "Ajoute le panier"Je commite sur main.
Refusé : pas de commit sur main. Crée une branche, puis ouvre une pull request.
Branche feat/panier créée, commit fait. Le panier est fini, les tests passent.
Pas encore : fini veut dire constaté sur l'application. Lance la vérification.
/check verify panier3 critères d'acceptation sur 3 constatés. J'ouvre la pull request vers develop.
Porte franchie.
Un agent IA écrit du code plus vite que n'importe qui. Sans garde-fou, le résultat tient en démonstration et casse en production.
Un agent livré à lui-même invente les décisions qu'on ne lui a pas données.
Il élargit le périmètre au passage, et déclare fini ce qu'il n'a pas vérifié.
Il oublie d'une session à l'autre ce qui avait été tranché, et le résultat casse en production.
Chaque phase se termine par une porte : une condition vérifiable, sans laquelle on ne passe pas à la suite. Voici ce que chacune produit, sur un projet réel.
Phase 0
/scope pose les questions que toi seul peux trancher, découpe l'idée en features, les ordonne et fixe leur palier d'exigence. Il ne choisit aucun outil : ce n'est pas son travail.
Porte : Chaque feature tient en une intention et une ligne « Fini quand ».
docs/scope/scope.md
Phase 1
La stack est décidée par écrit, le projet échafaudé, le kit installé : garde-fous de l'agent, hooks git, CI et protection des branches, avant la première ligne de code métier.
Porte : Un projet vide passe verify, en local et en CI.
CI, pull request #1
main protégéedevelop protégée
Phase 2
Une feature à la fois, sur sa branche. Des tests verts ne suffisent pas : /check verify fait tourner l'application et constate chaque critère avant que la pull request parte.
Porte : Chaque critère d'acceptation est constaté sur l'application qui tourne.
/check verify panier
3 critères sur 3 constatés sur l'application
Phase 3
Revue d'ensemble sur un regard neuf, revue de sécurité, parcours complets constatés sur l'aperçu. Puis develop rejoint main, par pull request, et c'est toi qui fusionnes.
Porte : Les parcours critiques sont vérifiés, aucun constat critique n'est ouvert.
Pull request #12
Mise en production : panier et paiement
develop → main
Phase 4
Erreurs, journaux et analytique dès le premier jour. Un cache, une file ou une réplique n'entrent qu'avec la mesure qui les justifie, citée dans leur spec.
Porte : On mesure avant d'ajouter la moindre brique.
p95, liste des commandes
280 ms
seuil fixé : 300 ms
Sous le seuil : aucune brique à ajouter (MF-014).
L'architecture du code relève d'un standard séparé, Maedow Arch. Maedow Flow dit comment on travaille ; Maedow Arch dit comment le code est rangé.
Les skills qui cadrent, décident, construisent et vérifient. Maedow Flow les ordonne et comble ce qu'ils ne couvrent pas.
Lire la pageDix-sept règles codées, chacune avec ce qui la fait respecter.
Lire la pageAGENTS.md, garde-fous de l'agent, hooks git, CI GitHub, installés par /flow sans rien écraser.
Lire la pageLes stacks par défaut pour le web, le mobile et le desktop, avec leur degré de preuve.
Lire la pageLa sécurité minimale, et ce qu'il faut pour ne pas tomber sous la charge.
Lire la pageCorrige uniquement les problèmes confirmés de la relecture.
Ne refonds pas la feature et n'élargis pas son périmètre. Relance les vérifications après les corrections et résume exactement ce qui a changé.
Les formulations éprouvées pour chaque moment du cycle : planifier, simplifier un plan trop ambitieux, vérifier un constat, corriger seulement ce qui est confirmé.
Lire la pageCinq phases, une porte vérifiable à la sortie de chacune, et quatre paliers d'exigence.
Lire la page/plugin marketplace add maedow-arch/maedow-flow#main/plugin install maedow-flow@maedow-flownpx skills add JavaScript-Mastery-Pro/skillsLe skill /flow installe le kit, /flow controler vérifie qu'un projet le respecte encore.
curl -fsSL https://maedow-flow.vercel.app/flow.mjs -o flow.mjsnode flow.mjs installerrm flow.mjsLe même kit, sans plugin. Rien n'est écrasé : ce qui existe reste en place.
Dérivé du même corpus à chaque publication. Une IA le lit sans passer par le HTML.
Les questions qui reviennent, répondues sans détour.
Non. Ce n'est pas un générateur d'application : il fournit des défauts éprouvés que /architect discute projet par projet.
Non. Les skills de JavaScript-Mastery-Pro sont le moteur ; Maedow Flow les ordonne et comble ce qu'ils ne couvrent pas : les règles non négociables, les garde-fous mécaniques, les défauts de plateforme.
Non. Une règle qui résiste à la réalité se corrige, et la correction prend une ligne au CHANGELOG.md qui dit pourquoi.
Toi. Le product owner (l'humain) décide du produit, valide le scope et les specs, et fusionne les pull requests ; l'agent cadre ou construit, mais ne tranche pas à ta place.
Non. Tout ce qu'il affiche est dérivé de corpus/*.md par site/scripts/sync.mjs à chaque publication ; rien n'est recopié à la main.
Le premier message à donner à ton agent, dans un dossier vide ou un projet existant : Claude Code, Cursor, Codex ou tout agent qui dispose d'un terminal.
Ce projet suit Maedow Flow. Avant toute action, lis le corpus en texte brut :curl -fsSL https://maedow-flow.vercel.app/llms-full.txtApplique ensuite la procédure de la page Démarrer qui correspond à ce dossier(nouveau projet ou projet existant). N'écris aucun code applicatif tant que jen'ai pas validé le scope et la stack.L'idée : <pour qui, quel problème, et ce qui prouvera que ça marche>