Rapport Auto-FL NVFLARE

Objectif

Transformer les preuves enregistrées d'une campagne NVFLARE Auto-FL arrêtée en un rapport Markdown reproductible, un résumé JSON lisible par machine, et un graphique de progression actualisé sans modifier la campagne ni ses résultats.

Quand l'utiliser

Utilisez cette compétence après qu'une campagne NVFLARE Auto-FL s'est arrêtée, a atteint une limite explicite, a rencontré un blocage majeur, ou a été interrompue manuellement. Utilisez-la quand l'utilisateur demande le rapport final, l'amélioration obtenue, les résultats littéraires, les idées qui ont échoué, les détails de reproduction, ou un graphique de progression actualisé.

Quand ne pas l'utiliser

N'utilisez pas cette compétence pour démarrer ou poursuivre l'optimisation, inventer des résultats manquants, ou finaliser une campagne toujours en cours d'exécution. Utilisez nvflare-autofl pour la boucle de candidat actif. N'arrêtez pas une campagne active simplement parce que l'utilisateur demande un aperçu du statut.

Scripts disponibles

Exécutez directement cette interface en ligne de commande regroupée avec Python. Cette compétence n'a pas d'helper NVFLARE ou agent run_script() ; n'en inventez pas et n'en appelez pas. Résolvez le script à partir du répertoire contenant ce SKILL.md, comme illustré dans le flux de travail.

Flux de travail

1. Localisez le répertoire de job contenant results.tsv, autofl.yaml, .nvflare/autofl/campaign_state.json, et les manifestes de candidat.

2. Confirmez que l'exécution s'est arrêtée. Préférez l'état de campagne avec final_response_allowed=true. Lorsqu'un processus a été brusquement interrompu et que l'état est obsolète, confirmez indépendamment qu'aucun processus de campagne ou de job ne demeure, puis utilisez --confirm-interrupted. Avant de finaliser, confirmez que l'état de campagne, results.tsv, et les manifestes de candidat disponibles ne contiennent aucun candidat en attente. Finalisez ou abandonnez le travail en attente d'abord via nvflare-autofl.

3. Générez les artefacts de rapport déterministes :

   python "$REPORTER" <job-dir>

   Résolvez REPORTER une fois au chemin absolu de scripts/generate_report.py par rapport à ce SKILL.md. Ne supposez pas un répertoire d'installation de compétence spécifique au fournisseur ou $CODEX_HOME.

4. Lisez à la fois autofl_final_report.md et autofl_report_summary.json. Vérifiez les avertissements concernant l'utilisation de métriques, les changements de budget exécutés, le désaccord état-de-campagne/ledger, la provenance manquante, et l'état d'interruption incomplet.

5. Donnez à l'utilisateur la ligne de base, le meilleur score, le delta, la généalogie du candidat le plus fort, des conclusions concises « ce qui a aidé » et « ce qui n'a pas aidé », les idées littéraires qui ont aidé ou échoué, la rationale de sélection, les avertissements de fiabilité, et les chemins absolus des artefacts.

L'helper tente d'actualiser progress.png en réutilisant le traceur Auto-FL du produit. Le traçage est une evidence optionnelle : si les dépendances de traçage manquent ou si l'artefact n'est pas un PNG valide, l'helper préserve l'artefact, enregistre un avertissement et artifacts.progress_plot_available=false, et écrit toujours les rapports Markdown et JSON sans incorporer l'image cassée. Il ne modifie pas la source, les manifestes de candidat, results.tsv, ou l'état de campagne. Toutes les options de chemin relatif de l'helper, y compris --plotter, se résolvent à partir du répertoire de job de campagne plutôt que du répertoire de travail actuel du shell. L'helper détient le verrou du cycle de vie de la campagne du chargement des preuves à l'écriture des artefacts. Il refuse une campagne occupée et rejette les chemins de sortie accessibles en écriture qui font alias aux preuves de campagne, job.py, aux chemins source de contrat de confiance, ou à une autre sortie, y compris les alias du système de fichiers. Les sorties ne doivent pas correspondre aux motifs de création de source autorisés du contrat de confiance.

Une archive de campagne en lecture seule est reportable uniquement quand son campaign.lock persisté existe déjà et que les chemins de sortie accessibles en écriture sont fournis ; la cible de verrou persistée seule n'implique pas de contention en direct.

Campagnes interrompues

L'helper de rapport doit refuser un état avec final_response_allowed=false à moins que l'humain n'ait dit que la campagne était arrêtée/interrompue et que l'agent confirme que l'exécution n'est plus active. Seulement alors, exécutez :

python "$REPORTER" <job-dir> --confirm-interrupted

