Ubicación compartida de las políticas: 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 que imprime
ten para leer esos archivos (vuelva a resolver a través de esa skill si no están disponibles). Los enlaces relativos a continuación identifican ubicaciones de origen; una copia faltante en docs/ del consumidor no es una política faltante y no debe desencadenar una presentación duplicada. Nunca copie o invente una segunda política en el repositorio de destino.
Aka — la rama sale
Naturaleza: Manipulador. Empujar es una operación del lado de git sobre estado compartido por definición, independientemente de qué naturaleza haya creado el diff.
Aplica lint, fusiona solo el historial no publicado, coloca la base debajo de él, vuelve a aplicar lint si eso movió el árbol, y coloca ese árbol exacto en el remoto. Sin PR. Sin pruebas a nivel de proyecto.
Aka es la primera llamada humana en el plano local. Todo lo anterior — los turnos de hatsu:ren, los commits de hatsu:kokusen — sucede sin preguntar, porque nada de ello sale de la máquina. Aka es donde el trabajo se convierte en algo que otra persona puede obtener, y ese límite es el que el mantenedor debe cruzar.
No abre ningún pull request. Eso es la ejecución de hatsu:mukai, y el paso de hatsu:shibari dentro de él. Aka termina con una rama empujada y nada más, deliberadamente: un push y un PR son dos decisiones, y fusionarlas hace que una de ellas no pueda ser preguntada.
0. Entrada independiente — esta skill SIEMPRE fue la llamada del mantenedor
Aka no tiene una entrada cableada. El § 1 ya lo dice: toda la skill se ejecuta solo en la llamada de publicación del mantenedor, y los agentes nunca la proponen. La primera excepción, el fallo del mantenedor del 2026-09-28 (b) (docs/ROSTER.md § Fallos del 2026-09-26/27/28): un paso then que nombre esta skill en una invocación tipada de futon es la llamada de publicación del mantenedor — el avance previo mugetsu § 3 define — aún nunca solicitada, nunca propuesta. docs/STANDALONE-ENTRY.md § 6 la nombra entre las fases que un informe, una campana, las opciones de una parada y un compuesto nunca deben ofrecer — y una ejecución independiente es precisamente donde tal oferta se leería como si el pipeline supiera más que el usuario.
Segunda excepción — publicación delegada de un compuesto tipado — el fallo del mantenedor HR-20 (zheref/hatsu#332), que ratifica docs/ROSTER.md § Lectura del 2026-10-19 — publicación delegada de un compuesto tipado sin cambios. Se basa en dos fallos ya emitidos: el delegado de kazaana redacta y publica cada issue en cola (ROSTER § Fallos del 2026-10-13, fallo 1), y un esfuerzo de futon en una rama de integración ejecuta aka para publicar su propia rama de esfuerzo (ROSTER § Fallos del 2026-09-30 — En nunca fusiona, fila Donde un esfuerzo se detiene); en la forma apilada o por issue, su push es futon § 4 → build § 5.
Una invocación tipada de futon o kazaana es la llamada de publicación del mantenedor para las ramas de trabajo que ejecutan los autores — una llamada permanente, nunca una por commit:
| El alcance de una línea tipada de futon / kazaana | |
|---|---|
| Cubierto | por esfuerzo en la cola de la ejecución: su publicación inicial (esta skill, en el delegado constructor o en la sesión — kazaana § 3; build § 5) y cada commit de mantenimiento y push que lo entrega — una corrección de revisión, una actualización, una reparación revisada (murasaki § 6 dentro de mukai y en) — al repositorio de destino de la ejecución y a la rama de trabajo propia de ese esfuerzo, a través de las compuertas sin cambios de esta skill y de murasaki |
| No cubierto | otro remoto o repositorio, otra rama, branch.base, una forma forzada o una reescritura de un commit publicado, una etiqueta, una fusión, un lanzamiento. Fuera de la fila Cubierto, un push se sostiene o cae según la propia regla de su skill: murasaki § 6 para una rama ya publicada; la rama de integración de futon § 5, empujada solo con nen wc publish, nunca a través de aka y nunca forzada (ROSTER § Fallos del 2026-09-30 — En nunca fusiona); getsuga § 3/§ 3a para la rama de propuesta y § 4 (El corte) para la etiqueta. El redestino de un hijo apilado es el plan de fusión (WORKFLOW.md § Pull requests apiladas regla 5; ROSTER § Fallos del 2026-10-12). Donde ninguna skill posee un acto, no se realiza, y se informa; es un G5 solo donde es un acto que solo el mantenedor puede hacer |
| Caducidades | cuando la ejecución termina (futon § 10), en una parada, o un G5 que detiene la ejecución, o por orden del mantenedor — nunca porque el commit cambió; un G5 propio de un esfuerzo caduca el alcance de ese esfuerzo solo — nunca el de otro — y se reanuda cuando el mantenedor responde; una indicación de fusión G2/G4 no caduca nada (como mugetsu § 3). Una sesión reanudada, reiniciada o compactada lo mantiene solo en una invocación tipada fresca, nunca desde un punto de control, un registro de ejecución o un resumen |
El alcance es el destino, nunca el SHA. Un nuevo commit en la misma rama del mismo repositorio está dentro de él; preguntar de nuevo porque el commit se movió es el fallo que #332 registra. Cada traspaso lo lleva — del padre al delegado constructor (kazaana § 3) y cada paso de mantenimiento posterior (mukai, en, murasaki): el registro de cinco hechos — la invocación citada textualmente, cualquier respuesta del mantenedor en la que también se basa el push, el repositorio, la rama de trabajo, y alcance: publicación inicial y pushes de mantenimiento a esta rama hasta que la ejecución termine. Un punto de control, un registro de ejecución o un traspaso posterior nunca lo reduce a un commit exacto; donde una línea anterior diga lo contrario, la corrección posterior lo reemplaza en lugar de estar a su lado.
El registro sobrevive a cada traspaso, incluidos los de mantenimiento, igual en todas las superficies (zheref/hatsu#529). Este párrafo no amplía ninguna de las tres filas. Un requisito previo fuera de la cola del selector no está Cubierto por la línea tipada: su push se sostiene solo por las propias palabras del mantenedor que autorizan esa publicación (la llamada del § 1, en sus propias palabras), citadas como el segundo hecho, en el repositorio de destino de la ejecución — una respuesta que aprueba solo su preparación no autoriza ningún push, y se pregunta una vez. La entrega de integración de una ejecución inactiva sigue siendo la de futon § 5 (No cubierto arriba); su solicitud lleva los mismos hechos y cita futon § 5 como su autoridad. Un push rutinario que necesita la aprobación del anfitrión presenta ese registro en la solicitud — en Codex, la justificación de su ruta de revisión compatible (docs/surfaces/codex.md § Solicitudes de publicación) — por lo que un actor, árbol de trabajo o commit cambiado no es motivo para preguntar al mantenedor de nuevo; lo que el anfitrión decida sigue siendo del anfitrión. El registro es evidencia para el revisor, nunca una aprobación autootorgada: un destino fuera de alcance, la base protegida, una reescritura o un acto de lanzamiento sigue siendo rechazado o detrás de su propia compuerta, y un rechazo real es el siguiente párrafo. Los casos limitados están en docs/ab/publication-authority.md.
Un rechazo del anfitrión sigue siendo del anfitrión. Donde la capa de aprobación del entorno rechace un push dentro del alcance, el rechazo se cita al mantenedor con la invocación y el alcance, y se resuelve solo a través de la ruta de aprobación compatible de ese anfitrión — el acto del mantenedor: su aprobación allí, o un reenvío a través de esa misma ruta que lleve sus palabras recién dadas citadas junto al registro (zheref/hatsu#529) — nunca un reintento solo con evidencia, nunca otro comando, ruta o superficie para el mismo push, nunca se pide una concesión más amplia, nunca se toca una configuración de permisos. Una aprobación exacta dada allí sigue siendo un recibo válido para su propia acción, y no amplía nada.
Una trayectoria representativa. hatsu:kazaana zheref/nen → el aka del delegado publica por primera vez <model>/kurapika/<slug> en el commit A → mukai abre el PR → en: se corrige un hallazgo de revisión, kokusen hace commit B, murasaki empuja B a la misma rama. Ambos pushes se sostienen en la única línea tipada y ninguno pregunta; B empujado a cualquier otra rama está fuera, y se sostiene o cae en la fila No cubierto.
Las dos excepciones se mantienen separadas. Un paso then aka es la orden de un solo uso de la primera excepción; la segunda cubre solo los pushes por esfuerzo que hace el motor del compuesto. hatsu:aka independiente no cambia — una llamada, una ejecución (§ 1) — y ninguna excepción alcanza una fusión en branch.base (la indicación de en § 5) o un lanzamiento (getsuga, mugetsu).
P1 aplica — hatsu:ten aka, que actualiza los requisitos previos de esta fase (ten § 6) — y P2 pertenece al informe antes de la fusión: la rama, limpia o sucia, cuántos commits no están empujados, y cuáles ya están en el remoto. § 4 fusiona solo commits no empujados y ese límite se lee del remoto, nunca se recuerda.
Nada más cambia. Aka aún no ejecuta pruebas a nivel de proyecto ni cobertura — hatsu:kotoamatsukami y hatsu:byakugan poseen esas en mukai — aún se detiene en G5 ante una verificación requerida en rojo, y aún nunca fuerza el push o reescribe un commit ya en el remoto.
Devolución. Siguiente en la ejecución cableada: hatsu:mukai — revisión, pruebas impactadas, cobertura, evidencia y el PR. Es suya para llamar, y esta ejecución no lo pregunta.
1. Invocación — y quién tiene permitido decirla
hatsu:aka
Sin argumentos, por lo que no hay nada para que nen parse posea — y decirlo es el punto, no una omisión.
nen parse <skill> --grammar <template> --line <text> existe para una gramática; un verbo desnudo no tiene ninguna, e inventar una cláusula opcional para que se pueda repetir un análisis sería ceremonia.
La llamada es del mantenedor, en sus propias palabras o por nombre. Dos consecuencias, ambas vinculantes:
- Ningún agente la sugiere. Ni
hatsu:jutaishoal final de un turno, nihatsu:spiritual-messageen un informe, ni un compuesto ofreciéndola como siguiente paso, ni una opción con letra en una parada. Un informe puede decir la rama está lista para salir; no puede decir ¿la empujo? Un agente que pide permiso que se le dijo que esperara ha convertido una llamada humana en un empujón, y el empujón es lo que la disciplina de push del plano local existe para prevenir. - Una llamada, una ejecución. Un
sípara este push no es autoridad para el siguiente. Diga que la ejecución ha comenzado y diga cuándo termina. La única llamada permanente es la de un compuesto tipado, limitada por destino (§ 0, segunda excepción: una línea de futon o kazaana, cuyos esfuerzos publican a través de build § 5); el push de un build independiente se sostiene en la delegación con alcance de ejecución propia de build § 5, no en esta excepción.
2. Los parámetros — nen/workflow.json, con los valores predeterminados indicados
| Clave | Utilizado para | Valor predeterminado cuando la clave (o el archivo) está ausente |
|---|---|---|
branch.base | la base contra la que § 4 fusiona y § 5 actualiza | main |
iteration.lane | qué carril § 3 y § 6 aplican lint | project.defaultLane |
commits.allowedAttributionTrailers | trailers de persona/plano canónicos que el commit puede llevar | Hatsu-Agent, Akatsuki-Agent |
commits.forbiddenTrailers | trailers de atribución que rechazan el commit de plano | incluye Co-Authored-By, Claude-Session, Signed-off-by, Generated-by, Generated-with, Reviewed-by |
nen schema check --repo <path> VALIDA este archivo en el build fijado — verificado en vivo, la fila lee ok nen/workflow.json coverage 80/85/90 (touched), branch '{model}/{persona}/{descriptor}' off 'main', checks: lint. Una clave malformada es un FALLO por puntero, por lo que esta skill ya no verifica la forma a ojo; lee los valores e indica los valores predeterminados siempre que sean los que se aplicaron.
Un argumento o elemento de configuración faltante se pregunta y configura en línea (missing-argument, missing-configuration; WORKFLOW.md § 4 Pregunta, configura, continúa); un valor predeterminado anterior que cubra la clave se usa y declara, nunca se pregunta. Los rechazos del § 4 no son lagunas: reescribir el historial publicado, un trailer prohibido y un push del tronco siguen siendo rechazados, nunca se adivinan.
Cambio declarado de
claude/agents/kurapika.md§ Cómo trabajas — nombrado, no introducido de forma encubierta. La definición del agente hoy dice "Sin atribución de IA más allá de los trailers que el propio entorno del mantenedor exige — hoyCo-Authored-By:yClaude-Session:… no agregas atribución propia ni eliminas la suya", y registra que la regla final es una cuestión constitucional dejada abierta.nen/workflow.jsones donde el mantenedor la responde para un repositorio dado, y este flujo de trabajo la responde:Hatsu-AgentyAkatsuki-Agentestán admitidos, uno por plano, y los otros dos están prohibidos. Donde los dos estén en desacuerdo, el bloquecommitspropio del repositorio gana para ese repositorio, porque es la decisión registrada del mantenedor en lugar de una tensión no resuelta. Un repositorio que no incluya un bloquecommitsobtiene los valores predeterminados anteriores, y dicen lo mismo. Este es un cambio de proceso declarado, divulgado aquí de la misma manera quehatsu:futon§ Cambio de proceso declarado divulga el suyo propio.
3. Puerta de lint previa a la fusión
Antes de que nen wc squash pueda reescribir incluso los commits no publicados, ejecute la fila de lint declarada para iteration.lane:
nen shu lint --repo <path> --lane <iteration.lane> --dry-run
nen shu lint --repo <path> --lane <iteration.lane>
Ejecute dry-run una vez en un repositorio desconocido. Un lint en rojo finaliza la ejecución antes de que cambie el historial. Se cita un asiento. Esta puerta está deliberadamente antes de la fusión; es barata y evita que aka reemplace varios puntos de control útiles con un commit en rojo. Es hatsu:gyo — el proceso de linting — no la