PRD Lifecycle

Cycle de vie PRD

Réunit les capacités dispersées de création, raffinement, revue et planification d'exécution des PRD en un point d'entrée unique, tout en conservant des limites de permissions et des garde-fous de validation distincts à chaque étape.

Routage des modes

Identifie d'abord les documents existants de l'utilisateur et le résultat attendu, puis n'entre que dans le mode nécessaire, sans forcer un parcours complet depuis le début.

Mode	Entrée typique	Résultat principal	Limite clé
create (Création)	Idée fonctionnelle + dépôt existant	Rapport d'état, ligne de base confirmée, PRD versionné	D'abord collecter des preuves, valider étape par étape ; pas de génération de PRD avant validation de la ligne de base
refine (Raffinement)	Brouillon de PRD/exigences	Révision incrémentale, historique des versions, .docx optionnel	Chaque étape : révision d'abord, écriture et mise à jour uniquement après validation
review (Revue contradictoire)	PRD spécifié + ligne de base/dépôt optionnel	Problèmes hiérarchisés, preuves, suggestions de révision	Lecture seule : ne modifie pas le document, n'implémente pas de code
execute (Planification d'exécution)	PRD approuvé + dépôt existant	Audit de conformité, document d'exécution, matrice de traçabilité, prompts de contrôle	Planification uniquement : ne modifie pas le PRD, n'implémente pas de code

Règles de routage :

• Idée seule, avec souhait de créer un PRD en s'appuyant sur le projet existant : utiliser create.
• Brouillon existant, objectif de compléter, réviser, peaufiner ou finaliser : utiliser refine.
• Objectif de trouver contradictions, risques, omissions ou éléments non vérifiables, sans demande de modification : utiliser review.
• Version clairement approuvée disponible, objectif de confier le développement à Codex par phases : utiliser execute.
• Demande de traitement de bout en bout : démarrer à l'étape la plus précoce applicable ; à chaque garde-fou ci-dessous, s'arrêter pour attendre autorisation, ne pas franchir d'étape automatiquement.
• "Examinez ceci" peut signifier revue ou modification ; privilégier le mode review en lecture seule, et préciser que les résultats de la revue peuvent être suivis d'un refine après autorisation séparée.
• L'utilisateur souhaite uniquement évaluer et implémenter des modifications locales dans le dépôt existant (code, UI, interactions, refactoring, architecture) : utiliser repo-grounded-change ; ne pas forcer la rédaction d'un PRD.

Contraintes partagées

Ordre d'autorité

Sauf indication contraire de l'utilisateur, traiter les conflits dans cet ordre :

1. Instruction explicite de l'utilisateur.
2. Décisions déjà confirmées dans la tâche en cours.
3. Lignes de base et PRD approuvés spécifiés.
4. Comportement existant prouvé par le code et les tests actuels.
5. Documentation produit actuelle.
6. Brouillons, enregistrements de revues et suggestions passés.

Le PRD cible n'est pas correct par nature ; en cas de conflit, exposer le conflit, son impact et la décision nécessaire, sans choisir silencieusement un camp. Le code sert à prouver l'état actuel, il ne peut pas invalider des exigences nouvelles déjà approuvées.

Étiquettes de fait et de suggestion

Utilisées lorsque la conclusion pourrait être ambiguë : Confirmé, Fait de code, Fait de documentation, Hypothèse produit, Suggestion technique, À confirmer, Non implémenté dans cette itération.

Limites d'autorisation

• Ne pas inventer de règles métier, états, seuils, permissions, priorités, dépendances, intégrations externes ou critères d'acceptation.
• Ne pas considérer l'achèvement d'une étape, la validation d'une revue ou la génération d'un plan comme une autorisation d'implémenter.
• Ne pas modifier le code métier, ne pas commit, push, déployer, ni appeler de systèmes de production externes.
• Vérifier l'arbre de travail et protéger les modifications existantes de l'utilisateur ; en cas d'impossibilité de contournement sécurisé, s'arrêter et expliquer la zone de chevauchement.
• Exécuter uniquement le mode demandé par l'utilisateur. Un passage au mode suivant nécessite une demande ou confirmation explicite.

create : Création de PRD après investigation du dépôt

1. Lire project-discovery.md, inspecter le dépôt, la documentation produit, les tests et l'arbre de travail, produire un rapport d'état. Sauf demande expresse de fusion des étapes, s'arrêter et attendre la confirmation de l'état.
2. Lire clarification-rounds.md, planifier les sujets en fonction des lacunes de preuves. Un seul sujet par cycle, proposer 1 à 3 questions à choix mutuellement exclusifs ; recommander l'option préférée en premier et expliquer l'impact.
3. Après la réponse de l'utilisateur, résumer les éléments confirmés, non confirmés, les conflits et les impacts aval de ce cycle, puis attendre la confirmation du résumé. Ne pas passer au sujet suivant sans confirmation.
4. Une fois tous les sujets pertinents confirmés, lire baseline-and-prd.md, générer la ligne de base de validation des exigences et s'arrêter.
5. Ce n'est qu'après approbation explicite de la ligne de base par l'utilisateur et demande de génération du PRD que créer le PRD versionné ; rechercher les versions existantes et incrémenter, ne pas écraser silencieusement.

Critère d'achèvement : Le PRD est cohérent avec les décisions validées, le périmètre et les non-objectifs sont clairs, les exigences et critères d'acceptation sont traçables, l'impact sur le dépôt est étayé par des preuves, et les points non résolus ne sont pas déguisés en exigences finales.

refine : Raffinement incrémental et révision versionnée

1. Lire l'intégralité du texte source, préserver le sens initial et établir une ligne de base de travail. Si un nouveau document de travail Markdown est nécessaire, utiliser scripts/prd_doc.py init pour créer v1.0 et le squelette des sections.
2. Lire la sous-section de l'étape actuelle de refinement-steps.md. Le squelette par défaut est :
   • Clarification des exigences et user stories ;
   • Solution fonctionnelle ;
   • Conditions aux limites ;
   • Critères d'acceptation.
3. Ne travailler que sur l'étape en cours. Présenter d'abord le contenu à réviser dans le dialogue, sans l'écrire dans le fichier.
4. Si l'utilisateur demande des modifications ou ajouts, rester sur l'étape en cours, ne pas incrémenter la version. Ce n'est qu'après confirmation explicite de l'utilisateur qu'écrire dans le document et effectuer une incrémentation mineure (minor) avec enregistrement des révisions, conformément à versioning.md.
5. En cas de besoin de métriques, de planification des dépendances, de rollback des risques, de conformité ou de retour d'avis, insérer des étapes supplémentaires ; appliquer le même processus « production → révision → validation → écriture → incrémentation de version ».
6. Après confirmation de toutes les étapes, fusionner le document complet et effectuer une incrémentation majeure (major). Si un .docx est demandé, utiliser scripts/prd_doc.py export et effectuer une validation de mise en page avec les outils documentaires disponibles.

Chaque étape doit non seulement compléter, mais aussi pointer les éléments vagues, contradictoires, non vérifiables et les scénarios facilement omis dans le texte original. Les user stories, fonctionnalités, limites et critères d'acceptation doivent être traçables ; chaque critère d'acceptation doit inclure des conditions claires et des résultats observables.

L'achèvement des révisions ne signifie pas que le PRD est approuvé commercialement, et n'entraîne pas automatiquement l'entrée dans review ou execute.

review : Revue contradictoire fondée sur des preuves

1. Lire review-protocol.md, confirmer la version cible, le périmètre de la revue, les sources d'autorité, les preuves du dépôt et les documents manquants. Lire intégralement le PRD cible.
2. Extraire le périmètre, le type, l'état, les seuils, les permissions, les données, le temps, les priorités et les invariants d'acceptation.
3. Lire finding-taxonomy.md, vérifier respectivement la régression de la ligne de base, la cohérence interne, le cycle de vie, l'historique des données, l'idempotence des interfaces, l'audit des permissions, les limites du prototype, les exigences non fonctionnelles NFR, l'exécutabilité et la traçabilité des FR/AC.
4. Dédupliquer puis ne conserver que les problèmes étayés par des preuves, ayant des conséquences et pouvant être corrigés. Ne pas créer de découvertes artificielles pour paraître complet.
5. Lire review-report.md, produire une conclusion : Pass (Réussi), Pass with changes (Réussi avec modifications), Blocked (Bloqué) ou Limited review (Revue limitée), et présenter les découvertes par gravité, avec preuves, impact et suggestions de correction minimales.

La revue est par défaut en lecture seule. Même en cas de problème évident, ne pas modifier directement le PRD ; autoriser une révision ultérieure par l'utilisateur avant d'entrer dans refine.

execute : Transformation en document d'exécution Codex

Prérequis : existence d'un PRD approuvé avec une version identifiable. L'achèvement des révisions ou une revue réussie ne constituent pas en soi une approbation.

1. Lire readiness-audit.md, vérifier la version du PRD, la ligne de base de validation, le périmètre de version cible, les points non résolus, le dépôt et les tests actuels, produire un tableau des écarts et une conclusion de conformité.
2. Si le comportement produit ne peut être déterminé de manière unique, s'il existe des conflits d'autorité, si l'acceptation n'est pas observable, ou si des dépendances/intégrations/migrations non autorisées sont nécessaires, la conclusion est BLOCKED (Bloqué) et on s'arrête, sans cacher le problème dans des hypothèses techniques.
3. Lire execution-document.md, définir les limites architecturales minimales satisfaisant le PRD : propriété, état, données, interfaces, persistance, horloge, dégradation et protection du système existant.
4. Commencer par une Phase 0 en lecture seule, créer des phases ordonnées par dépendances, indépendamment révisables. Chaque phase doit spécifier : FR/AC, périmètre des fichiers, interdictions, tests, preuves d'acceptation, barrières de qualité et barrières d'arrêt.
5. Lire traceability-and-gates.md, mapper chaque FR/AC du périmètre à une phase, une zone de code, des tests et des preuves, identifier les exigences orphelines et le travail hors périmètre.
6. Lire codex-control-prompt.md, générer le prompt de contrôle global et les prompts par phase. Les prompts doivent préserver la version, l'ordre d'autorité, les tests réels, la protection des modifications de l'utilisateur et les autorisations par phase.

Critère d'achèvement : Une autre instance de Codex peut démarrer par un audit en lecture seule, exécuter une seule phase approuvée, vérifier avec des commandes réelles, rapporter les résultats de traçage et s'arrêter ; le document explicite clairement les hypothèses, les exclusions, les blocages, les éléments reportés et les comportements protégés.

Garde-fous de transition entre phases

• create → refine : Uniquement si l'utilisateur estime que le PRD généré nécessite encore des compléments ou révisions.
• create/refine → review : Doit être demandé explicitement par l'utilisateur ; la revue ne modifie pas automatiquement.
• review → refine : Après autorisation explicite de l'utilisateur pour traiter des découvertes spécifiques, entrer en conservant l'identifiant de chaque découverte et sa correspondance avec les révisions.
• create/refine/review → execute : La version du PRD « approuvé » et le périmètre de version cible doivent être explicitement spécifiés.
• execute → implementation : Le document d'exécution ne fournit qu'un plan de contrôle ; l'implémentation réelle doit être autorisée séparément par l'utilisateur dans une tâche ultérieure.

Apprentissage par feedback

Au début du workflow, lire feedback-learning.md et learned-guidance.md. Appliquer d'abord le feedback à la tâche en cours ; la persistance n'est autorisée que si l'utilisateur demande explicitement de mémoriser et confirme les règles spécifiques et leur périmètre. Les règles apprises ne peuvent pas remplacer les instructions actuelles, les garde-fous de phase, la vérification des faits, la gestion de version ou les limites d'autorisation.