414960701/harness-distiller

Harness Distiller (Distillateur de harnais d'agent)

Distillez les preuves publiques en harnais d'agent (Agent Harness) implémentables, vérifiables et évolutifs. Traitez les noms de produits comme des recettes de comportement et de capacité, sans copier la marque, les prompts propriétaires, les éléments protégés ou les implémentations internes non vérifiables.

Règles impératives

1. Distinguez code, official-doc, protocol, behavior, inference ; ne présentez jamais une inference d'un produit closed-source comme un fait de code source.
2. Les quatre niveaux de maturité partagent le même protocole, le même modèle d'état et les mêmes limites de modules ; une mise à niveau ajoute uniquement des capacités et des optimisations, sans générer quatre ensembles d'implémentations incompatibles.
3. Commencez par une tranche verticale complète : modèle → boucle d'agent → un outil de lecture → permissions → exécution → événement → état → interface.
4. Maintenez le runtime headless ; les interfaces CLI, TUI, IDE, Bureau et Web interagissent uniquement via un protocole de commandes/événements versionné.
5. Séparez la politique d'approbation (approval policy) de l'application des contraintes du sandbox ; l'approbation utilisateur ne remplace pas les limites OS, conteneur, fichier ou réseau.
6. Chaque élément "implémenté" doit avoir un emplacement dans le code ; chaque élément "vérifié" doit disposer d'un test exécutable ou d'une preuve de comportement reproductible.
7. Ne considérez pas qu'un modèle capable d'appeler un shell constitue un "harnais complet". Vous devez implémenter : annulation, échec, reprise, persistance, permissions et reconstruction de l'état de l'interface.

Lectures à la demande

• Pour choisir un produit et vérifier l'exhaustivité du répertoire : lisez references/catalog.md.
• Pour choisir un niveau ou effectuer une mise à niveau : lisez references/levels.md.
• Pour déterminer quand une capacité peut être marquée comme vérifiée : lisez references/capabilities.md.
• Pour évaluer la fiabilité des preuves : lisez references/evidence.md et references/source-registry.md.
• Pour comprendre les limites partagées : lisez references/architecture.md.
• Avant de commencer à coder : lisez impérativement references/implementation/index.md, puis chargez les spécifications d'implémentation selon son routage.
• Pour sélectionner une capacité partagée : lisez references/knowledge/index.md et chargez uniquement les modules de connaissance sélectionnés.
• Pour forker un produit : lisez references/products/<product>/index.md et chargez les 13 dossiers de ce produit dans l'ordre spécifié par l'index.
• Pour un nouveau projet : lisez references/workflows/build.md.
• Pour mettre à niveau un projet existant : lisez references/workflows/upgrade.md.
• Pour valider un projet : lisez references/workflows/validate.md.

Analyse des requêtes

Analysez à partir de la requête utilisateur et du dépôt cible :

• recipe : un produit, hybrid ou custom ;
• level : runnable, usable, productive ou polished ;
• surfaces : cli, tui, ide, desktop, web, sdk, headless ;
• execution : local, container, remote ou combinaison ;
• stack : privilégiez la pile existante du dépôt cible ; pour un nouveau projet, choisissez en fonction du produit, de sa surface et des exigences de sécurité ;
• providers : fournisseurs de modèles, modèles locaux et exigences de dégradation des capacités ;
• security : modèle de menace personnel, équipe ou entreprise ;
• distribution : code source, package, extension, application de bureau ou service hébergé.

Lorsque l'utilisateur dit simplement "faites un produit comme Codex/Claude Code/QoderWork", sélectionnez par défaut la recette correspondante, le niveau usable, la surface principale du produit plus headless, et enregistrez les hypothèses dans le registre des décisions.

Utilisez les valeurs par défaut de repli pour les autres choix manquants : execution=local, security=personal, distribution=source ; pour les recettes : Codex-like → Rust + headless/TUI, Claude-Code-like → TypeScript + headless/CLI, QoderWork-like → TypeScript + Tauri/Rust executor + headless/Desktop, Aider-like → Python + headless/CLI, OpenCode → TypeScript/Bun + headless/TUI, OpenHands → Python + TypeScript/React + headless/Web/SDK, AgentScope, LangGraph et Deep Agents → Python + headless/SDK. Si le fournisseur n'est pas spécifié, implémentez d'abord un contrat neutre vis-à-vis du fournisseur, un fixture scripté déterministe et une interface d'adaptateur compatible OpenAI ; ne liez pas un service payant sans autorisation ; demandez la configuration du fournisseur avant l'intégration réelle.

Processus de génération

1. Vérifiez le dépôt, la pile technique, les instructions existantes, les modifications non validées (dirty changes) et l'environnement d'exécution disponible.
2. Confirmez dans references/catalog.md que le produit est au niveau d'implémentation ; pour une recette prévue mais dont les 13 dossiers ne sont pas complets, ne générez pas de fork de produit ; complétez d'abord les dossiers ou passez explicitement en hybrid/custom. Ensuite, exécutez scripts/new_blueprint.py pour créer .harness-distill/blueprint.yaml.
3. Lisez le fichier index.md, product-contract.md, recipe.md, acceptance-tests.md du produit.
4. Selon la recette, chargez les spécifications d'implémentation et les documents de connaissance partagée ; établissez la fermeture des dépendances de capacités.
5. Écrivez .harness-distill/evidence.md en enregistrant les assertions, les URL, les dates, les versions/commits, les types de preuve et les niveaux de confiance.
6. Écrivez .harness-distill/decisions.md en enregistrant les choix d'architecture, les inférences closed-source, les non-objectifs, les risques et les points de retour.
7. Implémentez d'abord le protocole, le squelette d'état et une tranche verticale exécutable ; sauvegardez et rejouez la trace d'événements.
8. Complétez les capacités dans l'ordre : schema → protocol → runtime → executor/policy → surface → migration.
9. Ajoutez simultanément les tests de contrat, de scénario, de sécurité, de reprise, de migration et les tests boîte noire du produit.
10. Exécutez scripts/validate_blueprint.py, les vérifications du dépôt cible et le fichier acceptance-tests.md du produit.
11. Marquez une capacité comme verified uniquement si elle possède un emplacement dans le code et une preuve de test.

Contrat minimum des artefacts

Le projet cible doit contenir une structure équivalente :

.harness-distill/
  blueprint.yaml       # sélection, niveau, capacités, état et version du contrat
  evidence.md          # preuves publiques et limites des inférences
  decisions.md         # décisions d'architecture, non-objectifs, risques et migrations
src/
  protocol/            # commandes/événements/erreurs/schéma/négociation des capacités
  runtime/             # machine à états des tours, annulation, reprise, budget, pilotage
  model/               # adaptateur fournisseur et négociation des capacités
  context/             # instructions, récupération, mémoire, budget, compression, cache
  tools/               # schéma, registre, routeur, cycle de vie, artefacts
  policy/              # autoriser/refuser/demander/modifier et portée d'approbation
  execution/           # espace de travail, fichiers, shell, patch, réseau, sandbox
  state/               # thread/tour/élément/événement/point de contrôle/migration
  surfaces/            # adaptateurs CLI/TUI/IDE/Bureau/Web
tests/
  contracts/           # contrats de protocole, fournisseur, outil et stockage
  scenarios/           # boucles fermées de tâches réelles
  security/            # dépassement, injection, secrets, réseau et évasion
  recovery/            # crash, duplication de messages, déconnexion et migration

Les noms peuvent être adaptés selon les conventions du langage, mais vous ne devez pas fusionner les frontières entre : politique et application, état du domaine et projection UI, historique du modèle et faits persistants.

Critère d'exhaustivité

Un harnais complet pour le niveau sélectionné n'est atteint que lorsque toutes les conditions suivantes sont remplies :

• blueprint, contrat produit et emplacements d'implémentation cohérents ;
• la trace thread/tour/élément/événement est persistable et rejouable pour le niveau runnable ; pour usable, elle prend en charge la pagination et la reprise après redémarrage ; pour polished, elle nécessite en plus la migration inter-version ;
• appels d'outils/résultats appariés de manière atomique, avec sémantique claire pour l'annulation, le timeout et les résultats tardifs ;
• la compression du contexte sélectionné ne brise pas l'atomicité des appels d'outils, la hiérarchie des instructions et le périmètre d'audit ;
• les actions restreintes sont d'abord décidées par la politique, puis appliquées par une véritable limite d'exécution ;
• l'interface utilisateur est reconstructible à partir de snapshots + événements, sans dépendre des objets mémoire du runtime ;
• la reprise après crash pour les niveaux usable et supérieurs ne répète pas les effets de bord irréversibles ;
• les scénarios du niveau actuel du fichier acceptance-tests.md du produit passent ;
• la note de livraison liste les comportements non pris en charge, les lacunes de preuves et les chemins de mise à niveau directs.

Mise à niveau inter-niveaux

Lors d'une mise à niveau directe depuis un niveau inférieur vers un niveau supérieur :

1. Validez le blueprint, le protocole et le schéma de base de données actuels ;
2. Calculez le delta des capacités et déroulez les dépendances intermédiaires ;
3. Migrez d'abord le schéma, puis étendez le protocole, le runtime, l'exécuteur et les interfaces ;
4. Conservez l'ancienne configuration et les anciens événements sur au moins une frontière de compatibilité de migration ;
5. Établissez des points de contrôle, des clés d'idempotence ou une confirmation humaine pour les actions externes irréversibles ;
6. Exécutez toutes les régressions du niveau inférieur et les validations du nouveau niveau ;
7. Ne mettez à jour le statut des capacités qu'après avoir passé les tests.