jarvis-ai-framework 1.0.0

package/workflows/engineering/qa/eng.qa-refinement-entry.md

@@ -0,0 +1,83 @@
+---
+description: Analisa spec/PRD/FRD de uma feature e gera estratégia de testes com critérios de aceite e mapeamento de cenários de risco
+auto_execution_mode: 2
+agent: "$IDE/agents/engineering/qa/eng.qa.test-planner.md"
+model_tier: high
+model_justification: Análise de requisitos e geração de estratégia de testes exige raciocínio profundo
+---
+
+# qa.refinement-entry
+
+Analisa uma spec de feature e gera o documento de estratégia de testes: critérios de aceite,
+mapeamento de cenários de risco e checklist de cobertura necessária.
+
+> 🤖 **Agent**: `eng.qa.test-planner`
+
+---
+
+## Contexto de Execução
+
+Este comando opera em **modo pré-código**: é executado após a tech spec ser escrita e
+antes da codificação começar. A entrada é sempre a especificação do card — não o código.
+
+**Regra obrigatória para o agente**: não executar `git diff` neste contexto.
+A fonte de verdade é o conteúdo do card no $TASK_MANAGER, lido via integração disponível (ex: Jira MCP).
+
+---
+
+## Entrada
+
+```
+#$ARGUMENTS
+```
+
+Aceita: ID de task no $TASK_MANAGER, caminho de spec (PRD/FRD/tech spec), ou descrição da feature.
+
+**Se não receber argumentos**, perguntar:
+- Qual card ou spec você quer mapear para testes?
+
+---
+
+## Execução
+
+O agente `eng.qa.test-planner` irá operar em **Modo A — Estratégia a partir da Tech Spec**:
+
+1. **Buscar o card no $TASK_MANAGER** via integração disponível (Jira MCP) usando o ID fornecido
+2. **Ler a spec** — identificar o fluxo principal, regras de negócio, integrações e restrições
+3. **Mapear riscos** — o que pode falhar? onde está a complexidade? quais dependências?
+4. **Definir critérios de aceite** — mensuráveis e testáveis (não apenas "funciona")
+5. **Gerar estratégia de testes**:
+   - Cenários E2E obrigatórios (happy path + cenários de risco alto)
+   - Cenários de teste exploratório recomendados
+   - O que NÃO precisa de teste automatizado (e por quê)
+6. **Gerar checklist de cobertura** para validação antes do deploy
+
+Não executar `git diff`, `git log` ou qualquer comando que dependa de código implementado.
+O código ainda não existe neste momento do fluxo.
+
+---
+
+## Output
+
+Documento de estratégia de testes salvo em:
+`$DOCS_FOLDER/engineering/qa/strategies/{task-id}-test-strategy.md`
+
+Estrutura do documento:
+```
+# Estratégia de Testes — {feature}
+
+## Critérios de Aceite
+(por cenário, mensuráveis)
+
+## Mapeamento de Risco
+(área × probabilidade × impacto)
+
+## Cenários E2E Obrigatórios
+(lista priorizada)
+
+## Recomendações de Exploratório
+(foco e time-box sugerido)
+
+## Checklist de Deploy
+(o que deve passar antes de ir para produção)
+```

package/workflows/engineering/qa/eng.qa-release-signoff.md

