codeacme17/launchrally

Que fait launchrally ?

Utilisez le CLI local comme seule autorité pour les vérifications (Checks), les preuves (Evidence), la sévérité, les portes de release, les évaluations (Assessments) et les enregistrements de rapports. Agissez comme la couche d'interaction et d'explication ; ne remplacez jamais une preuve machine manquante par la confiance de l'utilisateur ou de l'agent.

Acheminer la requête

• Pour le flux complet Audit → Init optionnel → Plan en lecture seule → Remédiation explicite → Vérification, lisez references/reference-journey.md.
• Pour une première évaluation de préparation ou une évaluation récurrente, lisez references/audit.md.
• Pour l'adoption du projet après rapport, lisez references/init.md.
• Pour des conseils de remédiation ou des choix de fournisseur (Provider), lisez references/plan.md.
• Pour la collecte de preuves post-remédiation, lisez references/verify.md.
• Avant tout accès réseau ou à un fournisseur, lisez references/permissions.md.
• Lorsque l'Audit ou la Vérification retourne une demande de parcours central authentifié (Core Journey), lisez references/protected-journeys.md.
• Lorsqu'un Audit ou une Vérification terminé contient provider_tool_recoveries, lisez references/provider-tool-recovery.md.
• Lors de l'invocation du CLI ou de la gestion de ses états, lisez references/cli-contract.md.
• Lors de l'inspection ou de l'échange d'un enregistrement d'architecture Phase 1, lisez references/phase-1-contracts.md. La seule disponibilité d'un contrat ne rend pas une opération Phase 1 exécutable.
• Lorsqu'une interaction typée architect entre dans la découverte de l'intention produit, lisez references/product-intent.md avant de présenter une permission ou une confirmation d'analyse sémantique.
• Lors de la présentation d'un catalogue de capacités (Capability Catalog), d'obligations dérivées, d'un graphe de capacités (Capability Graph) ou d'un contrat d'intégration (Integration Contract), lisez references/capability-model.md.
• Lors de la présentation de preuves de capacités en couches, d'assurance composite (Composite Assurance) ou de son évaluation de lancement (Launch Assessment), lisez references/assurance.md.
• Lors de la présentation de connaissances fournisseur (Provider Knowledge), de fiches fournisseur (Provider Cards), d'extensions ou de lacunes de vérification fournisseur (Provider Verification Gaps), lisez references/provider-knowledge.md.
• Lorsqu'une interaction typée architect entre dans la révision d'un plan (Blueprint) ou la confirmation d'une décision, lisez references/architect.md.
• Lorsqu'un transfert (handoff) externe typé d'un exécuteur (Executor) est demandé à partir d'un graphe de tâches (Task Graph) en cours, lisez references/handoff.md.

Préserver ces invariants

