jarvis-ai-framework 2.1.0 → 3.0.0

package/workflows/engineering/eng.work.md

@@ -2,7 +2,7 @@
 description: Fluxo de implementação de código (commit por fase, SEM push nem PRs)
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
-rules_file: "$IDE/rules/engineering/eng.work-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.work-rules.md"
 template_file: "$IDE/templates/engineering/work-progress-template.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: very_high
@@ -13,12 +13,28 @@ model_justification: Implementação de código requer máxima precisão, entend
 
 Este comando executa a **implementação de código** seguindo o plano de execução.
 
-> 📋 **Rules**: `$IDE/rules/engineering/eng.work-rules.md`
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.work-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/work-progress-template.md`
 
 > ⚠️ **IMPORTANTE**: Este workflow é para codificação com commits incrementais por fase.
 > **NÃO crie PRs, NÃO faça push**, mas **FAZ commit ao final de cada fase validada.**
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
+| Fase 0 › 0.1 Verificar ou Gerar Contexto da Sessão | `/jarvis-context-detect` | Se `ENABLE_CDD=true` e o `context.md` não existir (obrigatório antes da Fase 1) |
+| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
+| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-frontend` (via `eng.specializations-rules.md`) | Se o domínio da feature for frontend (componentes, UI, estado, estilos, bundle, a11y); a regra também carrega `FRONTEND_SPECIALIZATIONS` |
+| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-backend` (via `eng.specializations-rules.md`) | Se o domínio da feature for backend (endpoints, auth, workers, filas, cache, banco, integrações); a regra também carrega `BACKEND_SPECIALIZATIONS` |
+| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-automation` (via `eng.specializations-rules.md`) | Se o domínio da feature for RPA, scraping, extração de dados, ETL ou parsing; a regra também carrega `AUTOMATION_SPECIALIZATIONS` |
+| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-platform` (via `eng.specializations-rules.md`) | Se o domínio da feature for infraestrutura (IaC, contêineres, CI/CD, observabilidade, SRE, custo); a regra também carrega `PLATFORM_SPECIALIZATIONS` |
+| Fase 3 › 3.3.1 Identificar Gaps de Teste | `eng.qa.test-planner` (agente) | Sempre, depois de implementar o código da fase |
+| Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção A) | `eng.qa.testing-engineer` (agente) | Se o test-planner identificar gaps e a estratégia do `architecture.md` seção 6.5 indicar testes manuais (unitário/integração) |
+| Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção B) | `/eng-qa` | Se a estratégia do `architecture.md` seção 6.5 indicar uma especialização registrada em `QA_SPECIALIZATIONS` |
+| Fase 6 › 6.2 Se Todas as Fases Foram Concluídas | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido e todas as fases estiverem concluídas (freelance pula) |
+
 ---
 
 ## Regra de Execução Máxima
@@ -216,8 +232,8 @@ Se o usuário tiver sugestões, ajuste o plano.
 |---------|-------------|-------|
 | Frontend | componentes, UI, estado, estilos, bundle, a11y | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área frontend: `eng-frontend` + `FRONTEND_SPECIALIZATIONS`) |
 | Backend | endpoints, auth, workers, filas, cache, banco, integrações | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área backend: `eng-backend` + `BACKEND_SPECIALIZATIONS`) |
-| Scraping | web scraping, Puppeteer, extração de dados, ETL, parsing | [eng-scraper]($IDE/skills/eng-scraper/SKILL.md) |
-| Robô / automação | converter fluxo manual em Playwright via Stagehand, sem seletores conhecidos | [eng-scraper-robot-builder]($IDE/skills/eng-scraper-robot-builder/SKILL.md) |
+| Automation (RPA & Web) | RPA, web scraping, Puppeteer, extração de dados, ETL, parsing | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área automation: `eng-automation` + `AUTOMATION_SPECIALIZATIONS`) |
+| Platform (infra) | IaC, contêineres/orquestração, pipeline de CI/CD, observabilidade, SRE, custo de nuvem | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área platform: `eng-platform` + `PLATFORM_SPECIALIZATIONS`) |
 
 Para cada tarefa da fase:
 
@@ -275,25 +291,17 @@ Invoque o agente [eng.qa.testing-engineer]($IDE/agents/engineering/qa/eng.qa.tes
 - Seguir padrões de teste do projeto (Jest, Vitest, pytest, etc.)
 - Garantir cobertura mínima definida na estratégia
 
-**Opção B: Testes automatizados via TestSprite**
-
-Se a estratégia de testes (definida pelo `test-architect` no `eng.start`) indicar uso de TestSprite, execute o skill [eng-qa-testsprite]($IDE/skills/eng-qa-testsprite/SKILL.md) com `testScope=diff`:
+**Opção B: Especialização registrada em QA_SPECIALIZATIONS**
 
-- Gera testes automaticamente para o código implementado
-- Executa e valida cobertura
-- Suporta: E2E, API, integração, frontend, backend
-- Ideal para fluxos complexos ou quando velocidade é prioridade
+Se a estratégia de testes (definida pelo `test-architect` no `eng.start`) indicar uma ferramenta de geração/execução automatizada, use a especialização registrada em `QA_SPECIALIZATIONS` (via a base [eng-qa]($IDE/skills/eng-qa/SKILL.md)) para o escopo do diff da fase.
 
 **Quando usar cada opção:**
 
 | Cenário | Usar |
 |---------|------|
 | Testes unitários de funções/classes | testing-engineer |
-| Testes de API/endpoints | eng-qa-testsprite ou testing-engineer |
-| Testes E2E de fluxos de usuário | eng-qa-testsprite |
-| Testes de integração complexos | eng-qa-testsprite |
-| Projeto sem TestSprite configurado | testing-engineer |
-| Projeto sem TestSprite configurado | testing-engineer |
+| Fluxo com ferramenta automatizada já registrada em `QA_SPECIALIZATIONS` | a especialização registrada |
+| Sem especialização registrada | testing-engineer |
 
 > ⚠️ **Importante**: Consulte `architecture.md` seção 6.5 para ver qual abordagem foi definida pelo test-architect.
 
@@ -309,7 +317,7 @@ npm test # ou comando do projeto
 npm run test:coverage # se disponível
 ```
 
