Skill: kata — Karpathy Development Cycle

Você está executando o kata (型, "forma/padrão"), que orquestra o
Karpathy Development Cycle — um ciclo de 9 fases (+ judge opcional) para
garantir qualidade de código antes de commitar.

Esta skill é a versão para Claude Code do agente @kata do OpenCode. A
lógica de verificação (lint + teste + coverage + judge adversarial) vive no
pacote Python kata (pip install -e . neste repo), reutilizado por ambas
as versões — só a camada de orquestração/interação muda.

Filosofia

O kata combina duas influências complementares:

1. Karpathy Development Cycle (Andrej Karpathy): pensar antes de codar,
   manter o código mínimo, fazer mudanças cirúrgicas e verificar com critérios
   objetivos. Como um kata marcial, é uma sequência disciplinada e repetível.
2. The Fable Method (Sahir619/fable-method): classificar a tarefa antes de
   agir, definir "pronto" com verificação nomeada, reunir evidências em paralelo,
   mudar o mínimo, verificar por observação e reportar resultado primeiro.
   O fit gate e o triviality gate do kata são adaptações diretas do fable-method.

As Fases

FIT → THINK → SIMPLIFY → INTENT → SURGICAL → VERIFY → TWIN CHECK → ARTIFACT → REPORT
                                                                  ↓ (opcional)
                                                                JUDGE

Fase	Objetivo
FIT	Classificar a tarefa e aplicar triviality gate antes de investir esforço
THINK	Declarar problema, assumptions, alternativas e unknowns antes de codar
SIMPLIFY	Verificar se o código é mínimo — sem abstrações especulativas
INTENT	Verificar alinhamento entre código, teste e spec antes de mudar comportamento
SURGICAL	Validar arquivo-por-arquivo que cada mudança rastreia ao pedido
VERIFY	Rodar ruff + pytest + coverage (gate ≥ 70%) e checar critério de sucesso
TWIN CHECK	Se um defeito foi corrigido, buscar o mesmo padrão no projeto inteiro
ARTIFACT	Verificar que todas as linhas devidas (INTENT/AUTH/PENDING/TWINS) estão presentes
REPORT	Relatório outcome-first: resultado na primeira linha, verificações, caveats honestos, INTENT/AUTH/PENDING/TWINS lines
JUDGE (opcional)	Verificação adversarial — re-executa verificações, caça 7 tipos de fraude, entrega veredito VERIFIED/CAVEATS/UNVERIFIABLE/REFUTED

A fase FIT é inspirada no triviality gate e fit gate; a fase JUDGE
é inspirada no fable-judge do
The Fable Method, que prova
empiricamente que classificar a tarefa antes de agir reduz falhas procedurais
em agentes de código.

Ferramentas

Mapeamento de ferramentas do Claude Code para cada tarefa do kata:

Tarefa	Ferramenta	Uso
Carregar instruções da fase	Skill	kata-fit, kata-question, kata-think, kata-simplify, kata-intent, kata-surgical, kata-verify, kata-artifact, kata-report, kata-judge
Carregar adapter de domínio	Skill	kata-devops, kata-data-analysis, kata-research, kata-docs
Perguntar ao usuário	Texto livre (aberta) ou AskUserQuestion (fechada) + kata-question	Uma pergunta por vez; consulte a skill kata-question para a regra de qual ferramenta usar
Executar comandos	Bash	git diff, ruff, pytest, python -m kata --check-only etc.
Ler arquivos	Read	Inspecionar diff/código de arquivos específicos
Buscar no código	Grep / Glob	Encontrar callers, imports, patterns, arquivos
Editar arquivos	Edit	Aplicar correções pontuais
Criar/escrever YAML	Write	Criar/atualizar .kata/<task>.yaml
Rastrear progresso (opcional)	TaskCreate / TaskUpdate	Visualizar as 9 fases como uma lista de tarefas na UI — suplementar, não substitui o YAML

Regra: em cada fase, carregue primeiro a skill correspondente com Skill
e siga suas instruções. Esta skill é a orquestração; as demais
skills kata-* contêm o detalhe de cada fase.

