feat(pipeline): implement F40 local run cancellation

.agents/skills/session-primer/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: session-primer
+description: Use esta skill no início de uma sessão para orientar o trabalho lendo memória persistente, estado do branch e feature atual. Não substitui `technical-triage` para priorização de backlog.
+---
+
+# Objetivo
+
+Iniciar ou retomar uma sessão de trabalho com contexto completo: quem é o usuário, o que está em andamento, onde o branch está e qual o próximo passo recomendado.
+
+# Quando esta skill deve ser usada
+
+Use esta skill quando:
+
+- for o início de uma nova sessão de trabalho
+- a sessão foi interrompida e o contexto ficou difuso
+- um agente novo assumiu o trabalho e precisa de orientação
+- o usuário pedir explicitamente para "resumir o estado" ou "qual é o próximo passo"
+
+# Quando esta skill NÃO deve ser usada
+
+Não use esta skill para:
+
+- priorizar backlog ou decidir qual feature atacar (use `technical-triage`)
+- registrar ou consolidar memória após a sessão (use `memory-curator`)
+- diagnosticar falhas de CI ou runtime (use `debug-failure`)
+- substituir a leitura completa de SPEC ou arquitetura quando a implementação exige isso
+
+# Processo
+
+Execute nesta ordem, sem pular etapas:
+
+## 1. Ler memória persistente
+
+```bash
+cat ~/.claude/projects/*/memory/MEMORY.md 2>/dev/null || echo "(sem memória persistente)"
+```
+
+Leia também os arquivos de memória referenciados no índice `MEMORY.md` que forem relevantes para a sessão atual.
+
+## 2. Ler contexto do projeto
+
+Leia nesta ordem:
+
+1. `CONTEXT.md`
+2. `CLAUDE.md` (seção de arquitetura e convenções)
+
+## 3. Inspecionar estado do Git
+
+```bash
+git log --oneline -10
+git status
+git diff --stat
+```
+
+Identifique:
+- branch atual e se há drift em relação a `origin/main`
+- arquivos modificados / não rastreados
+- feature em andamento (pelo nome do branch ou pela presença de `features/<feature>/`)
+
+## 4. Identificar feature ativa
+
+Se houver `features/<feature>/SPEC.md`, leia-a.
+
+Se houver `features/<feature>/NOTES.md` ou `features/<feature>/PENDING.md`, leia-os também.
+
+## 5. Produzir resumo de orientação
+
+Produza um resumo conciso com:
+
+- **Feature atual**: ID, título e estado no fluxo (`SPEC → TEST_RED → CODE_GREEN → ...`)
+- **Branch**: nome, commits recentes, drift estimado
+- **Próximo passo recomendado**: a etapa mais imediata do fluxo oficial de desenvolvimento
+- **Pendências abertas**: itens de `PENDING_LOG.md` ou memória que afetam a continuidade
+- **Alertas**: drift de branch, inconsistências detectadas, decisões abertas críticas
+
+# Restrições obrigatórias
+
+- Não tome decisões de backlog — apenas oriente.
+- Não edite código, testes ou SPEC durante esta skill.
+- Se o estado do branch indicar drift relevante em relação a `origin/main`, recomende `branch-sync-guard` antes de qualquer trabalho.
+- Se houver ambiguidade sobre qual feature está ativa, pergunte ao usuário antes de prosseguir.
+- Mantenha o resumo curto: o objetivo é orientar em segundos, não substituir a leitura completa dos artefatos.
+
+# Saída final esperada
+
+Entregue apenas:
+
+1. Resumo de orientação (feature, branch, próximo passo, pendências, alertas)
+2. Recomendação de skill a invocar em seguida

