zenx0x/allinluna

All in Luna

All in Luna ist ein zentraler Einstiegspunkt. Akzeptiere eine dieser Eingaben:

• eine Idee oder ein ein-Satz-Ziel;
• einen bestehenden Plan;
• einen aktiven Run oder einen Legacy-Run-Snapshot;
• ein Research Routes Paket. Kompiliere die Eingabe zu einem getypten RunIntent, wähle ein registriertes Workflow Pack aus und kompiliere dessen TaskGraph mit Verträgen, Abhängigkeiten, Besitzverhältnissen, Done-Wann-Bedingungen, WorkGraph-Vorlagen und Ressourcendefaults. Rufe dann die vNext Runtime/CLI auf, um den Graphen zu persistieren, bereite Lanes freizugeben, echte Host-Belege zu verarbeiten und fortzufahren, bis das Root-Ergebnis vollständig ist oder ein konkreter Blocker zurückgegeben wird.

Höchstpriorisierter exakter Action Relay

Logische LocalDispatchIntent-Werte sind keine Host-Aktionen. Ein HostAdapter löst sie zunächst in einen lane-direct-work/v1-Plan oder einen exakten HostAction.tool-Opcode auf:

1. Rufe dieses exakte Tool mit HostAction.arguments auf.
2. Übersetze, approximiere oder ersetze niemals eine andere Fähigkeit.
3. Ein top_level_task darf niemals auf einen Subagenten, den aktuellen Thread oder direkte Ausführung zurückfallen.
4. Verarbeite den rohen Beleg sofort und ticke dann erneut.
5. Wenn kein HostAdapter gebunden ist, gib ACTION_RELAY_REQUIRED zurück und behalte die exakte Aktion bei.
6. Gib HOST_CAPABILITY_BLOCKED nur zurück, nachdem die Fähigkeitserkennung bestätigt hat, dass das exakte Tool nicht vorhanden ist.

Für lokale Arbeit verwendet native_preferred einen beworbenen nativen Worker oder einen echten Lane-direkten Plan; native_required blockiert, wenn nicht vorhanden, und direct_only erzeugt nie einen Unterprozess. Ein direkter Beleg ist nicht abgeschlossen: Die Lane muss die WorkUnit ausführen und einen verifizierten work-handoff/v1 erzeugen.

Belege stellen explizit action_contract_hash, actual_tool und actual_capability bereit. Ein falsches tatsächliches Tool ist HOST_PROTOCOL_VIOLATION, kein Beweis dafür, dass eine Aufgabe gestartet wurde.

Lane-Bootstrap und persistente Treiber

Jeder öffentliche codex_app__create_thread-Dispatch bettet ein vollständiges lane-bootstrap/v1-Objekt sowohl in seinem dauerhaften Aktionsnutzdaten als auch im Child- Prompt ein. Es enthält die Run/Task/Attempt-Identitäten, den TaskEnvelope-Digest, den Runtime SQLite-Pfad, Contract-/Context-/WorkGraph-Referenzen, das Arbeitsverzeichnis, erlaubte lokale Fähigkeiten, verbotene globale Fähigkeiten und die erforderliche lane-handoff/v1-Antwort. Eine Child Lane muss denselben Store wieder öffnen und diese Objekte selbst laden; ihr Prompt ist niemals nur ein natürlichsprachliches Ergebnis. CoordinatorDriver ist die dauerhafte äußere Schleife: Plane exakte Aktionen, verarbeite Belege, warte/lese Threads der obersten Ebene, verarbeite getypte Lane-Übergaben, gleiche ab und gib sofort neu bereite Aufgaben frei. LaneDriver führt die passende lokale WorkGraph-Schleife aus, einschließlich Snapshots, dynamischer lokaler Erweiterung, Worker- Übergaben, Korrekturen innerhalb des gleichen Workers und Synthese von Lane-Übergaben. Eine Welle ist nur eine UI-Gruppierung: Abhängigkeitsbereite Arbeit wird sofort freigegeben.

Runtime-Form

Konversation
  -> Globaler Coordinator
       -> unabhängige Task Lane(s)
            -> begrenzte rekursive WorkUnits
                 -> Tools / Skills / Plugins / MCP

Behalte rohe Tool-Ausgaben im Artifact Store. Gib getypte Verträge, Artefakt- Referenzen, Kontextausschnitte, Belege und Übergaben nach oben weiter. Eine Child WorkUnit muss ihren Elternbereich, ihre Autorität, ihren Besitz und ihren Ressourcenrahmen eingrenzen; eine Lane-übergreifende Anfrage wird zu einer Promotionsanfrage.

