Lujker/road-map-journal

Feuille de route et journal de travail

Maintenez un plan actuel utile et un enregistrement traçable des décisions sans imposer une nouvelle structure. Suivez les instructions de l'utilisateur et les conventions du projet. Préservez les noms, identifiants, langue, liens, modifications non validées et contenu non lié existants. Pour un nouveau plan, utilisez la langue que l'utilisateur spécifie ou que vous pouvez raisonnablement déduire ; demandez si ce n'est pas clair. N'imposez pas de langue.

Quand l'utiliser

Utilisez pour les demandes concernant une feuille de route, un plan de développement, une file d'attente, un journal de travail, un état d'élément, ou la poursuite d'un travail planifié. Les exemples incluent « quelle est la prochaine étape de la feuille de route ? », « continue l'élément convenu », « дорожная карта », « план разработки », « дневник разработки », « что дальше по плану? » et « продолжай разработку по плану ». Déterminez la portée demandée à partir du contexte ; une question de statut est en lecture seule.

Découvrir d'abord

Identifiez la racine du projet et lisez ses instructions. Localisez les feuilles de route, files d'attente, notes d'élément et documents de transfert existants ; les noms et emplacements varient. Lisez l'élément concerné, ses critères d'acceptation, la file d'attente actuelle et les notes liées. Vérifiez la mise en œuvre concernée, l'état du contrôle de version s'il est disponible, et les preuves lorsque la demande nécessite une évaluation de l'état actuel. Ne présumez pas de Git, d'une disposition de répertoire spécifique ou d'un vocabulaire de statut particulier. Pour plusieurs dépôts, suivez les liens existants ; demandez un emplacement faisant autorité inaccessible plutôt que d'inventer un remplacement.

Sélectionnez le mode implicite de la demande :

• Lecture seule : Répondez à partir des documents pertinents et des preuves. Distinguez les affirmations enregistrées des faits vérifiés de manière indépendante ; n'apportez aucune modification.
• Initialisation : Si aucun plan n'existe, discutez de la méthode de travail souhaitée par le propriétaire et proposez une structure adaptée, un emplacement, une portée, des éléments initiaux et leur ordre ; incluez les pistes, les rôles des agents et les fiches initiales si pertinent. Pour une exploration plus approfondie, utilisez grill-me si disponible et approprié ; si absent, proposez de l'installer, mais ne l'installez pas sans autorisation ou ne bloquez pas le flux de travail. Sinon, facilitez vous-même une discussion structurée concise, avec des recommandations pour les choix non résolus. Obtenez le consentement éclairé de l'utilisateur avant de créer des fichiers ; n'inventez pas de priorités ou d'engagements.
• Adoption : Si du matériel de planification existe déjà, utilisez-le en l'état. Lorsque le propriétaire demande une révision substantielle, utilisez la même discussion structurée facultative que pour l'initialisation, adaptée à ce qui n'est pas résolu. Expliquez tout nouveau fichier proposé, toute migration ou toute réécriture substantielle et obtenez d'abord un consentement éclairé. Ne créez pas silencieusement une source de vérité parallèle.
• Reprise : Lisez la dernière directive, la file d'attente active, les notes d'élément et l'état actuel pertinent. Résolvez les instructions contradictoires ou obsolètes en fonction des preuves actuelles et de la dernière décision de l'utilisateur ; demandez si un conflit important persiste. Si l'élément n'est pas déjà sélectionné ou délégué, convenez-en avant la mise en œuvre. Un plan sauvegardé ou une approbation pour documenter n'est pas une autorisation pour commencer le travail.
• Mise à jour : Effectuez les modifications demandées et délimitées aux enregistrements existants. Maintenez la cohérence du statut de l'élément, du travail restant et des entrées de file d'attente affectées ; préservez l'historique et l'ordre non lié. Pour un nouveau fichier ou une réécriture substantielle, expliquez le changement proposé et obtenez d'abord un consentement éclairé. Une demande limitée à un élément n'autorise pas la mise en œuvre ou la réécriture du reste du plan.

Enregistrer et réconcilier