-> 💡 **Fluxo**: Implementa código → test-planner (gaps) → testing-engineer OU eng-qa-testsprite (implementa) → valida
+> 💡 **Fluxo**: Implementa código → test-planner (gaps) → testing-engineer OU especialização de `QA_SPECIALIZATIONS` (implementa) → valida
 
 ---
 

package/workflows/engineering/frontend/eng.frontend-component.md

@@ -26,6 +26,13 @@ estrutura de pastas. O que é específico da stack do projeto vem de:
 
 **Antes de começar**, aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área **frontend**: ela carrega o skill base `eng-frontend` e as especializações registradas. Onde este workflow disser "conforme a especialização", siga o que o skill da especialização pedir; sem especialização registrada, siga as convenções do código existente e **pergunte ao usuário** o que faltar, sem inventar.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Contexto (antes de começar) | `/eng-frontend` (via `eng.specializations-rules.md`) | Sempre — a regra carrega o skill base da área frontend |
+| Contexto (antes de começar) | `skills em FRONTEND_SPECIALIZATIONS` (um por item da lista) | Se houver especialização registrada em `FRONTEND_SPECIALIZATIONS` no ENV.md; lista vazia: só o skill base |
+
 ---
 
 ## Fase 1 — Análise

package/workflows/engineering/frontend/eng.frontend-perf-audit.md

@@ -23,6 +23,14 @@ projeto e das especializações registradas em `FRONTEND_SPECIALIZATIONS`.
 
 **Antes de começar**, aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área **frontend**: ela carrega o skill base `eng-frontend` e as especializações registradas. Onde este workflow disser "conforme a especialização", siga o skill da especialização; sem especialização registrada, **pergunte ao usuário** qual ferramenta o projeto usa, em vez de presumir uma.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Contexto (antes de começar) | `/eng-frontend` (via `eng.specializations-rules.md`) | Sempre — a regra carrega o skill base da área frontend |
+| Contexto (antes de começar) | `skills em FRONTEND_SPECIALIZATIONS` (um por item da lista) | Se houver especialização registrada em `FRONTEND_SPECIALIZATIONS` no ENV.md; lista vazia: só o skill base |
+| Fase 3 — Otimizações (arquitetura distribuída) | `skill da especialização registrada` | Se o projeto dividir o frontend em módulos carregados separadamente (siga o skill da especialização registrada) |
+
 ---
 
 ## Fase 1 — Coleta de Dados (antes de otimizar)

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

@@ -23,6 +23,14 @@ especialização registrada em `FRONTEND_SPECIALIZATIONS` e o código existente
 
 **Antes de revisar**, aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área **frontend**: ela carrega o skill base `eng-frontend` e as especializações registradas. Se o PR tiver exigências que você não consegue verificar sem conhecer a stack, diga isso na revisão em vez de presumir.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Contexto (antes de começar) | `/eng-frontend` (via `eng.specializations-rules.md`) | Sempre — a regra carrega o skill base da área frontend |
+| Contexto (antes de começar) | `skills em FRONTEND_SPECIALIZATIONS` (um por item da lista) | Se houver especialização registrada em `FRONTEND_SPECIALIZATIONS` no ENV.md; lista vazia: só o skill base |
+| Checklist de Revisão (especializações) | `skill de cada especialização registrada` | Para cada especialização em `FRONTEND_SPECIALIZATIONS`, aplicar o checklist de revisão do próprio skill; sem especialização, a seção não se aplica |
+
 ---
 
 ## Como usar

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

