jarvis-ai-framework 2.1.0 → 3.0.0

package/rules/AGENTS.md

@@ -13,22 +13,31 @@ A pasta `rules/` contem **regras e diretrizes** que governam o comportamento do
 ## Estrutura
 
 ```
-rules/
+rules/                        # Sempre carregadas no início da sessão
 ├── engineering/              # Regras de engenharia
 │   ├── eng-rules.md          # Regras gerais de engenharia
-│   ├── eng.start-rules.md    # Regras para /eng.start
-│   ├── eng.plan-rules.md     # Regras para /eng.plan
-│   ├── eng.work-rules.md     # Regras para /eng.work
-│   ├── eng.pr-rules.md       # Regras para /eng.pr
 │   ├── eng.bump-rules.md     # Regras para versionamento
-│   ├── eng.tech-spec-rules.md # Regras para tech specs
 │   ├── eng.specializations-rules.md # Carregamento de especializações por stack
 │   ├── eng.skills-rules.md       # Área obrigatória nos skills e aviso de skill inexistente
 │   └── qa/                   # Regras de QA
 └── product/                  # Regras de produto
     └── prod-rules.md    # Regras de especificacao
+
+rules-on-demand/              # Lidas pelo workflow que as usa (não carregadas no início)
+└── engineering/
+    ├── eng.start-rules.md    # Regras para /eng.start
+    ├── eng.plan-rules.md     # Regras para /eng.plan
+    ├── eng.work-rules.md     # Regras para /eng.work
+    ├── eng.pre-pr-rules.md   # Regras para /eng.pre-pr
+    ├── eng.pr-rules.md       # Regras para /eng.pr
+    ├── eng.tech-spec-rules.md # Regras para tech specs
+    └── eng.breakdown-subtasks-rules.md # Regras para o breakdown de subtarefas
 ```
 
+### `rules/` x `rules-on-demand/`
+
+O Claude Code carrega tudo de `.claude/rules/` no início da sessão: `rules/` fica só com o que vale sempre. Rule de uma etapa só (um comando) vai para `rules-on-demand/`, e o workflow manda lê-la (`rules_file` + "antes de começar, leia..."). O `Applies to` e o filtro por perfil valem nas duas. Efeito: `jarvis tokens`.
+
 ---
 
 ## Hierarquia de Regras
@@ -36,7 +45,7 @@ rules/
 ```
 1. .windsurf/rules / .cursor/rules  (mais alta)
 2. rules/engineering/eng-rules.md
-3. rules/engineering/eng.{comando}-rules.md
+3. rules-on-demand/engineering/eng.{comando}-rules.md
 4. rules/product/prod-rules.md (mais baixa)
 ```
 
@@ -80,6 +89,8 @@ Cada arquivo de rule declara para quais perfis se aplica via bloco `applies_to`,
 
 **Ao criar uma nova rule**, definir o bloco `applies_to` é obrigatório. Sem ele, a rule é tratada como universal — o que pode ser indesejado para rules domain-specific.
 
+**Não declarar `trigger:` no frontmatter.** O Claude Code ignora o campo e carrega toda rule da pasta (sem `paths`) no início da sessão. Quem filtra a rule por perfil é o bloco `applies_to`.
+
 ---
 
 ## Estrutura de um Arquivo de Regras

package/rules/engineering/eng-rules.md

@@ -1,5 +1,4 @@
 ---
-trigger: always_on
 env_file: "@/ENV.md"
 ---
 
