jarvis-ai-framework 2.1.1 → 3.2.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-bug-report/references/1-integracao-task-managers.md

@@ -1,148 +0,0 @@
-# Integração com Task Managers (Adapter Pattern)
-
-> Parte do skill `eng-qa-bug-report`. Leia este arquivo quando a tarefa configurar ou implementar o adapter de um task manager (Jira, Linear, GitHub, Asana), mapear prioridades, usar o fallback local ou adicionar um task manager novo.
-
-## Integração com Task Managers (Adapter Pattern)
-
-### Arquitetura de Adapters
-
-O skill usa **Adapter Pattern** para suportar múltiplos task managers de forma desacoplada.
-
-```
-bug-report skill
-    ↓
-[Adapter Layer]
-    ↓
-┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
-│  JIRA   │ ClickUp │ Linear  │ Trello  │ GitHub  │ GitLab  │
-└─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
-```
-
-### Task Managers alinhados ao ENV-template
-
-| Task Manager | Método | Requer |
-|--------------|--------|--------|
-| **jira** | MCP Atlassian | MCP ou `TOKEN_TASK_MANAGER` + `PROJECT_KEY` |
-| **linear** | CLI | `linear` CLI + `LINEAR_TEAM_ID` |
-| **github** | gh CLI | `gh` autenticado |
-| **asana** | token | `TOKEN_TASK_MANAGER` (criação manual se adapter incompleto) |
-| **(vazio) / local** | Arquivo local | Freelance — `$SESSIONS_DIR/qa/bug-reports/` |
-
-Valores no ENV.md são **minúsculos** (`jira`, não `JIRA`).
-
-### Configuração no ENV.md
-
-#### Jira
-```bash
-TASK_MANAGER=jira
-TOKEN_TASK_MANAGER=your_jira_token  # Opcional se usar MCP
-PROJECT_KEY=PROJ
-```
-
-#### Linear
-```bash
-TASK_MANAGER=linear
-TOKEN_TASK_MANAGER=lin_api_your_token
-LINEAR_TEAM_ID=team-id
-```
-
-#### GitHub
-```bash
-TASK_MANAGER=github
-# Token via gh auth / GITHUB_TOKEN
-```
-
-#### Freelance / local
-```bash
-TASK_MANAGER=
-# Cards em $SESSIONS_DIR/qa/bug-reports/
-```
-
-#### GitLab
-```bash
-TASK_MANAGER=GITLAB
-GITLAB_REPO=group/project
-# Token via glab CLI (glab auth login)
-```
-
-### Implementação de Adapter
-
-Cada adapter implementa a interface:
-
-```bash
-create_task_card() {
-  # Input:
-  #   $1 - title (string)
-  #   $2 - description (markdown/text)
-  #   $3 - priority (P0/P1/P2/P3)
-  #   $4 - category (string)
-  #   $5 - labels (comma-separated)
-
-  # Output:
-  #   Card ID/Key (string) ou caminho do arquivo local
-
-  # Return:
-  #   0 - Sucesso
-  #   1 - Falha
-}
-```
-
-### Mapeamento de Prioridades
-
-Diferentes task managers usam sistemas de prioridade diferentes:
-
-| Framework | P0 | P1 | P2 | P3 |
-|-----------|----|----|----|----|
-| **Jira** | Highest | High | Medium | Low |
-| **ClickUp** | 1 | 2 | 3 | 4 |
-| **Linear** | 1 | 2 | 3 | 4 |
-| **Trello** | Label:P0 | Label:P1 | Label:P2 | Label:P3 |
-| **GitHub** | Label:priority-critical | Label:priority-high | Label:priority-medium | Label:priority-low |
-| **GitLab** | Label:priority::1 | Label:priority::2 | Label:priority::3 | Label:priority::4 |
-
-### Fallback Local
-
-Se task manager indisponível ou não configurado:
-1. Card salvo em `$SESSIONS_DIR/qa/bug-reports/bug-{timestamp}.md`
-2. Arquivo contém todas as informações necessárias
-3. Usuário pode criar card manualmente ou configurar integração
-
-### Como Adicionar Novo Task Manager
-
-Para adicionar suporte a um novo task manager:
-
-1. **Adicionar detecção** na seção de pré-requisitos:
-```bash
-NOTION)
-  if [ -n "$TOKEN_TASK_MANAGER" ]; then
-    TASK_MANAGER_ENABLED=true
-    echo "✅ Integração Notion disponível"
-  fi
-  ;;
-```
-
-2. **Implementar adapter** na função `create_task_card()`:
-```bash
-NOTION)
-  CARD_ID=$(curl -s -X POST "https://api.notion.com/v1/pages" \
-    -H "Authorization: Bearer $TOKEN_TASK_MANAGER" \
-    -H "Content-Type: application/json" \
-    -d '{
-      "parent": {"database_id": "'$(grep '^NOTION_DATABASE_ID=' "$IDE/ENV.md" | cut -d= -f2)'"},
-      "properties": {
-        "Name": {"title": [{"text": {"content": "'"$title"'"}}]},
-        "Priority": {"select": {"name": "'"$priority"'"}},
-        "Category": {"select": {"name": "'"$category"'"}}
-      }
-    }' | jq -r '.id')
-
-  echo "✅ Card criado no Notion: $CARD_ID"
-  echo "$CARD_ID"
-  ;;
-```
-
-3. **Documentar configuração** na seção acima
-
-4. **Adicionar teste** para validar funcionamento
-
----