@@ -23,6 +23,13 @@ antes da codificação começar. A entrada é sempre a especificação do card
 **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).
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Execução (Modo A) | `eng.qa.test-planner` (agente) | Sempre — opera em Modo A, estratégia a partir da tech spec |
+| Execução | `Jira MCP` (referência a confirmar) | Para ler o card do `$TASK_MANAGER` por "integração disponível (ex.: Jira MCP)"; o texto não indica a ferramenta exata |
+
 ---
 
 ## Entrada

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

@@ -22,6 +22,12 @@ Sign-off QA antes de um deploy. Verifica cobertura de testes, sessões explorat
 
 Aceita: nome da branch (padrão: branch atual via `git branch --show-current`).
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — workflow autocontido | — |
+
 ---
 
 ## Fase 0 — Identificar branch e mudanças

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

@@ -12,6 +12,12 @@ model_justification: Análise de risco multi-task e alocação de capacidade req
 
 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.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Fase 2 — Análise de Risco | `eng.qa.quality-strategist` (agente) | Sempre — avalia o risco, a cobertura ideal e a justificativa de cada task da sprint |
+
 ## Entrada
 
 ```
@@ -76,7 +82,7 @@ Com base no risco e na capacidade mapeada na Fase 0:
 |-------|------------------|
 | 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 |
+| Baixo | Champion ou delegar ao dev, orientado pela base `eng-qa` + `QA_SPECIALIZATIONS` |
 
 **Detectar sobrecarga**: se demanda > capacidade total, sinalizar quais tasks ficam sem cobertura designada e sugerir redução de escopo nos itens de menor risco.
 

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

@@ -32,6 +32,15 @@ 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.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Regras | `MCP do $TASK_MANAGER` | Se houver MCP disponível relacionado ao `$TASK_MANAGER` do usuário |
+| Regras | `/jarvis-docs-central` | Se as documentações do projeto não estiverem disponíveis localmente (via Skill tool) |
+| Regras | `/product-roadmap-report` | Sempre — via Skill tool, para trazer as informações do roadmap |
+| Status Reports por Squad / Dicas de Ferramenta | `MCP da Atlassian` (ex.: `Atlassian:searchJiraIssuesUsingJql`) | Para buscar os dados do roadmap no Jira, com o JQL ou o filtro salvo informado pelo usuário |
+
 ## 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:

package/workflows/product/prod.spec.ard.md

@@ -0,0 +1,97 @@
+---
+name: prod.spec.ard
+description: Ponto de entrada de produto para o ARD (Architecture Requirements Document): levanta com o PM os requisitos arquiteturais em termos de produto e conduz o ARD pelo fluxo de engenharia.
+auto_execution_mode: 3
+env_file: "@/ENV.md"
+recommended_model: gpt-4o
+model_tier: medium
+model_justification: Levantamento estruturado de requisitos arquiteturais a partir de PRD e FRD, seguido da condução do fluxo de engenharia existente
+---
+
+# ARD a partir do produto (Architecture Requirements Document)
+
+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/**/*.*`.
+
+Este fluxo é a **porta de entrada de produto** para o ARD. Ele levanta com o PM, em linguagem de produto, o que a arquitetura precisa atender (restrições, requisitos não funcionais, integrações, volumes e riscos) e, com isso, **conduz o ARD pelo fluxo de engenharia** (`eng.create-ard`), sem duplicá-lo.
+
+> ⚠️ **O ARD é um documento de engenharia.** O arquivo resultante fica em `$DOCS_FOLDER/engineering/ARD/` (como no `eng.create-ard`), e as decisões de arquitetura pertencem à engenharia. Este comando só levanta os requisitos e abre o fluxo. Diga isso ao usuário no início.
+
+Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entender o contexto do que foi pedido.
+<requirement>
+#$ARGUMENTS
+</requirement>
+
+## Quando usar
+- Depois de um PRD ou FRD aprovado, quando falta registrar os requisitos arquiteturais da iniciativa
+- Quando o PM precisa deixar claro para a engenharia o que a arquitetura precisa atender (volumes, prazos, integrações, regras de negócio com impacto técnico)
+- Para iniciar um ARD novo a partir de uma especificação de produto já existente
+
+## Quando **não** usar
+- Para iterar ou editar um ARD que já existe → use `eng.create-ard` (modo `edit`)
+- Para extrair o ARD do código existente → use `eng.create-ard-from-code`
+- Para decidir tecnologia, desenho de componentes ou contratos → isso é da engenharia, dentro do ARD
+- Quando ainda não há PRD nem FRD e a ideia está crua → comece por `prod.spec.discovery` ou `prod.spec.prd`
+
+## Pré-requisitos e opcionais
+- **PRD ou FRD de origem (recomendado).** Procure em `$PROD_DOCS` e pergunte qual é a origem. Sem nenhum, avise que o ARD fica sem rastreabilidade e pergunte se o usuário quer seguir assim ou criar antes o PRD (`prod.spec.prd`) ou o FRD (`prod.spec.frd`).
+- **Discovery (opcional).** Se o usuário apontar um discovery (por exemplo `discovery-002`), siga o princípio "Discovery como insumo" de `$PROD_RULES/prod.spec-rules.md`: leia-o como contexto e repasse tudo com o usuário antes de usar. Sem discovery apontado, não procure nem pergunte.
+- Nome do ARD (título e slug em kebab-case): pergunte se não vier em `$ARGUMENTS`.
+
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Gate 1: Reconhecer o contexto | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md e for preciso buscar o PRD ou FRD relacionado |
+| Gate 4: Conduzir o ARD | `/eng.create-ard` | Sempre, depois de os requisitos serem confirmados: modo `new`, com `--prd` quando houver PRD (workflow de engenharia; o aviso de transição de domínio é dado antes) |
+
+## Resultado final
+- Um **resumo dos requisitos arquiteturais** confirmado pelo usuário (Gate 3), entregue como insumo ao `eng.create-ard`
+- O **ARD** gerado pelo `eng.create-ard` (numeração `ARD-###`, versão `1.0.0`, template `$IDE/templates/engineering/ARD-template.md` e caminho `$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md`)
+- Rascunhos WIP, se houver, em `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/`; o documento canônico é o ARD
+- O arquivo final no mesmo idioma da interação do usuário
+
+## Princípios
+- **Não invente.** O que o PM não souber fica registrado como "a validar pela engenharia", e não como fato.
+- **Termos de produto, não de tecnologia.** Pergunte pelo que a solução precisa atender (por exemplo, "quantos usuários simultâneos no pico?"), e não por qual banco ou framework usar.
+- **Uma pergunta por vez.** Siga o formato de perguntas de `prod-rules.md` (`AskUserQuestion` quando existir; tabela com alternativas quando não).
+- **Terminologia consistente** com a do PRD e do FRD de origem (ver `$PROD_RULES/prod.spec-rules.md`).
+
+## Etapas de execução
+
+### Gate 1: Reconhecer o contexto
+1. Valide o `ENV.md` (regra geral de produto) e avise que o ARD é um documento de engenharia.
+2. Identifique o PRD ou FRD de origem em `$PROD_DOCS` (ou o caminho que o usuário informar) e leia-o. Se `CENTRAL_DOCS_REPO` estiver definido, busque no central docs o PRD ou FRD relacionado.
+3. Resuma em poucas linhas o que a especificação pede e confirme com o usuário que é essa a origem. Se `AREA` do usuário não for `ENGINEERING`, avise que o ARD seguirá o fluxo de engenharia e deve ser revisado por alguém da engenharia.
+
+### Gate 2: Levantar os requisitos arquiteturais em termos de produto
+Pergunte, **uma por vez**, só o que a especificação não responde (pule o que o PRD ou FRD já traz, confirmando):
+- **Volume e uso:** quantidade de usuários, picos, crescimento esperado, janelas de uso
+- **Requisitos não funcionais:** disponibilidade, tempo de resposta aceitável, retenção e auditoria de dados
+- **Integrações:** sistemas, parceiros ou serviços externos com que a solução precisa falar
+- **Regras de negócio com impacto técnico:** limites, prazos legais, compliance (LGPD e afins), dados sensíveis
+- **Restrições:** prazo, orçamento, equipe, tecnologias que **já são obrigatórias** na organização
+- **Riscos conhecidos** e dependências de outras iniciativas
+
+### Gate 3: Resumir e confirmar
+Apresente o **resumo dos requisitos arquiteturais** (por tópico do Gate 2, marcando o que ficou "a validar pela engenharia") e peça confirmação. Itere até a aprovação explícita. Não avance sem ela.
+
+### Gate 4: Conduzir o ARD
+1. Avise, antes de seguir, que a próxima etapa é o fluxo de engenharia e que as decisões de arquitetura passam a ser da engenharia.
+2. Execute o workflow `eng.create-ard` no modo `new`, com o nome do ARD e `--prd <caminho>` quando houver PRD de origem, entregando o resumo do Gate 3 como insumo do documento (seções de premissas, restrições, integrações, segurança, escalabilidade e riscos do template).
+3. O `eng.create-ard` cuida de numeração, versão, preenchimento do template, análise de impacto, estratégia de testes, guard rails e publicação no central docs. Siga as instruções dele a partir daí.
+
+### Gate 5: Fechar
+1. Informe o caminho do ARD criado e o que ficou "a validar pela engenharia".
+2. Sugira o próximo passo: revisão do ARD pela engenharia e, depois, `/eng.start` para a implementação. Não execute o próximo passo.
+3. Se a informação do ARD divergir do PRD ou FRD de origem, avise o usuário e sugira atualizar a especificação de produto (o PRD e o FRD são a fonte da verdade do produto).
+
+## Do
+- Confirmar a origem (PRD ou FRD) antes de perguntar
+- Registrar tudo o que o PM não souber como "a validar pela engenharia"
+- Deixar claro, no início e antes do Gate 4, que o ARD é um documento de engenharia
+
+## Don't
+- Escolher tecnologia, desenhar componentes ou definir contratos aqui (isso é do ARD, pela engenharia)
+- Duplicar o `eng.create-ard`: numeração, template e publicação são dele
+- Criar o ARD sem o resumo confirmado no Gate 3
+- Alterar o PRD ou o FRD de origem sem o usuário pedir

