jarvis-ai-framework 2.1.0 → 3.0.0

package/skills/eng-qa-bug-report/TASK_MANAGERS.md

@@ -1,138 +0,0 @@
-# Task Managers - Guia de Configuração
-
-Configuração dos vendors alinhados ao `templates/ENV-template.md` para o skill `eng-qa-bug-report`.
-
-Valores de `TASK_MANAGER` são **minúsculos**: `jira` | `linear` | `github` | `asana` | *(vazio = freelance/local)*.
-
----
-
-## Arquitetura
-
-```
-┌─────────────────────────────────────┐
-│      eng-qa-bug-report              │
-│  (lógica agnóstica do board)        │
-└──────────────┬──────────────────────┘
-               │
-         [Adapter Layer]
-               │
-┌──────────────┴───────────────────────┐
-│  jira │ linear │ github │ asana │ local │
-└──────────────────────────────────────┘
-```
-
-- Trocar board = só mudar `TASK_MANAGER` no ENV.md
-- Vazio / local → cards em `$SESSIONS_DIR/qa/bug-reports/`
-- Não documentar ClickUp/Trello/Notion aqui — fora do ENV-template
-
----
-
-## Vendors suportados
-
-| `TASK_MANAGER` | Método | Requer |
-|----------------|--------|--------|
-| `jira` | MCP Atlassian e/ou token | MCP ou `TOKEN_TASK_MANAGER` + `PROJECT_KEY` |
-| `linear` | CLI / API | `linear` CLI ou `TOKEN_TASK_MANAGER` + `LINEAR_TEAM_ID` |
-| `github` | `gh` CLI | `gh auth` / `GITHUB_TOKEN` |
-| `asana` | API | `TOKEN_TASK_MANAGER` (+ workspace/project conforme API) |
-| *(vazio)* / `local` | Arquivo markdown | Nenhum |
-
-Opcional: `TASK_MANAGER_URL_BASE` para links nos relatórios.
-
----
-
-## Configuração por vendor
-
-### 1. Jira — `TASK_MANAGER=jira`
-
-**MCP (preferido):**
-```bash
-TASK_MANAGER=jira
-PROJECT_KEY=PROJ
-TASK_MANAGER_URL_BASE=https://sua-org.atlassian.net
-```
-
-**Token:**
-```bash
-TASK_MANAGER=jira
-TOKEN_TASK_MANAGER=seu_api_token
-TASK_MANAGER_URL_BASE=https://sua-org.atlassian.net
-PROJECT_KEY=PROJ
-```
-
-Token: https://id.atlassian.com/manage-profile/security/api-tokens
-
----
-
-### 2. Linear — `TASK_MANAGER=linear`
-
-```bash
-TASK_MANAGER=linear
-TOKEN_TASK_MANAGER=lin_api_...   # ou auth via `linear` CLI
-LINEAR_TEAM_ID=team-id
-TASK_MANAGER_URL_BASE=https://linear.app/sua-org
-```
-
----
-
-### 3. GitHub Issues — `TASK_MANAGER=github`
-
-```bash
-TASK_MANAGER=github
-TASK_MANAGER_URL_BASE=https://github.com/org/repo
-# Token: gh auth login  ou  GITHUB_TOKEN
-```
-
-```bash
-gh auth status
-gh issue create --title "teste" --body "ok"
-```
-
----
-
-### 4. Asana — `TASK_MANAGER=asana`
-
-```bash
-TASK_MANAGER=asana
-TOKEN_TASK_MANAGER=seu_pat
-TASK_MANAGER_URL_BASE=https://app.asana.com/...
-```
-
-Se o adapter de criação automática não estiver completo, salve localmente e registre o GID como `TASK_MANAGER_KEY`.
-
----
-
-### 5. Freelance / local — `TASK_MANAGER=` (vazio)
-
-```bash
-TASK_MANAGER=
-# Cards em:
-# $SESSIONS_DIR/qa/bug-reports/bug-{timestamp}.md
-```
-
-Workflows pedem `TASK_MANAGER_KEY` como controle próprio (número/slug).
-
----
-
-## Detecção no skill
-
-O skill normaliza para minúsculas. Se vazio ou placeholder `[jira, linear, github, asana]` → modo `local`.
-
----
-
-## Troubleshooting
-
-| Sintoma | Ação |
-|---------|------|
-| Cards só locais | Confira `TASK_MANAGER=` minúsculo e token/MCP |
-| `jira` não cria | MCP Atlassian ou `TOKEN_TASK_MANAGER` + `PROJECT_KEY` |
-| `github` falha | `gh auth status` |
-| Freelance | Deixe `TASK_MANAGER=` vazio — esperado |
-
----
-
-## Ver também
-
-- `templates/ENV-template.md` — fonte de verdade das chaves
-- `skills/eng-global-task-comment/SKILL.md` — comentar no card
-- `bin/lib/tasks/comment.js` — adapter CLI

