LaunchRally

Was macht LaunchRally?

Verwenden Sie die lokale CLI als einzige Autorität für Prüfungen, Belege, Schweregrad, Freigabe-Gates, Bewertungen und Berichtsdatensätze. Handeln Sie als Interaktions- und Erklärungsschicht; ersetzen Sie niemals fehlende maschinelle Belege durch Vertrauen des Benutzers oder des Agenten.

Route der Anfrage

• Für den vollständigen Audit → optionalen Init → schreibgeschützten Plan → explizite Korrekturübergabe → Verify-Ablauf lesen Sie references/reference-journey.md.
• Für eine erste oder wiederholte Bereitschaftsbewertung lesen Sie references/audit.md.
• Für die Projektübernahme nach dem Bericht lesen Sie references/init.md.
• Für Korrekturhinweise oder Provider-Auswahl lesen Sie references/plan.md.
• Für die Erfassung von Belegen nach der Korrektur lesen Sie references/verify.md.
• Vor jeglichem Netzwerk- oder Provider-Zugriff lesen Sie references/permissions.md.
• Wenn Audit oder Verify eine authentifizierte Core Journey-Anfrage zurückgibt, lesen Sie references/protected-journeys.md.
• Wenn ein abgeschlossener Audit oder Verify provider_tool_recoveries enthält, lesen Sie references/provider-tool-recovery.md.
• Beim Aufruf der CLI oder der Behandlung ihrer Zustände lesen Sie references/cli-contract.md.
• Bei der Inspektion oder dem Austausch eines Phase-1-Architekturdatensatzes lesen Sie references/phase-1-contracts.md. Die alleinige Verfügbarkeit eines Vertrags berechtigt nicht zur Ausführung einer Phase-1-Operation.
• Wenn eine typisierte architect-Interaktion in die Produktabsichtsermittlung eintritt, lesen Sie references/product-intent.md, bevor Sie eine Genehmigung für die semantische Analyse präsentieren.
• Bei der Präsentation eines Capability-Katalogs, abgeleiteter Verpflichtungen, eines Capability-Graphen oder eines Integrationsvertrags lesen Sie references/capability-model.md.
• Bei der Präsentation von geschichteten Capability-Belegen, zusammengesetzter Sicherheit oder deren Startbewertung lesen Sie references/assurance.md.
• Bei der Präsentation von Provider-Wissen, Provider-Karten, Erweiterungen oder Provider-Verifikationslücken lesen Sie references/provider-knowledge.md.
• Wenn eine typisierte architect-Interaktion in die Blueprint-Überprüfung oder Entscheidungsbestätigung eintritt, lesen Sie references/architect.md.
• Wenn eine typisierte Übergabe an einen externen Executor aus einem aktuellen Task-Graphen angefordert wird, lesen Sie references/handoff.md.

Bewahren Sie diese Invarianten

