jarvis-ai-framework 2.1.1 → 3.0.0

package/workflows/engineering/eng.security-pipeline.md

@@ -1,219 +0,0 @@
----
-description: Orquestrador do pipeline defensivo de segurança — encadeia threat-model, audit, triage e patch em um único fluxo guiado
-globs:
-  alwaysApply: false
-recommended_model: claude-opus-4-6-20250529
-model_tier: very_high
-model_justification: Orquestração do pipeline completo exige raciocínio profundo para avaliar estado, decidir fases e interpretar outputs encadeados
----
-
-# Workflow de Engenharia – Security Pipeline (Orquestrador)
-
-## Objetivo
-
-Guiar o SENTINEL pelo pipeline defensivo completo de segurança, encadeando os 4 estágios em um fluxo único. Elimina a necessidade de lembrar a sequência de comandos — o usuário informa onde quer começar e o orquestrador conduz.
-
----
-
-## Quando Usar Este Workflow
-
-- Auditoria de segurança completa de um projeto ou feature
-- Retomada de pipeline interrompido em sessão anterior
-- Onboarding de segurança em projeto sem histórico de audit
-- Quando o usuário pede "auditar segurança", "pipeline completo" ou "fechar o loop"
-
-### Skills invocados durante o workflow
-
-| Passo | Skill | Condição |
-|-------|-------|----------|
-| Passo 2 › Estágio 1 — Threat Model | `/eng-security-threat-model` | Se o estágio 1 for selecionado no menu de entrada (modo bootstrap, interview ou bootstrap-then-interview, escolhido pelo usuário) |
-| Passo 2 › Estágio 2 — Security Audit | `/eng.security-audit` | Se o estágio 2 for selecionado no menu de entrada (usa o `THREAT_MODEL.md` como contexto, se existir) |
-| Passo 2 › Estágio 3 — Triage | `/eng-security-triage` | Se o estágio 3 for selecionado no menu de entrada (entrada: `security-findings.json`) |
-| Passo 2 › Estágio 4 — Patch | `/eng-security-patch` | Se o estágio 4 for selecionado no menu de entrada (entrada: `triage.json`) |
-
----
-
-## Passo 0 — Detectar estado do pipeline
-
-Antes de perguntar qualquer coisa, verificar o que já existe:
-
-```bash
-# Artefatos de output
-ls .security/outputs/ 2>/dev/null
-# State de sessões anteriores
-ls .security/state/ 2>/dev/null
-```
-
-| Artefato encontrado | Fase concluída |
-|---------------------|----------------|
-| `THREAT_MODEL.md` | Estágio 1 feito |
-| `security-findings.json` | Estágio 2 feito |
-| `triage.json` | Estágio 3 feito |
-| `PATCHES/` com conteúdo | Estágio 4 feito |
-
-Exibir o estado detectado antes de mostrar o menu.
-
----
-
-## Passo 1 — Menu de entrada
-
-```
-Pipeline de Segurança — SENTINEL
-
-Estado atual:
-  [✓/–] Estágio 1: Threat Model   (.security/outputs/THREAT_MODEL.md)
-  [✓/–] Estágio 2: Audit           (.security/outputs/security-findings.json)
-  [✓/–] Estágio 3: Triage          (.security/outputs/triage.json)
-  [✓/–] Estágio 4: Patch           (.security/outputs/PATCHES/)
-
-Onde iniciar?
-
-1. Completo    — estágio 1 → 2 → 3 → 4
-2. Audit+      — estágio 2 → 3 → 4  (já tenho ou pulo threat model)
-3. Triage+     — estágio 3 → 4       (já tenho security-findings.json)
-4. Só patch    — estágio 4            (já tenho triage.json)
-5. Retomar     — continuar de onde parou (detectar pelo state/)
-```
-
-> Se todos os artefatos existem, perguntar: "Pipeline completo encontrado. Reexecutar do início (--fresh) ou revisar outputs existentes?"
-
----
-
-## Passo 2 — Executar os estágios selecionados
-
-Executar cada estágio em sequência. Ao final de cada um, confirmar com o usuário antes de prosseguir para o próximo.
-
----
-
-### Estágio 1 — Threat Model (`/eng-security-threat-model`)
-
-**Skill**: `$IDE/skills/eng-security-threat-model/SKILL.md`
-
-Perguntar modo de operação:
-```
-Modo do threat model:
-1. bootstrap            — deriva o modelo do código automaticamente
-2. interview            — walk interativo com você como owner do sistema
-3. bootstrap-then-interview — bootstrap primeiro, entrevista refinadora depois
-```
-
-Invocar o skill com o modo escolhido. Output esperado: `.security/outputs/THREAT_MODEL.md`.
-
-Ao concluir:
-```
-✓ Threat model gerado em .security/outputs/THREAT_MODEL.md
-  Ameaças identificadas: {N}
-  Areas priorizadas para audit: {lista de focus-areas}
-
-Prosseguir para Estágio 2 (Audit)? [s/n]
-```
-
----
-
-### Estágio 2 — Security Audit (`/eng.security-audit`)
-
-**Workflow**: `$IDE/workflows/engineering/eng.security-audit.md`
-
-Passar `THREAT_MODEL.md` como contexto se existir (Fase 0.5 do audit).
-
-Perguntar escopo se não informado:
-```
-Escopo do audit:
-1. Projeto completo (--all)
-2. Pasta específica (ex: ./src/auth/)
-3. Focus específico (owasp | secrets | supply-chain | headers | compliance)
-```
-
-Output esperado: `.security/outputs/security-findings.json` + `security-audit-report.md`.
-
-Ao concluir:
-```
-✓ Audit concluído
-  Achados brutos: {N}
-  Distribuição: CRITICAL {n} | HIGH {n} | MEDIUM {n} | LOW {n}
-  Output: .security/outputs/security-findings.json
-
-Prosseguir para Estágio 3 (Triage)? [s/n]
-```
-
-> Se N == 0: informar "Nenhum achado encontrado. Pipeline encerrado." e parar.
-
----
-
-### Estágio 3 — Triage (`/eng-security-triage`)
-
-**Skill**: `$IDE/skills/eng-security-triage/SKILL.md`
-
-Input: `.security/outputs/security-findings.json`
-
-Perguntar modo:
-```
-Modo de triage:
-1. --auto    — sem perguntas interativas (recomendado para pipelines CI)
-2. interativo — coleta contexto de trust boundary e tolerância a ruído
-```
-
-Output esperado: `.security/outputs/triage.json`
-
-Ao concluir:
-```
-✓ Triage concluído
-  Achados confirmados: {N}  |  Falsos positivos descartados: {N}
-  Top 3 por exploitabilidade: {lista}
-  Output: .security/outputs/triage.json
-
-Prosseguir para Estágio 4 (Patch)? [s/n]
-```
-
-> Se N confirmados == 0: informar "Nenhum achado confirmado após triage. Pipeline encerrado." e parar.
-
----
-
-### Estágio 4 — Patch (`/eng-security-patch`)
-
-**Skill**: `$IDE/skills/eng-security-patch/SKILL.md`
-
-Input: `.security/outputs/triage.json`
-
-Perguntar escopo:
-```
-Gerar patches para:
-1. Todos os achados confirmados
-2. Apenas top N (ex: top 3 por severidade)
-3. Achado específico (ID F-NNN)
-```
-
-Output esperado: `.security/outputs/PATCHES/bug_NN/{patch.diff, patch_result.json}` + `PATCHES.md`
-
-Ao concluir:
-```
-✓ Pipeline de segurança concluído
-
-Resumo:
-  Threat model : .security/outputs/THREAT_MODEL.md
-  Achados audit: .security/outputs/security-findings.json  ({N} achados)
-  Triage       : .security/outputs/triage.json              ({N} confirmados)
-  Patches      : .security/outputs/PATCHES/                 ({N} diffs gerados)
-  Relatório    : .security/outputs/security-audit-report.md
-
-Próximos passos para o TL:
-  1. Revisar diffs em .security/outputs/PATCHES/
-  2. Aplicar patches aprovados: git apply .security/outputs/PATCHES/bug_NN/patch.diff
-  3. Criar cards no $TASK_MANAGER para achados sem patch (no_patch)
-  4. Commitar .security/outputs/ (excluir .security/state/ via .gitignore)
-```
-
----
-
-## Regras
-
-### Nunca
-- Pular a confirmação do usuário entre estágios sem `--auto` explícito
-- Avançar para Estágio 4 sem triage (patches gerados de achados não verificados têm alta taxa de erro)
-- Aplicar diffs automaticamente — output é sempre texto inerte para revisão humana
-
-### Sempre
-- Detectar estado existente antes de mostrar o menu
-- Informar quantos achados passaram de cada estágio
-- Parar o pipeline se nenhum achado sobreviver a um estágio (audit vazio ou triage sem confirmados)
-- Sugerir `.gitignore` para `.security/state/` se não estiver ignorado

