Débogage et rétrospective d'agent astronomique
Localisez les symptômes vers le premier contrat défaillant, réparez les couches nécessaires, puis prouvez séparément que l'exécution est correcte, que le mécanisme est efficace et que les bénéfices réels sont obtenus. Les trois conclusions sont enregistrées indépendamment.
Ce skill est extrait des documents historiques lisibles du projet « Agent astronomique ». Les cas sont des indices de diagnostic et ne signifient pas que l'implémentation actuelle présente les mêmes défauts. Les budgets historiques, nœuds, dates, noms de cartes et seuils de passage ne peuvent pas devenir des constantes par défaut pour de nouvelles tâches.
Établir l'identité
Confirmez que l'objectif est de corriger, diagnostiquer, accélérer de manière équivalente, améliorer la stratégie ou livrer une réparation. Identifiez le chemin réel et la version actuelle, vérifiez CURRENT, la liste figée, l'accusé de réception et le paquet final ; l'identité est basée sur le hachage du code source, des entrées, de la configuration et des résultats.
Enregistrez les versions officielles du protocole/scoreur, les champs visibles en ligne, les contraintes d'initialisation, le mode d'exécution, l'étalonnage CPU et la limite murale indépendante. Lorsque seule une erreur générique du site ou une carte locale de même nom est présente, la cause racine côté cloud n'est pas encore localisée.
Distinguer : complet valide, arrêt budgétaire, échec technique, interruption utilisateur, diagnostic terminé mais porte scientifique non franchie. Certains scores saisonniers n'entrent pas dans le classement complet de la saison ; les valeurs manquantes conservent null.
Lire les références selon les symptômes
- Action illégale, démarrage/ABI/manifeste/ZIP, numéro de données, nettoyage de sauvegarde : lisez protocol-and-data.md.
- Allocation élevée mais score bas, score zéro, réparation manquée, REQ/requête oubliée, divergence de relecture : lisez state-and-physics.md.
- Délai dépassé, modèle sans bénéfice, accélération diagnostique mais saison inchangée, échec de validation/abandon : lisez budget-and-experiments.md.
- Consultez les contre-exemples historiques et les preuves de réparation : lisez casebook.md ; vérifiez l'identité des fichiers originaux : lisez evidence.md et corpus-index.tsv.
Trouver la première divergence
Comparez selon le flux de données réel : entrées/contraintes → messages consommés → état/cache → entrées candidates → points totaux/allocation → action finale → exécution officielle → règlement du retour.
Trouvez la première divergence à partir du plus petit état d'échec ou de la trajectoire immuable avec les mêmes entrées. Enregistrez l'attendu, le réel, l'unité, le dénominateur, la sélection d'échantillon et la source. Marquez séparément la reproduction du code source, la corrélation des logs, l'hypothèse mécaniste et les preuves de bénéfices.
Corrigez d'abord les pollutions de protocole, d'identité et de relecture, puis expliquez les différences scientifiques. Une relecture fidèle reproduit la séquence de consommation originale ; modifier le comportement historique est une nouvelle candidature, à ne pas mélanger avec la trajectoire originale. En cas d'initialisation ou de message clé manquant, arrêtez-vous à la frontière identifiable, ne comblez pas les états cachés.
Concevoir une expérience de contrôle minimalement falsifiable
Une hypothèse correspond à un test qui peut la réfuter. Un fixture synthétique vérifie les limites, un shadow d'état public vérifie l'entrée et le mécanisme de sélection, une saison complète appariée vérifie la performance globale, un ensemble de validation indépendant vérifie une généralisation limitée ; chaque couche ne soutient que sa propre conclusion.
Listez les éléments conservés pertinents pour cette itération : physique/score, information publique, RNG, ordre des messages, registre, ABI native, ordre des candidats/ex aequo et facturation. Une accélération équivalente qui modifie les actions ou l'ensemble des candidats est reclassée comme changement de stratégie.
Les candidats stratégiques sont d'abord tracés pour voir s'ils peuvent entrer dans la chaîne réelle des candidats, être calculés avec précision, satisfaire la protection de complétion et modifier le choix d'exécution ; si la porte du mécanisme prédéfini n'est pas franchie, l'hypothèse est fermée. Les corrections de protocole sont validées avec des contre-exemples réels aux limites, sans exiger que les cartes normales changent d'action.
Exécuter une validation limitée
Le score et les modèles distants utilisent l'autorisation actuelle et le budget limité, sans hériter des crédits restants des études fermées. Choisissez des limites significatives, des différences et des contrôles normaux en fonction des modifications.
Lorsque le projet utilise un registre, confirmez avant le lancement que « planned » a réussi, lisez l'identité, le hachage de la source/de l'entrée et l'isolation de la sortie ; en cas d'échec d'enregistrement, traitez d'abord l'échec. Les exceptions sont toujours gérées dans un bloc finally pour comptabiliser les coûts réels et le nombre de requêtes. Les corrections techniques utilisent une sous-version pour conserver la version parent défaillante ; l'enregistrement après coup mentionne « retrospective ».
Le code source final est comparé avec la même origine, les mêmes entrées et la même facturation OFF/ON. Après un changement de code source, ne référencez que les preuves qui correspondent encore à ce code source. Rapportez élément par élément les portes obligatoires : état final complet, budget, REQ, requête, score scientifique/total et les rôles API requis. Tout échec à une porte obligatoire signifie que la validation n'est pas réussie.
En cas d'échec, passez à une nouvelle hypothèse de cause racine avec de nouvelles preuves ; changer de graine, choisir un code source, modifier le seuil de passage ou élargir le scan n'est pas une réparation de la validation originale. L'ensemble de validation utilisé pour la sélection ou le diagnostic devient des données de développement ; une nouvelle généralisation utilisera un nouvel ensemble de validation.
Sortie et critères de complétion
Selon la taille du problème, produisez :
Symptômes et premier maillon défaillant :
Niveau de preuve et identité de la source :
Cause racine confirmée / à confirmer :
Modifications minimales et éléments conservés :
Résultat : protocole / état / mécanisme / saison complète / ensemble de validation / déploiement
Éléments échoués, non exécutés et incertitudes :
Prochain test minimal pouvant distinguer les hypothèses :
Le paquet téléversé est généré à partir du code source figé final, dans un nouveau répertoire, avec un build/run piloté par l'analyseur de manifeste officiel. Validez les hachages JSONL, ressources et source/ZIP. Rapportez séparément pour mock, native local, API réelle, Linux et site web ; ils ne se substituent pas les uns aux autres.
Les nouvelles expériences doivent être accompagnées des conditions d'application, de la reproduction minimale et des preuves ; ne conservez que les règles qui modifient réellement la décision.