Skill: tao-run-deft-aoi-cosmos3

Installation

Installez cette application dans le contexte complet du root TAO skill-bank, non pas uniquement les dossiers de skill compagnons : TAO_SKILL_BANK_PATH doit pointer vers un répertoire contenant versions.yaml, scripts/resolve_versions_key.py, et le résolveur de modèle Cosmos scripts/resolve_tao_image.py, plus l'arborescence skills/{applications,models,data,platform,core}/... listée dans eval.config. Exécutez la validation intégrée avec le Python du skill afin que les dépendances correspondent au runtime : PYTHON=$(bash scripts/deft_python.sh); "$PYTHON" -m unittest tests.test_cosmos3_bare. Résolvez d'abord le mode réseau. Les imports air-gap manquants sont un arrêt complet ; la configuration réseau-enabled existe uniquement dans references/network-bootstrap.md.

Execution Contract

Traitez une exécution comme une machine à états sauvegardée sur disque.

1. Préservez toute valeur utilisateur explicite et affichez la source de chaque valeur effective (user, spec ou default) dans le Pre-Flight Summary.
2. Demandez quelle plateforme installée utiliser. Ne sélectionnez pas Docker, SLURM, Kubernetes, Brev, virtualenv ou une plateforme externe par défaut.
3. Résolvez le mode réseau, puis lisez exactement un fichier parmi references/air-gap.md ou references/network-bootstrap.md. Exécutez la Preflight du skill platform sélectionné et arrêtez en cas de prérequis système/CLI natif manquant.
4. Avant toute mutation ou lancement, invoquez tao-launch-workflow et affichez sa revue de lancement ainsi que le Pre-Flight Summary de ce skill. Attendez une approbation explicite.
5. Après approbation, définissez PYTHON=$(bash scripts/deft_python.sh) et initialisez ${RESULTS_DIR}/deft_state.json une seule fois avec "$PYTHON" scripts/init_deft_state.py. Passez le modèle GPU exact rapporté par la Preflight de la plateforme sélectionnée via --gpu-model (incluez la mémoire de l'accélérateur si disponible), plus le mode réseau résolu/source et le Python absolu sélectionné. Ne réinitialisez jamais une exécution reprise et ne modifiez pas deft_state.json à la main.
6. Avant chaque étape, après compaction du contexte et avant une affirmation d'achèvement, exécutez "$PYTHON" scripts/deft_context.py --state ... --stage .... Utilisez son next_stage durable et les champs du fichier d'état status, current_iteration, iterations.*.status, stage_completed et la dernière entrée events pour reprendre. Ne déduisez pas la progression de la prose de l'assistant ou d'un artefact non enregistré dans l'état.
7. Exécutez chaque commande qui peut installer, récupérer, se connecter ou lancer un conteneur local via "$PYTHON" scripts/deft_exec.py --state ... -- <command>. En air-gap, cela rejette les opérations de sortie/paquets et applique no-pull. Les plateformes distantes doivent appliquer la politique no-pull/offline équivalente immuable.
8. Soumettez chaque étape GPU via les quatre verbes de la plateforme choisie : submit / status / logs / cancel. Le verbe submit doit ouvrir le job-record avant le lancement natif ; l'id retourné est le seul handle de lancement. Interrogez le backend, non le job-record, et mappez l'état à PENDING RUNNING COMPLETE ERROR CANCELED UNKNOWN.
9. Engagez chaque étape DEFT complétée ou échouée avec "$PYTHON" scripts/commit_stage.py. Cela vérifie les entrées de l'étape et met à jour atomiquement l'instantané de reprise et le tableau events ordonné dans l'état. Chaque engagement d'étape exécutée nécessite une --duration-sec positive et mesurée : utilisez le temps écoulé du backend pour les jobs soumis et une minuterie d'horloge murale hôte pour les étapes inline. Un --skip documenté peut enregistrer 0 ; les durées négatives sont toujours rejetées.
10. Affirmez l'achèvement uniquement après que "$PYTHON" scripts/finalize_run.py ait vérifié la preuve Benchmark finale, engagé avec succès loop_stop, et qu'une lecture récente de deft_state.json montre status == "complete", iterations.baseline.status == "complete" et status == "complete" pour l'itération finale.

Ne placez jamais de secrets dans une spec, commande, transcription, job-record ou chat. Vérifiez uniquement la présence de credentials, par exemple [ -n "$HF_TOKEN" ] && echo SET || echo UNSET. Les credentials proviennent de l'environnement shell exporté de l'utilisateur ou d'un fichier env approuvé par l'utilisateur — ~/.tao/secrets.env, ~/.config/tao/.env ou un chemin pointé par l'utilisateur, jamais un trouvé simplement dans le workspace — chargé avec set -a; source /path/to/.env; set +a. Ne printez jamais le contenu du fichier ou aucune valeur de credential.

Cosmos3 Model Contract

• Model skill : tao-finetune-cosmos-reason.
• Modèles canoniques de base supportés :
  • nvidia/Cosmos3-Nano — défaut ;
  • nvidia/Cosmos3-Edge — seulement si demandé explicitement ;
  • nvidia/Cosmos3-Super — seulement si demandé explicitement.
• Normalisez les alias utilisateur nano, edge et super vers ces IDs canoniques. Préservez toute variante sélectionnée dans le prompt. Quand aucune variante n'est sélectionnée, utilisez Nano.
• Donnez des recommandations matérielles pour la variante sélectionnée et rapportez quand le calcul disponible est insuffisant. Si le prompt demande une recommandation de variante basée sur le matériel ou la charge de travail, recommandez une avec le compromis, mais exigez une sélection explicite avant l'initialisation de l'état. Ne passez jamais silencieusement à une autre variante ou ne basculez pas vers elle.
• Gardez l'ID canonique sélectionné comme lignée modèle source, mais ne passez pas le checkpoint en ligne natif directement à Cosmos-RL.
• Les raisonneurs Cosmos Reason 3 publiés sont livrés dans le format Omni natif de Cosmos3 (model_type="cosmos3_omni"), que Cosmos-RL ne peut pas charger. Après approbation de lancement et avant l'évaluation baseline, exécutez "$PYTHON" <model_skill>/scripts/prepare_cosmos3_vlm_checkpoint.py pour convertir le raisonneur sélectionné en PTM safetensors Qwen3-VL, ou validez et réutilisez une sortie préparée existante.
• Utilisez le PTM préparé de manière cohérente pour l'évaluation zero-shot, la Train policy.model_name_or_path et la LoRA model.base_model_path. Le modèle en cours de formation est toujours le raisonneur Cosmos Reason 3 sélectionné — gardez son ID canonique comme lignée checkpoint ; le PTM Qwen3-VL est seulement le format sur disque que Cosmos-RL consomme.
• Nano peut utiliser le Qwen3-VL par défaut fourni par l'helper. Edge et Super nécessitent une base VLM spécifique à la variante, validée ; ne réutilisez jamais les arguments de conversion de Nano.
• Image de conteneur : résolvez le backend cosmos-rl à partir de tao-finetune-cosmos-reason/references/skill_info.yaml avec "$PYTHON" "$TAO_SKILL_BANK_PATH/scripts/resolve_tao_image.py" ; ne copiez jamais une épingle d'image Cosmos dans ce skill application.
• Action Train : cosmos-rl --config <spec.toml> /opt/cosmos_rl/tao_sft_example.py.
• Avant le premier job evaluate, exécutez "$PYTHON" scripts/patch_eval_image_cap.py pour classifier l'image sélectionnée. Montez sa sortie en lecture seule dans chaque conteneur d'évaluation uniquement quand elle rapporte patch_required ; aucun montage n'est nécessaire pour already_sufficient ou cap_absent. Un cap/vLLM shape non reconnu est un arrêt complet ; voir references/cosmos-reason.md.
• Workflow override : automl_policy: off. DEFT maîtrise l'itération et la sélection de checkpoint ; c'est un argument workflow, pas une clé TOML.
• Adaptation par défaut : LoRA sur les projections du côté langage ["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], laissant les poids pré-entraînés de la tour vision intouchés. Le schéma accepte aussi "all-linear", qui adapte également les couches linéaires vision ; utilisez-le seulement quand l'utilisateur le demande explicitement. Dérivez tous les autres défauts Train du template courant du skill modèle.
• Chaque spec est un dictionnaire imbriqué sérialisé en TOML. N'écrivez jamais de clés pointées littérales plates dans une spec.
• Ne montez pas les données utilisateur sur /workspace ; cosmos-rl y est installé.
• Exécutez chaque conteneur Docker avec un montage hôte writable comme l'UID:GID invoquant avec USER, LOGNAME, HOME=/tmp et les bases données passwd/group hôte en lecture seule ; ne revenez jamais à un conteneur repair root. Cela couvre la préparation de checkpoint, Train, Proxy/Benchmark evaluate, AnomalyGen et mining. Voir references/cosmos-reason.md et references/tao-mine-aoi-images.md.

Lisez skills/models/tao-finetune-cosmos-reason/SKILL.md et son references/skill_info.yaml avant de rédiger une spec. Commencez depuis le template actuellement fourni du skill modèle pour l'action sélectionnée et appliquez uniquement les overrides de workflow AOI dans references/cosmos-reason.md. Remplacez chaque chemin dataset/output par le chemin compute-frame de la plateforme choisie. Prouvez que l'image Cosmos-RL sélectionnée peut charger le PTM préparé et former la variante demandée ; ne réutilisez pas les suppositions de conversion, parallélisme ou mémoire de Nano pour Edge ou Super.

Bare OK/NG Contract

Cette migration supporte un mode annotation : bare_okng.

• Chaque enregistrement est du JSON ShareGPT avec exactement deux images dans l'ordre [AOI, golden_reference].
• Le premier tour human/user contient le prompt d'inspection.
• La réponse assistant/gpt finale est exactement OK ou NG ; le raisonnement, les préfixes, explications et wrappers de réponse finale sont des étiquettes training invalides.
• NG est la classe positive. NG -> OK est une acceptation fausse ; OK -> NG est un rejet faux.
• L'évaluation peut normaliser une réponse modèle par son dernier token OK/NG autonome, mais les étiquettes training restent exactes.
• Les modes Rich, reasoning, BCQ/MCQ et task fan-out sont en dehors de cette migration. Arrêtez plutôt que de les accepter silencieusement.

Exécutez "$PYTHON" scripts/validate_sharegpt.py sur Proxy, Benchmark, Mining et chaque fichier training d'itération généré. Il n'y a pas d'annotation Train d'entrée. Exécutez "$PYTHON" scripts/validate_split_contract.py pour prouver que les cibles Proxy, Benchmark et Mining sont disjointes et que le hash d'annotation Benchmark figé n'a pas changé. Quand un fichier Train généré est fourni, le même validateur exige que ses cibles proviennent de Mining, de la graine --previous-train immédiate ou de la sortie --synthetic AnomalyGen de l'itération courante, et restent disjointes de Proxy et Benchmark. Pour l'itération N>1, --previous-train est requis et le validateur prouve que chaque enregistrement Train antérieur a été conservé.

KPI Isolation

• Proxy : annotations/proxy_kpi.json. C'est la seule source d'erreur pour RCCA, routing, mining targets et décisions de data-mixture. Cela n'arrête jamais la boucle.
• Benchmark : annotations/benchmark_kpi.json. C'est figé, évalué au baseline et à chaque itération, et c'est la seule source de stop-gate. Les erreurs Benchmark sample ne nourrissent jamais le routing ou mining.
• Gate par défaut : recall_ng >= 1.0. Si l'utilisateur demande la précision, utilisez accuracy >= <target>.
• Les réponses modèle inconnues bloquent la gate via la contrainte de métrique unknown_predictions <= 0.

scripts/analyze_gaps.py écrit les artefacts Proxy RCCA ou les métriques agrégées Benchmark plus metric_result.json. scripts/record_metric_result.py lie la preuve métrique Benchmark au contrat métrique configuré.

Workspace Contract

workspace/
├── annotations/                 # user-supplied
│   ├── benchmark_kpi.json
│   ├── proxy_kpi.json
│   └── mining_pool.json
├── images/                      # user-supplied
└── specs/                       # produced by this workflow, after approval
    ├── train_spec.toml
    ├── evaluate_spec_proxy.toml
    └── evaluate_spec_benchmark.toml

Les specs evaluate par rôle sont préférées à un evaluate_spec.toml partagé unique ; les deux sont acceptés. Voir references/data-layout.md.

L'utilisateur fournit les annotations et images. Les specs ne sont pas une entrée à demander : construisez-les à partir des templates tao-finetune-cosmos-reason plus les overrides AOI, et écrivez-les après la gate d'approbation et avant init_deft_state.py, qui refuse de s'initialiser sans elles. Un workspace portant ses propres specs est toujours valide — réutilisez-les plutôt que de les écraser — mais leur absence est normale et n'est jamais une raison d'arrêter et de demander à l'utilisateur un fichier TOML.

Les chemins non-default sont valides quand passés explicitement à scripts/init_deft_state.py ; les étapes suivantes doivent lire les chemins enregistrés au lieu de réinférer les conventions. Enregistrez les chemins artefacts hôte/compute-frame absolus sous ${RESULTS_DIR}/baseline ou ${RESULTS_DIR}/iterN.

Lisez references/data-layout.md pour les rôles dataset, catégories source autorisées et éligibilité commercial-training.

Launch Intake and Pre-Flight

Lisez references/preflight.md et exécutez chaque contrôle ordonné :

1. sélectionnez et preflight la plateforme ;
2. résolvez workspace, annotations, media root et max_iterations ;
3. validez bare ShareGPT et l'isolation des cibles Proxy/Benchmark/Mining ;
4. hashifiez et figez les annotations Benchmark ;
5. résolvez les images Cosmos-RL et data-services courantes à partir de versions.yaml ;
6. planifiez la conversion du raisonneur Cosmos Reason 3 sélectionné en PTM Qwen3-VL, et le chemin visible par plateforme de cette sortie ;
7. vérifiez seulement la présence de variables d'environnement requises ;
8. construisez les specs TOML Proxy / Benchmark et validez le template Train ;
9. vérifiez la forme compute et la visibilité des chemins depuis la plateforme sélectionnée ;
10. exécutez la preflight lancement modèle/plateforme ;
11. affichez le Pre-Flight Summary complet et arrêtez pour approbation.

Aucun répertoire de résultats, fichier d'état, mutation de spec, installation de dépendance, pull d'image ou lancement natif n'est autorisé avant cette gate, sauf la petite correction d'helper-Python de la politique TAO.

Workflow

Le graphe de transition complet se trouve dans references/pipeline-and-state.md.

La gate Benchmark figée est toujours évaluée avant tout travail Proxy. Les evaluate Proxy et RCCA existent seulement pour amorcer le mining de l'itération suivante, donc ils s'exécutent seulement quand la gate n'est pas respectée. Une exécution qui passe la gate s'arrête sans dépenser une évaluation Proxy.

Baseline commence avec une évaluation Benchmark figée zero-shot du modèle base non modifié, ce qui établit le KPI zero-shot :

1. evaluate_benchmark
2. benchmark_metrics — arrêtez ici quand la gate passe déjà.
3. evaluate_proxy — seulement quand la gate n'est pas respectée.
4. proxy_rcca

Avant chaque engagement proxy_rcca, écrivez proxy_rcca/RCCA_Report.md à partir des trois artefacts JSON Proxy RCCA en utilisant references/RCCA_REPORT_TEMPLATE.md, puis passez-le avec --rcca-report. Les exigences artefacts, sections de titre et champs d'état proviennent de references/rcca-artifact-manifest.json.

Pour chaque iterN quand la gate Benchmark figée n'est pas respectée :

1. routing — dérivez les mining targets des faux acceptations/rejets Proxy uniquement. Écrivez les deux formats depuis les mêmes lignes : mining_targets.json pour l'état (--mining-targets prend le JSON) et un parquet filepath[,label] pour le conteneur embedding. Les lignes gap ne portent pas de chemins image, donc rejoignez Proxy par id — voir references/gap-analysis.md.
2. anomalygen — générez des défauts synthétiques avec tao-generate-anomalies en mode inference_only, puis transformez chaque paire générée en un enregistrement bare NG avec "$PYTHON" scripts/emit_sdg_sharegpt.py. --skip est permis seulement quand la RCCA Proxy driving a enregistré zéro faux acceptations, et même alors générer est souvent toujours utile. L'émetteur accepte les chemins PAIDF 1.0.1 relatifs à repo-root et relative au output-dir documentés, avec --sdg-root comme base supplémentaire explicite — voir references/tao-generate-anomalies.md.
3. data_mining — invoquez tao-mine-aoi-images, appliquez le floor cosine configuré avec "$PYTHON" scripts/filter_mined_by_cosine.py, puis exécutez le post-processing conscient de l'historique du skill mappé afin qu'un chemin filepath sélectionné par une itération antérieure ne puisse pas entrer dans Train à nouveau. Le top-K par défaut reste 5 ; préservez une valeur utilisateur explicite et augmentez-la seulement quand le résumé historique montre une faible nouveauté.
4. assemble_data — alignez les chemins cible minés vers les prompts source Mining, les références golden et les étiquettes exactes avec "$PYTHON" scripts/emit_mined_sharegpt.py ; créez train_iter_1.json à partir des enregistrements minés et synthétiques seulement après RCA Proxy et sélection Mining, puis appendez de manière monotonique dans train_iter_N.json aux itérations suivantes avec "$PYTHON" scripts/assemble_training_json.py.
5. validate_data — validez les étiquettes bare exactes, fichiers, doublons et lignée Train générée plus fuite Proxy/Benchmark.
6. train
7. evaluate_benchmark
8. benchmark_metrics — arrêtez ici quand la gate passe ou N = max_iterations.
9. evaluate_proxy — seulement quand la boucle continue.
10. proxy_rcca

init_deft_state.py écrit le premier DEFT_Loop_Report.html ; chaque appel commit_stage.py réussi ensuite le rafraîchit via le hook post-commit scripts/render_report.py déterministe. Arrêtez quand le contrat Benchmark passe, max_iterations est atteint ou un arrêt complet se produit. Pour un arrêt ordinaire, exécutez "$PYTHON" scripts/finalize_run.py avec la raison explicite, puis exécutez "$PYTHON" scripts/render_report.py --require-terminal après alignement token optionnel. L'ajout de rapport Cosmos-only est une vitrine de prompt bornée sourcée à partir des annotations enregistrées ; gardez toute autre convention visuelle alignée avec ChangeNet. Voir references/REPORT_RENDERING.md. Ne déléguez jamais ou ne rédigez pas à la main le rendu de rapport.

Stage References

Hard Stops

Engagez une étape erreur et n'auto-réessayez pas pour : état disque invalide ; une étiquette training riche ou non-exacte ; une entrée annotation JSONL ou non-array ; un checkpoint Cosmos Reason 3 non-converti toujours en format Omni natif à une limite Cosmos-RL ; alignement miné-vers-source manquant/ambigu ; historique mining manquant/falsifié, duplication filepath miné cross-iteration ; chevauchement de cible parmi Proxy/Benchmark/Mining ; cible Train générée en dehors de Mining et sortie AnomalyGen, ou chevauchement Proxy/Benchmark ; hash Benchmark changé ; toute erreur Benchmark utilisée pour le routing ; sortie mining manquante/vide ; une exécution AnomalyGen échouée ou vide tandis que les faux acceptations Proxy restent en suspens ; un skip anomalygen non soutenu par zéro faux acceptations dans la RCCA driving ; un enregistrement synthétique dont l'étiquette n'est pas NG ou dont l'image appairée est manquante ; un checkpoint AnomalyGen non compatible PAIDF ; un checkpoint Guardrail AnomalyGen manquant ou un log SDG montrant le screening désactivé ; un checkpoint en dehors de l'arborescence de résultats d'itération ; une spec TOML imbriquée invalide ; ground truth évaluateur inconnu ; ou une erreur programme.

Les erreurs infrastructure peuvent suivre la politique retry bornée du skill platform choisi avec un nouveau job-record lié par --retry-of ; l'étape DEFT est engagée seulement une fois, après un résultat backend terminal réussi.