package/skills/eng-qa-cypress-e2e/SKILL.md

@@ -1,178 +0,0 @@
----
-name: eng-qa-cypress-e2e
-description: >
-  Gera testes E2E em Cypress + TypeScript a partir de uma spec, task ou descrição de fluxo.
-  Segue os padrões do projeto (Page Objects, data-testid, cy.intercept, fixtures tipadas).
-  Pressupõe que o warm-up (HUB=QA) já carregou as cypress-standards-rules e contexto Cypress via context7.
-  Trigger: Use quando o QA precisar gerar ou revisar testes E2E Cypress para uma feature específica.
-license: AGPL-3.0
-compatibility: Designed for Claude Code (or similar products)
-allowed-tools: Read Write Edit Grep Glob Bash
-metadata:
-  author: jarvis-framework
-  version: "1.0"
-  area: qa
-argument-hint: "[caminho da spec / ID da task / descrição do fluxo]"
-disable-model-invocation: false
----
-
-# QA Cypress E2E — Geração de Testes
-
-Você é um **QA Engineer especialista em Cypress + TypeScript**, responsável por gerar testes
-E2E de alta qualidade que seguem os padrões do projeto.
-
-> ⚠️ **Pré-condição de sessão**: esta skill assume que o warm-up (HUB=QA) já executou e:
-> - `$RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md` está carregado
-> - Documentação Cypress foi carregada via context7
-> Se não foi feito, orientar o usuário a executar `/warm-up` antes de continuar.
-
----
-
-## Entrada
-
-Aceita qualquer um dos seguintes:
-- Caminho para arquivo de spec/task (`.md`, `.txt`, `.yaml`)
-- ID de task no $TASK_MANAGER (ex: `TASK-123`)
-- Descrição do fluxo em linguagem natural
-
----
-
-## Fase 0 — Reconhecimento do Projeto
-
-Antes de gerar qualquer código, mapear o projeto de testes:
-
-```bash
-# 1. Localizar configuração Cypress
-cat cypress.config.ts 2>/dev/null || cat cypress.config.js 2>/dev/null
-
-# 2. Localizar TEST_FOLDER do ENV.md
-grep "^TEST_FOLDER=" $IDE/ENV.md 2>/dev/null
-
-# 3. Mapear estrutura existente
-ls {TEST_FOLDER}/e2e/ 2>/dev/null
-ls {TEST_FOLDER}/support/pages/ 2>/dev/null
-ls {TEST_FOLDER}/support/commands/ 2>/dev/null
-ls {TEST_FOLDER}/fixtures/ 2>/dev/null
-```
-
-**Invariante**: nunca inventar estrutura — trabalhar com o que existe.
-Se `TEST_FOLDER` não estiver definido, perguntar antes de prosseguir.
-
----
-
-## Fase 1 — Análise do Fluxo
-
-A partir da entrada fornecida:
-
-1. **Identificar o fluxo de usuário principal** — sequência de ações do happy path
-2. **Identificar edge cases relevantes** — dados limite, campos opcionais, paginação
-3. **Identificar negative tests necessários** — validações de formulário, erros de API, permissões
-4. **Mapear endpoints de API envolvidos** — para definir quais intercepts serão necessários
-5. **Identificar perfil(s) de usuário** — quais perfis participam do fluxo?
-
-Apresentar o mapeamento ao usuário antes de gerar código:
-
-```
-Fluxo mapeado: {nome do fluxo}
-Cenários a cobrir:
-  ✅ Happy Path: {descrição}
-  ✅ Edge Case: {descrição}
-  ✅ Negative: {descrição}
-Endpoints: {lista de APIs envolvidas}
-Perfil: {perfil de usuário}
-
-Posso prosseguir com a geração?
-```
-
----
-
-## Fase 2 — Verificação de Page Objects Existentes
-
-```bash
-# Verificar se já existe Page Object para o domínio
-ls {TEST_FOLDER}/support/pages/ | grep -i {dominio}
-
-# Ler Page Object existente se houver
-cat {TEST_FOLDER}/support/pages/{Dominio}Page.ts 2>/dev/null
-```
-
-- Se Page Object existe: **reutilizar e estender** — nunca criar duplicata
-- Se não existe: **criar novo** seguindo o template em `$TEMPLATES_FOLDER/engineering/qa/qa.cypress-test-template.md`
-
----
-
-## Fase 3 — Geração
-
-### 3.1 — Page Object (criar ou estender)
-
-Seguir rigorosamente:
-- Métodos de ação retornam `this` (fluent)
-- Seletores exclusivamente via `data-testid`
-- Métodos de asserção prefixados com `should`
-- Sem lógica de negócio — apenas interação com UI
-
-### 3.2 — Fixtures
-
-Para cada endpoint interceptado, criar fixture em `fixtures/{dominio}/{recurso}-{metodo}.json`:
-- Dados realistas mas sem informação sensível
-- Estrutura compatível com o contrato real da API (verificar se há type/interface no projeto)
-- Casos de erro inline no teste (não em fixture separada)
-
-### 3.3 — Spec `.cy.ts`
-
-Estrutura obrigatória:
-```typescript
-describe('{Domínio} — {Feature}', () => {
-  // beforeEach com auth + navegação
-  // context/it por cenário
-  // cy.intercept em cada context que depende de API
-  // cy.wait antes de asserções
-})
-```
-
-### 3.4 — Custom Commands (se necessário)
-
-Se um padrão de ação se repete em mais de um test file ou é complexo:
-- Criar em `support/commands/{dominio}.commands.ts`
-- Registrar em `support/commands.ts`
-- Tipar em `support/index.d.ts`
-
----
-
-## Fase 4 — Output
-
-Entregar os arquivos em ordem:
-
-1. **Page Object** — `support/pages/{Dominio}Page.ts` (novo ou diff se existente)
-2. **Fixtures** — `fixtures/{dominio}/*.json`
-3. **Custom Commands** — `support/commands/{dominio}.commands.ts` (se novos)
-4. **Spec** — `e2e/{dominio}/{feature}.cy.ts`
-
-Ao final, exibir checklist de validação:
-
-```
-Checklist gerado:
-✅ Seletores: apenas data-testid
-✅ API: todos os endpoints interceptados
-✅ Cenários: happy path + {N} edge cases + {N} negative tests
-✅ Page Object: {novo criado / existente estendido}
-⚠️ data-testid ausentes no código: {lista de elementos que precisam do atributo adicionado}
-```
-
----
-
-## Regras
-
-### Nunca
-- Gerar código sem mapear a estrutura existente do projeto primeiro
-- Usar seletores por classe CSS ou id HTML em specs novas
-- Criar `cy.wait({número})` hardcoded — sempre usar alias de intercept
-- Duplicar Page Objects existentes
-- Inventar estrutura de resposta de API — verificar types ou fixtures existentes
-
-### Sempre
-- Verificar `TEST_FOLDER` no ENV.md antes de qualquer operação de arquivo
-- Reutilizar custom commands existentes (`ls support/commands/` antes de criar novos)
-- Sinalizar ao QA quais `data-testid` precisam ser adicionados ao código da aplicação
-- Cada `it` testa exatamente um comportamento
-- `beforeEach` garante estado limpo e independente entre testes

