Lancement

Que fait Lancement ?

Lancement est la course de livraison du chantier naval : du briefing de mission à la modification vérifiée et livrée. Elle repose sur la frontière de vérifiabilité — les agents exécutent en continu tout ce qui est répétable et acceptable par des preuves ; les humains décident de ce qui ne peut pas être jugé par le système ou qui échoue de manière coûteuse. L'objectif n'est pas l'automatisation maximale — c'est la délégation maximale du travail vérifiable, de sorte que le temps de l'humain soit consacré uniquement aux décisions que seul un humain peut prendre.

Le test de vérifiabilité, appliqué à chaque étape : si cela est fait incorrectement, le système peut-il le détecter ? Peut-il refaire ou annuler automatiquement ? Les deux oui → agent. Pas de réponse unique, le système ne peut pas juger, ou coûteux à se tromper → humain.

Lancement suppose que le chantier naval existe — et refuse de s'exécuter s'il n'existe pas. La porte du chantier est la première action de chaque invocation, avant la résolution de la langue du document et avant la lecture de toute spécification fournie :

• Exécuter l'audit complet --check de la cale sèche — surfaces manquantes, documentLanguage manquant ou invalide dans le frontmatter de CONTEXT.md, chemins morts, termes du glossaire inutilisés dans le code, normes jamais référencées. C'est le seul critère : Lancement n'effectue aucun inventaire d'installation séparé de son propre chef.
• Les constatations actionnables / à haute confiance bloquent l'exécution : lister chaque constatation textuellement, pointer vers /oh-my-claudecode:drydock, indiquer que l'exécution n'a jamais commencé et qu'aucun artefact n'a été produit, et s'arrêter. Sans remplacement explicite, traiter toute constatation comme bloquante.
• Remplacement étroit (intention explicite uniquement) : les constatations à faible confiance, les constatations explicitement classées comme faux positifs dans le rapport de cale sèche, ou un dépôt brouillon/jetable déclaré explicitement par l'utilisateur peuvent être remplacées uniquement avec une intention délibérée et par invocation — le remplacement doit nommer la ou les constatations ou la portée jetable et ne doit jamais avaler silencieusement une constatation actionnable à haute confiance. Aucun indicateur de contournement général.
• Limitation actuelle de l'audit : aujourd'hui, --check est une liste de contrôle d'instructions de compétence sans contrat de constatation/gravité lisible par machine ni exécutable — la classification de gravité repose sur la formulation du rapport de cale sèche jusqu'à ce qu'un contrat structuré existe. Un contrat de sortie de constatation/gravité lisible par machine est la prochaine étape prévue ; le libellé de la porte reste honnête sur ce qu'il peut et ne peut pas prendre en charge mécaniquement.
• Un audit propre (ou une portée remplacée explicitement à faible confiance/faux positif/jetable) admet l'exécution. Chaque emplacement de piste papier (CONTEXT.md, docs/adr/, docs/business/) et surface d'installation existe déjà à ce stade ; Lancement remplit la piste papier au fur et à mesure que les décisions se stabilisent mais ne crée jamais les emplacements.
• La règle d'entrée est CLAUDE.md — la carte du chantier naval ne reconnaît aucun substitut.

La frontière

Points de contrôle humains (les 20 % critiques)	Exécution continue de l'agent (les 80 % mécaniques)
C1 rédiger le briefing de mission (objectif + périmètre)	recherche de faits et exploration du dépôt, en libre-service
C2 approuver les critères d'acceptation + la liste des jointures de test	préparation de l'entretien : questions frontières regroupées avec réponses recommandées
C3 approuver la décomposition en tickets (granularité, arêtes de blocage)	rédaction des spécifications et des tickets, validation mécanique (indépendance, démontrabilité, tient dans un contexte)
C4 répondre aux décisions irréversibles qui émergent en cours d'exécution (groupées, asynchrones)	implémentation tdd aux jointures convenues, builds, tests, régressions
C5 accepter le rapport d'achèvement ; véto via les hypothèses ouvertes et la liste de sédiments par ligne	révision de code, vérification à travers le changement, planification de la frontière de l'équipe, toute la piste papier