package/workflows/product/prod.spec.breakdown.md

@@ -42,6 +42,16 @@ Utilize o `$ARGUMENTS` como ponto de partida (caminho da spec, nome da feature o
 2. Se não houver spec pai: ofereça criar com `$PROD_FLOWS/prod.spec.prd.md` ou `$PROD_FLOWS/prod.spec.frd.md`. Não invente escopo do zero sem confirmação.
 3. Se a spec estiver cheia de “talvez” / “depois a gente vê”: sugira clarify antes; só continue se o usuário assumir o risco.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Pré-requisitos (item 2) | `/prod.spec.prd` | Se não houver spec pai e o usuário aceitar criar o PRD |
+| Pré-requisitos (item 2) | `/prod.spec.frd` | Se não houver spec pai e o usuário aceitar criar o FRD |
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver no ENV.md (best-effort) |
+| Resultado esperado (materialização) | `/prod.spec.epic` | Se o usuário aprovar criar os arquivos de épico a partir do breakdown (nunca automaticamente) |
+| Resultado esperado (materialização) | `/prod.spec.issue` | Se o usuário aprovar criar os arquivos de história ou tarefa a partir do breakdown (nunca automaticamente) |
+
 ## Template
 
 O artefato de breakdown segue o template `$PROD_TEMPLATES/prod-breakdown-template.md`.

package/workflows/product/prod.spec.clarify.md

@@ -21,6 +21,12 @@ Utilize o que o usuário fornecer analisar em:
 #$ARGUMENTS
 </requirement>
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — workflow autocontido | — |
+
 Etapas de execução:
 
 1. Carregue o arquivo atual da spec. Realize uma varredura estruturada de ambiguidades e cobertura usando esta taxonomia. Para cada categoria, marque o status: Claro / Parcial / Ausente. Produza um mapa de cobertura interno usado para priorização (não divulgue o mapa bruto a menos que nenhuma pergunta seja feita). Analise o arquivo da spec e realize uma cobertura apenas com os itens que estão incluídos na especificação do usuário.
@@ -163,13 +169,13 @@ Para cada categoria com status Parcial ou Ausente, adicione uma oportunidade de
    - Caminho para a spec atualizada.
    - Seções tocadas (liste os nomes).
    - Tabela de resumo de cobertura listando cada categoria da taxonomia com Status: Resolvido (era Parcial/Ausente e foi tratada), Adiado (excede a cota de perguntas ou melhor tratar no planejamento), Claro (já estava suficiente), Pendente (ainda Parcial/Ausente mas de baixo impacto).
-   - Se restarem itens Pendentes ou Adiados, recomende prosseguir para `/product/prod.spec.plan.md` ou rodar `/product/prod.spec.clarify.md` novamente após o planejamento.
+   - Se restarem itens Pendentes ou Adiados, recomende prosseguir para `/prod.spec.breakdown` ou rodar `/prod.spec.clarify` novamente após o planejamento.
    - Próximo comando sugerido.
 
 Regras de comportamento:
 
 - Se nenhuma ambiguidade significativa for encontrada (ou se todas as perguntas potenciais forem de baixo impacto), responda: “Nenhuma ambiguidade crítica detectada que valha esclarecimento formal.” e sugira prosseguir.
-- Se o arquivo da spec estiver ausente, instrua o usuário a rodar `/product/prod.spec.md` primeiro (não crie uma nova spec aqui).
+- Se o arquivo da spec estiver ausente, instrua o usuário a rodar `/prod.spec` primeiro (não crie uma nova spec aqui).
 - Nunca exceda 5 perguntas feitas no total (reformulações de uma mesma pergunta não contam como novas).
 - Evite perguntas especulativas sobre stack tecnológica, a menos que a ausência bloqueie a clareza funcional.
 - Respeite sinais de encerramento antecipado do usuário (“stop”, “done”, “proceed”).

package/workflows/product/prod.spec.discovery.md

@@ -39,6 +39,16 @@ O comando e o agente seguem obrigatoriamente `$PROD_RULES` (`prod-rules.md`):
 - Perguntas: use o `AskUserQuestion` se estiver disponível; senão, o formato de tabela do `prod-rules.md`. **Uma pergunta por vez**
 - Confirmar com o usuário o caminho e o nome antes de salvar arquivo
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Regras do framework / Passo 4 — A entrevista | `prod.discovery-interviewer` (agente) | Sempre — conduz a entrevista, e o comando segue a postura dele |
+| Passo 2 — Reconhecer o projeto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado |
+| Passo 2 — Reconhecer o projeto | `/jarvis-context-detect` | Para calibrar a profundidade da entrevista |
+| Passo 2 — Reconhecer o projeto | `/eng-backend-arch-c4` | Só com a confirmação do usuário; o retorno é tratado como suposição a validar |
+| Passo 2 — Reconhecer o projeto | `/eng-platform` + `PLATFORM_SPECIALIZATIONS` | Só com a confirmação do usuário; o retorno é tratado como suposição a validar |
+
 ## Passo 0 — Entender o que foi pedido
 
 1. **Sem `$ARGUMENTS`:** pergunte qual é a ideia antes de qualquer outra coisa.
@@ -62,7 +72,7 @@ Antes de perguntar, consulte o que já existe:
 - O código e os últimos commits, quando ajudarem a embasar a viabilidade
 - `jarvis-docs-central`, se `CENTRAL_DOCS_REPO` estiver configurado
 - `jarvis-context-detect`, para calibrar a profundidade da entrevista
-- `eng-backend-arch-c4` e `eng-security-cybersecurity` são skills de engenharia: só consulte **com a confirmação do usuário**, e trate o retorno como **suposição a validar**, não como fato
+- `eng-backend-arch-c4` e `eng-platform` (+ `PLATFORM_SPECIALIZATIONS`) são skills de engenharia: só consulte **com a confirmação do usuário**, e trate o retorno como **suposição a validar**, não como fato
 
 ## Passo 3 — Criar o arquivo
 

package/workflows/product/prod.spec.epic.md

@@ -33,6 +33,14 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 - Ter um breakdown existente é importante, mas opcional. Questione o usuário se ele deseja criar um breakdown (siga o fluxo de trabalho `prod.spec.breakdown.md`) ou se ele deseja criar um épico independente de especificações anteriores ou para projetos que já estão em andamento
 - Compreensão de alto nível da abordagem técnica
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md, antes de criar o épico |
+| Próximas etapas | `/prod.spec.issue` | Depois de criar o épico, se o usuário quiser escrever as histórias ou tarefas relacionadas |
+| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo epic`) | Se `CENTRAL_DOCS_REPO` estiver definido, o épico estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
+
 ## Resultado final
 - Por padrão, use o modelo `$PROD_TEMPLATES/prod-epic-template.md` integralmente
 - Siga a estrutura do modelo exatamente como definida, não pule passos, a não ser que o usuário solicite explicitamente

package/workflows/product/prod.spec.frd.md

@@ -26,6 +26,13 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 - Para documentar critérios de aceitação claros e testáveis
 - Para descrever o funcionamento detalhado da feature a partir do comportamento do usuário, de especificações de produto e de design
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
+| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo frd`) | Se `CENTRAL_DOCS_REPO` estiver definido, o FRD estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
+
 ## Princípios Fundamentais
 1. **Sempre use o template** `$PROD_TEMPLATES/prod-frd-template.md` para o output final
 2. **Nunca crie o arquivo final com suposições não validadas** — sempre confirme sugestões primeiro

