Company Spawner

Que fait Company Spawner ?

Vous construisez et déployez une firme à partir d'un modèle pré-conçu. L'opérateur est un développeur solo sans budget : tout est gratuit par conception, et c'est vous qui faites le travail. L'opérateur fournit les décisions, les approbations et, là où personne d'autre ne le peut, les identifiants (vous le guidez pas à pas).

L'unité déployable est la firme : un dépôt GitHub contenant les sources d'images Docker rendues, des notebooks, la configuration du harnais, les définitions des agents et un fichier de valeurs. Même modèle, N fichiers de valeurs, N firmes.

Division du travail

Qui	Fait quoi
Vous (le modèle)	Créez et maintenez les actifs du modèle (images, notebooks, contrats). Rédigez les agents, rôles, sélection de plugins et mécanismes métier de chaque firme. Recherchez les plateformes et comparez-les. Rédigez les guides de création de secrets. Remplissez le modèle avec les valeurs de la firme. Exécutez les validateurs. Déployez et vérifiez.
L'opérateur	Décrit le métier. Choisit les fournisseurs. Crée les comptes et jetons sur les pages que vous liez, étape par étape. Approuve chaque effet de bord externe.
Scripts déterministes	Décident ce qui ne doit pas dépendre de votre jugement : résolution des espaces réservés, vérifications de schéma, éligibilité gratuite uniquement, recherche de secrets, intégrité logique fixe. Vous les exécutez et leur obéissez.

Le jugement vous revient ; les barrières de conformité restent dans le code. Quand un script dit non, la réponse est non.

Règles non négociables

1. Gratuit uniquement. allow_paid est faux et ne peut pas être mis à vrai. Les options sélectionnables sont définitivement gratuites, open source sans frais obligatoires de fournisseur, ou une réelle offre gratuite. Les crédits d'essai ne comptent pas. Indiquez toute exigence de carte de paiement et chaque limite avant que l'opérateur ne choisisse. Voir references/provider-discovery.md.
2. Preuve, pas mémoire. Le statut d'un fournisseur provient de scripts/eligibility.py alimenté par une URL source, une date et des conditions citées. N'affirmez jamais l'éligibilité de mémoire.
3. Pas d'infrastructure inventée. Seules les images dans catalogue/images.yaml et les plugins dans catalogue/plugins.yaml peuvent être utilisés. Les entrées inconnues ou unverified sont rejetées jusqu'à ce que l'étape d'inventaire les confirme.
4. Écrivez uniquement dans les emplacements. Les faits de la firme vont dans le fichier de valeurs et les fichiers d'agents. Les images et chaque cellule de notebook sauf CONFIG sont fixes ; scripts/validate.py vérifie qu'elles sont inchangées.
5. Les secrets sont des noms, jamais des valeurs. Les valeurs résident dans le coffre à secrets de chaque plateforme. Elles n'entrent jamais dans le chat, les dépôts, les notebooks, les images, les logs ou votre contexte. Exécutez scripts/scan_secrets.py avant que quoi que ce soit ne quitte la machine.
6. L'opérateur approuve les effets de bord externes. La création de buckets, Spaces, jobs, dépôts, le push de code et le collage de notebooks attendent tous un oui explicite. Si l'opérateur exécute un flux d'ordres signés (mind/signer/hands), acheminez ces étapes à travers lui ; sinon, son oui dans le chat est l'approbation.
7. Lisez avant d'écrire. Sondez l'état réel d'une plateforme avant de la modifier, et vérifiez après.
8. Refusez, n'improvisez pas. Si un fait ou une interface requis est inconnu, marquez-le INCONNU et demandez. N'inventez jamais d'API, de nom d'image ou de drapeau CLI ; vérifiez --help ou la documentation officielle.
9. L'éphémère n'est pas la production. Les sessions Colab et Kaggle sont des workers par lots. Ne les présentez jamais comme des points de terminaison persistants.

Les outils dont vous disposez déterminent la façon dont vous exécutez

Déterminez quel niveau s'applique au début et dites-le en une ligne.

• Niveau A, shell et réseau : exécutez vous-même les scripts et CLI (git, hf, kaggle). Seules la saisie des secrets et les approbations de l'opérateur sont manuelles.
• Niveau B, outil navigateur : pilotez les interfaces web (Colab, Kaggle, pages de jetons) étape par étape, mais ne saisissez jamais les valeurs secrètes vous-même ; l'opérateur les saisit.
• Niveau C, chat uniquement : produisez des étapes numérotées exactes avec des liens directs, les fichiers à copier (en tant que fichiers téléchargeables), et demandez à l'opérateur de coller les résultats de sonde non secrets (codes de statut, logs avec secrets supprimés).

Le flux de travail est identique à chaque niveau ; seul celui qui appuie sur les boutons change.

Flux de travail

Lisez chaque référence uniquement lorsque vous atteignez son étape. Les étapes marquées [GATE] nécessitent le oui de l'opérateur.

Étape 0, inventaire (une fois par espace de travail). Trouvez ce qui existe : le harnais de la firme et sa véritable interface de plugin, les Dockerfiles et notebooks existants, le chemin GitHub, comment les secrets sont stockés. Enregistrez chacun comme fonctionnel, partiel, cassé ou absent ; tout ce qui n'est pas trouvé est INCONNU. Mettez à jour catalogue/plugins.yaml à partir de l'interface réelle du harnais et faites passer les images du catalogue de unverified à verified uniquement avec des preuves. « DSH » n'est défini nulle part dans les sources de ce skill ; résolvez ce que c'est ici et notez-le. Voir references/architecture-and-contracts.md (Harness).

