Foundry : préparer et reprendre une tâche de données

Exécuter Foundry dans un espace de travail distinct, examiner les preuves et respecter autorisation et reprise.

L’entrée habituelle de TianGong Foundry est foundry-tidas-import, pour les paquets externes et le développement de données à partir de sources. foundry-tidas-authoring intervient à la demande pour un travail sémantique concret. Foundry assure conversion, validation et exécution ; le skill choisit les entrées, interprète les preuves et soumet les décisions sémantiques.

1. Préparer un répertoire distinct

La combinaison vérifiée comprend Foundry 0.1.7, CLI 0.1.13, Node 24.19.0 et TIDAS 0.3.0, distribués par l’entrée complète de Skills 0a33db1. Dans l’installateur Skills du client, choisissez foundry-tidas-import depuis tiangong-lca/skills. Si Node/pnpm/Git sont déjà disponibles et que vous utilisez l’installateur en ligne de commande :

pnpm dlx skills@1.5.23 add tiangong-lca/skills --skill foundry-tidas-import --agent codex --copy --yes

Après installation, comparez skills.foundry-tidas-import.computedHash dans le skills-lock.json du projet à la valeur ci-dessous. Il s’agit de l’empreinte de l’installation examinée, pas d’une signature. Le dépôt peut évoluer : si la valeur diffère ou manque, arrêtez-vous avant de lancer le bootstrap et examinez la nouvelle source, le verrou complet et les preuves de qualification. Ne modifiez jamais le hash pour faire réussir le contrôle.

{
  "computedHash": "b101356d3804455e4a71d34c71d693891399f529c518c27064611a726252a603"
}

Pour OpenClaw, remplacez --agent codex par --agent openclaw. Ces outils concernent cette méthode d’installation ; une fois le skill complet installé, l’environnement Foundry géré prépare lui-même ses composants.

Il faut un dossier foundry-tidas-import installé au complet, avec le bootstrap POSIX/PowerShell original et son fichier adjacent de confiance bootstrap-lock.json. Ils doivent provenir de la même distribution qualifiée. Ne composez pas un fichier de remplacement à partir d’artefacts de tâche ou d’adresses de téléchargement provisoires. Réparez d’abord toute installation incomplète ou non vérifiée.

Cet environnement géré ne nécessite pas de Node, pnpm ou Git global. Il prend en charge Linux x64/ARM64 avec glibc, macOS Apple Silicon et Windows x64. macOS Intel, Windows ARM64 et Linux musl ne sont pas pris en charge. Le premier lancement télécharge les composants fixés ; les suivants réutilisent un cache vérifié. Un cache présent ne prouve ni connexion ni achèvement.

Choisissez un espace de travail utilisateur accessible en écriture ; les répertoires du skill et de l’environnement installé peuvent être en lecture seule. Enregistrez votre paquet valide sous inputs/package.zip. Il s’agit de votre entrée originale, pas d’un jeu d’essai généré par ce tutoriel. Pour les formats natifs et un exemple de conversion locale, consultez le premier paquet tidas.

2. Enregistrer la spécification

À la racine de l’espace de travail, enregistrez task-start.json :

{
  "schema": "tiangong-foundry.task-start.v1",
  "request_id": "first-foundry-package",
  "actor_id": "local-preparation",
  "lane": "external-dataset-curated-import",
  "profile_id": "generic",
  "target_entities": [
    "process"
  ],
  "sources": [
    {
      "path": "inputs/package.zip"
    }
  ],
  "seed": null,
  "account_intent": null,
  "preparation": null
}

Cet exemple prépare uniquement des candidats locaux. account_intent: null ne sélectionne aucun compte distant. Avant tout travail lié au compte, utilisez le parcours OAuth de la CLI de confiance pour établir le projet et l’utilisateur attendus, puis sélectionnez ce compte dans la spécification initiale. Ne devinez pas l’identité ; la connexion n’autorise pas une écriture.

Le travail fondé sur des sources utilise la lane source-evidence-dataset-development et un seed JSON de candidats étayés. Ce seed doit aussi figurer dans sources. Un article ou un document de transmission n’est pas encore un ensemble de lignes TIDAS valides.

3. Démarrer et vérifier

Remplacez les chemins indicatifs par les emplacements réels. Sous POSIX :