@@ -0,0 +1,170 @@
+---
+description: Sign-off QA pré-deploy — verifica cobertura de testes e bugs abertos para a branch, produz decisão GO/NO-GO
+auto_execution_mode: 2
+env_file: "@/ENV.md"
+recommended_model: claude-sonnet-4-20250514
+model_tier: medium
+model_justification: Leitura de arquivos locais, análise de cobertura e geração de documento estruturado
+---
+
+# qa.release-signoff
+
+Sign-off QA antes de um deploy. Verifica cobertura de testes, sessões exploratórias e bugs abertos para a branch atual, e produz um documento GO/NO-GO.
+
+> ℹ️ O documento gerado é validado automaticamente pelo CI via `jarvis qa-signoff`.
+> Para ativar a validação automática, o TL precisa adicionar o job ao pipeline — o snippet é fornecido ao final.
+
+## Entrada
+
+```
+#$ARGUMENTS
+```
+
+Aceita: nome da branch (padrão: branch atual via `git branch --show-current`).
+
+---
+
+## Fase 0 — Identificar branch e mudanças
+
+```bash
+# Branch atual (se não passada como argumento)
+git branch --show-current
+
+# Tasks incluídas neste deploy
+git log origin/main..HEAD --oneline
+
+# Arquivos alterados
+git diff origin/main...HEAD --name-only
+```
+
+---
+
+## Fase 1 — Verificar cobertura
+
+Para cada domínio/área afetada pelas mudanças:
+
+**1. Testes E2E**
+```bash
+ls $TEST_FOLDER/e2e/ 2>/dev/null
+```
+Verificar se existe spec cobrindo o domínio. Confrontar com arquivos alterados.
+
+**2. Sessão exploratória**
+```bash
+ls $SESSIONS_DIR/qa/ 2>/dev/null | grep -i {dominio}
+```
+Verificar se foi realizada sessão para a feature.
+
+**3. Quality gate**
+```bash
+ls $DOCS_FOLDER/engineering/qa/ 2>/dev/null | grep -i "quality-gate\|qg"
+```
+Verificar se a spec passou pelo quality gate antes da sprint.
+
+---
+
+## Fase 2 — Verificar bugs abertos
+
+Buscar no $TASK_MANAGER bugs abertos relacionados às tasks do deploy:
+
+```
+Buscar: type = Bug AND status != Done AND linkedIssue in ({tasks_do_deploy})
+```
+
+Para cada bug encontrado, apresentar ao QA:
+- É bloqueador para este deploy?
+- Aceitar com ressalva (documentar motivo)?
+- Não relacionado ao deploy atual?
+
+---
+
+## Fase 3 — Decisão GO / NO-GO
+
+| Condição | Decisão |
+|----------|---------|
+| Toda cobertura crítica atendida, nenhum bug bloqueador | ✅ GO |
+| Cobertura atendida, bugs não-bloqueadores documentados | ✅ GO com ressalvas |
+| Cobertura crítica ausente OU bug bloqueador em aberto | 🚫 NO-GO |
+
+Apresentar a decisão ao QA para confirmação antes de salvar.
+
+---
+
+## Fase 4 — Gerar documento
+
+Usar template `$TEMPLATES_FOLDER/engineering/qa/qa.release-signoff-template.md`.
+
+Salvar em:
+```
+$DOCS_FOLDER/engineering/qa/signoffs/signoff-{branch-slug}-{YYYYMMDD}.md
+```
+
+> O frontmatter **deve** conter `status: GO` ou `status: NO-GO` — o CLI `jarvis qa-signoff` lê este campo.
+
+---
+
+## Fase 5 — Setup CI (condicional, apenas na primeira vez)
+
+Verificar se o job de sign-off já existe no pipeline:
+
+```bash
+grep -l "qa-signoff\|jarvis qa-signoff" .gitlab-ci.yml .github/workflows/*.yml 2>/dev/null
+```
+
+Se **já encontrado** → pular silenciosamente.
+
+Se **não encontrado**:
+
+**1. Identificar o Tech Lead do squad**
+
+Ler `members.md` e buscar o membro com `TECH LEAD` na seção do squad atual (`SQUAD` do ENV.md):
+
+```bash
+grep -A 20 "^## $SQUAD" members.md | grep -i "TECH LEAD"
+```
+
+Extrair nome e Slack ID do TL encontrado.
+
+**2. Enviar mensagem automática via $MESSAGE_COMUNICATOR**
+
+Enviar Slack DM para o Slack ID do TL com o seguinte conteúdo:
+
+```
+📋 *Setup QA Sign-off — {WORKSPACE}*
+
+Olá, {nome_do_tl}! O QA {nome_do_qa} configurou o sign-off automático de release.
+
+Para ativar a validação no pipeline CI, adicione ao `.gitlab-ci.yml`:
+
+```yaml
+qa-signoff:
+  stage: validate
+  script:
+    - npx jarvis qa-signoff --branch $CI_COMMIT_REF_NAME
+  rules:
+    - if: $CI_COMMIT_BRANCH =~ /^(main|master|release\/.*)$/
+  allow_failure: false
+```
+
+*Pré-requisito:* `jarvis-framework` em `devDependencies` (já instalado se o projeto usa Jarvis).
+
+Após o merge, todo push para `main`/`release/*` será validado automaticamente. ✅
+```
+
+**3. Confirmar ao QA**
+
+```
+✅ Mensagem enviada para {nome_do_tl} via Slack.
+   O CI será ativado assim que ele adicionar o job ao pipeline.
+```
+
+Se $MESSAGE_COMUNICATOR não estiver configurado ou o TL não tiver Slack ID em `members.md`:
+- Exibir o snippet na tela para envio manual
+- Avisar: "Configure MESSAGE_COMUNICATOR no ENV.md para envios automáticos futuros."
+
+---
+
+## Output
+
+- `$DOCS_FOLDER/engineering/qa/signoffs/signoff-{branch-slug}-{YYYYMMDD}.md` — documento de sign-off
+- Snippet CI (apenas na primeira execução, se pipeline ainda não configurado)

package/workflows/engineering/qa/eng.qa-sprint-planning.md

@@ -0,0 +1,100 @@
+---
+description: Planejamento de capacidade QA para uma sprint — avalia risco de cada task e distribui entre QAs e Quality Champions
+auto_execution_mode: 2
+env_file: "@/ENV.md"
+rules_file: "$IDE/rules/engineering/qa/eng.qa.cypress-standards-rules.md"
+recommended_model: claude-sonnet-4-20250514
+model_tier: high
+model_justification: Análise de risco multi-task e alocação de capacidade requer raciocínio estratégico
+---
+
+# qa.sprint-planning
+
+Planejamento de capacidade QA para a sprint: avalia risco de cada task, considera QAs e Quality Champions disponíveis, e produz um plano de alocação baseado em critérios de risco.
+
+## Entrada
+
+```
+#$ARGUMENTS
+```
+
+Aceita: sprint ID, nome ou número (ex: `Sprint 42`, `42`, `sprint-42`).
+
+**Se não receber argumentos**, perguntar:
+- Qual sprint deseja planejar? (ID ou nome conforme o $TASK_MANAGER)
+
+---
+
+## Fase 0 — Reconhecimento de Capacidade
+
+Antes de buscar tasks, mapear a equipe disponível:
+
+```bash
+# Ler QAs e Quality Champions do members.md
+grep -A 50 "^## QA" members.md
+grep "Quality Champion" members.md
+```
+
+Extrair:
+- **QAs**: membros da seção `## QA` do `members.md`
+- **Quality Champions**: membros com `Quality Champion` no campo Posição (em qualquer squad)
+- Capacidade Champions: `QA_CHAMPION_CAPACITY` do ENV.md (padrão: 30%)
+
+Se `members.md` não existir ou não tiver seção QA, perguntar ao usuário antes de prosseguir.
+
+---
+
+## Fase 1 — Buscar Tasks da Sprint
+
+```bash
+# Via $TASK_MANAGER — adaptar query ao sistema configurado
+# Jira (JQL):
+# project = $PROJECT AND sprint = "{sprint}" AND type != Epic
+# AND status in ("To Do", "In Progress", "In Review")
+```
+
+Se $TASK_MANAGER não estiver configurado: pedir ao usuário que cole a lista de tasks.
+
+---
+
+## Fase 2 — Análise de Risco
+
+Invocar agente [eng.qa.quality-strategist]($IDE/agents/engineering/qa/eng.qa.quality-strategist.md) para avaliar cada task:
+
+Para cada task, o agente determina:
+- **Risco**: Alto / Médio / Baixo
+- **Cobertura ideal**: E2E / exploratório / quality gate / delegar ao dev
+- **Justificativa**: área do sistema, complexidade, histórico de bugs do domínio
+
+---
+
+## Fase 3 — Alocação
+
+Com base no risco e na capacidade mapeada na Fase 0:
+
+| Risco | Regra de alocação |
+|-------|------------------|
+| Alto | QA obrigatório — não delegar a Champion |
+| Médio | QA preferencial; Champion se QA sobrecarregado |
+| Baixo | Champion ou delegar ao dev via eng-qa-dev-guide |
+
+**Detectar sobrecarga**: se demanda > capacidade total, sinalizar quais tasks ficam sem cobertura designada e sugerir redução de escopo nos itens de menor risco.
+
+---
+
+## Fase 4 — Gerar Plano
+
+Usando o template `$TEMPLATES_FOLDER/engineering/qa/qa.sprint-plan-template.md`, gerar o plano e salvar em:
+
+```
+$DOCS_FOLDER/engineering/qa/sprints/sprint-plan-{sprint-slug}.md
+```
+
+Exibir o plano ao usuário e perguntar se há ajustes antes de salvar.
+
+---
+
+## Output
+
+- `$DOCS_FOLDER/engineering/qa/sprints/sprint-plan-{sprint-slug}.md` — plano de alocação da sprint
+- Pronto para compartilhar com o time ou colar no $TASK_MANAGER

package/workflows/engineering/ta/eng.ta.atendimento.md

@@ -0,0 +1,93 @@
+---
+description: Fluxo principal do Tech Analyst — diagnóstico, triagem e resolução/escalonamento de chamados técnicos
+version: "1.0"
+auto_execution_mode: 2
+agent: "$IDE/agents/engineering/eng.tech-analyst.agent.md"
+model_tier: medium
+model_justification: Diagnóstico técnico, classificação de bugs e geração de tickets Jira — requer raciocínio estruturado mas não análise arquitetural profunda
+---
+
+# eng.ta.atendimento — Atendimento Técnico
+
+## Objetivo
+
+Conduzir o Tech Analyst pelo fluxo completo de atendimento de chamados:
+desde a recepção do ticket do suporte N2 até resolução ou escalonamento qualificado.
+
+---
+
+## Entrada
+
+<ticket>
+#$ARGUMENTS
+</ticket>
+
+**Se não receber argumentos**, perguntar ao usuário:
+- Qual o ID ou descrição do chamado que precisa ser atendido?
+
+---
+
+## Fase 0 — Carregar Contexto
+
+Ler do ENV.md:
+- `SQUAD` — squad do Tech Analyst
+- `USER` — email do Tech Analyst
+- `SLACK_ID` — ID Slack para comunicações
+
+Registrar timestamp de início do atendimento.
+
+---
+
+## Fase 1 — Triagem Inicial
+
+Invocar o skill `eng-tech-analyst` para conduzir o fluxo:
+
+```
+Skill tool: eng-tech-analyst
+Contexto: {descrição do chamado ou ID do ticket}
+```
+
+O skill conduzirá:
+1. Verificação de completude da descrição
+2. Busca de existência no Jira
+3. Classificação da área e avaliação de impacto
+4. Decisão: resolver ou escalar
+
+---
+
+## Fase 2 — Confirmação
+
+Informar ao usuário:
+
+```
+✅ Atendimento encerrado
+
+📋 Ticket: {ID}
+🔍 Diagnóstico: {resumo}
+📁 Área: {FRONT|BACK|BD|PROCESSO}
+📊 Impacto: {alto|baixo}
+🎯 Desfecho: {Resolvido pelo Tech Analyst | Escalado para PM | Enviado para backlog | Bug existente — frequência atualizada}
+
+{se criou Jira}
+🐛 Jira: {URL do ticket criado}
+
+{se comunicou PM ou QA}
+💬 Comunicação enviada para {PM|QA} via Slack
+```
+
+---
+
+## Regras do Workflow
+
+- **Não avançar** sem descrição mínima do problema (Passo 1 do skill)
+- **Não escalar** sem ter classificado área e avaliado impacto
+- **Não escrever** no banco de dados — somente leitura
+- **Sempre** registrar no HS o desfecho do atendimento
+
+---
+
+## Skills Utilizados
+
+| Skill | Quando |
+|-------|--------|
+| `eng-tech-analyst` | Fluxo principal de triagem e decisão |

package/workflows/product/prod.roadmap.preview.md

@@ -0,0 +1,110 @@
+---
+name: prod.roadmap.preview
+description: Conhecer e ter visibilidade do roadmap de entregas planejadas do produto, como períodos de entrega, nome dos projetos e responsáveis.
+auto_execution_mode: 3
+env_file: "@/ENV.md"
+model_tier: high
+model_justification: Gestores e time precisam entender quais as próximas prioridades de entrega que serão feitas pelos times baseados nas informações disponíveis no projeto e também no task manager utilizado pela empresa.
+---
+
+# Roadmap Preview
+
+Este comando tem como objetivo de buscar e trazer informações sobre o roadmap de entregas planejadas do produto, como períodos de entrega, nome dos projetos e responsáveis.
+
+Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*`. Se você não estiver familiarizado com essa variável, leia as regras diretamente na pasta `.$IDE/rules/product/**/*.*`.
+
+Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entender o contexto do que foi pedido.
+<requirement>
+#$ARGUMENTS
+</requirement>
+
+## Regras
+
+- Sempre identifique o quadrimestre atual e o próximo com base na data de hoje.
+- Utilize o MCP disponível relacionado ao $TASK_MANAGER utilizado pelo usuário.
+- Antes de qualquer coisa, procure por informações sobre o projeto ou produto que o usuário está solicitando dentro da pasta de trabalho utilizado. Confirme com o usuário o que foi encontrado. Utilize também informações que o usuário já compartilhou.
+- As documentações de projeto podem ser encontradas na pasta do projeto (`$PROD_DOCS`). Rascunhos WIP: `$SESSIONS_DIR/prod/`. Caso não estejam disponíveis localmente, utilize via Skill tool a `docs-central` para buscar as informações do repositório `$CENTRAL_DOCS_REPO`.
+- Para trazer as informações, utilize via Skill tool a skill `prod-roadmap-report`
+
+### Status Reports por Squad
+
+Ler os squads em `taxonomy.md` (seção Squads). Não hardcodar times.
+
+Se o projeto tiver wiki de status report, usar URLs informadas pelo usuário ou variáveis do `ENV.md` — nunca uma tabela fixa de squads.
+
+## Formato de Períodos de Referência
+
+Nós usamos Quadrimestres como período de Referência. Então, quando o usuário falar quarter, entenda que é referente a quatro meses no ano, e não apenas 3. Como o padrão abaixo:
+
+- **Q1**: Janeiro – Abril
+- **Q2**: Maio – Agosto
+- **Q3**: Setembro – Dezembro
+
+Sempre identifique o quadrimestre atual e o próximo com base na data de hoje.
+
+### Sobre o Jira
+
+Confirme `$TASK_MANAGER` e `$TASK_MANAGER_URL_BASE` em `@/ENV.md`.
+
+Boards: usar o `board_code` de cada squad em `taxonomy.md` (se preenchido). Não hardcodar projetos.
+
+Filtro de roadmap: pedir ao usuário o JQL ou o ID do filtro salvo no `$TASK_MANAGER`. Não usar filtro fixo.
+
+Utilize o MCP da Atlassian para buscar os dados do roadmap.
+Não precisa trazer informações embedadas do jira, apenas o output definido aqui nessa skill.
+
+```
+Atlassian:searchJiraIssuesUsingJql
+JQL: (filtro informado pelo usuário ou montado a partir de board_code + labels)
+Campos a buscar: key, summary, status, priority, duedate, resolutiondate, assignee, labels, customfield (team, quadrimestre)
+```
+
+**Importante**: Use `Atlassian:getAccessibleAtlassianResources` para obter o `cloudId` antes de fazer queries.
+
+
+### Spaces no Jira
+
+Montar URLs com `{TASK_MANAGER_URL_BASE}` + `board_code` do `taxonomy.md`. Se `board_code` estiver vazio, perguntar o projeto ao usuário.
+
+### Complemento com Jira (opcional)
+Você **pode** complementar com informações do Jira apenas se tiver informações suficientes para fazer a query corretamente (ex: o squad tem um board ou label bem definidos no Jira e você tem certeza do filtro).
+
+⚠️ **Se tiver dúvida sobre como filtrar no Jira, NÃO inclua dados do Jira**. Evite trazer informações erradas ou de outros squads.
+
+
+## Status report via Wiki
+
+Use a URL de status report que o usuário informar (ou a wiki configurada no projeto). Não há tabela fixa de squads.
+
+Use `web_fetch` para acessar a URL do time selecionado.
+
+Busque os **dois últimos status reports** listados na página.
+Apresente os dois últimos reports no seguinte formato:
+
+```
+## 📋 Status Report — [Nome do time]
+
+### 📅 Último Report — [Data]
+[Conteúdo do report]
+
+---
+
+### 📅 Report Anterior — [Data]
+[Conteúdo do report]
+```
+
+---
+
+## Dicas de Ferramenta
+
+### Para dados do Jira
+1. Sempre chame `Atlassian:getAccessibleAtlassianResources` primeiro para obter o `cloudId`
+2. Use `Atlassian:searchJiraIssuesUsingJql` com o JQL adequado
+3. Para o roadmap, use o JQL/filtro informado pelo usuário
+4. Para campos customizados (team, quadrimestre), pode ser necessário chamar `Atlassian:getJiraIssueTypeMetaWithFields` para descobrir os IDs dos campos
+5. Links para issues do Jira devem ser no formato: `{TASK_MANAGER_URL_BASE}/browse/KEY-123`
+
+### Para dados da Wiki
+- Use `web_fetch` diretamente nas URLs dos reports
+- Se a página não carregar, informe o usuário que o conteúdo não está disponível no momento
+- Busque os **dois últimos status reports** listados na página.