@@ -27,7 +26,7 @@ env_file: "@/ENV.md"
     O arquivo ENV.md não existe ou está incompleto.
     Por favor, execute `/jarvis-init` para configurar o ambiente antes de continuar.
     ```
-  - **Listas de especializações (presentes, podem estar vazias)**: `BACKEND_SPECIALIZATIONS` e `FRONTEND_SPECIALIZATIONS` devem **existir** no `ENV.md`. Lista **vazia** é válida (só o skill base). Variável **ausente** interrompe o comando de backend ou de frontend e orienta o Upgrade do `/jarvis-init`. Detalhes e mensagens em `eng.specializations-rules.md`.
+  - **Listas de especializações (presentes, podem estar vazias)**: `BACKEND_SPECIALIZATIONS`, `FRONTEND_SPECIALIZATIONS`, `QA_SPECIALIZATIONS`, `DATA_SPECIALIZATIONS`, `AUTOMATION_SPECIALIZATIONS` e `PLATFORM_SPECIALIZATIONS` devem **existir** no `ENV.md`. Lista **vazia** é válida (só o skill base). Variável **ausente** interrompe o comando daquela área e orienta o Upgrade do `/jarvis-init` — mas só quando um comando daquela área específica é executado (igual já valia pra backend/frontend; não bloqueia comando de uma área não tocada). Detalhes e mensagens em `eng.specializations-rules.md`.
   - **Skills sem área**: skill instalado sem `metadata.area` reconhecida bloqueia o comando, e skill pedido que não existe gera aviso. Detalhes e mensagens em `eng.skills-rules.md`.
 
 - **🔧 VARIÁVEL `$IDE` - DETECÇÃO AUTOMÁTICA DA PASTA DA IDE**
@@ -171,18 +170,9 @@ env_file: "@/ENV.md"
 
 ---
 
-## 🔄 Fluxo Downstream de Cards
+## 🔄 Autonomia no card
 
-Ao orientar o usuário sobre transição de status de cards no board (Jira, GitLab, Linear ou equivalente), **sempre consultar**:
-
-> `$IDE/rules/engineering/eng.downstream-flow-rules.md`
-
-Este arquivo define:
-- Diagrama completo do fluxo (11 estágios)
-- Matriz de transições: quem move o quê e quando
-- Responsabilidades por papel, mapeadas diretamente de `taxonomy.md`
-- Critérios de entrada e saída por estágio
-- RACI consolidado
+Ao orientar o usuário sobre a movimentação de cards no board (Jira, GitLab, Linear, GitHub ou equivalente), use o princípio abaixo; não há um fluxo de colunas fixo no framework.
 
 **Princípio — autonomia do profissional:**
 - Quem assumiu o card (**DEV**, **TECH LEAD** ou **PM/TPM/GPM**) pode conduzi-lo **ponta-a-ponta**: puxar, implementar, abrir MR, merge, validar, aceite e preparar/executar deploy.

package/rules/engineering/eng-security-rules.md

@@ -1,5 +1,4 @@
 ---
-trigger: always_on
 env_file: "@/ENV.md"
 ---
 
@@ -8,7 +7,10 @@ env_file: "@/ENV.md"
 # Regras de Seguranca para Engenharia
 
 Regras de seguranca aplicaveis a todo o fluxo de engenharia — do planejamento ao merge.
-Toda implementacao deve seguir estas regras por padrao, sem necessidade de invocar o skill `eng-security-cybersecurity` explicitamente.
+Toda implementacao deve seguir estas regras por padrao. Seguranca de codigo de aplicacao ja e
+padrao embutido nas bases `eng-backend`/`eng-frontend`; seguranca de infraestrutura e fundamentos
+de seguranca da informacao (risco, ameacas, identidade, resposta a incidente, GRC, privacidade)
+ficam no `eng-platform` (temas 9 e 13).
 
 ---
 
@@ -104,21 +106,22 @@ O agente DEVE incluir no checklist de pre-PR as seguintes verificacoes de segura
 
 Se o PR toca em areas sensiveis (auth, sessions, RBAC, CORS, CSP, permissoes), o agente DEVE:
 1. Adicionar label `security` ao PR
-2. Recomendar ao usuario executar `/eng.security-review` antes do merge
+2. Seguir o gate de seguranca inline do `eng.pre-pr` (sanitizacao, auth guards, headers, secrets scan, `npm audit`) antes do merge
 
 ---
 
 ## Fase: eng.pr (Merge)
 
-- PRs com label `security` devem ter review de seguranca aprovado (manual ou via `/eng.security-review`)
+- PRs com label `security` devem ter review de seguranca aprovado manualmente antes do merge
 - Nunca aprovar PR com secret detectado no diff — sem excecoes
 - Se o PR adiciona endpoint publico, documentar justificativa no description do PR
 
 ---
 
-## Fronteira Read-Only (Analise de Seguranca)
+## Analise Read-Only de Seguranca
 
-Os skills de seguranca (`eng-security-threat-model`, `eng.security-audit`, `eng-security-triage`) operam em **modo estatico apenas**:
+Qualquer analise de ameacas, auditoria ou investigacao de seguranca feita pelo agente opera em
+**modo estatico apenas**:
 
 - Leem codigo-fonte, historico git e relatorios fornecidos pelo usuario
 - **Nunca** executam, buildam, fuzzam ou modificam o codigo-alvo
@@ -131,14 +134,14 @@ Os skills de seguranca (`eng-security-threat-model`, `eng.security-audit`, `eng-
 
 Usar `jarvis-context-detect` para calibrar a profundidade da analise de seguranca:
 
