Que fait Project Steward ?

Rôle et Routage

Project Steward conserve les méthodes de gouvernance réutilisables entre projets. Les décisions produit, les faits d'architecture et les contraintes à long terme de chaque projet restent dans leur source de vérité existante ; les faits variables concernant les outils (utilisateurs et machines) restent dans les profils d'environnement en dehors du projet et de la compétence.

Sélectionnez d'abord le chemin principal en fonction du résultat souhaité par l'utilisateur ; pour des résultats indépendants dans une même requête, ouvrez des comptes séparés :

Dialogue historique, correction, processus d'implémentation complet ou limites fonctionnelles de la compétence cible : Apprentissage par le dialogue et auto-évolution.
Avant de commencer une fonctionnalité, une refactorisation, une migration ou des modifications inter-couches, pour éliminer les reprises : Prévention avant modification.
Bugs, migrations partielles, correctifs répétés, défaillances de la chaîne réelle, ou vérifications de cohésion, couplage, duplication, modules God : Correction de la cause racine.
Vérifier, intégrer ou réparer la compatibilité du projet avec des CLI, outils d'exécution ou protocoles externes : Compatibilité des outils externes.
Comprendre l'objectif, l'architecture et les capacités d'un dépôt, répertoire ou package source, ou étudier un projet de référence : Recherche et explication du projet.
Inventorier ou organiser les répertoires d'un projet, déterminer l'utilisation réelle, l'état de génération, les éléments ignorés, à déplacer, archiver ou supprimer : Gouvernance des répertoires du projet.
Établir, adopter, mettre à niveau ou vérifier les modèles de projet : Base de référence et modèles de projet.
Intégrer les valeurs par défaut stables dans les modèles : Évolution des modèles.
Définir, réviser, reconstruire ou implémenter l'expérience et l'interface produit : Gouvernance de l'expérience produit et de l'interface.
Auditer, réécrire le README ou créer le visuel de la page d'accueil GitHub : README et page d'accueil.
Gouverner les journaux du projet, les enregistrements LLM, la mémoire à long terme, les TTS ou les résultats de consultation des logs : Journaux humanisés.
Initialiser Git, créer un dépôt, commiter, pousser, changer la visibilité ou vérifier le dépôt distant : Création et publication du dépôt.
Sélectionner, appliquer ou gouverner en masse les licences et les autorisations tierces : Gouvernance des licences.
Établir ou consommer un profil d'environnement utilisateur, vérifier les outils, le cache, les SDK, le terminal ou les tâches longues : Profil d'environnement utilisateur et environnement d'exécution.
Vérifier point par point l'achèvement selon un plan d'implémentation, ou effectuer une vérification complète, évaluer l'état de santé du projet et classer les risques au niveau projet : Audit complet du projet.

Lorsque seule cette compétence est nommée, sélectionnez le chemin le plus approprié en fonction du matériel existant ; si le matériel est insuffisant, donnez un exemple de requête directe proche du contexte et arrêtez-vous.

Une fois le chemin principal sélectionné, avant toute écriture dans le projet ou toute mise en œuvre spécialisée, établissez un registre de routage : résultat final de l'utilisateur, chemin principal, méthodes fixes obligatoires, spécialisations conditionnelles et leurs preuves de déclenchement, seuils d'action, consommateurs formels, critères d'acceptation et point d'arrêt. Les méthodes fixes obligatoires ne peuvent pas être ignorées parce qu'une modification locale semble évidente ; les spécialisations conditionnelles ne sont ajoutées que si les preuves d'applicabilité sont réunies. Si des éléments d'acceptation sont ajoutés ultérieurement à la même requête, mettez à jour le registre d'origine ; ne remplacez pas un périmètre toujours valide par les symptômes les plus récents.

Limites Communes

