zenx0x/allinluna

All in Luna

All in Luna est un point d'entrée public unique. Accepte l'une de ces entrées :

• une idée ou un objectif en une phrase ;
• un plan existant ;
• un instantané d'exécution active ou d'exécution héritée ;
• un paquet Research Routes.

Compile l'entrée en un RunIntent typé, sélectionne un Workflow Pack enregistré, et compile son TaskGraph contenant les contrats, dépendances, propriété, conditions d'achèvement, templates WorkGraph et valeurs par défaut des ressources. Ensuite, appelle le runtime/CLI vNext pour persister le graphe, libérer les Lanes prêtes, ingérer les reçus réels de l'hôte, et continuer jusqu'à ce que le résultat racine soit complet ou qu'un blocage concret soit renvoyé.

Relais d'action exact de plus haute priorité

Les valeurs logiques LocalDispatchIntent ne sont pas des HostActions. Un HostAdapter les résout d'abord en un plan lane-direct-work/v1 ou en un opcode exact HostAction.tool :

1. Invoque cet outil exact avec HostAction.arguments.
2. Ne traduit, n'approche ni ne substitue jamais une autre capacité.
3. Une top_level_task ne peut jamais se rabattre sur un sous-agent, le thread courant ou une exécution directe.
4. Ingère immédiatement le reçu brut, puis recommence.
5. Si aucun HostAdapter n'est lié, retourne ACTION_RELAY_REQUIRED et préserve l'action exacte.
6. Retourne HOST_CAPABILITY_BLOCKED seulement après que la découverte de capacité confirme que l'outil exact est absent.

Pour le travail local, native_preferred utilise un worker natif annoncé ou un véritable plan Lane-direct ; native_required bloque en cas d'absence et direct_only ne génère jamais. Un reçu direct n'est pas une complétion : la Lane doit exécuter la WorkUnit et produire un work-handoff/v1 vérifié.

Les reçus fournissent explicitement action_contract_hash, actual_tool et actual_capability. Un mauvais outil réel est une HOST_PROTOCOL_VIOLATION, pas une preuve qu'une tâche a démarré.

Bootstrap de Lane et pilotes persistants

Chaque dispatch public codex_app__create_thread intègre un objet complet lane-bootstrap/v1 à la fois dans sa charge utile d'action durable et dans le prompt enfant. Il comprend les identités d'exécution/tâche/tentative, le digest TaskEnvelope, le chemin SQLite du runtime, les références Contract/Context/WorkGraph, l'espace de travail, les capacités locales autorisées, les capacités globales interdites et la réponse lane-handoff/v1 requise. Une Lane enfant doit rouvrir ce même Store et charger ces objets elle-même ; son prompt n'est jamais seulement un résultat en langage naturel. CoordinatorDriver est la boucle externe durable : planifier les actions exactes, ingérer les reçus, attendre/lire les threads de niveau supérieur, ingérer les handoffs typés de Lane, réconcilier, et immédiatement libérer les tâches nouvellement prêtes. LaneDriver effectue la boucle WorkGraph locale correspondante, incluant les instantanés, l'expansion locale dynamique, les handoffs de worker, les corrections sur le même worker et la synthèse de handoff de Lane. Une vague n'est qu'un groupement d'interface utilisateur : le travail prêt pour les dépendances est libéré immédiatement.

Forme du runtime

Conversation
  -> Coordinateur global
       -> Lanes de tâches indépendantes
            -> WorkUnits récursives bornées
                 -> outils / compétences / plugins / MCP

Conserve la sortie brute des outils dans le Store d'artefacts. Passe les contrats typés, les références d'artefacts, les tranches de contexte, les reçus et les handoffs vers le haut. Une WorkUnit enfant doit rétrécir la portée, l'autorité, la propriété et l'enveloppe de ressources de son parent ; une requête entre Lanes devient une requête de promotion.

Routage des entrées et des Packs

Utilisez SinglePublicSkillAPI.compile() ou allinluna start :

• objectif simple -> delivery par défaut ;
• plan existant -> import hérité en lecture seule, puis delivery ;
• exécution active -> import d'état d'exécution en lecture seule et compilation orientée récupération ;
• paquet Research Routes -> research-routes-bridge, préservant les Claims, Evidence, inconnues, contradictions, régimes d'échec, HumanDecision et limites d'autorisation d'expérience.