-| Nivel de risco | Criterio | Estrategia | Tokens (estimado) |
-|---|---|---|---|
-| **Baixo** — PR comum | Logica de negocio sem superficie sensivel | Single-pass, sem fan-out | ~15k (main thread) |
-| **Medio** — PR sensivel | Toca auth, sessions, RBAC, CORS, CSP, PII, fluxo financeiro, criptografia | Fan-out por area + single-vote | ~80k (subagentes isolados) |
-| **Alto** — Audit completo | Usuario invoca `/eng.security-audit` explicitamente | Fan-out + multi-voto (3 votos por achado) | ~200k-1M (subagentes isolados) |
+| Nivel de risco | Criterio | Estrategia |
+|---|---|---|
+| **Baixo** — PR comum | Logica de negocio sem superficie sensivel | Single-pass, sem fan-out |
+| **Medio** — PR sensivel | Toca auth, sessions, RBAC, CORS, CSP, PII, fluxo financeiro, criptografia | Fan-out por area + single-vote |
+| **Alto** — Auditoria completa | Usuario pede uma auditoria dedicada do projeto | Fan-out + multi-voto (3 votos por achado) |
 
 O peso do token fica em subagentes isolados — janela da sessao principal nao lota.
-PR comum sem risco identificado = zero token extra (so as rules always_on).
+PR comum sem risco identificado = zero token extra (so as rules, que ja ficam carregadas).
 
 ---
 
@@ -150,23 +153,21 @@ As regras acima se aplicam a TODOS os engenheiros. A responsabilidade escala com
 |----------|---------------------------|
 | JUNIOR, PLENO | Seguir as regras. Em duvida de seguranca, consultar senior/TL — nao bloqueia a entrega se o risco for registrado |
 | SENIOR, SPECIALIST | Seguir + revisar seguranca de PRs do squad quando solicitado |
-| TECH LEAD, HEAD | Seguir + garantir que `/eng.security-review` foi executado em PRs com label `security`. Decidir se escala incidente |
+| TECH LEAD, HEAD | Seguir + garantir que o gate de seguranca do `eng.pre-pr` foi seguido em PRs com label `security`. Decidir se escala incidente |
 | CTO | Seguir + visao de compliance (LGPD/GDPR) e risco organizacional. Aprovar excecoes de seguranca |
 
 ---
 
-## Quando escalar para o agente SENTINEL
+## Quando o risco excede estas regras
 
-O agente de engenharia (ATHENA) deve recomendar o uso do agente SENTINEL (`eng.cybersecurity.agent.md`) quando:
+O agente de engenharia (ATHENA) deve sinalizar explicitamente ao usuario e pedir revisao humana quando:
 
 - Vulnerabilidade conhecida (CVE) afeta uma dependencia do projeto
-- Auditoria de seguranca completa e solicitada
+- Auditoria de seguranca completa e solicitada (sem skill dedicado hoje — se for recorrente, considere criar uma especializacao em `PLATFORM_SPECIALIZATIONS`)
 - Incidente de seguranca em producao
 - Feature envolve fluxo financeiro, PII ou auth complexa (OAuth, MFA)
 - Duvida sobre impacto de seguranca que excede o escopo das regras acima
 
-> O skill `/eng-security-cybersecurity` pode ser invocado diretamente para consulta rapida sem ativar o agente completo.
-
 ---
 
 ## Nunca

package/rules/engineering/eng.bump-rules.md