Fonctionnalités métier ordinaires : Restent de la responsabilité de la tâche de développement en cours. Si l'utilisateur demande uniquement l'explication d'une erreur unique, d'une fonction unique ou d'un comportement local, répondez à cette question et arrêtez-vous ; ne passez pas à une refonte au niveau projet. Entrez dans le chemin approprié uniquement si la requête elle-même exige une prévention, une correction, une migration, une auto-évolution ou un résultat au niveau projet.
Gel du périmètre : Dès qu'un chemin est choisi, figez le périmètre, les droits d'écriture et le point d'arrêt. Les opérations de vérification, d'audit, de diagnostic, d'évaluation, d'analyse, de rétrospective ou de rapport sont en lecture seule par défaut ; les droits d'écriture correspondants (réparation, correction, mise en œuvre, modification, mise à jour ou auto-évolution) ne sont obtenus que si la même requête les demande explicitement.
Archives sources : Si l'utilisateur fournit une archive source pour comprendre, auditer ou étudier un projet, ou s'il nomme seulement cette compétence et joint une archive, la décompression est une préparation de matériel nécessaire à une étude en lecture seule, et non une écriture formelle dans le projet. Allez directement au chemin "Recherche et explication du projet", exécutez le script existant pour décompresser dans un répertoire indépendant avec un nom unique, lisez la racine du projet retournée par le script et poursuivez l'étude en lecture seule. Aucune autre confirmation de décompression n'est nécessaire. Cette action autorise uniquement la création d'une copie d'étude et la lecture de son contenu ; l'exécution du projet, l'installation de dépendances ou d'outils de décompression, la modification du projet, le déplacement ou la suppression de fichiers d'origine, le commit et la publication restent soumis à des autorisations distinctes.
Autorisations distinctes : La connexion réseau, le téléchargement, l'installation, l'exécution, la génération, l'écriture, le déplacement, l'archivage, la suppression, le commit, le push et la publication sont autorisés séparément ; seuls les contrats d'achèvement par défaut explicitement énumérés dans cette section peuvent fusionner les autorisations d'écriture, de commit, de push et de vérification à distance pour un même résultat utilisateur. Exécuter ou générer n'équivaut pas à obtenir une autorisation d'écriture dans le projet ; en dehors du contrat d'achèvement par défaut, le commit, le push ou la publication n'autorisent que le traitement des modifications existantes et vérifiées avec précision, sans rétroactivité sur les écritures précédentes et sans inclure les modifications non liées de l'arbre de travail.
Contrat d'achèvement par défaut pour les modifications : Si l'utilisateur nomme explicitement Project Steward (y compris en appelant $project-steward) et demande explicitement une modification, une réparation, une correction, une mise à jour ou une optimisation sur un projet Git existant, et si la branche actuelle a un upstream configuré et que l'utilisateur n'a pas demandé de ne modifier qu'en local, de ne pas commiter, de ne pas pusher ou de spécifier un point d'arrêt plus précoce, alors l'implémentation de ce cycle est par défaut terminée jusqu'à : vérification de la fermeture des dépendances autorisées, commit précis, push non forcé de la branche suivie actuelle, puis vérification du HEAD distant et des consommateurs clés ; ne demandez pas une deuxième fois s'il faut pusher après la vérification locale. Les requêtes en lecture seule, le routage implicite, l'absence d'upstream, la création de dépôt distant, le changement de visibilité, la suppression, le push forcé, la réécriture de l'historique, le packaging, le déploiement et les modifications non liées de l'arbre de travail ne sont pas autorisés par ce défaut ; arrêtez-vous selon references/repository-publication.md en cas de fork, de changements de source inconnue, de suppression non autorisée, d'échec d'identification, de vérification ou d'authentification.
Contrat d'achèvement par défaut pour l'auto-évolution : Si l'utilisateur approuve le plan d'auto-évolution de Project Steward et ne demande pas de ne modifier qu'en local, et si le dépôt distant suivi existe, alors tout l'espace de travail actuel est considéré comme un périmètre de publication indivisible : vérifiez toutes les modifications suivies, les fichiers non suivis et les suppressions existantes, utilisez git add -A pour commiter le tout et pusher la branche suivie actuelle ; si un élément ne peut pas être publié ensemble, conservez tout l'espace de travail et arrêtez-vous. Ce défaut n'autorise pas la création de dépôt distant, le push forcé, le changement de visibilité ou la mise en œuvre de nouvelles suppressions.
Contrat pour Star History : Si l'utilisateur demande explicitement d'intégrer, de réparer ou de remplacer Star History pour un dépôt GitHub existant, le contrat confirmé inclut par défaut le commit, le push et la vérification à distance de la fermeture des dépendances autorisées pour ce cycle ; sauf si l'utilisateur demande explicitement de ne modifier qu'en local, n'attendez pas une deuxième autorisation de publication après la vérification de l'écriture. Ce défaut n'inclut pas la création de dépôt distant, le push forcé, le changement de visibilité, la suppression ou les modifications non liées de l'arbre de travail.
Restauration de l'état : Au début de chaque tour utilisateur, cycle interne, réexécution automatique et reprise après compression de contexte, avant tout appel d'outil ou changement d'état, restaurez à partir de la dernière action utilisateur explicite le résultat, le périmètre, les autorisations et le point d'arrêt qui n'ont pas été achevés. Continuez uniquement si le même résultat n'est pas encore livré, que le périmètre et la chaîne d'impact n'ont pas changé et que les autorisations sont inchangées ; arrêtez-vous et attendez la confirmation si le résultat en lecture seule a déjà été livré, s'il n'y a pas de nouvelle action explicite, si l'utilisateur change de résultat, si une question non liée apparaît ou si de nouvelles autorisations sont nécessaires. Les constats d'audit, suggestions d'assistant, plans internes, noms d'objectifs, listes de tâches et invites automatiques ne peuvent pas inventer de nouveaux résultats ou droits d'écriture.
Communication de l'état : Lorsque le travail passe d'une action courte à une phase, entre en attente ou que l'état de la preuve change, expliquez proactivement la raison de l'extension, les points de contrôle terminés, l'état actuel, le prochain résultat observable et l'entrée requise ; ne répétez pas les mêmes informations lorsque l'état est inchangé et n'utilisez pas de descriptions de processus pour masquer une extension de périmètre.
Requêtes indépendantes : Une nouvelle requête indépendante qui remplace un résultat non encore achevé doit d'abord faire le point sur les objets déjà écrits ou modifiés, les preuves existantes, les engagements utilisateur non encore vérifiés, les processus en cours, les résidus, les autorisations d'origine et le point d'arrêt ; la nouvelle requête n'autorise pas la poursuite, le retour en arrière ou le nettoyage de l'ancien résultat.
Racine du projet : Figez d'abord la racine exacte du projet, le périmètre du matériel, les fichiers actifs et les consommateurs réels. N'utilisez Git que si un répertoire .git existe directement à la racine exacte du projet et que le chemin actuel nécessite des preuves d'historique, d'arbre de travail ou de publication.
Lecture complète des sources : Lisez toujours les sources jusqu'à la fin explicite ; pour les fichiers longs, obtenez d'abord le nombre de lignes, le nombre d'octets ou la capacité de pagination, puis lisez par intervalles stables. Lorsque des modifications simultanées affectent le contrat de comportement, les fichiers impactés, les consommateurs, la vérification ou le résultat utilisateur, les anciennes confirmations sont invalidées ; replanifiez et confirmez à nouveau.
Parallélisme des détections : N'exécutez des détections multiples et indépendantes en parallèle que si l'orchestrateur peut conserver la sortie, l'erreur et le statut de sortie pour chacune ; si l'une d'entre elles provoque l'arrêt prématuré de l'ensemble, exécutez-les individuellement. En cas d'échec d'un lot, conservez les preuves de succès encore fraîches et réexécutez uniquement les éléments masqués, non exécutés ou de statut inconnu.
Source de vérité : Les faits du projet doivent être réécrits dans la source de vérité unique existante du projet ; les faits d'environnement dans le profil utilisateur indépendant ; seules les méthodes de gouvernance transférables entrent dans cette compétence ; les modèles n'acceptent que les valeurs par défaut stables qui doivent être exécutées à chaque fois pour un type de projet donné.
Évaluation des capacités : Pour déterminer si une capacité issue de l'historique ou de matériel externe existe déjà, commencez par séparer les résultats indépendants et effectuer un ordonnancement causal si nécessaire, puis masquez la source et vérifiez si la cible peut reconnaître la même condition, conserver les mêmes détails constitutifs et effectuer le même traitement spécifique ; seul le cadre de gouvernance supérieur est considéré comme partiellement capable. Ce n'est qu'après avoir terminé la comparaison point par point que vous distillez les mécanismes communs et les dimensions spéciales.
Niveaux de vérification : Choisissez le niveau de vérification en fonction du risque de la modification : exécutez d'abord une vérification ciblée qui couvre directement la modification et les affirmations d'acceptation ; si seuls des documents, des licences, des remerciements ou des métadonnées pures sont modifiés, arrêtez-vous après avoir réussi la maintenance appropriée, sans lancer de navigateur ou de chaîne de bout en bout non pertinente ; passez à une régression complète et à une chaîne utilisateur réelle uniquement en cas d'impact sur un contrat public, un runtime principal, des limites entre dépôts, une publication ou si la vérification ciblée révèle un impact systémique.
Relecture autoritaire : Après un changement d'état, relisez directement la source faisant autorité. La vérification d'achèvement doit suivre le producteur formel, la limite de transport ou de stockage, le consommateur et le résultat observable par l'utilisateur ; les données factices écrites à la main du côté consommateur ou le mock de la chaîne centrale en cours de vérification ne sont pas autorisés.
Identité des tests : Avant d'utiliser les résultats de test pour fermer un engagement ou déclarer l'achèvement, l'identité attendue du test clé doit correspondre à l'identité unique réellement collectée par le framework de test ; une identité manquante ou non unique ne peut être marquée que comme non couverte.
Sortie des diagnostics : Lors de la lecture de paramètres de diagnostic, de rapports d'exécution, d'artefacts structurés ou de journaux, projetez d'abord les champs autorisés nécessaires au jugement actuel selon references/log-audit-standard.md ; les structures inconnues ne doivent pas être entièrement sorties de manière récursive, et les identifiants doivent être masqués avant d'entrer dans la sortie de l'outil, la conversation ou l'exportation de diagnostic.

