devmethod-ai 0.1.0 → 0.2.0

package/docs/media/full-chain-4k/scenes.json

@@ -0,0 +1,173 @@
+[
+  {
+    "kind": "title",
+    "title": "DevMethod, du projet vide au produit vérifié",
+    "voice": "Dans cette démonstration, nous allons suivre toute la chaîne de Dev Method. Vous verrez les commandes adressées à Codex, ses réponses réelles et la prochaine étape proposée. Nous prendrons aussi le temps de regarder la direction artistique, le master screen et l'application finale. Les transcriptions de Codex sont réelles. Leur mise en page est adaptée au film pour rester lisible en quatre K. Les temps d'attente sont retirés.",
+    "stage": null,
+    "image": null,
+    "speech": "Dans cette démonstration, nous allons suivre toute la chaîne de Dev Method. Vous verrez les commandes adressées à Codex, ses réponses réelles et la prochaine étape proposée. Nous prendrons aussi le temps de regarder la direction artistique, le master screen et l'application finale. Les transcriptions de Codex sont réelles. Leur mise en page est adaptée au film pour rester lisible en quatre K. Les temps d'attente sont retirés.",
+    "duration": 29.913469
+  },
+  {
+    "kind": "install",
+    "title": "Un dossier neuf, un kit installé",
+    "voice": "Nous commençons dans un dossier sans code d'application. L'installation y dépose les compétences de la méthode. Dev Method est le nom du produit, mais sa commande d'entrée actuelle s'appelle project foundation. Elle se saisit dans la conversation de l'agent, pas comme une commande du terminal. Pour ce film, nous utilisons Codex CLI. Un premier essai incompatible avec la version du modèle a été conservé dans les journaux, puis corrigé.",
+    "stage": null,
+    "image": null,
+    "speech": "Nous commençons dans un dossier sans code d'application. L'installation y dépose les compétences de la méthode. Dev Method est le nom du produit, mais sa commande d'entrée actuelle s'appelle project foundation. Elle se saisit dans la conversation de l'agent, pas comme une commande du terminal. Pour ce film, nous utilisons Codex CLI. Un premier essai incompatible avec la version du modèle a été conservé dans les journaux, puis corrigé.",
+    "duration": 31.643356
+  },
+  {
+    "kind": "terminal",
+    "title": "Explorer le besoin",
+    "voice": "La première commande est project foundation explore. Nous donnons le besoin : une bibliothèque personnelle pour suivre ses lectures. Codex examine le brief et les sources disponibles. À ce stade, il ne doit pas coder. Il distingue ce qui est décidé de ce qui reste à préciser. Regardez la fin de la réponse : elle indique la commande recommandée pour continuer. La méthode transmet ainsi le contexte d'une étape à la suivante.",
+    "stage": "01",
+    "image": null,
+    "speech": "La première commande est project foundation explore. Nous donnons le besoin : une bibliothèque personnelle pour suivre ses lectures. Codex examine le brief et les sources disponibles. À ce stade, il ne doit pas coder. Il distingue ce qui est décidé de ce qui reste à préciser. Regardez la fin de la réponse : elle indique la commande recommandée pour continuer. La méthode transmet ainsi le contexte d'une étape à la suivante.",
+    "duration": 31.411156
+  },
+  {
+    "kind": "terminal",
+    "title": "Cadrer une première livraison",
+    "voice": "Nous envoyons ensuite frame. Le cadrage transforme l'idée en un résultat limité et vérifiable. Ajouter un livre, filtrer la bibliothèque et changer son statut font partie du besoin. Un service de lecture de livres, des comptes ou un serveur ne sont pas inclus. Ces exclusions comptent : elles évitent que l'agent construise un produit plus vaste que celui demandé. Le cadrage prépare aussi les critères qui serviront aux tests.",
+    "stage": "02",
+    "image": null,
+    "speech": "Nous envoyons ensuite frame. Le cadrage transforme l'idée en un résultat limité et vérifiable. Ajouter un livre, filtrer la bibliothèque et changer son statut font partie du besoin. Un service de lecture de livres, des comptes ou un serveur ne sont pas inclus. Ces exclusions comptent : elles évitent que l'agent construise un produit plus vaste que celui demandé. Le cadrage prépare aussi les critères qui serviront aux tests.",
+    "duration": 30.935147
+  },
+  {
+    "kind": "directions",
+    "title": "Trois directions, un même produit",
+    "voice": "Avant de développer l'interface, nous comparons trois directions appliquées au même contenu. Éditorial privilégie la typographie et l'espace. Atelier mise sur une organisation compacte. Botanique apporte des illustrations et une ambiance plus douce. Cette planche a réellement été générée pendant la session préparatoire. Ce ne sont pas trois applications terminées, mais trois propositions visuelles. Les mettre côte à côte rend le choix concret, plutôt que de demander seulement une préférence abstraite.",
+    "stage": null,
+    "image": "directions-v1.png",
+    "speech": "Avant de développer l'interface, nous comparons trois directions appliquées au même contenu. Éditorial privilégie la typographie et l'espace. Atelier mise sur une organisation compacte. Botanique apporte des illustrations et une ambiance plus douce. Cette planche a réellement été générée pendant la session préparatoire. Ce ne sont pas trois applications terminées, mais trois propositions visuelles. Les mettre côte à côte rend le choix concret, plutôt que de demander seulement une préférence abstraite.",
+    "duration": 36.635646
+  },
+  {
+    "kind": "choice",
+    "title": "Le choix humain : A — Éditorial",
+    "voice": "L'utilisateur a répondu A. C'est le choix réel conservé de notre session précédente, pas une réponse inventée pour la vidéo. Nous retenons donc la direction éditoriale. Ce choix fixe une intention : fond ivoire, contraste encre, accents rouille et titres avec empattements. Il ne suffit pas encore à valider tous les détails d'un écran. L'étape suivante consiste à produire une référence plus précise, que l'on peut examiner avant de coder.",
+    "stage": null,
+    "image": "directions-v1.png",
+    "speech": "L'utilisateur a répondu A. C'est le choix réel conservé de notre session précédente, pas une réponse inventée pour la vidéo. Nous retenons donc la direction éditoriale. Ce choix fixe une intention : fond ivoire, contraste encre, accents rouille et titres avec empattements. Il ne suffit pas encore à valider tous les détails d'un écran. L'étape suivante consiste à produire une référence plus précise, que l'on peut examiner avant de coder.",
+    "duration": 32.339955
+  },
+  {
+    "kind": "master",
+    "title": "Le master screen devient la référence",
+    "voice": "Voici le master screen détaillé, sur ordinateur et sur mobile. Nous pouvons maintenant examiner la hiérarchie, les cartes, les espacements et les boutons. Le libellé Lire a été remplacé par Commencer ou Marquer terminé, car le produit suit la lecture sans fournir le texte des livres. L'utilisateur a ensuite validé cette maquette par un oui. Cette référence approuvée est réutilisée dans la nouvelle implémentation. Elle sera le point de comparaison à la fin, et non une simple image d'inspiration.",
+    "stage": null,
+    "image": "editorial-mockup-v1.png",
+    "speech": "Voici le master screen détaillé, sur ordinateur et sur mobile. Nous pouvons maintenant examiner la hiérarchie, les cartes, les espacements et les boutons. Le libellé Lire a été remplacé par Commencer ou Marquer terminé, car le produit suit la lecture sans fournir le texte des livres. L'utilisateur a ensuite validé cette maquette par un oui. Cette référence approuvée est réutilisée dans la nouvelle implémentation. Elle sera le point de comparaison à la fin, et non une simple image d'inspiration.",
+    "duration": 35.764898
+  },
+  {
+    "kind": "terminal",
+    "title": "Design : préciser ce que l’image ne dit pas",
+    "voice": "La commande design relie la référence aux comportements attendus. Une image ne décrit pas à elle seule la validation du formulaire, le clavier, un filtre vide ou un échec de sauvegarde. Codex doit préciser ces états, identifier la référence choisie et préserver les décisions existantes. La génération d'images dépend des outils disponibles dans l'environnement. Dev Method organise ce travail, mais son installation ne fournit pas un moteur d'image.",
+    "stage": "03",
+    "image": null,
+    "speech": "La commande design relie la référence aux comportements attendus. Une image ne décrit pas à elle seule la validation du formulaire, le clavier, un filtre vide ou un échec de sauvegarde. Codex doit préciser ces états, identifier la référence choisie et préserver les décisions existantes. La génération d'images dépend des outils disponibles dans l'environnement. Dev Method organise ce travail, mais son installation ne fournit pas un moteur d'image.",
+    "duration": 33.651882
+  },
+  {
+    "kind": "terminal",
+    "title": "Architecture : rester proportionné",
+    "voice": "L'architecture choisit le minimum nécessaire au besoin. Ici, une application statique et un stockage dans le navigateur suffisent. La logique peut être testée séparément des éléments visuels. Cette étape n'a pas pour objectif d'accumuler des technologies. Elle permet de clarifier les frontières et les limites avant l'implémentation. Une évolution ultérieure vers plusieurs utilisateurs demanderait d'autres décisions ; elle ne fait pas partie de ce film.",
+    "stage": "04",
+    "image": null,
+    "speech": "L'architecture choisit le minimum nécessaire au besoin. Ici, une application statique et un stockage dans le navigateur suffisent. La logique peut être testée séparément des éléments visuels. Cette étape n'a pas pour objectif d'accumuler des technologies. Elle permet de clarifier les frontières et les limites avant l'implémentation. Une évolution ultérieure vers plusieurs utilisateurs demanderait d'autres décisions ; elle ne fait pas partie de ce film.",
+    "duration": 32.084535
+  },
+  {
+    "kind": "terminal",
+    "title": "Plan : une tranche avec des critères",
+    "voice": "La commande plan découpe le périmètre en travail réalisable. Pour ce petit produit, une première tranche peut réunir le parcours utile de bout en bout. Le plan doit contenir un objectif, des critères d'acceptation, les dépendances et les vérifications prévues. Une ligne marquée prête n'est pas une preuve que le code existe. Les statuts doivent rester reliés aux faits et aux résultats réellement observés.",
+    "stage": "05",
+    "image": null,
+    "speech": "La commande plan découpe le périmètre en travail réalisable. Pour ce petit produit, une première tranche peut réunir le parcours utile de bout en bout. Le plan doit contenir un objectif, des critères d'acceptation, les dépendances et les vérifications prévues. Une ligne marquée prête n'est pas une preuve que le code existe. Les statuts doivent rester reliés aux faits et aux résultats réellement observés.",
+    "duration": 28.949841
+  },
+  {
+    "kind": "terminal",
+    "title": "Ready : vérifier avant de construire",
+    "voice": "Ready contrôle que la tranche est assez précise pour être implémentée. Les sources sont-elles disponibles ? Les comportements importants sont-ils décidés ? Les tests ont-ils un sens ? Dans le parcours filmé, nous montrons cette commande séparément pour l'expliquer. Pour une petite correction déjà claire, Dev Method permet aussi de regrouper cette préparation avec l'implémentation, sans imposer une conversation supplémentaire à chaque étape.",
+    "stage": "06",
+    "image": null,
+    "speech": "Ready contrôle que la tranche est assez précise pour être implémentée. Les sources sont-elles disponibles ? Les comportements importants sont-ils décidés ? Les tests ont-ils un sens ? Dans le parcours filmé, nous montrons cette commande séparément pour l'expliquer. Pour une petite correction déjà claire, Dev Method permet aussi de regrouper cette préparation avec l'implémentation, sans imposer une conversation supplémentaire à chaque étape.",
+    "duration": 31.562086
+  },
+  {
+    "kind": "terminal",
+    "title": "Implement : produire du code et des preuves",
+    "voice": "Nous autorisons maintenant implement. Codex réalise l'application à partir du brief et du master screen. Aucun code de la première démonstration ne lui a été fourni. Les attentes de calcul et d'écriture sont retirées du montage ; la réponse montrée provient de l'exécution réelle. Regardez ce que l'agent dit avoir vérifié, mais aussi ce qu'il laisse explicitement à vérifier. Un résultat local doit rester distinct d'un déploiement.",
+    "stage": "07",
+    "image": null,
+    "speech": "Nous autorisons maintenant implement. Codex réalise l'application à partir du brief et du master screen. Aucun code de la première démonstration ne lui a été fourni. Les attentes de calcul et d'écriture sont retirées du montage ; la réponse montrée provient de l'exécution réelle. Regardez ce que l'agent dit avoir vérifié, mais aussi ce qu'il laisse explicitement à vérifier. Un résultat local doit rester distinct d'un déploiement.",
+    "duration": 31.399546
+  },
+  {
+    "kind": "terminal",
+    "title": "Review : examiner la réalisation",
+    "voice": "La revue confronte les fichiers réalisés aux critères de la tranche. Elle cherche des défauts concrets, pas seulement une liste de bonnes pratiques. Nous conservons le résultat de cette revue, y compris ses limites. Si une correction est nécessaire, elle doit être effectuée puis revérifiée. Le fait que l'agent relise son travail ne permet pas de prétendre à une validation indépendante universelle.",
+    "stage": "08",
+    "image": null,
+    "speech": "La revue confronte les fichiers réalisés aux critères de la tranche. Elle cherche des défauts concrets, pas seulement une liste de bonnes pratiques. Nous conservons le résultat de cette revue, y compris ses limites. Si une correction est nécessaire, elle doit être effectuée puis revérifiée. Le fait que l'agent relise son travail ne permet pas de prétendre à une validation indépendante universelle.",
+    "duration": 28.299683
+  },
+  {
+    "kind": "terminal",
+    "title": "Corriger les défauts réellement trouvés",
+    "stage": "08b",
+    "image": null,
+    "voice": "La revue a trouvé des défauts concrets. Un ajout pouvait écraser des données qui n’avaient pas été chargées. Deux autres points concernaient la création des identifiants et les caractères Unicode. Nous envoyons donc une nouvelle commande implement avec ces constats. Nous demandons aussi de rétablir les couvertures de la référence approuvée. Cette boucle fait partie de la chaîne réelle : une première implémentation n’est pas automatiquement une livraison acceptée.",
+    "speech": "La revue a trouvé des défauts concrets. Un ajout pouvait écraser des données qui n’avaient pas été chargées. Deux autres points concernaient la création des identifiants et les caractères Unicode. Nous envoyons donc une nouvelle commande implement avec ces constats. Nous demandons aussi de rétablir les couvertures de la référence approuvée. Cette boucle fait partie de la chaîne réelle : une première implémentation n’est pas automatiquement une livraison acceptée.",
+    "duration": 30.842268
+  },
+  {
+    "kind": "browser",
+    "title": "Le prototype en action",
+    "voice": "Nous passons maintenant dans le vrai navigateur. L'application affiche la bibliothèque et ses contrôles. Le test parcourt les actions importantes : filtrer, ajouter un livre, commencer ou terminer une lecture, puis recharger la page. C'est cette interaction réelle qui distingue une interface utilisable d'une simple maquette. Les livres sont fictifs et les données restent locales. Aucun appel payant à un fournisseur d'intelligence artificielle n'est nécessaire pour utiliser ce prototype.",
+    "stage": null,
+    "image": null,
+    "speech": "Nous passons maintenant dans le vrai navigateur. L'application affiche la bibliothèque et ses contrôles. Le test parcourt les actions importantes : filtrer, ajouter un livre, commencer ou terminer une lecture, puis recharger la page. C'est cette interaction réelle qui distingue une interface utilisable d'une simple maquette. Les livres sont fictifs et les données restent locales. Aucun appel payant à un fournisseur d'intelligence artificielle n'est nécessaire pour utiliser ce prototype.",
+    "duration": 35.544308
+  },
+  {
+    "kind": "comparison",
+    "title": "Comparer au master screen",
+    "voice": "Nous revenons à la référence approuvée et la comparons à la capture réelle. La comparaison porte sur la composition, la hiérarchie, les couleurs, les couvertures et les actions. Les différences de police ou d'espacement doivent être nommées, pas cachées derrière un build réussi. Le comportement mobile est vérifié séparément. Une image séduisante n'est donc pas la fin du parcours : elle devient un contrat visuel que l'on confronte au produit.",
+    "stage": null,
+    "image": null,
+    "speech": "Nous revenons à la référence approuvée et la comparons à la capture réelle. La comparaison porte sur la composition, la hiérarchie, les couleurs, les couvertures et les actions. Les différences de police ou d'espacement doivent être nommées, pas cachées derrière un build réussi. Le comportement mobile est vérifié séparément. Une image séduisante n'est donc pas la fin du parcours : elle devient un contrat visuel que l'on confronte au produit.",
+    "duration": 31.527256
+  },
+  {
+    "kind": "terminal",
+    "title": "Verify : consolider les résultats",
+    "voice": "Verify rassemble les contrôles manquants et leurs résultats. Les tests de logique et les observations navigateur répondent à des questions différentes. Une commande réussie ne prouve que le périmètre qu'elle a réellement inspecté. Les sorties du film permettent de voir cette séparation. Nous ne prétendons ni à un audit complet d'accessibilité, ni à une compatibilité universelle, ni à une supériorité démontrée sur une autre méthode.",
+    "stage": "09b",
+    "image": null,
+    "speech": "Verify rassemble les contrôles manquants et leurs résultats. Les tests de logique et les observations navigateur répondent à des questions différentes. Une commande réussie ne prouve que le périmètre qu'elle a réellement inspecté. Les sorties du film permettent de voir cette séparation. Nous ne prétendons ni à un audit complet d'accessibilité, ni à une compatibilité universelle, ni à une supériorité démontrée sur une autre méthode.",
+    "duration": 31.237007
+  },
+  {
+    "kind": "terminal",
+    "title": "Terminer et préparer la reprise",
+    "voice": "Le dernier point de passage enregistre ce qui est livré, les limites et l'état de reprise. Pour cette démonstration, la livraison est locale. Une fusion sur le dépôt de la méthode et une publication du produit seraient des actions différentes. La commande suivante n'autorise pas automatiquement un nouveau périmètre. Cette discipline permet de retrouver le travail dans une autre session sans confondre une proposition, une réalisation et une preuve.",
+    "stage": "10",
+    "image": null,
+    "speech": "Le dernier point de passage enregistre ce qui est livré, les limites et l'état de reprise. Pour cette démonstration, la livraison est locale. Une fusion sur le dépôt de la méthode et une publication du produit seraient des actions différentes. La commande suivante n'autorise pas automatiquement un nouveau périmètre. Cette discipline permet de retrouver le travail dans une autre session sans confondre une proposition, une réalisation et une preuve.",
+    "duration": 32.049705
+  },
+  {
+    "kind": "end",
+    "title": "Essayez la chaîne sur votre projet",
+    "voice": "Vous avez vu le besoin, les commandes et leurs sorties, les directions artistiques, le master screen approuvé, le code et les vérifications. Dev Method sert à relier ces étapes en conservant les décisions utiles. Retrouvez le guide et les exemples sur GitHub. Pour cette évolution, utilisez la version source documentée : le paquet publié zéro point un n'inclut pas encore toutes ces nouveautés. Commencez par une petite livraison et jugez la méthode sur le résultat.",
+    "stage": null,
+    "image": null,
+    "speech": "Vous avez vu le besoin, les commandes et leurs sorties, les directions artistiques, le master screen approuvé, le code et les vérifications. Dev Method sert à relier ces étapes en conservant les décisions utiles. Retrouvez le guide et les exemples sur guit-hub. Pour cette évolution, utilisez la version source documentée : le paquet publié zéro point un n'inclut pas encore toutes ces nouveautés. Commencez par une petite livraison et jugez la méthode sur le résultat.",
+    "duration": 34.638729999999995
+  }
+]