package/workflows/engineering/eng.security-review.md

@@ -1,241 +0,0 @@
----
-description: Workflow de Engenharia para Review de Seguranca em PRs/MRs (gate pre-merge)
-globs:
-  alwaysApply: false
-recommended_model: claude-sonnet-4-6-20250514
-model_tier: high
-model_justification: Security review de PRs requer analise focada de mudancas especificas — nao exige raciocinio tao profundo quanto audit completo, mas precisa de precisao
----
-
-# Workflow de Engenharia – Security Review (Gate Pre-Merge)
-
-## Objetivo
-
-Guiar o SENTINEL (ENG) na revisao de seguranca de PRs/MRs que tocam areas sensiveis do codigo — autenticacao, autorizacao, inputs, APIs, configs e permissoes. Funciona como gate de seguranca complementar ao code review normal.
-
----
-
-## Quando Usar Este Workflow
-
-- PR modifica fluxos de autenticacao ou autorizacao
-- PR adiciona ou modifica endpoints publicos
-- PR toca em processamento de inputs (forms, uploads, parsing)
-- PR modifica configs de seguranca (CORS, CSP, headers)
-- PR adiciona dependencias novas
-- PR toca em dados sensiveis (PII, financeiro)
-- PR modifica permissoes ou roles (RBAC, guards)
-- Tech Lead solicita security review explicito
-
----
-
-## Pre-requisitos
-
-### Entrada
-
-```
-/eng.security-review [referencia-do-pr]
-
-Onde [referencia-do-pr] pode ser:
-- Numero do PR/MR: #123
-- URL: https://gitlab.com/org/repo/-/merge_requests/123
-- Branch: feature/nova-auth
-```
-
-### Skills invocados durante o workflow
-
-| Passo | Skill | Condição |
-|-------|-------|----------|
-| — | Nenhuma — workflow autocontido | — |
-
----
-
-## Fase 1 – Scope
-
-### 1.1 Identificar arquivos alterados
-
-```bash
-# Listar arquivos alterados no PR/branch
-git diff --name-only main...HEAD 2>/dev/null || git diff --name-only origin/main...HEAD
-
-# Filtrar arquivos sensiveis
-git diff --name-only main...HEAD | grep -E "(auth|guard|middleware|session|login|permission|role|token|secret|password|cors|csp|helmet|security|\.env)" 2>/dev/null
-```
-
-### 1.2 Classificar risco do PR
-
-| Indicador | Risco | Motivo |
-|-----------|-------|--------|
-| Toca em auth/guard/session | **ALTO** | Bypass pode dar acesso total |
-| Adiciona endpoint publico | **ALTO** | Nova superficie de ataque |
-| Modifica CORS/CSP/headers | **ALTO** | Misconfiguration afeta toda app |
-| Processa input do usuario | **MEDIO** | Injection, XSS |
-| Adiciona dependencia nova | **MEDIO** | Supply chain |
-| Modifica roles/permissoes | **ALTO** | Escalacao de privilegio |
-| Toca em dados sensiveis | **ALTO** | Data exposure |
-| Refactoring sem mudanca de API | **BAIXO** | Risco minimo |
-
----
-
-## Fase 2 – Analysis
-
-### 2.1 Checklist de seguranca por area
-
-#### Auth e Sessions
-- [ ] Tokens JWT: expiracao curta para access, refresh com rotacao
-- [ ] Sessions: `httpOnly`, `secure`, `sameSite: strict`
-- [ ] Password hashing: bcrypt/argon2 (nunca MD5/SHA1)
-- [ ] Rate limiting em login/registro
-- [ ] Logout invalida session/token no backend
-
-#### Inputs e Validation
-- [ ] Todos os inputs validados com schema (Zod, Joi, class-validator)
-- [ ] Queries parametrizadas (nunca concatenacao SQL)
-- [ ] Uploads: validar tipo, tamanho, nome de arquivo
-- [ ] Rich text: sanitizado com allowlist (DOMPurify)
-- [ ] URLs dinamicas: validadas contra allowlist (prevenir SSRF)
-
-#### APIs e Endpoints
-- [ ] Endpoints protegidos com auth guard (exceto os intencionalmente publicos)
-- [ ] Autorizacao verificada (RBAC/permissions, nao apenas autenticacao)
-- [ ] IDOR prevenido (usuario so acessa seus dados ou tem permissao)
-- [ ] Rate limiting em endpoints sensiveis
-- [ ] Erros nao vazam detalhes internos (stack traces, queries)
-
-#### Configs e Headers
-- [ ] CORS: origins especificas (nunca `*` em producao)
-- [ ] CSP: configurado e restritivo
-- [ ] HSTS: habilitado com `includeSubDomains`
-- [ ] X-Frame-Options: `DENY` ou `SAMEORIGIN`
-- [ ] Sem debug mode em producao
-
-#### Dependencias
-- [ ] `npm audit` sem vulnerabilidades HIGH/CRITICAL
-- [ ] Lockfile atualizado e commitado
-- [ ] Dependencia nova: verificar manutencao, downloads, issues
-
-#### Dados Sensiveis
-- [ ] PII criptografada em repouso
-- [ ] Logs nao contem dados sensiveis (senhas, tokens, PII)
-- [ ] Dados sensiveis nao expostos em respostas de API desnecessariamente
-
----
-
-## Fase 2.5 — Verificacao Multi-Voto
-
-Para cada achado identificado no checklist (Fase 2), spawnar **3 subagentes de voto** independentes.
-
-> Subagentes de voto rodam **sem MCP** — apenas o texto do achado como contexto. Menos tool = veredicto mais deterministico e barato.
-
-**Brief por subagente de voto:**
-
-```
-Voce e um revisor de seguranca independente. Avaliar este achado:
-
-ACHADO: {titulo} em {arquivo}:{linha}
-EVIDENCIA: {codigo ou config vulneravel}
-CONTEXTO: PR #{referencia}, area {categoria}
-
-Este e um achado real e exploravel no contexto deste PR?
-
-Responda exatamente:
-verdict: confirmed | rejected | inconclusive
-reasoning: <uma linha explicando o veredicto>
-confidence: <0.0-1.0>
-```
-
-**Consolidacao dos votos:**
-
-| Resultado | Criterio | Acao |
-|---|---|---|
-| Confirmado | >= 2/3 votos `confirmed` | Incluir no report com severidade original |
-| Falso positivo | >= 2/3 votos `rejected` | Descartar — nao incluir |
-| Inconcluso | Divergencia | Incluir com flag `[REVISAR]` para humano |
-
----
-
-## Fase 3 – Verdict
-
-### 3.1 Classificar resultado
-
-| Verdict | Criterio | Acao |
-|---------|----------|------|
-| **APPROVED** | Nenhum achado HIGH/CRITICAL | Aprovar merge |
-| **CHANGES REQUESTED** | Achados MEDIUM ou HIGH corrigiveis | Solicitar correcoes com evidencia |
-| **BLOCKED** | Achado CRITICAL ou HIGH nao corrigivel trivialmente | Bloquear merge, escalar para TL |
-
-### 3.2 Feedback estruturado
-
-Para cada achado, comentar no PR com:
-
-```markdown
-**[SECURITY - {SEVERIDADE}]** {titulo}
-
-**Arquivo**: `path/to/file.ts:line`
-**Vetor**: {tipo de vulnerabilidade}
-**Evidencia**:
-\`\`\`typescript
-// codigo vulneravel
-\`\`\`
-
-**Correcao sugerida**:
-\`\`\`typescript
-// codigo seguro
-\`\`\`
-```
-
----
-
-## Fase 4 – Documentation
-
-### 4.1 Registrar decisao
-
-```markdown
-## Security Review Summary
-
-**PR/MR**: {referencia}
-**Reviewer**: SENTINEL (AI-assisted)
-**Data**: {ISO-8601}
-**Verdict**: APPROVED | CHANGES REQUESTED | BLOCKED
-
-### Areas revisadas
-- [ ] Auth e Sessions
-- [ ] Inputs e Validation
-- [ ] APIs e Endpoints
-- [ ] Configs e Headers
-- [ ] Dependencias
-- [ ] Dados Sensiveis
-
-### Achados
-| # | Severidade | Descricao | Status |
-|---|-----------|-----------|--------|
-| 1 | {sev} | {descricao} | {aberto|corrigido} |
-
-### Notas
-{observacoes adicionais relevantes}
-```
-
----
-
-## Fase 4.2 — Output JSON (security-findings.json)
-
-Alem do summary markdown (Fase 4.1), escrever `security-findings.json` conforme `docs/SECURITY-ARTIFACTS-SCHEMA.md` secao 2.
-
-Incluir apenas achados com `vote_result.verdict != rejected` (confirmed + inconclusive).
-Este arquivo pode ser consumido por `eng-security-triage` para dedup e re-rank caso o PR faca parte de um audit maior.
-
----
-
-## Regras
-
-### Nunca
-- Aprovar um PR com achado CRITICAL sem correcao
-- Bloquear um PR sem evidencia tecnica (nao bloquear por "sensacao")
-- Fazer review de seguranca superficial (checklist mecanico sem analise)
-- Ignorar dependencias novas adicionadas ao projeto
-
-### Sempre
-- Analisar o diff completo, nao apenas os arquivos marcados como "sensiveis"
-- Fornecer correcao sugerida para cada achado (nao apenas apontar o problema)
-- Considerar o contexto: um endpoint interno tem risco diferente de um publico
-- Comunicar achados CRITICAL ao TL imediatamente (nao esperar o review terminar)
-- Verificar se testes de seguranca foram adicionados para mudancas em auth