Compatibilidade operacional

O kata deve funcionar em Linux, macOS e Windows. Trate os caminhos como
relativos à raiz do projeto e use Read, Write, Edit e Glob para
arquivos sempre que possível; não construa caminhos concatenando
separadores manualmente. Ao executar comandos com Bash, use a sintaxe do
shell hospedeiro. Para Python, prefira python -m ...; no Windows, use
py -m ... se python não estiver disponível. Não presuma que bash,
python3, make ou comandos POSIX existam no Windows; se uma verificação
não puder ser executada nativamente, registre o bloqueio como caveat em vez
de declarar sucesso.

Preflight — as skills de fase estão instaladas?

O orquestrador não é auto-contido: cada fase carrega a skill
correspondente e segue as instruções dela. Se uma skill não carregar e você
improvisar a fase a partir do nome, o .kata/<task>.yaml sai preenchido sem
nada por trás — a "fase fingida" que o --audit existe para caçar, só que
produzida pelo ferramental em vez do agente. É a pior falha possível, porque
é silenciosa: nada no output distingue isso de trabalho de verdade.

Antes de começar o ciclo, rode python -m kata --doctor via Bash (ou
py -m kata no Windows). Exit 1 significa instalação parcial — pare e
peça ao usuário que rode make reinstall ou make reinstall-claude-code.
Instalação ausente por completo não é erro: quem só usa o CLI nunca instalou
frontend nenhum.

Se uma chamada de Skill falhar durante o ciclo:

1. Não improvise. Não escreva a seção da fase como se a tivesse seguido.
2. Use o contrato mínimo abaixo — o suficiente para não pular a fase em
   silêncio, e deliberadamente menos do que a skill entregaria.
3. Acrescente o nome da skill a preflight.skills_missing no YAML.
4. Diga no relatório final quais fases rodaram sem instrução própria.

Contrato mínimo de cada fase

Isto é o piso para quando a skill não carregar, nunca um substituto para
carregá-la. Reparar que VERIFY e JUDGE degradam bem: a lógica deles vive no
pacote Python, e não no texto da skill.

Fase	Piso, se a skill não carregar
FIT	Medir o diff, decidir trivialidade e rota, gravar fit.route e fit.reason
THINK	Perguntar problema, assumptions, alternativas, unknowns e o critério done; gravar em think
SIMPLIFY	Confrontar o diff com o pedido: código mínimo, sem abstração especulativa nem configurabilidade não solicitada
INTENT	Ler código, teste e spec; se discordarem, resolver por usuário > spec > teste > código antes de editar
SURGICAL	Confirmar arquivo por arquivo que a mudança rastreia ao pedido; conferir imports órfãos
VERIFY	python -m kata --check-only — a lógica é do CLI
TWIN CHECK	Se um defeito foi corrigido, buscar o mesmo padrão no projeto inteiro com Grep
ARTIFACT	Conferir as linhas devidas: INTENT, AUTH, PENDING, TWINS
REPORT	Resultado na primeira linha, verificações, caveats honestos, linhas devidas
JUDGE	python -m kata --task <name> --judge — a lógica é do CLI

Diretório de Trabalho

Use .kata/ na raiz do projeto atual. Cada tarefa é um arquivo
.kata/<task>.yaml com o schema:

task: nome-da-tarefa
status: draft | think-complete | approved | rejected
domain: coding        # coding | devops | data-analysis | research | docs
                      # default: coding; outras domains carregam um adapter
done: ""              # Fable Step 1: critério de sucesso declarado no THINK,
                      # ANTES da evidência; exibido no VERIFY e no relatório
base_commit: ""       # HEAD do git no início da tarefa; usado pelo JUDGE
                        # para comparar mesmo depois que a tarefa é commitada.
                        # O CLI também ancora este SHA em refs/kata/base/*;
                        # divergência entre YAML e Git invalida o JUDGE.
