zheref/en

Ubicación de la política compartida: docs/DISCOVERY.md, docs/WORKFLOW.md, docs/LAUNCH-MIGRATION.md, docs/STANDALONE-ENTRY.md, docs/PROCESS.md, docs/using/README.md y docs/using/mirrors.md pertenecen a la raíz resuelta del plugin Hatsu, no al repositorio consumidor. En una superficie instalada, use la raíz absoluta impresa por ten para leer esos archivos (resuelva de nuevo a través de esa habilidad si no está disponible). Los enlaces relativos a continuación identifican ubicaciones de origen; una copia faltante de docs/ en el consumidor no es una política faltante y no debe desencadenar un archivo duplicado. Nunca copie o invente una segunda política en el repositorio de destino.

En — el círculo mantenido alrededor de una PR hasta que esté lista

Naturaleza: Manipulador. Todo lo que hace en es de cara al tablero — impulsar, informar, notificar, observar. Kurapika lo dice cuando lo ejecuta. Cuando un ciclo lo envía de vuelta al cambio en sí — un hallazgo de un revisor que necesita código — el modo para esa corrección es el propio del cambio (Mejorador, Conjurador, Transformador), nombrado en voz alta para ese ciclo y devuelto después.

Permanece con esta PR: repórtala, observa cada verificación de cabeza actual y revisión, llévala a 'Ready' verificado, notifica una vez en su puerta humana — y detente después de un máximo de N ciclos de acción.

En es el último compuesto del plano local y el único que puede necesitar mantener la atención más allá del momento en que se abrió la PR. $mukai termina ofreciendo esta transferencia — iniciándola solo bajo nen/workflow.json → mukai.autoEn (decisión 2026-09-28); a partir de ahí la PR pertenece a En — y el turno del usuario aún activo solo en la ruta autoEn, un inicio tipeado desde la oferta siendo su propio turno — hasta que Sharingan demuestre que está lista, o un bloqueador/límite/estado terminal/cancelación concreto termine la ejecución de En. La fusión es un acto posterior del mantenedor, excepto para la excepción de entrega Futon registrada en § 5. Esta ejecución no cosecha y no limpia. Cuando En haya completado, quien invocó ofrece el cierre a través del selector (cleanup § 2, fila wrap-up; decisión 2026-10-13) — solo bajo los dos prerrequisitos de cleanup § 2 (HR-366); una PR lista en el aviso de § 5 no cumple ninguno: $cleanup, obligatorio, con $third-hand opcional a su lado — habilidades separadas, iniciadas después de que el protocolo de este archivo haya regresado, nunca como un paso de En.

Este archivo compone. No re-especifica. Cada paso a continuación es de otra habilidad, nombrada y enlazada, y su procedimiento, sus reacciones a códigos de salida, sus rechazos y sus residuos viven allí. Si encuentra una regla aquí que es realmente de esa habilidad, está en el archivo equivocado — vaya a leerla donde está autoria, porque una regla reafirmada en dos lugares se desvía en uno de ellos.

Lo que es genuinamente propio de en es el límite, la forma de la vigilancia y el límite al final de la sesión. Esos tres son § 2, § 6 y § 7, y son los únicos lugares donde este archivo afirma algo. Third-Hand no está en ese límite.

---

1. Invocación

P1 — esta ejecución comienza con $ten en (ten § 6 se pone al día de esta fase los prerrequisitos faltantes bajo su propio nombre; las fases que esta ejecución llama se saltan las suyas).

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

Iniciado por $mukai sin cláusula bajo mukai.autoEn — la PR es la que el paso 8 acaba de abrir — por $getsuga § 3 para la propuesta de lanzamiento que acaba de abrir (allí en ejecuta los pasos 1–5 y devuelve su veredicto citado a getsuga; el timbre del paso 6 no suena, porque getsuga § 3a es la fusión de esa PR), por la cadena por-incidencia de futon para la PR que su esfuerzo abrió, o para su PR de integración→main (futon § 5 no abre ninguna PR en su rama de integración; fusiona allí localmente), o por el mantenedor, nombrando una PR que ya está abierta (la línea de oferta de mukai). La regla de que cada PR que una sesión abre o causa que se abra llega al mantenedor a través de esta ejecución o con el veredicto citado está en docs/PROCESS.md § Reporting a phase's (zheref/hatsu#103), citado, no reafirmado:

