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 del plugin Hatsu resuelta,
no al repositorio consumidor. En una superficie instalada, usa la raíz absoluta impresa por ten para leer
esos archivos (resuelve nuevamente 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 copies ni inventes una segunda política en el repositorio de destino.
Ren — una solicitud, un turno, cada vez
Sin modo fijo. Ren es una ejecución compuesta: el modo es el que sea la solicitud —
Enhancer para código de producto, Conjurer para canon, Transmuter para maquinaria — mantenido para el
turno y nombrado en la respuesta, con Manipulator nombrado junto a él mientras los pasos de reporte del turno
se ejecutan. Nombra el modo en juego, di cuándo cambia y por qué, y nunca combines dos bajo un mismo encabezado
(claude/agents/kurapika.md).
Toma la solicitud. Calienta si esta es la primera, escríbela, pruébala y confírmala, maneja el lanzamiento, muéstrame el reporte, toca una vez la campana. Luego espera.
Ren es la forma del trabajo ordinario en el plano local. No es un ejecutor por lotes ni un observador: una invocación es una solicitud, y una solicitud es un turno. El bucle es que la siguiente solicitud inicia el siguiente turno, con el paso de calentamiento ya gastado.
Este archivo compone. No re-especifica. Cada paso a continuación es la habilidad de otro, nombrada y enlazada, y su procedimiento, sus reacciones a códigos de salida, sus rechazos y su residuo viven allí. Si encuentras una regla aquí que realmente pertenece a esa habilidad, está en el archivo equivocado — ve a leerla donde está autorizada, porque una regla repetida en dos lugares se desvía en uno de ellos.
1. Invocación
P1 — esta ejecución comienza con $ten ren (ten § 6 alcanza esta fase
los requisitos previos faltantes bajo su propio nombre; las fases que esta ejecución llama omiten los suyos).
$ren <solicitud> [--profile fast|standard|thorough]
nen parse ren --grammar "<solicitud> [--profile <profile:fast|standard|thorough>]" \
--line "<la solicitud, sin el prefijo $ren>"
profile: (cláusula ausente) significa profile.default (§ 2a); las palabras "turno rápido" o "turno exhaustivo"
dentro de la solicitud se leen como la misma anulación.
Verificado en vivo en v0.3.0 (docs/ab/ren.md § 2.1): una línea de solicitud se analiza para dar
solicitud: <la línea completa> con salida 0, y una línea vacía se rechaza con salida 2 — " es
requerida y la línea no la proporciona" — imprimiendo la línea corregida. Un turno sin solicitud nunca se infiere de lo que la sesión estaba haciendo por última vez — se solicita como texto libre:
la solicitud es la palabra del mantenedor (fila missing-maintainer-choice, registrada mediante nen stop answer,
docs/WORKFLOW.md § 4 La palabra del mantenedor nunca se deriva), por lo que cualquier
lectura que la sesión sugiera se enumera como referencia, ninguna marcada y ninguna como opción de selección, y
el turno se ejecuta en lo que el mantenedor escribe.
Ren es también la forma predeterminada, no solo una llamada explícita. En un repositorio cuyo
nen/workflow.json describe este bucle, una solicitud ordinaria del mantenedor es un turno ren;
dilo en la primera, para que nadie se sorprenda con el reporte y la campana al final.
2. El turno, en orden
| # | Paso | La habilidad que lo posee | Por qué está aquí |
|---|---|---|---|
| 1 | calentar | $breath | vincular/re-verificar aislamiento en cada entrada bajo WORKFLOW § Dónde viven los worktrees antes de la actualización de Ten o la mutación; calienta y prueba una rama fresca una vez por nuevo esfuerzo en ese checkout — el worktree de arnés de la propia sesión en una negativa de gancho observada (HR-374). Las continuaciones explícitas reutilizan solo el worktree propiedad del esfuerzo ya verificado. Una base roja es un G5 antes de la autoría; también lo es una cláusula conflictiva en su verificación de constitución (breath § 4a), registrada en la entrada del libro mayor de este paso |
| 2 | autorizar el cambio | $rasengan | escribir lo que el mantenedor pidió, en la pila que este repositorio declara: las ediciones, las pruebas junto a ellas, los docs y el changelog que sus convenciones deben — con las iteration.checks declaradas ejecutadas como la propia retroalimentación del autor mientras el trabajo está frente a él |
| 3 | verificar y confirmar | $kokusen | cada verbo económico de iteration.checks y las pruebas enfocadas declaradas sobre el árbol terminado, rojo rechazado; luego triaje, una pregunta sobre lo señalado, un commit con forma — solo local |
| 4 | lanzar | $amaterasu | un esfuerzo aislado reporta el comando de ejecución en seco y registra lanzamiento central diferido; se requiere llamada explícita del mantenedor, luego continúa sin preguntar, incluso en serie. Sin objetivo → sin objetivo de lanzamiento declarado; omitido. Un lanzamiento central nunca mueve la autoría o entrega fuera de su worktree vinculado |
| 5 | reportar | $spiritual-message como turno | la página: logros, desafíos, no entregado, arquitectura, capturas de pantalla, el comando de lanzamiento exacto, decisiones |
| 6 | campana | $jutaisho (§ 1 decide si la solicitud de la página lo convierte en una parada) | los peldaños que el flujo de trabajo declara — y una parada solo si realmente corresponde |
El paso 2 es el cambio en sí mismo, y dejó de tener medio número el 2026-09-10. Esta tabla solía tener un paso
1.5— "el trabajo", sin dueño — junto a un paso 2 llamado construir, que leíarasengancomo ejecutar el comando de construcción en lugar de construir la cosa. El fallo del mantenedor (docs/ROSTER.mdHR-55) lo resuelve:rasenganES la fase de autoría, por lo que el trabajo tiene una habilidad, los seis números enteros son nuevamente seis habilidades, y el compilar-antes-de-confirmar se sienta con la fase que prepara el árbol.
El orden es crítico en cinco lugares, y esos cinco son los únicos que ren afirma:
- 1 antes de 2 — sin autoría sobre una base no verificada. Breath corta la rama desde
origin/<branch.base>'s punta recién obtenida y prueba las comprobaciones declaradas en ella, por lo que la primera línea del cambio aterriza en un árbol que ya se sabe que construye y el primer rojo que alguien ve es uno que este esfuerzo causó. Una punta de base roja es una parada G5 allí, antes de que se escriba una línea; nunca se repara dentro de este esfuerzo. Lo mismo se aplica para la verificación de constitución de breath § 4a, cuya puerta breath § 6 establece (WORKFLOW.md§ La verificación de constitución). - 2 antes de 3 — nada se confirma que no haya sido autorizado en este turno y verificado en él. Rasengan escribe el cambio y mantiene honesto su propio bucle interno; kokusen luego ejecuta las comprobaciones declaradas sobre el árbol terminado y se niega a confirmar en rojo. Las dos ejecuciones no son una duplicación: el árbol se mueve con cada línea escrita después de la última verificación del autor, por lo que la única ejecución en la que un commit puede descansar es la realizada por la fase que mantiene el índice. Cuando un turno itera (escribir, verificar, escribir nuevamente), es el paso 2 iterando consigo mismo, y el paso 3 se ingresa una vez.
- 3 antes de 4. El manejo del lanzamiento sigue el resultado confirmado; el aislamiento no autoriza un lanzamiento central. Un comando diferido no es una demostración del árbol de este esfuerzo.
- 4 antes de 5. El reporte distingue un comando de ejecución en seco diferido de argv realmente ejecutado.
- 5 antes de 6. La campana lleva el enlace del reporte. Una campana que suena antes de que la página exista envía al mantenedor a la nada.
Las fases que esta composición llama OMITEN sus propias secciones ## 0. Entrada independiente. 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
re-derivarlos produciría una segunda respuesta a una pregunta que esta composición ya resolvió. Cada fase
dice qué composición la está sosteniendo en su lugar.
Dentro del paso 1, una vez por esfuerzo clasificado, $direct se ejecuta — para un esfuerzo que
nombre un issue (<CÓDIGO>#<N> en la solicitud) o una clasificación de texto ya etiquetada — con el
--surface, --model y --effort (unread donde el arnés oculta uno) de esta sesión, exactamente como lo hace build § 2b; su
§ 6 posee la comparación y la única pregunta, y el $ren escrito ya es la decisión de trabajar aquí, por lo que
nunca bloquea. Su respuesta B termina este turno, no el bucle: los pasos 5 y 6 aún se ejecutan y el reporte nombra
la línea de reinicio. Un esfuerzo sin etiqueta job/ es undirectable, una línea, y el turno continúa. No es un séptimo paso y no afirma ningún orden propio: lee dentro del calentamiento, pregunta como máximo una vez, no autoriza nada — y su § 7 paso de publicación no se ejecuta aquí: Ren no puede salir de la máquina (§ 3), por lo que el veredicto permanece en el reporte y el libro mayor local, y direct.publish actúa solo bajo
build, file (una vez archivado) o independiente.
El calentamiento se ejecuta una vez por esfuerzo; la selección del checkout se verifica en CADA entrada. Turnos posteriores y
fases de PR re-verifican la ruta de esfuerzo absoluta vinculada bajo $hatsu_root/docs/WORKFLOW.md § Dónde
viven los worktrees antes del paso 2 o cualquier actualización. Reporta la ruta, el estado de exención de la indicación original y
si Breath calentó o solo re-verificó. La continuación nunca evita el aislamiento.
Una nueva solicitud es un nuevo esfuerzo a menos que la persona que llama continúe explícitamente el actual.
Sentarse en una rama de característica limpia de un esfuerzo anterior no es una continuación
(zheref/hatsu#60; $breath
§ 2a). Breath aún se ejecuta, aún obtiene la base configurada, y aún corta una rama recién renderizada.
La reutilización es solo para un "continuar" / "mismo esfuerzo" / "en esta rama" explícito, o para
el turno 2+ de un bucle cuyo paso 1 ya cortó esta rama en esta sesión.
Cuando un turno posterior de este esfuerzo, o $mukai, re-ingresa a
$hanten, reutiliza el mismo libro mayor de ciclo —
.nen/hanten/<branch-slug>.cycle.json. La remediación no restablece los recuentos de revisores. Breath cortando
una nueva rama es el único nuevo ciclo
(zheref/hatsu#63; hanten § 2a).
2a. Perfiles y el libro mayor de fase
profile.default en nen/workflow.json da forma al turno (standard cuando está ausente);
el --profile de § 1 lo anula, un valor fuera de profile.allowed se solicita nuevamente con la lista permitida
como opciones del selector, y la primera línea del turno nombra el perfil en juego.
| Perfil | Qué cambia en § 2 |
|---|---|
fast | paso 1 verifica el enlace; el calentamiento aún se ejecuta una vez; pasos 2 y 3 según lo declarado; paso 4 omitido, línea de lanzamiento diferido por perfil fast; el aislamiento aún requiere una llamada explícita de lanzamiento central del mantenedor; paso 5 renderiza --variant turn-fast |
standard | el turno de hoy, como lo indica la tabla anterior |
thorough | standard, y después del paso 3, kotoamatsukami ejecuta los conjuntos impactados, en cada turno |
Un perfil decide qué pasos se ejecutan y qué variante renderiza el paso 5, nunca qué sucede dentro de un
paso. Los pasos 2 y 3 se ejecutan como sus habilidades dicen bajo cada perfil. Bajo fast los conjuntos impactados no se
ejecutan (son de mukai, paso 4 allí); bajo thorough los conjuntos impactados de kotoamatsukami se
ejecutan después del paso 3, siendo ren el tercer llamador de esa habilidad. El lanzamiento se omite, no se mueve:
mukai no tiene paso de lanzamiento, y amaterasu § 1a dice cómo se toma un lanzamiento omitido.
La cobertura no es capturada por ningún perfil de ren; esa es de byakugan, en mukai.
Un aterrizaje (mukai) siempre se ejecuta en thorough, sea cual sea el perfil que los turnos anteriores nombraron.
Cada paso es una entrada del libro mayor (WORKFLOW.md § Los libros mayores del esfuerzo posee el
mecanismo; lo que es de ren es qué pasos y cuándo). Antes de un paso, nen phase begin --effort <rama> --phase <nombre-paso> --surface <s> [--model <modelo-reportado>] --dial <nivel>; si el modelo es un ID servido reportado por el arnés,
añade --note "model-kind=served; registry alias <alias>" (WORKFLOW § Los libros mayores del esfuerzo); en la primera fase registra
nen session record con el título/id del arnés cuando se expone, una vez por sesión; después de un paso, nen phase end --effort <rama> --phase <nombre-paso> --exit <código>, por lo que .nen/phases/<esfuerzo>.json lleva una entrada temporizada por fase, incluido un paso
rechazado. El end del paso 1 lleva el registro de breath § 4a como su --note, compuesto con la
nota con la que comenzó el paso 1, porque end --note la reemplaza (el --begin-note del script; WORKFLOW
§ La verificación de constitución, pasos 3, 5 y 6, posee los formularios). La verificación no es una entrada propia,
por lo que los seis pasos siguen siendo seis entradas (HR-58). La entrada de uso se registra en el paso 5: nen usage record --effort <rama> --surface <s> [--model] --dial <nivel> [--input] [--output] [--cache-read] [--cache-write] [--minutes] desde
la propia lectura de costos de la superficie, --not-reported en una superficie que no expone ninguna.
Un esfuerzo reanudado lee antes de escribir (zheref/hatsu#444, zheref/hatsu#445; nen 0.28, el pin). Un esfuerzo cuya
rama ya tiene un libro mayor de fases, o un PR, es una reanudación: primero, donde existe un PR — el abierto: un número de sucesor, nunca el PR que una eliminación de base cerró (en § 6) — nen pr ledger read --target <owner/name> --pr <n> --effort <rama> --repo <checkout> --json, añadiendo --restore solo donde
nen phase show no encuentra un libro mayor local; luego nen phase show --effort <rama> --json. WORKFLOW § Los
libros mayores del esfuerzo, La porción duradera, posee los veredictos y el único formulario de línea de omisión; una entrada
breath omitida se lee antes del paso 2 (WORKFLOW § La verificación de constitución, paso 7). Por fase, en orden:
terminada con salida 0 → **