sh "<skill-dir>/scripts/tiangong-runtime-bootstrap.sh" workspace init --workspace "<workspace>" --json

Sous Windows, utilisez PowerShell 7 qualifié sans contourner sa stratégie d’exécution :

pwsh -NoProfile -File "<skill-dir>/scripts/tiangong-runtime-bootstrap.ps1" workspace init --workspace "<workspace>" --json

Pour les appels suivants, conservez le même préfixe bootstrap et ajoutez successivement ces arguments publics. Le chemin de la spécification est résolu depuis l’espace de travail explicitement choisi. Foundry renvoie l’identifiant de tâche.

doctor --workspace <workspace> --json
task start --workspace <workspace> --spec task-start.json --json
task status --workspace <workspace> --task <returned-task-id> --actor local-preparation --json
task resume --workspace <workspace> --task <returned-task-id> --actor local-preparation --json

Vérifiez immédiatement chaque code de sortie : echo $? sous POSIX ou $LASTEXITCODE dans PowerShell. Lisez ensemble status, blockers, permissions, artifacts et next_actions. Un code de sortie ou une sortie vide ne suffit pas à établir le succès. Conservez exactement executable, argv et cwd d’une action de commande courante.

4. Continuer selon l’état courant

ready / running : suivre l’action courante. Un resume fait avancer une étape enregistrée ; répéter le même appel ne résout pas un blocage inchangé.
needs_input : lire le travail demandé, le contexte complet et le modèle, puis soumettre une décision ou un patch. Foundry valide, applique et réévalue. Conserver la langue source et ajouter un anglais étayé aux champs multilingues obligatoires.
needs_auth : OAuth de la CLI ou sélection explicite du compte nécessaire. L’exemple local s’arrête ici ; ne pas annoncer un import terminé.
permissions.state: required : vérifier tâche, entrée, compte et actions. Réutiliser toute approbation valide ; obtenir l’autorisation manquante pour le périmètre courant.
blocked / failed : conserver erreur et preuves, résoudre la cause indiquée, puis continuer la tâche originale.
completed : vérifier les preuves d’achèvement et de relecture pour le périmètre actuellement demandé. Une sous-étape terminée n’achève pas toute la tâche.

Une nouvelle sélection d’entrée ou de compte, soumise dans une spécification vérifiée, crée une révision avec historique conservé. Elle ne réinitialise aucun ancien essai. Si la réponse à une écriture est incertaine, utiliser uniquement l’action readback/recovery de la tâche originale. Ne pas répéter directement la mutation, effacer les traces ou créer un autre répertoire pour les contourner.

La préparation locale est démontrée lorsque l’entrée originale, l’identifiant courant, les artefacts réellement produits et une prochaine action ou un blocage précis peuvent être identifiés. L’import complet exige encore travail sémantique, contrôles de compte, autorisation et relecture indépendante. Voir organiser les tâches en sécurité.

5. Mise à jour, migration et retour en lecture seule

Pour task_runtime_changed, conservez l’ancien espace et examinez-le d’abord avec workspace migrate --workspace <workspace> --dry-run --json. La migration exige source, destination, acteur, requête et entrées explicites, puis l’examen du plan, du stage, de l’aperçu d’adoption, de l’application et de l’audit. Ne réécrivez pas directement l’historique.

Seules les tâches locales connues, avec preuves complètes et sans tentative d’écriture, peuvent être préparées à nouveau par le propriétaire actuel. Un historique scellé, déjà tenté ou incomplètement classifié peut rester owner-readback-only, sans nouvelle tâche exécutable. Ne le requalifiez jamais en « non tenté » et ne rejouez pas le même périmètre depuis un autre répertoire.

Les compatibilités de lecture et d’écriture sont distinctes. Choisir un ancien environnement en lecture seule via le host/gestionnaire CLI de confiance n’annule aucune écriture distante et n’accorde aucun droit d’écriture. Reconstruction du cache, migration de tâche et déconnexion sont séparées ; conservez l’espace, les preuves originales et les marqueurs de tentatives consommées.

La compatibilité de lecture de l’espace ne garantit pas qu’un ancien environnement puisse lire une tâche plus récente ; conservez les traces et restaurez la version correspondante si la liaison de tâche diffère.