approved_commit: ""   # R14: HEAD no momento da aprovação. O JUDGE diffa
                        # base_commit..approved_commit em vez de base_commit..HEAD,
                        # então arquivos alterados por tasks POSTERIORES não
                        # contam como "não declarados" para esta. Ausente em
                        # tasks antigas (aprovadas antes desta rodada) — elas
                        # continuam diffando até HEAD. Não é gravado enquanto
                        # o HEAD ainda é o base_commit (aprovação antes do
                        # commit): teto igual ao piso é janela de diff vazia.
fit:
  trivial: false
  route: code-loop     # code-loop | plan-first | question | research | inference
  reason: ""
  answered: false      # grave true ao concluir o FIT, senão ele repergunta
                       # a cada retomada da tarefa
  skipped: false       # true só se a fase foi preenchida com default sem
                       # ninguém responder (modo não-interativo)
think:
  problem: ""
  assumptions: []
  alternatives: []
  unknowns: ""
  answered: false
  skipped: false
simplify:
  minimum_code: true
  no_single_use_abstractions: true
  no_speculative_config: true
  notes: ""            # observações opcionais do SIMPLIFY (só se preenchidas)
  answered: false       # true ao concluir a fase; false se foi preenchida
                        # com default sem ninguém responder
  skipped: false        # true só no modo não-interativo
intent:
  code_does: ""
  check_expects: ""
  spec_says: ""
  all_agree: true
  conflict_resolution: ""  # como o conflito código/teste/spec foi resolvido
                        # (só se all_agree for false)
  answered: false
  skipped: false
surgical:
  files: []
  removed_imports_clean: true
  answered: false       # true ao concluir a fase; false se foi preenchida
                        # com default sem ninguém responder
  skipped: false        # true só no modo não-interativo
verify:
  ruff_clean: true
  tests_pass: true
  coverage_pct: 0.0
  coverage_pass: false
  success_criteria_met: false
  attempts: 0          # Fable Step 5: contador de execuções do VERIFY; ao
                       # chegar em MAX_VERIFY_ATTEMPTS (3) com falha, hand back
  hand_back: false     # true quando N tentativas falharam — tarefa devolvida
                       # ao usuário com o que foi tentado, o output real e a
                       # hipótese atual
preflight:
  skills_missing: []    # skills de fase que não carregaram nesta execução.
                        # Fase rodada sem a instrução dela é fase degradada,
                        # não fase seguida — o --audit a gradua como tal
artifact:
  intent_owed: true
  intent_present: true
  auth_owed: false
  auth_present: true
  pending_owed: false
  pending_present: true
  twins_owed: false
  twins_present: true
auth:
  action_taken: false
  authorized: false
  action: ""           # o que foi feito
  quote: ""            # citação exata da autorização; sem ela a linha AUTH
                       # não é emitida, mesmo com authorized: true
pending:
  action: ""
  documented: false
twins:
  pattern: ""
  result: ""
  searched: false
  defect_fixed: false   # é ISTO que o gate TWINS lê para saber que houve
                        # correção de defeito; sem esta chave o gate nunca
                        # dispara, porque "verificações passaram" não é
                        # evidência de defeito corrigido
  matches_count: 0      # preenchidas pelo TWIN CHECK após a busca
  files_count: 0
  fix_applied: false

Parsing de Argumentos

Inicialização obrigatória do estado

Antes de ler ou escrever qualquer arquivo de tarefa, garanta que .kata/
existe, usando Bash com o comando adequado ao shell hospedeiro (conforme a
seção "Compatibilidade operacional" acima):

• POSIX (Linux/macOS): mkdir -p .kata
• Windows PowerShell: New-Item -ItemType Directory -Force .kata

Esta etapa é obrigatória em todos os modos (--init, --check-only,
--judge, --report, --audit, --plan, --task, e modo padrão).

Se esta skill foi invocada com argumentos (via /kata --init nome-da-tarefa
ou equivalente), analise-os antes de executar qualquer comando. Se foi
invocada sem argumentos, trate como o modo padrão. Mapeamento:

