Workflow PAS DEFT

Installation autonome ? Si cette session n'a pas été initialisée par le plugin de banque de skills TAO, exécutez d'abord le skill tao-setup pour les vérifications préalables du host, les contrôles de credentials et la découverte inter-skills.

Exécutez le flux PAS canonique en tant que workflow reprendre à partir du disque et résiliente. L'ensemble de la logique du workflow PAS, des templates et des adaptateurs de host sont fournis avec ce skill ; les clients n'ont pas besoin d'un checkout source séparé. Les scripts packagés rendent les appels de stage déterministes sans ajouter une autre couche d'orchestration.

Ce skill supporte chaque plateforme d'exécution TAO packagée : Docker, SLURM, Kubernetes, Brev et virtualenv. Le workflow produit un action bundle neutre vis-à-vis de la plateforme et validé par schéma ; le skill de plateforme sélectionné possède les verbes submit/status/logs/cancel natifs et le job-record. L'exécution virtualenv utilise des profils runtime immuables séparés pyt et ds ; le contrôle du workspace .venv n'est pas un runtime d'exécution.

Contrat d'entrée

tao-deft-pas et tao-run-deft-pas sélectionnent le même workflow. Si l'utilisateur n'a pas choisi de plateforme, posez la question une seule fois parmi Docker, SLURM, Kubernetes, Brev et virtualenv ; ne faites jamais de défaut à Docker. À la reprise, la plateforme immuable dans deft_state.json est déjà la sélection et ne doit pas être modifiée.

Utilisez deux phases d'admission :

1. Effectuez uniquement une découverte de chemin légère et bornée. Deux chemins de fichier d'archive explicites gagnent et suppriment toute recherche d'archive. Un répertoire d'archive explicite est traité comme une seule racine de recherche approuvée. Sinon, résolvez le ~/workspace conventionnel et utilisez uniquement ces racines de recherche dédupliquées : ~/pas, la racine du workspace et ses enfants pas/, input/ et inputs/. Vérifiez uniquement la racine du workspace elle-même ; sous chaque autre racine de recherche, inspectez la racine et les répertoires au maximum deux niveaux en dessous. Cette recherche de sous-arbre bornée de style AOI supporte les répertoires d'export/drop imbriqués sans se transformer en un scan de home ou de repository. Ne suivez jamais les symlinks et n'ajoutez pas le checkout courant, les repositories source, les arborescences tutoriel/notebook ou les arborescences de sortie de données du workspace comme racines de recherche implicites.

   Un candidat d'archive contient des enfants fichiers réguliers directs images_raw.tar et meta.tar.gz ; le workflow en a besoin d'une telle paire, non de multiples répertoires de dataset. Suivez la classification et le format de provenance dans references/preflight.md afin que l'utilisateur voit chaque racine de recherche, sa raison et sa limite de profondeur, le répertoire dans lequel une paire a été trouvée, et s'il s'agit d'archive seule ou mixte avec données extraites.

   Énumérez les fichiers d'état d'exécution uniquement à <workspace>/results/run_*/deft_state.json. Lisez les champs d'identité minimaux et présentez un candidat de reprise uniquement quand workflow est exactement tao-run-deft-pas ; ne proposez jamais AOI ou un état DEFT non identifié comme PAS. Ne validez pas les grandes archives jusqu'à EOF et n'inspectez pas encore les plateformes, images, GPU ou credentials.

2. Si max_iterations ou un budget de temps est absent, posez une seule question consolidée pour cette valeur requise et tout choix de chemin/exécution véritablement ambigu. Énoncez les défauts documentés et qu'une approbation complète en lecture seule plus un résumé d'approbation suit. Ne demandez pas si l'utilisateur souhaite les surcharges optionnelles de KPI, authentification ou paramètre ; appliquez leurs défauts sauf si le prompt en fournit déjà un.

Après résolution de l'admission requise, découvrez et validez :

