SeemSeam/plan-tree

Arbre de Planification (Plan Tree)

Utilisez cette compétence comme autorité de workflow de planification pour la direction durable d'un projet, l'état de préparation à l'exécution, l'état d'avancement et les arbres de planification Markdown. Elle préserve l'intention de l'utilisateur, le style de document existant, la piste de raisonnement et les preuves du plan à la mise en œuvre à travers les sessions et les agents.

Mode de Fonctionnement Requis

Pour chaque tâche d'arbre de planification, déterminez le mode de travail avant d'éditer ou de mettre en œuvre.

• Si le mode n'est pas clair, utilisez par défaut clarify ou ready-check, pas execute-ready.
• Lorsqu'un état existant de l'arbre de planification est disponible, inspectez le point d'entrée pertinent et l'état actuel du plan avant de changer de direction.
• Avant qu'une solution ne soit suffisamment mature pour être mise en œuvre, restez en mode planification et clarification. Développez l'intention de l'utilisateur en objectifs, non-objectifs, contraintes, options, compromis, risques, dépendances, critères d'acceptation, chemin de vérification, et notes de déploiement ou de restauration.
• Ne commencez pas une implémentation formelle dans la surface principale du projet tant qu'il subsiste une ambiguïté fondamentale sur le périmètre, l'approche, les surfaces affectées, le comportement attendu, les critères d'acceptation, le chemin de vérification ou les risques.
• Un petit prototype ou échantillon isolé est autorisé uniquement lorsqu'il valide une direction et reste clairement séparé du chemin de production.
• Un plan est prêt pour l'implémentation uniquement lorsque l'exécution ne devrait pas reposer sur "figure it out while coding" pour les décisions de base.
• Après la mise en œuvre, mettez à jour l'état de l'arbre de planification, les preuves de mise en œuvre, les décisions, les questions ouvertes et les notes de transfert afin que les projets d'implémentation reviennent à un état de plan durable.

Modes de Travail

Choisissez un mode principal au début d'une tâche, puis ne transitionnez que lorsque l'état change.

• clarify : l'intention, le périmètre, les contraintes, les critères de succès ou les compromis ne sont pas clairs. Discutez, posez des questions ciblées si nécessaire, et enregistrez les résultats de clarification durables dans les fichiers de l'arbre de planification si utile. Ne modifiez pas les fichiers d'implémentation principaux du projet.
• shape-plan : la direction est en grande partie connue mais a besoin d'une carte de solution concrète. Créez ou mettez à jour les éléments de la feuille de route, les sujets, les hypothèses, les décisions, les risques, les critères d'acceptation et les questions ouvertes.
• ready-check : l'utilisateur souhaite implémenter ou procéder, mais l'état de préparation est incertain. Évaluez si le périmètre, l'approche, les surfaces affectées, les critères d'acceptation, la vérification et les risques sont suffisamment explicites. Si ce n'est pas le cas, revenez à clarify ou shape-plan.
• resume : continuer le travail précédent. Lisez le point d'entrée racine, la base de référence pertinente, le README du plan cible, l'état d'implémentation, la feuille de route, et seulement les fichiers liés actifs. Résumez la phase actuelle, la TODO active, les blocages, la prochaine cible, et la dernière vérification avant d'éditer.
• execute-ready : le plan est suffisamment prêt pour être mis en œuvre. Modifiez les fichiers du projet uniquement dans le périmètre convenu, puis mettez à jour l'état de l'arbre de planification et les preuves.
• status-update : mettez à jour l'état de la feuille de route, l'état d'implémentation, le dernier atterrissage, la prochaine cible, les blocages, le transfert, ou le registre des plans après le travail ou la révision.
• archive : déplacez les détails obsolètes, les anciens instantanés de statut, les preuves acceptées ou le matériel de référence uniquement hors des fichiers actifs tout en préservant les liens de récupération.
• normalize : réorganisez un arbre de planification existant ou des fichiers sources multi-rôles surdimensionnés en unités de récupération plus petites. Créez ou mettez d'abord à jour indexes/migration-map.md ou l'index le plus utile à proximité, puis classez le matériel source par rôle de récupération, créez des capsules courtes et des éclats de détails de tâches de lecture, déplacez les vérifications acceptées vers evidence/, et déplacez les anciennes narrations de statut ou de raisonnement vers history/ sans supprimer le matériel source sauf approbation explicite.
• audit ou migrate : inspectez la cohérence, la récupération, la dérive, les racines héritées ou le mappage de migration. Par défaut, en lecture seule, sauf si l'utilisateur demande de réparer, normaliser ou migrer.