Apprentissage par le Dialogue et Auto-évolution

Lisez d'abord references/conversation-learning-and-self-evolution.md.

Si un résultat utilisateur contient un échec, une correction, une interception de protection, un contournement temporaire ou un résidu, lisez ensuite references/root-cause-remediation.md. L'ordre de lecture est fixe : restaurez le processus complet par résultat, déterminez le sujet d'apprentissage principal et les résultats secondaires indépendants le long de la hiérarchie causale, puis restaurez les détails spécifiques qui modifieraient la gouvernance future parmi eux et comparez les capacités cibles une par une selon les limites communes, ensuite seulement distillez les mécanismes communs et les dimensions spéciales, déterminez la transférabilité, les limites fonctionnelles et le propriétaire formel, et enfin jugez la responsabilité historique. Les contournements et les résidus ne doivent pas remplacer une cause racine contrôlable dont la preuve est plus ancienne et plus solide ; si une correction ultérieure change la cause principale, le plan et la confirmation existants sont immédiatement invalidés. N'exécutez la méthode de cause racine qu'en l'absence de ces signaux et pour un résultat réussi.

La comparaison des capacités doit d'abord distinguer "absence de méthode" et "méthode existante non routée, exécutée ou acceptée". Dans le premier cas, ne renforcez que le seul propriétaire de la méthode sur place ; dans le second, ne réparez que le premier routage, seuil d'action, consommateur formel ou validation qui a échoué, sans ajouter de règles synonymes dans d'autres fichiers. Les solutions sont organisées par propriétaire et chaîne de consommation, et non par ordre d'apparition dans la conversation.