Entre les points de contrôle, le pipeline ne reste jamais inactif : les agents continuent de travailler sur chaque ticket de frontière qui ne dépend pas d'une réponse humaine en attente.

Posture de cycle de vie

Lancement est une composition sans état sur le cycle de vie existant d'OMC — il ne possède aucune machine d'état d'exécution :

• L'équipe possède les statuts des tâches, les transitions, l'annulation et le nettoyage d'exécution ; Lancement ne les mute jamais en dehors du contrat de l'équipe.
• Les surfaces canoniques plan → execute → review → verify possèdent leur comportement de cycle de vie existant. Les artefacts créés par Lancement sont limités à .omc/specs/<feature-slug>/, CONTEXT.md, docs/adr/ et docs/business/ — plus, uniquement après l'approbation C5, les emplacements de sédiments nommés dans le tableau de la Phase 5.
• Lancement n'a pas de reprise automatique. Après une interruption, relire les artefacts et l'état actuel de l'équipe, mais continuer uniquement via une nouvelle invocation explicite de Lancement après que le cycle de vie de l'équipe propriétaire a atteint une limite de terminaison/nettoyage prise en charge. Ne jamais inférer une approbation humaine ou rejouer une tâche in_progress.
• Les efforts flous relèvent de la compétence du navigateur : lorsque la porte de brouillard redirige vers /oh-my-claudecode:ask-navigator, l'exécution n'a jamais commencé — aucun artefact, aucun état partiel. La carte du navigateur est le seul support à travers les sessions ; Lancement ne reprend qu'à partir du briefing de mission qu'il rend.
• Lancement n'ajoute aucun accusé de réception d'approbation, compteur de révision, journal de rejeu, chemin d'annulation, mécanisme de retour en arrière ou cycle de vie de nettoyage qui lui est propre.

Toute affirmation de durabilité dans cette compétence est une affirmation concernant les fichiers sur le disque, pas concernant une exécution cachée.

Phase 0 — Entrée

Une exécution n'atteint cette phase qu'à travers une porte de chantier propre. Avant de lire une spécification fournie ou d'entrer dans la Phase 1, résoudre la langue du document. Un choix humain explicite dans l'invocation actuelle l'emporte ; sinon lire une étiquette BCP-47 valide depuis le frontmatter de CONTEXT.md à la clé stable exacte documentLanguage ; sinon exiger une inférence unanime à haute confiance depuis CLAUDE.md puis README.md. Une étiquette chinoise persistée nue ou avec une région uniquement est ambiguë en termes de script et doit être demandée une fois à ce niveau d'autorité, jamais contournée par l'inférence. Une preuve chinoise manquante, mixte, conflictuelle, à faible confiance, explicitement invalide ou ambiguë en termes de script nécessite une question de langue regroupée ; ne pas deviner. Le chinois doit se résoudre en une étiquette de script explicite zh-Hans ou zh-Hant. zh-Hans-* sélectionne le compagnon simplifié et zh-Hant-* sélectionne le compagnon traditionnel tandis que l'étiquette normalisée complète est persistée. Persister l'étiquette normalisée résolue dans CONTEXT.md avant tout artefact créé par Lancement afin qu'une invocation explicite fraîche puisse la lire sans état de conversation caché. L'humain lit et maintient ces artefacts ; les agents sont indépendants de la langue.

Localiser uniquement la prose et les étiquettes/ valeurs scalaires localisables destinées à l'humain. Les chemins, commandes slash, drapeaux, blocs de code, espaces réservés, clés de frontmatter et valeurs sémantiques machine, clés YAML/JSON, jetons de cycle de vie (plan, execute, review, verify), énumérations de statut (pending, in_progress, completed, failed, ready-for-agent), IDs, blockedBy de ticket, blocked_by public de l'équipe, et tous les jetons d'analyseur / de contrôle restent stables octet par octet. Les compagnons de langue de référence sont mutuellement exclusifs : émettre exactement un rendu sélectionné, jamais d'en-têtes ou d'étiquettes bilingues en double.

