jarvis-ai-framework 1.0.0

package/skills/eng-security-patch/SKILL.md

@@ -0,0 +1,378 @@
+---
+name: eng-security-patch
+description: Gera diffs candidatos para achados confirmados de segurança. Consome triage.json (preferencial) filtrado por status == "confirmed". Executa 1 subagente de patch por achado + 1 reviewer independente por diff (sem ver a prosa do finding). Escreve PATCHES/bug_NN/{patch.diff,patch_result.json}, PATCHES.md e PATCHES.json como texto inerte para revisão humana — nunca aplica diffs. Usar quando pedido "gerar fixes", "patch dos achados", "fechar o loop do triage", "gerar correções candidatas".
+argument-hint: "<triage.json> [--repo PATH] [--top N] [--id F-NNN] [--fresh]"
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Write
+  - Task
+  - AskUserQuestion
+  - Bash(git log:*)
+---
+
+# eng-security-patch
+
+Terceira peça do pipeline estático (`/eng-threat-model` → `/eng.security-audit` → `/eng-security-triage` → `/eng-security-patch`).
+Transforma uma lista ranqueada de achados verificados em diffs candidatos.
+
+O skill **nunca aplica um diff** ao repositório-alvo. O output é texto inerte em `./.security/outputs/PATCHES/` para o TL revisar e aplicar fora de banda. Não existe flag `--apply` ou `--approve` por design: a capacidade está ausente e portanto não pode ser prompt-injetada.
+
+**Argumentos** (parsear de `$ARGUMENTS`):
+- `<triage.json>` (posicional, obrigatório): `triage.json` filtrado por `status == "confirmed"`. Aceita `security-findings.json` com warning.
+- `--repo PATH`: codebase-alvo, read-only (default: cwd). O skill para se os arquivos citados não resolverem sob esse path.
+- `--top N`: patchar apenas os N achados de maior severidade.
+- `--id F-NNN`: patchar apenas o achado com este id.
+- `--fresh`: ignorar checkpoint `.security/state/patch-state.json` e recomeçar do zero.
+
+**Escopo de Write.** A ferramenta Write pode escrever SOMENTE em `./.security/outputs/PATCHES/` e `./.security/state/`. Nunca escrever em `--repo`, nunca `git apply`, nunca `patch`, nunca editar código-alvo.
+
+---
+
+## Checkpointing (`.security/state/patch-state.json`)
+
+Estado persiste em `.security/state/patch-state.json` para que uma nova sessão `/eng-security-patch` retome sem re-spawnar subagentes.
+
+**Formato do estado:**
+```json
+{
+  "status": "running|complete",
+  "phase_done": 0,
+  "args": { "repo": ".", "top": null, "id": null, "findings_path": "triage.json" },
+  "findings": [],
+  "patches": []
+}
+```
+
+**Início da execução:**
+- Read `.security/state/patch-state.json` se existir.
+- Se `status == "complete"` OU arquivo ausente OU `--fresh` em `$ARGUMENTS` → começar do zero. Write estado inicial com `{"status": "running", "phase_done": 0, ...}` para `.security/state/patch-state.json`.
+- Se `status == "running"` com `phase_done == N` → retomar. Print `Retomando checkpoint: Fase N concluída`. Pular para Fase N+1.
+
+**Fim de cada fase N:**
+Write o estado atualizado (com `phase_done: N` e dados acumulados) para `.security/state/patch-state.json`.
+
+**Fim da execução:**
+Write `{"status": "complete", "phase_done": 4, ...}` para `.security/state/patch-state.json`.
+
+---
+
+## Fase 0: Parse de argumentos e validação
+
+### 0a. Parsear `$ARGUMENTS`
+
+Extrair: findings path (primeiro posicional), `--repo` (default `.`), `--top`, `--id`, `--fresh`.
+Se nenhum findings path: usar AskUserQuestion para solicitar.
+
+### 0b. Validar o input
+
+Ler o arquivo de findings:
+
+- **`triage.json`** — ler `.findings[]`. **Filtrar por `status == "confirmed"`**. Este é o input canônico: já verificado, deduplicado, ranqueado, com owner.
+- **`security-findings.json`** — ler `.findings[]`. Não verificado; print `Warning: security-findings.json não passou por triage. Execute /eng-security-triage primeiro para melhor precisão.` e continuar.
+- **JSON genérico** com lista top-level ou array `findings`/`results`/`issues`/`vulnerabilities`.
+
+Print: `N achados confirmados encontrados em <findings_path>`.
+
+**Checkpoint:** Write `.security/state/patch-state.json` com `{"status": "running", "phase_done": 0, "args": {...}}`.
+
+---
+
+## Fase 1: Ingest e normalização
+
+### 1a. Aliases de campos (canônico ← também aceito)
+
+| Canônico         | Também aceitar                                              |
+|------------------|-------------------------------------------------------------|
+| `file`           | `path`, `location.file`, `filename`                         |
+| `line`           | `line_number`, `location.line`, `lineno`                    |
+| `category`       | `type`, `cwe`, `rule_id`                                    |
+| `severity`       | `severity_rating`, `level`, `priority`, `severity_derived`  |
+| `title`          | `name`, `summary`, `message`                                |
+| `description`    | `details`, `report`, `body`, `evidence`                     |
+| `recommendation` | `fix`, `remediation`, `mitigation`                          |
+| `owner_hint`     | `owner`, `component`                                        |
+
+Preservar `id` do triage.json (padrão `F-NNN`). Adicionar `source` (path relativo do arquivo de input).
+
+### 1b. Filtro e ordem
+
+- Se `--id F-NNN`: manter apenas esse achado.
+- Se `--top N`: ordenar por `severity` (HIGH > MEDIUM > LOW) depois `exploitability_rank` asc, manter os N primeiros.
+- Descartar achados sem `file` (não é possível patchar o que não tem localização). Registrar como `patch_status: "skipped"` com razão `"no source location"`.
+
+### 1c. Localizar o codebase-alvo
+
+Resolver `--repo`. Para os primeiros 5 achados com `file`, verificar se o path resolve sob o repo (tentar como está, depois com prefixos comuns removidos). Se nenhum resolver: **parar** e informar o usuário com sugestão de valor para `--repo`.
+
+**Checkpoint:** Write `.security/state/patch-state.json` com `phase_done: 1` + `findings` normalizados + `skipped`.
+
+---
+
+## Fase 2: Gerar patches (1 subagente por achado)
+
+Um Task por achado, **todos em UMA única mensagem** para execução paralela. `subagent_type: "general-purpose"`. Nunca usar `run_in_background` — você precisa do texto do diff, não de um handle assíncrono.
+
+Cada subagente tem acesso read-only ao `--repo`. Ele não pode modificar o alvo; emite o diff como texto na resposta. O orquestrador escreve esse texto em `PATCHES/bug_NN/patch.diff`.
+
+Se `len(findings) > 40`, fazer batches sequenciais de ~40 achados (cada batch em uma mensagem).
+
+Se algum Task retornar `status: "async_launched"` em vez do texto do subagente, o runtime fez background. Escolher uma recuperação e usar para todo o batch:
+- Se notificações de conclusão chegarem na conversa: parsear os blocos tagueados de cada `result` conforme chega. Não encerrar o turno até que todos os achados estejam contabilizados.
+- Se notificações não chegarem: re-spawnar os subagentes ausentes em um batch menor (~10) e usar os resultados síncronos.
+
+### Prompt do subagente de patch (montar uma vez, reusar por achado)
+
+```
+Você está conduzindo pesquisa de segurança autorizada como parte de uma avaliação defensiva. Sua tarefa: escrever uma correção candidata para UMA vulnerabilidade verificada em uma codebase à qual você tem acesso somente leitura.
+
+Você pode usar Read, Glob e Grep APENAS em paths dentro de {REPO_PATH}. Você NÃO pode compilar, executar, instalar, editar arquivos no disco, ou acessar a rede. Você irá emitir a correção como um diff unificado na sua resposta final; você NÃO vai aplicá-lo.
+
+────────────────────────────────────────────────────────────────────────
+ACHADO:
+
+  id:        {id}
+  file:      {file}
+  line:      {line}
+  category:  {category}
+  severity:  {severity}
+  title:     {title}
+
+  description:
+  {description}
+
+  recommendation:
+  {recommendation ou "(nenhuma fornecida)"}
+
+────────────────────────────────────────────────────────────────────────
+PROCEDIMENTO:
+
+1. LER O CÓDIGO. Abrir {file} na linha {line} e a função em volta.
+   Entender o que o código faz — não confiar na descrição do achado como única fonte.
+
+2. CAUSA RAIZ PRIMEIRO. Rastrear de volta do sink citado até onde o valor incorreto ou verificação ausente se origina. A correção geralmente pertence lá, não na linha que o scanner apontou. Nomear a localização da causa raiz (file:line).
+
+3. BUSCA DE VARIANTES. Grep por call sites irmãos com o mesmo padrão. Sua correção deve cobrir todos, ou sua rationale deve explicar por que não.
+
+4. DIFF MÍNIMO. Menor mudança que corrige a causa raiz. Sem refatoração, sem cleanup colateral, sem reformatação, sem mudanças só de comentário. Manter o estilo do código vizinho (posição de chaves, nomenclatura, tratamento de erros).
+
+5. SELF-CHECK ADVERSARIAL. Reler seu diff como atacante. Nomear uma variação de input que atingiria o mesmo estado ruim sem acionar sua mudança. Se conseguir nomear uma, seu fix está na camada errada — voltar ao passo 2.
+
+6. TESTE DE REGRESSÃO. Como parte do diff, adicionar UM caso de teste que falha antes da sua mudança e passa depois — colocado onde o projeto mantém seus testes (procurar test_*/, *_test.*, tests/, spec/). Se não existir diretório de testes, omitir o teste e explicar em <test_note>.
+
+────────────────────────────────────────────────────────────────────────
+OUTPUT — sua resposta final DEVE conter exatamente estas tags. Emitir o diff verbatim entre os marcadores; NÃO envolver em ``` fences.
+
+<patch_diff>
+--- a/path/to/file
++++ b/path/to/file
+@@ ... @@
+ linha de contexto
+-linha removida
++linha adicionada
+</patch_diff>
+<rationale>o que mudou e por que, mecanicamente — file:line da causa raiz, o que a mudança garante</rationale>
+<variants_checked>pares file:function que você inspecionou para o mesmo padrão, e se cada um precisou da correção</variants_checked>
+<bypass_considered>a variação de input que você tentou no passo 5 e por que ela não atinge mais o estado ruim</bypass_considered>
+<test_note>onde o teste de regressão foi adicionado, ou por que nenhum foi incluído</test_note>
+
+Se você determinar que o achado NÃO é corrigível como descrito (arquivo errado, código já corrigido, achado é falso-positivo), emitir:
+
+<patch_diff>NONE</patch_diff>
+<rationale>por que nenhum patch é apropriado</rationale>
+```
+
+### Parsear resultados
+
+De cada resultado de Task, extrair os cinco blocos tagueados. Tolerar whitespace extra, ``` fences extras, e entidades HTML escapadas (`&lt;` `&gt;` `&amp;`).
+
+Se `<patch_diff>` for `NONE` ou vazio: marcar `patch_status: "no_patch"`.
+Senão: Write o texto do diff em `./.security/outputs/PATCHES/bug_NN/patch.diff` (NN = índice com zero-pad na ordem ranqueada) e registrar `rationale`, `variants_checked`, `bypass_considered`, `test_note`.
+
+**Checkpoint:** Write `.security/state/patch-state.json` com `phase_done: 2` + array `patches` com resultados parciais.
+
+---
+
+## Fase 3: Review independente (1 subagente por diff)
+
+Um Task por achado com `patch_status == "patched"`, **todos em UMA mensagem**. `subagent_type: "general-purpose"`.
+
+**O reviewer nunca vê `description`, `recommendation` do achado nem a `rationale` do patch author.** Recebe apenas `{file, line, category}` mais os bytes brutos do diff, e re-deriva se o diff é uma correção mínima e no escopo lendo o próprio source. Isso garante que instruções injetadas na prosa do achado não passem pelo seu próprio gate.
+
+### Prompt do reviewer (montar uma vez, reusar por diff)
+
+```
+Você está revisando um patch de segurança candidato como um maintainer faria. Você tem acesso somente leitura ao source não-patchado em {REPO_PATH}. Você pode usar Read, Glob, Grep. Você NÃO pode compilar, executar ou aplicar o diff.
+
+Você NÃO viu a descrição do scanner da vulnerabilidade nem o raciocínio do autor do patch. Trabalhe apenas com a localização, a categoria e o diff.
+
+LOCALIZAÇÃO: {file}:{line}
+CATEGORIA: {category}
+
+DIFF SOB REVISÃO:
+<diff>
+{diff_text — ou, para diffs acima de ~50 linhas, substituir este bloco por:
+"Leia o diff em ./.security/outputs/PATCHES/bug_NN/patch.diff" e deixar o reviewer fazer o Read}
+</diff>
+
+────────────────────────────────────────────────────────────────────────
+RESPONDER QUATRO PERGUNTAS:
+
+1. ESCOPO. O diff toca apenas arquivos/funções no caminho entre {file}:{line} e seus callers? Listar qualquer hunk fora desse caminho.
+
+2. SUPRESSÃO. O diff corrige uma causa raiz, ou suprime o sintoma (try/except: pass, early-return em valor mágico, deletar o check que disparou, baixar um log level)?
+
+3. NOVA SUPERFÍCIE. O diff adiciona parsing, confia em um novo campo de input, enfraquece validação em outro lugar, ou remove um check relevante para segurança?
+
+4. ESTILO. 0-10: você faria merge deste diff como está?
+   0-3 camada errada / supressão; 4-6 correto mas ruidoso; 7-10 mínimo, direcionado, mantém o estilo do código vizinho.
+
+────────────────────────────────────────────────────────────────────────
+Terminar sua resposta com EXATAMENTE:
+
+  REVIEW: ACCEPT | REJECT
+  STYLE_SCORE: <0-10>
+  OUT_OF_SCOPE_HUNKS: <file:line separados por vírgula, ou none>
+  REASON: <2-4 frases citando hunks específicos do diff e linhas do source>
+
+ACCEPT requer: no escopo, correção de causa raiz, sem nova superfície de ataque, style >= 5. Caso contrário REJECT.
+```
+
+### Parsear e consolidar
+
+De cada resultado, parsear o bloco final. Anexar `review`, `style_score`, `out_of_scope_hunks`, `review_reason` ao achado. Definir `verified: "static_review_only"` para **todo** resultado estático — o label descreve a classe de verificação, não o resultado.
+
+**Checkpoint:** Write `.security/state/patch-state.json` com `phase_done: 3` + `patches` completos.
+
+---
+
+## Fase 4: Output
+
+### 4a. `patch_result.json` por achado
+
+Para cada achado, Write `./.security/outputs/PATCHES/bug_NN/patch_result.json`:
+
+```json
+{
+  "id": "F-003",
+  "source": "triage.json#2",
+  "title": "...",
+  "file": "...",
+  "line": 0,
+  "category": "...",
+  "severity": "HIGH",
+  "owner_hint": "...",
+  "patch_status": "patched|no_patch|skipped",
+  "verified": "static_review_only",
+  "review": "ACCEPT|REJECT|null",
+  "style_score": 0,
+  "out_of_scope_hunks": [],
+  "rationale": "...",
+  "variants_checked": "...",
+  "bypass_considered": "...",
+  "test_note": "...",
+  "review_reason": "..."
+}
+```
+
+### 4b. `./.security/outputs/PATCHES.json`
+
+Write `./.security/outputs/PATCHES.json`:
+
+```json
+{
+  "patch_completed": true,
+  "repo": "...",
+  "input_file": "triage.json",
+  "summary": {
+    "input_count": 0,
+    "patched": 0,
+    "no_patch": 0,
+    "skipped": 0,
+    "accepted": 0,
+    "rejected": 0
+  },
+  "findings": [ { "...": "mesmo shape do patch_result.json" } ]
+}
+```
+
+### 4c. `./.security/outputs/PATCHES.md` (incremental)
+
+**Passo 1 — header.** Write `./.security/outputs/PATCHES.md` (sobrescreve se existir):
+
+````markdown
+# Patches Candidatos
+
+> **Somente revisão estática.** Estes diffs foram criados e revisados por
+> agentes independentes lendo o source. Eles NÃO foram compilados, executados
+> ou re-atacados. Leia cada diff antes de aplicar — verifique: (1) escopo mínimo,
+> (2) causa raiz corrigida (não supressão de sintoma), (3) nenhuma nova superfície de ataque.
+
+**Input:** {findings_path} · **Repo:** {repo} · {N} achados → {M} diffs
+
+---
+````
+
+**Passo 2 — por achado** (ordenar: ACCEPT primeiro, depois por severity). Para cada achado, append a `./.security/outputs/PATCHES.md`:
+
+````markdown
+## bug_{NN}: [{severity}] {title}  ({id})
+
+`{file}:{line}` · {category} · owner: {owner_hint ou "?"}
+**Status:** {verified} · review {review ou "n/a"} · style {style_score ou "n/a"}/10
+**Diff:** `.security/outputs/PATCHES/bug_{NN}/patch.diff`
+
+**Rationale:** {rationale}
+**Variantes verificadas:** {variants_checked}
+**Bypass considerado:** {bypass_considered}
+{se review == "REJECT":}
+> **Rejeitado pelo reviewer:** {review_reason}
+{se out_of_scope_hunks:}
+> **Hunks fora do escopo:** {out_of_scope_hunks}
+
+---
+````
+
+**Passo 3 — rodapé.** Append tabela `## Skipped` para achados sem `file` ou `patch_status == "no_patch"`, uma linha cada com a razão.
+
+**Checkpoint final:** Write `.security/state/patch-state.json` com `{"status": "complete", "phase_done": 4, ...}`.
+
+### 4d. Sumário terminal
+
+Máximo ~10 linhas:
+
+```
+Patches gerados (modo estático): {N} achados → {M} diffs.
+
+  Aceitos:    {n}   {título do top aceito}
+  Rejeitados: {n}
+  Sem patch:  {n}
+  Skipped:    {n}
+
+Escrito em ./.security/outputs/PATCHES/bug_NN/, ./.security/outputs/PATCHES.md, ./.security/outputs/PATCHES.json
+Estes são rascunhos. Revise cada diff antes de aplicar.
+```
+
+---
+
+## Guard Rails
+
+- **O skill nunca aplica diffs.** Sem `git apply`, sem `patch`, sem Edit contra `--repo`. Se parecer necessário, o design está errado.
+- **Write somente em `./.security/outputs/PATCHES/` e `.security/state/`.**
+- **Isolamento do reviewer.** O prompt do reviewer recebe `{file, line, category, diff}` e nada mais do achado. Não passar `description`, `recommendation` nem a `rationale` do autor do patch.
+- **Todos os Task calls de uma fase em UMA mensagem.** Spawn serial está correto mas N× mais lento.
+- **`verified: "static_review_only"` sempre** em modo estático, independente de ACCEPT/REJECT.
+- **Checkpoint antes de iniciar a próxima fase**, sempre.
+- **Input canônico é `triage.json` com `status == "confirmed"`.** Patchar achado não-verificado gasta tokens em falso-positivo.
+
+---
+
+## Pipeline completo
+
+```
+/eng-threat-model → /eng.security-audit → /eng-security-triage → /eng-security-patch
+    (mapa)              (scan guiado)         (verifica+ranqueia)     (fix candidato)
+```
+
+Schemas de todos os artefatos em `docs/SECURITY-ARTIFACTS-SCHEMA.md`.