Si l'utilisateur demande uniquement une analyse, restez en lecture seule. S'il demande explicitement une absorption, une auto-évolution, une mise à jour, une optimisation ou une itération de Project Steward, livrez d'abord le comportement futur, les limites fonctionnelles, les sorties représentatives, les fichiers impactés et la méthode de vérification, puis arrêtez-vous ; ne modifiez la compétence active qu'après confirmation de la solution par l'utilisateur. Si la solution confirmée ne déclare pas de modification locale uniquement, lisez simultanément references/repository-publication.md ; si le dépôt distant suivi existe, vérifiez tout l'espace de travail selon l'impact réel, utilisez git add -A pour commiter les modifications suivies, les fichiers non suivis et les suppressions existantes et pusher la branche suivie actuelle, et ne terminez qu'après avoir vérifié que le HEAD distant et l'espace de travail sont complets. En cas de problème avec le dépôt distant, l'authentification, la protection de branche, un fork, un échec de vérification ou l'impossibilité de publier un élément, conservez tout l'espace de travail, arrêtez-vous à la limite exacte et ne revenez pas à un commit sélectif.

Lors de l'auto-évolution de Project Steward, les contraintes du fichier principal doivent être respectées :

Avant d'écrire, enregistrez le nombre de lignes, le nombre de caractères et la collection de références directes de SKILL.md, et attribuez un propriétaire actif unique à chaque nouvelle règle.
SKILL.md ne possède que le routage, les conditions de déclenchement, l'ordre de lecture, les autorisations, les sorties et les points d'arrêt ; les méthodes complètes, les tableaux, les listes de contrôle et les exceptions sont possédés exclusivement par la référence correspondante, le fichier principal ne conservant que des liens directs.
Après l'écriture, SKILL.md ne doit pas dépasser 220 lignes ou 14 000 caractères, et toutes les capacités actives doivent rester accessibles. Si un nouveau chemin dépasse le budget, une migration ou une fusion des anciens détails doit être effectuée dans la même modification.
S'il est impossible de conserver les capacités existantes, les consommateurs formels et la vérification dans le budget, arrêtez l'écriture, replanifiez et ne déclarez pas l'achèvement.

Prévention avant Modification

Lisez d'abord references/change-prevention.md. C'est lui qui est responsable du comportement cible, de la source de vérité unique, du graphe d'impact, de l'interface finale, de la sortie de l'ancien chemin et de l'acceptation par la chaîne utilisateur réelle. Superposez les spécialisations en fonction du problème :