Les actions documentées telles que idea, promote, question et decision se produisent à l'intérieur de ces modes :

• idea : ajoutez une pensée à faible engagement dans ideas/inbox.md ou l'équivalent local.
• promote : déplacez une idée vers un élément de la feuille de route, un sujet, une question ouverte ou une décision, et liez l'idée d'origine.
• question : ajoutez, réduisez ou résolvez une question non résolue.
• decision : créez ou mettez à jour un enregistrement de décision stable.

Workflow de Base

Pour chaque tâche d'arbre de planification :

1. Sélectionnez le mode de travail et la surface d'écriture autorisée : aucune, arbre de planification uniquement, prototype isolé, ou fichiers projet plus mise à jour de l'arbre de planification.
2. Identifiez la racine de l'arbre de planification, la racine du plan cible, et l'intention de l'utilisateur.
3. Lisez l'index racine ainsi que seulement les fichiers pertinents de feuille de route, statut, sujet, décision, question, idée, historique ou base de référence.
4. Préservez les points d'entrée existants, les racines enregistrées, les noms de dossiers, le style de document et l'ordre d'autorité, sauf si la tâche consiste explicitement à les réorganiser.
5. Gardez les fichiers actifs de feuille de route, transfert et capsule de sujets petits ; déplacez les détails, les preuves et l'historique hors de l'état actif.
6. Mettez à jour les index, les en-têtes de récupération et les liens lors de l'ajout, du déplacement, de la promotion, de l'archivage ou du fractionnement de fichiers durables.
7. Effectuez les vérifications finales avant de répondre.
8. Signalez les fichiers modifiés, les questions non résolues, le mode actif et la prochaine action de maintenance utile, le cas échéant.

Système de Fichiers par Défaut

Utilisez docs/plantree/ comme système de fichiers par défaut pour le matériel géré par l'arbre de planification entre projets. C'est la racine du système et le registre de l'arbre de planification, pas une racine de plan unique ; le nom évite les collisions avec les dossiers plans/ natifs du fournisseur ou du framework.

Forme par défaut :

• docs/plantree/README.md : registre, ordre d'autorité, lien de base de référence, tableau des plans actifs et comment lire l'arbre.
• docs/plantree/baseline/ : contexte à l'échelle du projet, tel que la carte des modules, les flux d'exécution, les limites d'état/stockage, les portes de test/de release, et les points chauds de risque.
• docs/plantree/plans/<NNN>-<nom-du-plan>/ : racines de plan spécifiques avec un ordre numérique stable, feuille de route/statut, sujets, décisions, questions ouvertes, preuves, index et historique optionnel lorsque le projet n'a pas de convention de nommage établie.
• docs/plantree/ideas/inbox.md : boîte de réception d'idées à faible engagement.

Ordre de découverte :

1. Utilisez un chemin utilisateur explicite lorsqu'il est fourni.
2. Sinon, utilisez docs/plantree/ lorsque docs/plantree/README.md existe.
3. Sinon, préservez un autre arbre établi clairement actif pour la tâche en cours ; évaluez la migration uniquement lorsque l'utilisateur demande de l'adopter, de le normaliser ou de le migrer.
4. Sinon, amorcez docs/plantree/ avant de créer ou de mettre à jour un plan.

Les nouveaux plans spécifiques utilisent par défaut docs/plantree/plans/<NNN>-<nom-du-plan>/ lorsqu'aucune convention locale n'existe, doivent être enregistrés dans docs/plantree/README.md, et doivent lier les fichiers de base de référence pertinents au lieu de copier le contexte global. Préservez les arbres établis non numérotés ou organisés différemment, sauf si l'utilisateur approuve explicitement la migration.

Première Utilisation

Lorsqu'une tâche d'arbre de planification est invoquée dans un projet sans docs/plantree/, créez une racine minimale, sauf si l'utilisateur demande explicitement de ne pas créer de fichiers.

Amorçage :

• Racine : docs/plantree/README.md
• Base de référence : baseline/README.md, module-map.md, runtime-flows.md, storage-and-state.md, test-and-release-gates.md, risk-hotspots.md
• Conteneurs : plans/, ideas/inbox.md