nen parse en --grammar "on [<ref>]" --line "<la invocación, sin el prefijo $en>"

Verificado en vivo en v0.3.0 (docs/ab/en.md § 2.1): on HA#41 → ref: HA#41 con salida 0, y un on desnudo se analiza con la cláusula ausente, también salida 0. La cláusula está anclada detrás de un literal por la razón que $spiritual-message § 1 registra — una ranura entre corchetes solitaria se rechaza en la plantilla.

La línea vacía se rechaza, y por eso un compuesto no se analiza en absoluto. Verificado en vivo: --line "" sale 2 con "la línea debe comenzar con el literal 'on' — es lo que introduce <ref>". Una cláusula opcional anclada requiere su ancla; "sin cláusula" y "línea vacía" son entradas diferentes, y solo la primera se analiza. Así que mukai, bajo autoEn, entrega la PR directamente y no llama a nen parse en en absoluto — hacer eco de un análisis de una línea que nadie escribió sería teatro, y alimentarlo con "" produciría un rechazo que no significa nada. El análisis se ejecuta cuando, y solo cuando, el mantenedor escribió una cláusula.

Un argumento o elemento de configuración faltante se solicita y configura en línea (missing-argument, missing-configuration; WORKFLOW.md § 4 Ask, set up, continue): una línea del mantenedor que sale 2, o no nombra ninguna PR donde la sesión no tenga ninguna, es el desencadenante para o frecer las PRs abiertas de la sesión en el selector y reanudar con la respuesta, nunca el final de la ejecución.

Resuelva el código una vez, por adelantado, y mantenga el slug para cada llamada posterior — nunca lo vuelva a derivar de una segunda manera (claude/agents/kurapika.md § How you work):

nen repo resolve <CODE> --repo <ruta al checkout del repositorio de destino>
nen ref format --code <CODE> --kind PR --number <N>

Una PR cerrada o fusionada termina la ejecución inmediatamente con lo que le sucedió. No hay nada que aterrizar.

Una PR abierta cuya cabeza ya está publicada permanece en En en cada continuación. Cuando su rama se queda atrás de la base de la PR, o una corrección de revisión necesita publicación, ejecute los pasos de evidencia del árbol actual de En y la inserción de avance rápido protegida de $murasaki (§ 3 y murasaki § 6). No envíe la rama publicada a través del squash de $aka. La primera publicación sigue la autorización ya transportada por su flujo de trabajo invocador, ya sea una llamada directa a Aka o un compuesto tal como Futon. En aún se detiene en la puerta de fusión humana separada de § 5. Por ejemplo, la PR #274 ya estaba publicada en b5fddea cuando #273 avanzó main; su fusión de puesta al día preservó esa ascendencia publicada y Murasaki empujó el descendiente verificado 5de39c5.

Las fases que este compuesto llama se saltan sus propias secciones ## 0. Standalone entry. docs/STANDALONE-ENTRY.md es el contrato para una fase escrita a mano en un checkout arbitrario; una fase alcanzada desde aquí hereda P1–P4 de esta ejecución — el calentamiento, la orientación, el conjunto de cambios y cada argumento derivado — y volver a derivarlos produciría una segunda respuesta a una pregunta que este compuesto ya resolvió. Cada fase dice qué compuesto la está manteniendo en su lugar.

2. El límite — gramática, no un valor predeterminado

En actúa. Los pasos 2 y 4 impulsan; un ciclo que encuentra un nuevo hallazgo de revisión regresa al cambio y empuja una corrección. Eso convierte a en en la mitad mutante del par de bucle, y toda la disciplina de $izanagi se aplica: un bucle que escribe necesita un límite; un bucle que lee no lo necesita, y hacer que el límite sea parte de la gramática significa que nunca puede tener un valor predeterminado, heredarse u olvidarse.