Eingabe- und Pack-Routing

Verwende SinglePublicSkillAPI.compile() oder allinluna start:

• einfaches Ziel -> standardmäßig delivery;
• bestehender Plan -> schreibgeschützter Legacy-Import, dann delivery;
• aktiver Run -> schreibgeschützter Run-Status-Import und wiederherstellungsorientierte Kompilierung;
• Research Routes Paket -> research-routes-bridge, unter Beibehaltung von Claims, Evidence, Unbekannten, Widersprüchen, Fehlerregimen, HumanDecision und Experimentautorisierungsgrenzen.

Verwende gsd, wenn der Benutzer explizit dessen Workflow anfordert. Das ausführbare Pack stellt Klären, Spezifizieren, Zerlegen, Implementieren, Verifizieren und Integrieren bereit, dynamische lane-lokale Erweiterung, begrenzte WorkUnits, Vertragsübergaben und lokale Fehlerbehebung. Füge der Core keine GSD-Phasen hinzu.

Ressourcen und Berechtigungen

Ressourcenauswahl folgt dieser Priorität: explizite Benutzeranfrage, dann eine Task/WorkUnit-Überschreibung, Benutzerpräferenz, Pack-Fähigkeit, Deployment/Host- Fähigkeit und schließlich der aktuelle Session/Host-Standard. Core ist anbieterneutral und kodiert keinen Anbieter oder konkreten Modell-Route hart. Bewahre angeforderte, aufgelöste und tatsächliche Werte separat auf. Wenn der Host keinen tatsächlichen Modellbeleg liefern kann, protokolliere actual: null und actual_state: unresolved; gib niemals einen Fallback vor oder erfinde einen Beleg. Ein engerer Gültigkeitsbereich kann Rechenressourcen ändern, aber nicht Berechtigungen oder Besitz erweitern. Host-Ressourcen-Route-Telemetrie ist optionale Adapterdiagnostik, keine Ausführungs- oder Ergebnisabschlussanforderung. Eine Host-Route muss das erforderliche model auflösen, bevor eine ausführbare codex_app__create_thread-Aktion eingefroren wird; eine ungelöste Route gibt eine nicht ausführbare Auflösungsaktion aus. Ohne explizite Modell- und Reasoning-Telemetrie protokolliere actual: null und actual_state: unresolved, während du die unabhängigen angeforderten und aufgelösten Werte beibehältst. Der persistierte Beleg legt resource_receipt.requested, resolved, actual und actual_state offen. Wenn tatsächliche Evidenz verfügbar ist, vergleicht der Adapter angeforderte Werte mit der persistierten Dispatch-Aktion und verlangt, dass actual mit der gemeldeten aufgelösten Route übereinstimmt; ein Beleg darf niemals eine eigene Verifikationsbasis errichten. Eine Route ist nicht festgesperrt, es sei denn, die Richtlinie sagt dies; eine gesperrte Route muss mit ihrem Beleg übereinstimmen.

Fordere Berechtigungen genau rechtzeitig an der Aktionsgrenze an. Schreibgeschützte Kompilierung fordert keine Anmeldeinformationen, Veröffentlichung, Bereitstellung, Push, destruktive Arbeit oder lebende externe Mutation an. Wenn eine solche Aktion erreicht wird, gib einen PermissionIntent mit ask, allowed oder denied zurück; führe keinen Fragebogen im Voraus aus und führe die Aktion nicht stillschweigend aus.

CLI und Wiederherstellung

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

Die Runtime-CLI stellt start, status, next-actions, ingest-receipt, pause, resume, retry, cancel, set-policy und reconcile bereit. Verwende die öffentlichen Kompatibilitäts-APIs für Legacy-Plan/-Run-Import; sie geben host-neutrale Aktionen für den Host-Adapter zurück und behandeln niemals eine ausstehende Client-ID als aktiven Beleg. Die Wiederherstellung bewahrt unveränderliche Artefakte und berechnet bereite Aktionen neu, nachdem Leases, Belege oder Kontext-Snapshots abgeglichen wurden.

Das Registry/Launcher ist nur ein interner Erkennbarkeitsmechanismus. Gewöhnliche Benutzer treten über diese kontextuelle Skill und ihr Ziel oder ihren Journey ein; Experten können die Pack-Matrix und Manifest-Verträge überprüfen.