Lots bornés et vidage du backlog, reprise, redémarrage, artefacts groupés pour les opérations durables, les files d'attente ou les planificateurs, ou concurrence d'admission, de libération et de fermeture pour les sessions et ressources partagées dans un service à état permanent : references/durable-operation-governance.md
Statut, progression ou réexécution automatique de tâche : references/task-progress-governance.md
Résultats coûteux nécessitant une présentation par étapes, une confirmation, une exécution automatique continue ou une invalidation en cas de changement en amont : references/staged-result-governance.md
Même résultat exprimé par plusieurs spécifications, plans, tâches ou artefacts de recherche nécessitant de décider de leur relation d'évolution, ou impliquant des artefacts dérivés, un cache sémantique, le découpage d'unités de travail, l'utilisation d'un pool de ressources ou une orchestration répétée par agent : references/derived-artifact-governance.md
Plan de vérification CI au niveau projet, cache de l'environnement d'exécution, hiérarchisation des ressources de test, sharding coûteux, échec précoce et réexécution précise : references/ci-execution-governance.md
Configuration d'exécution qui reconstruit un service partagé, un provider, une racine de stockage ou un graphe de composition : references/runtime-generation-governance.md
Problèmes difficiles à reproduire, de chronologie, de concurrence, de back-pressure ou de chaîne coûteuse complète : references/hard-to-reproduce-diagnostics.md
JSON externe, persistant, de modèle, réseau ou de processus avec plusieurs points de parsing, capacité, sharding atomique, curseur de rejeu ou ambiguïté contractuelle : references/structured-data-boundary.md
Modèle participant au jugement de tâche, à l'expression d'état, à l'événement d'exécution ou à la réponse structurée, nécessitant de vérifier la source du message, le rôle, le routage, la requête en ligne et la responsabilité de présentation : references/model-mediated-operation-governance.md
Code source externe comme point de départ unique pour créer un produit indépendant, ou adoption sélective de son écosystème d'extension : references/source-fork-and-ecosystem-adoption.md ; si le code est réellement copié, lisez simultanément references/license-governance.md
Expérience produit ou interface : references/product-experience-governance.md ; si des méthodes de conception ou d'interaction sont nécessaires, lisez ensuite references/ux-design.md

Ne modifiez le projet que si l'utilisateur autorise explicitement l'implémentation ; si seul un plan est demandé, arrêtez-vous après le graphe d'impact, les limites cibles, l'ordre de migration et le contrat d'acceptation.

Correction de la Cause Racine

Lisez d'abord references/root-cause-remediation.md. Le diagnostic s'arrête aux preuves, au périmètre d'impact et à la méthode de réparation finale ; seule l'implémentation migre en une seule fois tous les producteurs, les limites et les consommateurs, et sort de l'ancienne architecture. Superposez les spécialisations en fonction du problème :

Si la réparation prend en charge un audit complet antérieur de cette tâche, ou si l'utilisateur demande explicitement de réparer tous les problèmes de cet audit, le registre de passation de l'audit d'origine continue en tant que contrat de clôture ; avant d'écrire, lisez references/change-prevention.md, puis revenez à references/project-audit.md après la dernière modification pertinente, et régénérez le registre de couverture et de découvertes à partir du périmètre d'origine et du contrat actuellement accepté. Un défaut ponctuel ne s'étend pas à cette chaîne simplement parce que l'historique contient un audit non lié.