package/workflows/engineering/qa/eng.qa-dev-quality-guide.md

@@ -1,57 +0,0 @@
----
-description: Orienta desenvolvedores sobre cobertura de testes para uma feature ou PR
-auto_execution_mode: 2
-rules_file: "$IDE/rules/engineering/qa/eng.qa.cypress-standards-rules.md"
-model_tier: medium
-model_justification: Análise de código e geração de orientação estruturada
----
-
-# qa.dev-quality-guide
-
-Analisa o código de um desenvolvedor e orienta sobre quais testes Cypress escrever,
-usando os padrões do projeto. Não escreve o teste — guia e valida.
-
-> 📋 **Rules**: `$IDE/rules/engineering/qa/eng.qa.cypress-standards-rules.md`
-> 🔧 **Skill**: `eng-qa-dev-guide`
-
-### Skills invocados durante o workflow
-
-| Passo | Skill | Condição |
-|-------|-------|----------|
-| Execução | `/eng-qa-dev-guide` | Sempre — invocado via Skill tool |
-
----
-
-## Entrada
-
-```
-#$ARGUMENTS
-```
-
-Aceita: caminho de arquivo(s), ID de task no $TASK_MANAGER, ou diff/PR em texto.
-
-**Se não receber argumentos**, perguntar:
-- Qual arquivo ou PR do dev você quer analisar?
-
----
-
-## Execução
-
-Invocar Skill tool: `eng-qa-dev-guide`
-
-A skill irá:
-1. Ler o código fornecido e mapear o que foi alterado/adicionado
-2. Verificar quais specs de teste já existem para o domínio
-3. Gerar análise de cobertura: o que está coberto vs. o que precisa de teste
-4. Orientar sobre como estruturar cada cenário (setup, intercept, ação, asserção)
-5. Indicar quais `data-testid` precisam ser adicionados
-6. Entregar checklist acionável para o dev
-
----
-
-## Output
-
-- Análise de cobertura: coberto vs. crítico vs. recomendado
-- Orientação de implementação para cada cenário necessário
-- Checklist de testes a implementar antes do merge
-- Lista de `data-testid` pendentes no código