Gardez le contenu d'amorçage léger et fondé sur des preuves. Si pas assez de code a été inspecté, écrivez Unknown / needs inventory au lieu d'inventer des faits sur le projet. Pour les projets anciens ou inconnus, construisez ou rafraîchissez la base de référence avant de créer un plan détaillé.

Modèle de Plan

Utilisez ces rôles lors de la création ou de la maintenance d'une racine de plan, en adaptant les noms à la convention locale :

• README.md : périmètre, autorité, carte des fichiers, chemin de lecture et registre actif lorsqu'il s'agit de la racine de l'arbre de planification. Pour les tableaux de plans actifs, préférez ID | Plan | Modules Affectés | Statut | Phase Actuelle | Dernier Atterrissage | Prochaine Cible lorsque des IDs légers sont utilisés.
• roadmap.md : état durable regroupé en Terminé, En Cours, Suivant et Reporté sauf si l'arbre utilise déjà un autre modèle.
• implementation-status.md : transfert opérationnel court pour les plans En Cours uniquement. Les plans en planification ou reportés n'ont généralement pas besoin de ce fichier.
• open-questions.md : questions non résolues uniquement.
• topics/ : contexte durable, cartes de solution, options, contraintes, critères d'acceptation, notes d'implémentation, plans d'hygiène de dépôt et analyse de risque. Gardez les fichiers de sujets de haut niveau comme des capsules courtes ; divisez les grands sujets en dossiers de sujets avec des éclats de détails.
• decisions/ : décisions stables, indexées lorsque l'ensemble grandit.
• evidence/ : enregistrements de vérification actuels ou acceptés, résultats de révision, notes d'artefact et index de preuves lorsque ceux-ci doivent être récupérés indépendamment de l'historique.
• history/ : journaux de points de contrôle acceptés, anciennes révisions, instantanés retirés, notes source d'archive uniquement et détails obsolètes.
• indexes/ : cartes de récupération optionnelles telles que les cartes de phases, les cartes de sujets, les cartes d'autorité, les cartes de migration et les cartes de preuves lorsque les index locaux résolvent un problème de navigation.
• ideas/ : pool d'idées optionnel à faible engagement lorsque les idées de niveau racine ne sont pas assez spécifiques.

Lisez references/maintenance-patterns.md lors de la création de modèles, de la gestion de grands arbres, de la maintenance de fichiers de décision/statut/transfert/historique/index, de l'ajout de plans d'hygiène de dépôt, ou lorsque vous avez besoin de la liste de contrôle détaillée des vérifications finales.

IDs Légers et Classification des Modules

Lorsqu'un projet n'a pas de convention de nommage des plans établie, utilisez des IDs légers pour améliorer la numérisation du système de fichiers et les références durables sans créer de base de données de tâches :

• Allouez des IDs de plan à l'échelle du projet comme P001, P002, etc. Mappez P001 à une racine plate telle que docs/plantree/plans/001-authentication/.
• Utilisez des nombres décimaux à trois chiffres de largeur fixe. Allouez le numéro de plan maximum retenu plus un ; ne réutilisez jamais un ID, ne comblez pas les écarts en renumérotant, et n'encodez pas la priorité, le statut, le module, le propriétaire, le travailleur, la phase ou la date.
• Gardez le slug sémantique stable et en kebab-case minuscule. Un titre ou un module affecté peut changer sans changer l'ID ou le répertoire du plan.
• Tant que le registre des plans est petit, conservez l'identité et l'enregistrement du cycle de vie dans docs/plantree/README.md. Ne le divisez en index que si cela améliore la récupération ; ne maintenez pas un registre d'allocation parallèle par défaut.
• Les IDs de tâches de la feuille de route, tels que T001, sont facultatifs et locaux au plan. Utilisez-les uniquement lorsque des références stables entre fichiers aident. Lorsqu'ils sont présents, roadmap.md est la seule autorité active pour l'identité, le statut et l'ordre des tâches ; ne créez pas de registre de tâches ou de dossier de tâches séparé par défaut.
• Les noms de fichiers de décision peuvent conserver la convention 001-<decision>.md. Les questions ouvertes peuvent utiliser Q001 lorsque des références durables aident. Les idées restent non numérotées jusqu'à leur promotion.
• Traitez les modules de code ou de produit comme des métadonnées de plan telles que Modules Affectés, en utilisant des clés stables définies dans baseline/module-map.md. Gardez les racines de plan plates par défaut ; ajoutez des index de modules ou des répertoires de modules physiques uniquement après un besoin de navigation démontré et une décision enregistrée.
• Appliquez la cohérence de même changement : mettez à jour le fichier faisant autorité et tout résumé de point d'entrée requis en un seul changement de maintenance, puis vérifiez les IDs, les chemins, les clés de module, l'unicité de la feuille de route, les revendications de statut et les liens relatifs avant de terminer.
• Préférez la détection de dérive en lecture seule à la réparation automatique. N'ajoutez pas de watchers, de renumérotation automatique, de verrous d'allocation ou de journaux de récupération jusqu'à ce que des échecs de coordination observés justifient leur coût.