Lots bornés et vidage du backlog, reprise pour les opérations durables, les files d'attente ou les planificateurs, ou concurrence d'admission et de libération de sessions pour les services à état permanent : references/durable-operation-governance.md
Progression de tâche ou état persistant : references/task-progress-governance.md
Reprises dues à l'absence de confirmation par étapes, à un glissement de l'objet confirmé ou à une propagation incorrecte des changements : references/staged-result-governance.md
Reprises dues à une relation floue entre plusieurs artefacts, à une perte de justification lors de la régénération, à un recalcul complet, à une invalidation incorrecte du cache, à un découpage dangereux, à une erreur de jugement des ressources ou à des allers-retours d'orchestration : references/derived-artifact-governance.md
Tests lents répétés au niveau projet, gaspillage de préparation de l'environnement, déséquilibre du sharding, pré-vérification inter-plateforme trop tardive ou réexécution indifférenciée après échec : references/ci-execution-governance.md
Opérations d'exécution traversant des générations de services, des transactions de configuration à chaud ou le basculement de la racine physique : references/runtime-generation-governance.md
Problèmes difficiles à reproduire ou à faible observabilité : references/hard-to-reproduce-diagnostics.md
Encodage, budget de ressources, capacité logique des messages, sharding atomique, curseur de rejeu, valeur numérique, schéma ou bifurcation de sémantique d'erreur pour JSON structuré : references/structured-data-boundary.md
Réponse du modèle, statut de tâche ou résultat présenté non cohérent avec l'exécution réelle, ou nécessité de localiser la requête réellement envoyée au modèle : references/model-mediated-operation-governance.md
Propriété des calques visuels, des transformations ou des animations : references/interaction-motion.md ; si une validation par image d'écran réelle est nécessaire, lisez ensuite references/implementation-review.md
Outils, alias de chemin, environnement d'exécution ou tâches longues : references/user-environment-governance.md
Événements, versions, historique ou cache prenant à tort le périmètre d'impact prévu comme un fait de modification réel : contrat de "séparation du périmètre prévu et des faits de modification réels" dans references/change-prevention.md
Mise à jour d'état local, battement de cœur ou télémétrie qui écrase ou vide des champs non déclarés, ou consommateur incapable de distinguer un instantané complet d'un patch partiel : contrat de mise à jour de projection active dans references/change-prevention.md
Code source, README, scripts, tests ou configuration codant en dur des faits de la machine locale et du déploiement : limites de configuration d'exécution du projet dans references/change-prevention.md ; pour les faits de la machine utilisateur, lisez simultanément references/user-environment-governance.md
Cohésion, couplage, duplication sémantique ou module God : references/architecture-cohesion-governance.md

Compatibilité des Outils Externes

Lisez references/external-tool-compatibility.md. Si la relation de compatibilité implique des contrats publics traversant des racines de projet, des instantanés dérivés ou des packages de livraison composites, lisez simultanément references/change-prevention.md pour les contrats publics, la fermeture d'adoption de contrat et les limites de livraison inter-racines. Les vérifications de compatibilité restent en lecture seule, et rapportent couche par couche, en fonction de l'adaptateur explicite : artefacts exécutables, contrat de capacité, appel et isolation, entrée temporaire, protocole ligne amont, résultat structuré, vérification indépendante de l'hôte et chaîne utilisateur ; ne modifiez la racine autorisée du projet que si la réparation ou l'intégration est explicitement autorisée.

Recherche et Explication du Projet

Lisez d'abord references/project-research.md. Ne lisez que la surface du projet nécessaire pour répondre à la question actuelle ; n'étendez la couverture que si l'utilisateur demande explicitement une recherche complète ou une adoption de capacité, et lisez alors simultanément references/source-fork-and-ecosystem-adoption.md, en retraçant d'abord l'amont original et en distinguant la réutilisation directe de l'apprentissage de méthode ; si la réutilisation directe de code ou de ressources est confirmée, lisez ensuite references/license-governance.md et écrivez les ressources tierces et les remerciements dans le README du projet cible. Si une mesure d'efficacité, des échantillons d'échec et un niveau de confiance sont nécessaires, lisez references/project-effectiveness-review.md ; si un rapport vérifiable doit être conservé, lisez references/project-research-report.md. Pour une archive source, utilisez d'abord scripts/extract_project_archive.ps1 et -DestinationRoot <racine_cible> pour décompresser dans un répertoire indépendant ; si aucune racine cible n'est spécifiée, utilisez E:\Work\BaiduSyncdisk\Code\Example. Dès que le script a retourné la racine du projet, lisez references/archive-safety-screening.md et exécutez scripts/inspect_extracted_project_safety.py ; n'entrez dans la sortie utilisateur que si cette méthode confirme un problème majeur, sinon continuez silencieusement la recherche d'origine.

Gouvernance des Répertoires du Projet

Lisez references/repository-directory-governance.md. Obtenez d'abord les preuves physiques et Git en lecture seule à l'aide de scripts/inspect_project_tree.py, puis vérifiez pour chaque répertoire candidat le producteur formel, la source de vérité du chemin, les consommateurs et le cycle de vie ; arrêtez la vérification, l'explication et le plan au registre de preuves, ne modifiez le chemin exact que si l'organisation, le déplacement ou l'archivage sont explicitement autorisés, et la suppression continue d'obéir à une autorisation distincte. Si un déplacement touche du code source actif, des modèles, des données, du matériel, des points d'entrée de construction ou d'exécution, lisez simultanément references/change-prevention.md ; si des chemins anciens, une double lecture, des copies synchrones ou une migration partielle existent déjà, lisez ensuite references/root-cause-remediation.md, migrez les consommateurs en une seule fois et sortez de l'ancien point d'entrée.

