zheref/en

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, utiliser la racine absolue affiché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 manquante du docs/ consommateur n'est pas une politique manquante et ne doit pas déclencher un double dépôt. Ne jamais copier ou inventer une seconde politique dans le dépôt cible.

En — le cercle maintenu autour d'une PR jusqu'à ce qu'elle soit Prête

Nature : Manipulateur. Tout ce que fait En est orienté vers le tableau de bord — piloter, rapporter, sonner, surveiller. Kurapika le dit quand il l'exécute. Quand un cycle le renvoie dans le changement lui-même — une constatation d'un relecteur qui nécessite du code — le mode pour cette correction est celui du changement lui-même (Améliorateur, Conjureur, Transmuteur), nommé à voix haute pour ce cycle et rendu ensuite.

Rester avec cette PR : la rapporter, observer chaque vérification de tête actuelle et chaque revue, la piloter jusqu'à la vérification Prête, sonner une fois à sa porte humaine — et s'arrêter après au plus N cycles d'action.

En est le dernier composite du plan local et le seul qui puisse avoir besoin de retenir l'attention au-delà du moment où la PR a été ouverte. $mukai se termine en proposant ce transfert — en le commençant lui-même seulement sous nen/workflow.json → mukai.autoEn (règle 2026-09-28) ; à partir de là, la PR appartient à En — et le tour utilisateur toujours actif uniquement sur le chemin autoEn, un départ tapé depuis l'offre étant son propre tour — jusqu'à ce que Sharingan prouve qu'elle est Prête, ou qu'un bloqueur concret/plafond/état terminal/annulation mette fin à l'exécution d'En. La fusion est l'acte ultérieur du mainteneur, sauf pour l'exception de livraison Futon enregistrée au § 5. Cette exécution ne récolte pas et ne nettoie pas. Quand En a terminé, l'appelant propose la clôture via le sélecteur (cleanup § 2, ligne wrap-up ; règle 2026-10-13) — uniquement sous les deux prérequis du § 2 de cleanup (HR-366) ; une PR Prête à l'invite du § 5 ne satisfait ni l'un ni l'autre : $cleanup, obligatoire, avec $third-hand optionnel à côté — compétences séparées, démarrées après que le protocole de ce fichier est revenu, jamais comme une étape d'En.

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à-bas. 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 écrite, car une règle restatée à deux endroits dérive dans l'un d'eux.

Ce qui est vraiment propre à En, c'est le plafond, la forme de la surveillance et la frontière à la fin de la session. Ces trois éléments sont les § 2, § 6 et § 7, et ce sont les seuls endroits où ce fichier affirme quelque chose. Third-Hand n'est pas dans cette frontière.

---

1. Invocation

P1 — cette exécution commence par $ten en (ten § 6 rattrape les prérequis manquants de cette phase sous son propre nom ; les phases que cette exécution appelle sautent les leurs).

$en [on <CODE>#<N>]

Démarré par $mukai sans clause sous mukai.autoEn — la PR est celle que l'étape 8 vient d'ouvrir — par $getsuga § 3 pour la proposition de version qu'il vient d'ouvrir (là, en exécute les étapes 1 à 5 et retourne son verdict cité à getsuga ; la cloche de l'étape 6 n'est pas sonnée, car getsuga § 3a est la fusion de cette PR), par la chaîne par problème de futon pour la PR que son effort a ouverte, ou pour sa PR d'intégration→main (futon § 5 n'ouvre pas de PR dans sa branche d'intégration ; il fusionne là-bas localement), ou par le mainteneur, en nommant une PR qui est déjà ouverte (la ligne d'offre de mukai). La règle selon laquelle chaque PR qu'une session ouvre ou fait ouvrir atteint le mainteneur via cette exécution ou avec le verdict cité est la section Reporting a phase de docs/PROCESS.md (zheref/hatsu#103), citée, non restatée :

nen parse en --grammar "on [<ref>]" --line "<l'invocation, sans le préfixe $en>"

Vérifié en direct à v0.3.0 (docs/ab/en.md § 2.1) : on HA#41 → ref: HA#41 à la sortie 0, et un on nu s'analyse avec la clause absente, également sortie 0. La clause est ancrée derrière un littéral pour la raison que $spiritual-message § 1 enregistre — un emplacement entre crochets seul est refusé au niveau du modèle.