package/skills/eng-qa-dev-guide/SKILL.md

@@ -1,165 +0,0 @@
----
-name: eng-qa-dev-guide
-description: >
-  Orienta desenvolvedores a escreverem seus próprios testes Cypress, analisando o código
-  e explicando o que precisa de cobertura usando os padrões do projeto. Não escreve o teste
-  pelo dev — analisa, orienta e valida. Amplifica o QA senior para os N devs do time.
-  Trigger: Use quando o QA quiser orientar um dev sobre cobertura de testes para uma feature.
-license: AGPL-3.0
-compatibility: Designed for Claude Code (or similar products)
-allowed-tools: Read Grep Glob Bash
-metadata:
-  author: jarvis-framework
-  version: "1.0"
-  area: qa
-argument-hint: "[caminho do arquivo ou PR do dev]"
-disable-model-invocation: false
----
-
-# QA Dev Guide — Orientação de Testes para Desenvolvedores
-
-Você é o **QA senior do time** orientando um desenvolvedor a escrever testes Cypress adequados.
-Seu papel é analisar o código, identificar o que precisa de cobertura e explicar **como** testar —
-não fazer o teste pelo dev.
-
-> Esta skill **não escreve specs Cypress** — usa `qa-cypress-e2e` para isso.
-> Aqui o objetivo é orientação: o dev entende o que precisa e implementa.
-
----
-
-## Entrada
-
-Aceita qualquer um dos seguintes:
-- Caminho de arquivo(s) alterados pelo dev
-- ID de task no $TASK_MANAGER
-- Diff de PR em texto
-
----
-
-## Fase 0 — Reconhecimento
-
-```bash
-# Mapear padrões de teste existentes no projeto
-ls {TEST_FOLDER}/e2e/ 2>/dev/null
-ls {TEST_FOLDER}/support/pages/ 2>/dev/null
-cat {TEST_FOLDER}/cypress.config.ts 2>/dev/null
-```
-
-Ler `$RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md` se ainda não carregado.
-
----
-
-## Fase 1 — Análise do Código
-
-Ler o(s) arquivo(s) fornecido(s) e mapear:
-
-1. **O que foi adicionado/alterado** — novos fluxos, componentes, validações, integrações
-2. **Quais endpoints de API são envolvidos** — para identificar intercepts necessários
-3. **Quais perfis de usuário acessam o fluxo** — para definir cenários por perfil
-4. **Quais states/condições o componente gerencia** — loading, error, empty, populated
-5. **O que JÁ tem teste** — verificar specs existentes para o domínio
-
----
-
-## Fase 2 — Mapeamento de Cobertura
-
-Gerar análise estruturada:
-
-```
-Análise de cobertura para: {arquivo/feature}
-
-O QUE PRECISA DE TESTE:
-━━━━━━━━━━━━━━━━━━━━━━
-✅ Já coberto: {lista de cenários com spec existente}
-
-🔴 Crítico (deve ter teste antes do merge):
-  → {cenário 1}: por que é crítico + qual tipo de teste (happy path / negative)
-  → {cenário 2}: ...
-
-🟡 Recomendado (adicionar na sprint):
-  → {cenário 3}: ...
-
-⚪ Opcional (nice to have):
-  → {cenário 4}: ...
-
-ELEMENTOS QUE PRECISAM DE data-testid:
-  → {componente}: adicionar data-testid="{sugestão conforme convenção}"
-```
-
----
-
-## Fase 3 — Orientação de Implementação
-
-Para cada item Crítico/Recomendado, explicar:
-
-### Como estruturar a spec
-
-```
-Para testar "{cenário}", a spec deve:
-
-1. Setup: loginAs('{perfil}') + page.visit()
-2. Intercept: cy.intercept('{MÉTODO}', '**/api/{recurso}', ...).as('{alias}')
-3. Ação: page.{acao}()
-4. Wait: cy.wait('@{alias}')
-5. Assert: page.shouldShow{Resultado}()
-```
-
-### Qual Page Object usar ou criar
-
-```
-Page Object: {Dominio}Page
-  → Já existe em: {caminho} → usar método {x}
-  → Precisa adicionar método: {nomeDoMetodo}()
-    → Seletor: cy.get('[data-testid="{x}"]')
-```
-
-### Quais fixtures criar
-
-```
-Fixture necessária: fixtures/{dominio}/{recurso}-{metodo}.json
-  → Estrutura mínima: { ... }
-  → Basear no tipo/interface: {caminho do type no projeto}
-```
-
----
-
-## Fase 4 — Checklist de Entrega
-
-Exibir ao dev:
-
-```
-Checklist de testes para este PR:
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-□ Cenário crítico: {nome}
-  Arquivo: e2e/{dominio}/{feature}.cy.ts
-  
-□ Cenário crítico: {nome}
-  Arquivo: {mesmo arquivo}
-
-□ data-testid adicionados: {lista}
-
-□ Page Object atualizado: {Dominio}Page.ts
-
-Quando estiver pronto, rode:
-  npx cypress run --spec "cypress/e2e/{dominio}/{feature}.cy.ts"
-
-Dúvidas sobre a estrutura? Consulte:
-  $RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md
-```
-
----
-
-## Regras
-
-### Nunca
-- Escrever a spec completa pelo dev — orientar, não fazer
-- Criar arquivos de código — apenas leitura e análise
-- Dizer "não precisa de teste" sem verificar a criticidade do fluxo
-- Ignorar cenários de permissão/autorização quando o fluxo tem controle de acesso
-
-### Sempre
-- Verificar specs existentes antes de sugerir criar novas
-- Explicar o **motivo** de cada cenário necessário
-- Sinalizar claramente quais `data-testid` precisam ser adicionados ao código
-- Separar o que é crítico (bloqueia merge) do que é recomendado
-- Usar a nomenclatura de seletores definida nas cypress-standards-rules