zheref/aka

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 habilidade se indisponível). Links relativos abaixo identificam locais de origem; uma cópia docs/ ausente no consumidor não é uma política ausente e não deve disparar um arquivamento duplicado. Nunca copie ou invente uma segunda política no repositório de destino.

Aka — o branch vai para fora

Natureza: Manipulador. Enviar é uma operação do lado do git em estado compartilhado por definição, independentemente de qual natureza tenha criado o diff.

Linte, faça squash apenas do histórico não publicado, coloque a base debaixo dele, relinte se isso moveu a árvore e coloque essa árvore exata no remoto. Sem PR. Sem testes de projeto.

Aka é a primeira chamada humana no plano local. Tudo antes dela — hatsu:ren's turnos, hatsu:kokusen's commits — acontece sem perguntar, porque nada disso sai da máquina. Aka é onde o trabalho se torna algo que outra pessoa pode buscar, e esse limite é do mantenedor cruzar.

Não abre pull request. Isso é a execução de hatsu:mukai e o passo de hatsu:shibari dentro dela. Aka termina com um branch enviado e nada mais, deliberadamente: um envio e um PR são duas decisões, e juntá-los torna uma delas inquestionável.

---

0. Entrada autônoma — esta habilidade SEMPRE foi a chamada do mantenedor

Aka não tem entrada conectada. § 1 já diz: toda a habilidade é executada apenas na chamada de publicação do mantenedor, e agentes nunca a propõem. A primeira exceção, o julgamento do mantenedor de 2026-09-28 (b) (docs/ROSTER.md § Julgamentos de 2026-09-26/27/28): um passo then nomeando esta habilidade em uma invocação tipada de futon é a chamada de publicação do mantenedor — o go avançado que mugetsu § 3 define — ainda nunca solicitado, nunca proposto. docs/STANDALONE-ENTRY.md § 6 a nomeia entre as fases que um relatório, um sino, uma parada e um composite nunca devem oferecer — e uma execução autônoma é precisamente onde tal oferta pareceria que o pipeline sabe o que é melhor.