Utilisez gsd lorsque l'utilisateur demande explicitement son workflow. Son Pack exécutable fournit clarifier, spécifier, décomposer, implémenter, vérifier et intégrer, l'expansion locale dynamique des Lanes, les WorkUnits bornées, les handoffs de contrat et la récupération locale des échecs. N'ajoutez pas de phases GSD à Core.

Ressources et permissions

Les choix de ressources suivent cette priorité : demande explicite de l'utilisateur, puis surcharge d'une Tâche/WorkUnit, préférence utilisateur, capacité du Pack, capacité de l'hôte de déploiement, et enfin la session/hôte par défaut. Core est neutre vis-à-vis des fournisseurs et ne code pas en dur un fournisseur ou une route de modèle concrète. Conservez séparément les valeurs demandées, résolues et réelles. Si l'hôte ne peut pas fournir un reçu de modèle réel, enregistrez actual: null et actual_state: unresolved ; ne prétendez jamais à un repli ou ne fabriquez jamais un reçu. Une portée plus étroite peut changer les ressources de calcul mais ne peut pas étendre les permissions ou la propriété.

La télémétrie de route de ressource hôte est un diagnostic d'adaptateur optionnel, pas une exigence d'exécution ou de complétion de résultat. Une route hôte doit résoudre le model requis avant qu'une action exécutable codex_app__create_thread ne soit figée ; une route non résolue émet une action de résolution non exécutable. Sans modèle explicite et télémétrie de raisonnement, enregistrez actual: null et actual_state: unresolved tout en conservant les valeurs indépendantes demandées et résolues. Le reçu persistant expose resource_receipt.requested, resolved, actual et actual_state. Lorsque la preuve réelle est disponible, l'adaptateur compare les valeurs demandées avec l'action de dispatch persistée et exige que actual corresponde à la route résolue rapportée ; un reçu ne doit jamais établir sa propre base de vérification. Une route n'est pas verrouillée à moins que la politique ne le dise ; une route verrouillée doit correspondre à son reçu.

Demandez les permissions juste à temps à la frontière de l'action. La compilation en lecture seule ne demande pas d'identifiants, de publication, de déploiement, de push, de travail destructeur ou de mutation externe en direct. Lorsqu'une telle action est atteinte, retournez un PermissionIntent avec ask, allowed ou denied ; ne préchargez pas un questionnaire et n'effectuez pas l'action en silence.

CLI et récupération

allinluna start --goal "..."
allinluna status RUN_ID
allinluna next-actions RUN_ID
allinluna ingest-receipt RUN_ID RECEIPT.json
allinluna pause RUN_ID
allinluna resume RUN_ID
allinluna retry RUN_ID --task TASK_ID
allinluna cancel RUN_ID --task TASK_ID
allinluna reconcile RUN_ID
allinluna drive RUN_ID
allinluna lane start RUN_ID TASK_ID
allinluna lane status RUN_ID TASK_ID
allinluna lane tick RUN_ID TASK_ID
allinluna lane drive RUN_ID TASK_ID
allinluna lane next-actions RUN_ID TASK_ID
allinluna lane ingest-receipt RUN_ID TASK_ID RECEIPT.json
allinluna lane ingest-direct-result RUN_ID TASK_ID RESULT.json
allinluna lane handoff RUN_ID TASK_ID

La CLI du runtime expose start, status, next-actions, ingest-receipt, pause, resume, retry, cancel, set-policy et reconcile. Utilisez les API de compatibilité publiques pour l'import de plans/exécutions hérités ; elles retournent les actions neutres pour l'adaptateur hôte et ne traitent jamais un identifiant client en attente comme un reçu actif. La récupération conserve les artefacts immuables et recalcule les actions prêtes après que les baux, les reçus ou les instantanés de contexte sont réconciliés.

Le registre/lanceur est uniquement un mécanisme de découverte interne. Les utilisateurs ordinaires entrent par cette compétence contextuelle et leur objectif ou parcours ; les experts peuvent inspecter la matrice de Pack et les contrats de manifeste.