Input	Modo	Ação
--init <task>	--init	Use Write para criar .kata/<task>.yaml com template (inclua base_commit), depois execute FIT + THINK e salve
--check-only	--check-only	Pule FIT/THINK/SIMPLIFY/SURGICAL; execute VERIFY via Bash (python -m kata --check-only, ou py -m kata no Windows) e reporte
--plan <task>	--plan	Crie/carregue task, execute FIT + THINK, salve o plano e pare (equivalente ao plan-first do fable-method)
--task <name>	--task	Carregue .kata/<name>.yaml com Read e continue o ciclo a partir do status atual
--judge	--judge	Carregue a task (por branch ou --task), execute verificação adversarial (re-executa checks, caça fraudes)
--report	--report	Carregue a task (por branch ou --task), gere relatório outcome-first
--audit [--task <name>]	--audit	Carregue a task e gradue as fases como followed / skipped / faked / degraded, com o risco concreto de cada skip/fake (fable-method audit)
(sem args)	padrão	Detecte task via branch git (Bash) ou pergunte ao usuário, FIT + ciclo completo

Para --init, você pode também usar Bash para rodar
python -m kata --init <task> (ou py -m kata no Windows), mas depois deve
carregar o YAML e prosseguir com THINK interativamente.

Detecção de Task

Antes de qualquer fase, confira a instalação (ver Preflight acima).

Se nenhum --task for fornecido:

1. Tente detectar o branch git atual via Bash: git rev-parse --abbrev-ref HEAD
2. Normalize: substitua / e _ por -
3. Se existir .kata/<branch>.yaml, retome essa tarefa
4. Caso contrário, liste tarefas existentes em .kata/ e pergunte ao usuário
5. Se não houver tarefas, pergunte o nome da nova tarefa

Fluxo de Execução

Fase 0: FIT

1. Carregue a skill kata-fit com Skill.
2. Execute git diff HEAD --stat via Bash para incluir alterações staged e
   unstaged; se não houver HEAD, use os diffs local e staged.
3. Classifique a tarefa (com kata-question para envolver o usuário):
   • A tarefa é trivial (1 arquivo, <10 linhas, sem busca)? Se sim, vá direto a VERIFY.
   • Qual a rota da tarefa: code-loop, plan-first, question, research, inference?
4. Se for question: carregue kata-question, investigue, entregue achados + recomendação, não altere código sem autorização, PARE.
5. Se for plan-first: execute só THINK, entregue um plano, PARE.
6. Registre a classificação em .kata/<task>.yaml sob a chave fit, e grave base_commit (HEAD atual) se ainda não estiver registrado.

Fase 0.5: Domain Adapter

Após o FIT, se o .kata/<task>.yaml declarar domain diferente de coding
(ex.: domain: devops), carregue o adapter correspondente com Skill:

• domain: devops → kata-devops
• domain: data-analysis → kata-data-analysis
• domain: research → kata-research
• domain: docs → kata-docs

O adapter define:

1. Evidência: o que abrir antes de agir.
2. Autoridade: quem decide o correto no domínio.
3. Verify by observation: como confirmar que a ação funcionou.
4. Fraud table: fraudes específicas do domínio.
5. Minimum evidence set (binding): checklist obrigatório antes de agir.
6. Rotas FIT por shape: quando cada rota se aplica no domínio.

Domain skills são opcionais. Se Skill falhar:

• Não improvise o conteúdo do adapter.
• Registre o nome da skill em preflight.skills_missing.
• Aplique o contrato mínimo descrito no adapter (evidência, autoridade,
  red lines) com o bom senso do domínio.
• Diga no relatório final que o adapter não carregou.

Fase 1: THINK

1. Carregue a skill kata-think com Skill.
2. Pergunte, em texto livre e uma de cada vez (ver kata-question):
   • "Qual o problema exato que estou resolvendo?"
   • "Quais assumptions estou fazendo? (separadas por ;)"
   • "Quais alternativas considerei? (separadas por ;)"
   • "O que NÃO sei? (preciso perguntar antes?)"
   • "O que é 'pronto'? (critério de sucesso + como vou verificar)" — Fable
     Step 1: defina done ANTES da evidência e grave em done. O VERIFY
     confronta este critério com o resultado final.
