zheref/en

Localização da política compartilhada: docs/DISCOVERY.md, docs/WORKFLOW.md, docs/LAUNCH-MIGRATION.md, docs/STANDALONE-ENTRY.md, docs/PROCESS.md, docs/using/README.md e docs/using/mirrors.md pertencem à raiz do plugin Hatsu resolvida, não ao repositório consumidor. Em uma superfície instalada, use a raiz absoluta impressa por ten para ler esses arquivos (re-resolva através dessa skill se indisponível). Links relativos abaixo identificam locais de origem; uma cópia docs/ ausente no consumidor não é uma política faltante e não deve disparar um arquivamento duplicado. Nunca copie ou invente uma segunda política no repositório de destino.

En — o círculo mantido em torno de um PR até que esteja Pronto

Natureza: Manipulador. Tudo que en faz é voltado para o board — dirigir, relatar, tocar, observar. Kurapika diz isso quando o executa. Quando um ciclo o envia de volta para a própria mudança — uma constatação do revisor que precisa de código — o modo para essa correção é o da própria mudança (Aprimorador, Materialização, Transformação), nomeado em voz alta para aquele ciclo e devolvido depois.

Fique com este PR: relate-o, observe cada verificação de cabeça atual e revisão, conduza-o até o Ready verificado, toque uma vez em seu portão humano — e pare após no máximo N ciclos de ação.

En é o último composto do plano local e o único que pode precisar manter a atenção além do momento em que o PR foi aberto. $mukai termina oferecendo esta transferência — iniciando-a ela mesma apenas sob nen/workflow.json → mukai.autoEn (decisão 2026-09-28); a partir daí o PR pertence a En — e a vez do usuário ainda ativo apenas no caminho autoEn, um início digitado a partir da oferta sendo sua própria vez — até que Sharingan prove que está Pronto, ou um bloqueador/teto/estado terminal/cancelamento concreto termine a execução de En. O merge é o ato posterior do mantenedor, exceto para a exceção de entrega Futon registrada na § 5. Esta execução não faz harvest e não limpa. Quando En tiver concluído, o chamador oferece o encerramento através do seletor (cleanup § 2, linha wrap-up; decisão 2026-10-13) — apenas sob os dois pré-requisitos da cleanup § 2 (HR-366); um PR Pronto no prompt da § 5 não atende a nenhum: $cleanup, obrigatório, com $third-hand opcional ao lado — skills separadas, iniciadas após o protocolo deste arquivo ter retornado, nunca como uma etapa de En.

Este arquivo compõe. Ele não reespecifica. Cada etapa abaixo é de outra skill, nomeada e vinculada, e seu procedimento, suas reações a códigos de saída, suas recusas e seus resíduos vivem lá. Se você encontrar uma regra aqui que é realmente daquela skill, ela está no arquivo errado — vá lê-la onde foi escrita, porque uma regra reafirmada em dois lugares deriva em um deles.

O que é genuinamente próprio de en é o teto, a forma da vigia e o limite no final da sessão. Esses três são § 2, § 6 e § 7, e são os únicos lugares onde este arquivo afirma algo. Third-Hand não está nesse limite.

---

1. Invocação

P1 — esta execução abre com $ten en (ten § 6 recupera as pré-condições faltantes desta fase sob seu próprio nome; as fases que esta execução chama pulam as suas).

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