Cela enregistre une assertion d'interruption au moment du rapportage ; cela ne réécrit pas l'état de campagne et ne prétend pas que le runner a finalisé correctement. Cela contourne seulement un état d'arrêt obsolète. Une ligne de ledger candidate ou un état de candidat en attente bloquent toujours la finalisation. Tout manifeste de candidat disponible dont le statut n'est pas une valeur terminale reconnue (keep, discard, crash, ou abandoned) bloque également. Un statut manquant, inconnu, ou illisible est une evidence inachevée car l'achèvement ne peut pas être établi. L'agent doit d'abord finaliser ou abandonner ce candidat.

Dépannage

Contrat de rapport

Le rapport final doit inclure :

• raison de résiliation de campagne, objectif, source métrique, direction, environnement, cap, nombre de candidats abandonnés, et budget fixe déclaré ;
• ligne de base, meilleur résultat conservé, delta de score, runtime, défaillances, et décomptes de statut ;
• rationale du candidat sélectionné, améliorations strictement conservées, non-améliorations représentatives, défaillances regroupées, et résultats par famille d'algorithme enregistrée ;
• trajectoire du meilleur en cours sélectionnée par les premières améliorations objectives, finales, et les plus grandes, plus un progress.png actualisé quand le traçage est disponible, avec disponibilité de graphique explicite dans le résumé JSON sinon ;
• manifeste du meilleur candidat, hash de patch, généalogie du candidat de base, changements de code hérités, artefacts, et commandes baseline/best exactes ;
• tous les points de contrôle littéraires enregistrés, son ID d'événement et ses marqueurs source, candidats explicitement liés, et si l'evidence mesurée a aidé, correspondait, échouait, ou ne confirmait pas l'idée ;
• idées écartées/écrasées et avertissements de comparabilité déterministe ;
• notes optionnelles de modèle agent, d'effort de raisonnement, de coût, ou d'outils quand fournis ;
• chemins absolus vers autofl.yaml, results.tsv, état de campagne, progress.png, autofl_report_summary.json, et autofl_final_report.md.

Le rapport doit distinguer le budget importé/déclaré des arguments de commande exécutés. Il doit avertir quand le meilleur candidat a changé la puissance de calcul d'entraînement ou la population de comparaison, quand l'état autoritaire désaccorde avec la comptabilité dérivée du ledger, ou quand la sélection répétée a utilisé une métrique semblable au test. Les campagnes Auto-FL du produit conservent la direction importée min ou max ; le rapport rejette l'evidence de minimisation héritage sans provenance de direction. Il ne doit pas ajouter de sections spécifiques à la PR comme « Product Findings » à moins que l'utilisateur ne les demande explicitement.

best signifie une ligne de base ou keep scored conservée ; un discard scored non conservé peut n'apparaître que comme best_observed. Les lignes candidat et crash ne deviennent jamais des résultats best conservés, des jalons, ou des améliorations littéraires.

L'identité de ligne de base est déterminée strictement par status=baseline, en correspondance avec le garde de campagne. Le rapport préserve le nom de métrique par exécution, la source d'extraction, l'artefact, le type de candidat, la famille d'algorithme, et la liaison d'événement littéraire. Il n'infère pas les familles d'algorithme ou les mécanismes à partir des noms de candidat.

Lisez report-contract.md lors de l'interprétation de la généalogie, des résultats littéraires, des avertissements de budget, ou de l'état interrompu.

Limitations

• Le rapport n'est aussi complet que le ledger persisté, l'état de campagne, et les manifestes de candidat ; il ne valide pas et ne reconstruit pas les claims non enregistrés.
• Les résultats d'une seule campagne ne établissent pas la robustesse ou la généralisation.
• L'helper ne démarre, n'arrête, ne reprend, ou ne remet pas les jobs de campagne.
• Le traçage de progression demeure optionnel, donc Markdown et JSON peuvent être produits sans PNG intégrable.
• Les archives de campagne copiées peuvent ne conserver que la provenance partielle quand les chemins de manifeste absolus enregistrés ne sont plus disponibles.

Exigences

• Traitez results.tsv comme evidence enregistrée ; ne réparez jamais les scores en devinant.
• Travaillez sans Git. Ne committez ou ne pushez pas à moins que l'utilisateur ne demande séparément.
• Préservez exactement les sources de campagne et de job comme trouvées.
• Ne contournez jamais les vérifications de contention de verrou de campagne ou de collision de chemin de sortie.
• Utilisez les manifestes de candidat quand disponibles, mais rapportez toujours la provenance partielle quand les artefacts copiés rendent les anciens chemins de manifeste absolus indisponibles.
• Gardez les conclusions proportionnelles à l'evidence. Une seule exécution est un candidat, pas une affirmation de robustesse.
• Pour POC/production, rapportez les IDs de job NVFLARE standard et les artefacts téléchargés déjà présents dans le ledger ; ne resoumettez pas les jobs lors du rapportage.