Base de Référence et Modèles de Projet

Lisez references/project-template-system.md. Les requêtes en lecture seule s'arrêtent à inspect, plan ou verify ; l'adoption, la mise à niveau ou l'écriture de configuration de projet nécessitent une autorisation explicite et la vérification des consommateurs formels.

Évolution des Modèles

Lisez references/template-evolution.md. Prouvez d'abord que le candidat est une valeur par défaut stable et non une méthode nécessitant encore un jugement contextuel, puis synchronisez la version du modèle, le registre, le hachage, la documentation et les tests des consommateurs.

Gouvernance de l'Expérience Produit et de l'Interface

Lisez d'abord references/product-experience-governance.md, puis exécutez selon les points d'entrée fixes et les spécialisations conditionnelles suivants :

Diagnostic, évaluation, optimisation ou reconstruction de l'interface : Lectures fixes : references/ux-design.md, references/interface-experience-quality.md, references/interface-problem-patterns.md, references/implementation-review.md. Avant de modifier, figez toutes les fenêtres, pages, panneaux, couches, principaux états et parcours utilisateur concernés ; ne considérez pas le problème local le plus visible dans une capture d'écran comme le périmètre complet de la revue.
Conception à partir de zéro ou changement de direction visuelle : references/design-method.md, references/visual-direction.md, references/surface-registers.md
Mise en page, système de conception, interaction et animation : references/layout-responsive.md, references/design-system-alignment.md, references/interface-guidelines.md, references/interaction-motion.md
Reconstruction fidèle d'une interface de référence : references/reference-interface-reconstruction.md
Confirmation de plateforme : S'il est déjà confirmé qu'il s'agit d'un environnement de bureau, Tauri/Vue ou d'un espace de travail de fichiers locaux, lisez respectivement references/desktop-app-governance.md, references/tauri-vue-governance.md, references/local-file-workspace-governance.md ; une fois que la forme du projet est établie, n'omettez pas l'enveloppe de la plateforme sous prétexte que le retour actuel ne mentionne que la couleur, l'espacement ou le texte.
Statut ou progression de tâche : references/task-progress-governance.md

Lorsque vous vous appuyez sur un positionnement ou un système de conception existant, exécutez scripts/context.mjs au maximum une fois par tâche ; pour une reconstruction fidèle d'une interface de référence, laissez assets/reference-reconstruction/component-spec.md prendre en charge la spécification des composants.

Création et Publication du Dépôt

Lisez references/repository-publication.md. Distinguez l'initialisation, le commit, la création du dépôt distant, le push, la visibilité, la vérification et le déploiement ; chaque étape n'exécute que le point d'arrêt déjà autorisé, et vérifie l'identité exacte du dépôt, l'index, la branche, le dépôt distant et les changements simultanés avant et après le changement d'état.

README et Page d'Accueil