Iniciado por $mukai sem cláusula sob mukai.autoEn — o PR é aquele que o passo 8 acabou de abrir — por $getsuga § 3 para a proposta de release que acabou de abrir (aí en executa os passos 1–5 e retorna seu veredito citado para getsuga; o sino do passo 6 não é tocado, porque getsuga § 3a é o merge daquele PR), por futon's cadeia por-issue para o PR que seu esforço abriu, ou para seu PR de integração→main (futon § 5 não abre PR em seu branch de integração; ele faz merge lá localmente), ou pelo mantenedor, nomeando um PR que já está aberto (linha de oferta de mukai). A regra de que todo PR que uma sessão abre ou faz abrir chega ao mantenedor através desta execução ou com o veredito citado é docs/PROCESS.md § Relatando uma fase's (zheref/hatsu#103), citada, não reafirmada:

nen parse en --grammar "on [<ref>]" --line "<a invocação, sem o prefixo $en>"

Verificado ao vivo em v0.3.0 (docs/ab/en.md § 2.1): on HA#41 → ref: HA#41 na saída 0, e um on nu parseia com a cláusula ausente, também saída 0. A cláusula é ancorada atrás de um literal pela razão que $spiritual-message § 1 registra — um único slot entre colchetes é recusado no template.

A linha vazia é recusada, e é por isso que um composto não parseia nada. Verificado ao vivo: --line "" sai 2 com "a linha deve abrir com o literal 'on' — é ele que introduz <ref>". Uma cláusula opcional ancorada requer sua âncora; "nenhuma cláusula" e "linha vazia" são entradas diferentes, e apenas a primeira parseia. Então mukai, sob autoEn, entrega o PR diretamente e não chama nen parse en de forma alguma — ecoar um parse de uma linha que ninguém digitou seria teatral, e alimentá-lo com "" produziria uma recusa que não significa nada. O parse executa quando, e apenas quando, o mantenedor digitou uma cláusula.

Um argumento ou item de configuração ausente é solicitado e configurado inline (missing-argument, missing-configuration; WORKFLOW.md § 4 Pergunte, configure, continue): uma linha do mantenedor que sai 2, ou não nomeia PR onde a sessão não possui nenhum, é o gatilho para oferecer os PRs abertos da sessão no seletor e retomar na resposta, nunca o fim da execução.

Resolva o código uma vez, antecipadamente, e mantenha o slug para cada chamada posterior — nunca derive-o uma segunda vez (claude/agents/kurapika.md § Como você trabalha):

nen repo resolve <CODE> --repo <caminho para o próprio checkout do repositório alvo>
nen ref format --code <CODE> --kind PR --number <N>

Um PR fechado ou com merge finaliza a execução imediatamente com o que aconteceu com ele. Não há nada a integrar.

Um PR aberto cuja cabeça já está publicada permanece em En em cada continuação. Quando seu ramo fica atrás da base do PR, ou uma correção de revisão precisa de publicação, execute as etapas de evidência da árvore atual de En e $murasaki's push fast-forward protegido (§ 3 e murasaki § 6). Não envie o ramo publicado através do squash de $aka. A primeira publicação segue a autorização já transportada por seu workflow de invocação, seja uma chamada Aka direta ou um composto como Futon. En ainda para no portão de merge humano separado da § 5. Por exemplo, o PR #274 já estava publicado em b5fddea quando #273 avançou main; seu merge de atualização preservou essa ancestralidade publicada e Murasaki fez push do descendente verificado 5de39c5.

As fases que este composto chama PULAM suas próprias seções ## 0. Entrada autônoma. docs/STANDALONE-ENTRY.md é o contrato para uma fase digitada manualmente em um checkout arbitrário; uma fase alcançada a partir daqui herda P1–P4 desta execução — o aquecimento, a orientação, o conjunto de mudanças e cada argumento derivado — e re-derivá-los produziria uma segunda resposta para uma pergunta que este composto já resolveu. Cada fase diz qual composto a está segurando.

2. O teto — gramática, não um padrão

En age. Os passos 2 e 4 dirigem; um ciclo que encontra uma nova constatação de revisão volta para a mudança e faz push de uma correção. Isso torna en a metade mutante do par de loop, e a disciplina inteira de $izanagi se aplica: um loop que escreve precisa de um limite que um loop que lê não precisa, e tornar o limite parte da gramática significa que ele nunca pode ser padronizado, herdado ou esquecido.

Chave	Arquivo	Usado para	Padrão quando a chave (ou o arquivo) está ausente
monitor.maxCycles	nen/workflow.json	o teto — a contagem de ciclos de ação (§ 6)	20
monitor.pollSeconds	nen/workflow.json	o intervalo entre observações, como --interval-ms	300 (→ --interval-ms 300000)
branch.base	nen/workflow.json	a base na qual § 5 solicita. O passo 3 atualiza a partir de, e "atrás" é medido contra, o próprio baseRefName do PR (gh pr view <N> --json baseRefName), que é branch.base para todo PR que en solicita	main
reports.dir / .sections / .retain	nen/workflow.json	arquivo do passo 7 — chaves de backlog-board § 3	Reports / obrigatório, sem padrão (WORKFLOW § 2 → reports) / final-only
notifications.rungs / .sound	nen/workflow.json	degraus do passo 6 — chaves de $jutaisho	["push","os","sound"] / Glass

Antes do ciclo 1, o teto é explicitado através do verbo que recusa um ausente:

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

Verificado ao vivo em v0.3.0 (docs/ab/en.md § 2.2), ambos os caminhos:

$ 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 é a metade MUTANTE do par de loop e o teto é gramática obrigatória,
nunca padronizado ou inferido -- uma invocação sem ele é recusada em vez de ser executada uma vez 'para ver'.
  try: take HA-PR-#41 to its human gate until it is Ready up to <N>
exit=2

O valor vem de monitor.maxCycles; a exigência vem da gramática. Essas são duas coisas diferentes e a distinção é o ponto: o arquivo fornece um número, e o verbo se recusa a executar sem um. Um repositório cujo bloco monitor está ausente recebe 20, declarado em voz alta — ele não recebe uma vigia ilimitada, porque "o arquivo não disse nada" é exatamente o caso onde um padrão herdado-e-esquecido é perigoso.

APOSENTADO em nen 0.7: contando os ciclos de ação manualmente

Cada ciclo de ação é RECLAMADO antes de agir, e o teto é imposto pela recusa da reclamação — a aposentadoria de izanagi § 3, herdada por inteiro:

git rev-parse --path-format=absolute --git-common-dir   # <common>, no worktree do esforço
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>

Saída 0 imprime iteration <n>/<cap> e quantas restam — a própria palavra do verbo é iteration, e o ciclo de en é o que ele está reclamando; saída 1 É o teto e termina a execução na linha de estouro de teto da § 6, com a invocação nomeada na própria recusa de nen. A --line é a mesma string que nen parse izanagi ecoou acima, reafirmada em cada reclamação, então monitor.maxCycles não pode ser silenciosamente aumentado no meio da execução: uma reclamação carregando um N diferente é saída 2 nomeando ambas as linhas (verificado ao vivo exatamente contra esta forma — up to 3 executando, up to 20 reclamado — docs/ab/izanagi.md § Aposentado em nen 0.7).

O --id é o PULL REQUEST, não a sessão, e isso é uma decisão com uma consequência que vale a pena declarar: o livro-razão é .nen/loop/en-<CODE>-<N>.json sob o diretório comum do git, então ele sobrevive à sessão (§ 7) e ao worktree do esforço, que a limpeza remove (docs/ab/en.md § O teto sobrevive ao worktree), então um $en reinvocado no mesmo PR retoma o mesmo teto em vez de começar novamente no ciclo 1. Essa é a leitura honesta de "vinte ciclos de ação para deixar este PR pronto" — um teto que um reinício de limite de sessão seria um teto que ninguém tem. Quando a condução de prontidão genuinamente termina — Pronto, fechado, ou entregue ao mantenedor em um portão — feche o livro-razão com nen loop iterate --id en-<CODE>-<N> --line "<mesma linha>" --release "<porquê>" --repo <common>; um loop em seu teto pode sempre ser liberado, e um novo teto após isso é um novo --id, escolhido deliberadamente e dito em voz alta, nunca uma linha redigitada.

O teto é um limite máximo, não um alvo. Atingi-lo é uma falha em alcançar o Pronto e é relatado como tal: o que ainda não é verdadeiro, e o que o próximo ciclo teria feito. Regra de izanagi § 4, inalterada. A política de rodadas de revisão é $sharingan § 6's, declarada lá uma vez e citada aqui, nunca reafirmada:

• Uma rodada do Copilot é solicitada depois que $hanten se acalma, nunca antes.
• Chegadas são remediadas, e uma rodada devida é re-solicitada sem perguntar apenas dentro dos dois limites de sharingan § 6 (round_policy.maxRounds solicitações, round_policy.minRounds resolvidas; linha cap-reached), então en continua observando; qualquer limite atingido é a quinta parada da § 6.
• Antes de qualquer re-solicitação, nen wake verify --repo-slug <dono/nome> --now <ISO> --author-pattern <login do mantenedor> --run redireciona uma execução engolida uma vez (action_required ou startup_failure que nunca executou); uma execução action_required pelo bot do Copilot não pode ser repetida e é relatada como tal. Então a proteção de sincronização sem operação: conte commits à frente da última cabeça revisada (git rev-list --count <cabeça-revisada>..HEAD, somente leitura) e o diff stat; mudança zero revisável significa nenhuma solicitação.
• O Copilot auto-revisa cada push, então o teto governa solicitações, não chegadas; uma chegada além do teto ainda é remediada e seus threads resolvidos.

Além do máximo, a execução termina como não-pronta com o board. Nenhum é um G5. nen/workflow.json → monitor.maxCycles é o teto de ciclo de ação de en, um número diferente.

3. A execução, em ordem

#	Passo	A skill que o possui	Quando
1	relatório de aterrissagem	$spiritual-message as landing	uma vez, no início — 00–07 mais 08 corpo do PR e 09 Prontidão. Se este En foi iniciado por mukai (autoEn) ou digitado a partir de sua oferta na mesma sessão sem nenhuma solicitação humana mais recente, 00 ainda responde àquela solicitação de mukai
2	dirigir	$sharingan	primeira condição de bloqueio...

…[truncado para tradução]