Clave	Archivo	Usado para	Predeterminado cuando la clave (o el archivo) está ausente
monitor.maxCycles	nen/workflow.json	el límite — el conteo de ciclos de acción (§ 6)	20
monitor.pollSeconds	nen/workflow.json	el intervalo entre observaciones, como --interval-ms	300 (→ --interval-ms 300000)
branch.base	nen/workflow.json	la base sobre la que § 5 solicita. El paso 3 se pone al día desde, y "atrasado" se mide contra, el propio baseRefName de la PR (gh pr view <N> --json baseRefName), que es branch.base para cada PR sobre la que en solicita	main
reports.dir / .sections / .retain	nen/workflow.json	el archivo del paso 7 — las claves de backlog-board § 3	Reports / obligatorio, sin predeterminado (WORKFLOW § 2 → reports) / final-only
notifications.rungs / .sound	nen/workflow.json	los peldaños del paso 6 — las claves de $jutaisho	["push","os","sound"] / Glass

Antes del ciclo 1, el límite se deletrea a través del verbo que rechaza uno faltante:

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

Verificado en vivo en v0.3.0 (docs/ab/en.md § 2.2), de ambas formas:

$ 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"
nen: 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

El valor proviene de monitor.maxCycles; el requisito proviene de la gramática. Esos son dos cosas diferentes y la distinción es el punto: el archivo proporciona un número, y el verbo se niega a ejecutarse sin uno. Un repositorio cuyo bloque monitor falta obtiene 20, indicado en voz alta — no obtiene una vigilancia ilimitada, porque "el archivo no dijo nada" es exactamente el caso en el que un valor predeterminado heredado y olvidado es peligroso.

RETIRADO en nen 0.7: contar los ciclos de acción manualmente

Cada ciclo de acción se RECLAMA antes de actuar, y el límite se aplica mediante el rechazo del reclamo — la jubilación de izanagi § 3, heredada por completo:

git rev-parse --path-format=absolute --git-common-dir   # <common>, en el árbol de trabajo del esfuerzo
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 salida 0 imprime iteration <n>/<cap> y cuántas quedan — la propia palabra del verbo es iteration, y el ciclo de en es lo que está reclamando; la salida 1 ES el límite y termina la ejecución en la fila de límite alcanzado de § 6, con la invocación nombrada en el propio rechazo de nen. El --line es la misma cadena que nen parse izanagi repitió arriba, reafirmada en cada reclamo, por lo que monitor.maxCycles no puede aumentarse silenciosamente a mitad de ejecución: un reclamo que lleva una N diferente es la salida 2 nombrando ambas líneas (verificado en vivo exactamente contra esta forma — up to 3 ejecutándose, up to 20 reclamado — docs/ab/izanagi.md § Retired at nen 0.7).

El --id es la PULL REQUEST, no la sesión, y esa es una decisión con una consecuencia que vale la pena indicar: el libro mayor es .nen/loop/en-<CODE>-<N>.json bajo el directorio común de git, por lo que sobrevive a la sesión (§ 7) y al árbol de trabajo del esfuerzo, que la limpieza elimina (docs/ab/en.md § The cap outlives the worktree), por lo que un $en reinvocado en la misma PR reanuda el mismo límite en lugar de comenzar de nuevo en el ciclo 1. Esa es la lectura honesta de "veinte ciclos de acción para preparar esta PR" — un límite que un reinicio de límite de sesión sería un límite que nadie tiene. Cuando la impulsión de preparación genuinamente termina — Lista, cerrada, o entregada al mantenedor en una puerta — cierre el libro mayor con nen loop iterate --id en-<CODE>-<N> --line "<misma línea>" --release "<por qué>" --repo <common>; un bucle en su límite puede siempre ser liberado, y un nuevo límite después de eso es un nuevo --id, elegido deliberadamente y dicho en voz alta, nunca una línea reescrita.