package/workflows/product/prod.spec.issue.md

@@ -35,6 +35,12 @@ Um grupo de histórias de um mesmo assunto podem formar um épico.
 - Referências de design (para histórias de usuário)
 - Quaisquer restrições técnicas ou requisitos relevantes
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Estrutura da Issue (salvar no `$TASK_MANAGER`) | `/eng-global-task-comment` (e adapter do vendor) | Se o usuário pedir para salvar no `$TASK_MANAGER` e `TASK_MANAGER`, token e URL estiverem no ENV.md; freelance ou sem token/URL: não usar, salvar só o markdown local |
+
 ## Resultado Final
 - Siga a estrutura exata do template `$PROD_TEMPLATES/prod-issue-template.md`
 - Convenção de nomenclatura: `{issue_type}-{id}-{issue_name}.md` (ex: story-123-fluxo-lembrar-senha.md)

package/workflows/product/prod.spec.md

@@ -21,6 +21,20 @@ Estas instruções ajudam a orientar o usuário que deseja começar a construir
 - Quando precisar criar novos ou editar épicos, issues, tasks, stories e bugs
 - Quando precisar de orientação sobre o tipo de documentação a ser gerada
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Instruções › Projeto existente ou novo | `/prod.spec.prd` | Se for projeto novo, ou projeto existente sem documentação e o usuário quiser criar o PRD inicial |
+| Instruções › Uso adequado dos comandos | `/prod.spec.discovery` | Se o usuário só tem uma ideia inicial (investigar problema, requisitos e viabilidade antes de especificar) |
+| Instruções › Uso adequado dos comandos | `/prod.spec.prd` | Se o pedido for um PRD |
+| Instruções › Uso adequado dos comandos | `/prod.spec.frd` | Se o pedido for um FRD |
+| Instruções › Uso adequado dos comandos | `/prod.spec.ard` | Se o pedido for registrar os requisitos de arquitetura (ARD) a partir de uma especificação de produto |
+| Instruções › Uso adequado dos comandos | `/prod.spec.issue` | Se o pedido for uma issue (história, tarefa ou bug) |
+| Instruções › Uso adequado dos comandos | `/prod.spec.clarify` | Para clarificar e revisar qualquer tipo de especificação |
+| Instruções › Uso adequado dos comandos | `/prod.spec.breakdown` | Para quebrar uma especificação grande em fatias (versões, épicos, histórias) |
+| Instruções › Uso adequado dos comandos | `/prod.spec.epic` | Se o pedido for criar épicos |
+
 ## Instruções
 
 - **Sessões de produto**: rascunhos WIP em `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/`. A spec canônica fica em `$PROD_DOCS` (não substituir).