• workspace et soit un nouveau ${RESULTS_DIR} soit une exécution existante à reprendre ;
• images_raw.tar et meta.tar.gz ; SHA256SUMS est optionnel ;
• max_iterations, ou un budget de temps fourni par l'utilisateur à partir duquel une limite d'itération peut être estimée ;
• nom de métrique, type de requête, opérateur et cible optionnelle ;
• si le déploiement nécessite un accès authentifié aux modèles Hugging Face ;
• plateforme d'exécution TAO sélectionnée et ses prérequis spécifiques à la plateforme ;
• tout override explicite d'époque, GPU, mining, apprentissage continu ou visualisation.

Pour une nouvelle exécution, RESULTS_DIR doit être un enfant de WORKSPACE. DATASET_ROOT doit être en dessous d'un répertoire de données du workspace (par exemple $WORKSPACE/data/pas_v31_tao_ft), pas directement en dessous du workspace ; ni un chemin ne peut contenir l'autre. Tous les chemins approuvés sont absolus et non-symlink.

Ne remplacez jamais une valeur explicite par une heuristique. Les défauts s'appliquent uniquement aux valeurs non spécifiées et doivent être identifiés comme défauts dans le résumé de prévolée. max_iterations n'a pas de défaut. Une cible de métrique absente signifie une exécution sans portail qui s'arrête après max_iterations. L'acheminement du token Hugging Face fait défaut à désactivé car le modèle packagé est public.

Le contrat de paramètre autoritaire est le schéma dataclass imbriqué dans scripts/pas_deft/config.py, adapté du notebook de référence PAS. Lisez ce schéma quand une demande a besoin de la signification, du défaut, des limites numériques ou des options valides d'un paramètre DEFT. N'inférez pas un champ non documenté ni ne contournez sa contrainte de métadonnées. La préparation de config, l'initialisation, l'audit et chaque stage côté host valident le bundle matérialisé à travers ce même schéma ; la section YAML pas est validée via le modèle de configuration PAS typé.

Si des informations requises restent manquantes après une découverte complète, posez un suivi consolidé unique. Une invocation normale ne doit avoir besoin d'aucune connaissance des modules de stage, des montages de container, des fichiers d'état ou des signatures de fonction runtime packagées.

Portail de sécurité

Effectuez uniquement une découverte en lecture seule avant approbation : résolvez les chemins, inspectez les métadonnées de fichier et les archives, vérifiez la présence des variables d'environnement de processus, inspectez les images locales, inspectez les GPU et auditez une exécution existante. Les credentials proviennent uniquement de l'environnement du processus de lancement ; n'ouvrez jamais ni ne sourcez un fichier de credential et ne printez, grepez, copiez ou echoed jamais une valeur de credential. Si une variable requise est absente, dites à l'utilisateur quel nom exporter dans le shell qui lance l'agent ; ne demandez jamais sa valeur en chat. N'inspectez pas les métadonnées de fichier credential quand aucun credential n'est nécessaire. Si l'utilisateur demande explicitement une vérification de permission de fichier, stat seulement ce fichier nommé et avertissez sur la lisibilité groupe/autres.

Affichez le résumé défini dans references/preflight.md, incluant chaque paramètre et source, création/extraction de fichier planifiées, tirages d'image, estimation du runtime et état de reprise. Attendez l'approbation explicite avant connexion au registry ou tirages, soumission de plateforme, installation de package, extraction d'archive, création de config/état ou toute écriture sous le workspace.

Si un paramètre approuvé change plus tard, affichez les lignes de résumé modifiées et obtenez l'approbation à nouveau avant de continuer. Aucune confirmation n'est nécessaire entre les stages inchangés et déjà approuvés.

Contrat d'exécution

1. Après approbation, suivez references/preflight.md pour préparer le runtime, matérialisez la config d'exécution immuable et initialisez l'état une seule fois. Ne réinitialisez jamais une exécution existante.

