Cycle de vie du module Holoscan HoloHub
Objectif
Conduire un module Holoscan réutilisable de la mise en page et du contrat API, en passant par producteur, consommateur, et preuve d'installation d'artefact clean.
Entrées
Exiger le contrat API, le checkout, la mise en page, les identités, le plancher SDK, la licence, le responsable, les formats de package et les vérifications d'acceptation provenant de la requête ou d'une source de référentiel faisant autorité. Si des métadonnées de version conséquentes restent inconnues, arrêter avant l'échafaudage ou l'empaquetage plutôt que de deviner.
- un contrat API producteur/consommateur réutilisable plutôt qu'une application ordinaire ;
- le checkout HoloHub fourni par l'utilisateur ;
- référentiel externe autonome ou mise en page de descripteur en arborescence ;
- identités de langage, module/opérateur/package, version SDK minimale, licence, détails du responsable et formats de package demandés ;
- vérifications d'acceptation producteur, consommateur et artefact finies.
Router une application ordinaire vers holohub-app-lifecycle et une commande ./holohub concrètement défaillante ou incorrecte vers holohub-debug-build-run. Si la skill correspondante n'est pas disponible, préserver le contexte de handoff et nommer la skill à installer au lieu d'étendre ce workflow.
Prérequis
- Toujours lire le contrat CLI.
- Lire développement de module pour la mise en page, la nomination, l'échafaudage, les métadonnées, l'implémentation, la construction et le scope de test.
- Lire consommateur et empaquetage quand une application consommatrice, une installation modifiable ou un artefact binaire sont en scope.
- Utiliser les tutoriels actuels créer-un-module et utiliser-un-module de HoloHub comme walkthroughs producteur et consommateur, puis vérifier les commandes sensibles aux versions par rapport au checkout sélectionné et au contrat CLI.
Le AGENTS.md du checkout sélectionné, l'aide locale, les conseils de module, les schémas, les modèles, les tutoriels et les exemples proches sont l'autorité technique en direct où ils ne contredisent pas les contraintes utilisateur, système ou de sécurité.
Instructions
À chaque étape, une commande wrapper défaillante ayant un effet termine ce chemin heureux ; suivre Dépannage avec son contexte exact. Analyser les résultats de diagnostic en lecture seule et s'arrêter seulement quand une capacité défaillante est requise par le module, consommateur, environnement d'empaquetage ou preuve demandée.
- Préserver et orienter. Enregistrer HEAD complet, statut concis, version wrapper/environnement local et sortie de découverte. Préserver la révision du checkout et le travail non lié.
- Choisir la mise en page. Utiliser un référentiel
holoscan-<name>externe pour une version indépendante ou un descripteur en arborescence sousmodules/pour le code maintenu avec HoloHub. - Corriger les identités avant les fichiers. Garder le nom d'affichage, le module/namespace
snake_case, le référentiel/packageholoscan-<kebab-case>et le slug opérateursnake_case_opcohérents. - Scaffolder les modules externes en toute sécurité. Prévisualiser la configuration du modèle, inspecter l'installation de sa dépendance hôte et obtenir une autorisation utilisateur explicite avant la véritable configuration. Seulement après que la configuration réussisse, prévisualiser et exécuter la commande create complètement spécifiée et non-interactive, en traitant la prévisualisation comme potentiellement mutante. Exiger un parent existant, inspecter le référentiel Git staged généré et ne jamais le pousser sans une requête.
- Implémenter le plus petit contrat public. Valider les métadonnées, exposer un opérateur/API utile, ajouter des tests déterministes et ajouter une démo finie qui consomme la même surface publique qu'un autre projet. Garder la politique de démo hors de l'opérateur réutilisable.
- Construire et tester honnêtement. Prévisualiser et exécuter les commandes de module et démo container-first. Dans HoloHub, tester chaque opérateur et démo déclarés car
test <module>n'est pas scoped au module. Dans un référentiel généré, combiner son test à l'échelle du référentiel avec des cibles pytest ou CTest ciblées. - Prouver un vrai consommateur. Déclarer la dépendance de métadonnées exacte et un SHA complet immuable pour une source externe. Utiliser une surcharge de source montée pour l'itération rapide ou une installation modifiable seulement dans l'environnement rapporté par
env-info --json. Enregistrer le hook et le retirer même si une étape ultérieure échoue ; si la suppression échoue, rapporter l'environnement exact et l'état du hook. - Empaqueter seulement après preuve de comportement. Prévisualiser et construire les artefacts DEB/WHEEL demandés, inspecter l'identité/métadonnées/dépendances/payload et installer chaque format dans un consommateur clean artefact-only avec une vérification d'importation/lien et une démo finie.
- Valider et transférer. Relancer les vérifications producteur et consommateur-clean,
git diff --checket statut final. Dans un checkout dirty, restreindre l'auto-correction lint aux chemins de tâche ; avant un commit demandé, valider le changement candidat exact avec le lint complet requis par le référentiel dans un checkout disposable clean. Confirmer qu'aucun artefact généré ou hook modifiable ne sont staged. Ne pas committer, pousser, uploader, publier ou relâcher sans autorisation.
Dépannage
Si une commande wrapper échoue, arrêter le chemin heureux et transférer sa commande exacte, révision, état dirty, entrées et résultat observé à holohub-debug-build-run.
Exemples
- Scaffolder et empaqueter un opérateur réutilisable avec preuve consommateur-clean : utiliser cette skill.
- Empaqueter une application ordinaire ou diagnostiquer une construction défaillante : router hors de cette skill.
Limitations
- Préserver le travail non lié. Ne pas réinitialiser, nettoyer, supprimer des fichiers non liés, modifier la configuration hôte, élargir les privilèges, committer, pousser, uploader, publier ou relâcher sans autorisation.
- Ne jamais exécuter
sudo ./holohub; obtenir l'approbation pour les packages hôtes, exécution local-hôte, conteneurs root, appareils/capacités ou changements de permission. - Garder la sortie de construction, données, installation, package et hooks modifiables hors des commits.
- Protéger les identifiants, sources propriétaires, données de patients, médias privés et métadonnées d'identification.
- Réclamer le support, la reproductibilité, l'installabilité, la performance ou la sécurité seulement pour le producteur, artefacts et preuve consommateur-clean réellement collectés.
Sortie
Retourner la mise en page et les identités, API/démo publique, métadonnées et enregistrements, résultats de commande preview et réels, scope de test honnête, preuve consommateur, identité/contenus/résultats d'installation d'artefact, limitations de licence et publication et état worktree final.
Pour une requête planification-seulement, retourner l'ordre proposé, sources de métadonnées faisant autorité, frontières d'approbation et exigences de preuve sans réclamer de résultats.