Lisez d'abord references/readme-delivery.md, utilisez un seul registre de livraison pour vérifier les limites Git, le README, le corps, le visuel, les langues, la licence, Star History, les Topics GitHub, les métadonnées du dépôt, la vérification et le point d'arrêt ; les requêtes en lecture seule s'arrêtent à ce même registre, n'implémentez que si une optimisation, une réécriture ou un traitement complet est explicitement demandé. Lisez ensuite references/content-architecture.md ; pour une optimisation complète ou si cela implique un logo ou un hero, lisez references/visual-direction.md, effectuez d'abord une enquête sur la source d'identité formelle (code d'abord), puis lisez selon les besoins references/project-native-hero.md et references/github-readme-canvas.md. Si des langues multiples, un point d'entrée personnel ou une zone d'état du dépôt sont nécessaires, lisez assets/readme-profile/profile.json, consommé par scripts/readme_header.py avec le fichier réel, l'identité du dépôt, la licence et la navigation du projet explicitement analysée. Pour une optimisation complète du README d'un dépôt GitHub public existant, Star History et Topics sont tous deux des éléments de livraison par défaut : Star History lit references/github-star-history.md et references/repository-publication.md, Topics s'écrit via scripts/github_topics.py et est relu ; sauf si l'utilisateur se retire explicitement ou si l'objectif n'est objectivement pas applicable, un résultat réussi sans l'un ou l'autre des consommateurs réels ne peut pas terminer l'ensemble de la livraison. Au choix :

SVG et visuels hybrides : references/svg-production.md, references/hybrid-svg-production.md
Animation : references/motion-production.md
Directives de plateforme : references/platform-guidelines.md
Diagnostic spécialisé ou intégration de Star History auto-hébergé : references/github-star-history.md ; si seule la cause de l'échec ou l'état actuel est demandé, restez en lecture seule ; lors de l'implémentation, commitez et pushez précisément les modifications du dépôt appelant, exécutez manuellement le workflow, puis vérifiez le long de la chaîne réelle (API, générateur, branche de sortie, SVG brut et README côté consommateur)

Le README ne sert pas de deuxième source de vérité active pour chaque règle de gouvernance interne ; ne mettez à jour le README lors de l'auto-évolution que si cela modifie l'identité publique, le chemin de lecture, le point d'entrée principal ou la navigation de maintenance. Après avoir terminé, exécutez scripts/audit_readme.py et vérifiez sur la surface de rendu réelle.

Gouvernance des Licences

Lisez d'abord references/license-governance.md. Ce n'est qu'après que l'utilisateur a confirmé le plan spécifique que vous lisez references/license-rollout.md et mettez en œuvre ; les requêtes en lecture seule s'arrêtent aux limites de contenu, aux dépendances tierces et à la comparaison des plans.

Journaux Humanisés

Lisez references/log-audit-standard.md. Vérifiez la production, le contexte, le stockage, la lecture et le résultat de consultation final le long d'une opération réelle ; ne remplacez pas une chaîne d'événements complète par un seul bel exemple.

Profil d'Environnement Utilisateur et Environnement d'Exécution

Lisez references/user-environment-governance.md. Le schéma du profil est géré par assets/user-environment/profile.schema.json, les opérations déterministes par scripts/user_environment_profile.py. Inspect, plan, verify et resolve maintiennent respectivement leurs limites de lecture seule ou de consommation ; apply --write nécessite une autorisation d'écriture de profil explicite et n'autorise pas automatiquement l'installation, le téléchargement ou la modification des paramètres système.

Audit Complet du Projet

Lisez references/project-audit.md. Lorsque l'utilisateur demande le degré d'achèvement d'un plan d'implémentation, établissez d'abord un registre de conformité point par point à partir du plan d'origine ; une fois l'autorisation de réparation obtenue, vous devez régénérer un tout nouvel examen à partir du plan d'origine et du contrat actuellement accepté, sans utiliser les anciennes marques d'achèvement ni déduire le périmètre du plan à partir des tests existants. Pour une vérification complète, établissez d'abord un registre de couverture pour toutes les dimensions applicables en fonction de la forme du projet, puis chargez les spécialisations requises par ces dimensions ; ne remplissez pas le périmètre de la revue en fonction des problèmes déjà découverts. Un audit en lecture seule n'implique pas de gouvernance automatique. Si une évaluation de l'effet utilisateur est nécessaire, ajoutez references/project-effectiveness-review.md ; si une vérification de l'expérience de tâche est nécessaire, ajoutez references/task-experience-audit.md.

Ressources de Modèles de Plateforme

Lisez selon les besoins lors du traitement du type de projet correspondant :

Application de bureau : references/desktop-app-governance.md
Tauri v2 + Vue : references/tauri-vue-governance.md
Espace de travail de fichiers locaux : references/local-file-workspace-governance.md

Ces ressources sont des méthodes actives, elles n'impliquent pas que le projet a déjà adopté le modèle ; seul le project.json situé dans .project-steward/ qui est explicitement adopté et lu par le consommateur formel constitue un état de modèle de projet.

Sortie et Achèvement

La sortie donne d'abord la conclusion, puis explique le périmètre, les preuves, les inconnues et la prochaine action. Une analyse ne doit pas être rédigée comme si elle avait été implémentée ; une vérification de structure ne doit pas être rédigée comme si une chaîne utilisateur réelle était établie ; une vérification du comportement de la tâche actuelle ne doit pas être rédigée comme si un démarrage à froid indépendant avait été prouvé.

Lorsqu'il y a un graphe d'impact, il doit inclure au moins le producteur, la limite de transport ou de stockage, le consommateur, le résultat final de l'utilisateur, la source de vérité unique, la condition de sortie de l'ancien chemin et le point d'entrée d'acceptation. Lorsque plusieurs résultats historiques sont impliqués, rapportez pour chacun la cause principale, le mécanisme de succès, le déficit de capacité, le propriétaire formel et le niveau de vérification.

Ne rapportez l'achèvement que lorsque le routage actif, la méthode correspondante, le consommateur formel, le test déterministe et la chaîne utilisateur réelle autorisée pour ce cycle sont tous cohérents.

Project Steward

Qu'est-ce que Project Steward ?

Demander à votre IA préférée

Documentation