i4h Workflow - Create Env

Purpose

Créer la première version exécutable d'un nouvel environnement workflows/agentic en forgeant l'env existant le plus proche. Gardez cette skill focalisée sur l'échafaudage d'env : YAML, assets, task, classe env, runtime, et validation. N'utilisez pas cette skill pour polir une scène existante, ajouter des props/caméras optionnels, ou bake des édits bridge ; utilisez [[i4h-workflow-scene-edit]] pour cela.

Base Code

Résolvez et travaillez depuis la racine i4h-workflows :

ROOT="${I4H_WORKFLOWS:-$(git rev-parse --show-toplevel 2>/dev/null)}"
if [ ! -d "$ROOT/workflows/agentic" ]; then
  ROOT="${I4H_WORKFLOWS:-$HOME/i4h-workflows}"
  [ -d "$ROOT/workflows/agentic" ] || git clone https://github.com/isaac-for-healthcare/i4h-workflows "$ROOT"
fi
export I4H_WORKFLOWS="$ROOT"; cd "$ROOT"

What to Load

Avant d'éditer, ne chargez que les références qui correspondent à la demande :

• Toujours charger skills/i4h-workflow/references/repo-map.md.
• Toujours charger skills/i4h-workflow-create/references/create-contract.md.
• Charger skills/i4h-workflow-create/references/env-authoring-patterns.md pour choisir l'env source, le propriétaire robot, la pile de politique, et le pattern YAML.
• Charger skills/i4h-workflow-create/references/hybrid-layout-rules.md uniquement pour les envs hybrides scène+robot, travail de footprint/hauteur de table G1, mise à l'échelle catalog USD, ou layout de surface de support.
• Charger un fichier recipe uniquement quand le prompt le correspond exactement assez pour éviter de re-décider les composants.

Routage recipe :

Create Contract

Créez d'abord le shell env. Une tâche create normale devrait produire exactement ces surfaces sauf si le pattern existant choisi requiert une exception explicite :

Conservez tous les chemins relatifs à la racine du repo et gardez le préfixe workflows/agentic/. Ne créez pas un nouveau package de politique, README, docs, ou édits de module partagé sauf si l'utilisateur le demande explicitement et que la pile de politique en a vraiment besoin.

Workflow

1. Résolvez les composants : id env, env source, source scène/assets, propriétaire robot, pile de politique, modèle/checkpoint, caméras, objets/destinations, règle de succès.
2. Inspectez les fichiers YAML env source, classe env, assets, task, runtime, et pile de politique avant d'écrire du code.
3. Forgez le pattern le plus proche qui fonctionne. Préservez le style inline-scene vs registry-asset ; n'inventez pas une nouvelle architecture.
4. Gardez la première version minimale et exécutable. Le polissage visuel optionnel, les props supplémentaires, les nouvelles caméras, et les changements de layout se font via scene-edit après que l'env existe.
5. Exécutez la validation et corrigez la source jusqu'à ce que l'env se construise et que la scène rendue soit visuellement saine.

Pour une correspondance recipe exacte, ne re-dérivez pas l'architecture après chargement de la recipe. Lisez uniquement les fichiers source que la recipe nomme, ignorez les fichiers runtime source volumineux quand la recipe dit que le runtime est une re-export, puis écrivez les cinq fichiers contract immédiatement. N'inspectez pas les internals du framework tiers sauf si une erreur de validation l'exige.

Forme du plan :

Env id:
Source env / recipe:
Scene/assets source:
Robot owner:
Policy stack + model/checkpoint:
Objects/destinations:
Success rule:
Files to create:
Validation:

Hard Rules