package/skills/eng-qa-bug-report/references/2-exemplos-de-uso.md

@@ -1,46 +0,0 @@
-# Exemplos de Uso
-
-> Parte do skill `eng-qa-bug-report`. Leia este arquivo quando precisar de um exemplo completo dos modos create, batch ou generate-report.
-
-## Exemplos de Uso
-
-### Exemplo 1: Criar card único (BUG-ALTO — todos os campos P1 obrigatórios)
-
-```bash
-/eng-qa-bug-report create \
-  --title="[auth] Token expirado retorna 500 ao invés de 401" \
-  --category="BUG-ALTO" \
-  --severity="P1" \
-  --environment="prod" \
-  --location="src/auth/token-validator.ts:67" \
-  --description="Quando o token JWT expira durante uma requisição autenticada, o serviço retorna HTTP 500 ao invés de 401. Ocorre de forma recorrente em produção para todos os usuários com sessão ativa há mais de 24h." \
-  --behavior-actual="POST /auth/validate retorna 500 Internal Server Error quando token está expirado" \
-  --behavior-expected="POST /auth/validate retorna 401 Unauthorized com body {error: 'token_expired'}" \
-  --reproduction="Pré-condição: usuário com token expirado (criado há >24h). Passos: 1. Fazer qualquer requisição autenticada. 2. Observar resposta. Resultado atual: HTTP 500." \
-  --impact="Todos os usuários com sessão ativa há mais de 24h — estimativa de 30% da base ativa. App client não consegue tratar 500 como sessão expirada, causando loop de erro sem logout automático." \
-  --entry-endpoint="POST /auth/validate" \
-  --affected-services="account,auth" \
-  --correlation-id="req-a1b2c3d4" \
-  --frequency="recorrente" \
-  --linked-to="PROJ-999" \
-  --suggestion="Adicionar catch específico para TokenExpiredError antes do handler genérico de erros"
-```
-
-### Exemplo 2: Criar cards em batch
-
-```bash
-/eng-qa-bug-report batch \
-  --from-audit="./sessions/bug-audit-20260208/bug-audit-report.md" \
-  --priority-filter="P0,P1"
-```
-
-### Exemplo 3: Gerar relatório
-
-```bash
-/eng-qa-bug-report generate-report \
-  --bugs="./sessions/bugs-found.json" \
-  --output="./sessions/consolidated-bug-report.md" \
-  --format="markdown"
-```
-
----

package/skills/eng-qa-bug-report/references/3-bug-to-test.md

@@ -1,45 +0,0 @@
-# Bug-to-Test (pós-criação)
-
-> Parte do skill `eng-qa-bug-report`. Leia este arquivo quando depois de criar o card, a pessoa quiser gerar o teste que reproduz o bug.
-
-## Bug-to-Test (pós-criação)
-
-Após criar o card no $TASK_MANAGER, sempre perguntar:
-
-```
-Bug registrado: {TASK-ID} — {título}
-
-Deseja gerar um teste de regressão Cypress para este bug?
-Recomendado: previne que o bug retorne após o fix.
-
-[S] Gerar agora
-[N] Registrar no backlog de cobertura
-[P] Pular
-```
-
-### Se "Gerar agora"
-
-Invocar Skill tool: `eng-qa-cypress-e2e` passando como entrada:
-- Título do bug como nome do fluxo
-- Passos de reprodução como sequência de ações
-- Comportamento esperado vs. atual como asserções
-
-Nomear o spec: `{dominio}/{TASK-ID}-regression.cy.ts`
-
-Após gerar o teste, adicionar comentário no card do bug com o caminho do arquivo criado.
-
-### Se "Registrar no backlog"
-
-Append em `$DOCS_FOLDER/engineering/qa/test-backlog.md` (criar se não existir):
-
-```markdown
-| {TASK-ID} | {título} | {domínio} | {dominio}/{TASK-ID}-regression.cy.ts |
-```
-
-Cabeçalho da tabela (inserir apenas se o arquivo for novo):
-```markdown
-# Test Backlog — Testes de Regressão Pendentes
-
-| Bug ID | Título | Domínio | Spec sugerida |
-|--------|--------|---------|---------------|
-```

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

@@ -1,184 +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`
-
-### Skills invocados durante a execução do skill
-
-| Passo | Skill | Condição |
-|-------|-------|----------|
-| — | Nenhuma — skill autocontida | — |
-
----
-
-## 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