• Auto-vérification rapide avant toute autre chose : le briefing nomme-t-il un objectif, une limite de périmètre et des non-objectifs ? Si deux ou plus sont manquants, le dire et demander un passage de précision — exécuter le pipeline sur un briefing flou convertit l'ambiguïté en sortie qui semble confiante.
• Porte de brouillard : après le passage de précision, appliquer le test de brouillard du navigateur — Q1 : la destination peut-elle être énoncée en une phrase (la spécification, la décision ou le changement vers lequel cet effort se dirige) ? Q2 : les trois premières décisions peuvent-elles être énoncées précisément dès maintenant, même si aucune ne peut encore être répondue ? L'une ou l'autre réponse non → l'exécution ne commence jamais : l'indiquer clairement, noter qu'aucun artefact n'a été produit, recommander /oh-my-claudecode:ask-navigator (le navigateur du chantier naval cartographie le brouillard comme une carte de tickets de décision et rend un briefing de mission), et s'arrêter. Transmettre les questions résiduelles et tout vocabulaire déjà établi, afin que le W1 du navigateur ne les repose pas.
• Vérification de la carte : avant de lire une spécification fournie ou d'entrer dans la Phase 1, rechercher une navigator:map ouverte (étiquette de suivi, ou sous .omc/wayfinder/). S'il en existe une et que cette invocation ne fournit pas de nouveau briefing → recommander /oh-my-claudecode:ask-navigator pour travailler la prochaine décision sur cette carte, et s'arrêter. S'il en existe une et qu'un nouveau briefing est fourni → poser une question — continuer la carte ouverte, ou commencer un nouvel effort — avant de procéder.
• Chemin de spécification fourni → la lire, passer à la Phase 2.
• Briefing de mission → Phase 1.
• Correction ponctuelle → confier à l'exécution, sortir.

Phase 1 — Converger (l'humain décide, l'agent prépare)

Exécuter l'entretien avec le protocole d'arbre de conception : cartographier les décisions et leurs dépendances, puis travailler en tours de frontière — regrouper chaque question actuellement posable en un tour, numéroté, chacun avec une réponse recommandée. L'humain répond ; l'arbre se restructure ; recalculer la frontière. Les faits sont toujours auto-servis par des sous-agents à partir de preuves du dépôt — l'humain n'est interrogé que sur ce qu'aucune exploration ne peut trancher.

Piste papier, écrite au moment où chaque élément se stabilise :

• vocabulaire du domaine → CONTEXT.md à la racine du dépôt (une entrée par terme)
• décisions passant le test ADR (difficiles à inverser, surprenantes sans contexte, vrai compromis) → docs/adr/NNNN-<slug>.md
• règles métier et contexte découverts lors de la convergence → docs/business/ (un article par question métier, le paragraphe d'ouverture indique pourquoi c'est important)

La non-convergence ici est un travail normal, pas un échec : si la frontière ne se vide pas, présenter les questions résiduelles classées — c'est l'entrée de C2, pas une erreur. Si les questions résiduelles elles-mêmes ne peuvent pas être énoncées précisément (le test Q2 du brouillard échoue), la destination elle-même n'est pas établie et cela dépasse l'autorité de C2 : s'arrêter, noter ce qui a déjà été établi (vocabulaire dans CONTEXT.md, questions répondues), recommander /oh-my-claudecode:ask-navigator, et sortir — le pipeline n'invente jamais de destination.

Détour par le loft. Une question résiduelle qui est précise mais ne peut pas être tranchée en prose — elle a besoin d'être vue ou cliquée, pas décrite (à quoi l'interface utilisateur devrait ressembler, si un modèle d'état semble correct) — est répondue avec un artefact, pas plus de questions : appeler l'outil Skill avec "loft", laisser le capitaine réagir, et réintégrer cette réaction dans l'entretien. L'artefact du loft est l'entrée de C2 ; le capitaine signe ce qu'il a vu, pas ce qu'on lui a dit.

Briefings du port. Un briefing de mission remis par /oh-my-claudecode:harbor contient des décisions signées avec des liens et conditions applicables : les consommer comme déjà prises — ne pas reposer les objectifs métier inchangés. Si le code a bougé depuis que les preuves ont été recueillies (nouvel en-tête, base modifiée), revérifier les preuves techniques affectées ; un nouveau périmètre d'implémentation au-delà du briefing signé obtient toujours sa propre approbation.