@@ -45,7 +59,7 @@ Estas instruções ajudam a orientar o usuário que deseja começar a construir
   - Para investigar uma ideia inicial (problema, requisitos e viabilidade) antes de especificar, use `$PROD_FLOWS/prod.spec.discovery.md`. Se o usuário só tem uma ideia, oriente para o discovery em vez de abrir um PRD com dados presumidos
   - Para PRD use as instruções em `$PROD_FLOWS/prod.spec.prd.md`
   - Para FRD use as instruções em `$PROD_FLOWS/prod.spec.frd.md`
-  - Para ARD use as instruções em `$PROD_FLOWS/prod.spec.ard.md`
+  - Para ARD use as instruções em `$PROD_FLOWS/prod.spec.ard.md` (o ARD é um documento de engenharia: este comando levanta os requisitos com o PM e conduz o `eng.create-ard`)
   - Para Issue use as instruções em `$PROD_FLOWS/prod.spec.issue.md`
   - Para clarificar e revisar qualquer tipo de especificação, use as instruções em `$PROD_FLOWS/prod.spec.clarify.md`
   - Para quebrar uma especificação grande em fatias (versões / épicos / histórias), use `$PROD_FLOWS/prod.spec.breakdown.md`

package/workflows/product/prod.spec.prd.md