2. Avant chaque stage, après compaction de contexte et avant toute réclamation d'achèvement, exécutez :

   "$SKILL_ROOT/scripts/deft_python.sh" --workspace "$WORKSPACE" --runtime \
     "$SKILL_ROOT/scripts/audit_deft_run.py" --results-dir "$RESULTS_DIR"

   Continuez uniquement quand l'audit rapporte IN_PROGRESS et son next_action correspond au stage prévu. Pour INVALID, cessez de lancer du travail et rapportez l'inconsistance listée. Pour FAILED non-terminal dont next_action est loop_stop, suivez la référence du pipeline et committez hard_stop ; pour FAILED terminal, rapportez l'échec et ne lancez aucun travail supplémentaire. Pour COMPLETE, ne réexécutez pas un stage.

3. Lisez uniquement la référence du stage courant nommée par read_before_action. Utilisez run_pas_stage.py pour les stages PAS host packagés. Pour chaque action TAO, utilisez run_deft_action.py prepare, réconciliez tout lancement interrompu, liez l'exact job-record possédé par la requête avant soumission native, dispatchez le bundle émis via les quatre verbes de la plateforme sélectionnée, synchronisez les sorties distantes, capturez les logs natifs, puis utilisez run_deft_action.py finalize. Suivez references/platform-execution.md ; n'assemblez jamais un lancement non-tracké.

4. Une commande ne réussit que quand son statut de sortie est zéro et ses contrôles de sortie documentés passent. Capturez la sortie détaillée au chemin log possédé par l'action ; inspectez le bloc d'erreur final ou au maximum les 40 dernières lignes.

5. Committez chaque stage réussi ou terminalement échoué exactement une fois avec commit_stage.py. Il valide la structure d'artefact, la fraîcheur, la portée d'itération, la preuve de commande, la fuite et l'ordre de transition avant d'appliquer une mise à jour récupérable et journalisée à deft_state.json et loop_log.jsonl. N'appelez jamais log_stage.py ou record_metric_result.py directement et n'éditez jamais à la main les fichiers d'état, log, métrique ou historique canoniques.

6. Rendez le rapport HTML avec render_deft_report.py. La génération de rapports est une lecture déterministe d'état audité ; elle ne nécessite pas un autre agent.

7. Gardez le tour moteur attaché à travers la boucle bornée complète. Après qu'un stage atteigne l'état terminal, finalisez/committez-le, ré-auditez et continuez immédiatement avec l'action suivante sélectionnée par l'audit. Une mise à jour en cours est un commentaire, pas une réponse finale et pas un point de détachement.

Tous les chemins d'artefact enregistrés sont des chemins de host absolus sous ${RESULTS_DIR}. Les artefacts de base vivent sous zs/, l'itération N sous iter_N/, et les splits à l'échelle de l'exécution, les embeddings sources et les fichiers d'historique à la racine d'exécution.

Workflow

Le chemin normal est linéaire, avec seulement deux décisions significatives :

approbation de prévolée
  -> dataset_setup -> pool_embed -> baseline evaluate
  -> KPI met? yes: loop_stop
              no: baseline gap_analysis
  -> for N = 1..max_iterations:
       data_mining -> history_select -> visualize -> train -> evaluate
       -> KPI met? yes: loop_stop
                   no and N < max: gap_analysis -> next iteration
                   no and N = max: loop_stop
  -> final audit -> HTML report

La propriété de stage et les commandes exactes sont dans references/scripts-and-agents.md. Lisez la référence détaillée uniquement quand son stage est prochain :

visualize est le seul stage optionnel. Committez-le avec --skip uniquement quand les deux paramètres de visualisation sont faux dans la config approuvée. Ne désactivez pas une visualisation échouée mid-run sans réviser et réapprouver la config.

Règles de boucle et récupération

