Que fait loft ?
Ne coupe pas l'acier tant que la forme n'est pas juste. Les constructeurs navals tracent les lignes de la coque à taille réelle et les ajustent avant la moindre découpe. Loft applique le même principe aux questions de conception : quand les mots ont atteint leur limite — deux réponses plausibles, aucune falsifiable par la discussion — construis un artefact exécutable bon marché, laisse le capitaine y réagir, et intègre cette réaction dans la décision.
Le contrat de rôles. L'équipe construit l'artefact ; le capitaine a pour seule tâche de réagir — et cette réaction est la décision. L'artefact est un instrument pour voir, jamais une longueur d'avance sur le livrable.
Quand lofter
- une question de conception s'enlise dans la prose : reformulée à plusieurs reprises, toujours pas tranchable (« à quoi devrait ressembler la page de chemin ? », « ce modèle d'état semble-t-il juste ? »)
- une carte de navigateur porte un ticket
loft - une discussion de spécifications atteint « il faudrait le voir d'abord »
Ne pas lofter quand :
- la question peut être répondue par des preuves dans le dépôt ou en demandant au capitaine (c'est interviewer, pas lofter)
- la destination elle-même n'est pas claire (c'est du brouillard —
/oh-my-claudecode:ask-navigator) - la réponse existe déjà dans une ADR (ne pas lofter des décisions déjà tranchées)
- la « question de conception » est en fait un bug (c'est la juridiction du débogueur)
Choisir la branche
Choisis selon ce que demande la question. Une mauvaise branche gaspille tout l'artefact.
Branche logique — le modèle est-il juste ?
Pour les questions d'état, de règles métier, de forme des données ou d'algorithmes (« le déverrouillage régresse-t-il lors d'une reprise ? », « ce reducer tient-il aux limites ? ») :
- Isole le cœur décisionnel — la machine d'état, le reducer, le schéma ou l'algorithme — comme un module pur : pas de DOM, pas d'E/S, pas de framework. Écrit de sorte qu'une fois la forme confirmée, il passe dans le vrai codebase inchangé.
- Enveloppe-le dans une coque HTML cliquable : un bouton par scénario, les cas limites délicats parcourus dans l'ordre, l'état complet visible après chaque clic.
- Une fois la confirmation que le module est prêt à être extrait — il rentre dans le vrai travail via un lancement. Pendant le loft,
mainreste intact et la coque reste sur la branche.
Branche UI — à quoi cela doit-il ressembler ?
Pour les questions de forme et d'agencement (« étapes ou cartes ? », « où vit la progression ? ») :
- Une route, trois variantes structurellement différentes — architecture de l'information, modèle de navigation, densité. Des variantes qui ne diffèrent que par le style ne répondent à rien : trois resurfaçages ne sont que du papier peint.
- Un sélecteur sur la page permet de passer d'une variante à l'autre ; intègre-les dans le produit existant si possible, pour que la densité réelle des données éprouve le design au lieu de trois lignes factices bien rangées.
- Une fois la confirmation, la décision est transférée et les variantes restent sur la branche comme enregistrement de la raison pour laquelle cela ressemble à cela.
La discipline
- Une seule commande à lancer — la commande de serve la plus simple existant dans le dépôt ; intègre le module dans la coque si les CORS du module
file://poseraient problème. Se charge en secondes ; aucune étape de build au-delà de ce que le dépôt propose déjà. - Pas de persistance, pas de tests, pas d'abstractions, pas de gestion d'erreurs au-delà du chemin heureux. L'artefact doit être quelque chose que tu ne voudrais pas livrer — les règles existent pour qu'il en reste ainsi.
- Attends-toi à ce que la première forme soit contestée : révise sur la branche dans la même session. La confirmation par le capitaine de la forme finale est la décision ; un artefact que personne ne conteste répond généralement à une question que personne ne se posait.
- La durée de vie totale de l'artefact est de quelques minutes pour le construire et une session pour décider. S'il commence à se transformer en code de production, arrête : ce travail est un effort de lancement, pas un loft. Le coût irrécupérable est le mode d'échec que cette compétence vise à prévenir.
- Un loft répond à une question. Deux questions équivalent à deux lofts — ou à une question qui en cachait en fait deux.
Intégrer la réponse
L'artefact est une preuve, pas un point d'arrivée. Quand le capitaine réagit :
- Enregistre la décision là où elle vit — dans le commentaire du ticket, la section Décisions d'Implémentation des spécifications, ou la note de décision en attente — dans les propres mots du capitaine, plus une ligne de justification. Un fragment plus précis que la prose (le reducer, la machine d'état, le schéma) peut y être intégré, marqué comme lofté.
- Pousse l'artefact sur une branche
loft/<nom>. Elle ne fusionne jamais : elle reste comme source première qu'un futur lecteur pourra ouvrir quand le « pourquoi » de la décision comptera. - Rien de l'artefact n'atterrit dans
main— pour la branche logique, le module confirmé rentre dans le vrai travail via lancement ; pour la branche UI, la vraie page est construite à partir de la décision.
Périmètre et non-objectifs
- Loft produit des réponses, pas des livrables : pas d'exécution continue, pas de fichiers d'état, rien de toujours actif.
- Il ne diagnostique pas (débogueur), ne cartographie pas le brouillard (
/oh-my-claudecode:ask-navigator), n'approuve pas sa propre réponse (la réaction du capitaine est la seule validation). - Il ne remplace pas l'approbation des seams : une UI loftée montre la forme ; les seams de test associés sont toujours approuvés en C2.
Définition de l'achèvement
Le capitaine a réagi, la réponse se trouve là où vit la décision, l'artefact est sur sa branche — et aucune ligne de l'artefact n'est dans main.