package/docs/media/full-chain-4k/transcripts.fr.md

@@ -0,0 +1,315 @@
+# Exécution réelle — transcriptions Codex CLI
+
+Les chemins temporaires sont remplacés par `<projet>`. Réponses enregistrées au moment de chaque étape, sans réécriture de leur contenu. Les prompts comprennent des contraintes de tournage en plus de la commande.
+
+Modèle utilisé : `gpt-5.6-sol`, Codex CLI 0.147.0, sessions éphémères successives avec la même mission sur disque. Le premier essai avec le modèle configuré par défaut a échoué (modèle incompatible avec cette CLI); il ne fait pas partie des sorties réussies ci-dessous. Aucun réglage global modifié.
+
+## Étape 01
+
+### Entrée
+
+```text
+$project-foundation explore
+Lis BRIEF.md. Explore le besoin de Lisière à partir de ce dossier neuf. Enregistre le contexte utile en un seul document de mission, sans coder. Termine par la prochaine commande recommandée.
+```
+
+### Sortie réelle
+
+Exploration terminée et consignée dans l’unique document canonique : [LIS-001-lisiere.md](<projet>/docs/missions/LIS-001-lisiere.md).
+
+Le document rassemble besoin, utilisateurs, parcours, périmètre, critères observables, contraintes, référence visuelle approuvée, risques et décisions encore ouvertes. Aucun code ni test applicatif n’a été créé.
+
+Incertitudes principales : état initial, règles d’ajout, comportement de « rouvrir », erreurs `localStorage` et états vides. `CONTRIBUTING.md`, `AGENTS.md`, dépôt Git et CI sont absents.
+
+Prochaine commande recommandée : `$project-foundation frame LIS-001`
+
+## Étape 02
+
+### Entrée
+
+```text
+$project-foundation frame
+Cadre le périmètre et les critères de réussite de Lisière depuis BRIEF.md et la mission existante. Aucun code.
+Lis BRIEF.md et la mission canonique. Réponse finale en français, concise (environ 180 mots maximum), honnête, avec prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+Cadrage consigné dans la [mission canonique LIS-001](<projet>/docs/missions/LIS-001-lisiere.md).
+
+- MVP : page locale, bibliothèque initialement vide, ajout titre/auteur, cycle **À lire → En cours → Terminé → En cours**, filtres et persistance.
+- Règles précisées : ajout initial « À lire », espaces seuls refusés, doublons acceptés, livres récents en premier, ordre inchangé par les transitions.
+- Exclus : modification, suppression, recherche, tri configurable, notes, dates, statistiques, backend, réseau et déploiement.
+- Réussite : preuves pour C1–C9, couvrant parcours, panne de stockage, états vides, clavier, responsive, fidélité éditoriale et fonctionnement autonome.
+- Restent à concevoir : formulaire, validations visibles, focus, états vides, alerte de stockage et adaptation responsive. La vérification navigateur demeure à la charge du parent.
+
+Aucun code ni test n’a été créé ou exécuté.
+
+Prochaine commande recommandée : `$project-foundation design LIS-001`
+
+## Étape 03
+
+### Entrée
+
+```text
+$project-foundation design
+Inspecte les images dans references. La direction A et le master screen ont été approuvés explicitement par le même utilisateur dans la session de préparation. Formalise les tokens, le master screen, le responsive et les interactions nécessaires dans la mission existante. Ne génère pas de fausse image ni de code. Mentionne cette réutilisation.
+Lis BRIEF.md et la mission canonique. Réponse finale en français, concise (environ 180 mots maximum), honnête, avec prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+Conception formalisée dans la [mission canonique LIS-001](<projet>/docs/missions/LIS-001-lisiere.md).
+
+Ajouts réalisés :
+
+- réutilisation explicite de la direction **A — Éditorial** et du master approuvés lors de la préparation ;
+- tokens visuels et interactifs ;
+- composition du master desktop ;
+- adaptations tablette et mobile ;
+- dialogue d’ajout, validation et gestion du focus ;
+- filtres, cycle des statuts et navigation clavier ;
+- états vides, stockage indisponible et données invalides ;
+- matrice UX minimale et décisions restant à l’architecture.
+
+La mission passe à l’étape « conception accomplie ». Aucune image, aucun code applicatif et aucun test n’ont été produits. La fidélité n’a pas été vérifiée dans un navigateur, conformément à la responsabilité laissée au parent. `CONTRIBUTING.md` et `AGENTS.md` restent absents.
+
+Prochaine commande recommandée : `$project-foundation architecture LIS-001`.
+
+## Étape 04
+
+### Entrée
+
+```text
+$project-foundation architecture
+Définis les frontières minimales pour une application statique locale sans dépendances, avec logique testable et stockage. Mets à jour la mission existante, pas de nouveau dossier de specs.
+Lis BRIEF.md et la mission canonique. Réponse finale en français, concise (environ 180 mots maximum), honnête, avec prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+Architecture minimale définie dans la [mission canonique LIS-001](<projet>/docs/missions/LIS-001-lisiere.md).
+
+- Frontières : domaine pur, adaptateur `localStorage`, application/vue, composition.
+- Contrats fixés : modèle du livre, transitions, limites Unicode, identifiants, ordre et couvertures déterministes.
+- Stockage versionné `v1`, validation stricte, récupération explicite et maintien en mémoire lors des échecs.
+- Compatibilité navigateur et stratégie de tests sans dépendance cadrées.
+- Mission passée à l’étape « architecture » sans créer de document ni dossier supplémentaire.
+
+Reste incertain : le harnais de test exact, à choisir après constat des runtimes disponibles. La vérification réelle dans le navigateur demeure à la charge du parent. Aucun code ni test n’a été produit, conformément au périmètre de cette étape.
+
+Prochaine commande recommandée : `$project-foundation plan LIS-001`
+
+## Étape 05
+
+### Entrée
+
+```text
+$project-foundation plan
+Découpe en une première tranche LISIERE-1 avec critères, tests, dépendances et preuve attendue. Reste dans le périmètre du brief.
+Lis BRIEF.md et la mission canonique. Réponse finale en français, concise (environ 180 mots maximum), honnête, avec prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+**Fait :** la mission canonique [LIS-001-lisiere.md](<projet>/docs/missions/LIS-001-lisiere.md) contient désormais la première tranche **LISIERE-1**.
+
+Elle couvre strictement le MVP du brief :
+
+- ajout et validation des livres ;
+- filtres et cycle des statuts ;
+- persistance `localStorage` et récupérations d’erreur ;
+- états vides, clavier et accessibilité ;
+- fidélité responsive à la référence éditoriale approuvée ;
+- fonctionnement hors réseau, sans dépendance.
+
+Le plan précise les critères C1–C9, l’ordre d’implémentation, les contrats à respecter, la définition de terminé et les preuves attendues. Node.js `v24.18.0` permettra des tests sans installation via `node:test`.
+
+**Non fait :** aucun code applicatif ni test n’a été créé ou exécuté. Les contrôles dans un navigateur réel restent explicitement à la charge du parent et ne sont pas présentés comme acquis.
+
+**Prochaine commande recommandée :** `$project-foundation ready LISIERE-1`
+
+## Étape 06
+
+### Entrée
+
+```text
+$project-foundation ready LISIERE-1
+Vérifie la préparation de cette tranche. Aucun code, pas de build par habitude.
+Lis BRIEF.md et la mission canonique. Réponse finale en français, concise (environ 180 mots maximum), honnête, avec prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+**Fait — LISIERE-1 est prête à implémenter.**
+
+Le brief et la mission canonique `docs/missions/LIS-001-lisiere.md` concordent sur :
+
+- objectif, périmètre et exclusions ;
+- critères C1–C9 et définition de terminé ;
+- frontières domaine / stockage / vue / composition ;
+- stratégie de tests avec `node:test`, sans dépendance ;
+- responsabilité distincte du parent pour la vérification navigateur.
+
+Les prérequis sont disponibles : Node.js `v24.18.0`, références PNG en 1536 × 1024, empreintes du brief et du master conformes à la mission. Aucun manifeste, lockfile ou code applicatif n’existe, conformément à l’état annoncé.
+
+**Limites :** `CONTRIBUTING.md` et `AGENTS.md` sont absents, mais ce n’est pas bloquant ici. `PROJECT_PROFILE.md` reste un gabarit vierge et non canonique. Aucun test, build ou contrôle navigateur n’a été exécuté.
+
+**Prochaine commande recommandée :** `$project-foundation implement LISIERE-1`
+
+## Étape 07
+
+### Entrée
+
+```text
+$project-foundation implement LISIERE-1
+Implémente maintenant la tranche et ses tests purs. Vue desktop/mobile fidèle au master screen validé, vrais contrôles et stockage local. Ne copie aucun code externe : seuls les assets de référence et le kit sont fournis. Application dans app/, tests node --test dans tests/. Le parent fera les tests Chrome. Regroupe implémentation, tests et corrections locales. Pas de dépendances, réseau, navigateur ou nouvel agent. Termine avec preuves et commande suivante.
+Lis BRIEF.md et la mission canonique. Réponse finale en français, concise (environ 180 mots maximum), honnête, avec prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+LISIERE-1 est implémentée dans [app/](<projet>/app) :
+
+- interface éditoriale responsive desktop/mobile fidèle au master ;
+- ajout via dialogue accessible, validation et gestion du focus ;
+- filtres, cycle des statuts et états vides ;
+- persistance `localStorage`, erreurs explicites, nouvelle tentative et réinitialisation confirmée ;
+- couvertures abstraites déterministes, sans réseau ni dépendance.
+
+Les tests purs sont dans [tests/](<projet>/tests). Preuves locales :
+
+- `node --test tests/*.test.js` : **22 réussis, 0 échec** ;
+- `node --check` réussi sur tous les JavaScript ;
+- aucune URL, dépendance applicative ou API réseau dans `app/`.
+
+La revue a corrigé un risque d’écrasement après échec de lecture et sécurisé l’accès initial à `localStorage`. La mission canonique a été actualisée dans [LIS-001-lisiere.md](<projet>/docs/missions/LIS-001-lisiere.md).
+
+Non vérifiés ici, conformément au partage des responsabilités : rendu Chrome réel, clavier, zoom, contraste, persistance et défaillances simulées.
+
+Commande suivante recommandée au parent : **`$project-foundation verify LISIERE-1`**.
+
+## Étape 08
+
+### Entrée
+
+```text
+$project-foundation review LISIERE-1
+Relis les fichiers réalisés et les critères, sans réécrire le code. Identifie les défauts concrets ou indique absence de défaut détecté. Ne prétends pas avoir exécuté Chrome.
+Lis BRIEF.md et la mission canonique. Réponse finale en français, concise (environ 180 mots maximum), honnête, avec prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+Revue statique de LISIERE-1 terminée, sans modification du code.
+
+Défauts concrets détectés :
+
+- [application.js](<projet>/app/application.js:25) autorise l’ajout après une lecture `localStorage` impossible ou incompatible. L’appel à `save()` peut alors écraser les données non chargées sans la réinitialisation confirmée exigée.
+- [view.js](<projet>/app/view.js:15) appelle directement `crypto.randomUUID()`. Son indisponibilité provoque une exception lors de l’ajout, sans avertissement explicite, contrairement au contrat de compatibilité.
+- [index.html](<projet>/app/index.html:35) utilise `maxlength="120"`, compté en unités UTF-16 par le navigateur, tandis que le domaine autorise 120 points de code Unicode. Certains titres comportant des caractères hors BMP sont donc refusés prématurément.
+
+C1–C3, C6 et C9 paraissent autrement correctement représentés dans les fichiers et tests. C4–C5 restent affectés par le premier défaut. C7–C8 ne peuvent pas être conclus par inspection seule.
+
+Je n’ai exécuté ni Chrome ni les tests; les « 22 tests réussis » restent une preuve antérieure consignée dans la mission.
+
+Prochaine commande recommandée : `$project-foundation implement LISIERE-1`.
+
+## Étape 08b
+
+### Entrée
+
+```text
+$project-foundation implement LISIERE-1
+Corrige les trois défauts de la revue précédente : ajout/retry ne doivent jamais écraser des données non chargées après échec de lecture ou données incompatibles sans reset confirmé, indisponibilité de crypto.randomUUID doit être gérée, limite Unicode doit suivre les points de code. Lis aussi BROWSER-PRELIMINARY.md : getter localStorage était cassé avant ta correction, le parent le retestera. Pour la fidélité, réutilise les couvertures de la référence approuvée pour les trois titres correspondants, via crops CSS de l'image disponible (ne copie aucun ancien code), garde des couvertures abstraites pour les autres. Ajoute les tests de régression pertinents, exécute-les, actualise la mission. Pas de navigateur ni réseau. Réponse française 180 mots environ, preuves précises et prochaine commande.
+```
+
+### Sortie réelle
+
+LISIERE-1 est corrigée et la mission actualisée.
+
+- La persistance est verrouillée après lecture échouée ou données incompatibles : ajout et retry restent en mémoire sans `setItem`; seul un reset confirmé et réussi la réactive ([application.js](<projet>/app/application.js:11)).
+- Le getter `localStorage` levant est capturé dans l’adaptateur, avec régression dédiée ([storage.js](<projet>/app/storage.js:43)).
+- `crypto.randomUUID` dispose d’un repli UUID v4 via `getRandomValues`, puis d’un dernier recours local ([domain.js](<projet>/app/domain.js:85)).
+- La limite de 120 suit désormais strictement les points de code Unicode : les `maxlength` UTF-16 ont été retirés.
+- Les trois couples titre/auteur approuvés utilisent des crops CSS de l’image maître; les autres gardent leurs couvertures abstraites ([styles.css](<projet>/app/styles.css:5)).
+- Les preuves et réserves sont consignées dans [LIS-001-lisiere.md](<projet>/docs/missions/LIS-001-lisiere.md:260).
+
+Vérification exécutée : `node --test tests/*.test.js` — **27 réussis, 0 échec**. Tous les JS passent `node --check`; aucun appel/import réseau détecté. Aucun navigateur n’a été lancé, conformément à la consigne.
+
+Prochaine commande :
+
+```text
+$project-foundation verify LISIERE-1
+```
+
+## Étape 09
+
+### Entrée
+
+```text
+$project-foundation verify LISIERE-1
+Lis la mission et BROWSER-EVIDENCE.md, preuves réelles Chrome du parent après correction08b. Consolide les critères sans prétendre avoir lancé le navigateur toi-même. Réutilise les27 tests déjà passés si leurs fichiers sont inchangés, exécute seulement un contrôle encore nécessaire. Signale toute vraie limite. Réponse française180 mots environ et prochaine commande qualifiée. Pas de nouveau code, réseau, publication ou agent.
+```
+
+### Sortie réelle
+
+**Vérification LISIERE-1 consolidée**
+
+C1 à C6 sont étayés par les 27 tests locaux déjà réussis et par les observations Chrome réelles du parent après correction08b : ajout, filtres, cycle complet, rechargement, validation, états vides et défaillances de stockage. C9 est également établi : fonctionnement local, sans dépendance, requête distante, fournisseur payant ni déploiement.
+
+C7 est partiellement confirmé : formulaire, fermeture par Échap et parcours interactifs ont été observés, mais la preuve ne détaille pas un parcours clavier intégral par tabulation puis activation des filtres et statuts. C8 est raisonnablement étayé par l’inspection parent des captures desktop/mobile : composition éditoriale, palette, couvertures et absence de débordement mobile sont préservées, sans identité pixel à pixel.
+
+Je n’ai lancé aucun navigateur. Le seul contrôle exécuté ici est la comparaison des dates de modification : tous les fichiers `app/` et `tests/` précèdent `BROWSER-EVIDENCE.md`. Les résultats 27/27 restent donc réutilisables et n’ont pas été relancés.
+
+Limites réelles : zoom 200 %, contraste mesuré, audit d’accessibilité complet et autres navigateurs non vérifiés. La mission n’est pas totalement clôturable au sens maximal du contrat.
+
+Prochaine commande recommandée : `$project-foundation verify LISIERE-1` avec Chrome réel, ciblée uniquement sur clavier complet, zoom 200 % et contraste.
+
+## Étape 09b
+
+### Entrée
+
+```text
+$project-foundation verify LISIERE-1
+Les preuves supplémentaires du parent sont enregistrées dans BROWSER-EVIDENCE.md : parcours clavier intégral réussi, contrastes mesurés >4.5, reflow720 et320px réussi. Le zoom natif navigateur n'est pas observé, seulement le reflow à largeur CSS divisée par deux : conserve cette limite sans la présenter comme un succès. Consolide l'acceptation locale au périmètre observé; l'utilisateur demande ce prototype pédagogique local, pas une certification tous navigateurs. Si un critère indispensable reste réellement bloqué, indique-le. Réutilise les27 tests inchangés. Réponse française180 mots environ et prochaine commande qualifiée. Pas de code ou publication.
+```
+
+### Sortie réelle
+
+**Fait.** LISIERE-1 est accepté localement dans le périmètre du prototype pédagogique observé. Les preuves navigateur couvrent C1 à C9 : ajout, filtres, cycle complet, persistance après rechargement, défaillances de stockage, états vides, parcours intégral au clavier, rendu desktop/mobile et autonomie hors réseau. Les régressions `localStorage`, données incompatibles, Unicode et repli UUID réussissent également.
+
+La suite existante a été réutilisée sans modification : `node --test tests/*.test.js` donne **27 tests réussis, 0 échec**. Les contrôles syntaxiques JavaScript réussissent. Aucun code, test ou document n’a été modifié, et rien n’a été publié.
+
+**Limites conservées.** Les contrastes mesurés sur les couples CSS sélectionnés sont tous supérieurs à 4,5, sans constituer une analyse de chaque pixel rendu. Le reflow réussit à 720 et 320 px sans débordement horizontal. En revanche, le zoom navigateur natif à 200 % n’a pas été manipulé : il demeure **non vérifié** et n’est pas déclaré réussi. Firefox, Safari, Edge et une certification exhaustive d’accessibilité restent hors du périmètre observé.
+
+Aucun critère indispensable au prototype local n’est réellement bloqué.
+
+**Prochaine commande recommandée :** `$project-foundation integrate LISIERE-1` — pour préparer l’intégration locale seulement, sans fusion, déploiement ni publication implicite.
+
+## Étape 10
+
+### Entrée
+
+```text
+$project-foundation integrate LISIERE-1
+La vérification finale09b a accepté le prototype local avec les limites documentées dans BROWSER-EVIDENCE.md. Enregistre la livraison locale et la reprise exacte dans la mission canonique. Le dossier n'est pas un dépôt Git : aucune fusion, PR ou publication à inventer. Aucun nouveau périmètre, aucun réseau, aucun code à modifier ou test à relancer sans cause. Réponse française180 mots environ, résultat concret, limites, prochaine commande qualifiée.
+```
+
+### Sortie réelle
+
+L’intégration locale de **LISIERE-1** est enregistrée dans la [mission canonique](<projet>/docs/missions/LIS-001-lisiere.md).
+
+La mission indique désormais :
+
+- la vérification finale09b acceptée ;
+- le prototype livré uniquement sous forme de fichiers locaux ;
+- les contrôles Chrome, clavier, persistance, stockage défaillant, contraste et reflow reliés à [BROWSER-EVIDENCE.md](<projet>/BROWSER-EVIDENCE.md) ;
+- la clôture de LISIERE-1 dans ce mode de livraison ;
+- l’absence explicite de dépôt Git, fusion, PR, publication ou déploiement.
+
+Les limites acceptées sont conservées sans sur-promesse : pas d’identité pixel, de métrique perceptuelle automatisée, de panel humain distinct, d’audit complet d’accessibilité ou inter-navigateurs. Le reflow à 720 et 320 px ne constitue pas une preuve du zoom Chrome natif à 200 %, qui reste non vérifié.
+
+Aucun code n’a été modifié, aucun test ou contrôle navigateur n’a été relancé, et aucun accès réseau n’a été effectué. Seule la cohérence documentaire de la mission a été vérifiée.
+
+Prochaine commande qualifiée : `$project-foundation next LISIERE-1`, pour constater la clôture et sélectionner uniquement une éventuelle suite expressément autorisée.

package/docs/media/visual-chain/README.md

@@ -0,0 +1,44 @@
+# DevMethod — du besoin au produit vérifié
+
+[Voir le film 4K](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/visual-chain/devmethod-du-besoin-au-produit-4k.fr.mp4) · [Sous-titres](devmethod-du-besoin-au-produit.fr.srt) · [Prototype source](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/visual-chain/lisiere-visual-source.zip)
+
+**2 min 58 s · 3840 × 2160 · 23 séquences · voix française.**
+
+Le film remplace le long documentaire comme démonstration principale : un seul projet, Lisière, une commande et son résultat visuel, puis l'étape suivante. Narration française courte, commandes tapées, apparitions successives, mouvements doux et interaction réelle. Le cadrage, les choix techniques, les responsabilités du code, la préparation, la revue et la reprise complètent le parcours des maquettes. GitHub garde la prononciation « guit-hub » demandée.
+
+## Ce qui est effectivement vérifié
+
+| Passage | Preuve et portée |
+| --- | --- |
+| Trois directions → choix A → master approuvé | Assets et choix réels conservés du pilote Lisière antérieur ; pas une nouvelle décision utilisateur inventée |
+| Master → images des écrans | Deux appels image_gen avec le master en référence : ajout et terminés ; une correction image du fond de la modale |
+| Images → nouvelle application | Nouveau dossier contenant seulement le kit, le brief et les références ; Codex CLI implémente ensuite sans recevoir l'ancien code |
+| Architecture | Stack HTML/CSS/JavaScript et stockage local réellement présents ; règles testables dans domain.mjs, validation des données sauvegardées ; ce choix de prototype ne vaut pas recommandation universelle |
+| Application → vérification | 6 tests Node ; parcours Chrome avec filtres, ajout, statut, focus après transition, sauvegarde, mobile et préservation de données illisibles |
+| Livraison | Prototype local archivé, sans déploiement ni publication npm |
+
+Les commandes visibles sont des formulations types réutilisables, pas une transcription littérale d'un unique chat ni une capture continue de Codex Desktop. Les résultats visuels et interactions sont réels. La préparation de la petite tranche neuve a été regroupée dans `implement` ; le film présente `frame`, `architecture`, `plan`, `ready`, `review` et `handoff` séparément pour expliquer leurs rôles. Ces étapes ne sont pas présentées comme des exécutions séparées réellement enregistrées.
+
+Le parent a corrigé deux défauts de la réalisation neuve avant la vérification finale : la règle CSS `hidden` de l'alerte et le maintien du focus après changement de statut. Les images dérivées ajoutent seulement des états déjà prévus ; aucune nouvelle approbation utilisateur de ces images n'est revendiquée. Le master A conserve son approbation antérieure. Écarts restants : police système, dimensions adaptées et détails raster ; aucune identité pixel à pixel ni certification complète d'accessibilité.
+
+## Parcours expliqué
+
+`explore` → `frame` → `design` → `architecture` → `plan` → `ready` → `implement` → `review` → `verify` → `integrate` → `handoff` / `next`.
+
+Dans Codex, chaque étape utilise le préfixe `$project-foundation`. Le niveau de détail dépend du projet ; une petite tranche peut regrouper plusieurs étapes dans une même exécution.
+
+Le skill [design-to-code](../../../.agents/skills/design-to-code/SKILL.md) guide les alternatives, le master approuvé, les images dérivées et la comparaison au navigateur. [decision-architecture](../../../.agents/skills/decision-architecture/SKILL.md) compare les technologies et leurs compromis, définit les frontières et consigne les décisions structurantes. Ces capacités se complètent ; le design ne remplace pas les choix techniques.
+
+## Revalidation du contenu
+
+Le film précédent était trop détaillé et ne prouvait pas le passage master → pages : sa commande design réutilisait surtout une référence existante. Le skill explicite désormais les trois points de passage et recommande de rester dans design lorsque des visuels demandés manquent. Il ne crée aucune commande autonome « master » ou « pages ».
+
+La génération d'images dépend toujours d'un outil disponible dans l'agent. Une instruction documentée ne suffit pas à prouver son exécution : le test présent conserve les prompts, les références, les images générées et la réalisation postérieure. Le [guide](../../VISUAL-WORKFLOW.md) contient les commandes correspondantes. Clair et Lisière ne sont plus mélangés dans la narration.
+
+## Sources de montage
+
+Les scripts sont dans [scripts/media/visual-short](../../../scripts/media/visual-short). Ils utilisent macOS Thomas, ffmpeg/ffprobe, Chrome et Playwright (PLAYWRIGHT_MODULE si nécessaire). Depuis la racine du dépôt : extraire le prototype dans /private/tmp/devmethod-shortfilm/project et le servir sur localhost:8768 ; exécuter check.cjs, story.py, record.cjs, puis encode.py. Les maquettes raster sont les assets générés déjà conservés, pas régénérées par ces scripts.
+
+Le montage est en 4K ; les images source générées sont en 1536×1024. Le texte et les transitions sont rendus dans Chrome à 3840×2160.
+
+Vérifications du média : MP4 H.264, AAC, sous-titres français mov_text ; 177.509 secondes. Plans explicatifs de 6 à 10 secondes environ, transitions et apparitions animées ; séquence navigateur de 20 secondes avec plusieurs actions. Images du master, des déclinaisons, de la comparaison et de la persistance encodée inspectées. Les sous-titres ont un timing proportionnel par phrase. Pas de revendication d’écoute humaine complète.