@@ -25,6 +25,13 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 - Quando documentação abrangente é necessária
 - Como fonte única de verdade para o desenvolvimento do produto e base para derivar histórias e tarefas
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md (iteração de PRD existente) |
+| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo prd`) | Se `CENTRAL_DOCS_REPO` estiver definido, o PRD estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
+
 ## Princípios Fundamentais
 1. **Sempre use o template** `$PROD_TEMPLATES/prod-prd-template.md` para o output final
 2. **Nunca crie o arquivo final com suposições não validadas** — sempre confirme sugestões primeiro

package/workflows/taxonomy.md

@@ -6,9 +6,9 @@ description: Gerencia o arquivo taxonomy.md de forma segura (CRUD de opções or
 
 Gerencia o arquivo `taxonomy.md` que define as opções válidas para SQUAD, HUB, POSITION e AREA.
 
-## Uso
+Este workflow é **autônomo**: as instruções para as operações abaixo estão aqui, sem depender de nenhum skill.
 
-Este command invoca o skill `taxonomy-manager` para operações CRUD seguras:
+## Uso
 
 ### Listar opções
 
@@ -45,10 +45,16 @@ Este command invoca o skill `taxonomy-manager` para operações CRUD seguras:
 /taxonomy validate
 ```
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — workflow autocontido | — |
+
 ## Sintaxe
 
 ```
-Skill("taxonomy-manager", "$ARGUMENTS")
+/taxonomy <operação> [<CATEGORIA>] [<NOME>] [<DESCRIÇÃO>]
 ```
 
 Onde `$ARGUMENTS` é um dos formatos:
@@ -58,6 +64,52 @@ Onde `$ARGUMENTS` é um dos formatos:
 - `remove <CATEGORIA> <NOME>`
 - `validate`
 