3. Registre as respostas no .kata/<task>.yaml sob a chave think
4. Atualize status para think-complete
5. Se houver unknowns que podem ser investigados no código, faça-o (Grep/Read)
   — budget de investigação (Fable Step 5): 2 buscas/lookups consecutivos
   sem resultado → pare de procurar e pergunte ao usuário em vez de continuar
   vasculhando.
6. Salve o arquivo e prossiga

Fase 2: SIMPLIFY

1. Carregue a skill kata-simplify com Skill.
2. Execute git diff --stat (ou git diff --cached --stat se vazio)
3. Mostre o diff ao usuário
4. Pergunte via AskUserQuestion (fechada, ver kata-question):
   • "O código mínimo resolve o problema?"
   • "Alguma abstração é para uso único?"
   • "Existe configurabilidade/flexibilidade não solicitada?"
   • Observações (opcional, texto livre)
5. Analise o diff você mesmo procurando anti-patterns (YAGNI, premature abstraction)
6. Registre as respostas no YAML sob simplify

Fase 2.5: INTENT

1. Carregue a skill kata-intent com Skill.
2. Abra o código, o teste e a spec/README/docstring dos arquivos a alterar (Read).
3. Determine ou pergunte:
   • O que o código FAZ hoje?
   • O que o teste/check ESPERA?
   • O que a especificação DIZ?
4. Se os três discordam, resolva o conflito pela ordem de autoridade:
   usuário > spec > testes > código (use AskUserQuestion para escolher a resolução). Não edite até resolver.
5. Registre o intent gate no .kata/<task>.yaml.

Fase 3: SURGICAL

1. Carregue a skill kata-surgical com Skill.
2. Execute git diff --name-only (ou git diff --cached --name-only)
3. Para cada arquivo, pergunte: "<arquivo> — necessário para esta tarefa?" (AskUserQuestion se poucos arquivos, texto livre listando todos se forem muitos)
4. Recall Gate: antes de usar qualquer API/endpoint/config de memória,
   abra a fonte real (docstring, docs, lib source) com Read. Se não acessível, marque
   como low-confidence no relatório.
5. Verifique imports órfãos: ruff check --select F401 <paths> via Bash
6. Pergunte: "Imports removidos são só os que sua mudança tornou inúteis?"
7. Registre a lista de arquivos com necessary: true/false no YAML sob surgical

Fase 4: VERIFY

1. Carregue a skill kata-verify com Skill.

2. Leia .kata/config.yaml primeiro. Se declarar verify.lint,
   verify.test ou verify.coverage, use aqueles comandos verbatim no papel
   correspondente — eles substituem os defaults Python abaixo, e as flags de
   caminho daquele papel deixam de valer. verify.gate e
   verify.coverage_pattern valem junto. Rodar kata --check-only já faz
   tudo isso sozinho. Se o projeto não for Python e não houver config, não
   invente comando: proponha criar o arquivo e registre o bloqueio como
   caveat — verificação que não rodou não é verificação que passou.

3. Lint (default): python -m ruff check <paths> via Bash (ou py -m ruff no Windows)

   • Paths padrão: src/ tests/. Adapte ao projeto (ex: app/ services/ tests/)
   • OK se returncode == 0
   • Se falhou, mostre o output completo

4. Teste (default): python -m pytest <test_paths> --tb=short -q (ou py -m pytest no Windows)

   • Test paths padrão: tests/. Adapte ao projeto
   • Se houver arquivos que precisam de --ignore, inclua-os
   • OK se returncode == 0
   • Se falhou, mostre o output completo

5. Coverage (default): python -m pytest <test_paths> --cov=<source> --cov-report=term-missing --cov-fail-under=70 -q (ou py -m pytest no Windows)

   • Source padrão: src. Adapte ao projeto (ex: app)
   • O --cov-fail-under já garante que o gate seja verificado pelo pytest-cov
   • Extraia o percentual do output para exibição (regex: TOTAL\s+\d+\s+\d+\s+(\d+)%)
   • Gate: 70%. OK se returncode == 0 (já inclui o gate)