.agents/skills/spec-validator/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: spec-validator
+description: Use esta skill quando a tarefa for validar uma SPEC.md existente com `validate_spec_file()` antes de passar para TDD. Não use esta skill para editar a SPEC, implementar código ou validar qualidade de código.
+---
+
+# Objetivo
+
+Executar `validate_spec_file()` sobre a SPEC da feature atual, interpretar os erros retornados e garantir que a SPEC está pronta para alimentar `test-red`.
+
+# Leia antes de agir
+
+Leia nesta ordem:
+
+1. `docs/architecture/SPEC_FORMAT.md`
+2. `features/<feature>/SPEC.md`
+
+# Quando esta skill deve ser usada
+
+Use esta skill quando:
+
+- `spec-editor` produziu ou atualizou uma `SPEC.md`
+- a SPEC existe mas nunca foi validada programaticamente
+- um erro de validação bloqueou `test-red` ou `green-refactor`
+- for necessário confirmar que o YAML frontmatter e as seções obrigatórias estão corretos
+
+# Quando esta skill NÃO deve ser usada
+
+Não use esta skill para:
+
+- editar ou reescrever a SPEC (use `spec-editor`)
+- validar código, testes ou qualidade técnica (use `quality-gate`)
+- validar imagem Docker ou runtime (use `repo-preflight`)
+- resolver ambiguidades de requisito sem antes consultar o usuário
+
+# Restrições obrigatórias
+
+- Execute sempre com `uv run --no-sync` para não alterar o ambiente.
+- Nunca edite `SPEC.md` diretamente nesta skill — apenas reporte os erros.
+- Se a validação falhar, entregue a lista de erros completa e pare: não tente corrigir automaticamente sem instrução do usuário.
+- Trabalhe uma feature por vez.
+
+# Processo
+
+1. Identifique o caminho da SPEC: `features/<feature>/SPEC.md`.
+2. Execute:
+
+```bash
+uv run --no-sync python -c "
+from pathlib import Path
+from aignt_os.specs.validator import validate_spec_file
+result = validate_spec_file(Path('features/<feature>/SPEC.md'))
+print(result)
+"
+```
+
+3. Interprete a saída:
+   - Se `validate_spec_file` retornar sem exceção: SPEC válida — registre o resultado e sinalize que `test-red` pode prosseguir.
+   - Se levantar exceção ou retornar erros: liste cada erro com descrição clara do campo ou seção afetada.
+4. Não prossiga para testes ou código.
+
+# Erros comuns e como reportá-los
+
+| Erro | Significado | O que reportar |
+|---|---|---|
+| Campo YAML ausente | `id`, `type`, `summary`, `inputs`, `outputs`, `acceptance_criteria` ou `non_goals` faltando | Nome do campo ausente |
+| Seção de corpo ausente | `# Contexto` ou `# Objetivo` como H1 não encontrada | Nome da seção ausente |
+| Heading com nível errado | Seção obrigatória escrita como `##` em vez de `#` | Linha e nível encontrado vs. esperado |
+| YAML inválido | Frontmatter malformado | Mensagem de erro do parser |
+
+# Saída final esperada
+
+Entregue:
+
+1. Resultado bruto do comando (`print(result)`)
+2. Interpretação: SPEC válida ou lista de erros classificados
+3. Próximo passo recomendado: `test-red` se válida, ou `spec-editor` com lista de correções se inválida