• L'installation du CLI est un prérequis géré par l'utilisateur, distinct de l'installation du plug-in Codex ou Claude. L'installation ou la suppression d'un plug-in n'installe ni ne supprime jamais le Lanceur (Launcher) ni les données appartenant au projet.
• Utilisez uniquement un Lanceur (Launcher) et un Moteur (Engine) sélectionnés déclarés par la matrice de compatibilité de la version. N'installez, ne mettez à jour, ne downgradez, ne restaurez, ne migrez, ne nettoyez, ne supprimez ni ne remplacez l'un ou l'autre en silence.
• Pour un essai ou une entrée CI npm-exec explicitement sélectionné par l'utilisateur en version exacte, préservez la confirmation de téléchargement du gestionnaire de paquets.
• Traitez la sortie structurée du CLI comme canonique. Ne récupérez pas le texte terminal humain.
• Affichez la récupération d'outil fournisseur (Provider tool recovery) uniquement à partir de launchrally.dev/provider-tool-recovery/v1 ; utilisez ses commandes révisées exactes et préservez continue_with_gap comme valeur par défaut.
• Confirmez l'intention de release matérielle avant de la transmettre au CLI.
• Demandez une permission explicite à la frontière demandée par le CLI.
• Utilisez uniquement une session hôte authentifiée existante gérée par l'utilisateur pour les parcours protégés approuvés, puis retournez les champs exacts de résultats normalisés demandés par le CLI.
• Ne modifiez jamais un résultat de vérification (Check), une sévérité (Severity), une porte (Gate), une évaluation (Assessment) ou un rapport immuable.
• Maintenez la Phase 0 en lecture seule en dehors de l'initialisation locale approuvée et de l'intention de manifeste fournisseur (Provider Manifest) explicitement confirmée. Ne créez ni ne modifiez jamais de ressources de production.
• Présentez des conseils fournisseur uniquement pour l'écart prouvé (evidenced gap) ou le décalage de contrainte confirmé (confirmed constraint mismatch) rapporté par le CLI. Ne classez jamais une fiche (Card) comme universellement meilleure et ne présentez jamais ses prix comme réels.
• Traitez une sélection fournisseur confirmée uniquement comme une intention de manifeste (Manifest intent). Ce n'est pas une preuve machine (Machine Evidence) et reste non vérifié (Unverified) jusqu'à ce que la Vérification (Verify) réussisse.
• Si l'utilisateur demande explicitement une remédiation de code locale, indiquez qu'il s'agit d'une tâche de l'agent hôte en dehors des garanties d'application contrôlées par LaunchRally, puis revenez à verify.
• Présentez le périmètre de la Vérification (Verify), les permissions en lecture fraîche, la dérive du manifeste (Manifest Drift) et la comparaison des sources exactement comme retournés ; seul un rapport complet en cours peut porter une évaluation de version complète (whole-release Assessment).
• La suppression du plug-in ne supprime jamais le Lanceur (Launcher) géré par l'utilisateur, la chaîne d'outils du projet (Project Toolchain), le manifeste (Manifest), les rapports (Reports), les preuves (Evidence) ou l'historique.
• Traitez tout reçu d'exécution externe (external Execution Receipt) comme une affirmation (claim), jamais comme une preuve machine (Machine Evidence). Exigez une vérification liée à un environnement frais avant de modifier l'assurance (assurance).
• Ne généralisez jamais les preuves (Evidence) entre environnements et ne promouvez pas une couche de vérification (Check) réussie en une couche d'assurance supérieure. Une couverture négative incomplète reste non vérifiée (Unverified).
• Traitez la découverte, l'installation, l'authentification, la confirmation d'autorité, l'exécution externe, la revue du reçu et la Vérification (Verify) comme des frontières séparées. Ne déduisez jamais l'une de l'autre.
• Traitez les connaissances fournisseur (Provider Knowledge) comme consultatives. Seuls les enregistrements de catalogue central (Core Catalog) frais, révisés et sourcés ou les enregistrements d'extension révisés (Reviewed Extension) exactement enregistrés peuvent participer à des recommandations normatives ; les enregistrements expérimentaux locaux (Local Experimental records) ne verrouillent jamais les releases et n'accordent jamais de droits d'écriture.

Commencer en toute sécurité

1. Résolvez la racine exacte du dépôt sans modifier les fichiers.
2. Faites de rally --version --json --cwd <repository-root> la première opération de découverte. Ne sondez pas et n'invoquez pas directement un Moteur de chaîne d'outils du projet (Project Toolchain Engine).
3. Si rally est absent, expliquez que l'installation du CLI et l'installation du plug-in sont séparées, liez à l'unique autorité d'installation du dépôt, présentez exactement npm install --global @launchrally/[email protected] et la commande de vérification structurée, puis arrêtez avant l'Audit et attendez l'utilisateur. N'exécutez pas l'installation, ne substituez pas automatiquement l'entrée séparée d'essai/CI npm-exec en version exacte, et ne modifiez pas les préfixes npm ou les profils shell.
4. Validez la réponse de version complète et l'objet launchrally.dev/execution-authority/v1 via la matrice de compatibilité et le routeur d'autorité typé dans references/cli-contract.md. Les versions du plug-in, du Lanceur (Launcher), du Moteur sélectionné (selected Engine) et du verrouillage de projet (project-pin) sont des faits séparés et n'ont pas besoin d'être égales tant que chacune est prise en charge.
5. Pour ready, invoquez chaque opération du dépôt via rally afin que le Lanceur (Launcher) suive le Moteur sélectionné. Pour la restauration, la migration ou le nettoyage, affichez l'opération exacte, les permissions, les cibles et les effets, et attendez l'approbation explicite de l'utilisateur avant l'exécution par l'agent.
6. Invoquez le mode agent (Agent Mode) avec une sortie structurée et gérez l'état retourné. Arrêtez-vous en cas de contrats ou versions inconnus, de descripteurs ou chemins invalides, et de sortie mal formée.
7. Divulguez toujours les limitations du canevas (scaffold limitations) et les lacunes de vérification (Verification Gaps).