6. Critério de sucesso: confronte o critério declarado no THINK (done)
   com o resultado final e pergunte ao usuário via AskUserQuestion
   "O critério de sucesso da tarefa está satisfeito?"

   • Em modo --check-only, assuma satisfeito

7. Hard bound (Fable Step 5): registre verify.attempts (contador de
   execuções do VERIFY). Após 3 tentativas falhas, grave verify.hand_back: true e devolva a tarefa ao usuário com o que foi tentado, o output real
   e a hipótese atual — não fique repetindo o mesmo fix-verify.

8. Calcule o resultado final:

   • Aprovado se: ruff ✅ AND pytest ✅ AND coverage ✅ AND sucesso ✅
   • Rejeitado caso contrário

9. Atualize status para approved ou rejected no YAML

Fase 4.2: TWIN CHECK

Executar depois do VERIFY e antes do ARTIFACT, e só se a tarefa foi
aprovada. Quando um defeito é corrigido, o mesmo padrão costuma existir em
outros lugares — foi assim que vários defeitos deste projeto reapareceram
depois de "corrigidos" num único ponto.

1. Determine se um defeito foi corrigido. Se o intent gate registrou
   discordância (intent.all_agree: false), a resposta já é sim. Caso
   contrário, pergunte ao usuário com AskUserQuestion.
2. Se não houve correção de defeito, grave twins.defect_fixed: false e siga
   para o ARTIFACT. Gravar a resposta importa: é a única evidência de que
   a pergunta foi feita, e sem ela o gate TWINS não consegue distinguir "não
   houve defeito" de "ninguém verificou".
3. Se houve, pergunte qual padrão buscar (regex) e rode a busca com Grep
   no projeto inteiro.
4. Mostre as ocorrências, pergunte se deseja corrigi-las agora, e registre:

twins:
  pattern: "assert True"
  result: "3 arquivo(s), 7 ocorrência(s)"
  searched: true
  defect_fixed: true
  matches_count: 7
  files_count: 3
  fix_applied: false

O CLI não edita as ocorrências do TWIN CHECK. fix_applied: true só pode ser
gravado por um host que tenha feito e verificado a edição de fato.

Fase 4.5: ARTIFACT

1. Carregue a skill kata-artifact com Skill.
2. Verifique se as linhas devidas estão no relatório:
   • INTENT: comportamento mudou? Intent gate está registrado?
   • AUTH: ação irreversível? Autorização do usuário documentada?
   • PENDING: docs prescrevem follow-up? Ação não tomada documentada?
   • TWINS: defeito corrigido? Varredura de padrão recorrente registrada?
3. Se alguma linha devida está ausente, adicione-a ou marque como ressalva.
4. Registre o resultado no .kata/<task>.yaml.

Fase 5: REPORT

1. Carregue a skill kata-report com Skill.
2. O relatório é gerado automaticamente ao final do ciclo completo.
3. Para regenerar: python -m kata --task <name> --report via Bash (ou py -m kata no Windows).
4. Verifique se o relatório contém:
   • Outcome first: primeira linha = resultado
   • O que foi feito: problema e arquivos alterados
   • INTENT line: se comportamento mudou
   • Verificações: ruff, pytest, coverage, critério de sucesso
   • Caveats: o que está pendente, fraco, ou não verificado
   • AUTH/PENDING/TWINS lines: se devidas
5. Hostile-reviewer reread: releia o relatório como revisor hostil.
   • Alguma claim não verificada?
   • Resposta no formato errado?
   • Algo tocado fora do escopo?

Fase 6: JUDGE (opcional — adversarial verification)

1. Carregue a skill kata-judge com Skill.

2. Verifique se status é approved (julgar só tarefas concluídas).

3. Execute o judge: python -m kata --task <name> --judge via Bash (ou py -m kata no Windows).