• La boucle est bornée par max_iterations ; ne créez jamais une itération en dehors de cette plage. Une fois que le KPI passe, la seule transition légale suivante est loop_stop. Ne minez ni ne reentraînez.
• La surveillance fait défaut à attachée (long_running_enabled=true, mises à jour toutes les cinq minutes). Utilisez l'interrogation par condition terminale : conservez l'id job de la plateforme sélectionnée et sondez son statut natif pas plus souvent que tous les 30 secondes, continuant à travers finalize, commit, audit et le stage suivant. L'état d'audit terminal du workflow borné est la condition de fin, donc ce n'est pas un sondage ouvert.
• Ne renvoyez jamais une réponse finale tandis qu'une exécution approuvée est non-terminale. Une réponse finale termine l'exécution côté chat et rien ne peut la réveiller automatiquement. Finalisez le tour uniquement après que l'audit rapporte COMPLETE, FAILED terminal, ou INVALID, ou quand l'utilisateur demande explicitement d'arrêter ou détacher. Si le runtime ne peut véritablement pas garder un tour en vie, dites-le avant lancement et fournissez la commande d'audit de reprise durable exacte ; ne prétendez pas une surveillance sans surveillance.
• Ne répétez jamais une commande échouée inchangée spéculativement. Classifiez l'échec, inspectez son bloc log final, faites une correction fondée sur preuve permise par la référence de stage, puis réessayez une fois. Les enregistrements de statut de commande stable persistent tentative 1/2, et les wrappers refusent une troisième tentative après perte de contexte. L'audit doit passer avant d'avancer.
• Une interruption transiente de registry/réseau ou contention GPU peut être réessayée une fois après preuve que la condition a changé. Un deuxième échec équivalent est terminal pour l'exécution.
• Ne réessayez jamais checksum ou échec de vérification de reconstruction, zero-row mining, échec schéma/cardinalité, preuve d'eval-split manquante, eval leakage, conflit d'historique qui échoue la reprise documentée, mismatch de contrat métrique, sortie périmée/cross-itération ou architecture GPU non-supportée. Committez une erreur quand l'état le permet et arrêtez avec l'action de récupération exacte.
• Si une commande a écrit des sorties mais s'est écrasée avant commit de stage, exécutez l'audit. Réutilisez les sorties uniquement quand leur statut de commande est réussi, frais, correctement scopé, et tous les validateurs de stage passent. La sélection d'historique a une récupération supportée : réexécutez l'adaptateur déterministe avec --resume ; ne supprimez jamais ou ne modifiez jamais une entrée d'historique à la main.
• La modification manuelle ou la troncature de deft_state.json ou loop_log.jsonl invalide l'exécution. Préservez-la pour diagnostic et commencez un nouveau répertoire de résultats.

Sémantique métrique et arrêt

Le contrat de métrique approuvé est immuable pour l'exécution. L'évaluation doit parser le nvidia_pas_metrics_aggregate.csv de l'itération exacte ; le résultat enregistre son chemin source et est ré-dérivé lors du commit et audit. Le classement de checkpoint et le rapportage de meilleure exécution suivent l'opérateur approuvé (>=/> choisit la valeur plus haute, <=/< la plus basse), pas une convention métrique codée en dur.

L'achèvement réussi est exactement l'un de :

• loop_stop(reason=kpi_met) après une évaluation bornée satisfaisant sa cible ;
• loop_stop(reason=max_iterations) après l'évaluation finale autorisée quand la cible est non-rencontrée ou absente.

hard_stop est un résultat terminal échoué, pas un achèvement réussi.

Achèvement

À une limite de boucle normale :

1. committez loop_stop avec la raison sélectionnée par l'audit ;

2. rendez ${RESULTS_DIR}/DEFT_Loop_Report.html avec trigger loop-end ;

3. exigez que cette commande s'exit zéro :

   "$SKILL_ROOT/scripts/deft_python.sh" --workspace "$WORKSPACE" --runtime \
     "$SKILL_ROOT/scripts/audit_deft_run.py" \
       --results-dir "$RESULTS_DIR" --require-complete

Rapportez la raison d'arrêt, la métrique baseline et meilleure, meilleure itération/checkpoint, nombre d'itération complétée, chemin du rapport et tout avertissement. Un checkpoint, CSV, fichier HTML ou énoncé d'assistant seul n'est pas preuve d'achèvement.

Références progressives