Emplacement de la politique partagée : docs/DISCOVERY.md, docs/WORKFLOW.md,
docs/LAUNCH-MIGRATION.md, docs/STANDALONE-ENTRY.md, docs/PROCESS.md, docs/using/README.md et docs/using/mirrors.md appartiennent à la racine du plugin Hatsu résolue,
pas au dépôt consommateur. Sur une surface installée, utilisez la racine absolue imprimée par ten pour lire
ces fichiers (re-résoudre via cette compétence si indisponible). Les liens relatifs ci-dessous identifient les emplacements
source ; une copie docs/ manquante chez le consommateur n'est pas une politique manquante et ne doit pas déclencher un
dépôt en double. Ne copiez jamais et n'inventez jamais une seconde politique dans le dépôt cible.
Ren — une requête, un tour, à chaque fois
Pas de mode fixe. Ren est une exécution composée : le mode est celui de la requête —
Enhancer pour le code produit, Conjurer pour le canon, Transmuter pour la machinerie — maintenu pour le
tour et nommé dans la réponse, avec Manipulator nommé à ses côtés pendant que les étapes de rapport du tour
s'exécutent. Nommez le mode en jeu, dites quand il change et pourquoi, et ne mélangez jamais deux modes sous un seul en-tête
(claude/agents/kurapika.md).
Prenez la requête. Échauffez-vous si c'est la première, écrivez-la, prouvez-la et validez-la, gérez le lancement, montrez-moi le rapport, sonnez une fois. Puis attendez.
Ren est la forme du travail ordinaire dans le plan local. Ce n'est pas un exécuteur par lots ni un observateur : une invocation est une requête, et une requête est un tour. La boucle est que la prochaine requête commence le tour suivant, avec l'étape d'échauffement déjà effectuée.
Ce fichier compose. Il ne re-spécifie pas. Chaque étape ci-dessous est celle d'une autre compétence, nommée et liée, et sa procédure, ses réactions aux codes de sortie, ses refus et ses résidus vivent là. Si vous trouvez une règle ici qui est vraiment celle de cette compétence, elle est dans le mauvais fichier — allez la lire là où elle est authentifiée, car une règle répétée à deux endroits dérive dans l'un d'eux.
1. Invocation
P1 — cette exécution commence par $ten ren (ten § 6 rattrape les
prérequis manquants de cette phase sous son propre nom ; les phases que cette exécution appelle sautent les leurs).
$ren <requête> [--profile fast|standard|thorough]
nen parse ren --grammar "<requête> [--profile <profile:fast|standard|thorough>]" \
--line "<la requête, sans le préfixe $ren>"
profile: (clause absente) signifie profile.default (§ 2a) ; les mots "fast turn" ou "thorough turn"
à l'intérieur de la requête sont lus comme la même surcharge.
Vérifié en direct à v0.3.0 (docs/ab/ren.md § 2.1) : une ligne de requête est analysée en
request: <la ligne entière> avec code de sortie 0, et une ligne vide refuse avec le code de sortie 2 — "<requête> est
requise et la ligne ne la fournit pas" — avec la ligne corrigée imprimée. Un tour sans requête n'est jamais déduit de ce que la session faisait en dernier — il est demandé sous forme de texte libre
: la requête est la parole du mainteneur (ligne missing-maintainer-choice, enregistrée via nen stop answer,
docs/WORKFLOW.md § 4 La parole du mainteneur n'est jamais dérivée), donc toutes les
lectures que la session suggère sont listées pour référence, aucune n'est marquée d'une étoile et aucune n'est une option de sélecteur, et le
tour s'exécute sur ce que le mainteneur tape.
Ren est aussi la forme par défaut, pas seulement un appel explicite. Dans un dépôt dont
nen/workflow.json décrit cette boucle, une requête ordinaire du mainteneur est un tour ren ;
dites-le dès la première, pour que personne ne soit surpris par le rapport et la sonnerie à la fin.
2. Le tour, dans l'ordre
| # | Étape | La compétence qui la possède | Pourquoi elle est ici |
|---|---|---|---|
| 1 | échauffement | $breath | lier/re-vérifier l'isolation à chaque entrée selon WORKFLOW § Où vivent les worktrees avant le rattrapage ou la mutation de Ten ; échauffer et prouver une branche fraîche une fois par nouvel effort dans ce checkout — le propre worktree de harnais de la session en cas de refus de crochet observé (HR-374). Les continuations explicites réutilisent uniquement le worktree appartenant à l'effort vérifié. Une base rouge est un G5 avant la rédaction ; de même pour une clause conflictuelle dans sa vérification de constitution (breath § 4a), enregistrée dans l'entrée du registre de cette étape |
| 2 | rédiger la modification | $rasengan | écrire ce que le mainteneur a demandé, sur la pile que ce dépôt déclare : les modifications, les tests à côté, la documentation et le journal des modifications que ses conventions doivent — avec les iteration.checks déclarés exécutés comme le propre retour d'information de l'auteur pendant que le travail est devant lui |
| 3 | vérifier et valider | $kokusen | chaque verbe iteration.checks peu coûteux et les tests ciblés déclarés sur l'arbre terminé, le rouge est refusé ; puis triage, une question sur ce qui est signalé, une validation structurée — seulement en local |
| 4 | lancement | $amaterasu | un effort isolé signale la commande dry-run et enregistre core launch deferred; explicit maintainer call required, puis continue sans demander, même en série. Pas de cible → no launch target declared; skipped. Un lancement central ne déplace jamais la rédaction ou la livraison hors de son worktree lié |
| 5 | rapport | $spiritual-message as turn | la page : accompli, défis, non livré, architecture, captures d'écran, la commande de lancement exacte, décisions |
| 6 | sonnerie | $jutaisho (§ 1 décide si la demande de la page en fait un arrêt) | les échelons que le workflow déclare — et un arrêt seulement si un est vraiment dû |
L'étape 2 est le changement lui-même, et elle a cessé d'être demi-numérotée le 2026-09-10. Ce tableau utilisait auparavant une étape
1.5— "le travail", possédée par aucune compétence — à côté d'une étape 2 appelée build, qui lisaitrasengancomme exécuter la commande de construction plutôt que construire la chose. La décision du mainteneur (docs/ROSTER.mdHR-55) le règle :rasenganEST la phase de rédaction, donc le travail a une compétence, les six nombres entiers sont à nouveau six compétences, et le compile-avant-validation siège avec la phase qui prépare l'arbre.
L'ordre est structurel à cinq endroits, et ces cinq sont les seuls que ren affirme :
- 1 avant 2 — pas de rédaction sur une base non vérifiée. Breath coupe la branche depuis
origin/<branch.base>fraîchement récupérée et prouve les vérifications déclarées dessus, donc la première ligne de la modification atterrit sur un arbre déjà connu pour compiler et le premier rouge que quiconque voit est un que cet effort a causé. Un sommet de base rouge est un arrêt G5 là, avant qu'une ligne ne soit écrite ; il n'est jamais réparé à l'intérieur de cet effort. Il en va de même pour la vérification de constitution de breath § 4a, dont le verrou breath § 6 énonce (WORKFLOW.md§ La vérification de constitution). - 2 avant 3 — rien n'est validé qui n'a pas été rédigé dans ce tour et vérifié dans celui-ci. Rasengan écrit la modification et maintient sa propre boucle interne honnête ; kokusen exécute ensuite les vérifications déclarées sur l'arbre terminé et refuse de valider en cas de rouge. Les deux exécutions ne sont pas une duplication : l'arbre bouge avec chaque ligne écrite après la dernière vérification de l'auteur, donc la seule exécution sur laquelle une validation peut reposer est celle effectuée par la phase détenant l'index. Là où un tour itère (écrire, vérifier, écrire à nouveau), c'est l'étape 2 qui itère avec elle-même, et l'étape 3 est entrée une fois.
- 3 avant 4. La gestion du lancement suit le résultat validé ; l'isolation n'autorise pas un lancement central. Une commande différée n'est pas une démonstration de l'arbre de cet effort.
- 4 avant 5. Le rapport distingue une commande dry-run différée de argv réellement exécuté.
- 5 avant 6. La sonnerie porte le lien du rapport. Une sonnerie qui sonne avant que la page n'existe envoie le mainteneur vers rien.
Les phases que ce composite appelle SAUTENT leurs propres sections ## 0. Entrée autonome. docs/STANDALONE-ENTRY.md est le
contrat pour une phase tapée à la main dans un checkout arbitraire ; une phase atteinte depuis ici hérite de P1–P4
de cette exécution — l'échauffement, l'orientation, l'ensemble des modifications et chaque argument dérivé — et
les re-dériver produirait une seconde réponse à une question que ce composite a déjà résolue. Chaque phase
indique quel composite la contient à la place.
À l'intérieur de l'étape 1, une fois par effort classifié, $direct s'exécute — pour un effort qui
nomme un problème (<CODE>#<N> dans la requête) ou une classification de texte déjà étiquetée — avec les
--surface, --model et --effort de cette session (unread là où le harnais en cache un), exactement comme build § 2b le fait ; son
§ 6 possède la comparaison et la seule question, et le $ren tapé est déjà la décision de travailler ici, donc il
ne bloque jamais. Sa réponse B termine ce tour, pas la boucle : les étapes 5 et 6 s'exécutent toujours et le rapport nomme
la ligne de redémarrage. Un effort sans étiquette job/ est undirectable, une ligne, et le tour continue. Ce n'est pas une septième étape et n'affirme aucun ordre propre : il lit à l'intérieur de l'échauffement, demande au plus une fois, ne rédige rien — et son § 7 étape de publication ne s'exécute pas ici : Ren ne peut pas quitter la machine (§ 3), donc le verdict reste dans le rapport et le registre local, et direct.publish n'agit que sous build, file (une fois déposé) ou autonome.
L'échauffement s'exécute une fois par effort ; la sélection du checkout est vérifiée à CHAQUE entrée. Les tours ultérieurs et les
phases PR revérifient le chemin d'effort absolu lié sous $hatsu_root/docs/WORKFLOW.md § Où vivent les worktrees
avant l'étape 2 ou tout rattrapage. Signalez le chemin, le statut de dérogation de l'invite originale et
si Breath a échauffé ou seulement revérifié. La continuation ne contourne jamais l'isolation.
Une nouvelle requête est un nouvel effort, sauf si l'appelant continue explicitement l'actuel. Se trouver
sur une branche de fonctionnalité propre d'un effort précédent n'est pas une continuation
(zheref/hatsu#60; $breath
§ 2a). Breath s'exécute toujours, récupère toujours la base configurée, et coupe toujours une branche nouvellement rendue.
La réutilisation est uniquement pour un "continuer" / "même effort" / "sur cette branche" explicite, ou pour
le tour 2+ d'une boucle dont l'étape 1 a déjà coupé cette branche dans cette session.
Lorsqu'un tour ultérieur de cet effort, ou $mukai, rentre dans
$hanten, il réutilise le même registre de cycle —
.nen/hanten/<slug-branche>.cycle.json. La correction ne réinitialise pas les comptes de relecteurs. Breath coupant
une nouvelle branche est le seul nouveau cycle
(zheref/hatsu#63; hanten § 2a).
2a. Profils, et le registre de phase
profile.default dans nen/workflow.json façonne le tour (standard en son absence) ; le
--profile du § 1 le surcharge, une valeur en dehors de profile.allowed est redemandée avec la liste autorisée
comme options du sélecteur, et la première ligne du tour nomme le profil en jeu.
| Profil | Ce qui change dans § 2 |
|---|---|
fast | l'étape 1 vérifie la liaison ; l'échauffement s'exécute toujours une fois ; étapes 2 et 3 comme déclaré ; étape 4 ignorée, ligne de lancement deferred by profile fast; isolation still requires an explicit maintainer core-launch call ; étape 5 rend --variant turn-fast |
standard | le tour d'aujourd'hui, comme le tableau ci-dessus l'énonce |
thorough | standard, et après l'étape 3 kotoamatsukami's les suites impactées s'exécutent, sur chaque tour |
Un profil décide quelles étapes s'exécutent et quelle variante l'étape 5 rend, jamais ce qui se passe à l'intérieur d'une
étape. Les étapes 2 et 3 s'exécutent comme leurs compétences le disent sous chaque profil. Sous fast les suites impactées ne sont pas
exécutées (elles sont celles de mukai, étape 4 là-bas) ; sous thorough les suites impactées de kotoamatsukami
s'exécutent après l'étape 3, ren étant le troisième appelant de cette compétence. Le lancement est ignoré, pas déplacé :
mukai n'a pas d'étape de lancement, et amaterasu § 1a dit comment un lancement ignoré est
pris. La couverture n'est capturée par aucun profil ren ; c'est celle de byakugan, chez mukai.
Un atterrissage (mukai) s'exécute toujours en thorough, quel que soit le nom des tours avant lui.
Chaque étape est une entrée de registre (WORKFLOW.md § Les registres de l'effort possède le
mécanisme ; ce qui est à ren est quelles étapes et quand). Avant une étape, nen phase begin --effort <branche> --phase <nom-étape> --surface <s> [--model <modèle-rapporté>] --dial <niveau> ; si le modèle est un ID de service rapporté par le harnais, ajoutez --note "model-kind=served; registry alias <alias>" (WORKFLOW § Les registres de l'effort) ; à la première phase enregistrez
nen session record avec le titre/id du harnais lorsqu'il est exposé, une fois par session ; après une étape, nen phase end --effort <branche> --phase <nom-étape> --exit <code>, donc .nen/phases/<effort>.json porte une entrée chronométrée par phase, incluant une étape refusée.
Le end de l'étape 1 porte l'enregistrement de breath § 4a comme son --note, composé avec la
note avec laquelle l'étape 1 a commencé, car end --note la remplace (le --begin-note du script ; WORKFLOW
§ La vérification de constitution, étapes 3, 5 et 6, possède les formulaires). La vérification n'est pas une entrée propre,
donc les six étapes restent six entrées (HR-58). L'entrée d'utilisation est enregistrée à l'étape 5 : nen usage record --effort <branche> --surface <s> [--model] --dial <niveau> [--input] [--output] [--cache-read] [--cache-write] [--minutes] depuis
le propre relevé de coûts de la surface, --not-reported sur une surface qui n'en expose aucun.
Un effort repris lit avant d'écrire (zheref/hatsu#444, zheref/hatsu#445 ; nen 0.28, l'épingle). Un effort dont
la branche a déjà un registre de phase, ou une PR, est une reprise : d'abord, là où une PR existe — l'ouverte : un numéro de successeur, jamais la PR qu'une suppression de base a fermée (en § 6) — nen pr ledger read --target <propriétaire/nom> --pr <n> --effort <branche> --repo <checkout> --json, ajoutant --restore uniquement là où
nen phase show ne trouve aucun registre local ; puis nen phase show --effort <branche> --json. WORKFLOW § Les
registres de l'effort, La tranche durable, possède les verdicts et la seule forme de ligne ignorée ; une entrée
breath ignorée sa note est lue avant l'étape 2 (WORKFLOW § La vérification de constitution, étape 7). Par phase, dans l'ordre :
terminée avec code de sortie 0 → **