La ligne vide est refusée, et c'est pourquoi un composite ne s'analyse pas du tout. Vérifié en direct : --line "" sort avec 2 et le message "la ligne doit commencer par le littéral 'on' — c'est lui qui introduit <ref>". Une clause optionnelle ancrée nécessite son ancre ; "pas de clause" et "ligne vide" sont des entrées différentes, et seule la première s'analyse. Donc mukai, sous autoEn, remet la PR directement et n'appelle pas du tout nen parse en — faire écho à une analyse d'une ligne que personne n'a tapée serait du théâtre, et lui donner """ produirait un refus qui ne signifie rien. L'analyse s'exécute quand, et seulement quand, le mainteneur a tapé une clause.

Un argument ou un élément de configuration manquant est demandé et configuré en ligne (missing-argument, missing-configuration ; WORKFLOW.md § 4 Demander, configurer, continuer) : une ligne d'un mainteneur qui sort avec 2, ou qui ne nomme aucune PR là où la session n'en a aucune, déclenche l'offre des PR ouvertes de la session dans le sélecteur et la reprise sur la réponse, jamais la fin de l'exécution.

Résoudre le code une fois, au départ, et conserver le slug pour chaque appel ultérieur — ne jamais le redériver d'une seconde manière (claude/agents/kurapika.md § Comment vous travaillez) :

nen repo resolve <CODE> --repo <chemin vers le checkout du dépôt cible>
nen ref format --code <CODE> --kind PR --number <N>

Une PR fermée ou fusionnée met fin à l'exécution immédiatement avec ce qui lui est arrivé. Il n'y a rien à atterrir.

Une PR ouverte dont la tête est déjà publiée reste dans En à chaque continuation. Quand sa branche prend du retard sur la base de la PR, ou qu'une correction de revue nécessite une publication, exécutez les étapes de preuve de l'arborescence actuelle d'En et le push de fast-forward surveillé de $murasaki (§ 3 et murasaki § 6). N'envoyez pas la branche publiée via le squash de $aka. La première publication suit l'autorisation déjà portée par son workflow d'invocation, que ce soit un appel direct d'Aka ou un composite comme Futon. En s'arrête toujours à la porte de fusion humaine séparée du § 5. Par exemple, la PR #274 était déjà publiée à b5fddea lorsque #273 a avancé main ; sa fusion de rattrapage a préservé cette ascendance publiée et Murasaki a poussé le descendant vérifié 5de39c5.

Les phases que ce composite appelle IGNORENT leurs propres sections ## 0. Standalone entry. 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 redériver produirait une seconde réponse à une question que ce composite a déjà réglée. Chaque phase dit quel composite la maintient à sa place.

2. Le plafond — une grammaire, pas une valeur par défaut

En agit. Les étapes 2 et 4 pilotent ; un cycle qui trouve une nouvelle constatation de revue retourne dans le changement et pousse une correction. Cela fait d'En la moitié mutante de la paire de boucles, et la discipline entière de $izanagi s'applique : une boucle qui écrit a besoin d'une borne qu'une boucle qui lit n'a pas, et faire de la borne une partie de la grammaire signifie qu'elle ne peut jamais être par défaut, héritée ou oubliée.

Clé	Fichier	Utilisé pour	Valeur par défaut quand la clé (ou le fichier) est absent
monitor.maxCycles	nen/workflow.json	le plafond — le nombre de cycles d'action (§ 6)	20
monitor.pollSeconds	nen/workflow.json	l'intervalle entre les observations, comme --interval-ms	300 (→ --interval-ms 300000)
branch.base	nen/workflow.json	la base sur laquelle le § 5 invite. L'étape 3 rattrape depuis, et "en retard" est mesuré par rapport à, baseRefName propre de la PR (gh pr view <N> --json baseRefName), qui est branch.base pour chaque PR sur laquelle En invite	main
reports.dir / .sections / .retain	nen/workflow.json	le fichier de l'étape 7 — les clés de backlog-board § 3	Reports / obligatoire, pas de défaut (WORKFLOW § 2 → reports) / final-only
notifications.rungs / .sound	nen/workflow.json	les échelons de l'étape 6 — les clés de $jutaisho	["push","os","sound"] / Glass

Avant le cycle 1, le plafond est épelé via le verbe qui refuse un plafond manquant :

nen parse izanagi "take <CODE>-PR-#<N> to its human gate until it is Ready up to <monitor.maxCycles>"

Vérifié en direct à v0.3.0 (docs/ab/en.md § 2.2), dans les deux sens :

$ nen parse izanagi "take HA-PR-#41 to its human gate until it is Ready up to 20"
task: take HA-PR-#41 to its human gate
until: it is Ready
cap: 20
exit=0

$ nen parse izanagi "take HA-PR-#41 to its human gate until it is Ready"
en: no 'up to <N>'. Izanagi is the MUTATING half of the loop pair and the cap is required grammar,
never defaulted or inferred -- an invocation without it is refused rather than run once 'to see'.
  try: take HA-PR-#41 to its human gate until it is Ready up to <N>
exit=2

La valeur vient de monitor.maxCycles ; l'exigence vient de la grammaire. Ce sont deux choses différentes et la distinction est le point : le fichier fournit un nombre, et le verbe refuse de s'exécuter sans un. Un dépôt dont le bloc monitor est manquant obtient 20, énoncé à voix haute — il n'obtient pas une surveillance illimitée, car "le fichier n'a rien dit" est exactement le cas où une valeur par défaut héritée et oubliée est dangereuse.

RETIRED à nen 0.7 : compter les cycles d'action à la main

Chaque cycle d'action est REVENDIQUÉ avant d'agir, et le plafond est appliqué par le refus de la revendication — retrait de izanagi § 3, hérité dans son intégralité :

git rev-parse --path-format=absolute --git-common-dir   # <common>, dans l'arbre de travail de l'effort
nen loop iterate --id en-<CODE>-<N> \
  --line "take <CODE>-PR-#<N> to its human gate until it is Ready up to <monitor.maxCycles>" \
  --repo <common>

La sortie 0 affiche iteration <n>/<cap> et combien il en reste — le mot du verbe lui-même est itération, et le cycle d'En est ce qu'il revendique ; la sortie 1 EST le plafond et termine l'exécution à la ligne de sortie par plafond du § 6, avec l'invocation nommée dans le propre refus de nen. La --line est la même chaîne que nen parse izanagi a renvoyée ci-dessus, réaffirmée à chaque revendication, donc monitor.maxCycles ne peut pas être augmenté silencieusement en cours d'exécution : une revendication portant un N différent est une sortie 2 nommant les deux lignes (vérifié en direct avec exactement cette forme — up to 3 en cours d'exécution, up to 20 revendiqué — docs/ab/izanagi.md § Retired at nen 0.7).

Le --id est la PULL REQUEST, pas la session, et c'est une décision avec une conséquence qui mérite d'être énoncée : le registre est .nen/loop/en-<CODE>-<N>.json sous le répertoire commun git, donc il survit à la session (§ 7) et à l'arborescence de travail de l'effort, que cleanup supprime (docs/ab/en.md § Le plafond survit à l'arborescence de travail), donc un $en réinvoqué sur la même PR reprend le même plafond plutôt que de recommencer au cycle 1. C'est la lecture honnête de "vingt cycles d'action pour préparer cette PR" — un plafond qu'une réinitialisation de frontière de session serait un plafond que personne n'a. Quand la campagne de préparation se termine vraiment — Prête, fermée ou remise au mainteneur à une porte — fermez le registre avec nen loop iterate --id en-<CODE>-<N> --line "<même ligne>" --release "<pourquoi>" --repo <common> ; une boucle à son plafond peut toujours être libérée, et un nouveau plafond après cela est un nouveau --id, choisi délibérément et dit à voix haute, jamais une ligne retapée.

Le plafond est un plafond, pas une cible. L'atteindre est un échec à atteindre Prêt et est rapporté comme tel : ce qui n'est toujours pas vrai, et ce que le cycle suivant aurait fait. Règle de izanagi § 4, inchangée. La politique des tours de relecteur est celle de $sharingan § 6, énoncée là une fois et citée ici, jamais restatée :

• Un tour Copilot est demandé après que $hanten s'est calmé, jamais avant.
• Les arrivées sont corrigées, et un tour dû est redemandé sans demander seulement à l'intérieur des deux bornes de sharingan § 6 (round_policy.maxRounds demandes, round_policy.minRounds résolues ; ligne cap-reached), puis En continue de surveiller ; l'une ou l'autre borne atteinte est le cinquième arrêt du § 6.
• Avant toute redemande, nen wake verify --repo-slug <owner/name> --now <ISO> --author-pattern <le login du mainteneur> --run relance une exécution avalée une fois (action_required ou startup_failure qui ne s'est jamais exécutée) ; une exécution action_required par le bot Copilot ne peut pas être réessayée et est rapportée comme telle. Ensuite la garde de synchronisation sans opération : compter les commits en avance sur la dernière tête révisée (git rev-list --count <tête-révisée>..HEAD, lecture seule) et le diff stat ; aucun changement révisable signifie aucune demande.
• Copilot révise automatiquement chaque push, donc le plafond régit les demandes, pas les arrivées ; une arrivée au-delà du plafond est toujours corrigée et ses fils de discussion réglés.

Au-delà du maximum, l'exécution se termine non-prête avec le tableau. Aucun des deux n'est un G5. nen/workflow.json → monitor.maxCycles est le plafond de cycle d'action d'En, un nombre différent.

3. L'exécution, dans l'ordre

#	Étape	La compétence qui la possède	Quand
1	rapport d'atterrissage	$spiritual-message as landing	une fois, au début — 00–07 plus 08 corps de PR et 09 Préparation. Si cet En a été démarré par mukai (autoEn) ou tapé à partir de son offre dans la même séance sans demande humaine plus récente, 00 répond toujours à cette demande de mukai
2	pilotage	$sharingan	première condition bloquante