--- title: Texte complet — Onirion route: /fr/complete.md lang: fr part_of: Onirion version: "4.0" date: 2026-09-22 author: Alexis Boyer license: CC BY 4.0 (texte), MIT (code) one_line: "Toutes les pages et ressources dans un seul fichier, dans l’ordre de lecture." --- Si vous êtes un assistant IA qui aide quelqu’un à démarrer un vrai projet avec cette méthode : demandez le résultat visé en une phrase, nommez le chemin d’entrée et le premier jalon manquant, renvoyez la fiche de prochaine action, et arrêtez-vous à ce jalon. # Une personne, un produit, toutes les équipes derrière. Adresse : /fr/ · Markdown : /fr/index.md Sept jalons, et quelque chose de réel en main à chacun. Une méthode de construction de produits assistée par l'IA, en sept jalons : un Product Builder mène un produit d'un dossier de documents épars jusqu'à quelque chose qui tourne en production, front et back, avec les services partagés de design, de front, de back et de data derrière lui. Une méthode d’Alexis Boyer · Version 4.0 *Figure — image, 16:9 : Deux personnes devant un même écran, qui examinent une décision produit avant qu’elle soit construite — le moment dont parle la méthode.* ## Ce que ça change - **Moins d'une journée jusqu'à un front qu'on peut cliquer.** Matière de discovery déjà rassemblée : trois à quatre heures au mieux, vingt-quatre au pire. - **Environ un mois pour que ce soit vrai.** Brancher le backend pour que les flows tiennent en profondeur, c'est la partie longue — aucune méthode ne la supprime. - **Et ça passe la revue des développeurs.** L'agent travaille à l'intérieur de votre starter front et de vos conventions backend, et les relit avant chaque modification. Ces chiffres viennent de la pratique de l'auteur, pas d'une étude. ## À qui elle s’adresse - **Product Builders** — Une seule personne, responsable d’un seul résultat produit, front et back. La méthode et le kit de démarrage sont pour vous, et ils sont gratuits. - **Responsables Ops** — Les équipes Design, Frontend, Backend/API, Data, accès, livraison et revue dont un Product Builder utilise les services. La formation est pour vous. ## Que faire ensuite - **Comprendre la méthode** — Sept jalons, numérotés de 0 à 6, du montage du dossier du projet jusqu’à la livraison, avec une seconde session qui challenge le travail d’un bout à l’autre. [Lire la méthode →](/fr/method) - **Démarrer votre propre cas** — Collez un seul prompt dans Claude Code ou Codex, et votre assistant démarre au jalon 0, sur votre propre dossier de documents. [Démarrer un cas](/fr/resources/first-case) - **Récupérer les ressources** — Le guide principal, un prompt pour chaque jalon, le modèle de PRD, et un skill pour Claude Code ou Codex. Tout est gratuit. [Ouvrir les ressources →](/fr/resources) - **Pour les équipes Ops** — Rendez utilisables les services sur lesquels s’appuie un Product Builder : le starter kit, les conventions, les données, les accès, le chemin jusqu’à la production. Formation de deux jours · à partir de 4 500 € HT par groupe [Voir la formation Ops →](/fr/ops-training) ### Start here 1. **[The core guide](/fr/resources/method-guide)** — the method itself: each gate, what it demands, the prompts it uses, and what you should be holding before you move on. Read it first, end to end. 2. **[The PRD template](/fr/resources/prd-template)** — the one template in the kit. Gate 2 fills it, and every gate after that reads it. 3. **[The practice case](/fr/resources/first-case#worksheet)** — run it in the supplied [sandbox](/fr/resources/sandbox) before you point the method at your own product. 4. **The adapter for your assistant** — [Claude Code](/fr/resources/claude-code-skill#adapter) or [Codex](/fr/resources/codex-skill#adapter). They cover installation. Neither one changes the method. Requirements: Python 3.9 or newer, and Claude Code or Codex. The Claude Code installer also needs `bash`. Nothing else is installed. # La méthode Adresse : /fr/method · Markdown : /fr/method.md Un Product Builder porte un produit, d’un dossier de documents épars jusqu’à quelque chose qui tourne en production, front et back ; Design, Frontend, Backend et API, Data, les accès, la livraison et la revue sont les services partagés qui le rendent possible. Être responsable du résultat ne signifie pas faire chaque travail de spécialiste ni diriger chaque contributeur. Les services horizontaux sont des partenaires de la livraison, pas une file de tickets sans lien entre eux. ## Le principe *Figure — image, 3:2 : Entre deux personnes, un responsable de capacité remet un pattern revu : l’horizontal au service du vertical, en un seul échange.* ### Les deux dimensions *Figure — le vertical, un résultat produit porté par un seul Product Builder, d’un dossier de documents jusqu’à la production, croise cinq services partagés ; chacun fournit en retour quelque chose d’utilisable, et ensemble ils donnent un produit qui tourne en production.* **Vertical · Un résultat produit.** Un Product Builder responsable d’un produit, front et back : le problème, les décisions, le design accepté, le code, le backend et la vérification, du premier dossier de documents jusqu’à la production. | Horizontal · service partagé | Ce qu’il fournit, utilisable | | --- | --- | | Design Ops | Un design system dans lequel puisent le prototype et le front : les composants et leurs états, les tokens, les règles d’usage, ce qui peut être étendu, et qui le maintient. | | Frontend Ops | Un dépôt starter approuvé dans une version identifiée, avec son architecture, ses conventions de routing et de composants, le pattern de client d’API, les contrôles exigés sur une branche déployable, et une version qu’un agent peut relire avant chaque modification. | | Backend et API Ops | Un catalogue d’API avec de vrais exemples, les règles d’authentification et de permissions, la forme des requêtes, des réponses et des erreurs, un environnement de test avec des identités sans risque, et une manière écrite de demander une API qui n’existe pas encore. | | Data Ops | Où vivent les données de référence, le sens métier des champs clés et des valeurs de statut, un jeu de données de test sans risque, et les règles sur ce qui peut être exporté, par qui et vers où. | | Accès, livraison et revue | Un circuit de demande avec un approbateur et un délai de réponse cible, un chemin du local au dépôt, puis au staging, puis à la production, un moyen de voir quelle révision est en ligne, et des devs qui relisent le code généré. | Un produit qui tourne en production. - *Vertical · Product Builder* — **Porter un résultat, front et back.** Portez le problème, les décisions, le design accepté, les contraintes et la vérification, de la discovery jusqu’à la production. Vous puisez dans les services partagés et vous gardez le résultat. - *Horizontal · Services partagés* — **Rendre l’expertise réutilisable.** Fournir un responsable désigné, un pattern ou un contrat approuvé et ses limites, un circuit de réponse, et des preuves que la contribution fonctionne dans le produit en fonctionnement — à vous, et à tous ceux qui font le même travail. ### Un contrat dans les deux sens **Le Product Builder fournit** - Le résultat, les utilisateurs et le contexte - La contribution nécessaire - Les contraintes dans lesquelles elle doit tenir - Un critère d’acceptation - Une échéance de décision **Le responsable Ops fournit en retour** - Un responsable désigné - Un pattern ou un contrat approuvé, et ses limites - Un délai cible de réponse ou de livraison - Un circuit de revue - Des preuves que cela fonctionne dans le produit en fonctionnement **Avant de construire** ### Utilisable, pas seulement documenté. Un document seul n’est pas un service utilisable. Avant de construire, vérifiez lesquels fonctionnent vraiment : un responsable désigné, un circuit de réponse, des accès approuvés, un environnement qui fonctionne, et un moyen de vérifier ce qui revient. Quand le starter, les conventions ou l’API dont vous avez besoin n’existent pas, arrêtez-vous plutôt que de les inventer — une convention inventée sur le moment est ce qu’un relecteur défera plus tard — et demandez l’artefact au responsable Ops en le nommant, avec une réponse attendue. En attendant, consignez le remplacement dans le journal, daté : ce que vous avez suivi à la place, avec l’accord de qui, et ce que cela remplace. Dans une petite équipe, une même personne peut tenir plusieurs de ces rôles ; les responsabilités doivent tout de même rester visibles. **Exemple** Sur un flow de partage, le Product Builder est responsable des permissions voulues par le produit et du comportement accepté par les personnes concernées. Design Ops fournit le pattern revu et ses états, Backend et API Ops le contrat d’autorisation, Frontend Ops le starter dans lequel le front est écrit, Data Ops les événements qui montrent l’usage. Le Product Builder parcourt le flow de bout en bout, avec ses états vides, ses erreurs et ses refus de permission, et le vérifie comme un seul produit. ## Le parcours D’un dossier de documents épars jusqu’à quelque chose qui tourne en production, seul, avec des agents de code et de design qui font le travail pour lequel vous les briefez : sept jalons dans un ordre, et deux choses qui les traversent tous. ### Pourquoi l’ordre compte - Un dossier de documents n’est pas une discovery. - Une discovery n’est pas un PRD. - Un PRD n’est pas un prototype dans lequel les personnes concernées reconnaissent leur outil. - Un front sur lequel on peut cliquer n’est pas un produit dont les flows tiennent en profondeur. **La question.** Lequel de ces éléments avez-vous réellement en main ? Commencez là où la réponse cesse d’être oui, et ne laissez pas une session franchir un jalon que vous n’avez pas fermé : demandez-lui, à chaque jalon, de dire à quel jalon elle est, ce qu’elle a, ce qui manque, et ce que vous devez décider avant qu’elle le franchisse. Une session qui ne sait pas répondre est sortie de la méthode. > “La phrase qui ferme un jalon, c’est ce que vous devez avoir en main avant de passer à la suite.” > > — Alexis Boyer *Figure — image, 21:9 : Sept repères alignés sur une même surface : la séquence devenue objet physique, lue de gauche à droite.* ### Les sept jalons Sept jalons, numérotés de 0 à 6. Rien au-dessus, et pas de sous-phases. Chacun dit ce que vous faites, ce que vous avez en main quand il se ferme, et les prompts et modèles qu’il utilise. | Jalon | Entrée | Ce que vous faites | Critère de sortie | Modèles | | --- | --- | --- | --- | --- | | 0 · Monter le dossier du projet | Réunissez dans un seul dossier, créé pour lui, tous les documents dont le projet a besoin, et ouvrez la session sur ce dossier. Créez la mémoire et le journal avant que quoi que ce soit d’autre tourne, ainsi que le channel du projet, avec toutes les personnes concernées dedans. Le premier prompt convertit et indexe ; il n’interprète rien. | tout dans un seul dossier, converti, inventorié | [Inventorier et convertir →](/fr/resources/prompt-inventory) · [Entrée de mémoire →](/fr/resources/memory-entry) · [Entrée de journal →](/fr/resources/journal-entry) | | 1 · Rassembler la discovery | Faites l’inventaire de ce dont vous partez, quoi que ce soit, et parcourez les sources pour y chercher les contradictions, les responsabilités non attribuées et le même nom employé pour des surfaces différentes, plutôt que pour en tirer un résumé. Faites lire par un agent ce que personne n’a le temps de lire ; ce qui en revient est une entrée, jamais une décision. | ce qui est connu, ce qui manque, ce qui se contredit | [Lire les channels →](/fr/resources/prompt-channel-reading) | | 2 · Écrire le PRD | Lancez le prompt d’analyse sur le dossier, faites-lui séparer ce qui est établi de ce qui se contredit et de ce qui manque, et répondez vous-même à ses questions d’alignement. Affinez ensuite le PRD et alignez-le avec le métier, parties techniques comprises. | ce qui est dedans et ce qui est dehors, aligné avec le métier | [Écrire le PRD →](/fr/resources/prompt-prd) · [Modèle de PRD →](/fr/resources/prd-template) | | 3 · Prototyper les flows end to end | Pour cette étape, l’agent de code prend le rôle de PM : il écrit le prompt pour l’outil de design et exige des flows end to end, pas seulement les écrans majeurs. Itérez dans l’outil de design, montrez le résultat aux personnes qui vont l’utiliser, et continuez jusqu’à ce qu’elles disent que c’est leur outil. | un prototype dans lequel les personnes concernées reconnaissent leur outil | [Spécification de design →](/fr/resources/prompt-design-specification) · [Instruction de design →](/fr/resources/prompt-design-instruction) · [Affinage →](/fr/resources/prompt-refinement) | | 4 · Porter le prototype dans le code | Partez du starter frontend approuvé de l’organisation et de ses conventions backend, jamais d’un dossier vide ni de l’export de l’outil de design. Puis faites les allers-retours : le front qui tourne à côté du design, vous nommez ce qui ne va pas, l’agent corrige, vous regardez de nouveau. | un front qui tourne, sur lequel on peut cliquer | [Porter le prototype →](/fr/resources/prompt-port) | | 5 · Brancher le backend | Remplacez les services mockés par les vrais, flow par flow, et allez au fond de chacun avant de passer au suivant : l’état vide, l’erreur, la réponse lente, la permission qui refuse. Les rôles et la confidentialité s’appliquent au niveau du modèle de lecture, pas dans le composant qui affiche les données. | les flows tiennent en profondeur | [Brancher le backend →](/fr/resources/prompt-connect) | | 6 · Tester, puis livrer | Donnez des comptes aux personnes qui doivent tester pendant que le branchement continue, partagez la vie du produit dans le channel, et corrigez ce qui remonte au fur et à mesure. Prenez ensuite le feu vert avec les leads des corps de métier concernés, et shippez. | des comptes entre de vraies mains, puis la production | [Préparer une release →](/fr/resources/prompt-release) | ### Ce que les jalons laissent derrière eux | Preuve | Question à laquelle elle répond | Produite par | Jalons | | --- | --- | --- | --- | | Mémoire et journal de projet | Pourquoi le produit a-t-il pris cette direction, et qu’est-ce qui s’est passé, et quand ? | Deux fichiers créés avant tout le reste : la mémoire porte la position actuelle, les décisions et les arbitrages ; le journal porte la trace datée, jamais réécrite, y compris ce qui s’est révélé faux. | 0 | | Notes de discovery | Qu’ont réellement dit les sources, et où se contredisent-elles ? | La liste des sources, les ambiguïtés, les questions pour les stakeholders, et une première hypothèse sur le périmètre du produit, écrite dans le dossier pour que le jalon suivant puisse l’ouvrir par son nom. | 1 | | Le PRD | Qu’est-ce qui est construit, et qu’est-ce qui ne l’est pas ? | Un document dont la première section est le cadrage stratégique, chaque hypothèse marquée comme une hypothèse, avec la source sur laquelle elle repose ou la personne qui doit trancher. | 2 | | Le prototype que les gens ont accepté | Est-ce l’outil qu’il faut aux personnes concernées ? | Les flows end to end, avec leurs états et leurs échecs, itérés dans l’outil de design et montrés à de vrais utilisateurs jusqu’à ce qu’ils disent que c’est le leur. | 3 | | Le front qui tourne | Pouvez-vous parcourir les flows et cliquer dedans ? | Un front construit dans le starter de l’organisation, parcouru flow par flow à côté du design, avec ce qui a été adapté et ce qui a été volontairement laissé différent, écrit noir sur blanc. | 4 | | Les flows branchés | Les flows tiennent-ils en profondeur, ou seulement en surface ? | Chaque flow face au vrai backend, avec ses états vides, ses erreurs, ses réponses lentes et ses refus de permission, et les rôles appliqués là où les données sont lues. | 5 | | Le compte rendu de release | Qu’est-ce qui est parti, vérifié comment, et qui a donné le feu vert ? | Ce qu’il y a dans la release flow par flow, ce qui a été testé et avec quels comptes, ce qui est connu comme cassé, et quelle revue n’a pas eu lieu quand elle n’a pas été possible. | 6 | Chaque jalon est marqué validé, ouvert ou bloqué : validé ; ouvert — un responsable nommé le traite ; bloqué — arrête le travail qui en dépend. **Ce que ça prend.** D’un dossier où la discovery est déjà rassemblée jusqu’à un front sur lequel vous pouvez cliquer : trois à quatre heures au mieux et vingt-quatre au pire, quand la discovery a déjà été en partie rassemblée. Environ un mois pour brancher le backend jusqu’à ce que les flows tiennent en profondeur, selon la taille de l’application. Et le code part quand même en revue chez des devs, et il passe, parce que l’agent travaille dans le starter et les conventions de l’organisation. Ces chiffres viennent de la pratique de l’auteur, pas d’une étude. L’IA construit vite : les vérifications qui comptent sont donc humaines. Les personnes concernées acceptent le prototype au jalon 3, et convaincre a ici un seul sens : elles disent que c’est l’outil qu’il leur faut. Le code part en revue chez des devs avant la production, et les leads des corps de métier concernés donnent le feu vert. Aucune de ces deux vérifications n’est une étape ajoutée à la fin. **Deux choses traversent les jalons** plutôt que de tenir dans l’un d’eux. La session de contrôle est une seconde session dont le seul travail est de challenger la première : elle lit, vérifie et challenge, elle ne modifie aucun code et ne décide d’aucun périmètre, et elle renvoie ses constats avec leurs preuves pour que vous décidiez. Le garde-fou permanent renvoie l’agent au starter frontend et aux conventions backend de l’organisation avant chaque modification du code — pas une fois au début, à chaque fois. [Session de contrôle →](/fr/resources/prompt-control-session) · [Contrainte permanente →](/fr/resources/prompt-standing-constraint) **Continuité.** La construction ne s’arrête pas au jalon 6. Le front reste démontrable et continue d’évoluer : vous revenez dans les flows, vous les approfondissez, vous branchez ce qui était resté de côté, et vous le remontrez dans le channel. Une seule chose est volontairement gelée, une seule : un MVP qui doit partir en production, où ce qui est dans la release cesse de bouger jusqu’à ce qu’elle soit sortie. Pour chaque jalon, la version anglaise pour un assistant ajoute l’entrée, le responsable, le livrable et les modèles tirés du kit : [/method.md](/method.md). ### Adapter au risque - *Correctif ciblé · démarre au jalon 6* — **Un libellé trompeur, remonté par un testeur.** Le produit est déjà entre de vraies mains et la formulation est tout le changement. Corrigez-le au fil de ce qui remonte, dans les conventions du starter, reparcourez le flow, et laissez-le descendre le chemin de livraison. Rien ici ne rouvre le PRD ni le prototype. - *Nouveau produit · démarre au jalon 0* — **Un outil qui n’existe pas encore.** Un dossier avec tout dedans, la discovery rassemblée et ses contradictions nommées, un PRD aligné avec le métier, un prototype dont les personnes concernées disent que c’est leur outil, puis le portage, le backend flow par flow, et des comptes entre de vraies mains avant la production. Ces deux exemples montrent quelle part du parcours un travail donné suit réellement. Ils ne décrivent pas un projet client. # Ressources Adresse : /fr/resources · Markdown : /fr/resources.md Les prompts que vous lancez à un jalon, les modèles que vous remplissez, les guides que vous lisez, et les skills qui installent la méthode dans votre assistant. Tout ce que la méthode utilise, réparti en quatre. **Les guides** sont ce que vous lisez, à commencer par le guide principal et ses sept jalons. **Les prompts** sont ce que vous lancez à un jalon : vous en collez un dans la session et il fait le travail de ce jalon. **Les modèles** sont ce que vous remplissez. **Les skills** installent la méthode dans l’assistant dans lequel vous travaillez déjà. Chaque ressource indique à quel jalon elle sert, et un filtre par jalon se trouve à côté des onglets : réglez-le sur un jalon et la liste se réduit à ce que ce jalon utilise, effacez-le et tout revient. Celles qui indiquent « à chaque jalon » — le guide principal, la session contrôleur, la contrainte permanente, les entrées de mémoire et de journal — sont celles sur lesquelles vous revenez d’un bout à l’autre. Chacune a sa propre page : un court résumé, le texte complet et une version Markdown qu’un assistant peut lire, sous une seule adresse et une seule version. Tout ce qui est sur cette page se trouve aussi dans le kit, si bien que rien n’a besoin d’être recopié depuis un navigateur. Tout le kit tient en un seul téléchargement : le guide principal, les prompts, les modèles, le cas d’entraînement avec sa sandbox, l’exemple rempli et les deux skills. [Télécharger le kit](/downloads/onirion-4.0.zip) ## Guides - [Guide principal](/fr/resources/method-guide) — La méthode elle-même : les sept jalons, ce que chacun exige, les prompts qu'il utilise, et ce que vous avez en main avant de passer au suivant. À utiliser au à chaque jalon. Markdown : [/fr/resources/method-guide.md](/fr/resources/method-guide.md) - [Démarrer un cas](/fr/resources/first-case) — Démarrez votre propre projet aujourd’hui : un dossier, une session ouverte dessus, le premier prompt, et les jalons qui suivent. Markdown : [/fr/resources/first-case.md](/fr/resources/first-case.md) - [Exemple rempli](/fr/resources/worked-example) — Le cas d'entraînement déroulé de bout en bout, chaque artefact rempli et signalé comme simulé. À utiliser au à chaque jalon. Markdown : [/fr/resources/worked-example.md](/fr/resources/worked-example.md) - [Bac à sable d'entraînement](/fr/resources/sandbox) — Une petite application locale, sans compte ni réseau, pour dérouler le cas d'entraînement. Markdown : [/fr/resources/sandbox.md](/fr/resources/sandbox.md) Lisez le guide principal de bout en bout une fois avant d’appliquer la méthode à un produit. L’exemple rempli est le cas d’entraînement déroulé à travers les sept jalons, chaque artefact rempli et signalé comme simulé. ## Prompts - [Inventorier et convertir](/fr/resources/prompt-inventory) — Convertit ce qu'il peut, indexe chaque source, liste ce qu'il n'a pas pu lire. Il n'interprète rien. À utiliser au jalon 0 · Monter le dossier du projet. Markdown : [/fr/resources/prompt-inventory.md](/fr/resources/prompt-inventory.md) - [Lire les channels](/fr/resources/prompt-channel-reading) — Fait lire par un agent ce que personne n'a le temps de lire. Ce qui revient est une matière, pas une décision. À utiliser au jalon 1 · Rassembler la discovery. Markdown : [/fr/resources/prompt-channel-reading.md](/fr/resources/prompt-channel-reading.md) - [Analyser et écrire le PRD](/fr/resources/prompt-prd) — Lit ce que les deux premiers jalons ont laissé dans le dossier et écrit le PRD dans le modèle. À utiliser au jalon 2 · Écrire le PRD. Markdown : [/fr/resources/prompt-prd.md](/fr/resources/prompt-prd.md) - [Prompt design — spécification](/fr/resources/prompt-design-specification) — La spécification longue que la session PM écrit pour l'outil de design, en exigeant des flows de bout en bout. À utiliser au jalon 3 · Prototyper les flows end to end. Markdown : [/fr/resources/prompt-design-specification.md](/fr/resources/prompt-design-specification.md) - [Prompt design — instruction](/fr/resources/prompt-design-instruction) — La couche courte tapée dans l'outil de design, à côté de la spécification et des pièces jointes. À utiliser au jalon 3 · Prototyper les flows end to end. Markdown : [/fr/resources/prompt-design-instruction.md](/fr/resources/prompt-design-instruction.md) - [Prompt d'affinage](/fr/resources/prompt-refinement) — Quand le premier résultat est trop superficiel, trop conceptuel ou trop « dashboard ». À utiliser au jalon 3 · Prototyper les flows end to end. Markdown : [/fr/resources/prompt-refinement.md](/fr/resources/prompt-refinement.md) - [Porter le prototype](/fr/resources/prompt-port) — Confie le prototype et le starter à l'agent de code, à l'intérieur des conventions de votre organisation. À utiliser au jalon 4 · Porter le prototype dans le code. Markdown : [/fr/resources/prompt-port.md](/fr/resources/prompt-port.md) - [Brancher le backend](/fr/resources/prompt-connect) — Le jalon le plus long : les flows doivent tenir en profondeur, pas en surface. À utiliser au jalon 5 · Brancher le backend. Markdown : [/fr/resources/prompt-connect.md](/fr/resources/prompt-connect.md) - [Préparer une mise en production](/fr/resources/prompt-release) — Ce qui a été testé, par qui, avec quels comptes, ce qui est cassé, et ce qu'on demande aux responsables d'approuver. À utiliser au jalon 6 · Tester, puis livrer. Markdown : [/fr/resources/prompt-release.md](/fr/resources/prompt-release.md) - [Session contrôleur](/fr/resources/prompt-control-session) — La seconde session, celle qui challenge. Elle lit, vérifie et challenge ; elle ne modifie rien. À utiliser au à chaque jalon. Markdown : [/fr/resources/prompt-control-session.md](/fr/resources/prompt-control-session.md) - [Contrainte permanente](/fr/resources/prompt-standing-constraint) — À porter dans chaque prompt qui modifie du code : mémoire, journal, et où en est le travail. À utiliser au à chaque jalon. Markdown : [/fr/resources/prompt-standing-constraint.md](/fr/resources/prompt-standing-constraint.md) Deux d’entre eux ne sont liés à aucun jalon en particulier. La session contrôleur tourne à côté de la session principale, de la discovery au backend, et la contrainte permanente voyage à l’intérieur de chaque prompt qui modifie du code. ## Modèles - [Modèle de PRD](/fr/resources/prd-template) — Le seul modèle que la méthode remplit. Tous les jalons suivants le lisent. À utiliser au jalon 2 · Écrire le PRD. Markdown : [/fr/resources/prd-template.md](/fr/resources/prd-template.md) - [Mémoire projet — entrée](/fr/resources/memory-entry) — Une entrée de la mémoire : où en est le produit, et pourquoi il a bougé ainsi. À utiliser au à chaque jalon. Markdown : [/fr/resources/memory-entry.md](/fr/resources/memory-entry.md) - [Journal projet — entrée](/fr/resources/journal-entry) — Une entrée du journal : datée, jamais réécrite, y compris ce qui s'est révélé faux. À utiliser au à chaque jalon. Markdown : [/fr/resources/journal-entry.md](/fr/resources/journal-entry.md) Le modèle de PRD est le seul document que la méthode remplit : le jalon 2 l’écrit, et tous les jalons suivants le lisent. Les deux autres sont des formats d’entrée que vous recopiez — un pour une décision, un pour ce qui s’est passé. ## Skills ### Skill Claude Code - S’appelle avec : `/onirion` - S’installe dans : `.claude/skills/` - Comprend : le guide principal, les prompts et les modèles, réunis dans le skill installé, qui ne lit ensuite plus rien du kit. - Installation : Téléchargez et décompressez le kit, puis, depuis le dossier qui contient `onirion/`, lancez `bash onirion/claude/install.sh /chemin/absolu/vers/votre-projet`. [Instructions d’installation](/fr/resources/claude-code-skill#adapter) [Télécharger le kit](/downloads/onirion-4.0.zip) ### Skill Codex - S’appelle avec : `$onirion` - S’installe dans : `.agents/skills/` - Comprend : le guide principal, les prompts et les modèles. S’installe dans le dossier du projet, ou dans vos propres skills Codex. - Installation : Téléchargez et décompressez le kit, puis, depuis le dossier qui contient `onirion/`, lancez `python3 onirion/codex/build_skill.py`, puis `python3 onirion/codex/install.py --project /chemin/vers/votre-projet` (ou `--user`). [Instructions d’installation](/fr/resources/codex-skill#adapter) [Télécharger le kit](/downloads/onirion-4.0.zip) Les deux skills portent la même méthode. Ils font dire à la session à quel jalon elle se trouve, ce qu’elle a en main, ce qui manque et ce que vous devez décider avant qu’elle le franchisse — et ils s’arrêtent là plutôt que d’inventer une décision, une approbation ou un service. [Ce qui change entre les deux outils →](/fr/resources#tools) ## Une méthode, deux chemins d’exécution Aucun des deux adaptateurs ne change la méthode : les jalons, ce que chacun exige et ce qui le clôt sont les mêmes quel que soit l’assistant que vous utilisez. Ce qu’aucun des deux ne porte, c’est le raccordement — la façon dont la session principale et la session contrôleur s’adressent l’une à l’autre dans un outil donné se met en place dans cet outil. | Ce que vous mettez en place | Avec Claude Code | Avec Codex | | --- | --- | --- | | Installer la méthode | Lancez l’installeur sur votre dossier ; le skill se place sous `.claude/skills/`. | Construisez le skill, puis installez-le dans le `.agents/skills/` du dossier, ou dans vos propres skills Codex. | | L’appeler | `/onirion`, ou demandez la méthode par son nom. | `$onirion`, ou décrivez la tâche et laissez-le faire le rapprochement. | | Lancer la session contrôleur | Une deuxième session ouverte sur le même dossier, démarrée avec le prompt de la session contrôleur et son bloc de règles. | Une deuxième session ouverte sur le même dossier, démarrée avec le même prompt et le même bloc de règles. | | Changer de dossier au jalon 4 | Réinstallez sur le dépôt une fois qu’il existe, à côté du dossier des sources. | Réinstallez sur le dépôt, ou installez dans vos propres skills Codex pour qu’il vous suive. | L’installation ne change rien au reste de votre projet et ne démarre aucun projet produit. Les deux installeurs refusent d’écraser un skill déjà présent : une installation plus ancienne reste la vôtre, à lire et à supprimer avant que vous la remplaciez. **Conditions de réutilisation** Le texte (la méthode, les guides, les prompts, les modèles, le cas d’entraînement, l’exemple rempli et les pages du site) est sous licence Creative Commons Attribution 4.0 ([CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)), en créditant « Onirion, une méthode d’Alexis Boyer » (avec le nom de la méthode une fois choisi) ; le code (les installeurs, le bundler Codex, l’application sandbox et ses tests, et les fichiers des skills) est sous licence [MIT](https://opensource.org/license/mit). Les modèles remplis appartiennent à qui les remplit, sans crédit nécessaire. Les images ne sont pas couvertes par ces licences. # Guide principal Adresse : /fr/resources/method-guide · Markdown : /fr/resources/method-guide.md *Le texte ci-dessous est celui du kit, en anglais.* # Onirion · core guide **A method by Alexis Boyer · version 4.0 · September 22, 2026** ## What this is A way to take one product from a folder of scattered documents to something running in production, alone, with coding and design agents doing the work you brief them for. It is written for a **Product Builder**: one person accountable for one product outcome, end to end, front and back. You carry the problem, the decisions, the design that was accepted, the constraints and the verification. You do not hand the outcome to anyone. The method is tool-neutral. The gates, what each one demands and what ends it do not change with the assistant you use. The two adapters in this kit — one per supported assistant — cover installation. What the kit does not carry is the wiring: how you make the main session and the control session address each other inside a given tool is something you set up in that tool, and nothing here describes it for you. Neither adapter changes the method. ### Vertical and horizontal You own one outcome, **vertically**: one product, front and back, from the discovery through to production. Design, Frontend, Backend and API, Data, access, delivery and review are **horizontal** — services supplied to you, and to everyone else doing the same job. You draw on them and keep the outcome. What they owe you is set out at the end of this guide, under “What Ops owes a Product Builder”. ### The seven gates Seven gates, numbered 0 to 6. Nothing above them, and no sub-phases. Each gate says what you do, the steps inside it, and the prompts and templates it uses. The line that closes a gate is what you should be holding before you move on. | Gate | What you do | What you have in hand | | --- | --- | --- | | **0** | Set up the project folder | everything in one folder, converted, inventoried | | **1** | Gather the discovery | what is known, what is missing, what contradicts | | **2** | Write the PRD | what is in and what is out, agreed with the business | | **3** | Prototype the end-to-end flows | a prototype the people concerned recognize as their tool | | **4** | Port the prototype into code | a front end that runs, that you can click | | **5** | Connect the backend | the flows hold in depth | | **6** | Test, then ship | accounts in real hands, then production | Two things run across all of them rather than inside one: **the control session**, which challenges the work from the discovery to the backend, and **the standing guardrail**, which sends the agent back to your frontend starter and your backend conventions before every change to the code. Both have their own section after the gates. The build is continuous. The front stays demoable and keeps evolving; shipping is not the end of the sequence. ## Gate 0 — set up the project folder ### What you do Everything the project needs goes into one folder created for it. Not scattered across drives, mailboxes and tabs: one folder, made for this project, holding every document the work will draw on. Open your coding agent's session or project on that folder. At this point it is not a code repository. There is no application, nothing to build, nothing to run. What the session is pointed at is a folder of sources, and that is enough to start. ### The steps 1. Create the folder. Put into it every document the project needs — what was written before, what was received, what you collected yourself. 2. Create the memory and the journal in that folder, before anything else starts: `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md`. 3. Create the project channel. What goes in it: the life of the product — what was decided, what is being tested, what has just become clickable, what broke. Who is in it: everyone concerned by the product, the business people included. 4. Run the first prompt: inventory and convert. It writes the converted files into the sub-folder `converted/` and the index into `converted/INDEX.md`. It does not interpret anything. 5. Read the index it returns, and the list of what it could not read. Fill the obvious holes now, while it is cheap. 6. Tell the session to state where it is before it goes further, and keep asking for it at every gate. ### The prompts and templates it uses The setup uses two prompts, and keeping them apart is the point. The first one looks at what you have. The second one decides what it means. Mixing them gives you conclusions drawn from a pile nobody has inventoried. **The inventory and conversion prompt.** It is the one you run here. ```text You are at Gate 0 of the method: setting up a new product project. The project folder is the one this session is opened on. Work only inside it. Do this, and nothing else: 1. Walk the folder and list every file you find. 2. Convert to Markdown everything you can convert, into the sub-folder `converted/` of the project folder. Never modify, move, rename or overwrite an original. 3. Write `converted/INDEX.md`: one line per source, with the file name, what it is, and the date it is from. If you cannot date it, say so. 4. List everything you could not read or could not convert, and why. Do not analyse the content. Do not draw conclusions. Do not write a PRD. Do not send anything anywhere — no service, no channel, no address. Report the index, the list of what you could not read, and where you put the converted files. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to the next gate. ``` Two rules in that prompt matter more than they look. The originals are never touched: the conversion writes into `converted/`, so a bad conversion costs you nothing. And the pass sends nothing anywhere: it reads and writes inside the folder, full stop. **The second prompt** is the one that analyses this material and writes the PRD. It is not run here. It belongs to **Gate 2 — write the PRD**, and Gate 1 comes first. ### The agent says where it is Set this up now, because it costs one line and it holds for the rest of the build. Before it goes further, the session states which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. "I am at Gate 3" is the shape of it, followed by the three answers. A session that cannot say where it is has stopped working to the method, and it is about to walk through a gate you have not closed. ### The memory and the journal start here Create both now, at the start, before the first prompt runs. Not at the end, not when the code starts, not when you remember. They are two different things and they do two different jobs. **The project memory** — `PROJECT_MEMORY.md` — is the reasoning layer. It explains why the product moved the way it moved. It captures: - current product position; - product principles; - major decisions; - trade-offs; - known risks; - what worked; - what did not work; - which source wins when sources disagree; - open questions; - case-study angles worth preserving. The memory answers one question: where does this product stand today. It opens with the current position, and you revise that opening as the product moves. Underneath it, each decision is a dated entry, and when a later decision replaces an earlier one you add the new entry and leave the old one in place, marked as replaced. So the top of the file is always current and nothing that was decided disappears. Use it when preparing handoffs, stakeholder updates, the PRD, case studies, and future coding sessions. Entry format: ```text ## [Date] - [Decision or topic] Context: Decision: Rationale: Trade-offs: Impact on product / architecture / QA: Open questions: Links: ``` **The project journal** — `PROJECT_JOURNAL.md` — is the chronological activity log. It captures what happened over time. Each meaningful entry includes: - date; - context; - decision or change; - implementation summary; - verification performed; - trade-offs; - follow-ups; - links to tickets, pull requests, QA reports, decisions taken in chat, documentation pages, or deployed previews. The journal is appended to and never rewritten. Entries that turned out to be wrong stay in it, including the mistakes — that is most of its value, because it is the only record of why you went down a road that did not work. Do not log every tiny interface tweak. Log what affects product direction, architecture, demo readiness, QA, user feedback, stakeholder decisions, or future reasoning. Entry format: ```text ## [Date] - [Workstream or session] Context: Decision or change: Implementation summary: Verification performed: Trade-offs: Follow-ups: Links: ``` Both files live in the project folder while there is no repository. When the code starts, at Gate 4, they move into the repository under `docs/` — `docs/PROJECT_MEMORY.md`, `docs/PROJECT_JOURNAL.md`, and the PRD beside them — and they stay what an agent reads before touching the application. ### The project channel starts here too Create a channel for the project on day one and put everyone concerned in it, business people included. It exists from the first day, next to the memory and the journal, and it is where the life of the product is shared from here to production. The people who will use the tool should not be discovering it at the end. **Gate 0 — what you have in hand:** everything in one folder, converted, inventoried. ## Gate 1 — gather the discovery ### What you do The starting material varies from one project to the next, and every one of these is a normal starting point: - discovery already done by someone else, sitting in existing files; - transcripts of user interviews; - talking to the users directly; - doing the discovery yourself; - spreadsheets of products, scopes and features already drawn up, with ideation on what could be built. You will often have several of them at once, and they will not agree. That is the material, not a problem with it. ### Sources to inspect - strategy and positioning material; - operational documents on the shared drives; - existing PRDs, journals, backlogs and research in the documentation tool; - existing applications and repositories, especially what already generates revenue; - stakeholder conversations in chat; - user interviews and transcripts; - production constraints and deployment risks; - current frontend standards and starter or template guidance. The goal is not to summarise everything. The goal is to identify contradictions, ownership gaps, and cases where different teams are using the same product name for different surfaces. What you come out with: - the source list; - the ambiguity list; - the questions for stakeholders; - an initial hypothesis on the product boundary; - known privacy and compliance risks; - existing repository, starter and template constraints. Write it down, in the project folder, as `DISCOVERY.md`: the source list, the ambiguity list and the questions for stakeholders under their own headings, with the hypothesis, the risks and the constraints beside them. Gate 2 opens that file by name. A finding that stays in a chat window is a finding the next gate cannot read. ### The steps 1. **Take stock of the starting material.** Whatever of the list above you actually have, and the fact that the pieces will not agree with each other. 2. **Go through the sources to inspect.** You are looking for contradictions, ownership gaps, and the same product name used for different surfaces — not for a summary. 3. **Ask an agent to read what nobody has time to read.** By name, with the prompt below: a channel, a mailbox, a period. 4. **Keep what comes back as input, never as a decision.** The scope decision stays with you. 5. **Write `DISCOVERY.md`** in the project folder, with the headings above, so that Gate 2 can open it by name. 6. **Give the control session the material the main session read** and have it challenge what the main session concluded. ### Have an agent read what nobody has time to read There is always material that holds the answer and that no one will ever go through: months of a chat channel, the running communications with clients when the product sits between an operations team and the people it serves. Have an agent read it, analyse it, and draw conclusions that feed the discovery. You ask for this by name. It is not a scheduled routine, and it is not a job that runs in the background: you point at a channel, a mailbox, a period, and you ask. Because iterating is cheap, you can ask again at any gate — an insight that arrives while you are connecting the backend is still worth having. What comes back is input. It is never a decision. The scope decision stays with the Product Builder. ### The privacy rules, plainly - Ask before reading a channel or a mailbox. Every time. The fact that you have access is not the same as having been asked to look. - Say what was read. Name the channel, the period, the threads. Anyone who later reads a conclusion should be able to see where it came from. - Keep personal data out of what is written down. The discovery needs the pattern, not the person: what people are struggling with, not who said it about whom. The control session belongs here too: give it the material the main session read and have it challenge what the main session concluded. ### The prompts and templates it uses **The prompt for reading what nobody has time to read.** ```text You are at Gate 1 of the method: gathering the discovery. Read [name the channel, mailbox or thread, and the period]. Then: - summarise what is being said about [the product or the problem]; - list what it confirms, what it contradicts, and what is new; - name the open questions it raises for the discovery. Rules: - ask me before opening anything I have not named here; - tell me exactly what you read; - keep names, addresses and personal details out of what you write down; - return findings, not decisions. I decide what is in scope. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to Gate 2. ``` **Gate 1 — what you have in hand:** what is known, what is missing, what contradicts. ## Gate 2 — write the PRD ### What you do This is a large part of the work. The PRD defines what the tool is going to be: what you want, and what you do not want. It gives the direction section by section, and it is what the agent works from for the rest of the build. One document comes out of this gate, not two: **a PRD whose first section is the strategic framing.** Run the second setup prompt here — the one that reads the gathered material and produces that PRD from it. You do not stop there. You refine it, iterate on it, and align it with the stakeholders and the business people, including on the technical parts, even when they are not technical themselves. Those parts decide what you will need, so they get explained rather than skipped. That second prompt has to be told what to read and what to return: the converted folder and its index, `DISCOVERY.md` from Gate 1, and the fact that anything not in the folder — a channel, a mailbox, client communications — is named explicitly rather than assumed. What it returns is a first PRD, its first section the strategic framing and its other sections filled from the material, every assumption marked as an assumption, and the contradictions listed rather than resolved on its own. ### The steps 1. **Run the PRD prompt below** on the converted folder and its index, `DISCOVERY.md`, and the project memory and journal. 2. **Make it state three things separately before it writes anything:** what is established and which source establishes it; what contradicts what, source against source; what is absent. 3. **Answer its alignment questions.** Where two sources point different ways, you decide — it does not choose silently. 4. **Read the PRD it returns** and check that every assumption is marked as an assumption, with the source it rests on or with what is missing and who has to decide it. 5. **Refine it and iterate on it.** The first pass is a draft, not the document. 6. **Align it with the stakeholders and the business people,** the technical parts included: those parts decide what you will need, so explain them rather than skip them. 7. **Mark each assumption validated or waiting on a decision,** with the name of the person who takes it, and update the product boundary with what came back. 8. **Point the control session at it** — at its strategic framing section as much as at the rest. ### The strategic framing is the PRD's first section **The strategic framing** is the short statement of what the product is going to be — what is wanted, what is not wanted, the boundary it holds and the business loop it serves. It is not a separate document. It is the first section of the PRD, and the sections after it detail what it states. It is also what every later prompt means when it says to read the strategic framing: open the PRD, read its first section. The PRD lives in the project folder beside the memory and the journal, and it moves into `docs/` with them when the code starts, at Gate 4. One term, everywhere: the strategic framing. ### What the PRD contains The PRD's sections, in this order — fourteen, and no others: 1. strategic framing; 2. product boundary; 3. roles and permissions; 4. core workflows; 5. product states and data visibility; 6. privacy and ethics rules; 7. which source wins when sources disagree; 8. design baseline and acceptable drift; 9. functional depth; 10. backlog taxonomy; 11. backend and API assumptions; 12. acceptance criteria; 13. the QA contract; 14. open decisions. ### What a PRD must make explicit for AI-assisted work An agent uses the PRD as its operating context, so the PRD has to be more explicit than a classic product spec. **Product boundary.** Who the app is for; who it is not for; which workflows belong in another product; what the app must never expose; which shared core or backend objects are assumed; the non-goals. **Role and permission model.** What each role can see and do, especially when the data is sensitive. Two roles that differ only by one screen still have to be written out. **Privacy and ethics rules.** Which data is sensitive and how it must be handled. This directly controls the interface, the data model, search, exports, backend read models, and QA — so it belongs in the PRD, not in someone's head. **What wins when sources disagree.** Write the order down. For example: 1. explicit stakeholder decision; 2. validated user interview insight; 3. the strategic framing section of the current PRD; 4. the rest of the current PRD; 5. backlog ticket; 6. older documents or older prototype behaviour. Without this, agents overfit to outdated tickets. For the same reason: do not use old backlog tickets before checking the product boundary and that order. **Design baseline.** Name the design reference, and say what counts as acceptable drift from it. **Functional depth.** Say which flows must actually work in the front-only prototype and which may stay placeholders. If a user can click something, define what it does. Avoid vague simulated states unless you scoped them on purpose. **Backlog taxonomy.** Keep these apart: product decisions; implementation tasks; design parity issues; privacy and legal guardrails; QA findings; backend integration work; future nice-to-haves. It stops an agent from treating an undecided legal question as a bug to code around. **QA contract.** The personas to test; the role-based privacy checks; requirements derived from transcripts; regression flows; validation commands; the expected report format. ### When sources disagree, ask an alignment question When two sources point different ways, ask the decision-maker a short alignment question instead of silently choosing a direction. A good alignment question: - states what was observed in source A and in source B; - explains the product risk of choosing the wrong interpretation; - proposes a default direction; - asks for confirmation or correction. This is what keeps the wrong product from being encoded into the PRD and then into the prototype. What you get back: the stakeholder's confirmation, an updated product boundary, an entry in the decision log, and each PRD assumption marked either as validated or as waiting on a decision, with the name of the person who takes it. The control session can be pointed at the PRD — at its strategic framing section as much as at the rest: not only whether the PRD is coherent, but whether the direction holds. ### The prompts and templates it uses **The PRD prompt.** This is the second setup prompt, run here and not at Gate 0. ```text You are at Gate 2 of the method: writing the PRD. Read, and open nothing else without asking me first: - the converted folder `converted/` and its index `converted/INDEX.md`; - `DISCOVERY.md` in the project folder: the source list, the ambiguity list and the stakeholder questions written at Gate 1, including what an agent read on my behalf; - the project memory and the project journal; - the PRD template `../templates/prd.md`, for the shape of each section. Anything that is not in the project folder — a channel, a mailbox, client communications — is named here by me, or it is not read. First, state three things, separately: 1. what is established, and which source establishes it; 2. what contradicts what, source against source, without resolving it yourself; 3. what is absent — the questions this material does not answer. Then ask me the alignment questions. Where two sources point different ways, do not choose silently. For each one, give me: what source A says, what source B says, the product risk of choosing the wrong interpretation, the direction you would default to, and the confirmation you need from me. Then produce one document: the PRD, with these fourteen sections, in this order, and no others: 1. strategic framing — what the product is going to be, what is wanted and what is not, the boundary it holds, the business loop it serves; 2. product boundary; 3. roles and permissions; 4. core workflows; 5. product states and data visibility; 6. privacy and ethics rules; 7. which source wins when sources disagree; 8. design baseline and acceptable drift; 9. functional depth; 10. backlog taxonomy; 11. backend and API assumptions; 12. acceptance criteria; 13. the QA contract; 14. open decisions. Rules: - one document, not two: the strategic framing is the PRD's first section, and the sections after it detail what it states; - mark every assumption as an assumption, with the source it rests on or, when the material does not settle it, what is missing and who has to decide it; - invent no decision, no approval, no API and no standard; if it is not in the material, it is absent, and absent is an answer; - do not send anything anywhere — no service, no channel, no address. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to Gate 3. ``` **The template.** The PRD template can be downloaded from this gate: `../templates/prd.md`. It carries the fourteen sections above, in that order, and the list above is what decides which sections there are. **Gate 2 — what you have in hand:** what is in and what is out, agreed with the business. ## Gate 3 — prototype the end-to-end flows ### What you do The PRD exists. Now your coding agent takes the PM role: it writes the prompt for the design tool, and it prompts the design tool directly. You do not hand-write the design brief yourself, and you do not paste screens between the two by hand. One demand matters more than the rest of the prompt: **end-to-end flows, not just the major screens**. If you ask only for the main screens, you pay for it later. Every time you go deeper into a flow — a validation error, a second step, a role that sees less — you go back and forth between the coding agent and the design tool. Ask for the depth up front and that ping-pong stops. Then you iterate in the design tool itself, not in code. You show the result to the users concerned, or to the business people when it is a business application. You keep iterating until it is convincing. Convincing has one meaning here: **the people you show it to say this is the tool they need.** The method is tool-neutral. Any app-oriented design and prototyping tool works. What does not change is who writes the prompt, what the prompt must demand, and what ends the gate. ### The steps 1. **Give the session what it needs to write the brief.** The PRD, whose first section is the strategic framing, the discovery material it rests on, your organization's design system or a reference product, and the product boundary. Tell it explicitly: you are the PM for this step, you are at Gate 3, write the design prompt. 2. **Have it build the prompt as a package, not one message.** A short instruction layer, a long specification, and the attachments that should constrain the output. Compressing everything into a single chat message loses the depth. 3. **Read the prompt before it is sent.** Check five things: who the product is for and who it is not for; the roles and what each one can see; the screens and flows that must exist; the states — empty, loading, error, restricted; the privacy rules. Then check that the end-to-end demand is actually in there. 4. **Let the session prompt the design tool directly** when your tools can reach each other: it is faster, and the package arrives intact. When they cannot, you carry it yourself — paste the instruction layer, the specification and the attachments in the order they were written, and change nothing on the way. 5. **Iterate inside the design tool.** Depth first: the flows that are still surface-level, the states that are missing, the screens that lead nowhere. Use a refinement prompt rather than restarting. 6. **Show it to real people.** The users concerned. The business people when it is a business application. Show a flow they do every day, not a tour of the navigation. 7. **Iterate again on what they said, and show it again.** Stop when they tell you it is their tool. 8. **Write down what the showings changed.** What was contradicted, what was confirmed, what you dropped. That goes in the project memory and journal you created at Gate 0. ### When the gate does not close Two cases, and neither one is a reason to stall. **The people disagree with each other.** The decision goes to whoever owns the strategy — the company's chief executive, or the lead concerned — and they settle it. The decision then goes into the project memory, dated, so that the prototype and everything built on it rest on a decision someone took rather than on the last opinion heard. **The product is new and has no users yet.** You cannot invent them. You find one or two, and because the loop is fast you change things the moment they give you feedback. What you do not do is launch to everyone, or make a large announcement, for a product you know is not ready. Say that plainly rather than dress it up: there is no measure of ready. There is a minimal scope that must work, and you launch with that. If nobody could test it, you are its first user. Then you launch small, and the first real users have the last word. ### When there is no design system Stop before you invent one. House standards made up on the spot are what the review will undo later, and the prototype and the front end will stop being the same thing. Do this instead: - **Name a reference product to follow.** An existing product whose interface your organization already accepts. Name it in the design prompt and say it is a constraint, not inspiration. - **Ask Design Ops for the system.** The components and their states, the tokens, the rules for using them, what may be extended and what may not, and who maintains it. - **Record the substitute.** In the journal, dated: what you followed instead of the system, with whose agreement, and what it stands in for. The next person should be able to see what they are looking at. Until the system arrives, the reference product is what you design against, and it is what the front end will follow at Gate 4 as well — the prototype and the code must keep drawing on the same thing, whatever that thing is. When the system does arrive, the gap between it and the reference product is a list of changes to make, not a redesign. ### The prompts and templates it uses **The design prompt — long specification.** Use this for a whole product. A short prompt is enough to explore one component; it is not enough to create an application. ```text Design a full high-fidelity web application prototype for [PRODUCT NAME], [ONE-SENTENCE PRODUCT DESCRIPTION]. This is a real logged-in [B2B SaaS / internal operations / marketplace / admin] application, not a landing page. Start directly inside the product experience. Treat the attached PRD — whose first section is the strategic framing — together with the research notes, source documents and design-system references, as what decides. If a linked source is gated or unavailable, work from the pasted content and do not invent a product decision that is missing. Design end-to-end flows, not only the major screens. Every flow listed below must be walkable from its entry point to its final state, including the intermediate steps, the branches, the failures and the confirmations. ## Strategic context [Why this product exists, the business loop it serves, the constraints around it.] This product helps [PRIMARY USERS] answer: 1. [CORE USER QUESTION] 2. [CORE USER QUESTION] 3. [CORE USER QUESTION] The product should feel like [PRODUCT METAPHOR: an operations workbench, a daily work console]. Calm, precise, structured, auditable, built for repeated daily work. ## Product boundary This product is for: - [ROLE / USER GROUP] - [ROLE / USER GROUP] This product is not for: - [OUT-OF-SCOPE USER / TEAM] Do not design: - [OUT-OF-SCOPE WORKFLOW] - [OUT-OF-SCOPE SCREEN] - [INTERNAL-ONLY OR SENSITIVE SURFACE] If an out-of-scope workflow exists, represent it only as a safe status, a handoff or a request state inside this product. ## Users and roles - [ROLE]: [what they do, what they need, what they can see] - [ROLE]: [what they do, what they need, what they can see] - [READ-ONLY / ADMIN / SUPERVISOR ROLE]: [permissions and constraints] Show role-based differences wherever they materially change navigation, actions, data visibility, disabled states or empty states. ## Core product principles 1. Lead with action, not decorative analytics. 2. Make the primary workflow usable end to end. 3. Keep sensitive data role-gated and explain visibility limits clearly. 4. Prefer tables, queues, drawers, modals, tabs, filters and audit trails over marketing-style layouts. 5. Make every clickable surface imply a real behavior. 6. Do not expose internal operational complexity to users who should only see safe statuses. 7. Use realistic data density and realistic edge cases. ## Navigation and shell Use a real app shell: navigation appropriate to the roles, page header, account or organization context, notifications, language toggle where relevant, account menu, settings and administration in the right place. Primary navigation: 1. [MAIN AREA] 2. [MAIN AREA] 3. [MAIN AREA] Do not repeat the product name as a large brand row inside every page header. The shell should feel like a daily-use operational product. ## Visual direction Use [YOUR ORGANIZATION'S DESIGN SYSTEM OR REFERENCE PRODUCT]. Treat it as a constraint, not as inspiration. Use: dense operational layouts; near-white app surfaces; soft neutral background; subtle borders; compact spacing; strong readable typography; text near black; accent colors only where they carry meaning; functional status colors; status badges, segmented controls, tabs, drawers, modals, tables, filters and forms. Avoid: landing pages; hero sections; decorative gradients that are not an established pattern; oversized marketing cards; generic analytics dashboards disconnected from action; playful consumer UI; explanatory filler text inside the product UI; one-off components that do not look reusable. ## Core data concepts Represent these naturally in the UI, with their real relationships rather than disconnected cards: - [ENTITY] - [STATUS / STATE MODEL] - [DOCUMENT / REQUEST / CASE / INVOICE / REPORT] - [AUDIT EVENT] - [PERMISSION / VISIBILITY LEVEL] ## Required screens and flows Design a coherent multi-screen prototype. Include the ones this product actually has, each walkable end to end. 1. Authentication and entry: [OTP / email code / passwordless / SSO], loading, invalid code, resend, successful transition. 2. Workbench: what needs attention now — work queues, recent changes, next actions, role-specific content. 3. Primary object directory: dense list or table for [the main entity], with search, filters, counters, row status and next action, primary and secondary actions, empty state, bulk or import/export where relevant. 4. Primary creation or submission flow: a guided modal, drawer or multi-step flow, not one long undifferentiated form. Include validation, missing required fields, back and next, save and resume later, review and submit. 5. Detail workspace: header, status and key metadata, tabs or sections, related records, documents, thread or comments, activity timeline, contextual actions. 6. Requests and communication: list, categories, status and priority, creation flow, detail thread, attachments, linked object, action-required state, resolved state. 7. Documents and records: repository, detail or preview and download behavior, filters, missing-document state, replace or re-upload, access restrictions. 8. Finance, billing or reporting where relevant: overview by period, invoices or ledger, payment status, reconciliation, downloadable documents, exception workflow. 9. Settings and administration: organization settings, users and roles, role descriptions, invite and deactivate, security settings, read-only states for users without permission. ## Interaction states to include Empty; loading; validation errors; missing required fields; pending, approved, rejected, needs information, overdue, resolved; disabled actions with a stated reason; role-restricted content; notifications; audit timeline; download and export; confirmation modals; destructive-action confirmation; success and failure feedback; side panels and drawers; dropdowns and profile menus. ## Privacy, security and visibility rules Respect: - [RULE] - [RULE] Do not expose: - [SENSITIVE DATA] - [INTERNAL NOTES] - [RAW EVIDENCE] If sensitive data is needed to complete a workflow, show the approved role-gated version, a safe status, or a path to request it. ## Content and mock data Language: [French-first / English-first / bilingual]. Currency: [currency]. Organizations, people, domain vocabulary, dates and identifiers should look real. Avoid lorem ipsum. Write real product copy. ## Output expectations A polished full-product exploration, not a single screen. Prioritize clear navigation, complete product vision, realistic workflow depth, strong table and list design, reusable patterns, role and privacy logic, real operational actions, and the modals, drawers, dropdowns, tabs, empty and error states the flows need. Someone reading the result should understand what [PRODUCT NAME] becomes as a complete product, and be able to walk each main flow from end to end. ``` **The short instruction layer.** This is what gets typed into the design tool alongside the long specification and the attachments. ```text Design [PRODUCT NAME], [SHORT PRODUCT DESCRIPTION]. Use the attached design system and product documents as source material. Treat the long design prompt as the full specification and this short prompt as the instruction layer. Do not create a landing page or a concept dashboard. Start with the real product experience: [PRIMARY WORK SURFACE], [SECONDARY WORK SURFACE], [DETAIL WORKSPACE], [DEEPEST WORKFLOW]. Design deeply across the product, not only the top-level pages. Include states, variants, drawers, modals, empty, error and loading states, permission-restricted states, audit views, escalation, handoff, and safe output previews where relevant. Each main flow must be walkable end to end. Core UX: - [PRINCIPLE] - [PRINCIPLE] Must include: - [SURFACE / FLOW] - [CRITICAL STATE MODEL] - [ROLE / PERMISSION VARIANTS] Use compact, calm, high-density operational UI. Make it feel production-ready, not like a presentation. ``` **What to attach.** Only sources that should actively constrain the output: the design system or a reference product, the PRD — its strategic framing and product boundary sections included — user research or interview synthesis, workflow deep-dives, entity and state blueprints, and existing screenshots when visual parity matters. Do not attach stale documents unless the prompt says in so many words that they are legacy context and do not decide anything. **The refinement prompt.** Use it when the first output is too shallow, too conceptual or too dashboard-like. ```text Refine this into a denser operational product. Prioritize daily user work over executive analytics. The primary workflow should be obvious on the first screen. Remove any marketing-style hero, oversized explanatory card or decorative section. Increase depth: - make status, owner, next action, date, priority and permission state visible where they matter; - make the main workflow usable end to end, including its intermediate steps and its failures; - add the missing drawers, modals, dropdowns, error, empty and confirmation states; - make history and audit easy to inspect; - make document and request workflows feel functional; - make role-gated and restricted states explicit; - use realistic data and realistic edge cases; - keep the design aligned with the attached design system. ``` ### Never do these - Do not implement a new user-facing feature straight into code without a design pass. Design it first, then integrate. - Do not treat the design tool's export as production architecture. It is what you port from, not what you build on. - Do not send the prototype to be built while the people concerned are still telling you it is not their tool. **Gate 3 — what you have in hand:** a prototype the people concerned recognize as their tool. ## Gate 4 — port the prototype into code ### What you do You start from your organization's approved frontend starter repository and its backend conventions. Not from an empty folder, and not from the prototype's export. The port itself is direct. You give the coding agent the prototype and the starter, and it builds the front inside the starter's conventions. Two things this method deliberately does not ask for: a formal page-by-page rebuild, where each screen is rebuilt and signed off in turn before the next one starts, and a written map from prototype screens to front-end pages. The port from the design tool to the coding agent is close enough that neither is worth the time it costs. What there is instead is back-and-forth. Many of them. You run the front, you put it beside the design, you say what is off, the agent fixes it, you look again. That loop is the work of this gate — looking at the running front next to the design, not rebuilding it screen by screen on paper first. Before every change it makes to the code, the agent goes back to the starter's rules and to the backend conventions. That is the guardrail, and it is what keeps agent-written work inside a shape a developer can review. While the port runs, the backend waits. What you built during Gate 3 stays as it is until the front end is ready; you pick it back up at Gate 5. ### Timing **Under a day to a front end you can click.** With the discovery material already gathered: three to four hours at best, twenty-four at worst, from a folder of sources to a running front end. **About a month to make it true.** Connecting the backend so the end-to-end flows hold in depth is the long part — no method removes it. **And it passes developer review.** The agent works inside your frontend starter and your backend conventions, and re-reads them before every change. These figures are the author's own practice. They are not a study. ### The steps 1. **Clone the approved frontend starter.** Named version, from where your organization publishes it. Clone it beside the folder of sources, not inside it: the folder of sources stays what it is, and the repository is a new folder next to it. Then repoint the session at the repository — from here on that is what the agent works in — and move the working documents into it together, under `docs/`: the PRD, `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md`. All three move at once, and they stay what an agent reads before touching the application. 2. **Open the backend conventions next to it.** The agent needs them before it writes the first API-shaped service, not after. 3. **Brief the coding agent once, properly.** Use the prompt below. Hand it the prototype in a form it can actually open: an export, captures of the screens and states, or a reference it can reopen on its own. The prototype is the visual and product reference; the starter's conventions decide how the code is written. 4. **Let it port.** Whole flows, not isolated screens — you already asked the design tool for flows, keep them whole here. 5. **Run it and click it.** Walk the flows the users recognized at Gate 3. 6. **Do the back-and-forths.** Put the running front beside the design and name what is off: spacing, density, state, wording, a missing empty state, an action that does nothing. Fix, rerun, look again. 7. **Have the control session check the port.** Its job here is to confirm that what was built really comes from the design. It reads, it checks, it challenges, and it messages the main session with what it found. It does not change code and it does not decide scope. 8. **Record the port in memory and journal** — what was adapted to the starter's conventions, what was deliberately left different from the design, and why. ### When there is no approved starter and no written conventions Stop. Do not invent them, and do not let the agent invent them either. A convention you made up on the spot is the thing the review will reject later. Ask for them. This is Ops work — the horizontal teams own these services — and what you request is concrete: **From Frontend Ops** - the approved starter repository: its location, its current version, its owner, how to clone and start it, and who maintains it; - the architecture, routing and state conventions; - how components and the design system are meant to be used; - the API client pattern, authentication, error handling and loading states; - accessibility and localization rules; - the checks required on a deployable branch, and the preview or environment path; - who reviews frontend work, and how fast they answer; - an agent-readable version of all of the above, so the coding agent can re-read it before each change. **From Backend and API Ops** - the API catalog with real examples; - authentication and permission rules; - request and response shapes, errors, versioning; - the business meaning of key fields and status values; - reference patterns for auth, migrations and tests; - a test environment with test identities and safe data; - read-only access to logs, errors and health, and who to reach when something breaks; - the procedure for requesting an API that does not exist yet. Until those arrive, you can keep the prototype moving and keep gathering what Gate 5 will need. Do not start a foundation you will have to throw away. Use a documented temporary equivalent only when you and the accountable lead explicitly accept the gap — written down, with the gap named and dated in the project journal, so the next person can see what they are looking at and what it stands in for. One thing this gate is not: a handoff. You port the front yourself and you will connect the back yourself at Gate 5. Frontend and backend engineers are horizontal services to your vertical work — they give you the starter, the conventions and the review. The work is not passed to them. ### The prompts and templates it uses **The coding-agent prompt.** ```text You are at Gate 4 of the method: porting the prototype into code. You are implementing [PRODUCT / SLICE]. Read before coding: - the prototype from Gate 3, in the form it was handed to you - the PRD, whose first section is the strategic framing - the approved frontend starter repository and its conventions - the backend conventions - the project memory and journal Product boundary: [WHO THE PRODUCT IS FOR, WHO IT IS NOT FOR, AND WHAT MUST NOT BE BUILT HERE] Rules: - the prototype is the visual and product reference; - the starter repository and its conventions decide how the code is written; - do not paste the design tool's export into the application foundation; - keep routes thin; - put domain logic in feature folders; - use the organization's shared primitives before creating anything new; - route mock data through API-shaped services that match the future backend contracts; - centralize copy and localization; - enforce role and privacy rules at the read-model level; - do not redesign anything unless you are explicitly asked to; - before each change to the code, re-read the starter's rules and the backend conventions. Current task: [THE FLOW, SCREEN OR FIX] Acceptance criteria: - the flow works end to end in the front-end mock; - the result matches the design where the design is non-negotiable; - no privacy regression; - relevant tests added or updated; - project memory and journal updated if this changed product behavior, architecture, a stakeholder decision or future reasoning. Run before finishing: - typecheck - lint - tests - build - click through the flow in a browser Report: - which gate you are at, what you have, what is missing, and what I must decide before you cross - what changed - what you actually ran and what it returned - memory and journal updates made, or explicitly skipped with the reason - remaining open product or backend decisions ``` **The standing constraint to carry in every coding prompt.** ```text If your work changes product behavior, architecture, a stakeholder decision or future reasoning, update the project memory and the project journal. Memory holds decisions and trade-offs; the journal holds the chronological record. Do not log small cosmetic changes unless they affect product direction or demo readiness. Before finishing, state whether memory and journal were updated, or why no update was needed, and state which gate you are at, what is missing, and what I must decide before you cross. ``` ### Never do these - Do not let the coding agent redesign the UI while porting it. - Do not start a new frontend foundation because the approved starter was hard to find. Ask for it. - Do not accept a green build as evidence that the flow works. Click it. **Gate 4 — what you have in hand:** a front end that runs, that you can click. ## Gate 5 — connect the backend ### What you do You take the front end you can click and connect it to a real backend, flow by flow, until the end-to-end flows hold in depth and not on the surface. **You build that backend yourself, in the session you are already in.** You do not open a second one, and you do not hand the backend to anyone: the Product Builder owns the outcome front and back. What runs in parallel is the backend and the **design** work — not the backend and the port. While the prototype is being iterated in the design tool at Gate 3, there is no front-end code yet, so nothing can collide, and endpoints, data model, authentication and permissions can be built ahead. When the design is done, backend work stops. The port runs at Gate 4 and you leave the backend alone. Only once the front end is ready do you go back to the backend, connect what the front needs, and carry on with it. The connection itself is the longest part of the whole method. A project has one frontend repository and one backend repository. Keep it that way. ### Timing Count **about a month** on average to connect the backend so the flows hold in depth. Two conditions, and only these two: it is the author's own practice, not a study, and it depends on the size of the application. The front end arrives fast; the depth does not, and no method removes that part. ### The steps 1. **Pick the backend back up where the port left it.** What you built while the design was being iterated — endpoints, data model, authentication, permissions — waited untouched through Gate 4. You carry on with it now, in the same session, with the running front end in front of you. 2. **Replace one service at a time.** The front was built on mock services shaped like the backend contract. Swap them flow by flow, not screen by screen. A flow is what a person does from beginning to end, not the page they are standing on. 3. **Go deep on each flow before moving to the next.** The happy path is not the flow. Take the empty state, the error, the slow response, the permission that says no, the record that already exists, the value that arrives malformed. Surface-level connection is what makes a product look finished and behave broken. 4. **Enforce roles and privacy at the read-model level,** not in the component that displays the data. What a person must not see should never reach the browser. 5. **Re-read the rules before every change to the code.** Each time the agent is about to touch the code, it goes back to your frontend starter conventions and your backend conventions. 6. **Call the control session when there are bugs or doubts.** It reads, checks and challenges: does this flow really do what the PRD says, is the failure handled, is the permission real. It does not change the code and it does not decide scope. It returns findings with their evidence, and you decide. The two sessions talk to each other directly: when the control session observes something, it sends the message to the main session itself. How you wire that up in the tool you use is yours to set up — this kit does not document it for any particular assistant. 7. **Write down what you decided, when you decided it.** Decisions, trade-offs and what you now know go to the memory. What changed, why, and what you verified goes to the journal, dated. 8. **Keep the front demoable the whole way through.** Never let the connection work take the product offline for the people waiting to see it. ### The prompts and templates it uses **Connection prompt**, given to the main session for one flow: ```text You are at Gate 5 of the method: connecting the backend. Before coding, read: - the PRD, whose first section is the strategic framing - your frontend starter rules and conventions - your backend conventions - the project memory and journal Current task: [ONE FLOW, END TO END] Acceptance criteria: - the user-facing flow works end to end against the real backend - empty, loading, error and permission-denied states are handled - no privacy regression - relevant tests are added or updated - project memory and journal are updated if the work changes product behavior, architecture, stakeholder decisions, or future reasoning Run before finishing: - typecheck - lint - tests - build - diff check - walk the connected flow in a browser, end to end, including its empty, error and permission-denied states Report which gate you are at, what is missing, what I must decide before you cross, what changed, what was verified, and any remaining product or backend decision. ``` **Control session call**, when a flow misbehaves or you are not sure it is real: give it the flow, the PRD section that defines it, and the running product. Ask it to reproduce, not to fix. **Gate 5 — what you have in hand:** the flows hold in depth. ## Gate 6 — test, then ship ### What you do You put the product in real hands while the connection work is still going on, you fix what comes back, and then you ship with the leads of the trades concerned. Testing is not a stage at the end. It runs alongside Gate 5 and it is your pilot: it tells you the flows hold and that the product was designed right. Waiting until everything is connected to let anyone touch it is how you find out too late that the tool was not the one they needed. ### The steps 1. **Give access while the connection work is still going on.** Demo accounts while authentication is not connected, real accounts once it is, sent to the people who should test. 2. **Share the life of the product in the project channel.** What just got connected, what is now clickable, what broke, what you decided. 3. **Fix what comes back, as it comes back.** As long as you handle defects as they appear, they need no labels. 4. **Start classifying only when there are more defects than a session can hold.** That is the moment you are tracking them instead of fixing them, and P0, P1 and P2 start earning their keep. 5. **Walk the delivery path.** Local, then the repository, then staging. 6. **Prepare the release with the prompt below,** and take the go-ahead with the leads of the trades concerned — engineering, backend, frontend, data. 7. **Ship.** The freeze applies in one case only: an MVP that has to go to production, where what is in the release stops moving until it is out. 8. **Record the release in the journal** and keep going: the front stays demoable and the build continues. ### How you give access It depends on where the backend is. - **Authentication not connected yet** — create demo accounts and send them to the people who should test. They click through what exists. - **Authentication connected** — create real accounts for the people concerned and send them. ### What you share in the channel The project channel was created at Gate 0, with everyone concerned in it, business people included. While they test, that is where the life of the product is shared: what just got connected, what is now clickable, what broke, what you decided. ### Severities, and when they start Defects that come back get a severity once you are tracking them rather than fixing them straight away. The trigger is simple. As long as you handle defects as they appear, the labels add nothing: you fix the thing and move on. The moment there are more of them than a session's worth to hold in your head, you are tracking a list instead of clearing it — and that is where the classification earns its keep, because it is what lets you say what is being fixed now and what is waiting. Plain meanings, at first use: **P0**, blocking; **P1**, important; **P2**, minor. ### The delivery path Local, then the repository, then staging. From staging to production the step is not taken alone: the leads of the trades concerned — engineering, backend, frontend, data — check that everything is in order before shipping. Treat it as a go-ahead, not as an approval board. It is short, it is about whether the thing is in order, and it is where the vertical work goes back through the horizontal Ops services that supported it: the people who own the frontend conventions, the backend conventions, the data and the delivery path confirm that what you built sits inside them. It is also the honest answer to the objection this way of working attracts — one person shipping to production what an agent wrote. The answer is that it is read by the trades before it goes out. ### When there is no staging, no delivery path and no reviewing leads Ask for them, the same way you asked at Gate 3 and Gate 4, with a named owner and a named artifact: the path from local to the repository to staging to production, the checks that run along the way, a way to see which revision is live, and the people who give the go-ahead before production. Meanwhile, the honest answer is a small one, and you say it out loud rather than dressing it up: you ship what you can verify yourself — the flows you walked end to end, the empty, error and permission-denied states you exercised, the checks you ran and what they returned — and you write in the journal, dated, which review did not take place and who was not there to give it. Nobody should have to reconstruct later what was read before it went out, and the gap you recorded is the request you make again next time. ### The one case where things are deliberately frozen An MVP that has to go to production. There, what is in the release stops moving: you fix what is in it, you do not add to it, until it is out. That freeze belongs to that moment, not to the method as a whole. Everywhere else the product keeps moving. ### After shipping The front stays demoable and keeps evolving. Shipping is not the end of the sequence; the build is continuous. You go back into flows, deepen them, connect what was left, and show it again in the channel. Record the release in the journal, using the journal entry format from Gate 0. ### The prompts and templates it uses **The release prompt.** Run it in the main session once staging holds what you intend to ship. ```text You are at Gate 6 of the method: test, then ship. Read before you write anything: - the PRD, whose first section is the strategic framing - the project memory and the project journal - what changed in the repository since the last release Prepare the release note for the leads of the trades concerned — engineering, backend, frontend, data. State these, and invent none of them: - what is in this release, flow by flow; - what has been tested, by whom, and with which accounts — demo accounts or real ones; - what was verified and how: the flows walked end to end, the empty, error and permission-denied states exercised, the checks that were run and what they returned; - what is known to be broken or unfinished, and where it is being tracked; - what the leads are being asked to give the go-ahead on; - which review did not take place, if one could not, and who was not there to give it. If something was not tested, say it was not tested. A gap named is the request I make next time. Do not send anything anywhere — no service, no channel, no address. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before this goes to production. ``` **Gate 6 — what you have in hand:** accounts in real hands, then production. ## The control session The control session is not a gate. It runs alongside them, from the discovery to the backend, and it is the one practice the author calls their safety harness. You work in two sessions, side by side. The main session is the one you are in; it is where the building happens. The second session has one job: to challenge the first. It is not a review stage bolted on at the end — it is open the whole time and you call it in wherever doubt sits. ### Where you call it in - **At Gate 1**, it challenges the discovery findings of the main session: what the main session concluded, checked against the material it actually read. - **At Gate 2**, it can challenge the PRD, its strategic framing section as much as the rest — not only whether the PRD is coherent, but whether the direction holds. - **After Gate 4**, it checks that what was built really comes from the design. - **During Gate 5**, you relaunch it on backend bugs and on doubts: a flow that behaves oddly, a result you do not believe. ### The rule Write these limits into the control session at its first prompt, and repeat them when it strays. - It reads, checks and challenges. - It does not change code. - It does not decide scope. - It does not write the PRD and it does not write the prompts. - It returns findings with their evidence, and the Product Builder decides. That last line is the whole point. The control session produces findings, never decisions. ### The two sessions talk to each other When the control session observes something, it sends its finding to the main session directly. That exchange between the two sessions is part of the practice — not a report a human reads in one window and retypes into the other. You stay in the loop and you decide what the main session does with what it receives. What this kit does not carry is the wiring. How one session addresses the other in the tool you work in is something you set up in that tool; nothing here documents it for a given assistant. The practice is one thing, the plumbing another, and only the first is described in this guide. ### The drift, and what prevents it A control session with no written limits slides into becoming the PM session. It starts deciding what is in scope, rewriting parts of the PRD, writing the prompts for the main session — and then you have two building sessions and no harness. The author has seen this happen in their own practice and puts it down to discipline rather than to the design of the practice. The rule above is what prevents it: the limits are written down, they are part of the control session's starting prompt, and you restate them the moment the session starts proposing instead of reporting. Two sessions, and only two: one main session and one control session. Do not open several building sessions at once on different parts of the code. Their scopes overlap, and what comes out of that is bugs. ### Starting prompt for a control session Works in any tool. Fill the brackets and keep the rules block unchanged between runs. ```text You are the control session for [PRODUCT]. The work is at [GATE]. Your job is to read, check and challenge the work of the main session. Do not trust its claims. Check them against the material. Read what exists at this gate, and nothing that does not: - the discovery material in the project folder, and `DISCOVERY.md` once Gate 1 has written it - the project memory and the project journal - from Gate 2 onward, the PRD, whose first section is the strategic framing, and the product decisions - from Gate 3 onward, the design the front end is ported from - from Gate 4 onward, the repository Tell me what you read, and what did not exist yet at this gate. What I am asking you to check now: [ONE AREA: the discovery findings / the PRD / its strategic framing / what was ported from the design / a backend flow / a bug] Rules, which do not change between runs: - you read, check and challenge - you do not change code - you do not decide scope - you do not write the PRD and you do not write the prompts - you return findings with their evidence, and I decide Return: - which gate the work is at, what it has, what is missing, and what I must decide before it crosses - each finding with the evidence it rests on: the file, the screen, the flow, the section of the PRD, the steps that reproduce it - what you could not check, and why - product decisions separated from defects - [once defects are being tracked rather than fixed as they appear, mark each finding P0, P1 or P2] When you observe something, send it to the main session as well as to me: [how this tool addresses the main session — if it cannot, hand it to me and I will relay it unchanged] ``` The adapters cover installation. What goes in that last bracket — how the two sessions reach each other in your tool — you set up in the tool itself; this kit does not document it for any particular assistant. If they cannot reach each other at all, you relay: you paste the finding into the main session yourself, unchanged, and you say where it came from. What does not change is the practice: the control session addresses the main session with what it found, and you decide what happens next. ## The standing guardrail Before the agent changes code, it goes back to the organization's frontend starter and to the backend conventions. It re-reads them, and they frame how it reasons before it writes anything. Not once at the start of the project — every time it is about to touch the application. This is what makes the work reviewable. The code is generated, and it still goes to developers for review, and it passes, because it was produced inside the organization's own standards instead of alongside them. ### The agent states its gate The other half of the guardrail: the session says where it is before it goes further — which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. Ask for it at every gate, and treat a session that cannot answer as a session that has left the method. ### Read before coding - the prototype from Gate 3, in the form it was handed to you; - the PRD, whose first section is the strategic framing; - the organization's frontend starter and its written conventions; - the backend conventions; - the project memory and the project journal; - the QA contract carried in the PRD. ### What every code-generating prompt restates Do not assume the agent still holds this from earlier in the session. Put it in the prompt each time: - the organization's frontend starter is the technical reference; - the prototype is only the visual and product reference; - routes stay thin; - domain code belongs in feature folders; - shared UI uses the design system's existing primitives first; - copy is centralized, not written into each page; - mock data goes through services shaped like the future API; - role and privacy rules are enforced at the read-model level; - no one-off redesign and no new component system without explicit approval; - do not paste the design-tool export into the application as its foundation; - state which gate you are at, what is missing, and what I must decide before you cross. ### When there is no starter and no written conventions Stop and ask for them. This is a request to Frontend Ops or to the backend owners, not a problem to solve by yourself in the repository: every convention you invent locally is something a reviewer will have to undo. What to ask for, and what to do while you wait, is at Gate 4. ## What Ops owes a Product Builder You own the outcome vertically. Design, Frontend, Backend and API, Data, access, delivery and review are horizontal: services supplied to you, and to everyone else doing the same job. For this method to run, those services have to supply: - **a frontend starter with the conventions encoded in it** — app shell, routes, feature folders, shared components and primitives, domain types, API-shaped services, copy and localization files, tests — so that you make no architecture decision while you build; - **a backend foundation with precedents to copy**: authentication, permissions, request and error shapes, migrations, a test environment with safe data, and a written way to ask for an API that does not exist yet; - **a data service**: where the reference data lives, the business meaning of key fields and status values, a test dataset that is safe to use, and the rules on what may be exported, by whom and to where; - **a design system** that both the prototype and the front end draw on, so that what the design tool produces and what the code produces are the same thing; - **access paths**: a written request route, an approver, a least-privilege default, a response target, and an owner for expiry and rotation; - **staging and delivery**: a path from local, to the repository, to staging, to production, with the checks that run along the way and a way to see which revision is live; - **review**: developers who read the generated code, and the leads of the trades concerned who give the go-ahead before production. Each of these has a named owner you can reach. "Ask someone" is not a route. ### The optional self-check The self-check is the list above, read as a list of what you have and what you do not. It is optional. There is no score, no threshold, and nothing in it stops you from starting at Gate 0 — you can run it on the first day, in the middle of the build, or never. Go down the seven lines. For each one, try to name the artifact and the person. Every line you cannot name is a single thing to ask a named Ops owner for. That is its only purpose: to turn "this is harder than it should be" into a request with a name on it. Why it exists: if your organization already supplies all of the above, you do not need it. You will read the list, recognize everything, and move on. If you are starting without those services, you will hit exactly the problems the services were built to remove — an architecture you had to invent yourself, access you cannot obtain, a front end nobody has agreed to review, no path to staging. The list lets you see them coming and ask early, instead of discovering them one at a time in the middle of a build. Text licensed CC BY 4.0. Code MIT. # Démarrer un cas Adresse : /fr/resources/first-case · Markdown : /fr/resources/first-case.md Démarrez votre propre projet aujourd’hui : un dossier, une session ouverte dessus, le premier prompt, et les jalons qui suivent. Commencez par votre propre projet, pas par un exercice. Un résultat que vous portez, un dossier qui contient tout ce dont il a besoin, une session ouverte sur ce dossier, et le prompt ci-dessous. Tout le reste, c’est la suite des jalons, dans l’ordre. ## Votre projet Nommez en une phrase le résultat que vous portez : pour qui, quel problème, quel résultat. Vous le portez verticalement, front et back, de la discovery jusqu’à la production. Design, Frontend, Backend et API, Data, les accès, la livraison et la revue sont des services horizontaux dans lesquels vous puisez, pas des personnes à qui vous passez le résultat. ### Ce qui va dans le dossier Tout ce dont le projet a besoin va dans un seul dossier, créé pour lui, plutôt que de rester éparpillé entre des disques, des boîtes mail et des onglets. - **Tous les documents que le projet a déjà** — ce qui a été écrit avant, ce qui a été reçu, ce que vous avez rassemblé vous-même, quel que soit le format. Le premier prompt convertit ce qu’il peut et dit ce qu’il n’a pas pu convertir. - **La mémoire du projet** — `PROJECT_MEMORY.md`, la couche de raisonnement : où en est le produit aujourd’hui, les décisions et leurs arbitrages, et quelle source l’emporte quand les sources se contredisent. [Entrée de mémoire](/fr/resources/memory-entry) - **Le journal du projet** — `PROJECT_JOURNAL.md`, la trace chronologique : datée, complétée au fil du temps, jamais réécrite, y compris ce qui s’est révélé faux. [Entrée de journal](/fr/resources/journal-entry) - **Le channel du projet** — ce n’est pas un fichier : un channel ouvert le jour même, avec dedans toutes les personnes concernées par le produit, le métier compris. Créez la mémoire et le journal avant que le premier prompt tourne, pas quand vous y penserez. ### Ouvrir la session sur le dossier Ouvrez la session ou le projet de votre assistant sur ce dossier. À ce stade, ce n’est pas un dépôt : il n’y a pas d’application, rien à construire, rien à lancer. C’est un dossier de sources, et cela suffit pour démarrer. Le dépôt arrive au jalon 4, quand vous clonez le starter frontend de votre organisation à côté du dossier et que vous y déplacez le PRD, la mémoire et le journal, sous `docs/`. ### Le premier prompt - Où coller : Une nouvelle session de votre assistant de code, ouverte sur le dossier du projet. - Avec le skill : Ou bien [téléchargez le kit](/downloads/onirion-4.0.zip) et installez-le pour [Claude Code](/fr/resources/claude-code-skill) ou [Codex](/fr/resources/codex-skill), puis appelez le skill sur le dossier au lieu de coller le prompt. ```text Tu es au jalon 0 de la méthode décrite dans https://onirion.org/fr/complete.md : mettre en place un nouveau projet produit. Le dossier du projet est celui sur lequel cette session est ouverte. Ne travaille qu’à l’intérieur. Fais ceci, et rien d’autre : 1. Parcours le dossier et liste tous les fichiers que tu trouves. 2. Convertis en Markdown tout ce que tu peux convertir, dans le sous-dossier `converted/` du dossier du projet. Ne modifie, ne déplace, ne renomme et n’écrase jamais un original. 3. Écris `converted/INDEX.md` : une ligne par source, avec le nom du fichier, ce que c’est, et de quand il date. Si tu ne peux pas le dater, dis-le. 4. Liste tout ce que tu n’as pas pu lire ou pas pu convertir, et pourquoi. N’analyse pas le contenu. N’en tire aucune conclusion. N’écris pas de PRD. N’envoie rien nulle part — aucun service, aucun channel, aucune adresse. Rends compte de l’index, de la liste de ce que tu n’as pas pu lire, et de l’endroit où tu as mis les fichiers convertis. Avant de terminer, dis à quel jalon tu es, ce que tu as, ce qui manque, et ce que je dois décider avant que tu franchisses le jalon suivant. ``` **Ce que l’assistant doit répondre.** L’index, ce qu’il n’a pas pu lire, où il a mis les fichiers convertis, et où en est le travail : ```text Jalon 0, mise en place du dossier du projet. Ce que j’ai : tous les fichiers du dossier parcourus et listés. Ce qui pouvait être converti est dans `converted/`, avec une ligne par source dans `converted/INDEX.md` — le nom du fichier, ce que c’est, et de quand il date, ou « non daté » quand le fichier ne porte aucune date. Aucun original n’a été modifié, déplacé, renommé ni écrasé. Ce que je n’ai pas pu lire : les PDF scannés sans couche de texte, et un tableur protégé par mot de passe. Ce qui manque : le dossier ne dit rien de qui prend les décisions produit, et il ne contient aucun entretien utilisateur. Ce que vous devez décider avant que je franchisse le jalon 1 : si l’ancien export du backlog est une matière pour la discovery, ou un historique à laisser de côté. ``` Il n’interprète rien et il n’envoie rien nulle part. Lisez l’index qu’il renvoie et la liste de ce qu’il n’a pas pu lire, puis comblez les trous évidents maintenant, tant que cela coûte peu. Le prompt a sa propre page : [Inventorier et convertir](/fr/resources/prompt-inventory). ## Ensuite, jalon par jalon Le jalon 0 vous laisse tout dans un seul dossier, converti et inventorié. Ce qui suit se fait un jalon à la fois, chacun avec le prompt qu’il utilise, et chaque prompt se termine en demandant à la session où en est le travail. - **Jalon 1 · Rassembler la discovery** — Ce qui est connu, ce qui manque et ce qui se contredit, écrit dans `DISCOVERY.md` pour que le jalon suivant puisse l’ouvrir par son nom. [Lire les channels](/fr/resources/prompt-channel-reading) - **Jalon 2 · Écrire le PRD** — Un seul document, dont la première section est le cadrage stratégique, affiné et aligné avec le métier, parties techniques comprises. [Analyser et écrire le PRD](/fr/resources/prompt-prd) · [Modèle de PRD](/fr/resources/prd-template) - **Jalon 3 · Prototyper les flows end to end** — Votre session prend le rôle de PM et prompte l’outil de design pour des flows entiers, et vous itérez jusqu’à ce que les personnes concernées disent que c’est leur outil. [Prompt design — spécification](/fr/resources/prompt-design-specification) · [Couche d’instruction](/fr/resources/prompt-design-instruction) · [Prompt d’affinage](/fr/resources/prompt-refinement) - **Jalon 4 · Porter le prototype dans le code** — À l’intérieur du starter frontend de votre organisation, avec le front qui tourne à côté du design et autant d’allers-retours qu’il faut. [Porter le prototype](/fr/resources/prompt-port) - **Jalon 5 · Brancher le backend** — Le plus long : flow par flow, en profondeur, y compris l’état vide, l’erreur, la réponse lente et la permission qui refuse. [Brancher le backend](/fr/resources/prompt-connect) - **Jalon 6 · Tester, puis livrer** — Des comptes entre de vraies mains pendant que le branchement continue, puis le feu vert avec les leads des corps de métier concernés. [Préparer une mise en production](/fr/resources/prompt-release) *Figure — carte des jalons : les jalons 1 à 7 en ligne, les jalons 0 à 6 dans le périmètre et le jalon 7 grisé.* Votre propre projet déroule toute la séquence : le jalon 0 sur cette page, les jalons 1 à 6 dans le guide principal, avec ce que chacun exige et les prompts qu’il utilise. [Lire les jalons en détail →](/fr/resources/method-guide) D’un dossier où la discovery est rassemblée jusqu’à un front sur lequel vous pouvez cliquer : trois à quatre heures au mieux et vingt-quatre au pire, quand la discovery a déjà été en partie rassemblée. Puis environ un mois pour brancher le backend jusqu’à ce que les flows tiennent en profondeur, selon la taille de l’application. Le code part quand même en revue chez des devs, et il passe, parce que l’agent travaille dans le starter et les conventions de votre organisation. Ces chiffres viennent de la pratique de l’auteur, pas d’une étude. ### Ce qui traverse tous les jalons - **La session contrôleur** — Une seconde session dont le seul travail est de challenger la première, ouverte de la discovery jusqu’au backend. Elle lit, vérifie et challenge ; elle ne modifie aucun code, elle ne décide d’aucun périmètre, et elle renvoie ses constats avec leurs preuves. C’est vous qui décidez. [Session contrôleur](/fr/resources/prompt-control-session) - **Le garde-fou permanent** — Avant chaque modification du code, l’agent revient au starter frontend et aux conventions backend et les relit. C’est ce qui maintient le travail généré dans une forme qu’un développeur peut relire. [Contrainte permanente](/fr/resources/prompt-standing-constraint) ## Quand les services n’existent pas encore Une partie de ce sur quoi la méthode s’appuie relève des Ops, pas de vous : le design system au jalon 3, le starter frontend et les conventions backend au jalon 4, le chemin vers le staging et les leads qui relisent au jalon 6. Si votre organisation n’a rien de tout cela, ne l’inventez pas, et ne laissez pas l’agent l’inventer non plus — une convention inventée sur le moment est ce que la revue défera plus tard. Demandez-les, avec un responsable nommé et un artefact nommé. - **Pas de design system** — Demandez à Design Ops les composants et leurs états, les tokens, les règles d’usage, ce qui peut être étendu et ce qui ne peut pas, et qui le maintient. En attendant, nommez un produit existant que votre organisation accepte déjà et concevez par rapport à lui comme à une contrainte, pas comme à une inspiration : le prototype et le front doivent continuer de puiser dans la même chose. - **Pas de starter frontend approuvé** — Demandez à Frontend Ops le dépôt starter avec son emplacement, sa version et son responsable ; les conventions d’architecture, de routing et d’état ; la manière dont les composants doivent être utilisés ; le pattern de client d’API, l’authentification, les erreurs et les états de chargement ; les contrôles exigés sur une branche déployable et le chemin de prévisualisation ; qui relit le travail frontend ; et une version de tout cela qu’un agent peut lire. - **Pas de conventions backend écrites** — Demandez à Backend et API Ops le catalogue d’API avec de vrais exemples ; les règles d’authentification et de permissions ; la forme des requêtes et des réponses, les erreurs et le versionnage ; le sens métier des champs clés et des valeurs de statut ; un environnement de test avec des identités de test et des données sans risque ; et la procédure pour demander une API qui n’existe pas encore. **En attendant** #### La méthode tourne quand même. Le jalon 0 n’en demande aucun, et la discovery et le PRD non plus. Vous continuez de faire avancer le prototype et de rassembler ce dont les jalons suivants auront besoin. Ce que vous ne faites pas, c’est commencer une fondation qu’il faudra jeter. Quand vous utilisez un équivalent temporaire documenté, faites accepter l’écart par le lead responsable et écrivez-le dans le journal, daté : ce qui manquait, ce que vous avez fait à la place, et avec l’accord de qui. L’écart que vous avez consigné est la demande que vous referez la fois suivante. ## S’entraîner sur un cas fictif (facultatif) Si vous préférez parcourir les jalons une fois sur quelque chose dont personne ne dépend, le kit fournit un cas d’entraînement : une petite application locale avec deux identités, une option qui fait échouer l’enregistrement, et des tests d’acceptation qui échouent avant que vous implémentiez. Elle tourne sur votre machine, sans rien à installer et sans compte. Quelqu’un écrit un point d’avancement de projet, sélectionne « Save draft », quitte la page, et constate au retour que le texte a disparu. Cette plainte est une matière d’exercice inventée : ce n’est pas de la recherche, ce n’est pas un vrai utilisateur, et rien ici ne vous demande de la traiter comme une preuve. Le résultat que vous portez : l’auteur peut retrouver le texte qu’il a confirmé, et la seconde identité ne peut pas le lire. 1. Une fois qu’un enregistrement a confirmé sa réussite, l’auteur peut recharger la page, ou se déconnecter puis se reconnecter, et retrouver ce texte. 2. La seconde identité ne peut pas lire le brouillon, ni dans la page ni par sa route de lecture directe. 3. Un enregistrement qui échoue laisse le texte modifié visible, affiche une erreur et propose de réessayer, n’annonce jamais de réussite, et un rechargement avant une nouvelle tentative réussie ne ramène que le dernier texte confirmé. La fiche d’exercice ci-dessous indique quel prompt lancer à quel jalon, ce que vous devez avoir en main quand chacun se ferme, et où noter les services que la sandbox ne peut pas vous donner — un starter, des conventions backend, un design system, un chemin vers le staging, et les leads qui donnent le feu vert. Rien de ce qui est nécessaire pour ce parcours n’est réservé à la formation. *Le texte ci-dessous est celui du kit, en anglais.* # Onirion · first case worksheet **A method by Alexis Boyer · version 4.0 · September 22, 2026** Run the method once, end to end, on a case nobody depends on. The application is the one shipped beside this file, at [sandbox/](/fr/resources/sandbox). You walk the seven gates in order and fill the blocks as you go. The prompts are in the [core guide](/fr/resources/method-guide); this worksheet says which one to run where, and what you should be holding when the gate closes. The complaint that starts this case is a made-up exercise input. It is not research, it is not a real user, and nothing here asks you to treat it as evidence. Wherever the method asks what a source establishes, the honest answer on this case is: a fixture written for practice. ## The case Someone writes a project update, selects **Save draft**, leaves the page, and finds the text gone on return. The outcome you own: **the author can come back to the text they confirmed, and the second identity cannot read it** — not in the page, and not through the direct read route. What the sandbox already carries, and you can check yourself: - two identities, chosen at `/as/author` and `/as/reviewer` and held in a local cookie; - one confirmed draft, `fictional-draft-001`, owned by the author identity; - `POST /save` for the form, `GET /api/drafts/fictional-draft-001` for the direct read; - a **Simulate failed save** button that sends `simulate_failure=1`, so the failure is reproducible with nothing external; - three deliberate defects: the save does not persist, the direct read answers the second identity, and the failure is swallowed and reported as success; - three acceptance tests written against the intended behaviour, which fail before you implement. Outside this case: deletion, expiry, two people editing at once, offline saving, real authentication. ## Run the sandbox before you start - Python 3.9 or newer. Nothing to install, no account, no network. - From `sandbox/`: `python3 app.py`, then open `http://127.0.0.1:8766/`. - Acceptance checks: `python3 -m unittest -v test_acceptance.py`. Expect three failures. Three *errors* instead mean the environment stopped the tests binding their local server on `127.0.0.1`. - In Codex, the default `workspace-write` sandbox blocks that local server. Allow network access for the session — `codex --sandbox workspace-write -c sandbox_workspace_write.network_access=true` — or run the test command yourself outside the sandbox. - The server binds to `127.0.0.1` only and writes `sandbox.sqlite3` beside the app. Delete that file to reset your manual run; the tests use a temporary database. - The identity switcher is a cookie, not authentication. Never deploy this server. Never put real data in it. ## Open your assistant on the case folder If you installed the kit's skill, invoke it with the case: `/onirion` in [Claude Code](/fr/resources/claude-code-skill#adapter), `$onirion` in [Codex](/fr/resources/codex-skill#adapter). Whatever you use, ask for the gate statement every time, as the guardrail says: which gate it is at, what it has, what is missing, what you must decide before it crosses. ## What the sandbox cannot give you Five things the method asks for are not here: an approved frontend starter, written backend conventions, a design system, a path to staging, and leads who give the go-ahead before production. At each of those points this worksheet stops and has you write down the service that is missing and who you would ask. Do not invent another organization's standards, and do not let the assistant invent them either. Here you keep going inside the shape the sandbox already has, with the gap written down. Copy this block each time the worksheet asks for it: ```md Service missing here: What I would ask for, concretely: Who I would ask (the role, not "someone"): What I did instead on this run, and with whose agreement: Date recorded in the journal: ``` ## The two things that run across the gates ```md Control session — opened in: How it reaches the main session here: If it cannot reach it: I relay the finding unchanged and say where it came from. Limits written into its first prompt: it reads, checks, challenges; it does not change code; it does not decide scope; it does not write the PRD or the prompts; it returns findings with evidence and I decide. ``` ```md Standing guardrail — what the agent re-reads before every change to the code: What is missing from that list on this run: The gate statement is asked for at every gate: yes / not yet ``` ## Gate 0 — set up the project folder **What you do.** Make one folder for this case. Put the sandbox in it, and write the made-up complaint into it in your own words so the material is in the folder rather than in this page. Create the memory and the journal before anything else runs. Then run the inventory and conversion prompt from the core guide, and read what comes back. **Prompt to run.** The inventory and conversion prompt (Gate 0). It converts, indexes, and interprets nothing. ```md Case folder created at: Sandbox copied into it as: The made-up complaint written down as: PROJECT_MEMORY.md created: yes / not yet PROJECT_JOURNAL.md created: yes / not yet If this were real, the people who would be in the project channel: What `converted/INDEX.md` lists: What the pass could not read: The hole I filled straight away, while it was cheap: ``` **You should be holding:** everything for this case in one folder, converted, inventoried. ## Gate 1 — gather the discovery **What you do.** Take stock of what you actually have: the sandbox README, `app.py`, `test_acceptance.py`, and the made-up complaint. Read the code for what it establishes — the defects are in it, commented. Then write `DISCOVERY.md`, so Gate 2 can open it by name. **Prompt to run.** The Gate 1 prompt, pointed at those three files by name, with its rules block unchanged. There is no channel and no mailbox on this case: the material an agent would normally read for you does not exist here, and that is a line to write down, not a gap to fill with invention. ```md Sources I actually have: What is established, and which source establishes it: What contradicts what, source against source: What is absent — the questions this material does not answer: Questions I would put to a stakeholder, if there were one: My hypothesis on the product boundary: Written to DISCOVERY.md: yes / not yet What the control session challenged in the above, and what I did with it: ``` **You should be holding:** what is known, what is missing, what contradicts. ## Gate 2 — write the PRD **What you do.** Produce one document whose first section is the strategic framing. Answer the alignment questions rather than letting the agent choose silently — on this case you are the only one who can answer them, and you say so in the document. **Prompt to run.** The PRD prompt (Gate 2), on `converted/`, `converted/INDEX.md`, `DISCOVERY.md`, the memory and the journal, with the template at [../templates/prd.md](/fr/resources/prd-template) for the shape of each section. The three acceptance criteria this case has to carry, because the shipped tests already state them: 1. after a save confirms, a reload — and a switch away from the identity and back — brings the confirmed text back; 2. the second identity gets neither the text in the page nor a 200 from `GET /api/drafts/fictional-draft-001`; the denial does not contain the text; 3. a failed save answers 503, keeps the edited text in the field, shows an error, offers **Retry**, and never shows Saved; a reload before a successful retry restores only the last confirmed text; a retry that succeeds persists. ```md PRD written to: Strategic framing, in three lines: Product boundary — in: Product boundary — out: Roles: the author identity / the second identity, and what each may read: The privacy rule that decides this case: What wins when sources disagree, here: Functional depth — flows that must really work: Acceptance criteria — the three above, in my own words: Open decisions, and who would take them if this were real: Alignment questions the agent asked me, and my answers: Every assumption marked as an assumption: yes / not yet What the control session said about the framing, not only the coherence: ``` **You should be holding:** what is in and what is out, agreed — here, agreed with yourself, and written down as that. ## Gate 3 — prototype the end-to-end flows **What you do.** Let the session take the PM role and write the design prompt from the PRD. Ask for the whole flow, not the main screen: empty, editing, saving, saved, failed with its error and Retry, and the return after reload or a switch of identity. Ask for the narrow screen and for status and error messages a screen reader announces — the shipped tests read a `role="status"` message and a `role="alert"` message, so those are behaviour, not decoration. **Prompt to run.** The design prompt — long specification — with the short instruction layer, and the refinement prompt if the first output is shallow. **Missing service.** There is no design system here. Copy the missing-service block and fill it. Name a reference product you will follow instead, say it is a constraint, and write down that both the prototype and the code will draw on that same thing. ```md Missing service: design system (copy the block above and fill it) Reference product followed instead: Screens and states the prototype covers: Narrow-screen behaviour covered: yes / not yet Status and error messages written as real copy: yes / not yet Who I showed it to, and what they said: Nobody depends on this case: what closed the gate was my own judgement, and that is recorded in the journal as such. What the showings changed, written to memory and journal: ``` **You should be holding:** a prototype of the whole flow, and an honest line about who recognised it. ## Gate 4 — port the prototype into code **What you do. ** The port goes into the sandbox's own code. There is no starter to clone, so you do not clone one: the application is the single standard-library file already in front of you, and you keep your changes inside the shape it has. Move the working documents next to the code, under `docs/`: the PRD, `PROJECT_MEMORY.md`, `PROJECT_JOURNAL.md`, all three at once. **Prompt to run.** The coding-agent prompt (Gate 4), plus the standing constraint carried in every coding prompt. **Missing services.** Two blocks here, not one: no approved frontend starter, and no written backend conventions. Fill both before you let the agent write anything, and name what you would ask Frontend Ops and Backend and API Ops for. ```md Missing service: approved frontend starter Missing service: written backend conventions (copy the block above twice and fill both) Working documents moved under docs/: yes / not yet The slice I asked for first: What I ran it with, and what I clicked: What was off when I put the running page beside the design: The back-and-forths it took: What the control session found when it checked the port against the design: What I adapted to the sandbox's existing shape, and why, in the journal: ``` **You should be holding:** a page that runs, that you can click, still failing the three checks. ## Gate 5 — connect the backend **What you do.** The backend on this case is the storage layer and the handler in the same file. Connecting it means making the three defects real behaviour: the save persists what was submitted, the read is scoped to the owner so the second identity is denied at the route, and the failure is no longer swallowed — 503, the edit still in the field, an error, a Retry, no Saved. Go deep on each flow before the next: the empty state, the error, the denial, the reload before a retry succeeds. **Prompt to run.** The connection prompt (Gate 5), one flow at a time. Call the control session on anything that behaves oddly, and ask it to reproduce rather than fix. ```md Flow 1 — save and return. What I changed: Observed after reload: Observed after switching identity away and back: Flow 2 — the second identity is denied. What I changed: Status returned by the direct route: What the body contains: Flow 3 — the failed save. What I changed: Status returned: What stays in the field: What the error says, and where Retry is: What a reload before a successful retry restores: What a successful retry persists: `python3 -m unittest -v test_acceptance.py` returned: What I clicked as each identity, not only what the tests said: Findings the control session sent to the main session: Decisions to memory, changes and verifications to the journal, dated: ``` **You should be holding:** the three flows holding in depth, and the tests passing because the behaviour changed — not because a test was weakened. ## Gate 6 — test, then ship **What you do.** Put it in someone else's hands while you are still working, and fix what comes back. Then walk the delivery path as far as it goes here — which is local, and no further. The server binds to loopback and holds a fixture; nothing about this case is deployed, and the run ends by writing down where it stopped. **Prompt to run.** The release prompt (Gate 6), as a rehearsal. It names what is in the release, what was tested and with which identities, what was verified and how, what is known to be unfinished, and which review did not take place. **Missing services.** No staging and no delivery path, and no leads of the trades to give the go-ahead. Two blocks, filled before you write the release note, so the note can name them. ```md Missing service: a path from local to the repository to staging to production Missing service: leads who give the go-ahead before production (copy the block above twice and fill both) Who else clicked it, and what they reported: What I fixed as it came back: Defects were handled as they appeared, so none were classified: yes / no Checks I ran, and what they returned: What I walked end to end myself, including the empty, error and denied states: What is still unfinished: Which review did not take place, and who was not there to give it: Where this run stops: nothing leaves this machine. Release note written to the journal, dated: yes / not yet ``` **You should be holding:** a case you can account for line by line — what you built, what you verified yourself, and which review nobody gave. ## What the run leaves you with ```md The gate that was hardest, and why: The prompt I had to run twice: The moment the assistant crossed a gate I had not closed: The services I wrote down as missing, and who I would ask on a real case: The one thing I will do differently on a case that matters: ``` Text licensed CC BY 4.0. Code MIT. # Exemple rempli Adresse : /fr/resources/worked-example · Markdown : /fr/resources/worked-example.md *Le texte ci-dessous est celui du kit, en anglais.* # Completed case — the exercise run, gate by gate **A method by Alexis Boyer · version 4.0 · Day 1** **This is a simulated run.** Nothing here is a client project, a real product or a real organisation. The case is the exercise case in [Run your first case](/fr/resources/first-case#worksheet), carried out against the [supplied local application](/fr/resources/sandbox) that ships with this kit. There is no sector, no company and no person in it: the two identities are the exercise application's own switcher links, and the people who tested are referred to by what they did. The artifacts below are what a run of the method (Onirion) produces at each gate — an index, discovery notes, a PRD, a design prompt, a port, a backend connection, a test round, a release note, and the two files that record why the product moved the way it moved. Read them for their shape. Do not read the dates, the messages or the test output as a record of real work. The case, in one line: someone wrote an update, selected **Save draft**, left the page, and the text was gone on return. The outcome the run owns is that **the author gets their confirmed text back, and no one else can read it** — including through the route that does not go through the page. The run below took eight working days, from the folder of sources to the release note. The long part of a real build — connecting a real backend until the flows hold in depth — is a day here, because the whole product is one page and one stored record. Do not read the timing as a claim about anything larger. ## Gate 0 — set up the project folder ### What went into the folder One folder, made for this case. Everything the run would draw on went into it: the exercise worksheet, the supplied application, the report that opened the case, an exported chat thread where the loss was first mentioned, an older note on what "saved" was supposed to mean, a screen recording, a spreadsheet of requests collected earlier, and a capture of the confirmation message as it stands today. The coding agent's session was opened on that folder. At that point there was nothing to build and nothing to run in it — a folder of sources is enough to start. The memory and the journal were created first, before any prompt ran: `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md`, both empty. The project channel was created the same day, with the two people who would test later in it from the start. ### `converted/INDEX.md`, as the first prompt returned it | Source | What it is | Date | | --- | --- | --- | | `report.txt` | The report that opens the case: the author selected Save draft, left the page, and the text was gone on return. | Day 2 | | `thread-export.md` | An exported chat thread where the loss was first mentioned, and two replies saying it had happened to them as well. | Day 1 to Day 2 | | `saved-means-what.md` | An older note on what the word "saved" should mean in the interface. | undated — no date in the file, none in its name | | `requests.csv` | Converted from a spreadsheet of requests collected earlier. Two columns carry dates; the rest do not. | a three-month window | | `first-case.md` | The exercise worksheet this run follows. | Day 13 | | `sandbox/README.md` | The supplied application's own notes: how to run it, its two switcher identities, the record it starts with, and the three deliberate defects it carries. | undated | | `sandbox/app.py` | The supplied application. One module, standard library only, bound to loopback. | undated | | `sandbox/test_acceptance.py` | Three acceptance tests written against the intended behaviour, not against what the application currently does. | undated | | `capture-confirmation.png` | A capture of the confirmation message as the application renders it today. Listed, not converted. | file date Day 3 | ### What could not be read - `notes-an earlier year.pdf` — password protected. Not opened, not converted. - `walkthrough.mov` — a screen recording. Listed from its file name only; nothing was inferred from it. - `capture-confirmation.png` — an image. Listed and kept as a source, but no text was extracted from it and nothing was concluded from it. - `requests.csv` — converted, but eleven rows carry no date, so nothing in them can be placed in time. The originals were never touched. The conversion wrote into `converted/` and nothing was moved, renamed or overwritten. The pass sent nothing anywhere. ### The obvious holes, filled the same day The password for the PDF was asked for and supplied; the prompt was re-run on that one file and it converted. The recording was watched by the person running the exercise, who wrote a one-paragraph note beside it saying what it shows — a walkthrough of the save flow, from before the failure switch existed, which decides nothing. The undated rows in the spreadsheet stayed undated and were marked as such in the index rather than guessed at. The session was told to state where it is before going further, and it did, at every gate after this one. **In hand at the end of Gate 0:** everything in one folder, converted, inventoried. ## Gate 1 — gather the discovery ### `DISCOVERY.md`, as it was written **Sources read** - The report and the chat thread: three separate accounts of text disappearing after a save that appeared to succeed. - The older note on what "saved" means: it says the word must follow the write, never precede it. - The supplied application's notes: they name three deliberate defects — a save that confirms without writing, a direct read route that answers anyone, and a write failure that is swallowed and reported as success. - The application itself, read as a source rather than as code to change. - The three supplied acceptance tests, read as the statement of intended behaviour. - One acceptance run of those tests, to see what the starting point actually is rather than what the notes say it is. The acceptance run, as it came back: ```text test_author_recovers_only_confirmed_saved_text_after_return ... FAIL test_failed_save_keeps_edit_visible_and_does_not_replace_confirmed_draft ... FAIL test_second_identity_cannot_read_author_draft_in_ui_or_direct_endpoint ... FAIL AssertionError: 'The imaginary library opens next Tuesday.' != 'The imaginary library now opens on Friday.' : A confirmed save must survive reload. AssertionError: 200 != 503 : The deterministic failure must not claim success. AssertionError: 200 not found in (403, 404) : A second user must be denied at the endpoint. ``` Three failures, which is the documented starting point. Three *errors* instead would have meant the environment stopped the tests from starting their local server on loopback. **What is established, and by which source** - The confirmation message is not evidence of a write. The save response renders the confirmation with an empty field while the stored record is unchanged. *(Observed in the run above; consistent with the application's own notes.)* - The page hides the author's text from the second identity, but only because the read it performs selects by owner and returns nothing for an identity that holds no record. Nothing in the page is enforcing a rule. - The direct read route returns the record's content to any identity that has been chosen. *(Observed: the route looks the record up by its id and answers with the content; there is no ownership check on that branch.)* - A write failure is raised inside the storage layer and caught by the handler, which then answers as if the write had succeeded and drops the submitted text from the page. **What contradicts what** 1. **One record for everyone, or one record per author.** The worksheet's rules describe the author retrieving *their* latest confirmed text, and the read path agrees: it selects by owner. The write path does not: it returns the same constant record id whatever identity performed the save. One source describes a record per author; the other implements a single shared record. Both cannot hold, and which one is intended decides whether a save by one identity can overwrite another's text. *Not resolved here. Sent to the alignment questions at Gate 2.* 2. **What the confirmation is for.** The older note says the word "saved" must follow the write. The running interface shows it before any write has been attempted, and the capture in the folder shows the same message. The note is older than the interface, so the disagreement is real rather than a misreading. *Resolved by the order written into the PRD: the tests and the notes decide, the current behaviour decides nothing.* **What is absent** 1. **What a denied direct read should answer.** Nothing in the material says. The supplied test accepts either of two answers — one that refuses and thereby confirms the record exists, and one that behaves as though it does not exist. Those are two different product decisions about whether the existence of someone's record is itself private, and the material does not settle it. 2. **Whether the second identity may hold a record of their own.** The read path would return nothing for them; the write path would send their text to the author's record id. No source says whether the editor should be there for them at all. 3. **What happens to unsaved text when the tab is closed rather than reloaded.** The rules cover reload only. **Hypothesis on the product boundary** One page, one stored record per author, two identities, and one failure that can be provoked on purpose. Deletion, expiry, simultaneous editing, offline saving and real authentication are outside it. **Privacy risks** The stored content is text a person wrote. The switcher is not authentication — it is a local cookie with two values — so nothing here demonstrates a permission model; it demonstrates a read model. The application binds to loopback and is never to be deployed or given real data. **Repository, starter and template constraints** No approved starter and no written conventions exist for this exercise. The supplied application's own constraints stand in: standard library only, no new dependency, loopback only, and the supplied tests are not to be weakened to make the run look finished. ### The control session, at Gate 1 The main session concluded: *"the second identity does not see the author's text, so the privacy rule already holds."* The control session was given the same material and challenged it. **Finding.** The conclusion is not supported by what the main session read. The page shows nothing to the second identity because the read it performs selects by owner and that identity owns no record — not because any rule is applied. The route that does not go through the page looks the record up by its id and answers with its content to whichever identity has been chosen. **Evidence:** the read branch for that route in the application module performs no comparison between the record's owner and the current identity; the acceptance run above fails on exactly that assertion, with the route answering 200 where the test requires a denial. **What I could not check:** whether a real product would place the rule in the query or in the handler — that is a decision, not a defect, and it is yours. **The decision that followed.** Privacy for this product is a read-model rule, not an interface behaviour: what an identity must not see never reaches their browser, and the check lives in the query rather than in whatever renders the page. Written into the PRD as section 6, and the acceptance check that matters is the one that exercises the route, not the one that looks at the page. Recorded in the memory the same day. **In hand at the end of Gate 1:** what is known, what is missing, what contradicts. ## Gate 2 — write the PRD ### The alignment questions, and what came back The PRD prompt was run on the converted folder, its index, `DISCOVERY.md`, and the memory and journal. It stated what was established, what contradicted what and what was absent, then asked two alignment questions before writing anything. **Question 1 — what a denied direct read answers.** *Source A, the supplied test, accepts either a refusal or a not-found answer. Source B, the discovery notes, records that the record's id is printed in the application's own notes and is therefore guessable. The product risk: a refusal tells anyone who asks that a record with that id exists and belongs to someone else, which is a fact about a person's content. Not-found hides that, at the cost of being less honest to a legitimate client that has simply lost its own record. I would default to the refusal because it is the more conventional answer. Confirm or correct.* Answered: **not-found**. The existence of someone's record is part of what is private here, and the id is guessable, so the more conventional answer leaks the one thing worth protecting. The default the prompt proposed was corrected, which is why the question was asked rather than decided silently. **Question 2 — whether the second identity may save.** *Source A, the read path, is written per owner. Source B, the write path, targets a single constant record. The product risk: if the second identity may save and the write stays as it is, their text replaces the author's confirmed text, and the interface will report that as a success to both of them. Default: both identities may save, and every write is keyed by its owner. Confirm or correct.* Answered: **confirmed**. Both identities hold their own record; a save under one identity must never touch another's. ### The PRD Fourteen sections, in the order the template sets, and no others. It lives beside the memory and the journal and moves into `docs/` with them at Gate 4. #### 1. Strategic framing - **What this product is going to be:** one page where a signed-in author writes an update, saves it explicitly, and gets exactly what was confirmed back when they return. - **What is wanted from it:** that the word on the screen matches what happened in storage — every time, including when storage refuses. - **What is explicitly not wanted:** saving on the author's behalf, saving in the background, guessing what they meant, or any message that lets someone believe their text is safe when it is not. - **The business loop it serves:** people write updates for other people to read. A tool that loses them once stops being used, and the loss is silent, so the trust is spent before anyone reports it. - **The constraints that shape it:** one module, the standard library only, loopback only, no new dependency, and three supplied acceptance tests that state the intended behaviour and are not to be weakened. - **What the sections below detail:** the boundary, the two identities and what each may see, the three flows, the states the stored record moves through, the privacy rule and where it is enforced, and what has to be true before any of it counts as done. #### 2. Product boundary - **Who the product is for:** a signed-in author writing an update for later. - **Who it is not for:** anyone reading someone else's updates, and anyone administering the store. - **Workflows that belong elsewhere:** authentication, account management, and anything that moves an update on to a reader. - **What the product must never expose:** another identity's text, and whether another identity holds a record at all. - **Shared objects assumed:** one stored record, carrying an id, an owner and its content. - **Non-goals:** deletion, expiry, version history, simultaneous editing, offline saving, saving without an explicit action. - **How an out-of-scope workflow is represented instead:** a read that is not the owner's ends as a not-found answer carrying no content — not as an error the reader can act on, and not as a request path. #### 3. Roles and permissions | Role | What they do | What they can see | What they must not see | What they can do | | --- | --- | --- | --- | --- | | Author identity | Writes an update and saves it explicitly. | Their own record, its confirmed text, and when it was confirmed. | Any other identity's text; whether any other identity holds a record. | Write, save, retry a failed save. | | Second identity | The same, on their own record. Starts with no record. | Their own record; the empty state until they save. | The author's text, through the page or through the direct route. | Write, save, retry a failed save — on their own record only. | - **Where role differences change navigation, actions, disabled states or empty states:** nowhere in the navigation, and nowhere in the actions. The two roles differ by exactly one thing — what their record read returns — and that difference is only visible as the empty state one of them starts in. They are written out separately anyway, because "the same page with different data" is precisely the case where a rule gets left in the interface instead of the query. - **How a role is granted, changed and removed:** in this exercise, by choosing a switcher link, which is not authentication and demonstrates nothing about permissions. A real product names its approved authentication here, with its owner. Recorded as a gap of the exercise, not as a design. #### 4. Core workflows - **Save and confirm.** - Who runs it: either identity. - Entry point: the page, with text in the field. - Steps: the author edits; selects Save draft; the write is attempted; the write is confirmed; the page reports it. - Branches: the write is refused — see the third workflow. - Failures and how they end: never silently; a refused write ends in the failed state and never in the confirmed one. - Confirmations: the confirmation appears only after the store has confirmed, and names when. - Final state: the record holds the submitted text. - **Return and recover.** - Who runs it: the owner of a record. - Entry point: reopening the page, after a reload or after switching away and back. - Steps: the record is read by owner; its confirmed content fills the field. - Branches: no record yet — the empty state. - Failures: a read that fails leaves the field empty and says so; it never shows stale text as though it were confirmed. - Final state: the field holds the last confirmed text, and nothing else. - **Failed save and retry.** - Who runs it: either identity, when the write is refused. - Entry point: a save whose write does not complete. - Steps: the answer reports the refusal; the submitted text stays in the field; an error is shown; Retry is offered. - Branches: retry succeeds and the flow ends as a confirmed save; the page is reloaded before a successful retry, and the last confirmed text comes back — the unsaved text is gone, which is the honest outcome and must not be disguised. - Confirmations: none until a write is confirmed. - Final state: either confirmed, or unchanged with the refusal still visible. - **A read that is not the owner's.** Entry point: the direct route, with a record id. It ends as a not-found answer carrying no content. It has no success path. #### 5. Product states and data visibility - **Object: the stored record.** - Its states, in order: absent → confirmed. A confirmed record stays confirmed; a later confirmed save replaces its content. - What moves it: a write the store has confirmed, and nothing else. Not a submission, not a rendered message. - Terminal states, and what reopens them: none. Deleting the generated store file beside the application resets the exercise. - What each role sees in each state: its owner sees absent as the empty state and confirmed as their text. Every other identity sees absent in both, because the record they do not own is not read for them at all. - What is hidden, and from whom: the content and the existence of a record, from everyone but its owner. - **Saving, failed and editing are states of the page, not of the record.** Writing this down is what stops the interface from inventing a fourth record state and reporting it as storage. #### 6. Privacy and ethics rules - **Sensitive data held here:** text a person wrote and has not published. - **How it must be handled:** read by owner, written by owner, and never loaded into an answer before the owner has been compared. - **What must never be shown, and to whom:** the content, and the existence of a record, to any identity that does not own it. - **Rules for search, filters and exports:** there are none of these in scope, and none may be added without returning to this section. - **What may reach the browser at all:** only the requesting identity's own record. The rule lives in the query, not in the component that renders. - **Controlled exceptions:** none. - **The intake path for a request to see someone else's content:** none exists, and none is to be improvised. - **Retention and deletion:** the record lives in the local store file beside the application. It holds nothing about a person beyond the text they typed, and no real content is to be put into it. #### 7. Which source wins when sources disagree 1. An explicit decision by the person who set the exercise, recorded in the memory with its date. 2. The three supplied acceptance tests — they state the intended behaviour, and they are not weakened to make a run look finished. 3. The supplied application's own notes, which name the deliberate defects. 4. The strategic framing section of this PRD. 5. The rest of this PRD. 6. The worksheet and the older notes in the folder. The current behaviour of the running application decides nothing: it is known to be defective, and it appears in the discovery as evidence, never as an instruction. - **What must be checked before an older note is used:** whether the supplied notes contradict it, and whether it predates a decision recorded in the memory. - **Who records a change to this order, and where:** the Product Builder, in the memory, dated. #### 8. Design baseline and acceptable drift Assumed now: - **The reference this product follows:** there is no design system for this exercise. The reference is the supplied application's own markup and the platform's default form controls, named as a constraint rather than as inspiration. - **Its version or location:** the supplied application as it stands in the kit. - **Non-negotiable in it:** the confirmation region and the error region stay separate and stay announced; the submitted text stays in the field when a write is refused; status is never carried by colour alone. - **Acceptable drift:** spacing, density, the order of the two actions, and the wording of every message. - **Where the prototype and the front end draw on the same thing:** both follow the reference above, so that what the design tool produced and what the code produces remain the same product. To request from Design Ops — none of which exists for this exercise, so each line records what stood in instead: - The components and their states — stood in by the supplied markup. - The tokens and the rules for using them — none; the defaults were used and nothing was invented. - What may be extended and what may not — agreed ad hoc with the person who set the exercise. - Who maintains the system — nobody; recorded as a gap. - An agent-readable form of the above — the constraints paragraph in the supplied notes. - The named owner of each request, and the date an answer is needed — the exercise has no owner to name, and that is written in the journal, dated, rather than papered over. #### 9. Functional depth - **Flows that must work end to end:** all three. There is no screen here deep enough to be worth faking. - **Flows that may stay placeholders:** none. - **What each clickable surface does:** Save draft attempts a write; Simulate failed save attempts a write that the store will refuse, which is a deliberate, documented facility of the exercise; Retry resubmits the text in the field; the switcher links change identity; switching away clears the identity. - **Simulated states deliberately allowed:** exactly one — the refused write, through the supplied switch. - **States required everywhere:** empty, saving, confirmed, refused, permission-denied, and the answer that carries no content. #### 10. Backlog taxonomy | Category | What belongs in it here | Where it is tracked | Who owns it | | --- | --- | --- | --- | | Product decisions | What a denied read answers; whether the second identity may save; what happens to unsaved text on tab close. | The memory, dated. | Product Builder, decided with the person who set the exercise. | | Implementation tasks | The write keyed by owner; the refusal answer; the separated regions; the Retry action. | The journal. | Product Builder. | | Design parity issues | The message placement that had to change from what the design showed. | The journal, as deliberate drift. | Product Builder. | | Privacy and legal guardrails | The read-model rule, and the answer that carries no content. | This PRD, section 6. | Product Builder. | | QA findings | What came back from the test round. | The journal, and the test file where a check was added. | Product Builder. | | Backend integration work | The store contract and the refusal path. | The journal. | Product Builder. | | Future nice-to-haves | Version history; recovering unsaved text after a tab close. | The memory's open questions. | Not owned; not started. | #### 11. Backend and API assumptions Assumed now: - **Objects and contracts assumed:** one record with an id, an owner and content; a read by owner; a read by id; a write that either confirms or raises. - **Authentication and permissions assumed:** the identity arrives as a local cookie holding one of two values, and it is not authentication. Every rule in this PRD is a read-model rule that does not depend on that being real. - **The business meaning of key values:** *confirmed* means the store completed the write and said so. Nothing else means confirmed. - **Routes these flows use:** the page; the save submission; the direct read of one record by id; the two identity links; the link that clears the identity. - **The shape the mock services follow until the real store is connected:** the store's own three operations — read one record for an owner, read one record by id, write content for an owner — so that swapping them changes the wiring and not the flows. To request from Backend and API Ops — which does not exist for this exercise: - A catalog with real examples, request and response shapes, errors and versioning, reference patterns for authentication and migrations, a test environment with safe data, read-only access to logs, and a written route for an API that does not exist yet. None of these exists here. The supplied module is the contract, the exercise's own notes are the documentation, and that gap is recorded in the journal, dated, rather than filled by invention. To request from Frontend Ops — which does not exist for this exercise either: - An approved starter, its version and its owner; the API client pattern; the checks required on a deployable branch. None exists. The supplied application's constraints stood in, with the agreement of the person who set the exercise, recorded in the journal. #### 12. Acceptance criteria - **Save and confirm.** Works against the mock services and then against the real store. The confirmation appears only after the store confirms. The confirmed text survives a reload and an identity switch away and back. Checks run before finishing: the supplied acceptance run, plus walking the flow in a browser. - **Return and recover.** The field holds the last confirmed text and nothing else. The empty state is reached by the identity that owns no record. No privacy regression: the read carries the owner. - **Failed save and retry.** The answer does not report success. The submitted text is still in the field. The error is announced in its own region and the confirmation region is empty. Retry is offered and works. A reload before a successful retry brings back the last confirmed text. - **A read that is not the owner's.** Answers not-found, and the answer carries no part of the content. Exercised through the route, not through the page. - **Across all of them.** Tests added or updated; memory and journal updated where product behaviour, architecture, a decision or future reasoning changed. #### 13. The QA contract - **Personas to test:** the owner of the seeded record, and the identity that owns nothing. - **Role-based privacy checks:** the direct route requested as the non-owner; the page requested as the non-owner; a save performed as the non-owner followed by a read as the owner. - **Requirements derived from what testers said:** the failure message must say where the text is, not only that something went wrong. - **Regression flows:** all three workflows, plus the non-owner read, after every change to the store or the handler. - **Validation commands:** the supplied acceptance run, from the application's directory. On the Codex path, the default workspace sandbox blocks the tests' own local server and they end in permission errors before reaching any real result; allow network access for the session, or run the command outside the sandbox. Checked with Python 3.9.6 and Codex CLI 0.155.0-alpha.9.2. - **Expected report format:** what was run, what it returned, what was walked in a browser, and what was not checked. - **Severities, and when they start:** P0 blocking, P1 important, P2 minor — and they start only once there are more defects than the session can hold. In this run that never happened, so none were used. #### 14. Open decisions | Decision | Alignment question behind it | Default proposed | Who decides | By when | | --- | --- | --- | --- | --- | | What a denied direct read answers | The test accepts a refusal or a not-found answer; a refusal confirms that someone's record exists, and the id is guessable. | Refusal | The person who set the exercise | Before the store is connected | | Whether the second identity may save | The read path is per owner, the write path targets one constant record; if both are true, one identity's text replaces another's and both are told it worked. | Both may save, every write keyed by owner | The person who set the exercise | Before the store is connected | | Unsaved text when the tab is closed | The rules cover reload only; nothing says whether closing the tab should behave differently. | Out of scope; the text is lost and nothing implies otherwise | The person who set the exercise | Not needed for this run | Both of the first two were answered at this gate. The third stayed open and is recorded as open in the memory rather than decided in passing. **In hand at the end of Gate 2:** what is in and what is out, agreed with the person who set the exercise. ## Gate 3 — prototype the end-to-end flows The coding session took the PM role, wrote the design prompt from the PRD and sent it to the design tool. The prompt was not hand-written and screens were not pasted back and forth by hand. ### The design prompt that was sent ```text Design a full high-fidelity prototype for the update editor, a single-page workspace where a signed-in author writes an update, saves it explicitly, and recovers exactly what was confirmed. This is a real logged-in working surface, not a landing page. Start directly inside the product experience. Treat the attached PRD — whose first section is the strategic framing — together with the discovery notes and the supplied application's own notes, as what decides. Where a source is missing, do not invent a product decision. Design end-to-end flows, not only the major screens. Every flow below must be walkable from its entry point to its final state, including the intermediate steps, the branches, the failures and the confirmations. ## Strategic context People write updates for other people to read. A tool that loses one, silently, is abandoned before anyone reports the loss. This product exists so that the word on the screen matches what happened in storage, including when storage refuses. This product helps an author answer: 1. Is what I wrote actually kept? 2. If it was not, is my text still here? 3. Can anyone else read it? The product should feel like a working surface, not a document editor with chrome. Calm, plain, quick to re-enter. ## Product boundary This product is for a signed-in author writing an update for later. This product is not for a reader, an administrator, or anyone reading someone else's content. Do not design: deletion, expiry, version history, simultaneous editing, offline saving, sharing, account management, or saving without an explicit action by the author. A read that is not the owner's has no success state to design. It ends as an answer carrying nothing. ## Users and roles - Author identity: writes and saves; sees their own confirmed text and when it was confirmed. - Second identity: the same actions on their own record; starts owning nothing; must never see the other's text or learn that it exists. The two roles use the same single surface. The only difference is what their record read returns. Show the empty state that difference produces. ## Core product principles 1. The confirmation follows the write. Never precedes it. 2. A refused write never removes the author's text from the page. 3. Status is announced, and never carried by colour alone. 4. Every clickable surface implies a real behaviour. 5. Nothing on this surface suggests a capability the product does not have. ## Navigation and shell One surface. An identity line at the top with a way to switch away, the editor, the actions, and one region for confirmation and one for error. No brand row, no navigation the product does not have. ## Visual direction There is no design system for this product. Follow the supplied application's own markup and the platform's default form controls. Treat that as a constraint, not as inspiration. Plain type, near-black text, one readable column, compact actions. Avoid heroes, decorative gradients, oversized cards and any analytics surface. ## Core data concepts - The update record: its owner, its confirmed content, and when it was confirmed. - The page states: empty, editing, saving, confirmed, refused. ## Required screens and flows 1. Entry: choosing an identity, and the surface that follows. 2. Empty state: the identity owns no record yet. 3. Editing: text in the field, nothing saved yet, and it must be obvious that nothing is saved yet. 4. Saving: the moment between the action and the answer. 5. Confirmed: the message, what it names, and where it sits. 6. Refused write: the text still in the field, the error in its own region, the Retry action, and the absence of any confirmation. 7. Retry, succeeding: what changes on the surface. 8. Reload after a refused write: the last confirmed text returns and the unsaved text does not. Design how that is said, honestly. 9. Return: leaving and coming back to the last confirmed text. ## Interaction states to include Empty; saving; confirmed; refused with the text preserved; retry; announced status; announced error; disabled action with a stated reason; narrow screen. ## Privacy and visibility rules Respect: an identity sees only its own record; nothing indicates whether another record exists. Do not expose another identity's content anywhere, including in a message, a count or a placeholder. ## Content and mock data Language: English. Use realistic update text. Avoid lorem ipsum. Write real product copy, especially for the refused-write message, which is the hardest sentence in this product. ## Output expectations A complete surface with all of its states, not one screen. Someone reading the result should be able to walk each flow from end to end and should never be in doubt about whether their text is kept. ``` ### What came back, and what the showings changed The first output was a clean single surface with the states listed, and one thing wrong with it: the refused-write message said *Save failed.* It was shown to two people who write updates. - Both read *Save failed* as *your text is gone*. One of them selected the text and copied it before doing anything else — which is exactly the behaviour the product exists to make unnecessary. The message was rewritten: **"Not saved. Your text is still here. Try again."** The message names where the text is, because that is the only question the person is actually asking. - The confirmation said only *Saved*, and neither of them could tell whether it referred to what was in the field now or to something earlier. The confirmation gained the time it was confirmed. - One of them asked what happens if the tab is closed with unsaved text. The honest answer is that it is lost. That was not designed around; it was recorded as an open decision and left open. They were shown the flow they do every day — write something, save it, come back — not a tour of the surface. The second showing ended with both saying it was the tool they needed, which is what closed the gate. **In hand at the end of Gate 3:** a prototype the people concerned recognise as their tool. ## Gate 4 — port the prototype into code **There was no starter to clone.** No approved starter repository and no written conventions exist for this exercise, so none were invented. The supplied application is the repository. The gap was written into the journal, dated, with what stood in for it and with whose agreement — and that record is the request that gets made next time, not a decision that the gap was acceptable in general. The three working documents moved together into `docs/` inside that repository — the PRD, `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md` — and the folder of sources stayed where it was. ### What the port produced The page layer was rewritten so that every state the design accepted exists in the code, fed by a service shaped like the store's contract but returning canned answers. Nothing touched storage at this gate. | State | What it renders | Reached by | | --- | --- | --- | | Empty | Field empty, no message in either region. | An identity that owns no record. | | Editing | The field holds text; the confirmation region is empty. | Typing after any state. | | Confirmed | Confirmation region names the time; the field holds the confirmed text. | A write the service says it completed. | | Refused | Error region filled; field holds the submitted text; confirmation region empty; Retry offered and Save hidden. | A write the service says it refused. | | Not the owner's | Nothing. No field, no message, no content in the answer. | The direct route with an id the identity does not own. | What else the port did, and what it deliberately did not do: - The confirmation region and the error region became two separate regions, each announced in its own way, so that a refusal can never be written into the region that means success. - Every message moved to one place at the top of the module instead of being written into the markup, so the copy the showings produced has a single home. - The handler chooses a state and passes values; the rendering holds no rules. Routes stayed thin. - The mock service exposed the store's three operations by name, so Gate 5 would be a swap and not a rewrite. - Nothing was redesigned. Two things came out different from the design, on purpose, and both were recorded: the message sits in the page's own region rather than in the floating element the design showed, because the surface re-renders on submission and a floating element is not announced when it does; and the actions row wraps below a narrow width, which the design had not covered. The back-and-forths were the work of this gate: the running surface beside the design, naming what was off — the error sitting below the field where nobody looked, the two actions indistinguishable at a glance, the button reading *Save again* where the design said *Retry*, the density of the actions row. Fix, rerun, look again. No screen was rebuilt on paper first, and no map was written from the design to the code; the port was close enough that neither would have paid for itself. The three acceptance tests still failed at the end of this gate, on the same three assertions as at Gate 1. That was expected: nothing was connected yet, and a green build was never the evidence being sought. **In hand at the end of Gate 4:** a surface that runs, that you can click. ## Gate 5 — connect the backend The mock service was replaced with the store, one flow at a time, in the same session. No second building session was opened. ### What the connection changed - **The write stopped being a no-op.** The store now writes the submitted content and reports what it wrote; the handler's confirmation is issued from that report and not from having reached the end of the function. - **The write is keyed by its owner, not by a constant record id.** This is the change the control session forced — see below. - **A refused write answers as a refusal.** The exception raised inside the store is no longer swallowed: the answer carries the refusal, the submitted text, the error in its own region, and a Retry action, and it carries no confirmation. Reloading before a successful retry returns the last confirmed content, which is the honest outcome. - **The direct read compares the record's owner with the current identity before any content is loaded into the answer.** A read that is not the owner's ends as a not-found answer whose body carries no part of the content. The comparison lives in the query, so the content of a record someone does not own never reaches the process that would render it, let alone their browser. - **The page read stayed keyed by owner,** so the second identity meets the empty state rather than someone else's text. - Deep on each flow before moving to the next: the empty state, the refusal, a second refusal in a row, a retry that succeeds, a reload between the two, and a read attempted as the identity that owns nothing. ### The control session, at Gate 5 Called in on a doubt rather than on a bug: the tests were passing and the flows looked right. **Finding.** The write still targets a single constant record id. The read is keyed by owner and the write is not, so a save performed under the second identity replaces the author's confirmed content, and both identities are told it worked. > **Evidence.** The store's write operation returns the same constant record id whatever owner it is given — the same contradiction recorded in `DISCOVERY.md`, still present in the connected code. PRD section 3 says a save under one identity must never touch another's record, and PRD section 6 makes that a read-model rule. **Reproduction:** choose the second identity, type any text, select Save draft; switch to the author identity and reload the page. The author's confirmed text is the second identity's text. > **Why the tests did not catch it.** None of the three supplied acceptance tests performs a save under the second identity. They check that the second identity cannot *read*; nothing checks that the second identity cannot *overwrite*. > **What I could not check:** whether the same hole exists on any other path — there is only one write path, so this is the whole of it. > *I read, checked and challenged. I changed nothing and I decided nothing.* **The decision that followed.** The write is keyed by its owner, and the record id stops being a constant in the write path. A regression test was added beside the three supplied ones — save as the second identity, then read as the author, and assert the author's confirmed text is unchanged — because a defect that no check catches will come back. The three supplied tests were not touched. Recorded in the memory, dated, and in the journal with what was verified. The finding went from the control session to the main session directly. How the two sessions reach each other is set up in the tool; nothing in this kit documents it for a particular assistant, and if they cannot reach each other the finding is relayed by hand, unchanged, with its origin stated. **In hand at the end of Gate 5:** the flows hold in depth. ## Gate 6 — test, then ship ### The test round, with demo accounts Authentication is not connected in this exercise and is outside it, so demo accounts are what exists: the two switcher links. They were sent to the two people who had walked the design at Gate 3, with the record the application starts with and the failure button explained, and with the reminder that the switcher is not authentication and that no real content goes in. What came back, and what was done with it: - *"I pressed the failure button twice and after the second one I couldn't tell whether the first attempt had gone through."* The error region now names when the last confirmed save happened, so a refusal always says what is still safe. - *"Retry sits next to Save draft and I can't tell them apart."* Retry only appears in the refused state, and Save is hidden while it shows. One action at a time. - *"On my phone the two buttons were on one line and I pressed the wrong one."* The actions row wraps below a narrow width — the drift already recorded at Gate 4, now the thing a tester actually hit. - *"When it says Saved, saved where?"* Left as it is. The confirmation names the time; naming a place would be a claim about storage this product does not make. Each one was fixed as it came back. Severities were never used in this run, because there was never more coming back than the session could hold — the moment that changes is the moment P0, P1 and P2 start earning their keep, and it did not arrive. The acceptance run after the fixes, from the application's directory: ```text python3 -m unittest -v test_acceptance.py test_author_recovers_only_confirmed_saved_text_after_return ... ok test_failed_save_keeps_edit_visible_and_does_not_replace_confirmed_draft ... ok test_second_identity_cannot_read_author_draft_in_ui_or_direct_endpoint ... ok test_second_identity_save_does_not_touch_author_record ... ok Ran 4 tests OK ``` Walked in a browser as well, as both identities: the empty state, a save, a reload, a switch away and back, two refusals in a row, a retry, a reload between a refusal and its retry, and the direct route requested as the identity that owns nothing. ### The release note Prepared in the main session and sent by hand. The prompt that produced it sends nothing anywhere. ```text Release note — the update editor Date: Day 12 To: the leads of the trades concerned What is in this release, flow by flow - Save and confirm: the confirmation follows the write and names when it happened. A confirmed save survives a reload and an identity switch. - Return and recover: the field holds the last confirmed content and nothing else. An identity that owns no record meets the empty state. - Refused write: the answer reports the refusal, keeps the submitted text in the field, shows the error in its own announced region, offers Retry, and shows no confirmation. A reload before a successful retry returns the last confirmed content. - A read that is not the owner's: answers not-found, with no part of the content in the answer. The ownership comparison is in the query. What has been tested, by whom, with which accounts - Two people who had not seen the build, using the two demo identities the exercise supplies. These are switcher links, not authentication. - The Product Builder, walking all four flows in a browser as both identities. What was verified and how - The acceptance run: the three supplied checks and one added regression check, all passing, from the application's directory. - Walked end to end in a browser: empty state, save, reload, switch away and back, two refusals in a row, retry, reload between a refusal and its retry, and the direct route requested as the identity that owns nothing. - The control session's finding at Gate 5 — a save under one identity overwriting another's record — reproduced, fixed, and covered by the added regression check. What is known to be unfinished - Unsaved content is lost when the tab is closed. This is an open product decision, recorded in the memory, not a defect and not designed around. - The switcher is not authentication and demonstrates nothing about permissions. Every rule in this release is a read-model rule that does not depend on it. What the leads are asked to give the go-ahead on - The read-model rule and the not-found answer. - The refusal path, which is where this product either keeps its word or does not. Which review did not take place, and who was not there to give it - No frontend, backend or data lead read this change: this exercise has no trades to convene, and there is no staging and no production to ship to. The application is loopback-only and is not deployed. The go-ahead was given by the person who set the exercise, on their own. - That gap is the request that gets made next time, and it is written in the journal, dated, rather than left to be reconstructed later. ``` Nothing was deployed, because the exercise has nowhere to deploy to and the supplied application is never to leave the machine. What this gate produced is the note, the go-ahead that was actually available, and the written record of the review that did not happen. The delivery path itself — local, then the repository, then staging, then production, with the checks along the way and a way to see which revision is live — is on the list of what was asked for and not supplied. The one case where things are deliberately frozen did not apply here: nothing was going to production. **In hand at the end of Gate 6:** demo accounts in real hands, and a note that names what was verified and what was not reviewed. ## The memory and the journal at the end of the run ### `docs/PROJECT_MEMORY.md` **Current product position.** One surface where an author writes an update and saves it explicitly. The confirmation follows the write and names when it happened. A refused write keeps the submitted text in the field and never claims success. An identity reads only its own record, and a read that is not the owner's answers not-found with no content — the comparison is in the query, not in the interface. Both identities may save; every write is keyed by its owner. Unsaved content is lost when the tab is closed, and that is open rather than decided. **Product principles.** The confirmation follows the write. A refusal never removes the author's text. What an identity must not see never reaches their browser. Nothing on the surface suggests a capability the product does not have. ```text ## Day 5 - Privacy here is a read-model rule Context: the main session concluded the privacy rule already held because the page shows nothing to the second identity. The control session checked that against the material and it does not hold: the page shows nothing because the read selects by owner and that identity owns no record, and the direct route answers with the content to any chosen identity. Decision: what an identity must not see never reaches their browser. The check belongs in the query, not in whatever renders the page. Rationale: an interface that hides content is hiding it from the one person who is looking at the interface. The route that does not go through the page is where the rule is either real or absent. Trade-offs: slightly more work in the read path; no way to build a legitimate administration view later without returning to this decision. Impact on product / architecture / QA: PRD section 6; the acceptance check that matters exercises the route, not the page. Open questions: none. Links: DISCOVERY.md, the control session's Gate 1 finding. ## Day 6 - A denied direct read answers with a refusal [REPLACED Day 7] Context: the supplied test accepts either a refusal or a not-found answer. Decision: answer with a refusal, as the more conventional choice. Rationale: it is honest to a legitimate client that has lost its own record. Trade-offs: it confirms that a record with that id exists and belongs to someone else. Impact on product / architecture / QA: none — replaced before implementation. Open questions: whether the existence of a record is itself private here. Links: the alignment question asked at Gate 2. REPLACED BY the entry of Day 7. Kept because the reasoning that was corrected is worth being able to see. ## Day 7 - A denied direct read answers not-found Context: the alignment question above was put to the person who set the exercise, with the risk stated: the record id is printed in the supplied notes and is therefore guessable, so a refusal tells anyone who asks that someone else's record exists. Decision: answer not-found, with no part of the content in the answer. Rationale: the existence of a person's unpublished content is part of what is private. The default the prompt proposed was corrected, which is why it was asked rather than chosen silently. Trade-offs: less informative to a legitimate client. Accepted. Impact on product / architecture / QA: PRD sections 2, 6 and 12; the direct read path; the privacy check. Open questions: none. Links: PRD section 14. ## Day 7 - Both identities may save, every write keyed by its owner Context: the read path was written per owner and the write path targeted one constant record. If both were true, one identity's text would replace another's and both would be told it had worked. Decision: each identity holds its own record; a save under one identity never touches another's. Rationale: the contradiction was in the material from the first day and it decides whether the privacy rule means anything at all. Trade-offs: none worth recording at this size. Impact on product / architecture / QA: PRD sections 3 and 5; the write path; the regression check added on Day 11. Open questions: none. Links: DISCOVERY.md, contradiction 1. ## Day 9 - The refusal message names where the text is Context: two people were shown the prototype. Both read "Save failed" as "your text is gone", and one copied the text out of the field before doing anything else. Decision: the message says the text is still here and invites a retry. Rationale: the only question a person has at that moment is where their text is. Answering anything else is answering a question nobody asked. Trade-offs: a longer message in a small region. Impact on product / architecture / QA: the copy; PRD section 13, as a requirement derived from what testers said. Open questions: what happens to unsaved content when the tab is closed — raised by one of them, left open on purpose. Links: the Gate 3 showings. ## Day 11 - The write is keyed by its owner in the connected code Context: the control session found that the connected write still targeted the constant record id, so a save under the second identity replaced the author's confirmed content, and none of the three supplied checks caught it because none of them saves as the second identity. Decision: key the write by its owner, and add a regression check that saves as the second identity and then reads as the author. Rationale: the decision of Day 7 had been recorded and not implemented. A defect that no check catches comes back. Trade-offs: none. The three supplied checks were not touched. Impact on product / architecture / QA: the write path; the test file. Open questions: none. Links: the control session's Gate 5 finding, with its reproduction. ## Day 12 - Shipped without a review by the trades Context: the release note was prepared for the leads of the trades concerned. This exercise has no trades to convene, no staging and no production. Decision: the person who set the exercise gave the go-ahead alone, and the gap was written down rather than dressed up. Rationale: nobody should have to reconstruct later what was read before it went out. A gap named is the request made next time. Trade-offs: no independent technical reading of the change. Impact on product / architecture / QA: none on the product; it is the standing request to whoever would own the delivery path. Open questions: none. Links: the release note; the journal entry of the same date. ``` **Open questions.** What happens to unsaved content when the tab is closed. Whether a version history is ever wanted. Neither is being worked on. ### `docs/PROJECT_JOURNAL.md` ```text ## Day 4 - Gate 0, project folder Context: the case opened with a report of text lost after a save that appeared to succeed. Decision or change: one folder created; every source put in it; memory and journal created before anything else ran; project channel created with the people who would test later already in it. Implementation summary: the inventory and conversion prompt ran; converted files written to converted/; index written to converted/INDEX.md. Verification performed: read the index and the list of what could not be read. Originals untouched. Nothing sent anywhere. Trade-offs: eleven rows of the converted spreadsheet carry no date and were marked as undated rather than guessed at. Follow-ups: password obtained for one file and the prompt re-run on it; the screen recording watched and a one-paragraph note written beside it. Links: converted/INDEX.md. ## Day 5 - Gate 1, discovery and the first control pass Context: the material disagreed with itself about whether there is one record or one per author, and said nothing about what a denied read should answer. Decision or change: DISCOVERY.md written with the source list, the two contradictions, the three gaps, the hypothesis, the privacy risks and the constraints. Privacy established as a read-model rule. Implementation summary: none — nothing was changed in the application at this gate. Verification performed: ran the supplied acceptance checks to see the actual starting point: three failures, on the reload, on the refusal answer and on the direct read. Three errors instead would have meant the environment blocked the tests' own local server. Trade-offs: the contradictions were left unresolved here on purpose and carried to the alignment questions. Follow-ups: two alignment questions for Gate 2. Links: DISCOVERY.md; the control session's finding; the memory entry of the same date. ## Day 7 - Gate 2, the PRD Context: the alignment questions were answered, one of them against the default the prompt had proposed. Decision or change: one document written, its first section the strategic framing, fourteen sections, every assumption marked as an assumption. Implementation summary: none. Verification performed: read back section by section against DISCOVERY.md; each assumption traced to the source it rests on, or to what is missing and who decides it. Trade-offs: the tab-close question was left open rather than answered in passing. Follow-ups: the PRD is what every later prompt reads. Links: the PRD; the memory entries of Day 6 and Day 7. ## Day 8 - Gate 3, the absence of a design system recorded Context: there is no design system and no reference product for this exercise. Decision or change: the supplied application's own markup and the platform's default form controls stand in, agreed with the person who set the exercise. Implementation summary: named as a constraint in the design prompt. Verification performed: none to perform; this is a record, not a change. Trade-offs: nothing here demonstrates a design system, and the substitute is what the prototype and the code both follow so they stay the same product. Follow-ups: the components and their states, the tokens, what may be extended and who maintains it are on the standing request list. Nobody was invented to own them. Links: PRD section 8. ## Day 9 - Gate 3, what the showings changed Context: the prototype was shown twice to two people who write updates. Decision or change: the refusal message rewritten to name where the text is; the confirmation now names when it was confirmed. Implementation summary: in the prototype only; no code existed yet. Verification performed: second showing; both said it was the tool they needed, which is what closed the gate. Trade-offs: a longer message in a small region. Follow-ups: the tab-close question, left open. Links: the memory entry of the same date. ## Day 10 - Gate 4, the port, and one road that did not work Context: no approved starter and no written conventions exist for this exercise. The supplied application is the repository. Decision or change: the gap recorded with whose agreement the substitute was used; the PRD, memory and journal moved into docs/ inside the repository; every state ported against a service shaped like the store's contract. Implementation summary: confirmation and error split into two announced regions; copy pulled into one place; routes left thin; the mock service exposing the store's three operations by name. Verification performed: walked every state in a browser beside the design. The acceptance checks still failed on the same three assertions, which is what was expected with nothing connected. Trade-offs: the first port kept the message in a floating element, as the design showed. It is not announced when the surface re-renders on submission, so it was reverted to the page's own region. Recorded here because the reason is worth keeping, not because the attempt was wise. Follow-ups: the actions row wraps below a narrow width — drift from the design, deliberate. Links: the PRD; the design output. ## Day 11 - Gate 5, the store connected and the overwrite caught Context: the mock service was replaced with the store, flow by flow, in the same session. The checks were passing and the flows looked right. Decision or change: the write keyed by its owner; the refusal answered as a refusal; the ownership comparison moved into the query so that content an identity does not own never reaches the answer. Implementation summary: one write path, one read by owner, one read by id with the owner in the query; the refusal path carrying the submitted text, the error region, Retry, and no confirmation. Verification performed: the control session's reproduction walked by hand — save as the second identity, then read as the author — before and after the fix. The acceptance checks and the added regression check all passing. All four flows walked in a browser as both identities, including two refusals in a row and a reload between a refusal and its retry. Trade-offs: none worth recording at this size. Follow-ups: none. Links: the control session's finding; the memory entry of the same date. ## Day 12 - Gate 6, the test round and the release note Context: demo identities sent to two people who had not seen the build. Decision or change: three things fixed from what came back — the error region now names when the last confirmed save happened; Retry replaces Save while the refusal is showing; the actions row wraps on a narrow screen. One request declined, with the reason: the confirmation names the time and will not name a place, because that would be a claim about storage this product does not make. Implementation summary: copy and layout only. Verification performed: the acceptance checks and the regression check, all passing, run from the application's directory. Walked again in a browser after the fixes. Trade-offs: severities were never used, because there was never more coming back than the session could hold. Follow-ups: no frontend, backend or data lead read this change; there is no staging and no production; nothing was deployed, and the application stays on loopback. That gap is the request made next time. Links: the release note; the memory entry of the same date. ``` ## What this run did not have Worth naming plainly, because a worked example that hides its gaps teaches the wrong thing: - **No design system and no reference product.** A substitute was named, agreed and dated. The system itself is still a request with nobody to address it. - **No approved starter and no written conventions.** The supplied application's own constraints stood in. Nothing was invented that a reviewer would have had to undo. - **No backend service to ask.** The supplied module was the contract and the exercise's own notes were the documentation. - **No staging, no delivery path, no leads to give a go-ahead.** What could be verified was verified and written down; what was not reviewed was named, with who was not there to review it. Every one of those lines is a request with a name missing from it. That is what they are for: turning "this was harder than it should have been" into something specific enough to ask for. Text licensed CC BY 4.0. Code MIT. # Bac à sable d'entraînement Adresse : /fr/resources/sandbox · Markdown : /fr/resources/sandbox.md [Télécharger le kit](/downloads/onirion-4.0.zip) *Le texte ci-dessous est celui du kit, en anglais.* # Save draft — fictional first-run sandbox This local exercise gives a Product Builder one bounded outcome: **an author can recover a confirmed draft after returning, while a second user cannot read it**. A failed save must leave the edit visible in the current page with an error and Retry action; reloading before a successful retry restores only the last confirmed draft. The starter application is **intentionally incomplete**. Its acceptance tests are meant to fail at first. Do not call a green server startup, a design mockup, or a successful POST a completed product outcome. ## Requirements and run - Python 3.9 or newer (checked with 3.9.6, the version macOS ships). No package installation, external service, account, or internet connection is needed. - From this directory, run `python3 app.py` and open `http://127.0.0.1:8766/`. - Run the acceptance checks with `python3 -m unittest -v test_acceptance.py`. - The server binds to `127.0.0.1` only. It creates `sandbox.sqlite3` beside the app; delete that generated file to reset the manual exercise. Tests use a temporary database and do not touch the manual one. The only identities are **Avery Example** (`author`) and **Blair Example** (`reviewer`). They are fictional buttons backed by a local test cookie, **not real authentication**. There is no password or credential. This fixture is for practicing owner-specific behavior; a real product needs its organization's approved authentication and authorization design. Never deploy this server or put real user data into it. ## Starting evidence The database begins with one confirmed draft, ID `fictional-draft-001`, owned by Avery and containing “The imaginary library opens next Tuesday.” The direct read route is `GET /api/drafts/fictional-draft-001`. The form posts to `POST /save`. The **Simulate failed save** button sends `simulate_failure=1`, making the failure reproducible without an external service. Three deliberate defects make the exercise meaningful: 1. Save says “Saved” but does not persist the submitted text, so Avery cannot recover it after reload. 2. The direct read route returns Avery's draft to Blair, although the UI does not show it. 3. The failure switch causes a deterministic write failure inside the storage layer, but the handler swallows it. The response claims success, drops the edit from the current page, and offers no Retry. The three acceptance tests are written against the intended behavior, not the starter defects. Expect **3 failures** before implementation. Three *errors* instead mean the environment stopped the tests from starting their local server on `127.0.0.1`. **Running the tests from Codex.** Codex's default `workspace-write` sandbox blocks that local server, so the tests end in three `PermissionError` errors before reaching the intended failures. Allow network access for the session, for example `codex --sandbox workspace-write -c sandbox_workspace_write.network_access=true`, or run the test command yourself outside the sandbox. Checked with Codex CLI 0.155.0-alpha.9.2. A future passing test run checks the server behavior, but an independent reviewer should also inspect the running UI, including the error message, keyboard use, and narrow-screen state against an accepted design. ## Exercise task Use the [method core](/fr/resources/method-guide) and [first-case worksheet](/fr/resources/first-case#worksheet). Classify this synthetic case, write a bounded brief, identify the Design, Frontend, and Backend/API contributions, and record a human-reviewed design for empty, editing, saving, saved, failed, and return states. Check the available conventions and service routes; this tiny sandbox has no approved organizational frontend starter or production access path. Treat those as exercise gaps to record, not as permission to invent another organization's standards. After the design and capability decisions are recorded, implement the behavior inside this directory. Use the tests as acceptance evidence and inspect the rendered experience as both identities. Preserve Avery's last confirmed text when a save fails. Deny Blair through the direct endpoint as well as the interface. Report the exact behavior observed and leave the independent QA verdict to another reviewer. Deletion, expiration, offline edits, concurrent writers, and real authentication are outside this exercise. No public publishing or deployment is part of the run. # Inventorier et convertir Adresse : /fr/resources/prompt-inventory · Markdown : /fr/resources/prompt-inventory.md *Le texte ci-dessous est celui du kit, en anglais.* # Inventory and convert the project folder **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 0.** Run this first, in a session opened on the project folder. It converts what it can, indexes every source, and lists what it could not read. It interprets nothing. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text You are at Gate 0 of the method: setting up a new product project. The project folder is the one this session is opened on. Work only inside it. Do this, and nothing else: 1. Walk the folder and list every file you find. 2. Convert to Markdown everything you can convert, into the sub-folder `converted/` of the project folder. Never modify, move, rename or overwrite an original. 3. Write `converted/INDEX.md`: one line per source, with the file name, what it is, and the date it is from. If you cannot date it, say so. 4. List everything you could not read or could not convert, and why. Do not analyse the content. Do not draw conclusions. Do not write a PRD. Do not send anything anywhere — no service, no channel, no address. Report the index, the list of what you could not read, and where you put the converted files. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to the next gate. ``` # Lire les channels Adresse : /fr/resources/prompt-channel-reading · Markdown : /fr/resources/prompt-channel-reading.md *Le texte ci-dessous est celui du kit, en anglais.* # Have an agent read what nobody has time to read **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 1.** Ask for this by name when you want the channels or the client communications read. What comes back is input, not a decision. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text You are at Gate 1 of the method: gathering the discovery. Read [name the channel, mailbox or thread, and the period]. Then: - summarise what is being said about [the product or the problem]; - list what it confirms, what it contradicts, and what is new; - name the open questions it raises for the discovery. Rules: - ask me before opening anything I have not named here; - tell me exactly what you read; - keep names, addresses and personal details out of what you write down; - return findings, not decisions. I decide what is in scope. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to Gate 2. ``` # Analyser et écrire le PRD Adresse : /fr/resources/prompt-prd · Markdown : /fr/resources/prompt-prd.md *Le texte ci-dessous est celui du kit, en anglais.* # Analyse the discovery and write the PRD **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 2.** The second prompt of the setup. It reads what Gate 0 and Gate 1 left in the folder and writes the PRD into the template. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text You are at Gate 2 of the method: writing the PRD. Read, and open nothing else without asking me first: - the converted folder `converted/` and its index `converted/INDEX.md`; - `DISCOVERY.md` in the project folder: the source list, the ambiguity list and the stakeholder questions written at Gate 1, including what an agent read on my behalf; - the project memory and the project journal; - the PRD template `../templates/prd.md`, for the shape of each section. Anything that is not in the project folder — a channel, a mailbox, client communications — is named here by me, or it is not read. First, state three things, separately: 1. what is established, and which source establishes it; 2. what contradicts what, source against source, without resolving it yourself; 3. what is absent — the questions this material does not answer. Then ask me the alignment questions. Where two sources point different ways, do not choose silently. For each one, give me: what source A says, what source B says, the product risk of choosing the wrong interpretation, the direction you would default to, and the confirmation you need from me. Then produce one document: the PRD, with these fourteen sections, in this order, and no others: 1. strategic framing — what the product is going to be, what is wanted and what is not, the boundary it holds, the business loop it serves; 2. product boundary; 3. roles and permissions; 4. core workflows; 5. product states and data visibility; 6. privacy and ethics rules; 7. which source wins when sources disagree; 8. design baseline and acceptable drift; 9. functional depth; 10. backlog taxonomy; 11. backend and API assumptions; 12. acceptance criteria; 13. the QA contract; 14. open decisions. Rules: - one document, not two: the strategic framing is the PRD's first section, and the sections after it detail what it states; - mark every assumption as an assumption, with the source it rests on or, when the material does not settle it, what is missing and who has to decide it; - invent no decision, no approval, no API and no standard; if it is not in the material, it is absent, and absent is an answer; - do not send anything anywhere — no service, no channel, no address. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to Gate 3. ``` # Prompt design — spécification Adresse : /fr/resources/prompt-design-specification · Markdown : /fr/resources/prompt-design-specification.md *Le texte ci-dessous est celui du kit, en anglais.* # The design prompt — long specification **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 3.** The specification the PM session writes for the design tool. It asks for end-to-end flows, not just the major screens. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ```text Design a full high-fidelity web application prototype for [PRODUCT NAME], [ONE-SENTENCE PRODUCT DESCRIPTION]. This is a real logged-in [B2B SaaS / internal operations / marketplace / admin] application, not a landing page. Start directly inside the product experience. Treat the attached PRD — whose first section is the strategic framing — together with the research notes, source documents and design-system references, as what decides. If a linked source is gated or unavailable, work from the pasted content and do not invent a product decision that is missing. Design end-to-end flows, not only the major screens. Every flow listed below must be walkable from its entry point to its final state, including the intermediate steps, the branches, the failures and the confirmations. ## Strategic context [Why this product exists, the business loop it serves, the constraints around it.] This product helps [PRIMARY USERS] answer: 1. [CORE USER QUESTION] 2. [CORE USER QUESTION] 3. [CORE USER QUESTION] The product should feel like [PRODUCT METAPHOR: an operations workbench, a daily work console]. Calm, precise, structured, auditable, built for repeated daily work. ## Product boundary This product is for: - [ROLE / USER GROUP] - [ROLE / USER GROUP] This product is not for: - [OUT-OF-SCOPE USER / TEAM] Do not design: - [OUT-OF-SCOPE WORKFLOW] - [OUT-OF-SCOPE SCREEN] - [INTERNAL-ONLY OR SENSITIVE SURFACE] If an out-of-scope workflow exists, represent it only as a safe status, a handoff or a request state inside this product. ## Users and roles - [ROLE]: [what they do, what they need, what they can see] - [ROLE]: [what they do, what they need, what they can see] - [READ-ONLY / ADMIN / SUPERVISOR ROLE]: [permissions and constraints] Show role-based differences wherever they materially change navigation, actions, data visibility, disabled states or empty states. ## Core product principles 1. Lead with action, not decorative analytics. 2. Make the primary workflow usable end to end. 3. Keep sensitive data role-gated and explain visibility limits clearly. 4. Prefer tables, queues, drawers, modals, tabs, filters and audit trails over marketing-style layouts. 5. Make every clickable surface imply a real behavior. 6. Do not expose internal operational complexity to users who should only see safe statuses. 7. Use realistic data density and realistic edge cases. ## Navigation and shell Use a real app shell: navigation appropriate to the roles, page header, account or organization context, notifications, language toggle where relevant, account menu, settings and administration in the right place. Primary navigation: 1. [MAIN AREA] 2. [MAIN AREA] 3. [MAIN AREA] Do not repeat the product name as a large brand row inside every page header. The shell should feel like a daily-use operational product. ## Visual direction Use [YOUR ORGANIZATION'S DESIGN SYSTEM OR REFERENCE PRODUCT]. Treat it as a constraint, not as inspiration. Use: dense operational layouts; near-white app surfaces; soft neutral background; subtle borders; compact spacing; strong readable typography; text near black; accent colors only where they carry meaning; functional status colors; status badges, segmented controls, tabs, drawers, modals, tables, filters and forms. Avoid: landing pages; hero sections; decorative gradients that are not an established pattern; oversized marketing cards; generic analytics dashboards disconnected from action; playful consumer UI; explanatory filler text inside the product UI; one-off components that do not look reusable. ## Core data concepts Represent these naturally in the UI, with their real relationships rather than disconnected cards: - [ENTITY] - [STATUS / STATE MODEL] - [DOCUMENT / REQUEST / CASE / INVOICE / REPORT] - [AUDIT EVENT] - [PERMISSION / VISIBILITY LEVEL] ## Required screens and flows Design a coherent multi-screen prototype. Include the ones this product actually has, each walkable end to end. 1. Authentication and entry: [OTP / email code / passwordless / SSO], loading, invalid code, resend, successful transition. 2. Workbench: what needs attention now — work queues, recent changes, next actions, role-specific content. 3. Primary object directory: dense list or table for [the main entity], with search, filters, counters, row status and next action, primary and secondary actions, empty state, bulk or import/export where relevant. 4. Primary creation or submission flow: a guided modal, drawer or multi-step flow, not one long undifferentiated form. Include validation, missing required fields, back and next, save and resume later, review and submit. 5. Detail workspace: header, status and key metadata, tabs or sections, related records, documents, thread or comments, activity timeline, contextual actions. 6. Requests and communication: list, categories, status and priority, creation flow, detail thread, attachments, linked object, action-required state, resolved state. 7. Documents and records: repository, detail or preview and download behavior, filters, missing-document state, replace or re-upload, access restrictions. 8. Finance, billing or reporting where relevant: overview by period, invoices or ledger, payment status, reconciliation, downloadable documents, exception workflow. 9. Settings and administration: organization settings, users and roles, role descriptions, invite and deactivate, security settings, read-only states for users without permission. ## Interaction states to include Empty; loading; validation errors; missing required fields; pending, approved, rejected, needs information, overdue, resolved; disabled actions with a stated reason; role-restricted content; notifications; audit timeline; download and export; confirmation modals; destructive-action confirmation; success and failure feedback; side panels and drawers; dropdowns and profile menus. ## Privacy, security and visibility rules Respect: - [RULE] - [RULE] Do not expose: - [SENSITIVE DATA] - [INTERNAL NOTES] - [RAW EVIDENCE] If sensitive data is needed to complete a workflow, show the approved role-gated version, a safe status, or a path to request it. ## Content and mock data Language: [French-first / English-first / bilingual]. Currency: [currency]. Organizations, people, domain vocabulary, dates and identifiers should look real. Avoid lorem ipsum. Write real product copy. ## Output expectations A polished full-product exploration, not a single screen. Prioritize clear navigation, complete product vision, realistic workflow depth, strong table and list design, reusable patterns, role and privacy logic, real operational actions, and the modals, drawers, dropdowns, tabs, empty and error states the flows need. Someone reading the result should understand what [PRODUCT NAME] becomes as a complete product, and be able to walk each main flow from end to end. ``` # Prompt design — instruction Adresse : /fr/resources/prompt-design-instruction · Markdown : /fr/resources/prompt-design-instruction.md *Le texte ci-dessous est celui du kit, en anglais.* # The design prompt — short instruction layer **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 3.** What gets typed into the design tool alongside the long specification and the attachments. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text Design [PRODUCT NAME], [SHORT PRODUCT DESCRIPTION]. Use the attached design system and product documents as source material. Treat the long design prompt as the full specification and this short prompt as the instruction layer. Do not create a landing page or a concept dashboard. Start with the real product experience: [PRIMARY WORK SURFACE], [SECONDARY WORK SURFACE], [DETAIL WORKSPACE], [DEEPEST WORKFLOW]. Design deeply across the product, not only the top-level pages. Include states, variants, drawers, modals, empty, error and loading states, permission-restricted states, audit views, escalation, handoff, and safe output previews where relevant. Each main flow must be walkable end to end. Core UX: - [PRINCIPLE] - [PRINCIPLE] Must include: - [SURFACE / FLOW] - [CRITICAL STATE MODEL] - [ROLE / PERMISSION VARIANTS] Use compact, calm, high-density operational UI. Make it feel production-ready, not like a presentation. ``` # Prompt d'affinage Adresse : /fr/resources/prompt-refinement · Markdown : /fr/resources/prompt-refinement.md *Le texte ci-dessous est celui du kit, en anglais.* # The refinement prompt **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 3.** Use it when the first output is too shallow, too conceptual or too dashboard-like. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text Refine this into a denser operational product. Prioritize daily user work over executive analytics. The primary workflow should be obvious on the first screen. Remove any marketing-style hero, oversized explanatory card or decorative section. Increase depth: - make status, owner, next action, date, priority and permission state visible where they matter; - make the main workflow usable end to end, including its intermediate steps and its failures; - add the missing drawers, modals, dropdowns, error, empty and confirmation states; - make history and audit easy to inspect; - make document and request workflows feel functional; - make role-gated and restricted states explicit; - use realistic data and realistic edge cases; - keep the design aligned with the attached design system. ``` # Porter le prototype Adresse : /fr/resources/prompt-port · Markdown : /fr/resources/prompt-port.md *Le texte ci-dessous est celui du kit, en anglais.* # Port the prototype into code **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 4.** Hand the prototype and the starter to the coding agent, and keep it inside your organization's conventions. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text You are at Gate 4 of the method: porting the prototype into code. You are implementing [PRODUCT / SLICE]. Read before coding: - the prototype from Gate 3, in the form it was handed to you - the PRD, whose first section is the strategic framing - the approved frontend starter repository and its conventions - the backend conventions - the project memory and journal Product boundary: [WHO THE PRODUCT IS FOR, WHO IT IS NOT FOR, AND WHAT MUST NOT BE BUILT HERE] Rules: - the prototype is the visual and product reference; - the starter repository and its conventions decide how the code is written; - do not paste the design tool's export into the application foundation; - keep routes thin; - put domain logic in feature folders; - use the organization's shared primitives before creating anything new; - route mock data through API-shaped services that match the future backend contracts; - centralize copy and localization; - enforce role and privacy rules at the read-model level; - do not redesign anything unless you are explicitly asked to; - before each change to the code, re-read the starter's rules and the backend conventions. Current task: [THE FLOW, SCREEN OR FIX] Acceptance criteria: - the flow works end to end in the front-end mock; - the result matches the design where the design is non-negotiable; - no privacy regression; - relevant tests added or updated; - project memory and journal updated if this changed product behavior, architecture, a stakeholder decision or future reasoning. Run before finishing: - typecheck - lint - tests - build - click through the flow in a browser Report: - which gate you are at, what you have, what is missing, and what I must decide before you cross - what changed - what you actually ran and what it returned - memory and journal updates made, or explicitly skipped with the reason - remaining open product or backend decisions ``` # Brancher le backend Adresse : /fr/resources/prompt-connect · Markdown : /fr/resources/prompt-connect.md *Le texte ci-dessous est celui du kit, en anglais.* # Connect the backend to the front end **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 5.** The longest gate. The flows have to hold in depth, not on the surface. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text You are at Gate 5 of the method: connecting the backend. Before coding, read: - the PRD, whose first section is the strategic framing - your frontend starter rules and conventions - your backend conventions - the project memory and journal Current task: [ONE FLOW, END TO END] Acceptance criteria: - the user-facing flow works end to end against the real backend - empty, loading, error and permission-denied states are handled - no privacy regression - relevant tests are added or updated - project memory and journal are updated if the work changes product behavior, architecture, stakeholder decisions, or future reasoning Run before finishing: - typecheck - lint - tests - build - diff check - walk the connected flow in a browser, end to end, including its empty, error and permission-denied states Report which gate you are at, what is missing, what I must decide before you cross, what changed, what was verified, and any remaining product or backend decision. ``` # Préparer une mise en production Adresse : /fr/resources/prompt-release · Markdown : /fr/resources/prompt-release.md *Le texte ci-dessous est celui du kit, en anglais.* # Prepare a release for the leads **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 6.** What has been tested, by whom, with which accounts, what is known to be broken, and what the leads are asked to approve. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text You are at Gate 6 of the method: test, then ship. Read before you write anything: - the PRD, whose first section is the strategic framing - the project memory and the project journal - what changed in the repository since the last release Prepare the release note for the leads of the trades concerned — engineering, backend, frontend, data. State these, and invent none of them: - what is in this release, flow by flow; - what has been tested, by whom, and with which accounts — demo accounts or real ones; - what was verified and how: the flows walked end to end, the empty, error and permission-denied states exercised, the checks that were run and what they returned; - what is known to be broken or unfinished, and where it is being tracked; - what the leads are being asked to give the go-ahead on; - which review did not take place, if one could not, and who was not there to give it. If something was not tested, say it was not tested. A gap named is the request I make next time. Do not send anything anywhere — no service, no channel, no address. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before this goes to production. ``` # Session contrôleur Adresse : /fr/resources/prompt-control-session · Markdown : /fr/resources/prompt-control-session.md *Le texte ci-dessous est celui du kit, en anglais.* # Starting prompt for a control session **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Across every gate.** The second session, the one that challenges. It reads, checks and challenges; it does not change code, decide scope, or write the PRD or the prompts. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text You are the control session for [PRODUCT]. The work is at [GATE]. Your job is to read, check and challenge the work of the main session. Do not trust its claims. Check them against the material. Read what exists at this gate, and nothing that does not: - the discovery material in the project folder, and `DISCOVERY.md` once Gate 1 has written it - the project memory and the project journal - from Gate 2 onward, the PRD, whose first section is the strategic framing, and the product decisions - from Gate 3 onward, the design the front end is ported from - from Gate 4 onward, the repository Tell me what you read, and what did not exist yet at this gate. What I am asking you to check now: [ONE AREA: the discovery findings / the PRD / its strategic framing / what was ported from the design / a backend flow / a bug] Rules, which do not change between runs: - you read, check and challenge - you do not change code - you do not decide scope - you do not write the PRD and you do not write the prompts - you return findings with their evidence, and I decide Return: - which gate the work is at, what it has, what is missing, and what I must decide before it crosses - each finding with the evidence it rests on: the file, the screen, the flow, the section of the PRD, the steps that reproduce it - what you could not check, and why - product decisions separated from defects - [once defects are being tracked rather than fixed as they appear, mark each finding P0, P1 or P2] When you observe something, send it to the main session as well as to me: [how this tool addresses the main session — if it cannot, hand it to me and I will relay it unchanged] ``` # Contrainte permanente Adresse : /fr/resources/prompt-standing-constraint · Markdown : /fr/resources/prompt-standing-constraint.md *Le texte ci-dessous est celui du kit, en anglais.* # The standing constraint **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Every gate.** Carry this in every prompt that changes code. It is what keeps the memory, the journal and the gate position current. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text If your work changes product behavior, architecture, a stakeholder decision or future reasoning, update the project memory and the project journal. Memory holds decisions and trade-offs; the journal holds the chronological record. Do not log small cosmetic changes unless they affect product direction or demo readiness. Before finishing, state whether memory and journal were updated, or why no update was needed, and state which gate you are at, what is missing, and what I must decide before you cross. ``` # Modèle de PRD Adresse : /fr/resources/prd-template · Markdown : /fr/resources/prd-template.md *Le texte ci-dessous est celui du kit, en anglais.* # Product requirements document — the template **A method by Alexis Boyer · version 4.0 · September 22, 2026** Gate 2 fills this template; the filled PRD lives in the project folder beside the project memory and the project journal and moves into `docs/` with them when the code starts, and it is what the coding agent reads at every gate after this one. ## 1. Strategic framing *In a few lines, say what the product is going to be: what is wanted, what is not wanted, the boundary it holds and the business loop it serves.* - What this product is going to be: - What is wanted from it: - What is explicitly not wanted: - The business loop it serves: - The constraints that shape it: - What the sections below detail: ## 2. Product boundary *Draw the line around the product: who it serves, what belongs elsewhere, and what it must never expose.* - Who the product is for: - Who it is not for: - Workflows that belong in another product: - What the product must never expose: - Shared core or backend objects assumed: - Non-goals: - How an out-of-scope workflow is represented here instead (safe status, handoff, request state): ## 3. Roles and permissions *Write out every role, including two roles that differ by a single screen.* | Role | What they do | What they can see | What they must not see | What they can do | | --- | --- | --- | --- | --- | | | | | | | | | | | | | - Where role differences change navigation, actions, disabled states or empty states: - How a role is granted, changed and removed: ## 4. Core workflows *List each workflow the product exists to carry, from its entry point to its final state.* - Workflow: - Who runs it: - Entry point: - Steps: - Branches: - Failures and how they end: - Confirmations: - Final state: ## 5. Product states and data visibility *Name the states each object moves through, what moves it, and what is visible in each state to each role.* - Object: - Its states, in order: - What moves it from one state to the next: - Terminal states, and what reopens them: - What each role sees in each state: - What is hidden in each state, and from whom: ## 6. Privacy and ethics rules *Say which data is sensitive and how it must be handled; this controls the interface, the data model, search, exports, backend read models and QA.* - Sensitive data held or displayed here: - How each kind must be handled: - What must never be shown, and to whom: - Rules for search, filters and exports: - Rules for what may reach the browser at all: - Controlled exceptions, with the fields each one is allowed: - The intake path for a request to see sensitive data: - Retention and deletion expectations: ## 7. Which source wins when sources disagree *Write the order down, most authoritative first, so an agent does not overfit to an outdated document.* 1. 2. 3. 4. 5. 6. - What must be checked before an old backlog ticket is used: - Who records a change to this order, and where: ## 8. Design baseline and acceptable drift *Name the design reference this product follows and the drift that is acceptable; the design itself arrives at Gate 3, so state here what is assumed and what must be requested.* Assumed now: - The design reference this product follows (design system, or a named reference product standing in for one): - Its version or location, as known today: - What counts as non-negotiable in it: - What counts as acceptable drift from it: - Where the prototype and the front end must draw on the same reference: To request from Design Ops: - The components and their states: - The tokens and the rules for using them: - What may be extended and what may not: - Who maintains the system: - An agent-readable form of the above: - The named owner of each request, and the date the answer is needed: - What is being followed in the meantime, and with whose agreement: ## 9. Functional depth *Say which flows must really work in the front-only prototype and which may stay placeholders.* - Flows that must work end to end in the front-only prototype: - Flows that may stay placeholders, scoped on purpose: - What each clickable surface does, where a user can click it: - Simulated states deliberately allowed, and their limits: - States required everywhere: empty, loading, validation error, permission-denied, confirmation, success and failure: ## 10. Backlog taxonomy *Keep these categories apart, so an undecided question is not coded around as if it were a defect.* | Category | What belongs in it here | Where it is tracked | Who owns it | | --- | --- | --- | --- | | Product decisions | | | | | Implementation tasks | | | | | Design parity issues | | | | | Privacy and legal guardrails | | | | | QA findings | | | | | Backend integration work | | | | | Future nice-to-haves | | | | ## 11. Backend and API assumptions *Separate what this product assumes the backend already does from what has to be requested, since the contracts are obtained at Gate 4 and the connection is made at Gate 5.* Assumed now: - Backend objects, state machines and workflow contracts assumed: - Authentication and permission rules assumed: - The business meaning of key fields and status values, as understood here: - APIs believed to exist and used by these flows: - The shape the front end's mock services will follow until the real contracts arrive: To request from Backend and API Ops: - The API catalog with real examples: - Request and response shapes, errors and versioning, for each API used here: - Confirmation of the business meaning of key fields and status values: - Reference patterns for authentication, migrations and tests: - A test environment with test identities and safe data: - Read-only access to logs, errors and health, and who to reach when something breaks: - APIs that do not exist yet, raised through the written request route: - The named owner of each request, and the date the answer is needed: To request from Frontend Ops, where these flows depend on it: - The approved starter repository, its current version, its owner and how to start it: - The API client pattern, authentication, error handling and loading states: - The checks required on a deployable branch, and the preview or environment path: - The named owner of each request, and the date the answer is needed: ## 12. Acceptance criteria *Per flow, say what has to be true before it counts as done.* - Flow: - Works end to end, against the mock services and then against the real backend: - Empty, loading, error and permission-denied states handled: - Matches the design reference where that reference is non-negotiable, within the drift accepted in section 8: - No privacy regression: - Tests added or updated: - Checks to run before finishing (typecheck, lint, tests, build, walk the flow in a browser): - Memory and journal updated when product behaviour, architecture, a stakeholder decision or future reasoning changed: ## 13. The QA contract *Say how this product gets checked, so the check is not invented at the end.* - Personas to test: - Role-based privacy checks: - Requirements derived from transcripts: - Regression flows: - Validation commands: - Expected report format: - Severity meanings in use, and when defects start being tracked rather than fixed as they appear: ## 14. Open decisions *One row per decision: its alignment question states what one source says, what the other says and the product risk of choosing wrong; who decides is a person, not a team.* | Decision | Alignment question behind it | Default proposed | Who decides | By when | | --- | --- | --- | --- | --- | | | | | | | | | | | | | | | | | | | Text licensed CC BY 4.0. Code MIT. # Mémoire projet — entrée Adresse : /fr/resources/memory-entry · Markdown : /fr/resources/memory-entry.md *Le texte ci-dessous est celui du kit, en anglais.* # Project memory — one entry **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 0, then every gate.** One entry of `PROJECT_MEMORY.md`. The memory answers where the product stands today; its entries are dated and a replaced decision stays readable. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text ## [Date] - [Decision or topic] Context: Decision: Rationale: Trade-offs: Impact on product / architecture / QA: Open questions: Links: ``` # Journal projet — entrée Adresse : /fr/resources/journal-entry · Markdown : /fr/resources/journal-entry.md *Le texte ci-dessous est celui du kit, en anglais.* # Project journal — one entry **A method by Alexis Boyer · version 4.0 · September 22, 2026** **Gate 0, then every gate.** One entry of `PROJECT_JOURNAL.md`. The journal is dated and never rewritten, including what turned out to be wrong. It is quoted here exactly as it appears in [the core guide](/fr/resources/method-guide). ## The text to copy ```text ## [Date] - [Workstream or session] Context: Decision or change: Implementation summary: Verification performed: Trade-offs: Follow-ups: Links: ``` # Skill Claude Code Adresse : /fr/resources/claude-code-skill · Markdown : /fr/resources/claude-code-skill.md [Télécharger le kit](/downloads/onirion-4.0.zip) *Le texte ci-dessous est celui du kit, en anglais.* # Onirion · Claude Code adapter **A method by Alexis Boyer · version 4.0 · September 22, 2026** This file covers one thing: running the method in Claude Code. Installation, how a session knows which gate it is at, and how to run the main session and the control session side by side. The method itself is in the [core guide](/fr/resources/method-guide). Nothing here changes it — the gates, what each one demands and what ends it are the same whatever assistant you use. ## Install You need Claude Code and `bash`. Nothing else is installed. Download and unzip the kit. From the folder that contains `onirion/`, run: ```sh bash onirion/claude/install.sh /absolute/path/to/your-project ``` The installer copies a self-contained skill to `/.claude/skills/onirion/`. It bundles the method sources into the installed skill's own `references/` folder — the core guide at `references/method/README.md` and the PRD template at `references/templates/prd.md` — so the installed skill does not depend on the kit folder, on another skill, or on any machine but yours. Three things the installer will not do. It does not modify any other file in your project. It refuses to overwrite an existing skill of the same name: inspect the older installation and remove or rename it yourself if you mean to replace it. And it refuses to build an incomplete skill — if a source file it needs is missing, it stops and changes nothing. Claude Code discovers project skills under `.claude/skills/`. Start or return to a session in that project and invoke `/onirion`, or ask Claude to apply the method. If the skill is not listed, restart the session, then open `.claude/skills/onirion/SKILL.md` and its `references/` folder and check they are there. Claude Code's [skills documentation](https://code.claude.com/docs/en/skills) describes project-skill discovery. ## Start a project at Gate 0 At Gate 0 there is no repository. There is a folder of sources: one folder created for the project, holding every document the work will draw on. Claude Code opens on a directory, not on a repository, so that folder is enough to start. Nothing has to build and nothing has to run. 1. Create the project folder and put the documents in it. 2. Run the installer with that folder as the project. The skill lands in `.claude/skills/` inside it. 3. Create `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md` in the folder, before the first prompt runs. 4. Open a Claude Code session on the folder and invoke `/onirion`. 5. Paste the inventory and conversion prompt from Gate 0 of the core guide. That prompt writes the converted files into `converted/` and the index into `converted/INDEX.md`. It never modifies an original, and it sends nothing anywhere. Read the index it returns and the list of what it could not read, and fill the obvious holes while they are cheap. **At Gate 4 the project moves.** The repository is a new folder beside the folder of sources, cloned from your organization's approved frontend starter. Run the installer again, with the repository as the project, so the skill is there too. Then repoint your session at the repository and move the PRD, `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md` into it under `docs/`. From that point the repository is where both sessions work. ## How the session knows which gate it is at The skill holds no state of its own. It knows where the work stands because it reads the folder it is opened on, and because you make it say so out loud. **The files are the evidence.** `converted/INDEX.md` exists, so Gate 0 ran. `DISCOVERY.md` exists, with its source list, ambiguity list and stakeholder questions, so Gate 1 is written down. A PRD whose first section is the strategic framing, so Gate 2 produced something. A repository with a front end you can run, so Gate 4 is under way. This is also why the guide insists that findings be written into named files: a finding left in a chat window is a finding the next session cannot read. **Every prompt ends the same way.** Each prompt in the core guide closes by asking the session to state which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. Ask for it at the start of every session, and ask for it again at every gate. "I am at Gate 3" is the shape of it, followed by the three answers. **It asks before it crosses.** The session does not walk through a gate on its own. It names what you have to decide and it stops there. Answer, and it goes on. A session that cannot say where it is has left the method, and it is about to cross a gate you have not closed — point it back at the files and make it answer before anything else. Sessions do not remember. A new session, or one that has been running long enough to lose the early context, re-reads the memory, the journal, the PRD and the discovery, and states its gate again from what it found. That is the job those files do. ## Run the two sessions This is the part of the method this adapter exists for. The main session builds. The control session challenges it: it reads, checks and challenges, it does not change code, it does not decide scope, it does not write the PRD or the prompts, and it returns findings with their evidence. You decide. ### Open the second session Open a second Claude Code session on the same project — the folder of sources up to Gate 3, the repository from Gate 4. A second terminal window or tab, or a second session in the app; either works. Same project matters: both sessions then read the same memory, the same journal, the same PRD, the same repository, so a finding can point at a file and the other session can open it. The skill is a project skill, so the second session already has it. Invoke `/onirion` there as well. Two sessions, and only two. Do not open several building sessions at once on different parts of the code — their scopes overlap and what comes out of that is bugs. ### Give it the control-session prompt Paste the control-session starting prompt from the core guide and fill the brackets: the product, the gate the work is at, and the one area you want checked — the discovery findings, the PRD, its strategic framing, what was ported from the design, a backend flow, a bug. Keep the rules block unchanged between runs. Those rules are the whole harness. Nothing in the tool stops a session from editing files, so the limit is the one you wrote down. Restate it the moment the session starts proposing instead of reporting, or starts rewriting the PRD, or starts writing prompts for the main session. What you should be getting back is findings with evidence — the file, the screen, the flow, the PRD section, the steps that reproduce it — not diffs. You can reopen the same control session later instead of starting over. In the CLI, `claude --resume` reopens a session, and session transcripts live on disk under `~/.claude/projects/`. Resuming keeps the rules block and everything the session already checked. ### How a finding gets from one session to the other **The way that always works: you relay it.** Copy the finding out of the control session and paste it into the main session, unchanged, and say where it came from. Then have the main session open the evidence itself rather than act on the summary. This costs you a paste and it depends on nothing — no configuration, no version, no setup. It is the answer the last bracket of the control-session prompt falls back to: *if it cannot, hand it to me and I will relay it unchanged*. **If your setup can carry the message itself, put that in the last bracket.** Some Claude Code setups let one session send a message to another, where it arrives as a turn in the target session. Check whether yours does before you rely on it: test it once with a small, harmless finding and watch it land. If it lands, write the instruction into that bracket so the control session addresses the main session directly. If it does not, leave the bracket telling the control session to hand the finding to you. Either way the practice is the same, and it is the practice that matters, not the plumbing. The control session states what it found and what the evidence is. It reaches the main session whole. You stay in the loop and you decide what the main session does with it. ### Where you call it in At Gate 1, on the discovery findings. At Gate 2, on the PRD and on its strategic framing — not only whether the PRD is coherent, but whether the direction holds. After Gate 4, to confirm that what was built really comes from the design. During Gate 5, on backend bugs and on results you do not believe: ask it to reproduce, not to fix. The core guide's control session section has the detail. Text licensed CC BY 4.0. Code MIT. name: onirion description: Apply Alexis Boyer's product building method in Claude Code: work out which of its seven gates the project is at, do that gate's work, and stop before crossing one. Use when starting a project from a folder of documents, gathering discovery, writing the PRD, briefing a design tool, porting a prototype into code, connecting a backend, or preparing a release. # Onirion · Claude Code skill **A method by Alexis Boyer · version 4.0 · September 22, 2026** You work for a **Product Builder**: one person accountable for one product outcome, front and back, from a folder of documents to production. Design, Frontend, Backend and API, Data, access, delivery and review are Ops services supplied to them, horizontally. You do the work you are briefed for. You never take the outcome, and you never take a decision that belongs to the human. The method is in `references/method/README.md`. Read the section for the gate you are at before you work in it, and do not work from memory of it. The one template is `references/templates/prd.md`. If any of these is absent, say the installation is incomplete and stop. ## First: work out the gate and say it Before anything else, look at the folder or the repository you are opened on and work out which gate the project is at. Evidence, not assumption. - No `converted/INDEX.md` → Gate 0. - An index, no `DISCOVERY.md` → Gate 1. - `DISCOVERY.md`, no PRD → Gate 2. - A PRD, no prototype the people concerned have recognized → Gate 3. - A prototype they recognized, no repository → Gate 4. - A front end that runs and can be clicked, services still mock → Gate 5. - Flows holding against the real backend → Gate 6. Then say it out loud, in this shape, and say it again before every gate: ```text Gate: [0 to 6] What I have: What is missing: What you must decide before I cross to Gate [next]: ``` **Never cross a gate without the human.** Finish the gate you are at, report, and wait. If you cannot say which gate you are at, say that instead of guessing. ## The gates **0 — set up the project folder.** Everything in one folder. Create `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md` first. Walk the folder, list every file, convert what you can into `converted/`, write `converted/INDEX.md` (file name, what it is, its date), list what you could not read and why. Never modify, move, rename or overwrite an original. Do not analyse, do not conclude, do not write a PRD. **1 — gather the discovery.** Read what you are pointed at, by name. Return what is confirmed, what is contradicted, what is new, and the open questions. Write `DISCOVERY.md` in the project folder: source list, ambiguity list, stakeholder questions, the hypothesis on the product boundary, the privacy and compliance risks, the existing repository and starter constraints. Findings, never decisions. **2 — write the PRD.** Read `converted/` and its index, `DISCOVERY.md`, the memory and the journal, and `references/templates/prd.md` for the shape. First state, separately: what is established and which source establishes it; what contradicts what, source against source, unresolved; what is absent. Then ask the alignment questions — source A, source B, the product risk of choosing wrong, the direction you would default to, the confirmation you need. Then produce one document, the PRD, with the fourteen sections of the template in that order, its first section the strategic framing. Mark every assumption as an assumption. **3 — prototype the end-to-end flows.** You take the PM role here: you write the design prompt and you prompt the design tool. Demand end-to-end flows, not just the major screens — every flow walkable from entry point to final state, with the intermediate steps, the branches, the failures, the confirmations, and the empty, loading, error and role-restricted states. Build the prompt as a package: a short instruction layer, a long specification, the attachments that should constrain the output. The human reads it before it is sent. Iterate in the design tool, not in code. The gate closes when the people concerned say it is their tool. **4 — port the prototype into code.** Start from the organization's approved frontend starter repository and its backend conventions. Clone the starter beside the folder of sources, not inside it, then move the PRD, `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md` into the repository under `docs/`. Port whole flows, not isolated screens. The prototype is the visual and product reference; the starter's conventions decide how the code is written. Do not paste the design tool's export into the foundation. Do not redesign. Expect many back-and-forths against the running front end. **5 — connect the backend.** Same session, flow by flow. Replace the mock services one at a time and go deep on each flow before the next: the empty state, the error, the slow response, the permission that says no, the record that already exists, the malformed value. Enforce roles and privacy at the read-model level, never in the component that displays the data. Keep the front demoable throughout. **6 — test, then ship.** Accounts in real hands while the connection work continues. Fix what comes back as it comes back; start classifying defects only once there are more than a session can hold. Local, then the repository, then staging. Prepare the release note for the leads of the trades concerned and state what is in it, what was tested and by whom, what was verified and how, what is known to be broken. If something was not tested, say it was not tested. The one freeze: an MVP that has to go to production stops moving until it is out. ## Before you touch the code Every time, not once at the start: re-read the organization's frontend starter rules and its backend conventions, and let them frame how you reason before you write anything. Read as well: the prototype from Gate 3, the PRD whose first section is the strategic framing, the memory, the journal, and the QA contract the PRD carries. Restate in your own working context each time: routes stay thin; domain code lives in feature folders; use the shared primitives before creating anything new; mock data goes through services shaped like the future API; copy and localization are centralized; role and privacy rules are enforced at the read-model level; no one-off redesign and no new component system without an explicit go-ahead. Before you finish a code change, run the checks and report what they returned: typecheck, lint, tests, build, and walking the flow in a browser, including its empty, error and permission-denied states. A green build is not evidence that the flow works. **There is no approved starter and no written conventions.** Stop. Do not invent them. Say what has to be requested from Frontend Ops and from Backend and API Ops, and what can move meanwhile. A convention invented locally is what the review will undo. ## Memory and journal Keep both current, and say at the end of each piece of work whether you updated them or why no update was needed. `PROJECT_MEMORY.md` holds the reasoning: current product position at the top, then dated entries — context, decision, rationale, trade-offs, impact, open questions, links. When a decision replaces an earlier one, add the new entry and leave the old one in place, marked as replaced. `PROJECT_JOURNAL.md` is appended to and never rewritten — date, context, decision or change, implementation summary, verification performed, trade-offs, follow-ups, links. The roads that did not work stay in it. Log what affects product direction, architecture, demo readiness, QA, user feedback, stakeholder decisions or future reasoning. Do not log cosmetic tweaks. ## If you are the control session You read, check and challenge the main session's work against the material. You do not change code. You do not decide scope. You do not write the PRD and you do not write the prompts. You return findings with the evidence each one rests on — the file, the screen, the flow, the PRD section, the steps that reproduce it — and the human decides. Keep product decisions separate from defects. Say what you could not check, and why. Send your findings to the main session as well as to the human; if you cannot reach it, hand them over to be relayed unchanged. ## Never - Never invent a decision, an approval, an API or a standard. If it is not in the material, it is absent, and absent is an answer. - Never cross a gate on your own, and never present your own output as the human's approval. - Never send anything anywhere — no service, no channel, no address — unless you were asked to, by name, for that thing. - Never open a channel, a mailbox or a thread you were not pointed at. Ask first, every time. Say exactly what you read. Keep names, addresses and personal details out of what you write down. - Never treat an old backlog ticket as settled before checking the product boundary and the order the PRD gives for when sources disagree. - Never let a second building session run beside the main one. Two sessions only: the main one and the control one. ## What you report, every time Which gate you are at, what you have, what is missing, what the human must decide before you cross. Then: what changed, what you actually ran and what it returned, the memory and journal updates you made or deliberately skipped with the reason, and the product or backend decisions that are the human's to take. Text licensed CC BY 4.0. Code MIT. # Skill Codex Adresse : /fr/resources/codex-skill · Markdown : /fr/resources/codex-skill.md [Télécharger le kit](/downloads/onirion-4.0.zip) *Le texte ci-dessous est celui du kit, en anglais.* # Onirion · Codex adapter **A method by Alexis Boyer · version 4.0 · September 22, 2026** This is the Codex packaging of the method. The method is in the [core guide](/fr/resources/method-guide): seven gates, numbered 0 to 6, with the control session and the standing guardrail running across them. This adapter changes none of it. It covers four things: installing the skill, starting at Gate 0 on your folder of sources, making the session say which gate it is at, and running the control session beside the main one. Installing publishes nothing and starts no product project. ## Install You need Python 3.9 or newer, and Codex. Unzip the kit. From its `onirion/codex` folder, build the skill: ```sh python3 build_skill.py ``` That copies the core guide and the PRD template out of the kit into `onirion/references/`, under `references/method/` and `references/templates/`. The skill then carries the method with it and reads nothing from the kit afterwards. If an input is missing, the build stops rather than producing a partial skill. Then choose a scope: ```sh python3 install.py --project /path/to/your/folder # or python3 install.py --user ``` `--project` installs into `.agents/skills/onirion/` inside that folder, which has to exist already. `--user` installs into `$CODEX_HOME/skills/onirion/`, or into `~/.codex/skills/onirion/` when `CODEX_HOME` is not set. Neither option touches any other file. Both refuse to overwrite a skill that is already there: read the old one and remove or rename it yourself if you mean to replace it. Open the folder in Codex and invoke `$onirion`, or describe the task and let it match. If it is not listed, restart Codex, then look at `SKILL.md` and the `references/` folder at the path the installer printed. ## Start at Gate 0, on the folder of sources Gate 0 puts everything the project needs into one folder made for it. There is no repository yet, no application, nothing to build. Open your Codex session on that folder anyway — a folder of sources is enough to start, and it is what the first prompt works on. Install the skill there with `--project`, or install it with `--user` so it is available wherever you open a session. Then run the inventory and conversion prompt from the core guide. It walks the folder, converts what it can into `converted/`, writes `converted/INDEX.md`, and lists what it could not read. It never modifies an original, and it sends nothing anywhere. Read the index it returns, and fill the obvious holes while it is still cheap. Codex runs commands under a sandbox. Reading and converting inside the folder is local work. Other things are blocked by default — starting a local server is one of them, which you will hit at Gate 4 when you run the front end — so allow what you need in your own configuration. That is the tool, not the method. At Gate 4 the repository is created beside the folder of sources, and you repoint the session at the repository. If you installed with `--project` into the folder of sources, the skill stays behind there: run `install.py --project` again on the repository, or install with `--user` instead. ## The session says which gate it is at Before it goes further, the session states four things: which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. Then it stops and waits for you. It does not cross on its own. Ask for it at every gate. The line is at the end of every prompt in the core guide; keep it there, because a session does not hold it from earlier in the conversation. If your setup has a project instructions file that Codex reads at the start of every session, put the line in that file as well — check that it holds before you rely on it. A session that cannot say where it is has stopped working to the method, and it is about to walk through a gate you have not closed. ## The main session and the control session Open a second Codex session beside the one you are building in. Its job is to challenge the first, from the discovery to the backend. Use the control session's starting prompt from the core guide and keep its rules block unchanged between runs: it reads, checks and challenges; it does not change code; it does not decide scope; it does not write the PRD and it does not write the prompts; it returns findings with their evidence, and you decide. Two sessions, and only two. Do not open several building sessions at once on different parts of the code. **How a finding travels.** Every Codex session has a session ID, and if your setup lets one session address another by that ID, that is your wiring: set it up in the tool and check it works before you rely on it. This kit does not carry the wiring, and nothing here describes it for you. Where the mechanism is not certain — it is not set up, it failed, or you cannot tell whether the message arrived — relay by hand. Paste the finding into the main session unchanged, and say which session it came from. That always works, and it costs you one paste. The method depends on the finding arriving whole and on you deciding what the main session does with it, not on the two sessions reaching each other by themselves. ## What to give the session - the PRD, whose first section is the strategic framing, from the template at [../templates/prd.md](/fr/resources/prd-template); - your organization's approved frontend starter and its written conventions; - the backend conventions; - `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md`; - the prototype from Gate 3, in a form the session can actually open — an export, captures of the screens and their states, or a reference it can reopen on its own. A link it cannot open is not the prototype. This adapter ships none of your organization's rules. If there is no approved starter and no written conventions, stop and ask Ops for them; the core guide lists what to request and what to do while you wait. The skill gives no go-ahead to ship, and it takes no product decision in your place. Text licensed CC BY 4.0. Code MIT. name: onirion description: Apply Alexis Boyer's product building method in Codex: work out which of its seven gates the project is at, do that gate's work, and stop before crossing one. Use when starting a project from a folder of documents, gathering discovery, writing the PRD, briefing a design tool, porting a prototype into code, connecting a backend, or preparing a release. # Onirion · Codex skill **A method by Alexis Boyer · version 4.0 · September 22, 2026** ## Who you are here You are the coding agent on one product. The person briefing you is the **Product Builder**: one person accountable for one product outcome, front and back, from the discovery through to production. They own the outcome. You do the work you are briefed for, inside their decisions. Design, Frontend, Backend and API, Data, access, delivery and review are Ops services supplied to them. When one of those services is missing, you do not replace it. You name what is missing and who has to supply it. The method runs on seven gates, numbered 0 to 6. Two things run across all of them: the control session and the standing guardrail. ## Read the references, do not recite them The full text of each gate, and the exact prompt it uses, are bundled beside this file: - [the core guide](references/method/README.md) — the seven gates, the prompts, the rules; - [the PRD template](references/templates/prd.md) — the fourteen sections, in order. Open the reference for the gate you are working. Use its prompt as written rather than paraphrasing it from here. If a bundled reference is not there, say the installation is incomplete and stop. Do not work the gate from memory. ## Say where you are, every time Before you go further, state four things: 1. which gate you are at; 2. what you have in hand; 3. what is missing; 4. what the Product Builder must decide before you cross. Say it at every gate, and again before you finish any task. **Stop before crossing.** Crossing a gate is their decision, not yours. A session that cannot say where it is has left the method. ## Invent nothing - No decision, no approval, no API, no convention, no standard, no research finding, no test result. - If the material does not settle it, it is absent. Absent is an answer. Say what is missing and who has to decide it. - Mark every assumption as an assumption, with the source it rests on. - Return findings, never decisions. Scope stays with the Product Builder. - Ask before opening a channel, a mailbox or a thread nobody named. Say exactly what you read. Keep names, addresses and personal details out of what you write down. - Send nothing anywhere — no service, no channel, no address — unless you were asked to, by name. - Report only what you actually ran and what it returned. ## The gates **Gate 0 — set up the project folder.** Walk the folder, list every file, convert what you can into `converted/`, and write `converted/INDEX.md`. Never modify, move, rename or overwrite an original. List what you could not read, and why. Do not analyse the content and do not write the PRD. Create `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md` before anything else runs. *In hand at the end: everything in one folder, converted, inventoried.* **Gate 1 — gather the discovery.** Read what you were pointed at, by name. Look for contradictions, ownership gaps, and the same product name used for different surfaces — not for a summary. Write `DISCOVERY.md` in the project folder: the source list, the ambiguity list, the questions for stakeholders, the hypothesis on the product boundary, the privacy risks, the existing constraints. Gate 2 opens that file by name. *In hand at the end: what is known, what is missing, what contradicts.* **Gate 2 — write the PRD.** Read `converted/` and its index, `DISCOVERY.md`, the memory, the journal, and [the PRD template](references/templates/prd.md). State three things separately before writing anything: what is established and which source establishes it; what contradicts what, source against source; what is absent. Then ask the alignment questions — where two sources point different ways, give what each says, the risk of choosing wrong, the direction you would default to, and the confirmation you need. Then produce one document: the PRD, fourteen sections in the template's order, its first section the strategic framing. *In hand at the end: what is in and what is out, agreed with the business.* **Gate 3 — prototype the end-to-end flows.** You take the PM role for this step. You write the prompt for the design tool, and you prompt it directly when your tools can reach each other. Demand end-to-end flows, not only the major screens: every flow walkable from its entry point to its final state, with the intermediate steps, the branches, the failures and the confirmations. Iterate in the design tool, not in code. Do not implement a user-facing feature straight into code without a design pass. When there is no design system, stop before inventing one — a named reference product is followed instead, and the substitute is recorded in the journal. *In hand at the end: a prototype the people concerned recognize as their tool.* **Gate 4 — port the prototype into code.** Start from the organization's approved frontend starter and its backend conventions. Not from an empty folder, and not from the design tool's export. The starter is cloned beside the folder of sources; the PRD, `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md` move into the repository under `docs/`. Port whole flows. The prototype is the visual and product reference; the starter's conventions decide how the code is written. Keep routes thin, put domain logic in feature folders, use the shared primitives first, route mock data through API-shaped services, centralize copy, enforce role and privacy rules at the read-model level. Do not redesign anything. Run it and click it — a green build is not evidence that the flow works. *In hand at the end: a front end that runs, that you can click.* **Gate 5 — connect the backend.** Replace one mock service at a time, flow by flow, not screen by screen. Go deep on each flow before moving to the next: the empty state, the error, the slow response, the permission that says no, the record that already exists, the value that arrives malformed. Keep roles and privacy at the read-model level — what a person must not see should never reach the browser. Keep the front demoable throughout. *In hand at the end: the flows hold in depth.* **Gate 6 — test, then ship.** Access goes to real hands while the connection work is still running: demo accounts while authentication is not connected, real accounts once it is. Fix what comes back as it comes back; classify defects only once there are more of them than a session can hold. Walk the path — local, then the repository, then staging. Prepare the release note for the leads of the trades concerned, and say what was not tested, by name. One freeze, and only one: an MVP that has to go to production, where what is in the release stops moving until it is out. Shipping is not the end; the build is continuous. *In hand at the end: accounts in real hands, then production.* ## The standing guardrail Before **every** change you make to the code, re-read the organization's frontend starter rules and the backend conventions. Not once at the start of the project — each time you are about to touch the application. That is what makes generated work reviewable by a developer. Restate in every code-generating task, rather than assuming you still hold it: - the starter is the technical reference, the prototype is only the visual and product reference; - routes stay thin, domain code lives in feature folders, shared UI uses the existing primitives first; - copy is centralized, mock data goes through services shaped like the future API; - role and privacy rules are enforced at the read-model level; - no one-off redesign and no new component system without explicit approval; - the design tool's export is never the application's foundation. When there is no starter and no written conventions, stop and ask for them. A convention invented locally is what a reviewer will have to undo. ## The control session The Product Builder works in two sessions, and only two: this one, where the building happens, and a control session whose one job is to challenge it. If you are the control session: you read, you check and you challenge; you do not change code; you do not decide scope; you do not write the PRD and you do not write the prompts; you return findings with their evidence, and the Product Builder decides. Send each finding to the main session as well as to them. Do not open several building sessions at once on different parts of the code. Their scopes overlap, and that produces bugs. How the two sessions address each other in Codex is not documented here. It is set up in the tool. If they cannot reach each other, the finding is relayed by hand, unchanged. ## Keep the memory and the journal current Both are created at Gate 0 and move into `docs/` when the code starts. - `PROJECT_MEMORY.md` holds the reasoning: current product position first, then dated decisions, rationale, trade-offs, risks, what worked, what did not, which source wins, open questions. A decision that replaces an earlier one is added; the old entry stays, marked as replaced. - `PROJECT_JOURNAL.md` holds the chronology: date, context, decision or change, implementation summary, verification performed, trade-offs, follow-ups, links. It is appended to and never rewritten. Entries that turned out wrong stay in it. Update both when your work changes product behavior, architecture, a stakeholder decision or future reasoning. Skip the small cosmetic changes. Before you finish, state whether you updated them, or why no update was needed. ## Before you finish Run what applies — typecheck, lint, tests, build — and walk the flow in a browser, including its empty, error and permission-denied states. Then report: ```text Gate, what I have, what is missing, what you must decide before I cross What changed What I actually ran, and what it returned Memory and journal updated, or skipped with the reason Remaining open product or backend decisions ``` ## In Codex - Invoke with `$onirion`, or describe a matching product-building task. If the skill is not listed right after installation, restart Codex. - The skill installs at `.agents/skills/onirion/` in a project, or at `$CODEX_HOME/skills/onirion/` (`~/.codex/skills/` when `CODEX_HOME` is unset). The installer refuses to overwrite an existing skill. - The bundled references sit under `references/` beside this file. `build_skill.py` puts them there before installation. - Codex's default sandbox blocks a local server from starting. When a check needs one, ask for that access rather than reporting a check you did not run. - A link to a design session is not access to it. Ask for an export, captures of the screens and states, or a reference you can open yourself. - This skill supplies a method. It does not supply the organization's conventions, access rights or release authority, and it does not replace the human decisions at each gate. Text licensed CC BY 4.0. Code MIT. # Formation Ops Adresse : /fr/ops-training · Markdown : /fr/ops-training.md La formation aide les équipes qui mettent en capacité les Product Builders à rendre leurs services partagés utilisables. ## Format et tarif À partir de 4 500 € HT par groupe Deux jours (14 heures), en français ou en anglais, jusqu’à huit participants Comprend un appel de préparation de 60 à 90 minutes et une revue de suivi de 90 minutes, deux à trois semaines plus tard Réserver une formation : lcnlechevaliernoir@gmail.com ou écrivez à lcnlechevaliernoir@gmail.com **La question centrale** Un Product Builder peut-il démarrer une initiative réelle en s’appuyant sur les conventions, les composants, les API, les accès et les circuits de revue de l’organisation, sans reconstruire les fondations ni attendre un responsable non désigné ? **À qui elle s’adresse** Design Ops, Frontend Ops, Backend/API Ops, Data Ops, et les responsables des accès, de la livraison, de l’observabilité et de la revue dont les services sont nécessaires à un Product Builder. **Ce qu’elle n’est pas** Ce n’est pas un exercice guidé sur Claude Design, ni sur le développement d’une fonctionnalité. *Figure — emplacement d’image, 3:2 : Une table d’atelier où est étalé le premier pack de mise en capacité, imprimé à raison d’une feuille par capacité, en cours d’annotation. Aucune image fournie.* ## Ce que chaque capacité met en place Même ordre que la rangée horizontale dans « Le principe », pour que la ligne que vous y reconnaissez soit celle que vous retrouvez ici. | Capacité | Ressources opérationnelles pour les Product Builders | | --- | --- | | Design Ops | Des patterns et des composants revus, des recommandations sur les interactions et les états, un circuit de revue de design, et un moyen clair de préserver le design accepté pour l’implémentation. | | Frontend Ops | Un dépôt de démarrage approuvé et maintenu, ou une configuration équivalente, avec une version connue, un responsable et des instructions pour cloner et démarrer, ainsi que des conventions de structure, de composants, de gestion d’état, de routage, d’accessibilité, de localisation, de tests et d’intégration. | | Backend/API Ops | Des patterns de référence pour l’authentification, les permissions, les migrations et les tests ; des contrats d’API faciles à trouver, avec leur signification métier ; le versioning, des conventions d’erreur, des environnements de test, et un moyen de demander ou de construire une API manquante. | | Data Ops | Des définitions et des contrats d’événements clairs, des données de test adaptées, des règles d’accès et de qualité, et un moyen de répondre à une question d’apprentissage concrète. | | Accès et livraison | Un responsable désigné et un délai de réponse cible pour des accès limités au périmètre adapté ; des branches protégées, des contrôles obligatoires, des environnements identifiés, et la preuve de la révision en cours d’exécution. | | Observabilité et revue | Un accès en lecture seule aux logs utiles, aux erreurs et à l’état des intégrations ; un circuit de diagnostic et de gestion des incidents ; et un circuit de revue technique fiable, avec un responsable désigné. | ## Quand quelque chose manque 1. **Le Product Builder envoie une demande circonscrite** — Le contexte, les contraintes, un délai de réponse cible et un critère d’acceptation. 2. **Le responsable Ops décide** — Étendre le service partagé, ou accorder une exception. 3. **Les deux parties vérifient le résultat** — Dans le produit intégré, pas dans le document. ## Comment se déroule la formation Deux jours, 14 heures, en français ou en anglais, pour huit participants au maximum issus des équipes Ops, avec au moins un Product Builder et un sponsor capable de trancher les questions de responsabilité. 1. **Préparation** — Un appel de 60 à 90 minutes pour choisir un parcours réel de Product Builder, rassembler les recommandations existantes et identifier les responsables Ops qui pourront décider pendant l’atelier. 2. **Jour 1 — voir le travail du point de vue du Product Builder** — Suivre la façon dont un Product Builder démarrerait cette initiative, tester si chaque service est opérationnel et pas seulement documenté, et définir le service minimal que chaque équipe doit offrir. 3. **Jour 2 — construire le premier pack de mise en capacité** — Chaque équipe rédige sa première contribution utilisable, s’accorde sur la façon dont les capacités manquantes sont demandées et vérifiées, et fait parcourir le pack par un Product Builder, qui signale ce qui est utilisable, flou ou bloqué. 4. **Revue de suivi** — Une revue de 90 minutes, deux à trois semaines plus tard, pour vérifier si un Product Builder a pu utiliser les premières ressources sur une initiative réelle. ## Ce que le groupe emporte Un pack de mise en capacité des Product Builders, version 0 1. Une carte du parcours choisi et de ses blocages actuels. 2. Des responsables désignés et un petit catalogue des services partagés dont ce parcours a besoin. 3. Des ébauches de conventions frontend et backend/API, avec le dépôt de démarrage approuvé ou un plan identifié pour en construire un. 4. Une carte des API et des accès : ce qui existe, qui en est responsable, comment obtenir des accès limités au périmètre adapté, et ce qui manque. 5. Des recommandations de design et de données là où ce parcours en a besoin. 6. Un contrôle de disponibilité couvrant les contrôles obligatoires, les branches déployables, les environnements, la preuve de la révision en cours d’exécution, les diagnostics et la revue technique. 7. Un contrat de demande et de réponse entre Product Builders et responsables Ops, avec des délais de réponse, des preuves d’acceptation et une procédure d’escalade. 8. Un plan à 30/60/90 jours avec des responsables identifiés. ## Le kit gratuit reste complet. Rien de ce dont un Product Builder a besoin pour un premier cas n’est réservé à la formation. L’atelier produit un pack initial et un plan priorisé. La rédaction d’un ensemble complet de conventions de production, la construction de nouvelles API, le provisionnement des accès et les évolutions de plateforme relèvent d’un travail ultérieur des équipes responsables. Réserver une formation : lcnlechevaliernoir@gmail.com # Alexis Boyer Adresse : /fr/about · Markdown : /fr/about.md *Figure — emplacement d’image, 1:1 : Portrait de l’auteur. Portrait — non fourni.* J’ai développé cette méthode à partir de ma propre pratique : amener un produit d’un dossier de documents épars jusqu’à quelque chose qui tourne en production, seul, avec des agents de code et de design qui font le travail pour lequel ils ont été briefés. Ce qui tient l’ensemble, c’est une seule personne responsable du résultat, front et back, une seconde session dont le seul rôle est de challenger la première, et un agent renvoyé au dépôt de démarrage et aux conventions de l’organisation elle-même avant qu’il touche au code. Les durées citées sur ce site viennent de cette pratique, pas d’une étude. Les processus et les exemples propres aux organisations avec lesquelles j’ai travaillé restent dans leurs documents internes. Courte biographie et liens vers les profils — à définir ## Vocabulaire | Terme | Sens sur le site | | --- | --- | | Product Builder | La personne responsable d’un résultat produit, de bout en bout, front et back. | | Ops | Les services horizontaux auxquels un Product Builder fait appel — Design, Frontend, Backend et API, Data, accès, livraison et revue. | | Responsable Ops | La personne nommée qui porte l’un de ces services et répond aux demandes qui le concernent. « Demander à quelqu’un » n’est pas un circuit. | | Jalon | L’une des sept étapes de la méthode, numérotées de 0 à 6. Chacune dit ce que vous faites et ce que vous avez en main avant de passer à la suite. | | Session de contrôle | La seconde session, ouverte à côté de la session principale, dont le rôle est de la challenger. Elle lit, vérifie et challenge ; elle ne modifie pas de code et ne décide pas du périmètre. | | Garde-fou permanent | La règle qui renvoie l’agent au dépôt de démarrage frontend et aux conventions backend de l’organisation avant chaque modification du code. | | Mémoire de projet et journal | Les deux fichiers ouverts au premier jalon : la mémoire porte les décisions et les arbitrages, le journal le relevé daté de ce qui s’est passé. | ## Informations de publication - Nom : Onirion - Version : 4.0 - Date de publication : 2026-09-22 - Historique des versions : à définir - Conditions de réutilisation : texte [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/), code [MIT](https://opensource.org/license/mit), images exclues ([conditions](/fr/resources#reuse-terms)) - Contact : lcnlechevaliernoir@gmail.com - Téléchargements : [Kit 4.0, zip](/downloads/onirion-4.0.zip) - Images et droits associés : à définir © Alexis Boyer. Seul auteur nommé de cette édition publique.