@@ -23,5 +23,6 @@ Corrigir bugs sem alterar feature pretendida.
 Pequenas melhorias de performance.
 Atualizações de documentação ou mudanças de metadata.
 
-Altere a versão no pyproject.toml.
-Então, execute `uv sync --all-extras` para regenerar o lock file.
+Altere a versão em `package.json`.
+Então, execute `npm install` para regenerar o `package-lock.json`.
+Adicione uma entrada em `CHANGELOG.md` para a nova versão, seguindo o formato [Keep a Changelog](https://keepachangelog.com/).

package/rules/engineering/eng.docs-scraping-rules.md

@@ -19,7 +19,7 @@ Aplicável sempre que um robô novo for implementado, um bug estrutural for reso
 #### Localização
 
 - Sempre criar em `docs/engineering/robots/{robot-tag}-robot.md`
-- Exemplos: `docs/engineering/robots/ba-robot.md`, `docs/engineering/robots/sp-robot.md`
+- Exemplos: `docs/engineering/robots/consulta-orgao-robot.md`, `docs/engineering/robots/extrator-dados-robot.md`
 
 #### Conteúdo obrigatório
 
@@ -30,8 +30,8 @@ Todo arquivo `{robot-tag}-robot.md` deve conter:
 | **Visão Geral** | O que o robô coleta e o que **não** coleta (limitações por design) |
 | **Fluxo de Execução** | Sequência de chamadas HTTP com URLs completas de cada etapa |
 | **Fontes de Dados** | Cada fonte (PDF, HTML, API) com mapeamento de campos/colunas |
-| **Campos Extraídos** | Tabela por `situation` (ex: IMPOSTA vs AGUARDANDO IMPOSICAO) — quais campos existem em cada uma e a fonte |
-| **Limitações Conhecidas** | Campos indisponíveis na fonte do DETRAN/órgão — documentar por que não é possível extrair |
+| **Campos Extraídos** | Tabela por `situation` (ex: CONCLUIDO vs PENDENTE) — quais campos existem em cada uma e a fonte |
+| **Limitações Conhecidas** | Campos indisponíveis na fonte do sistema/órgão externo — documentar por que não é possível extrair |
 | **Histórico de Bugs** | Bugs resolvidos com referência ao Jira key, sintoma, causa e fix aplicado |
 | **Checklist de Troubleshooting** | Tabela: sintoma → causa provável → ação |
 
@@ -39,7 +39,7 @@ Todo arquivo `{robot-tag}-robot.md` deve conter:
 
 - Ao implementar um robô novo
 - Ao resolver qualquer bug estrutural (ex: campo retornando vazio, matching falho)
-- Ao fazer descobertas relevantes sobre o comportamento do site-alvo (ex: estrutura de colunas HTML, campos disponíveis por situação de multa)
+- Ao fazer descobertas relevantes sobre o comportamento do site-alvo (ex: estrutura de colunas HTML, campos disponíveis por situação do registro)
 - Sempre referenciar o Jira key no histórico de bugs
 
 ### Proibido

package/rules/engineering/eng.integrations-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
 
 # Integrações — vendors via ENV
@@ -12,8 +8,8 @@ O Jarvis não assume Jira, GitLab ou Slack. Leia `$IDE/ENV.md` e despache pelo a
 
 | Variável | Vendors | Adapter |
 |----------|---------|---------|
-| `TASK_MANAGER` | jira, linear, github, asana | `bin/lib/tasks/comment.js` |
-| `VERSION_CONTROL` | gitlab, github, bitbucket | `bin/lib/vcs/` |
+| `TASK_MANAGER` | jira, linear, github, asana | `jarvis tasks comment` |
+| `VERSION_CONTROL` | gitlab, github, bitbucket | `jarvis vcs create-merge` / `create-issue` / `fetch-raw` |
 | `MESSAGE_COMUNICATOR` | slack, discord, teams | runtime `communicator/` |
 
 `{TASK_MANAGER_KEY}` = id da tarefa. Com board, é o id do card. Sem board, é o número de controle do usuário.
@@ -47,7 +43,7 @@ Só se `TASK_MANAGER` estiver preenchido com um vendor. Freelance → pular.
 ## MR / PR
 
 ```
-node bin/lib/vcs/create-merge.js --source BRANCH --target BRANCH --title "..." --body-file path
+jarvis vcs create-merge --source BRANCH --target BRANCH --title "..." --body-file path
 ```
 
 Vendor pelo hostname de `git remote get-url origin` (ou `VERSION_CONTROL`).

package/rules/engineering/eng.skills-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
 # Regras de Skills: área obrigatória e nome inexistente
@@ -14,7 +10,7 @@ Garantir que todo skill instalado tenha uma área reconhecida e avisar a pessoa,
 
 Vale para todo comando `eng.*` e seus agentes, **ao iniciar**. A pasta de skills considerada é `$IDE/skills/`.
 
-**Áreas reconhecidas:** `qa`, `data`, `ai`, `frontend`, `backend`, `security`, `scraper`, `devops`, `global`, `product`.
+**Áreas reconhecidas:** `qa`, `data`, `ai`, `frontend`, `backend`, `automation`, `devops`, `platform`, `global`, `product`.
 
 ## Regras
 

package/rules/engineering/eng.specializations-rules.md

@@ -1,10 +1,6 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
-# Regras de Especializações por Stack
+# Regras de Especializações por Área
 
 ## Objetivo
 
@@ -12,12 +8,25 @@ Fazer todo comando `eng.*` carregar o **skill base** da área mais as **especial
 
 ## Escopo
 
-Vale para qualquer comando `eng.*` e seus agentes, **ao iniciar um trabalho de backend** (APIs, autenticação, workers, banco de dados, servidor) **ou de frontend** (componentes, interface, estilos, estado). Se o trabalho envolve as duas áreas, aplique a regra a cada uma. Se não é de nenhuma das duas, não carregue nada.
+Vale para qualquer comando `eng.*` e seus agentes, ao iniciar um trabalho que seja claramente de uma destas áreas. Se o trabalho envolve mais de uma, aplique a regra a cada uma. Se não é de nenhuma, não carregue nada.
+
+| Área | Indicadores de quando se aplica |
+|------|----------------------------------|
+| backend | APIs, autenticação, workers, banco de dados, servidor |
+| frontend | Componentes, interface, estilos, estado |
+| qa | Testes, cobertura, quality gates, planejamento de testes |
+| data | Pipelines, ETL/ELT, modelagem, contratos de dados, qualidade de dados |
+| automation | RPA (robôs, automação de browser/fluxos de trabalho), web scraping, crawling, parsing |
+| platform | Infraestrutura, cloud, IaC, contêineres, CI/CD, observabilidade, SRE, segurança de infra, FinOps |
 
 | Área | Variável no `ENV.md` | Skill base |
 |------|----------------------|------------|
 | backend | `BACKEND_SPECIALIZATIONS` | `eng-backend` |
 | frontend | `FRONTEND_SPECIALIZATIONS` | `eng-frontend` |
+| qa | `QA_SPECIALIZATIONS` | `eng-qa` |
+| data | `DATA_SPECIALIZATIONS` | `eng-data` |
+| automation | `AUTOMATION_SPECIALIZATIONS` | `eng-automation` |
+| platform | `PLATFORM_SPECIALIZATIONS` | `eng-platform` |
 
 ## Regras
 
@@ -57,8 +66,9 @@ Vale para qualquer comando `eng.*` e seus agentes, **ao iniciar um trabalho de b
 
 ## Exceções
 
-- Áreas além de backend e frontend não têm lista (evolução futura).
-- Skills de outras áreas não passam por esta regra.
+- `ai`, `devops`, `global` e `product` ainda não têm lista — fora do escopo desta regra até que apareça necessidade real (evolução futura).
+- Skills dessas áreas não passam por esta regra.
+- A área `security` foi descontinuada (2026-10-05): não existe mais skill própria nem lista. Segurança de infraestrutura e fundamentos de segurança da informação entram em `PLATFORM_SPECIALIZATIONS`; segurança de código de aplicação já é padrão embutido em `eng-backend`/`eng-frontend`. Ver `skills/security-skills-deleted.md`.
 
 ## Referências
 

package/rules/engineering/frontend/eng.frontend-rules.md

@@ -88,10 +88,7 @@ Aplica-se quando a linguagem do projeto tem tipagem estática ou contratos expl
 
 ### Ferramentas disponíveis no framework
 
-- **TestSprite** (`/eng-qa-testsprite`): se estiver instalado no projeto, usá-lo para gerar e executar testes de componente e de ponta a ponta — ele gera planos de teste e código automaticamente.
-  Verificar: `ls node_modules/@testsprite 2>/dev/null || cat package.json | grep testsprite`
-- **Stagehand** (`/eng-scraper-robot-builder`, `/eng-qa-e2e`): para testes de ponta a ponta em linguagem natural ou automação de fluxos complexos, descrevendo o fluxo em português.
-  Verificar: `cat package.json | grep stagehand`
+- **Especialização de testes automatizados registrada em `QA_SPECIALIZATIONS`** (via a base `/eng-qa`): se o projeto tiver uma, usá-la para gerar e executar testes de componente e de ponta a ponta.
 
 > Quando qualquer dessas ferramentas estiver disponível no projeto, **preferir sobre a implementação manual** — reduz o custo de manutenção e aumenta a cobertura mais rápido.
 

package/rules/engineering/qa/eng.qa.cypress-standards-rules.md

@@ -6,7 +6,7 @@ Convenções obrigatórias para a escrita e manutenção da suíte de testes E2E
 Estas regras são carregadas automaticamente pelo `warm-up` quando `HUB=QA`.
 
 > **Fonte de verdade**: este arquivo define o padrão para toda a sessão.
-> A skill `eng-qa-cypress-e2e` assume que estas regras foram carregadas — não as redescobre.
+> A especialização de Cypress registrada em `QA_SPECIALIZATIONS` assume que estas regras foram carregadas — não as redescobre.
 
 ---
 

package/rules/engineering/rpa/eng.rpa-rules.md

@@ -174,17 +174,13 @@ Documentar o resultado no `{robot-tag}-robot.md` na seção de Visão Geral.
 - Executar manualmente antes do PR em ambiente com acesso ao sistema-alvo
 - Não incluir no pipeline de CI sem ambiente controlado
 
-### TestSprite (recomendado para fluxos de UI)
+### Validação E2E (recomendada para fluxos de UI)
 
-Quando o robô interage com interface visual (browser headless), usar o skill `eng-qa-testsprite` para gerar e executar testes do fluxo de automação:
-
-```
-/eng-qa-testsprite
-```
+Quando o robô interage com interface visual (browser headless), usar a especialização de testes automatizados registrada em `QA_SPECIALIZATIONS` (via a base `eng-qa`) para gerar e executar testes do fluxo de automação:
 
 - Útil para validar que o fluxo completo (login → navegação → extração) continua funcionando após mudanças
 - Complementa os testes unitários com validação end-to-end contra o sistema-alvo em ambiente controlado
-- Referência: `$IDE/skills/eng-qa-testsprite/SKILL.md`
+- Referência: `$IDE/skills/eng-qa/SKILL.md`
 
 ---
 
@@ -225,6 +221,5 @@ com justificativa explícita. Exceções recorrentes devem ser propostas como at
 ## Referências
 
 - `$IDE/rules/engineering/eng.docs-scraping-rules.md` — padrão de documentação de robôs
-- `$IDE/skills/eng-scraper/SKILL.md` — skill de scraping (Puppeteer, Playwright, ETL)
-- `$IDE/skills/eng-scraper-robot-builder/SKILL.md` — skill de automação via Stagehand
+- `$IDE/skills/eng-automation/SKILL.md` — skill base de automação (+ especializações em `AUTOMATION_SPECIALIZATIONS`)
 - `$IDE/agents/engineering/eng.rpa.agent.md` — agente especializado RPA (ARACHNE)

package/rules/product/README.md

@@ -15,6 +15,7 @@ Documentação didática (termos por extenso, exemplos, quando usar cada comando
 | `/prod.spec.discovery` | [prod.spec.discovery.md](../../docs/produto/prod.spec.discovery.md) |
 | `/prod.spec.prd` | [prod.spec.prd.md](../../docs/produto/prod.spec.prd.md) |
 | `/prod.spec.frd` | [prod.spec.frd.md](../../docs/produto/prod.spec.frd.md) |
+| `/prod.spec.ard` | [prod.spec.ard.md](../../docs/produto/prod.spec.ard.md) |
 | `/prod.spec.breakdown` | [prod.spec.breakdown.md](../../docs/produto/prod.spec.breakdown.md) |
 | `/prod.spec.clarify` | [prod.spec.clarify.md](../../docs/produto/prod.spec.clarify.md) |
 | `/prod.spec.epic` | [prod.spec.epic.md](../../docs/produto/prod.spec.epic.md) |

package/rules/product/prod-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
 
 ## Principais Regras
@@ -98,6 +94,7 @@ Sempre siga as instruções de acordo com as relações abaixo.
 - `$PROD_FLOWS/prod.spec.discovery.md` — Investigação inicial de uma ideia (rascunho estruturado; não define tarefas) → [docs/produto/prod.spec.discovery.md](../../docs/produto/prod.spec.discovery.md)
 - `$PROD_FLOWS/prod.spec.prd.md` — Documento de Requisitos de Produto (*Product Requirements Document*) → [docs/produto/prod.spec.prd.md](../../docs/produto/prod.spec.prd.md)
 - `$PROD_FLOWS/prod.spec.frd.md` — Documento de Requisitos Funcionais (*Functional Requirements Document*) → [docs/produto/prod.spec.frd.md](../../docs/produto/prod.spec.frd.md)
+- `$PROD_FLOWS/prod.spec.ard.md` — ARD a partir do produto (requisitos arquiteturais com o PM; conduz o `eng.create-ard`) → [docs/produto/prod.spec.ard.md](../../docs/produto/prod.spec.ard.md)
 - `$PROD_FLOWS/prod.spec.breakdown.md` — Quebra de especificação grande em fatias → [docs/produto/prod.spec.breakdown.md](../../docs/produto/prod.spec.breakdown.md)
 - `$PROD_FLOWS/prod.spec.clarify.md` — Esclarecimento de ambiguidades na spec → [docs/produto/prod.spec.clarify.md](../../docs/produto/prod.spec.clarify.md)
 - `$PROD_FLOWS/prod.spec.epic.md` — Épico (agrupador de histórias/tarefas) → [docs/produto/prod.spec.epic.md](../../docs/produto/prod.spec.epic.md)

package/rules/product/prod.spec-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: PRODUCT | SQUAD: all
 
 # Regras de Escrita de Especificação de Produto

package/rules/rtk-rules.md

@@ -1,5 +1,4 @@
 ---
-trigger: always_on
 env_file: "@/ENV.md"
 ---
 

package/{rules → rules-on-demand}/engineering/eng.breakdown-subtasks-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
 
 # Regras do Workflow Breakdown Subtasks

package/{rules → rules-on-demand}/engineering/eng.plan-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
 # Regras do Workflow Plan (Planejamento de Execução)

package/{rules → rules-on-demand}/engineering/eng.pr-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
 # Regras do Workflow PR (Pull Request / Merge Request)

package/{rules → rules-on-demand}/engineering/eng.pre-pr-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
 # Regras do Workflow Pre-PR

package/{rules → rules-on-demand}/engineering/eng.start-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
 # Regras do Workflow Start

package/{rules → rules-on-demand}/engineering/eng.tech-spec-rules.md

@@ -1,5 +1,4 @@
 ---
-trigger: always_on
 env_file: "@/ENV.md"
 ---
 
@@ -43,7 +42,7 @@ Sempre siga as instruções de acordo com as relações abaixo:
 
 ### Regras
 
-- **import `$IDE/rules/engineering/eng.tech-spec-rules.md`**: Regras específicas de tech spec (este arquivo)
+- **import `$IDE/rules-on-demand/engineering/eng.tech-spec-rules.md`**: Regras específicas de tech spec (este arquivo)
 
 ---
 

package/{rules → rules-on-demand}/engineering/eng.work-rules.md

@@ -1,7 +1,3 @@
----
-trigger: always_on
----
-
 > **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
 # Regras do Workflow Work