Ces valeurs par défaut sont progressives. Préservez la convention locale d'ID, de problème, de ticket ou de dossier d'un arbre mature plutôt que d'ajouter un espace de noms concurrent.

Statut Dynamique et Preuves

• Seuls les plans En Cours ont besoin de implementation-status.md ; les plans En Planification doivent exprimer leur état de préparation dans roadmap.md, les sujets, les questions ouvertes ou les décisions.
• Gardez implementation-status.md opérationnel et court. Préférez moins de 100 lignes ; s'il grandit, archivez ou indexez les anciens détails.
• Gardez TODO Actif à au maximum cinq éléments en cours. Plus d'éléments signifie généralement que le travail a besoin d'une phase de feuille de route, d'un sujet ou d'un fractionnement.
• Lorsque des IDs de tâches de la feuille de route sont utilisés, réutilisez ces IDs dans TODO Actif plutôt que de reformuler l'identité de la tâche dans un deuxième registre.
• Incluez des éléments concrets Phase Actuelle, Prochaine Cible, Dernier Atterrissage, TODO Actif, Bloqué par, et Dernière Vérification ou des notes de transfert lorsque cela est applicable.
• Dernier Atterrissage doit pointer vers un commit, un artefact, un résultat de test, un point de contrôle accepté ou une autre preuve avec une date lorsque disponible.
• Utilisez evidence/README.md, indexes/evidence-map.md, ou l'équivalent local pour les preuves au niveau de la phase/package/porte. Utilisez history/evidence-index.md uniquement pour les archives de preuves obsolètes. N'enregistrez pas chaque petite étape ici.
• Les fichiers actifs de feuille de route/statut doivent lier les anciennes preuves, pas absorber les journaux répétés, les anciennes sorties d'automatisation, les détails de travail de révision ou les récits historiques.

Modèle de Récupération

L'arbre de planification est un système d'unités de récupération, pas un endroit pour faire croître de grands documents omnibus. Chaque fichier durable doit avoir un rôle principal :

• Point d'entrée ou index : routage, ordre d'autorité, chemins de lecture et résumés d'une ligne.
• État actuel : feuille de route active, phase actuelle, blocages, prochaine cible et transfert.
• Capsule de sujet : un court résumé d'un domaine, d'une fonctionnalité, d'un ensemble de contraintes ou d'un flux de travail avec des liens vers des éclats de détails.
• Éclat de détail : contrats, alternatives, cas limites, notes d'implémentation, déploiement, opérations, état de préparation ou détails d'hygiène de dépôt pour une tâche de lecture.
• Décision : un choix stable avec contexte et conséquences.
• Preuve : enregistrements de vérification, résultats de révision, liens d'artefact, résumés de tests acceptés ou index de preuves.
• Historique/Archive : statut obsolète, anciens journaux d'exécution, matériel source migré et détails retirés.

Ne laissez pas un seul fichier porter le résumé, l'état actif, les décisions, les longs raisonnements, les journaux, les preuves et l'historique en même temps. Si une mise à jour ferait franchir à un fichier sa limite de rôle, créez ou mettez d'abord à jour une unité de récupération liée, puis ne laissez que le résumé concis et les liens dans le fichier actif.

Utilisez ces nombres de lignes comme déclencheurs de fractionnement, pas comme des tests de correction stricts :

• README racine, README de plan, feuille de route et statut d'implémentation : gardez près de 150 lignes ou moins.
• Capsule de sujet : gardez près de 250 lignes ou moins.
• Éclat de détail ordinaire : fractionnez ou indexez autour de 400 lignes.
• Fichiers d'historique ou de preuves : indexez ou fractionnez autour de 500 lignes.

Lors du fractionnement...

[le contenu a été tronqué pour la traduction]