• Env YAML est la source de vérité pour robot, politique, caméras, texte task, mapping dataset, et defaults train.
• Forgez à partir de l'implémentation existante la plus proche. Pour les envs hybrides, l'intégration robot vient du propriétaire robot et la construction de scène vient de la source scène.
• Les tâches de tri ont besoin d'au moins deux types d'objet, au moins deux destinations, et une règle de succès qui échoue sur les placements échangés.
• Les props de destination statiques/cinématiques ne doivent pas exposer .data.root_pos_w ; les vérifications de succès doivent revenir à entity.get_world_poses().
• Les fonctions référencées par func= à l'intérieur de classes config doivent être définies au-dessus de ces classes.
• Les envs G1 WBC ont besoin de clairance de footprint et de valeurs ground/base-height appairées ; chargez hybrid-layout-rules.md avant de choisir ces chiffres.
• Les caméras fixes supplémentaires sont normalement du travail scene-edit/bake. Si un prompt create requiert explicitement une caméra politique/dataset, chargez la caméra scene-edit et les références bake et câblez toutes les surfaces en une seule passe.

Validation

Exécutez ces vérifications statiques :

python -m py_compile <changed-python-files>
workflows/agentic/policy/run.sh --list-envs
workflows/agentic/arena/run.sh --env <env> --dry-run
workflows/agentic/policy/run.sh --env <env> --dry-run

Puis exécutez le vrai portail build/visual depuis skills/i4h-workflow-create/references/create-validation.md. --dry-run est shallow : il ne prouve pas que la task/assets s'instancient ou que la scène est visuellement utilisable. Ne rapportez pas un nouvel env comme prêt tant que le bridge n'a pas atteint ready, que les objets clés ne sont valides, qu'une capture viewport n'a été inspectée, et que le bridge ne soit arrêté avec :

workflows/agentic/arena/stop.sh --env <env>

Si Isaac Sim ne peut pas se lancer sur l'hôte, rapportez cela comme un blocker et incluez les résultats des vérifications statiques ; ne présentez pas static-only comme un succès.

Hand Off to Scene Edit

Après que le shell env passe la validation create, utilisez [[i4h-workflow-scene-edit]] pour :

• Ajouter, déplacer, redimensionner, ou remplacer des objets/assets.
• Ajouter des caméras fixes room/overhead/wrist.
• Édits live bridge.
• Bake des changements live en source.
• Exécuter local-agent/validate-bake.sh.

Le workflow scene-edit possède les snippets d'objet, snippets de caméra, détails d'endpoint bridge, et checklists de bake afin que ce workflow create reste petit.

Prerequisites

• La configuration du workflow est complétée via [[i4h-workflow-setup]] ; .venv, les checkouts tiers, et le support de lancement Isaac Sim sont présents.
• L'env source et l'id env cible sont connus, ou le prompt fournit assez d'informations pour les choisir parmi les patterns existants.
• La validation bridge s'exécute sur un hôte GPU qui peut lancer Isaac Sim.

Limitations

• Créez un env par invocation.
• Forgez les patterns existants ; n'inventez pas une nouvelle pile de politique ou un framework partagé.
• Utilisez scene-edit pour le polissage post-create, les props optionnels, le baking de caméra, et la persistance source des édits live.
• --dry-run n'est pas un substitut pour le build bridge et le portail de validation visuelle.

Troubleshooting

• Missing setup : si .venv, les checkouts tiers, ou les entrypoints run.sh manquent, exécutez d'abord [[i4h-workflow-setup]].
• Env not listed : vérifiez que le YAML existe à workflows/agentic/config/environments/<env>.yaml et que tous les fichiers utilisent le préfixe repo-root complet workflows/agentic/.
• Build fails after static checks pass : inspectez la première stack trace Isaac/arena ; les causes courantes sont de mauvais cfg kwargs, un helper défini en dessous d'une classe config, ou une observation pointant vers un capteur manquant.
• Scene looks wrong : corrigez la source ou utilisez scene-edit pour ajuster live et bake ; ne rapportez pas le succès à partir des vérifications statiques seules.

Final Response

Rapportez l'id env, les choix source, les fichiers créés, les commandes de validation et les résultats, les chemins de capture, et tout blocker. Ne commitez pas les changements sauf si l'utilisateur le demande explicitement.