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 resolvida do plugin Hatsu,
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 habilidade se indisponível). Links relativos abaixo identificam localizações de
origem; uma cópia docs/ ausente no consumidor não é uma política ausente e não deve acionar um
arquivamento duplicado. Nunca copie ou invente uma segunda política no repositório de destino.
Ren — uma requisição, um turno, sempre
Sem modo fixo. Ren é uma execução composta: o modo é aquele que a requisição é —
Enhancer para código de produto, Conjurer para cânone, Transmuter para maquinário — mantido para o
turno e nomeado na resposta, com Manipulator nomeado junto enquanto as etapas de relatório
do turno são executadas. Nomeie o modo em jogo, diga quando ele muda e por quê, e nunca misture dois sob um cabeçalho
(claude/agents/kurapika.md).
Pegue a requisição. Aqueça se esta for a primeira, escreva-a, prove-a e faça commit, gerencie o lançamento, me mostre o relatório, toque uma vez. Então espere.
Ren é a forma do trabalho comum no plano local. Não é um executor de lote nem um observador: uma invocação é uma requisição, e uma requisição é um turno. O ciclo é que a próxima requisição inicia o próximo turno, com a etapa de aquecimento já gasta.
Este arquivo compõe. Ele não reespecifica. Cada etapa abaixo é de outra habilidade, nomeada e vinculada, e seu procedimento, suas reações a códigos de saída, suas recusas e seu resíduo vivem lá. Se você encontrar uma regra aqui que é realmente daquela habilidade, está no arquivo errado — vá lê-la onde é escrita, porque uma regra reafirmada em dois lugares se desvia em um deles.
1. Invocação
P1 — esta execução abre com $ten ren (ten § 6 atualiza esta fase com
pré-requisitos faltantes sob seu próprio nome; as fases que esta execução chama pulam as suas).
$ren <requisição> [--profile fast|standard|thorough]
nen parse ren --grammar "<requisição> [--profile <profile:fast|standard|thorough>]" \
--line "<a requisição, sem o prefixo $ren>"
profile: (cláusula ausente) significa profile.default (§ 2a); as palavras "turno rápido" ou "turno completo"
dentro da requisição são lidas como a mesma sobrescrita.
Verificado ao vivo em v0.3.0 (docs/ab/ren.md § 2.1): uma linha de requisição analisa para
request: <a linha inteira> na saída 0, e uma linha vazia recusa na saída 2 — "<requisição> é
obrigatória e a linha não a fornece" — com a linha corrigida impressa. Um turno sem requisição nunca é inferido
a partir do que a sessão estava fazendo por último — é solicitado como texto livre: a requisição é a palavra do
mantenedor (linha missing-maintainer-choice, registrada através de nen stop answer,
docs/WORKFLOW.md § 4 A palavra do mantenedor nunca é derivada), então quaisquer
leituras que a sessão sugira são listadas para referência, nenhuma destacada e nenhuma como opção de seletor, e
o turno executa o que o mantenedor digitar.
Ren também é a forma padrão, não apenas uma chamada explícita. Em um repositório cujo
nen/workflow.json descreve este ciclo, uma requisição comum do mantenedor é um turno ren;
diga isso no primeiro, para que ninguém seja surpreendido pelo relatório e pelo sino no final dele.
2. O turno, em ordem
| # | Etapa | A habilidade que a possui | Por que está aqui |
|---|---|---|---|
| 1 | aquecimento | $breath | vincular/re-verificar isolamento em cada entrada sob WORKFLOW § Onde os worktrees vivem antes da atualização do Ten ou mutação; aquecer e provar uma nova branch uma vez por novo esforço naquele checkout — o worktree de arnês da própria sessão em uma recusa de hook observada (HR-374). Continuações explícitas reutilizam apenas o worktree de esforço verificado. Uma base vermelha é um G5 antes da autoria; o mesmo para uma cláusula conflitante em sua verificação de constituição (breath § 4a), registrada na entrada do razão desta etapa |
| 2 | criar a mudança | $rasengan | escrever o que o mantenedor pediu, na pilha que este repositório declara: as edições, os testes ao lado delas, os docs e changelog que suas convenções devem — com os iteration.checks declarados executados como o próprio feedback do autor enquanto o trabalho está na frente deles |
| 3 | verificar e commitar | $kokusen | cada verbo iteration.checks barato e os testes focados declarados sobre a árvore finalizada, vermelho recusado; então triagem, uma pergunta sobre o que foi sinalizado, um commit moldado — apenas local |
| 4 | lançamento | $amaterasu | um esforço isolado relata o comando de dry-run e registra lançamento principal adiado; chamada explícita do mantenedor necessária, então continua sem perguntar, mesmo quando serial. Sem alvo → nenhum alvo de lançamento declarado; pulado. Um lançamento principal nunca move autoria ou entrega para fora de seu worktree vinculado |
| 5 | relatório | $spiritual-message como turno | a página: realizado, desafios, não entregue, arquitetura, capturas de tela, o comando exato de lançamento, decisões |
| 6 | sino | $jutaisho (§ 1 decide se a pergunta da página torna uma parada) | os degraus que o workflow declara — e uma parada apenas se uma for genuinamente devida |
A etapa 2 é a mudança em si, e parou de ser meio-numerada em 2026-09-10. Esta tabela costumava carregar uma etapa
1.5— "o trabalho", de propriedade de nenhuma habilidade — ao lado de uma etapa 2 chamada build, que liarasengancomo execute o comando de build em vez de construa a coisa. A decisão do mantenedor (docs/ROSTER.mdHR-55) resolve:rasenganÉ a fase de autoria, então o trabalho tem uma habilidade, os seis números inteiros são seis habilidades novamente, e o compilar-antes-de-commitar fica com a fase que prepara a árvore.
A ordem é crucial em cinco lugares, e esses cinco são os únicos que ren afirma:
- 1 antes de 2 — nenhuma autoria em uma base não verificada. Breath corta a branch de
origin/<branch.base>'s ponta recém-buscada e prova as verificações declaradas nela, então a primeira linha da mudança cai em uma árvore já conhecida por construir e o primeiro vermelho que alguém vê é um que este esforço causou. Uma ponta de base vermelha é uma parada G5 ali, antes que uma linha seja escrita; nunca é reparada dentro deste esforço. O mesmo vale para a verificação de constituição de breath § 4a, cujo portão breath § 6 declara (WORKFLOW.md§ A verificação de constituição). - 2 antes de 3 — nada é commitado que não foi criado neste turno e verificado nele. Rasengan escreve a mudança e mantém seu próprio loop interno honesto; kokusen então executa as verificações declaradas sobre a árvore finalizada e recusa commitar em vermelho. As duas execuções não são uma duplicação: a árvore se move com cada linha escrita após a última verificação do autor, então a única execução na qual um commit pode se basear é aquela feita pela fase que mantém o índice. Onde um turno itera (escrever, verificar, escrever novamente), é a etapa 2 iterando consigo mesma, e a etapa 3 é inserida uma vez.
- 3 antes de 4. O manuseio do lançamento segue o resultado commitado; o isolamento não autoriza um lançamento principal. Um comando adiado não é uma demonstração da árvore deste esforço.
- 4 antes de 5. O relatório distingue um comando de dry-run adiado de argv realmente executado.
- 5 antes de 6. O sino carrega o link do relatório. Um sino que toca antes da página existir envia o mantenedor para lugar nenhum.
As fases que este composite chama PULAM suas próprias seções ## 0. Entrada independente. 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 composite já resolveu. Cada fase
diz qual composite a está segurando.
Dentro da etapa 1, uma vez por esforço classificado, $direct executa — para um esforço que
nomeia uma issue (<CÓDIGO>#<N> na requisição) ou um classificado de texto já rotulado — com
--surface, --model e --effort (unread onde o arnês esconde um) desta sessão, exatamente como build § 2b faz; seu
§ 6 possui a comparação e a única pergunta, e o $ren digitado já é a decisão de trabalhar aqui, então
nunca bloqueia. Sua resposta B termina este turno, não o ciclo: as etapas 5 e 6 ainda são executadas e o relatório nomeia
a linha de reinício. Um esforço sem rótulo job/ é undirectable, uma linha, e o turno prossegue. Não é uma sétima etapa e não afirma
ordem própria: lê dentro do aquecimento, pergunta no máximo uma vez, não cria nada — e sua etapa de publicação § 7
não executa aqui: Ren não pode deixar a máquina (§ 3), então o veredito fica no relatório e no razão local, e direct.publish atua apenas sob
build, file (uma vez arquivado) ou independente.
O aquecimento é executado uma vez por esforço; a seleção do checkout é verificada em CADA entrada. Turnos posteriores e
fases de PR re-verificam o caminho absoluto do esforço vinculado sob $hatsu_root/docs/WORKFLOW.md § Onde
os worktrees vivem antes da etapa 2 ou qualquer atualização. Relate o caminho, o status de isenção do prompt original e
se Breath aqueceu ou apenas re-verificou. Continuação nunca ignora isolamento.
Uma nova requisição é um novo esforço, a menos que o chamador continue explicitamente o atual. Estar
sentado em uma branch de feature limpa de um esforço anterior não é uma continuação
(zheref/hatsu#60; $breath
§ 2a). Breath ainda executa, ainda busca a base configurada, e ainda corta uma branch recém-renderizada.
Reúso é apenas para uma "continue" explícita / "mesmo esforço" / "nesta branch", ou para
turno 2+ de um ciclo cuja etapa 1 já cortou esta branch nesta sessão.
Quando um turno posterior deste esforço, ou $mukai, reentra em
$hanten, ele reutiliza o mesmo razão de ciclo —
.nen/hanten/<branch-slug>.cycle.json. Remediação não redefine contagens de revisor. Breath cortando
uma nova branch é o único novo ciclo
(zheref/hatsu#63; hanten § 2a).
2a. Perfis, e o razão de fase
profile.default em nen/workflow.json molda o turno (standard quando ausente); o § 1's
--profile o sobrescreve, um valor fora de profile.allowed é perguntado novamente com a lista permitida
como opções do seletor, e a primeira linha do turno nomeia o perfil em jogo.
| Perfil | O que muda em § 2 |
|---|---|
fast | etapa 1 verifica o vínculo; aquecimento ainda é executado uma vez; etapas 2 e 3 conforme declarado; etapa 4 pulada, linha de lançamento adiado pelo perfil fast; isolamento ainda requer uma chamada explícita de lançamento principal do mantenedor; etapa 5 renderiza --variant turn-fast |
standard | turno de hoje, conforme a tabela acima declara |
thorough | standard, e após a etapa 3, as suítes impactadas de kotoamatsukami são executadas, em cada turno |
Um perfil decide quais etapas são executadas e qual variante a etapa 5 renderiza, nunca o que acontece dentro de uma
etapa. As etapas 2 e 3 são executadas conforme suas habilidades dizem sob cada perfil. Sob fast, as suítes impactadas não são
executadas (elas são de mukai, etapa 4 lá); sob thorough, as suítes impactadas de kotoamatsukami são
executadas após a etapa 3, sendo ren o terceiro chamador dessa habilidade. O lançamento é pulado, não movido:
mukai não tem etapa de lançamento, e amaterasu § 1a diz como um lançamento pulado é
considerado. Cobertura não é capturada por nenhum perfil de ren; isso é de byakugan, em mukai.
Um pouso (mukai) sempre executa thorough, qualquer que seja o perfil nomeado pelos turnos anteriores.
Cada etapa é uma entrada de razão (WORKFLOW.md § Os razões do esforço possui o
mecanismo; o que é de ren são quais etapas e quando). Antes de uma etapa, nen phase begin --effort <branch> --phase <nome-da-etapa> --surface <s> [--model <modelo-relatado>] --dial <nivel>; se o modelo for um ID servido relatado pelo arnês,
adicione --note "model-kind=served; registry alias <alias>" (WORKFLOW § Os razões do esforço); no primeiro registro de fase
nen session record com o título/id do arnês quando exposto, uma vez por sessão; após uma etapa, nen phase end --effort <branch> --phase <nome-da-etapa> --exit <código>, para que .nen/phases/<esforço>.json carregue uma entrada temporizada por fase, incluindo uma
etapa recusada. O end da etapa 1 carrega o registro de breath § 4a como seu --note, composto com a
nota com a qual a etapa 1 começou, porque end --note a substitui (o --begin-note do script; WORKFLOW
§ A verificação de constituição, etapas 3, 5 e 6, possui os formulários). A verificação não é uma entrada própria,
então as seis etapas permanecem seis entradas (HR-58). A entrada de uso é registrada na etapa 5: nen usage record --effort <branch> --surface <s> [--model] --dial <nivel> [--input] [--output] [--cache-read] [--cache-write] [--minutes] a partir
da leitura de custo da própria superfície, --not-reported em uma superfície que não expõe nenhuma.
Um esforço retomado lê antes de escrever (zheref/hatsu#444, zheref/hatsu#445; nen 0.28, o pin). Um esforço cuja
branch já tem um razão de fase, ou um PR, é uma retomada: primeiro, onde um PR existe — o aberto: o número de um sucessor, nunca o PR que uma exclusão de base fechou (en § 6) — nen pr ledger read --target <dono/nome> --pr <n> --effort <branch> --repo <checkout> --json, adicionando --restore apenas onde
nen phase show não encontra razão local; então nen phase show --effort <branch> --json. WORKFLOW § Os
razões do esforço, A fatia durável, possui os vereditos e o único formulário de linha pulada; uma notam de
entrada breath pulada é lida antes da etapa 2 (WORKFLOW § A verificação de constituição, etapa 7). Por fase, em ordem:
terminada na saída 0 → …