Utilisez l'agencement établi du projet. En règle générale, une feuille de route résume les éléments et leur ordre actuel ; un journal contient les décisions, les constats, les preuves et l'historique. Liez plutôt que de dupliquer les longs détails. Gardez les identifiants stables. Ne supprimez pas silencieusement les décisions ou le travail annulé : marquez-les comme remplacés ou annulés avec la raison si pertinent.

Lorsqu'une décision, une pause ou un ordre change, mettez à jour les résumés actuels concernés et les instructions de prochaine étape dans la portée autorisée ; étiquetez les instructions antérieures comme historiques. Un plan mis en pause ou différé ne doit pas apparaître comme une instruction active pour continuer. Ne réordonnancez pas un travail non lié simplement parce qu'une note a été ajoutée. Si une correction nécessaire dépasse la portée autorisée, signalez-la à l'utilisateur plutôt que d'étendre la modification.

À moins que le propriétaire n'ait autorisé une portée plus large, travaillez sur un élément à la fois et ne commencez pas automatiquement le suivant. Une sous-étape terminée ne termine pas l'élément parent ; enregistrez le reste. Gardez le mode de travail séparé des autorisations et des budgets : l'autorisation de continuer n'est pas une autorisation générale pour des actions de production ou des écritures externes. Gardez distincts l'achèvement enregistré, l'acceptation utilisateur en attente et le travail pleinement accepté. Gardez des points de contrôle concis lors des transferts, des décisions, des résultats vérifiés et des blocages, y compris ce qui reste et comment reprendre ; vérifiez les actions en cours incertaines avant de les répéter. Avant une mise à jour multi-fichier dans un checkout partagé, vérifiez l'état du contrôle de version et les chemins sales immédiatement avant d'écrire, appliquez des modifications étroites sur un contenu fraîchement lu, préservez le travail non lié et vérifiez les modifications délimitées sans valider ni publier sauf autorisation.

Pour un travail qui s'étend sur plusieurs éléments, agents ou sessions, qui a un budget, ou où le propriétaire autorise une piste ou un mode continu, lisez d'abord Travail de longue durée.

Statut et preuves

Utilisez le vocabulaire de statut du projet. S'il n'en existe pas, suggérez OUVERT, EN COURS, BLOQUÉ, PARTIEL et TERMINÉ, avec des significations convenues pour le projet. Enregistrez le statut en fonction des critères d'acceptation et des preuves réelles, et non de l'intention ou d'une affirmation non étayée d'un délégué. Pour PARTIEL, nommez ce qui reste et tout bloqueur. Gardez les références de statut affectées cohérentes.

Enregistrez les vérifications réellement effectuées, leurs résultats et leur portée, et qui les a effectuées si pertinent. Les preuves peuvent être historiques ou provenir d'un autre exécuteur ; étiquetez leur source et leur applicabilité, et n'impliquez pas qu'elles ont été réexécutées. Si des modifications ultérieures invalident une vérification, identifiez ou effectuez la vérification appropriée. N'inventez jamais de commandes, résultats, nombres de tests, approbations ou acceptation utilisateur. Les tests automatisés, le code publié et l'exploitation en direct sont des affirmations différentes : n'inférez jamais une acceptation en direct à partir de la mise en œuvre ou des tests. Si l'acceptation requise n'a pas eu lieu, conservez PARTIEL ou l'équivalent du projet et indiquez l'environnement ou l'approbation manquante.

Après une modification autorisée, vérifiez le statut affecté, la file d'attente, les liens et la cohérence avec les preuves et la portée. Signalez les modifications, les vérifications réellement effectuées et les éléments non résolus. Ne revendiquez pas une vérification qui n'a pas été effectuée.

Références

• Modèles génériques — points de départ facultatifs, adaptés au projet.
• Scénarios — exemples concis de choix de mode et de portée.
• Travail de longue durée — pistes, points de contrôle, pause et arrêt, acceptation, budgets, checkouts partagés.
• Réconciliation multi-dépôts — préservez le travail et distinguez l'état enregistré, Git et en direct dans les checkouts.