Boucle OwnFramework - spécification

Que fait Boucle OwnFramework - spécification ?

Cette compétence est un adaptateur hôte pour le noyau déterministe ofloop.

Règles

• N'approuvez jamais votre propre paquet.
• N'écrivez jamais directement STATE.json, APPROVAL.json, REVIEW_VERDICT.json, les journaux d'événements ou les fichiers de verrouillage.
• Ne fabriquez jamais le jeton de confirmation TTY.
• N'ajoutez jamais d'autorité distante liée à push, merge, deploy, publish, send, payment, ou non liée.

Nouvelle spécification (flux normal)

1. Confirmez que le répertoire de travail est le dépôt Git cible.

2. Résolvez l'identité du dépôt AVANT de créer le run :

   • inspectez les remotes Git configurées ;
   • déterminez la classification du paquet à partir de l'état actuel réel, pas de l'état futur prévu ;
   • local_only signifie qu'aucune remote n'est configurée ;
   • lorsqu'une surface de revue GitHub privée fait partie du projet, créez-la / configurez-la, pushez la base de référence prévue, prouvez la parité locale/remote, et utilisez github_private avant ofloop spec new ;
   • ne créez pas un run local-only puis n'ajoutez pas de remote par la suite.

3. Inspectez seulement suffisamment de contexte du dépôt pour rédiger un paquet limité et précis.

4. Utilisez ofloop spec new <repo> "<mission>" pour créer le run.

5. Rédigez WORK_PACKET.md en utilisant le schéma du dépôt et les conventions de paquet. Déclarez des capabilities portables pour les besoins de l'hôte/outil au lieu d'incorporer des chemins machine ou de reconstruire manuellement la topologie réseau spécifique à l'outil (par exemple toolchain.python, package.uv, browser.playwright.chromium). Utilisez runner_profile uniquement comme un NOM de profil de confiance lorsque la mission nécessite une politique de modèle/effort commandée par l'opérateur ; les paquets ne transportent jamais de flags Claude bruts. Utilisez network_read_allowlist uniquement pour les hôtes de lecture supplémentaires spécifiques au paquet qui ne sont pas déjà fournis par un contrat de capacité. N'ajoutez jamais de joker large, de schéma, de port, de chemin, de point de terminaison de publication, de socket de démon ou d'hôte non lié. Avant la mise en file d'attente, exécutez ofloop capabilities probe pour inspecter l'hôte et ofloop capabilities preflight <repo> <capability>... pour l'ensemble exact demandé. Si une capacité ordinaire demandée est indisponible, provisionnez-la ou commandez-la sur l'hôte ou révisez le paquet avant l'exécution ; ne commencez pas à utiliser HOME/PATH ni ne retombez sur une exécution non isolée. Les capacités privilégiées container.docker / local.http-service nécessitent en plus le flux de commissionnement de la canarie propriétaire de l'opérateur.

6. Pour les paquets PROGRAM avec des résultats spécifiques aux points de contrôle, conservez le contrat complet d'acceptation de la mission au niveau supérieur et assignez-le de manière déterministe avec les acceptance_criterion_ids de chaque point de contrôle. Si un point de contrôle utilise des identifiants AC limités, chaque point de contrôle doit déclarer une liste non vide et l'union doit couvrir chaque identifiant AC de niveau supérieur. N'utilisez pas not_applicable pour de futurs critères de point de contrôle simplement pour satisfaire la couverture.

7. Validez la forme du paquet avec le validateur pris en charge.

8. Revenez à l'opérateur :

   • repo
   • run_id
   • packet_sha256
   • spec_baseline_branch / spec_baseline_sha
   • execution_mode / checkpoint_count
   • mise en file d'attente non supervisée canonique : ofloop supervisor enqueue
   • statut canonique : ofloop supervisor status
   • horloge d'exécution lorsqu'elle n'est pas déjà en cours d'exécution en tant que service : ofloop supervisor serve
   • adaptateur Claude premier plan/débogage uniquement : /of-loop:build
   • adaptateur Claude premier plan/débogage uniquement : /of-loop:review

9. STOP. Le fonctionnement normal en arrière-plan est prioritaire au superviseur. Mettez le run en file d'attente ; un service superviseur déjà commissionné le consomme, ou ofloop supervisor serve peut exécuter l'horloge d'exécution manuellement. Le premier BUILD actionnable crée automatiquement le sceau d'exécution immuable.

État interne vs orienté opérateur

Le nom de stockage interne AWAITING_APPROVAL est conservé pour la compatibilité ascendante. La signification orientée opérateur est READY_TO_START (le run est pouvant être démarré ; aucune cérémonie d'approbation n'est requise).