package/skills/eng-security-triage/SKILL.md

@@ -0,0 +1,266 @@
+---
+name: eng-security-triage
+description: >-
+  Triage de achados de seguranca. Consome um ou mais security-findings.json (output de
+  eng.security-audit ou eng.security-review), deduplica em 2 passadas (deterministica +
+  semantica), verifica cada achado com N votos independentes, re-rankeia por exploitabilidade
+  e escreve triage.json. Use apos eng.security-audit ou eng.security-review.
+argument-hint: "<findings-file> [<findings-file2> ...] [--auto] [--votes N]"
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Write
+  - AskUserQuestion
+  - Task
+  - Bash(git log:*)
+  - Bash(find:*)
+---
+
+# eng-security-triage
+
+Recebe o output bruto do scan (`security-findings.json`) e produz lista limpa, verificada e ranqueada (`triage.json`).
+
+**Problema que resolve:** scanners de seguranca tem alta taxa de falso-positivo (~45%) e achados duplicados entre focus areas. Triage resolve em 4 fases: normalizar → deduplicar → verificar com N votos → re-rankear por exploitabilidade.
+
+**Subagentes de verificacao rodam sem MCP** — apenas o texto do achado como contexto. Menos tool = veredicto mais deterministico, mais barato, sem distração por acesso ao codigo.
+
+---
+
+## Checkpointing
+
+Em lotes grandes (>20 achados × N votos), a triage pode esgotar contexto ou atingir rate limit mid-run.
+Estado persiste em `.security/state/` via Write tool — sem dependencia de Python.
+
+**Verificacao de resume (sempre antes do Step 0):**
+
+Verificar se `.security/state/triage-state.json` existe.
+- Nao existe ou `--fresh` em `$ARGUMENTS`: fresh start.
+- `status == "running"` com `phase_done == N`: ler `.security/state/triage-phase-N.json` e pular direto para Fase N+1.
+- `status == "complete"`: fresh start.
+
+**Ao final de cada fase N:** dois Writes:
+1. `.security/state/triage-phase-N.json` — estado completo da fase (achados com campos preenchidos ate aqui).
+2. `.security/state/triage-state.json` — `{"status": "running", "phase_done": N}`.
+
+**Ao escrever o `triage.json` final:**
+`.security/state/triage-state.json` → `{"status": "complete", "phase_done": 6}`.
+
+`.security/state/` e scratch — adicionar ao `.gitignore` do projeto.
+
+---
+
+## Step 0 — Entrevista (pular com `--auto`)
+
+Antes de processar, coletar contexto via `AskUserQuestion`:
+
+1. **Fronteira de confianca:** "Qual a fronteira de confianca do sistema? (ex: usuarios autenticados podem fazer upload, mas nao modificar dados de outros)"
+2. **Threat model:** "Existe `THREAT_MODEL.md`? Qual o path? (ou 'nao existe')"
+3. **Tolerancia a ruido:** "Preferencia de precisao? `low` (menos falsos positivos) | `medium` (default) | `high` (manter tudo duvidoso para revisao humana)"
+4. **Padrao de score:** "Usar CVSS (impacto x likelihood) ou `exploitability-first` (priorizar por facilidade de exploracao)?"
+
+`--auto`: pular entrevista — defaults: `noise_tolerance=medium`, `scoring=exploitability-first`, threat model = buscar `THREAT_MODEL.md` na raiz.
+
+Salvar respostas em `.security/state/triage-context.json` para sobreviver a compactacao.
+
+---
+
+## Fase 1 — Normalizar
+
+1. Ler todos os `security-findings.json` passados como argumento.
+2. Flatten em lista unica de achados.
+3. Normalizar IDs para `F-001`, `F-002`, ... (ordenado por impact desc, likelihood desc, file, linha).
+4. Registrar `input_files[]` e `total_input` para o `summary` final.
+
+Se um arquivo nao existir ou nao for JSON valido: reportar ao usuario e continuar com os restantes.
+
+---
+
+## Fase 2 — Deduplicar
+
+**Passada 1 — Deterministica:**
+Agrupar achados onde:
+- Mesmo `file`
+- Mesma `category`
+- `line` dentro de ±10 linhas entre si
+
+Para cada grupo: manter o achado com `description` mais longa (mais informativo). Registrar descartados com `dedup_group: <id do canonico>`.
+
+**Passada 2 — Semantica:**
+Para pares que sobreviveram a passada 1 com mesma `category` mas arquivos diferentes ou linha fora do range, spawnar 1 subagente de comparacao (sem MCP):
+
+```
+Dois achados de seguranca. Corrigir um necessariamente corrige o outro?
+
+ACHADO A: {title_a} em {file_a}:{line_a}
+Descricao: {description_a}
+
+ACHADO B: {title_b} em {file_b}:{line_b}
+Descricao: {description_b}
+
+Responda exatamente:
+is_duplicate: true | false
+reasoning: <uma linha>
+```
+
+Se `is_duplicate: true`: manter o de maior `confidence`, descartar o outro com `dedup_group`.
+Incrementar `duplicates_removed` no `summary`.
+
+---
+
+## Fase 3 — Verificacao Multi-Voto
+
+Para cada achado nao-descartado, spawnar **N subagentes de voto independentes** (default N=3; sobrescrever com `--votes N`).
+
+Cada subagente recebe apenas o texto do achado — **sem acesso ao codigo-fonte, sem MCP**:
+
+```
+Voce e um revisor de seguranca independente. Avaliar este achado:
+
+ID: {id}
+TITULO: {title}
+CATEGORIA: {category} ({file}:{line})
+IMPACTO: {impact} | LIKELIHOOD: {likelihood}
+
+DESCRICAO:
+{description}
+
+EVIDENCIA:
+{evidence}
+
+FRONTEIRA DE CONFIANCA DO SISTEMA: {trust_boundary}
+
+Sua postura padrao: o scanner esta ERRADO. Re-derive a conclusao a partir da descricao e evidencia fornecidas.
+
+REGRAS DE EXCLUSAO — se o achado se encaixa em qualquer uma, e FALSO POSITIVO mesmo que tecnicamente preciso:
+
+  1. DoS volumetrico ou rate-limiting ausente (tratado na camada de infraestrutura). ReDoS, complexidade algoritmica e recursao ilimitada SAO findings validos.
+  2. Codigo de teste, codigo morto, codigo de exemplo/fixture ou crash sem impacto de seguranca.
+  3. Comportamento intencional do design (middleware de compressao, algoritmo fraco oferecido ao lado de um forte com opt-in).
+  4. Memory-safety em linguagens memory-safe fora de blocos unsafe/FFI.
+  5. SSRF onde o atacante controla apenas o path, nao o host ou protocolo.
+  6. Input de usuario fluindo para prompt de IA/LLM (prompt injection nao e vulnerabilidade de codigo no alvo).
+  7. Path traversal em object storage (S3/GCS) onde ../ nao escapa uma fronteira de confianca.
+  8. Inputs confiaveis usados como vetor (env vars, flags CLI definidos pelo operador), a menos que o sistema marque-os como nao-confiaveis.
+  9. Codigo client-side flagrado para classes de vulnerabilidade server-side.
+ 10. Versoes desatualizadas de dependencias (gerenciado por processo separado; use npm audit para isso).
+ 11. Randomness fraca usada para fins nao-seguranca (jitter, shuffling, fallbacks de dev).
+ 12. Issues de baixo impacto: log spoofing, CSRF em logout, self-XSS, open redirect, tabnabbing, injecao de regex.
+ 13. Gap de hardening sem caminho de exploit concreto: headers de seguranca ausentes, sem audit logging, config permissiva nao alcancada por input nao-confiavel.
+ 14. XSS em framework com auto-escape padrao (React, Angular, Vue, Jinja2 autoescape=on) a menos que o sink seja escape hatch de HTML raw (dangerouslySetInnerHTML, v-html, |safe).
+ 15. Identificadores construidos para serem inesgotaveis (UUIDv4, tokens de 128+ bits aleatorios) flagrados como "previsiveis" ou "precisam de validacao".
+ 16. Race conditions ou TOCTOU apenas teoricos — sem janela realista ou sem mudanca de estado com relevancia de seguranca entre check e use.
+
+Este achado e real e exploravel dado a fronteira de confianca declarada? Avalie contra as regras acima e a evidencia fornecida.
+
+Responda exatamente:
+verdict: confirmed | rejected | inconclusive
+verify_verdict: exploitable | mitigated | needs_manual_test
+  exploitable: caminho de ataque realista, sem mitigacao efetiva
+  mitigated: achado real mas controle existente reduz o risco (nomear o controle no reasoning)
+  needs_manual_test: conclusao depende de comportamento runtime — recomendar PoC humano
+  (para verdict=rejected: sempre needs_manual_test)
+reasoning: <uma linha — citar regra de exclusao se aplicavel, ex: "Regra 1: DoS volumetrico">
+confidence: <0.0-1.0>
+```
+
+**Consolidacao:**
+
+| Votos confirmed | Resultado | Status final |
+|---|---|---|
+| >= ceil(N/2) confirmed | Confirmado | `confirmed` |
+| >= ceil(N/2) rejected | Falso positivo | `rejected` |
+| Outro | Inconcluso | `inconclusive` |
+
+Registrar `vote_result{votes_total, votes_confirmed, verdict, reasoning}` em cada achado.
+`verify_verdict` do achado: valor modal entre os votos (se todos rejected: `needs_manual_test`).
+Incrementar `rejected_by_vote` no `summary`.
+
+---
+
+## Fase 4 — Re-rankear por Exploitabilidade
+
+Ordenar achados `confirmed` e `inconclusive` por exploitability score (1 subagente por achado, sem MCP):
+
+```
+Dado este achado confirmado:
+{id} | {title} | {category}
+impact (scanner): {impact} | likelihood: {likelihood}
+trust_boundary: {trust_boundary}
+verify_verdict: {verify_verdict}
+
+PASSO 1: Listar TODAS as pre-condicoes para exploracao (estado de auth, configuracao especifica, posicao de rede, janela de race).
+
+PASSO 2: Identificar nivel de acesso minimo necessario:
+  unauthenticated_remote | authenticated | local | physical
+
+PASSO 3: Derivar severidade — aplicar tabela e tomar o resultado MENOR:
+  | Pre-condicoes | Acesso                 | Severidade |
+  | 0             | unauthenticated_remote | HIGH       |
+  | 1-2           | authenticated          | MEDIUM     |
+  | 3+            | local / sem demo path  | LOW        |
+  Exemplo: 0 pre-condicoes mas so authenticated → MEDIUM, nao HIGH.
+
+PASSO 4: Comparar com impact declarado pelo scanner (severity_alignment -5..+5):
+  +3..+5 justificado ou subestimado | 0..+2 adequado | -1..-3 inflado | -4..-5 muito inflado
+
+PASSO 5: Score de explorabilidade 1-10 para desempate no ranking:
+  10=trivial, tooling publico; 7-9=habilidade media; 4-6=conhecimento especializado; 1-3=acesso privilegiado
+
+Responda exatamente:
+preconditions: <lista separada por ponto e virgula>
+access_level: <unauthenticated_remote|authenticated|local|physical>
+severity_derived: <HIGH|MEDIUM|LOW>
+severity_alignment: <-5..+5>
+exploitability_score: <1-10>
+reasoning: <uma linha>
+```
+
+Ordenar por `severity_derived` (HIGH > MEDIUM > LOW) → `exploitability_score` desc → `impact` desc → `likelihood` desc.
+Atribuir `exploitability_rank` (1 = mais critico).
+
+---
+
+## Fase 5 — Atribuicao de Owner
+
+Para cada achado `confirmed` ou `inconclusive`, identificar o dono mais especifico inferivel. Parar na primeira regra que produzir resultado:
+
+1. **CODEOWNERS**: buscar `CODEOWNERS`, `.github/CODEOWNERS`, `docs/CODEOWNERS` no repo. Se encontrado, fazer match do `file` do achado contra os padroes (ultimo match vence). Registrar como `"CODEOWNERS: <padrao> → <owner(s)>"`.
+
+2. **git log**: executar `git log --format='%an' -n 50 -- "{file}" | sort | uniq -c | sort -rn | head -3`. Registrar como `"top committer: <nome> (<n>/<total> commits recentes); sem entrada CODEOWNERS"`.
+
+3. **Fallback de modulo**: registrar como `"componente: <diretorio-raiz do file>/; sem CODEOWNERS ou historico git"`.
+
+Salvar como `owner_hint` no achado. Para achados `rejected` ou `duplicate`: `owner_hint: null`.
+
+---
+
+## Step 2 — Escrever output
+
+Ler `docs/SECURITY-ARTIFACTS-SCHEMA.md` secao 3 antes de escrever.
+
+Escrever `.security/outputs/triage.json`. Criar `.security/outputs/` se não existir.
+
+Salvar `.security/state/triage-meta.json`:
+
+```json
+{
+  "triage_date": "<ISO-8601>",
+  "input_files": ["<path>"],
+  "total_input": 0,
+  "confirmed": 0,
+  "top_finding": "<F-001: titulo>"
+}
+```
+
+---
+
+## Step 3 — Sumario ao usuario
+
+Apos escrever:
+
+1. Path do `.security/outputs/triage.json`.
+2. Tabela: top 5 por `exploitability_rank` (id, titulo, categoria, file:line, impact, rank, owner_hint).
+3. Contadores: `{total_input} input → {duplicates_removed} dedup → {rejected_by_vote} rejeitados por voto → {confirmed} confirmados`.
+4. Achados `inconclusive`: listar ids para revisao humana.
+5. Proximo passo: *"Achados confirmados prontos para cards no $TASK_MANAGER."*