Scoville Plan

Que fait Scoville Plan ?

Gardez la direction du projet dans des fichiers de dépôt révisables sans nécessiter un CLI de planification, un serveur MCP, une base de données, un journal ou un état caché. Cette compétence gère la discipline de planification et la maintenance native des Plans et des Décisions. Elle enregistre les choix que les humains ont déjà faits et préserve un choix non résolu sous forme de proposition avant de demander sa décision de cycle de vie. Elle ne donne pas d'autorité aux choix inférés ni ne prouve que le travail signalé a eu lieu.

Conservez la surface de fonctionnalité complète prise en charge par format_version: 1 : récupération en lecture seule, configuration, Plans, Éléments de Travail, Décisions, propositions, cycle de vie, bloqueurs, preuves et réparation étroite. Utilisez des modifications natives directes sans supprimer ni réinterpréter une fonctionnalité de connaissance du projet.

En cas d'exclusion explicite, ne lisez pas les références, ne créez ni ne modifiez de fichiers de planification, et ne formulez pas de revendications dérivées de la compétence. Si une instruction de projet de priorité plus élevée nécessite ce système de Plan, signalez ce conflit exact. Une exclusion frère Scoville n'exclut que ce frère.

Suivez le propriétaire existant

Résolvez les exigences de planification dans cet ordre :

1. instructions système, de sécurité et explicites pour la demande actuelle ;
2. instructions du dépôt et son mécanisme de planification canonique existant ;
3. un profil natif pris en charge existant ; et
4. les valeurs par défaut de cette compétence pour ce qui reste non spécifié.

Ne créez jamais un deuxième plan à côté d'un plan propriétaire du projet. Si un autre système de planification durable possède déjà l'état, utilisez-le et appliquez uniquement les garde-fous de qualité de planification de cette compétence là où ils sont compatibles. Un plan d'exécution est un miroir jetable, jamais un deuxième propriétaire canonique.

Cette compétence n'a aucune dépendance exécutable obligatoire et n'invoque jamais un CLI de planification. Son validateur Python intégré est un contrôle structurel optionnel strictement en lecture seule, jamais un chemin d'écriture. Ne prétendez pas au verrouillage, à la publication atomique de plusieurs fichiers, à la sécurité de mutation typée ou à la preuve sémantique. Utilisez des outils de fichiers ordinaires et limités et ne signalez que les vérifications réellement effectuées.

Cette compétence fonctionne de manière indépendante. N'exigez, n'installez ni ne simulez jamais Code, UI ou Scribe. Lorsqu'un frère est applicable de manière indépendante, n'en composez que son implémentation, son interface ou son domaine de formulation propres ; son absence n'affaiblit pas la structure du Plan, le cycle de vie, l'autorité ou les règles de preuve.

Décidez si une planification durable est justifiée

Utilisez un Plan de dépôt pour plusieurs résultats dépendants, un séquencement matériel, un travail qui doit survivre à des interruptions ou à un passage de relais, ou un workflow de projet contraignant. Pour un petit changement réversible, implémentez et validez directement, sauf si le projet exige déjà un Élément de Travail suivi.

Classez l'opération avant de charger les détails :

Opération	Charger
Lire la direction actuelle ou lister les enregistrements sans écrire	read-only.md
Initialiser un profil entièrement absent	planning-granularity.md, native-plan-format.md, native-project-lifecycle.md et native-editing.md
Créer ou restructurer un Plan	planning-granularity.md, native-plan-format.md, native-project-lifecycle.md et native-editing.md
Insérer, affiner, déplacer, sélectionner, bloquer, avancer ou supprimer un Élément de Travail	native-plan-format.md, native-work-items.md et native-editing.md
Enregistrer un choix humain explicite ou une Décision matérielle possible	native-decision-format.md, native-plan-format.md et native-editing.md
Appliquer une transition de Décision explicitement autorisée	native-decision-format.md, native-plan-format.md et native-editing.md
Appliquer un lot d'acceptation ou de rejet explicitement autorisé	native-decision-format.md, native-decision-batches.md, native-plan-format.md et native-editing.md
Activer, terminer ou annuler un Plan	native-plan-format.md, native-project-lifecycle.md, native-work-items.md lorsque le travail en cours change, et native-editing.md
Auditer la structure ou le cycle de vie d'un Plan natif	native-plan-format.md ; ajoutez planning-granularity.md uniquement lors du jugement de la décomposition
Auditer la structure ou le cycle de vie d'une Décision native	native-decision-format.md
Valider après des écritures natives ou diagnostiquer un profil complet pris en charge	Exécutez la vérification groupée via profile-validation.md, puis chargez uniquement la référence native nécessaire pour un diagnostic ou une correction signalé

Ne préchargez pas les détails du format pour une réponse de statut en lecture seule.

Lorsque l'existence du profil est inconnue, listez la racine du projet avant de lire tout chemin canonique. Si PROJECT_INDEX.md est absent, n'essayez pas de le lire. Pour un nouveau Plan durable explicitement demandé, traitez l'espace de travail actuel comme la racine de configuration, classifiez le profil complet et initialisez uniquement lorsque les trois chemins canoniques sont totalement absents. Si la création n'a pas été demandée, signalez qu'aucun profil n'existe au lieu d'en initialiser un implicitement. Préservez et arrêtez-vous sur un profil partiel, étranger, non pris en charge ou dont l'intention est invalide.

Préservez l'autorité et les preuves