package/workflows/engineering/qa/eng.qa-e2e-test-generation.md

@@ -1,57 +0,0 @@
----
-description: Gera testes E2E Cypress a partir de uma feature, task ou spec
-auto_execution_mode: 2
-rules_file: "$IDE/rules/engineering/qa/eng.qa.cypress-standards-rules.md"
-template_file: "$IDE/templates/engineering/qa/qa.cypress-test-template.md"
-model_tier: high
-model_justification: Requer análise de codebase, geração de Page Objects e specs completas
----
-
-# qa.e2e-test-generation
-
-Gera testes E2E Cypress + TypeScript para uma feature a partir de spec, task ou descrição.
-
-> 📋 **Rules**: `$IDE/rules/engineering/qa/eng.qa.cypress-standards-rules.md`
-> 📤 **Template**: `$IDE/templates/engineering/qa/qa.cypress-test-template.md`
-> 🔧 **Skill**: `eng-qa-cypress-e2e`
-
-### Skills invocados durante o workflow
-
-| Passo | Skill | Condição |
-|-------|-------|----------|
-| Execução | `/eng-qa-cypress-e2e` | Sempre — invocado via Skill tool |
-
----
-
-## Entrada
-
-```
-#$ARGUMENTS
-```
-
-Aceita: caminho de spec/task, ID de task no $TASK_MANAGER, ou descrição do fluxo em linguagem natural.
-
-**Se não receber argumentos**, perguntar:
-- Qual feature ou fluxo deseja cobrir com testes E2E?
-
----
-
-## Execução
-
-Invocar Skill tool: `eng-qa-cypress-e2e`
-
-A skill irá:
-1. Mapear a estrutura de testes existente no projeto
-2. Analisar o fluxo e identificar cenários (happy path, edge cases, negative tests)
-3. Confirmar cenários com o QA antes de gerar
-4. Gerar: Page Object + fixtures + custom commands (se necessário) + spec `.cy.ts`
-5. Exibir checklist de `data-testid` que precisam ser adicionados ao código da aplicação
-
----
-
-## Output
-
-- `{TEST_FOLDER}/e2e/{dominio}/{feature}.cy.ts` — spec gerada
-- `{TEST_FOLDER}/support/pages/{Dominio}Page.ts` — Page Object (novo ou atualizado)
-- `{TEST_FOLDER}/fixtures/{dominio}/*.json` — fixtures de intercept
-- Checklist de `data-testid` pendentes no código da aplicação