Phase 2 — Synthèse de spécification (l'agent rédige → C2 approuve)

Synthétiser .omc/specs/<feature-slug>/spec.md :

# Spécification de <Fonctionnalité>
## Problème
## Solution
## Histoires utilisateur        (numérotées, chacune avec des critères d'acceptation testables)
## Décisions d'implémentation
## Décisions de test   (comportement externe uniquement)
## Hors périmètre

Tout rédiger, puis s'arrêter à C2 : présenter les critères d'acceptation et la liste des jointures de test pour approbation humaine. Les jointures sont sélectionnées par les preuves du dépôt et la discipline du module profond (interfaces publiques, jointures de test existantes, analyse de profondeur) ; l'humain confirme ou corrige la liste — une jointure que l'humain n'a pas approuvée ne reçoit aucun test.

Porte de durabilité (appliquée par l'agent, aucune approbation nécessaire) : les spécifications et les tickets portent des contrats, jamais des coordonnées — pas de chemins de fichiers, pas de numéros de ligne. Les fragments encodant une décision mieux que la prose (machines d'état, réducteurs, schémas) sont l'exception et indiquent leur origine (généralement un loft).

Phase 3 — Décomposition en tickets (l'agent rédige → C3 approuve)

Diviser en tranches verticales sous .omc/specs/<feature-slug>/tickets/ :

• NN-slug.md, un fichier par ticket, classé par dépendance, chacun déclarant blockedBy: [ids]
• chaque ticket traverse chaque couche, est démontrable indépendamment et tient dans un contexte frais
• les refontes larges vont en extension-contraction : ajouter la nouvelle forme, migrer par lots, supprimer l'ancienne — chaque lot un ticket

La validation mécanique côté agent s'exécute en premier (indépendance, démontrabilité, adéquation au contexte). Puis C3 : présenter la granularité, les arêtes de blocage et les fusions/séparations proposées pour approbation humaine. Itérer jusqu'à approbation. Marquer chaque ticket ready-for-agent.

Règle d'intégration-câblage : chaque tranche verticale inclut son propre câblage et une assertion de fumée — une tranche dont la sortie n'est rien montée, servie ou importée n'est pas terminée. Les jointures inter-tranches qu'aucune tranche unique ne possède (montage de route, service statique, câblage de point d'entrée) obtiennent un ticket d'intégration explicite comme dernier élément de frontière.

Phase 4 — Exécuter la frontière

La frontière est l'ensemble des tickets dont tous les bloqueurs sont terminés.

Parallèle (par défaut, 2+ tickets). Confier les tickets à l'équipe : chaque ticket devient une tâche d'équipe, les arêtes blockedBy sont reportées — les mécanismes de revendication de l'équipe ne sélectionnent que les tickets de frontière. Lancer N travailleurs. Chaque travailleur implémente avec la discipline tdd aux jointures approuvées en C2, en appliquant /oh-my-claudecode:minimal-code-discipline comme discipline de rédaction (elle reste opt-in) ; un ticket se ferme uniquement après que la révision de code passe sur le diff, déclaré par le réviseur — l'implémenteur ne s'approuve jamais lui-même.

Série (ticket unique, ou --serial). Déléguer un ticket à la fois à un sous-agent exécuteur ; même porte de révision.

Porte de révision à deux axes. La révision de clôture s'effectue le long de deux axes, en parallèle, rapportée séparément — jamais fusionnée ou classée de manière croisée, car un changement peut passer un axe et échouer l'autre (conforme aux normes mais comportement incorrect ; fidèle mais enfreignant les conventions). Le réviseur échoue le ticket lorsqu'un axe échoue :

• Axe des normes — le diff par rapport au volume docs/standards/ correspondant, plus une référence de base de l'odeur uniquement basée sur le jugement (une norme de dépôt documentée remplace la référence de base ; tout ce que les outils imposent déjà est ignoré). C'est le consommateur permanent qui maintient les surfaces de normes référencées.
• Axe de la spécification — le diff par rapport aux critères d'acceptation de ce ticket (la spécification est le livre de comptes total à partir duquel les tickets ont été décomposés ; elle n'est consultée que pour retracer d'où vient un critère et pour statuer sur le périmètre passé en contrebande — comportement qu'aucun ticket