zjp1997720/codex-doctor

Codex Doctor

Exécutez une vérification de santé en deux couches :

1. Réutilisez la commande intégrée stable codex doctor --json pour les vérifications d'installation, configuration, authentification, environnement d'exécution, Git, terminal, serveur d'application, mise à jour et inventaire des threads.
2. Exécutez le scanner en lecture seule fourni pour la gouvernance du contexte de l'espace de travail que la commande intégrée ne couvre pas.

Le scanner rassemble des preuves déterministes. Vous émettez le jugement sémantique. Cette séparation est importante car un script peut prouver que du texte se répète, mais il ne peut pas décider en toute sécurité qu'un fait métier, une limite de sécurité, une voix de marque ou une règle de répertoire est jetable.

Exécutez la vérification

Résolvez le répertoire Skill à partir du chemin du Skill chargé, puis exécutez :

python3 <skill-dir>/scripts/scan_workspace.py --cwd "$PWD" --compact-json

Pour un passage plus rapide uniquement sur l'espace de travail lorsque le rapport intégré a déjà été exécuté dans la même tâche :

python3 <skill-dir>/scripts/scan_workspace.py --cwd "$PWD" --compact-json --skip-built-in

--compact-json préserve chaque constatation et chaque ligne de vérification intégrée tout en omettant les grands inventaires de Skills et les détails verbaux des vérifications réussies. Utilisez --json uniquement lorsque des preuves d'inventaire déterministes complètes sont nécessaires.

Ne sauvegardez pas le rapport intégré brut dans le dépôt. Si un stockage temporaire est nécessaire, utilisez /tmp et supprimez-le avant de terminer.

Interprétez les constatations

Lisez checks-and-repair-policy.md avant de proposer un nettoyage ou une réparation. Gardez la sévérité et la confiance séparées :

• S0 : exposition prouvée de secret ou risque destructeur prouvé
• S1 : configuration effective cassée, règles strictes tronquées, exécutables activés manquants, ou inadéquation d'installation/mise à jour
• S2 : redondance exacte, noms/sources actifs en double, ou violation claire de l'hygiène du projet
• S3 : pression de maintenance, entrées désactivées obsolètes, avis de nouvelle version, ou descriptions surdimensionnées
• S4 : informatif, candidat sémantique, ou lacune de preuve

Traitez les semantic_candidates comme des invitations à inspecter, non comme des constatations. Lisez la section source concernée et classez-la comme l'un des types suivants :

• règle de comportement ou limite de sécurité : préservez
• préférence utilisateur, voix de marque, fait métier ou contrat de répertoire : préservez
• fait du dépôt nécessitant une synthèse multi-fichier : généralement à préserver
• inventaire directement découvrable, version de framework, liste de dépendances ou liste de répertoires : candidat à tailler
• déclaration obsolète ou contradictoire : vérifiez par rapport au dépôt avant de proposer une modification

Preuves de Skill inutilisé

La découverte statique ne peut pas prouver qu'un Skill est inutilisé. Si l'utilisateur demande explicitement des Skills inutilisés ou peu fréquents, utilisez le Skill installé codex-skill-admin en mode audit en lecture seule :

python3 <codex-skill-admin-dir>/scripts/codex_skill_admin.py audit-unused --cwd "$PWD" --days 30

Rapportez la fenêtre de preuve et le nombre distinct de sessions/sources. Ne désactivez rien sauf si l'utilisateur le demande séparément et approuve la liste cible.

Structure du rapport

Commencez par le résultat global, puis montrez uniquement les éléments actionnables ou pertinents pour la décision :

# Codex 健康检查

Statut : PASS / WARN / FAIL

## À traiter
- [identifiant de constatation] sévérité / confiance — conclusion
  Preuve : source et état observé
  Impact : défaillance concrète ou coût de contexte
  Recommandation : action exacte suivante

## Suggéré pour révision humaine
- candidats sémantiques avec pourquoi ils peuvent être inférables ou obsolètes

## Réussi
- domaines groupés, pas chaque ligne de bas niveau

## Lacunes de preuve
- vérifications qui ne peuvent pas être prouvées à partir de données publiques/locales

Préservez les sous-vérifications intégrées du docteur comme des faits séparés. Par exemple, un échec d'accessibilité HTTP et un succès WebSocket doivent rester deux lignes ; ne les fusionnez pas en « le réseau est cassé ».

Protocole de réparation

Le diagnostic n'autorise pas la réparation. Lorsque l'utilisateur demande de corriger des constatations :

1. Affichez un identifiant de constatation, la source exacte, pourquoi c'est faux, et un diff unifié d'un seul fichier.
2. Demandez l'approbation explicite de cet identifiant de constatation lorsque le changement supprime ou réécrit sémantiquement des instructions, modifie la configuration, active/désactive un composant ou déplace des fichiers.
3. Recalculez le SHA-256 du fichier source immédiatement avant d'appliquer le correctif. Arrêtez-vous s'il diffère des preuves du scan.
4. Appliquez uniquement le diff approuvé avec apply_patch.
5. Réexécutez la vérification concernée et rapportez le résultat avant/après.

Ne jamais automatiquement :

• supprimer ou affaiblir les règles de sécurité, les règles de marque/persona, les faits métier, les faits de projet, les barrières Git ou les limites de répertoire
• supprimer du texte simplement parce qu'il est dupliqué entre AGENTS.md et CLAUDE.md ; la parité entre hôtes peut être intentionnelle
• exécuter des hooks pour mesurer les performances
• faire confiance aux hooks, se connecter à MCP, exposer des identifiants, installer des dépendances, mettre à jour Codex ou changer de fournisseur
• modifier les paramètres sandbox, d'approbation, de modèle, de réseau ou d'authentification
• exécuter des commandes Git destructrices, nettoyer les fichiers non suivis ou déplacer des répertoires protégés du projet

Vérifications d'achèvement

Avant de signaler l'achèvement :

• confirmez que le scanner n'a apporté aucune modification au dépôt
• distinguez les diagnostics Codex intégrés des constatations de gouvernance de l'espace de travail
• étiquetez l'inférence comme telle
• rapportez les vérifications ignorées et les lacunes de preuve
• si des réparations ont été approuvées, vérifiez chaque fichier modifié et réexécutez sa vérification de domaine