Segunda exceção — publicação delegada de um composite tipado — o julgamento do mantenedor HR-20 (zheref/hatsu#332), ratificando docs/ROSTER.md § Leitura de 2026-10-19 — publicação delegada de um composite tipado inalterado. Baseia-se em dois julgamentos já feitos: o delegado de kazaana cria e publica cada issue enfileirada (ROSTER § Julgamentos de 2026-10-13, julgamento 1), e um esforço de futon em um branch de integração executa aka para publicar seu próprio branch de esforço (ROSTER § Julgamentos de 2026-09-30 — En nunca faz merge, linha Onde um esforço para); na forma empilhada ou por issue, seu envio é futon § 4 → build § 5. Uma invocação tipada de futon ou kazaana é a chamada de publicação do mantenedor para os branches de trabalho que executam autores — uma chamada única, nunca uma por commit:

	O escopo de uma linha tipada de futon / kazaana
Coberto	por esforço na fila da execução: sua publicação inicial (esta habilidade, no delegado builder ou na sessão — kazaana § 3; build § 5) e todo commit de manutenção e envio que o entrega — uma correção de revisão, um catch-up, um reparo revisado (murasaki § 6 dentro de mukai e en) — para o repositório de destino da execução e para o próprio branch de trabalho daquele esforço, através dos portões inalterados desta habilidade e de murasaki
Não coberto	outro remoto ou repositório, outro branch, branch.base, um formulário de força ou uma reescrita de um commit publicado, uma tag, um merge, um release. Fora da linha Coberto, um envio depende de sua própria regra da habilidade proprietária: murasaki § 6 para um branch já publicado; o branch de integração de futon § 5, enviado apenas com nen wc publish, nunca através de aka e nunca forçado (ROSTER § Julgamentos de 2026-09-30 — En nunca faz merge); getsuga § 3/§ 3a para o branch de proposta e § 4 (O corte) para a tag. O redirecionamento de um filho empilhado é do plano de merge (WORKFLOW.md § Pull requests empilhados regra 5; ROSTER § Julgamentos de 2026-10-12). Onde nenhuma habilidade possui um ato, ele não é executado e é relatado; é um G5 apenas onde é um ato que apenas o mantenedor pode fazer
Expirações	quando a execução termina (futon § 10), em uma parada, ou um G5 que para a execução, ou pela palavra do mantenedor — nunca porque o commit mudou; o próprio G5 de um esforço expira o escopo daquele esforço apenas — nunca o de outro — e ele retoma quando o mantenedor responde; um prompt de merge G2/G4 não expira nada (como mugetsu § 3). Uma sessão retomada, reiniciada ou compactada o mantém apenas em uma invocação tipada nova, nunca de um checkpoint, um registro de execução ou um resumo

O escopo é o destino, nunca o SHA. Um novo commit no mesmo branch do mesmo repositório está dentro dele; perguntar novamente porque o commit mudou é a falha que #332 registra. Cada passagem o carrega — do pai ao delegado builder (kazaana § 3) e cada passo de manutenção depois (mukai, en, murasaki): o registro de cinco fatos — a invocação citada literalmente, qualquer resposta do mantenedor na qual o envio também se baseia, o repositório, o branch de trabalho e escopo: publicação inicial e envios de manutenção para este branch até o fim da execução. Um checkpoint, um registro de execução ou uma passagem posterior nunca o restringe a um commit exato; onde uma linha mais antiga diz o contrário, a correção posterior o substitui em vez de permanecer ao lado dele.

O registro sobrevive a cada passagem, incluindo as de manutenção, o mesmo em toda superfície (zheref/hatsu#529). Este parágrafo não amplia nenhuma das três linhas. Um pré-requisito fora da fila do seletor não é Coberto pela linha tipada: seu envio depende apenas das palavras do próprio mantenedor autorizando essa publicação (§ 1 da chamada, em suas próprias palavras), citadas como o segundo fato, no repositório de destino da execução — uma resposta aprovando apenas sua preparação não autoriza nenhum envio e é solicitada uma vez. A entrega de integração de uma execução ociosa permanece em futon § 5 (Não coberto acima); sua solicitação carrega os mesmos fatos e cita futon § 5 como sua autoridade. Um envio rotineiro que precisa da aprovação do host apresenta esse registro na solicitação — no Codex, a justificativa de sua rota de revisão suportada (docs/surfaces/codex.md § Solicitações de publicação) — para que um ator, árvore de trabalho ou commit alterado não seja motivo para perguntar ao mantenedor novamente; o que o host decide permanece do host. O registro é evidência para o revisor, nunca uma aprovação autoconcedida: um destino fora do escopo, a base protegida, uma reescrita ou um ato de release permanecem recusados ou atrás de seu próprio portão, e uma rejeição real é o próximo parágrafo. Os casos limitados estão em docs/ab/publication-authority.md.

Uma recusa do host permanece do host. Onde a camada de aprovação do harness recusa um envio dentro do escopo, a recusa é citada ao mantenedor com a invocação e o escopo e resolvida apenas através do caminho de aprovação suportado desse host — o ato do mantenedor: sua aprovação lá, ou um reenvio através da mesma rota carregando suas palavras recém-dadas citadas ao lado do registro (zheref/hatsu#529) — nunca uma nova tentativa com base apenas em evidências, nunca outro comando, rota ou superfície para o mesmo envio, nunca uma autorização mais ampla solicitada, nunca uma configuração de permissão tocada. Uma aprovação exata dada lá permanece um recibo válido para sua própria ação e não amplia nada.

Uma trajetória representativa. hatsu:kazaana zheref/nen → o aka do delegado publica pela primeira vez <model>/kurapika/<slug> no commit A → mukai abre o PR → en: um achado revisado é corrigido, kokusen commit B, murasaki envia B para o mesmo branch. Ambos os envios se baseiam na única linha tipada e nenhum pergunta; B enviado para qualquer outro branch está fora e depende da linha Não coberto.

As duas exceções permanecem separadas. Um passo then aka é o uso único da primeira exceção; a segunda cobre apenas os envios por esforço que o motor do composite faz. hatsu:aka autônomo permanece inalterado — uma chamada, uma execução (§ 1) — e nenhuma exceção atinge um merge em branch.base (o prompt de en § 5) ou um release (getsuga, mugetsu).

P1 se aplica — hatsu:ten aka, que atualiza os pré-requisitos desta fase (ten § 6) — e P2 pertence ao relatório antes do squash: o branch, limpo-ou-sujo, quantos commits não foram enviados e quais já estão no remoto. § 4 faz squash apenas de commits não enviados e esse limite é lido do remoto, nunca lembrado.

Nada mais muda. Aka ainda não executa testes de projeto e nem cobertura — hatsu:kotoamatsukami e hatsu:byakugan possuem esses no mukai — ainda para em G5 em uma verificação obrigatória vermelha e ainda nunca força push ou reescreve um commit já no remoto.

Devolução. Próximo na execução conectada: hatsu:mukai — revisão, testes impactados, cobertura, evidências e o PR. É sua para chamar, e esta execução não pergunta por ela.

---

1. Invocação — e quem tem permissão para dizê-la

hatsu:aka

Sem argumentos, então não há nada para nen parse possuir — e dizer isso é o ponto, não uma omissão. nen parse <skill> --grammar <template> --line <text> existe para uma gramática; um verbo simples não tem nenhuma, e inventar uma cláusula opcional para que uma análise possa ser ecoada seria cerimônia.

A chamada é do mantenedor, em suas próprias palavras ou por nome. Duas consequências, ambas vinculantes:

• Nenhum agente nunca a solicita. Nem hatsu:jutaisho no final de um turno, nem hatsu:spiritual-message em um relatório, nem um composite oferecendo-a como um próximo passo, nem uma opção letrada em uma parada. Um relatório pode dizer o branch está pronto para sair; ele não pode dizer devo enviá-lo? Um agente que pede permissão que lhe foi dito para esperar converteu uma chamada humana em um empurrão, e o empurrão é o que a disciplina de envio do plano local existe para prevenir.
• Uma chamada, uma execução. Um sim para este envio não é autoridade para o próximo. Diga que a execução começou e diga quando termina. A única chamada permanente é de um composite tipado, com escopo por destino (§ 0, segunda exceção: uma linha de futon ou kazaana, cujos esforços publicam através do build § 5); o envio de um build autônomo depende da delegação com escopo de execução do próprio build § 5, não desta exceção.

2. Os parâmetros — nen/workflow.json, com os padrões declarados

Chave	Usado para	Padrão quando a chave (ou o arquivo) está ausente
branch.base	a base contra a qual § 4 faz squash e § 5 faz catch-up	main
iteration.lane	qual lane § 3 e § 6 lint	project.defaultLane
commits.allowedAttributionTrailers	trailers canônicos de persona/plano que o commit pode carregar	Hatsu-Agent, Akatsuki-Agent
commits.forbiddenTrailers	trailers de atribuição que recusam o commit imediatamente	inclui Co-Authored-By, Claude-Session, Signed-off-by, Generated-by, Generated-with, Reviewed-by

nen schema check --repo <path> VALIDA este arquivo no build travado — verificado ao vivo, a linha lê ok nen/workflow.json coverage 80/85/90 (touched), branch '{model}/{persona}/{descriptor}' off 'main', checks: lint. Uma chave malformada é um FAIL por ponteiro, portanto esta habilidade não verifica mais a forma a olho; ela lê os valores e declara os padrões sempre que eles são o que se aplicou.

Um argumento ou item de configuração ausente é perguntado e configurado inline (missing-argument, missing-configuration; WORKFLOW.md § 4 Pergunte, configure, continue); um padrão acima que cobre a chave é usado e declarado, nunca perguntado. As recusas de § 4 não são lacunas: reescrever história publicada, um trailer proibido e um envio do tronco ainda recusam, nunca adivinhados.

Mudança declarada de claude/agents/kurapika.md § Como você trabalha — nomeada, não introduzida sorrateiramente. A definição do agente hoje diz "Sem atribuição de IA além dos trailers que o próprio harness do mantenedor exige — hoje Co-Authored-By: e Claude-Session: … você não adiciona atribuição própria nem remove a deles" e registra que a regra final é uma questão constitucional deixada em aberto. nen/workflow.json é onde o mantenedor responde por um determinado repositório, e este workflow responde: Hatsu-Agent e Akatsuki-Agent são admitidos, um por plano, e os outros dois são proibidos. Onde os dois discordam, o próprio bloco commits do repositório vence para aquele repositório, porque é a decisão registrada do mantenedor em vez de uma tensão não resolvida. Um repositório que não envia nenhum bloco commits obtém os padrões acima, e eles dizem a mesma coisa. Esta é uma mudança de processo declarada, divulgada aqui da mesma forma que hatsu:futon § Mudança de processo declarada divulga a sua.

3. Portão de lint pré-squash

Antes de nen wc squash poder reescrever até mesmo commits não publicados, execute a linha de lint declarada para iteration.lane:

nen shu lint --repo <path> --lane <iteration.lane> --dry-run
nen shu lint --repo <path> --lane <iteration.lane>

Dry-run uma vez em um repositório desconhecido. Um lint vermelho termina a execução antes que o histórico mude. Um assento é citado. Este portão está deliberadamente antes do squash; é barato e impede que aka substitua vários checkpoints úteis por um commit vermelho. É hatsu:gyo — o processo de linting — não o

…

[truncado para tradução]