+`<CATEGORIA>` é `SQUADS`, `HUBS`, `POSITIONS` ou `AREAS`. Sem argumentos ou com uma operação desconhecida, mostre a sintaxe acima e pergunte o que a pessoa quer fazer.
+
+## Como executar cada operação
+
+O arquivo é o `taxonomy.md` da raiz do framework (ou do workspace). Cada categoria é uma seção `## ...` (Squads, Hubs, Positions, Areas) e cada opção é um título `### NOME`, seguido de linhas de descrição. Em `SQUADS`, a opção também pode ter linhas de metadados (`channel_id:`, `board_code:`, `modules:`); em `AREAS`, a linha `prefix:`. A seção `Domain` (`DOMAIN:`) não é uma categoria de opções.
+
+### Regras comuns (antes de qualquer alteração)
+
+1. **Ler** o `taxonomy.md` inteiro e localizar a seção da categoria. Se a categoria não existir, informe e liste as categorias válidas.
+2. **Validar o nome** (em `add`): MAIÚSCULAS, sem espaços (use `-` ou `_` para separar palavras), sem duplicar uma opção que já existe na categoria.
+3. **Fazer backup** antes de gravar: copie o `taxonomy.md` para `.jarvis/backups/taxonomy-{AAAAMMDD-HHMMSS}.md` (a pasta `.jarvis/` não é versionada). Se não for possível gravar o backup, **pare** e avise, sem alterar o arquivo.
+4. **Mostrar o que vai mudar** (a seção antes e depois) e **pedir confirmação** antes de gravar em `add`, `update` e `remove`.
+5. **Preservar a estrutura markdown**: não reordenar nem reescrever outras seções; alterar só a opção pedida.
+
+### `list <CATEGORIA>`
+
+Mostre cada opção da categoria com a primeira linha da descrição, em tabela. Não altera nada.
+
+### `add <CATEGORIA> <NOME> <DESCRIÇÃO>`
+
+1. Aplique as regras comuns.
+2. Acrescente, no fim da seção da categoria (antes do `---` que a encerra), um bloco `### NOME` com a descrição.
+3. Em `SQUADS`, pergunte se a pessoa quer preencher `channel_id`, `board_code` e `modules`; sem resposta, deixe-os vazios como nas outras squads.
+4. Em `AREAS`, peça o `prefix` (letras minúsculas, sem espaços) e **avise** que as áreas do framework são `ENGINEERING` e `PRODUCT`: adicionar outra área exige um menu correspondente no `warm-up` e só deve ser feito com confirmação explícita.
+
+### `update <CATEGORIA> <NOME> <NOVA_DESCRIÇÃO>`
+
+1. A opção deve existir; se não, informe e sugira nomes parecidos.
+2. Substitua só as linhas de descrição da opção (mantendo `prefix:` e metadados), depois de mostrar o antes e o depois e pedir confirmação.
+
+### `remove <CATEGORIA> <NOME>`
+
+1. A opção deve existir; se não, informe e sugira nomes parecidos.
+2. **Ação destrutiva:** leia o `$IDE/ENV.md`; se o valor de `SQUAD`, `HUB`, `POSITION` ou `AREA` for a opção a remover, **avise** que o `ENV.md` ficará inválido e peça confirmação explícita.
+3. Remova o bloco `### NOME` e suas linhas, sem tocar nas outras opções, depois de mostrar o que será removido e pedir confirmação.
+
+### `validate`
+
+Não altera nada. Verifique e reporte, por categoria:
+- a seção existe e tem ao menos uma opção;
+- todo nome está em MAIÚSCULAS e sem espaços, sem duplicata;
+- toda opção de `AREAS` tem `prefix:`;
+- a estrutura markdown está íntegra (títulos `##` e `###`, separadores `---`).
+
+Termine com um resumo (`✅ válido` ou a lista de problemas, com a linha de cada um).
+
 ## Exemplos
 
 ### Adicionar novo squad
@@ -77,9 +129,9 @@ Onde `$ARGUMENTS` é um dos formatos:
 
 ## Segurança
 
-✅ Backup automático antes de modificações
+✅ Backup antes de modificações (`.jarvis/backups/`)
 ✅ Validação de formato (MAIÚSCULAS, sem espaços)
-✅ Confirmação para ações destrutivas
+✅ Confirmação para ações destrutivas e antes de gravar
 ✅ Preservação da estrutura markdown
 
 ## Após Modificações
@@ -89,4 +141,4 @@ Depois de adicionar/remover opções:
 2. Não é necessário reiniciar o Claude ou a IDE
 3. Projetos existentes continuam funcionando
 
-> **Documentação completa**: Ver `.claude/skills/taxonomy-manager/SKILL.md`
+> **Referência**: o formato das seções está descrito no próprio `taxonomy.md` ("Como Adicionar Novas Opções").