.agents/skills/task-planner/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: task-planner
+description: Use esta skill quando a feature tiver 3 ou mais passos independentes e for necessário decompor os critérios de aceite em tasks atômicas rastreáveis via TaskCreate/TaskUpdate/TaskList. Não use para hotfixes simples nem para substituir `session-primer`.
+---
+
+# Objetivo
+
+Decompor os critérios de aceite de uma SPEC em tasks atômicas, criar essas tasks com `TaskCreate`, e manter o status de cada uma atualizado (`pending → in_progress → completed`) durante a execução.
+
+# Quando esta skill deve ser usada
+
+Use esta skill quando:
+
+- a feature tiver 3 ou mais passos independentes ou sequencialmente dependentes
+- a sessão for longa e a perda de contexto entre mensagens for um risco real
+- o usuário pedir explicitamente um plano de execução rastreável
+- `test-red` ou `green-refactor` precisarem coordenar múltiplos arquivos em ordem
+
+# Quando esta skill NÃO deve ser usada
+
+Não use esta skill para:
+
+- hotfixes ou mudanças diretas de 1–2 arquivos (custo de overhead supera o benefício)
+- substituir `session-primer` como orientação inicial da sessão
+- substituir `technical-triage` como priorização de backlog
+- rastrear tasks de outras features simultaneamente (trabalhe uma feature por vez)
+
+# Restrições obrigatórias
+
+- Crie tasks apenas para a feature ativa no momento.
+- Nunca misture tasks de features diferentes na mesma sessão.
+- Cada task deve ser atômica: um único critério de aceite ou um único arquivo-alvo.
+- Mantenha o status sempre atualizado — uma task nunca deve ficar em `in_progress` por mais de uma mensagem sem atualização.
+- Ao final da feature, marque todas as tasks como `completed` ou registre as que ficaram abertas em `PENDING_LOG.md`.
+
+# Processo
+
+## 1. Ler a SPEC
+
+Leia `features/<feature>/SPEC.md` e extraia:
+- lista de critérios de aceite (`acceptance_criteria`)
+- dependências entre critérios (se A deve preceder B)
+- fora de escopo (`non_goals`) — nunca crie task para itens fora de escopo
+
+## 2. Decompor em tasks atômicas
+
+Para cada critério de aceite, crie uma task descrevendo:
+- o que deve ser feito (ação concreta)
+- o arquivo ou módulo alvo, se identificável
+- o critério de aceite que a task satisfaz
+
+Agrupe critérios trivialmente relacionados em uma única task se fizerem sentido juntos (ex.: criar arquivo + adicionar import).
+
+## 3. Criar tasks com TaskCreate
+
+Use a ferramenta `TaskCreate` para cada task. Campos obrigatórios:
+- `name`: descrição curta e acionável (ex.: "Escrever teste RED para CancellationToken")
+- `description`: critério de aceite da SPEC que esta task satisfaz
+- Status inicial: `pending`
+
+## 4. Apresentar o plano ao usuário
+
+Liste as tasks criadas com IDs e status. Aguarde confirmação antes de iniciar execução.
+
+## 5. Executar e manter status
+
+Durante a execução da feature (em conjunto com `test-red`, `green-refactor` etc.):
+
+- Antes de iniciar uma task: `TaskUpdate` → `in_progress`
+- Ao concluir uma task: `TaskUpdate` → `completed`
+- Se uma task for bloqueada: registre o bloqueio na descrição e marque como `pending` novamente com nota
+
+## 6. Encerrar o plano
+
+Ao final:
+1. Liste todas as tasks com status final via `TaskList`.
+2. Tasks `completed`: confirmadas.
+3. Tasks `pending` ou `in_progress` remanescentes: registre em `PENDING_LOG.md`.
+
+# Saída final esperada
+
+Entregue:
+
+1. Lista de tasks criadas (ID, nome, status)
+2. Sequência de execução recomendada
+3. Dependências explícitas entre tasks, se houver
+4. Próxima skill a invocar para iniciar execução (geralmente `test-red`)

.claude/agents/explorer.md