El límite es un techo, no un objetivo. Alcanzarlo es un fracaso en alcanzar 'Ready' y se informa como tal: quép aún no es cierto, y qué habría hecho el siguiente ciclo. La regla de izanagi § 4, sin cambios. La política de rondas de revisión es $sharingan § 6, indicada allí una vez y citada aquí, nunca reafirmada:

• Se solicita una ronda de Copilot después de que $hanten se estabilice, nunca antes.
• Las llegadas se remedian, y una ronda debida se vuelve a solicitar sin preguntar solo dentro de los dos límites de sharingan § 6 (round_policy.maxRounds solicitudes, round_policy.minRounds resueltas; fila cap-reached), luego en sigue observando; cualquiera de los límites alcanzados es la quinta parada de § 6.
• Antes de cualquier nueva solicitud, nen wake verify --repo-slug <owner/name> --now <ISO> --author-pattern <el login del mantenedor> --run reactiva una ejecución tragada una vez (action_required o startup_failure que nunca se ejecutó); una ejecución action_required por el bot de Copilot no puede reintentarse y se informa como tal. Luego, el guardia de sincronización sin operación: cuente las confirmaciones por delante de la última cabeza revisada (git rev-list --count <reviewed-head>..HEAD, solo lectura) y el diff stat; cero cambios revisables significa ninguna solicitud.
• Copilot revisa automáticamente cada push, por lo que el límite rige las solicitudes, no las llegadas; una llegada más allá del límite aún se remedia y sus hilos se resuelven.

Más allá del máximo, la ejecución termina como no lista con el tablero. Ninguno es un G5. nen/workflow.json → monitor.maxCycles es el límite de ciclos de acción de en, un número diferente.

3. La ejecución, en orden

#	Paso	La habilidad que lo posee	Cuándo
1	informe de aterrizaje	$spiritual-message as landing	una vez, al inicio — 00–07 más 08 cuerpo de PR y 09 Preparación. Si este En fue iniciado por mukai (autoEn) o escrito desde su oferta en la misma sesión sin una solicitud humana más reciente, 00 aún responde a esa solicitud de mukai
2	impulsar	$sharingan	primera condición de bloqueo que se encuentra. Este paso puede ejecutar su propio bucle (compartido con En): en tal bucle, las solicitudes se rigen por la política de rondas de sharingan, y no hay un límite de ciclo de acción separado; la vigilancia de En cubre la espera. Si sharingan no comienza un bucle, este paso es una única llamada, no un bucle
3	ponerse al día desde la base	$murasaki as catch-up	cuando la rama de la PR está detrás de la base, o después de que una corrección de revisión se publique a través del empuje de murasaki. En conoce la base del control remoto desde § 1; no la averigua de nuevo. Murasaki conoce la rama de la PR desde su propia invocación dentro del paso 3
4	solicitar disponibilidad	la propia PR — gh pr comment <N> --body "@<mantenedor> lista para fusionar" — o, si la política de rondas ha completado su última revisión, el informe de paso 5. El comentario incluye el límite restante y el número de ciclo actual	una vez, cuando sharingan indica que la revisión está completa y no se necesitan más correcciones. Si el mantenedor responde, el paso 4 no se repite; la ejecución continúa al paso 5. Si no hay respuesta después de un tiempo de espera (configurable en nen/workflow.json → monitor.pollSeconds), el paso 4 se repite en el siguiente ciclo
5	informe de preparación	$spiritual-message as readiness	cuando se alcanza la preparación, o cuando el límite de ciclos de acción se alcanza sin preparación. Este informe enumera el estado final de la PR y el motivo de la finalización. Si la ejecución termina debido al límite, el informe incluye qué acción habría tomado el siguiente ciclo. Si la ejecución termina debido a la preparación, el informe incluye una instrucción para que el mantenedor fusione, a menos que se aplique la excepción de Futon (sección 5)
6	notificación	$jutaisho	una vez, después del paso 5. Jutaisho notifica a los canales configurados con el resultado de la ejecución. La notificación incluye la PR, el resultado y el límite restante (si lo hay). Si la ejecución terminó debido a la preparación y se aplica la excepción de Futon, Jutaisho también notifica que la fusión se ha realizado
7	informe de tablero	$backlog-board	una vez, después del paso 6. Backlog-board actualiza el tablero de backlog con el resultado de la ejecución. El tablero muestra el estado de la PR y el motivo de la finalización. El tablero también muestra el límite restante (si lo hay) y el número de ciclo final