4. Interprete o veredito:

   • VERIFIED → nenhuma fraude, e o juiz teve como procurar
   • VERIFIED WITH CAVEATS → fraudes leves/médias; ressalvas documentadas
   • UNVERIFIABLE → nenhuma fraude, mas o juiz não teve como observar
     (nada re-executado, ou teste em linguagem que ele não lê). Não
     reporte como sucesso: diga ao usuário o que ficou sem verificação
   • REFUTED → fraude de alta severidade; ciclo precisa ser revisto
   • O baseline precisa resolver, ser ancestral do HEAD e coincidir com a
     âncora Git criada no início; se a âncora faltar, o resultado é no máximo
     UNVERIFIABLE.

5. Se REFUTED, investigue as fraudes apontadas:

   • Weakened checks: revise asserts removidos/relaxados em testes
   • False completion: re-execução falhou — corrija e reexecute
   • Scope creep: arquivos não declarados — reverta ou justifique
   • Unauthorized action: ação externa sem AUTH — documente ou reverta
   • Spec betrayal: discordância de INTENT aprovada sem resolução — volte ao INTENT, resolva o conflito com o usuário pela ordem de autoridade e só então reaprove. Não escreva conflict_resolution depois do veredito só para limpá-lo: o juiz aceita o texto sem verificar, e isso seria a fraude que ele caça
   • Debris: limpe arquivos temporários, debug prints, TODOs

6. Registre o resultado no .kata/<task>.yaml sob chave judge.

7. Mostre o resumo final:

✅ ruff limpo
✅ pytest 850 passaram
✅ coverage 87.0% (gate: 70%)
✅ critério de sucesso satisfeito

┌──────────────────────────────────────────────────────────┐
│  ✅  KATA CYCLE — APROVADO                               │
└──────────────────────────────────────────────────────────┘

Adaptação ao Projeto

O kata é genérico, mas precisa saber a estrutura do projeto para rodar
verificações corretas. Detecte automaticamente:

Se existir...	Use para ruff	Use para pytest	Use para coverage
src/	src/ tests/	tests/	--cov=src
app/ + services/	app/ services/ tests/	tests/unit/	--cov=app
app/	app/ tests/	tests/	--cov=app

Se houver pyproject.toml ou setup.cfg, leia-o (Read) para identificar:

• [tool.ruff] → caminhos padrão
• [tool.pytest] → testpaths
• [tool.coverage.run] → source

Persistência

Após cada fase, escreva/atualize .kata/<task>.yaml com os resultados
(via Write/Edit). Isso permite retomar uma tarefa interrompida.

Use o formato YAML (se PyYAML disponível) ou JSON como fallback — o mesmo
comportamento do CLI kata.

Modo Não-Interativo

Em execução não interativa (por exemplo, --check-only, CI, ou uma sessão
sem canal para perguntar), pule THINK/SIMPLIFY/SURGICAL preenchendo com
defaults, marque as fases com skipped: true e execute só VERIFY. Não
presuma que a sessão é não-interativa sem evidência clara (ex.: a flag
--check-only), e não use a presença de TTY como prova de que as perguntas
podem ser respondidas; se puder perguntar, pergunte normalmente.

Comportamento Importante

• Propose, don't interrogate: se o usuário não sabe uma resposta, proponha baseando-se no contexto do código
• Investigue unknowns: se o usuário declara um unknown sobre o código, investigue com Grep/Read antes de perguntar
• Seja específico: rejeite respostas vagas em THINK — peça especificidade
• Não pule fases: cada fase existe por uma razão. Mesmo que pareça redundante, execute-a
• Exceção: triviality gate: se FIT classificar como trivial (1 arquivo, <10 linhas, sem busca), pule THINK/SIMPLIFY/SURGICAL e vá direto a VERIFY + reporte em 2 frases
• Exit code: em modo --check-only, o CLI Python (python -m kata --check-only) termina com status apropriado (aprovado/rejeitado); esta skill em si não tem exit code, apenas reporta o resultado
• Português BR: todas as interações com o usuário em português brasileiro