package/workflows/engineering/qa/eng.qa-exploratory-session.md

@@ -1,68 +0,0 @@
----
-description: Conduz sessão de teste exploratório estruturada com charter, roteiro de risco e registro de achados
-auto_execution_mode: 2
-rules_file: "$IDE/rules/engineering/qa/eng.qa.exploratory-session-rules.md"
-template_file: "$IDE/templates/engineering/qa/qa.exploratory-session-template.md"
-model_tier: medium
-model_justification: Análise de risco e estruturação de sessão — raciocínio moderado
----
-
-# qa.exploratory-session
-
-Conduz ou documenta uma sessão de teste exploratório, gerando o doc de sessão estruturado
-e criando cards de bug via `eng-qa-bug-report` ao final.
-
-> 📋 **Rules**: `$IDE/rules/engineering/qa/eng.qa.exploratory-session-rules.md`
-> 📤 **Template**: `$IDE/templates/engineering/qa/qa.exploratory-session-template.md`
-> 🔧 **Skill**: `eng-qa-exploratory`
-
-### Skills invocados durante o workflow
-
-| Passo | Skill | Condição |
-|-------|-------|----------|
-| Execução | `/eng-qa-exploratory` | Sempre — invocado via Skill tool (modos `plan`, `document` e `report`) |
-| Execução (modo `document`) | `/eng-qa-bug-report` | Para os bugs S1–S4 identificados na sessão (acionado pela skill `eng-qa-exploratory`) |
-| Execução (modo `report`) | `/eng-qa-bug-report` | Para criar em lote os cards de bug do documento de sessão (acionado pela skill `eng-qa-exploratory`) |
-
----
-
-## Entrada
-
-```
-#$ARGUMENTS
-```
-
-Aceita: nome da feature/módulo a explorar, ou caminho de doc de sessão já realizada.
-
-**Se não receber argumentos**, a skill perguntará o modo desejado:
-- `plan` — planejar sessão antes de executar
-- `document` — registrar achados de sessão já realizada
-- `report` — processar doc e criar bug cards
-
----
-
-## Execução
-
-Invocar Skill tool: `eng-qa-exploratory`
-
-A skill irá (modo `plan`):
-1. Coletar escopo, contexto, tempo disponível e ambiente
-2. Analisar riscos e gerar hipóteses priorizadas
-3. Criar doc de sessão em `$SESSIONS_DIR/qa/EXP-{YYYYMMDD}-{N}.md`
-
-A skill irá (modo `document`):
-1. Carregar doc de sessão existente
-2. Coletar achados em linguagem natural do QA
-3. Classificar severidade e preencher o documento
-4. Acionar `eng-qa-bug-report` para bugs S1–S4
-
-A skill irá (modo `report`):
-1. Processar doc de sessão
-2. Criar todos os cards de bug em batch via `eng-qa-bug-report`
-
----
-
-## Output
-
-- `$SESSIONS_DIR/qa/EXP-{ID}.md` — documento de sessão estruturado
-- Cards criados no $TASK_MANAGER para cada bug S1–S4