La regla de que cada paso se ejecuta exactamente una vez, y en orden, es una regla de este archivo. Si un paso produce un código de salida distinto de cero, la ejecución se detiene y se informa del error. Si un paso produce un código de salida que indica que se debe repetir el paso (por ejemplo, si sharingan indica que se necesita una nueva ronda de revisión), el paso se repite hasta un máximo de monitor.maxCycles veces. Si el paso se repite más allá del límite, la ejecución termina con un error de límite.

4. Límite de ciclos de acción

El límite de ciclos de acción es el número máximo de veces que la ejecución repetirá los pasos 2-5. Cada ciclo de acción comienza en el paso 2 y termina después del paso 5. El límite se configura en nen/workflow.json → monitor.maxCycles. El valor predeterminado es 20. El límite se verifica al comienzo de cada ciclo de acción. Si el límite se alcanza antes de que la PR esté lista, la ejecución termina con un error de límite.

El límite es un techo, no un objetivo. Alcanzarlo es un fracaso en alcanzar 'Ready' y se informa como tal: qué aún no es cierto, y qué habría hecho el siguiente ciclo. La regla de izanagi § 4, sin cambios.

5. Excepción de entrega de Futon

Si la PR fue abierta por Futon como parte de una entrega apilada, y la PR está lista, En puede fusionar la PR sin esperar la acción del mantenedor. Esta excepción solo se aplica si se cumplen todas las condiciones siguientes:

1. La PR fue abierta por Futon como parte de una entrega apilada.
2. La PR está marcada como lista por Sharingan (sin hallazgos de revisión pendientes, todas las comprobaciones de CI pasan).
3. La PR no tiene conflictos con su base.
4. La entrega apilada está registrada en el libro mayor de Futon.
5. La PR es la última (más joven) en la pila.

Si se cumplen todas las condiciones, En fusiona la PR usando el comando gh pr merge <N> --merge --delete-branch. La fusión se informa en el paso 5 y se notifica en el paso 6. Si no se cumplen todas las condiciones, En entrega la PR al mantenedor para su fusión.

6. Límite de la sesión

La ejecución de En termina después de que se completa el paso 7. La sesión no mantiene ningún estado después de que la ejecución finaliza. El libro mayor del límite de ciclos de acción se almacena bajo el directorio común de git (.nen/loop/en-<CODE>-<N>.json) y sobrevive a la sesión. Si En se reinvoca en la misma PR, el libro mayor se reanuda.

Si la ejecución termina debido a un error, la sesión se limpia y el libro mayor se conserva. El libro mayor puede liberarse usando el comando nen loop iterate --id en-<CODE>-<N> --line "<misma línea>" --release "<razón>" --repo <común>.

7. Entrega

Después de que la ejecución de En se completa (ya sea con éxito o con error), la ejecución se entrega a la habilidad de limpieza. El invocador (mukai, getsuga, futon o el mantenedor) ofrece el cierre a través del selector de limpieza (cleanup § 2, fila wrap-up). La limpieza es obligatoria. Third-Hand es opcional. La limpieza y Third-Hand se inician después de que el protocolo de este archivo haya regresado, nunca como un paso de En.

La entrega es una transferencia de control, no una finalización. El invocador es responsable de iniciar la limpieza. En no posee la limpieza ni Third-Hand. En solo informa el resultado de su ejecución.

---

Este archivo es la especificación completa de la habilidad En. Cualquier comportamiento no especificado aquí está definido en las habilidades que En compone. Si encuentra una regla aquí que es realmente de esa habilidad, está en el archivo equivocado — vaya a leerla donde está autoria, porque una regla reafirmada en dos lugares se desvía en uno de ellos.