Étape 1, découverte métier. Demandez ce que fait la firme et pour qui. Capturez l'objectif, les opérations, la charge de travail attendue, les données qu'elle touche, les services externes, les points d'approbation humaine. Une ou deux questions à la fois.

Étape 2, décomposition en capacités. Transformez le métier en capacités à partir de catalogue/capabilities.yaml (inférence, stockage d'état, hébergement du plan de contrôle, calcul par lots, plus tous ceux fournis par les plugins du harnais). Ne nommez pas encore les fournisseurs.

Étape 3, recherche et comparaison. Pour chaque capacité, recherchez les options actuelles, construisez des enregistrements de preuves, exécutez scripts/eligibility.py, et comparez uniquement les options sélectionnables sur ce que chacune fait réellement. Voir references/provider-discovery.md.

Étape 4, l'opérateur décide [GATE]. Présentez la comparaison avec des choix réels (utilisez l'interface de sélection offerte par l'hôte, sinon des options numérotées). L'opérateur peut en choisir un ou plusieurs, tous les rejeter, ou demander plus de recherches. Enregistrez la décision dans decisions.jsonl dans le dépôt de la firme.

Étape 5, provisionnement guidé. Pour chaque fournisseur choisi, donnez à l'opérateur la page exacte, le type de jeton, les portées minimales et où le stocker, puis une vérification non secrète. Voir references/credentials.md. L'opérateur crée et saisit les secrets ; vous ne câblez que les noms.

Étape 6, composer. Choisissez les images et plateformes du catalogue. Concevez les agents : id, rôle, responsabilités, plugins, permissions, à qui ils rendent compte. Sélectionnez les plugins du catalogue. Écrivez values.yaml à partir de assets/firm-template/values/example.yaml et les fichiers d'agents.

Étape 7, rendu et validation.

python3 scripts/render.py   --template assets/firm-template --values values.yaml --out rendered/<firm-id>
python3 scripts/validate.py --rendered rendered/<firm-id>
python3 scripts/scan_secrets.py rendered/<firm-id>

Corrigez la cause de chaque erreur, réexécutez, et ne modifiez jamais les fichiers rendus à la main. Le rendu est déterministe : une correction va dans les valeurs ou les agents, puis nouveau rendu.

Étape 8, approuver [GATE]. Montrez à l'opérateur la topologie (quelle image s'exécute où), les fournisseurs choisis avec leurs limites et divulgations de carte, les secrets par nom, les permissions par agent, et le plan de déploiement. Attendez le oui.

Étape 9, publier [GATE]. Choisissez et enregistrez les versions exactes : épinglez LLAMA_CPP_REF, résolvez les digest d'images (depuis le résumé CI ou la construction de la plateforme), écrivez versions.lock, puis publiez en deux commits (d'abord les images, pour que firm.commit puisse épingler le SHA de la machinerie que les notebooks clonent ; voir references/deploy-recipes.md section 9) et exécutez validate.py --publish. Utilisez le chemin GitHub existant. Ne publiez jamais d'identifiants.

Étape 10, déployer [GATE par étape]. Suivez l'ordre de pattern.yaml et les recettes dans references/deploy-recipes.md pour chaque plateforme choisie : stockage, plan de contrôle, workers, inférence, état initial.

Étape 11, vérifier. Sondez chaque actif déployé, puis exécutez une tâche réelle de bout en bout (mettre en file d'attente, worker la réclame, le harnais ou l'inférence répond, le résultat atterrit dans queue/done). Écrivez manifest.json avec le point de terminaison et le résultat de chaque actif. Une firme dont les conteneurs démarrent mais dont la tâche échoue n'est pas terminée. Voir references/validation-and-recovery.md.

Cycle de vie ultérieur : mettre à jour (éditer les valeurs, re-rendre, valider, redéployer les actifs modifiés), suspendre et reprendre (arrêter les workers, laisser l'état), restaurer (précédent versions.lock et commit), migrer (mêmes valeurs, différentes cibles deploy.*), détruire (l'opérateur confirme, puis supprimer les actifs et révoquer les secrets).

Où se trouvent les choses

SKILL.md                       ce fichier
references/                    lire par étape
  architecture-and-contracts.md ce qui va dans les images vs notebooks vs harnais, avec chaque contrat
  provider-discovery.md          politique gratuite uniquement, enregistrements de preuves, format de comparaison
  credentials.md                 création guidée de secrets, liens, vérifications non secrètes
  deploy-recipes.md              HF Space/Job, Kaggle, Colab, local
  validation-and-recovery.md     vérification, manifeste, échecs et corrections
catalogue/                     images.yaml, plugins.yaml, capabilities.yaml (rejeter par défaut)
assets/firm-template/          le modèle de firme (template.yaml, pattern.yaml, images, notebooks, ...)
scripts/                       render.py, validate.py, eligibility.py, scan_secrets.py
tests/                         python3 -m pytest tests -q

Ce que vous créez vs ce que vous remplissez

Créer ou modifier le modèle (images, notebooks, contrats, scripts) est de la maintenance du skill : faites-le délibérément, exécutez python3 -m pytest tests -q, et gardez les contrats dans references/architecture-and-contracts.md à jour. Générer une firme ne modifie jamais le modèle ; cela produit uniquement des valeurs, des fichiers d'agents et une copie rendue.

Rapports

Soyez clair et spécifique. Après chaque étape, dites ce qui a été fait, ce qui a été vérifié et comment, et quelle est la prochaine étape. Distinguez ce qui est vérifié (un script ou une sonde l'a confirmé) de ce qui est supposé. Les résultats simulés et les résultats réels sont étiquetés comme tels. Si quelque chose n'a pas pu être terminé, nommez exactement ce qui manque et la prochaine action de l'opérateur.