• N'inventez jamais l'Objectif, les Non-objectifs, le résultat d'acceptation, le bloqueur, la dépendance, la preuve ou un choix de cycle de vie accepté. Traitez l'implémentation, la documentation ordinaire, le code source, le silence et le comportement actuel comme des preuves, pas comme une autorisation humaine.
• Demandez avant l'activation, l'annulation, un changement de périmètre, une acceptation plus faible, un successeur ambigu, ou l'adoption d'un choix matériel simplement possible.
• Lorsque l'utilisateur sélectionne explicitement une direction, demande à la conserver dans les règles du projet, ou qu'une instruction de projet applicable indique sans équivoque une direction choisie par l'humain, créez et acceptez la Décision correspondante sans redemander. Liez chaque Élément de Travail mutable affecté.
• Lorsque l'analyse ne révèle qu'une Décision matérielle possible concernant le périmètre, l'architecture, le comportement public, les données stockées, la sécurité, les dépendances, la réversibilité, l'acceptation, la migration ou le déploiement, créez-la comme proposed, liez chaque Élément de Travail mutable affecté, signalez sa recommandation, ses alternatives, ses compromis et son effet pratique, puis demandez à l'utilisateur de l'accepter, de la rejeter ou de la réviser. Ne l'acceptez pas avant cette réponse.
• Une demande de rédaction d'une proposition crée proposed. Un choix clair d'enregistrer la direction énoncée autorise son acceptation. Ne rejetez, ne dépréciez ni ne remplacez jamais une Décision sans ce choix de cycle de vie explicite.
• Au début du travail sur le projet, faites l'inventaire du frontmatter des Décisions, lisez chaque proposition, signalez son ID, son titre, le choix recommandé et son effet pratique, et demandez à l'utilisateur de l'accepter, de la rejeter ou de la réviser. Répétez les propositions non résolues lors du passage de relais. Seul le travail dépendant s'arrête.
• Marquez un Élément de Travail comme done uniquement après avoir observé son résultat d'Acceptation et ajouté une preuve concise. Une vérification de forme de fichier ne prouve que la structure.
• Laissez le travail échoué ou partiel comme in_progress, paused ou explicitement bloqué.

Gardez des Éléments de Travail complets en comportement

• Gardez au plus un Élément de Travail in_progress, égal à current_item. Cela limite l'exécution simultanée ; cela ne limite pas un Plan à un seul Élément de Travail au total.
• Séparez les résultats pouvant être repris indépendamment avec des limites d'acceptation distinctes, des dépendances, des propriétaires ou un calendrier de déploiement en Éléments de Travail séparés.
• Gardez l'ordre d'implémentation à l'intérieur des Étapes optionnelles. Les vérifications de test, de révision, de documentation et de publication appartiennent à l'Acceptation ou aux Preuves, sauf si des livrables demandés indépendamment nécessitent leur propre résultat pouvant être repris.
• Modifiez le contenu ou l'ordre créé uniquement lorsqu'un élément est todo. Une fois commencé, préservez son approche de départ et mettez à jour uniquement l'état en direct.
• Gardez Next action égal à la première action concrète non encore effectuée. Une fois l'implémentation existante, avancez-la à la prochaine vérification non observée de test, de construction, de navigateur, de révision ou de vérification appartenant à l'évaluateur.
• Sélectionnez un nouveau travail en cours uniquement lorsque ses dépendances sont terminées et que le successeur est explicite. Utilisez complete_and_advance uniquement lorsque la terminaison et le début du remplacement exact sont tous deux valides en tant que résultat préparé.
• Lorsque le travail réel final se termine, terminez son Élément de Travail et son Plan et définissez l'index du projet sur inactif. N'inventez jamais un successeur simplement pour le maintenir actif.

Travaillez nativement et étroitement

Avant d'écrire, confirmez la racine du projet, le format pris en charge, le Plan actif, l'Élément de Travail actuel, les octets affectés, le résultat observable et la preuve d'acceptation. Utilisez des correctifs contextualisés et préservez le travail non lié. Préparez un changement multi-fichier complet avant d'appliquer un membre, tout en reconnaissant que les modifications directes ne sont pas atomiques.

Après l'écriture :

1. relisez chaque fichier canonique modifié ;
2. inspectez le diff complet et limité ;
3. vérifiez la propriété de l'index, le nombre de Plans actifs, le statut de l'élément actuel, l'ordre des clés des Éléments de Travail, l'ordre et les cycles des dépendances, les références aux Décisions et Plans, les bloqueurs, les champs de cycle de vie, les Preuves et la Next action ;
4. exécutez le validateur optionnel groupé via profile-validation.md lorsque son script et Python sont déjà disponibles, sinon effectuez et signalez l'inspection manuelle limitée ; et
5. enregistrez uniquement les preuves d'acceptation observées.

Arrêtez-vous en cas de format non pris en charge, de modifications simultanées, d'autorité de cycle de vie ambiguë, d'état invalide dont la réparation modifierait l'intention, ou de transition multi-fichier partielle. N'écrasez pas le problème pour lui donner une validité apparente.

Signalez l'état durable

Commencez par le résultat actuel du Plan. Nommez les fichiers canoniques modifiés, le travail actif et bloqué, les vérifications observées, les preuves enregistrées, les choix matériels non résolus et la prochaine action concrète. Distinguez l'inspection structurelle native de la vérification comportementale. Ne racontez pas les opérations de fichier de routine.