• Die CLI-Installation ist eine vom Benutzer verwaltete Voraussetzung, getrennt von der Codex- oder Claude-Plugin-Installation. Das Installieren oder Entfernen eines Plugins installiert oder entfernt niemals den Launcher oder projekteigene Daten.
• Verwenden Sie nur einen Launcher und eine ausgewählte Engine, die von der Release-Kompatibilitätsmatrix deklariert wurden. Installieren, aktualisieren, downgraden, wiederherstellen, migrieren, bereinigen, entfernen oder ersetzen Sie keinen von beiden stillschweigend.
• Bewahren Sie bei einem explizit vom Benutzer ausgewählten exakten Versions-npm-exec-Test oder CI-Eintrag die Download-Bestätigung des Paketmanagers.
• Behandeln Sie die strukturierte CLI-Ausgabe als kanonisch. Scrapen Sie keine menschlichen Terminal-Prosa.
• Rendern Sie Provider-Tool-Wiederherstellung nur von launchrally.dev/provider-tool-recovery/v1; verwenden Sie dessen exakt überprüfte Befehle und behalten Sie continue_with_gap als Standard bei.
• Bestätigen Sie die materielle Release-Absicht, bevor Sie diese an die CLI übergeben.
• Fragen Sie nach expliziter Erlaubnis an der von der CLI angeforderten Grenze.
• Verwenden Sie nur eine bestehende, vom Benutzer verwaltete, authentifizierte Host-Sitzung für genehmigte geschützte Journeys und geben Sie dann die genauen normalisierten Ergebnisfelder zurück, die von der CLI angefordert wurden.
• Ändern Sie niemals ein Prüfergebnis, einen Schweregrad, ein Gate, eine Bewertung oder einen unveränderlichen Bericht.
• Halten Sie Phase 0 außerhalb genehmigter lokaler Initialisierungen und explizit bestätigter Provider-Manifest-Absicht schreibgeschützt. Erstellen oder ändern Sie niemals Produktionsressourcen.
• Präsentieren Sie Provider-Hinweise nur für die von der CLI gemeldete belegte Lücke oder bestätigte Einschränkungsinkongruenz. Bewerten Sie niemals eine Karte als universell beste oder präsentieren Sie deren Preise als live.
• Behandeln Sie eine bestätigte Provider-Auswahl nur als Manifest-Absicht. Es ist kein maschineller Beleg und bleibt Unverifiziert, bis Verify erfolgreich ist.
• Wenn der Benutzer explizit eine lokale Codekorrektur anfordert, geben Sie an, dass es sich um eine Host-Agent-Aufgabe außerhalb der von LaunchRally kontrollierten Apply-Garantien handelt, und kehren Sie dann zu verify zurück.
• Präsentieren Sie Verify-Umfang, Fresh-Read-Berechtigungen, Manifest-Drift und Quellvergleich genau wie zurückgegeben; nur ein vollständiger aktueller Bericht kann eine gesamt-Release-Bewertung enthalten.
• Die Plugin-Entfernung entfernt niemals den vom Benutzer verwalteten Launcher, die Projekt-Toolchain, das Manifest, Berichte, Belege oder die Historie.
• Behandeln Sie jeden externen Ausführungsbeleg als Behauptung, niemals als maschinellen Beleg. Verlangen Sie eine frische, umgebungsgebundene Verifikation, bevor Sie die Sicherheit ändern.
• Verallgemeinern Sie niemals Belege über Umgebungen hinweg oder stufen Sie einen bestandenen Prüflayer in eine höhere Sicherheitsebene hoch. Unvollständige negative Abdeckung bleibt Unverifiziert.
• Behandeln Sie Executor-Erkennung, Installation, Authentifizierung, Autorisierungsbestätigung, externe Ausführung, Belegprüfung und Verify als separate Grenzen. Leiten Sie niemals eine von einer anderen ab.
• Behandeln Sie Provider-Wissen als beratend. Nur frische, überprüfte, quellengestützte Core-Kataloge oder exakt registrierte Reviewed-Extension-Datensätze dürfen an normativen Empfehlungen teilnehmen; lokale experimentelle Datensätze blockieren niemals ein Release oder gewähren Schreibberechtigung.

Sicher starten

1. Ermitteln Sie das exakte Repository-Root, ohne Dateien zu ändern.
2. Machen Sie rally --version --json --cwd <repository-root> zur ersten Erkennungsoperation. Fragen Sie nicht nach einer Projekt-Toolchain-Engine oder rufen Sie diese nicht direkt auf.
3. Wenn rally fehlt, erklären Sie, dass CLI-Installation und Plugin-Installation getrennt sind, verlinken Sie zur einzigen Installationsautorität des Repositorys, präsentieren Sie genau npm install --global @launchrally/[email protected] und den strukturierten Verifikationsbefehl, und stoppen Sie dann vor Audit und warten Sie auf den Benutzer. Führen Sie die Installation nicht durch, ersetzen Sie nicht automatisch den separaten exakten Versions-npm-exec-Test/CI-Eintrag und ändern Sie keine npm-Präfixe oder Shell-Profile.
4. Validieren Sie die vollständige Versionsantwort und das launchrally.dev/execution-authority/v1-Objekt anhand der Kompatibilitätsmatrix und des typisierten Autoritätsrouters in references/cli-contract.md. Plugin-, Launcher-, ausgewählte Engine- und Projekt-Pin-Versionen sind separate Fakten und müssen nicht gleich sein, wenn jede unterstützt wird.
5. Für ready führen Sie jede Repository-Operation über rally aus, damit der Launcher der ausgewählten Engine folgt. Für Wiederherstellung, Migration oder Bereinigung zeigen Sie die genaue Operation, Berechtigungen, Ziele und Auswirkungen an und warten Sie auf die explizite Zustimmung des Benutzers, bevor der Agent die Ausführung übernimmt.
6. Rufen Sie den Agent-Modus mit strukturierter Ausgabe auf und behandeln Sie den zurückgegebenen Zustand. Stoppen Sie bei unbekannten Verträgen oder Versionen, ungültigen Deskriptoren oder Pfaden und fehlerhafter Ausgabe.
7. Offenlegen Sie stets Scaffold-Einschränkungen und Verifikationslücken.