@@ -0,0 +1,31 @@
+---
+name: explorer
+description: Explorador read-only da arquitetura do AIgnt OS. Mapeia arquivos afetados, ADRs, SPECs e dependências operacionais antes de qualquer edição de código.
+model: claude-sonnet-4-6
+disallowedTools:
+  - Write
+  - Edit
+  - MultiEdit
+maxTurns: 30
+---
+
+Fique em modo de exploração.
+
+Seu papel é mapear os caminhos de código reais, arquivos, símbolos, ADRs, SPECs,
+scripts e dependências operacionais envolvidos na tarefa antes que alguém edite código.
+
+Prioridades:
+1. Identificar entry points, módulos afetados, contratos, testes e docs.
+2. Citar arquivos e símbolos concretos.
+3. Distinguir fatos de arquitetura de suposições.
+4. Preferir leitura direcionada a varreduras amplas.
+5. Escalar ambiguidade cedo.
+
+Não implemente mudanças.
+Não proponha grandes reescritas a menos que o agente pai pedir explicitamente.
+
+Leia antes de agir:
+1. AGENTS.md
+2. CONTEXT.md
+3. docs/architecture/SDD.md
+4. features/<feature>/SPEC.md se a tarefa for específica de uma feature

.claude/agents/monitor.md

@@ -0,0 +1,26 @@
+---
+name: monitor
+description: Monitor operacional para comandos longos, logs, evidências de CI, verificações de runtime e captura de falhas.
+model: claude-sonnet-4-6
+maxTurns: 50
+---
+
+Você é um monitor operacional.
+
+Seu papel é:
+- executar ou observar comandos longos
+- coletar logs e evidências de runtime
+- resumir falhas de CI ou locais
+- acompanhar estado de preflight/runtime
+- reportar passos precisos de reprodução e resultados
+
+Prefira captura de evidências a interpretação.
+Não edite código da aplicação a menos que o agente pai reatribua a tarefa explicitamente.
+Não oculte falhas parciais.
+
+Comandos úteis neste repositório:
+- ./scripts/docker-preflight.sh
+- ./scripts/branch-sync-check.sh
+- ./scripts/commit-check.sh --no-sync
+- uv run --no-sync python -m pytest
+- git status / git diff --stat / git log --oneline -10

.claude/agents/reviewer.md

@@ -0,0 +1,35 @@
+---
+name: reviewer
+description: Revisor read-only focado em correção, regressões, segurança, cobertura de testes e risco de débito técnico.
+model: claude-sonnet-4-6
+disallowedTools:
+  - Write
+  - Edit
+  - MultiEdit
+maxTurns: 30
+---
+
+Revise como dono do código.
+
+Foco em:
+- correção
+- regressões
+- cobertura de testes faltante
+- segurança
+- risco operacional
+- débito técnico introduzido pelo patch
+
+Lidere com achados concretos.
+Prefira evidência a comentários de estilo.
+Sinalize o que bloqueia, o que é arriscado e o que é aceitável com follow-up.
+
+Não edite código.
+Não se prenda a detalhes de formatação.
+
+Leia antes de agir:
+1. AGENTS.md
+2. CONTEXT.md
+3. docs/architecture/SDD.md
+4. docs/architecture/TDD.md
+5. features/<feature>/SPEC.md se a tarefa for específica de uma feature
+6. git diff da mudança atual

.claude/agents/worker.md

@@ -0,0 +1,32 @@
+---
+name: worker
+description: Agente de implementação para mudanças pequenas e focadas, após a tarefa estar entendida e escopo definido.
+model: claude-sonnet-4-6
+maxTurns: 50
+---
+
+Implemente mudanças de escopo restrito após a tarefa ser entendida.
+
+Regras:
+- siga o fluxo do repositório definido em AGENTS.md
+- mantenha edições pequenas e reversíveis
+- não expanda escopo
+- preserve design CLI-first, spec-first e feature-by-feature
+- não contorne gates obrigatórios
+- prefira a mudança mínima que satisfaz a SPEC e os testes
+
+Antes de editar:
+- confirme os arquivos-alvo
+- confirme os critérios de aceite
+- confirme os testes relevantes
+
+Após editar:
+- resuma o que mudou
+- liste as validações executadas
+- reporte riscos residuais
+
+Leia antes de agir:
+1. AGENTS.md
+2. CONTEXT.md
+3. features/<feature>/SPEC.md
+4. testes relevantes