Compatibilité uniquement : pré-sceau TTY hérité

La commande historique optionnelle de pré-sceau TTY reste comme pré-sceau strict compatible ascendante / optionnel. Elle N'est PAS requise par le flux de travail normal et ne doit PAS apparaître dans les instructions de l'opérateur.

Immutabilité du paquet

Avant le premier sceau d'exécution : les amendements de paquet sont pris en charge via la surface d'amendement prise en charge.

Après le sceau d'exécution : le paquet est immuable. Une mission/portée modifiée nécessite un NOUVEAU RUN.

Identité du dépôt avant exécution

target.classification est l'identité du dépôt au moment de la spécification, pas un souhait de déploiement futur. Un run destiné à un projet privé revu sur GitHub doit être créé seulement après que la remote privée et la branche de base existent et que HEAD local est prouvé égal à la base de référence remote prévue.

Si la topologie/classification distante change après spec new mais avant le premier sceau d'exécution, préférez arrêter le run jamais démarré et créer un nouveau run à partir de l'état final du dépôt. Ne comptez pas sur la première réclamation BUILD pour découvrir un décalage local_only + remote évitable.

L'exécution actuelle du noyau échoue déjà en mode fermé lorsqu'un paquet local_only a des remotes configurées. Le flux de travail de spécification devrait empêcher d'atteindre ce refus en fonctionnement normal.

Vérification préalable de l'autonomie PROGRAM

Avant qu'un PROGRAM v3 soit considéré comme prêt :

• utilisez acceptance_criterion_ids sur les points de contrôle ; n'émettez jamais de checkpoint.acceptance_criteria ;
• déclarez le plus petit ensemble de capabilities portables nécessaire à la mission et vérifiez-le avant la mise en file d'attente. L'autorité de lecture réseau effective est l'union figée des hôtes network_read_allowlist spécifiques au paquet et des hôtes dérivés exacts des capacités. Une liste de paquets vide signifie donc AUCUN domaine supplémentaire, pas nécessairement zéro domaines lorsqu'une capacité de paquet/navigateur déclarée nécessite des points de terminaison de téléchargement restreints ;
• choisissez runner_profile uniquement parmi les profils de confiance exposés par ofloop capabilities profile <name> ; les modèles explicites doivent être des identifiants de modèle de fournisseur épinglés plutôt que des alias Claude mouvants. Un effort explicite nécessite également ofloop capabilities attest-effort <name> sur le runtime Claude actuel. L'identité du profil est liée au run et peut sélectionner uniquement un modèle/effort sémantique, jamais une autorité sandbox/outil/MCP/session ;
• validez les budgets du paquet par rapport aux plafonds exécutables avant la première exécution ;
• traitez les valeurs build/review/repair de niveau supérieur comme des enveloppes cumulatives PROGRAM ;
• à moins de limiter intentionnellement l'ensemble du PROGRAM, financez ces enveloppes globales à partir des sommes des budgets locaux des points de contrôle ;
• assurez-vous qu'une allocation de réparation globale est réalisable par l'allocation build/review globale ;
• choisissez max_pass_runtime_seconds en fonction de la complexité d'un passage sémantique (jusqu'à 28800 par passage ; le fusible de repli non déclaré est 3600, donc tout passage qui nécessite légitimement plus d'une heure doit déclarer son budget) ;
• déclarez risk_budget.max_runtime_seconds comme enveloppe temps réel de l'ensemble du run lorsque le PROGRAM peut légitimement s'exécuter longtemps (jusqu'à 2419200). supervisor enqueue le consomme comme plafond opérationnel temps réel ; sans cela, aucun plafond temps réel ne s'applique et le run est limité uniquement par ses protections de passage sémantique / réparation / non-progression.

Un paquet qui ne peut découvrir un plafond déterministe impossible qu'après qu'un modèle a déjà effectué du travail est un défaut de spécification et ne doit pas pouvoir être démarré.

Sémantique budgétaire non supervisée

Les plafonds de jetons sont désactivés par défaut et les plafonds de coûts sont désactivés par défaut. L'exécution non supervisée est limitée par des protections de progression significative (plafonds de passage et de réparation, série de non-progression, fusible de répétition de résultat identique, politique de nouvelle tentative par classe d'échec), pas par la conservation des jetons ou des coûts. Les opérateurs qui souhaitent une ligne de dépense stricte peuvent passer --max-cost-usd / --max-total-tokens / --max-wall-seconds explicitement au moment de la mise en file d'attente. Lorsqu'un plafond de coût global positif est financé, le superviseur réduit également chaque passage en mode d'impression Claude avec le budget de run durable exact restant ; le registre Loop reste la source comptable globale canonique.