jarvis-ai-framework 1.0.0

package/skills/prod-specs-update/SKILL.md

@@ -0,0 +1,272 @@
+---
+name: prod-specs-update
+description: >
+  Sincroniza especificações de produto (PRD/FRD) em cascata e mantém dois
+  índices atualizados: um local (projeto atual) e um global no Google Drive
+  (todos os projetos). Trigger: quando um PRD ou FRD é criado ou modificado,
+  ou quando o usuário pede para sincronizar ou indexar specs.
+allowed-tools: Read Write Edit Grep Glob Bash MCP
+metadata:
+  author: jarvis-team
+  version: "1.0"
+argument-hint: "[path-do-arquivo-criado-ou-modificado]"
+disable-model-invocation: false
+---
+
+# Update Specs — Sincronização de Especificações de Produto
+
+Você é responsável por manter PRDs, FRDs e os índices de specs sempre
+consistentes. Quando uma spec muda, você propaga em cascata e atualiza
+dois índices: o local do projeto na pasta `docs` e o global no repositório `$CENTRAL_DOCS_REPO`.
+
+O Central Docs é a pasta que centralizamos todas as especificações de produto. Ele serve como referência para todos os projetos e deve ser atualizada sempre que houver mudanças em qualquer spec.
+
+
+## Entrada
+
+- `$ARGUMENTS` — (Opcional) Path do arquivo criado ou modificado.
+- Pergunte para o usuário qual o path do Centarl Docs, que é onde devemos adicionar e atualizar as especificações de produto.
+
+---
+
+## Pré-requisito — Carregar ENV.md
+
+Antes de qualquer ação, ler o `ENV.md` e extrair as variáveis necessárias:
+```bash
+cat ENV.md
+```
+
+Se não existir um `ENV.md`, crie executando a skill `init-jarvis`  com  Skill tool.
+
+---
+
+## Árvore de Decisão
+```
+$ARGUMENTS fornecido?
+  → SIM: Ler frontmatter do arquivo
+      id começa com "PRD"? → Fluxo PRD  
+      id começa com "FRD"? → Fluxo FRD  
+      Nem um nem outro?    → Avisar e encerrar
+  → NÃO: Ir direto para Reconstrução Completa dos Índices
+```
+
+---
+
+## Fluxo de Trabalho
+
+### 1. Fluxo FRD — quando uma FRD foi criada ou modificada
+
+Extrair do frontmatter:
+```bash
+grep -E "^(id|name|status|related_prd):" {arquivo_frd}
+```
+
+**Se `related_prd` estiver ausente ou vazio**, perguntar:
+```
+A FRD "{id}: {name}" não tem PRD pai definido.
+→ Qual é o path do PRD relacionado?
+```
+Atualizar o frontmatter da FRD com o valor informado antes de continuar.
+
+**Abrir o PRD referenciado** e verificar a seção `## Solução`:
+
+- FRD **não aparece na lista** → Adicionar entry:
+  `- **[{id}]({path_relativo}) ({status}):** {name}`
+- FRD **já aparece** → Corrigir status se divergente. Não alterar mais nada.
+
+Mostrar diff proposto ao usuário. Aguardar confirmação antes de escrever.
+
+---
+
+### 2. Fluxo PRD — quando um PRD foi criado ou modificado
+
+Extrair do frontmatter:
+```bash
+grep -E "^(id|name|status):" {arquivo_prd}
+```
+
+Buscar FRDs filhas nos dois diretórios:
+```bash
+grep -rl "related_prd:" $PROD_DOCS --include="*.md"
+```
+
+Filtrar apenas as que apontam para este PRD. Para cada FRD encontrada,
+verificar na seção `## Solução` do PRD se o entry está presente e com
+status correto. Atualizar divergências.
+
+Mostrar diff proposto ao usuário. Aguardar confirmação antes de escrever.
+
+---
+
+### 3. Reconstrução dos Índices
+
+Executado sempre após os fluxos acima, ou diretamente quando `$ARGUMENTS`
+está vazio.
+
+#### 3.1 Escanear specs locais
+```bash
+# PRDs
+find $PROD_DOCS -maxdepth 1 -name "*.md" | xargs grep -l "^id: PRD"
+
+# FRDs
+find $PROD_DOCS_FRD -name "*.md" | xargs grep -l "^id: FRD"
+```
+
+Para cada arquivo, extrair via grep: `id`, `name`, `status`
+(e `related_prd` nas FRDs).
+
+#### 3.2 Obter projeto e repositório para cada PRD
+
+Se o índice local já existir (`$PROD_DOCS/specs-index.md`), reutilizar
+os mapeamentos já registrados.
+
+Para cada PRD **sem mapeamento registrado**, perguntar:
+```
+O PRD "{id}: {name}" ainda não tem projeto ou repositório mapeado.
+→ Projeto: (nome, URL ou "nenhum")
+→ Repositório Git: (nome, URL ou "nenhum")
+```
+
+#### 3.3 Gerar o índice local
+
+Escrever ou atualizar `$PROD_DOCS/specs-index.md` seguindo o template
+de Índice Local abaixo.
+
+#### 3.4 Escanear specs no Drive (se MCP disponível)
+
+Acessar `$CENTRAL_DOCS_REPO` via MCP e listar todos os arquivos `.md`.
+
+Para cada arquivo encontrado, extrair os metadados YAML (`id`, `name`,
+`status`, `related_prd`). Consolidar com os dados locais, deduplizando
+por `id`.
+
+#### 3.5 Gerar o índice global no Drive (se MCP disponível)
+
+Verificar se `specs-index.md` já existe na raiz da pasta do Drive.
+Reutilizar mapeamentos de projeto/repositório já registrados. Perguntar
+apenas o que estiver faltando.
+
+Escrever ou atualizar o `specs-index.md` no Drive seguindo o template
+de Índice Global abaixo.
+
+---
+
+## Templates
+
+### Índice Local (`$PROD_DOCS/specs-index.md`)
+```markdown
+# Índice de Especificações — {WORKSPACE}
+
+Índice das especificações do projeto atual. Atualizado automaticamente
+pela skill `prod-update-specs`.
+
+_Última atualização: {YYYY-MM-DD}_
+
+---
+
+## Relação de Arquivos e Projetos
+
+| Spec | Status | Projeto | Repositório Git |
+|------|--------|---------|-----------------|
+| [PRD-001 — Nome](./prd-001.md) | in_progress | Projeto A | [repo-a](url) |
+| [FRD-001 — Nome](./frds/frd-001.md) | in_review | Projeto A | [repo-a](url) |
+
+---
+
+## Relação PRD → FRDs
+
+### PRD-001: Nome do PRD
+- [FRD-001 — Nome](./frds/frd-001.md) · `in_review`
+- [FRD-002 — Nome](./frds/frd-002.md) · `in_progress`
+```
+
+---
+
+### Índice Global (`specs-index.md` no Drive)
+```markdown
+# Índice Global de Especificações
+
+Índice consolidado de todas as especificações de produto, abrangendo todos
+os projetos. Atualizado automaticamente pela skill `prod-update-specs`.
+
+_Última atualização: {YYYY-MM-DD}_
+
+---
+
+## Relação de Arquivos e Projetos
+
+| Spec | Status | Projeto | Repositório Git |
+|------|--------|---------|-----------------|
+| [PRD-001 — Nome](link-drive) | in_progress | Projeto A | [repo-a](url) |
+| [PRD-002 — Nome](link-drive) | in_review   | Projeto B | [repo-b](url) |
+| [FRD-001 — Nome](link-drive) | in_progress | Projeto A | [repo-a](url) |
+
+---
+
+## Projetos
+
+| Projeto | Specs relacionadas |
+|---------|--------------------|
+| Projeto A | PRD-001, FRD-001, FRD-002 |
+| Projeto B | PRD-002, FRD-003 |
+
+---
+
+## Repositórios
+
+| Repositório | Specs relacionadas |
+|-------------|-------------------|
+| [repo-a](url) | PRD-001, FRD-001, FRD-002 |
+| [repo-b](url) | PRD-002, FRD-003 |
+
+---
+
+## Relação PRD → FRDs
+
+### PRD-001: Nome — Projeto A
+- [FRD-001 — Nome](link-drive) · `in_progress`
+- [FRD-002 — Nome](link-drive) · `in_review`
+
+### PRD-002: Nome — Projeto B
+- [FRD-003 — Nome](link-drive) · `icebox`
+```
+
+---
+
+## Regras
+
+### Nunca
+- Remover entradas existentes de specs ou do índice sem confirmação explícita
+- Sobrescrever mapeamentos de projeto/repositório já registrados sem perguntar
+- Escrever mudanças em cascata sem mostrar o diff antes
+- Alterar o bloco de versionamento dos docs
+
+### Sempre
+- Mostrar resumo das mudanças propostas e aguardar confirmação
+- Preservar paths relativos corretos entre os arquivos
+- Tratar Drive como indisponível graciosamente — nunca bloquear o fluxo local
+- Reutilizar mapeamentos de projeto/repo já existentes nos índices
+
+---
+
+## Checklist de Conclusão
+
+- [ ] ENV.md lido — `$PROD_DOCS`, `$PROD_DOCS_FRD` e `$CENTRAL_DOCS_REPO` extraídos
+- [ ] Disponibilidade do Drive MCP verificada
+- [ ] Tipo do arquivo identificado (PRD / FRD / scan completo)
+- [ ] Cascata de atualizações mapeada e confirmada pelo usuário
+- [ ] Projeto e repositório obtidos para specs sem mapeamento
+- [ ] Índice local gerado em `$PROD_DOCS/specs-index.md`
+- [ ] Índice global gerado no Drive (se MCP disponível)
+- [ ] Links internos validados
+
+---
+
+## Output
+
+| Artefato | Escopo | Condição |
+|----------|--------|----------|
+| `$PROD_DOCS/specs-index.md` | Projeto atual | Sempre |
+| `specs-index.md` no Drive | Todos os projetos | MCP conectado ou Integração ativa |
+| PRDs afetados | Seção "Solução" sincronizada | Quando FRD muda |
+| FRDs afetadas | `related_prd` preenchido | Quando ausente |

package/skills/report-issue/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: report-issue
+description: Reporta um bug no próprio framework Jarvis. A IA reflete sobre qual artefato (skill/workflow/rule) causou o erro, monta o report e abre um issue no repo do Jarvis (GitLab, GitHub ou Bitbucket, conforme VERSION_CONTROL).
+argument-hint: "[descrição opcional do problema]"
+disable-model-invocation: false
+allowed-tools: Read Bash Grep Glob
+license: AGPL-3.0
+metadata:
+  author: jarvis-team
+  version: "1.0"
+---
+
+# report-issue — Auto-report de bug no Framework Jarvis
+
+Você é a IA que acabou de cometer ou identificar um erro causado por uma instrução do Jarvis.
+Sua tarefa é: **refletir sobre o que falhou no framework, montar o report e abrir o issue no repositório do Jarvis**.
+
+O usuário não precisa preencher nada — você é o autor do report.
+
+---
+
+## Fase 1 — Reflexão (obrigatória antes de qualquer ação)
+
+Responda internamente às perguntas abaixo. Use o contexto da conversa atual:
+
+```
+1. Qual skill, workflow ou rule estava sendo executado quando o erro ocorreu?
+   → Nome do artefato + caminho (ex: skills/eng-backend/SKILL.md)
+
+2. O que a instrução dizia que eu deveria fazer?
+   → Transcreva ou resuma a instrução relevante
+
+3. O que eu fiz de errado ou o que saiu diferente do esperado?
+   → Comportamento real vs. comportamento esperado
+
+4. Por que a instrução induziu esse erro?
+   → Ambiguidade? Instrução incompleta? Pressuposto incorreto? Conflito com outra rule?
+
+5. O que deve mudar no artefato para que esse erro não ocorra novamente?
+   → Sugestão concreta de correção (reescrita de instrução, adição de gate, exemplo, etc.)
+```
+
+Se não houver contexto suficiente na conversa, pergunte ao usuário **uma** coisa antes de continuar:
+> "Para abrir o issue, preciso saber: qual skill ou workflow estava sendo executado?"
+
+---
+
+## Fase 2 — Montar o issue
+
+Com as respostas da Fase 1, monte o issue no formato abaixo.
+
+**Título:** `[BUG] {artefato}: {descrição curta do problema em até 80 chars}`
+
+**Corpo:**
+
+```markdown
+## O que aconteceu
+
+{descrição do comportamento errado observado — o que a IA fez de errado}
+
+## O que deveria ter acontecido
+
+{comportamento correto esperado pelo framework}
+
+## Artefato com problema
+
+`{caminho/do/arquivo}` — {seção ou instrução problemática, se identificável}
+
+## Causa raiz (hipótese)
+
+{análise da IA: por que a instrução induziu o erro — ambiguidade, lacuna, conflito}
+
+## Sugestão de correção
+
+{o que deve mudar no artefato para evitar o problema — seja específico}
+
+## Contexto de execução
+
+- **Artefato em execução:** {nome do skill/workflow/rule}
+- **Versão do Jarvis:** {ler de package.json → campo "version"}
+- **Reportado por:** IA (auto-report)
+```
+
+---
+
+## Fase 3 — Credenciais e repo
+
+Ler do `$IDE/ENV.md`:
+
+- `JARVIS_PROJECT` (preferido) ou alias `JARVIS_GITLAB_PROJECT` — URL ou `grupo/repo`
+- `VERSION_CONTROL` — `gitlab` | `github` | `bitbucket` (default pelo hostname da URL)
+
+Se o projeto não estiver definido:
+
+> `🚫 BLOQUEADO: defina JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework` (ou GitLab/Bitbucket) no ENV.md.`
+> → PARAR
+
+Token: o adapter resolve sozinho (`.npmrc` GitLab, `gh auth` / `GITHUB_TOKEN`, `BITBUCKET_TOKEN`).
+
+Versão do Jarvis:
+
+```bash
+grep '"version"' package.json | head -1 | sed 's/.*"version": *"\([^"]*\)".*/\1/'
+```
+
+---
+
+## Fase 4 — Abrir o issue
+
+```bash
+BODY_FILE=$(mktemp)
+# gravar o corpo markdown do issue em $BODY_FILE
+
+REPO=$(grep -E '^(JARVIS_PROJECT|JARVIS_GITLAB_PROJECT)=' $IDE/ENV.md | tail -1 | cut -d= -f2-)
+
+node bin/lib/vcs/create-issue.js \
+  --repo "$REPO" \
+  --title "$ISSUE_TITLE" \
+  --body-file "$BODY_FILE"
+
+rm -f "$BODY_FILE"
+```
+
+---
+
+## Fase 5 — Confirmar ao usuário
+
+Sucesso (exit 0):
+
+```
+✅ Issue aberto com sucesso!
+
+  Título : {título do issue}
+  Artefato: {caminho do arquivo com problema}
+  URL     : {url retornada}
+
+O time do Jarvis vai revisar e corrigir o artefato.
+```
+
+Erro:
+
+```
+🚫 Erro ao abrir issue: {mensagem}
+
+Verifique token (GitLab .npmrc / gh auth / BITBUCKET_TOKEN) e JARVIS_PROJECT.
+```
+
+---
+
+## Regras
+
+- **Nunca** pedir ao usuário que preencha o report — a IA preenche tudo
+- **Nunca** abrir issue sem completar a Fase 1 (reflexão obrigatória)
+- **Nunca** hardcodar o repo ou token — sempre ler `JARVIS_PROJECT` do ENV.md; o adapter resolve o vendor
+- **Sempre** usar label `bug` — sem exceções
+- **Sempre** limpar arquivos temporários após o curl

package/taxonomy.md

@@ -0,0 +1,270 @@
+# Taxonomia Organizacional
+Define a estrutura organizacional, vocabulário e configurações do framework Jarvis
+
+> **📝 Como usar**: Este arquivo define as opções válidas para variáveis do ENV.md.
+> Edite este arquivo para customizar as opções da sua organização antes de instalar o framework.
+>
+> **Domínio de Email**: Configure `DOMAIN:` para validar emails corporativos (ex: `DOMAIN: suaempresa.com.br`)
+
+---
+
+## 🏢 Squads (Times de Desenvolvimento)
+
+Squads são times multidisciplinares. Customize via `/taxonomy`. Skills e agentes técnicos (RPA, Data, QA, etc.) **não** dependem destes nomes.
+
+### CORE
+channel_id:
+board_code:
+modules:
+Time principal. Adicione squads da sua organização com `/taxonomy add SQUADS`.
+
+### SUPPORT
+channel_id:
+board_code:
+modules: atendimento, chamados, triagem, diagnostico, escalonamento
+Time de suporte técnico — Tech Analysts. Transversal às squads de desenvolvimento.
+
+---
+
+## 🎯 Hubs (Áreas Técnicas)
+
+Hubs representam especialidades técnicas dentro da organização.
+
+### AI
+Inteligência Artificial, Jarvis, Chatbots, n8n, agents
+
+### FRONTEND
+Desenvolvimento de interfaces de usuário, web e mobile
+
+### BACKEND
+Desenvolvimento de APIs, serviços, microsserviços e integrações
+
+### QA
+Quality Assurance, testes automatizados, testes manuais e garantia de qualidade
+
+### DATA
+Engenharia e análise de dados, pipelines, BI e operações de dados, Machine Learning, Data Science e modelos preditivos
+
+### FULLCYCLE
+Desenvolvedor que atua em todas as camadas técnicas (frontend, backend e, quando necessário, dados) do início ao fim de uma entrega — em qualquer verificação de HUB, é tratado como coringa/superusuário: satisfaz qualquer HUB exigido, nunca bloqueado por applies_to HUB específico
+---
+
+## 👤 Positions (Cargos e Senioridades)
+
+Níveis de senioridade e cargos técnicos na organização.
+
+### HEAD
+Líder de área (Engenharia, Produto, Vendas)
+- Responsável por uma área técnica ou de negócio
+- Gestão de pessoas e direção técnica/produto
+- Interface entre squads e liderança executiva
+
+### JUNIOR
+Desenvolvedor Júnior (0-2 anos de experiência)
+- Aprendendo tecnologias e processos
+- Pede ajuda quando precisar — sem gate obrigatório de TL/PM
+- Foco em desenvolver habilidades técnicas
+- No fluxo downstream: dono ponta-a-ponta do card que assumiu (puxar, implementar, MR, validar, deploy)
+
+### PLENO
+Desenvolvedor Pleno (2-4 anos de experiência)
+- Autonomia em tarefas individuais
+- Contribui para decisões técnicas
+- Mentoría desenvolvedores júnior
+- No fluxo downstream: dono ponta-a-ponta do card que assumiu
+
+### SENIOR
+Desenvolvedor Sênior (4+ anos de experiência)
+- Alta autonomia técnica
+- Toma decisões arquiteturais
+- Mentoria e liderança técnica
+- No fluxo downstream: dono ponta-a-ponta do card que assumiu
+
+### TECH LEAD
+Líder técnico de time ou squad
+- Responsável por direção técnica do time
+- Coordena desenvolvimento e arquitetura
+- Interface entre time e stakeholders
+- No fluxo downstream: apoia o time. Não é gate — o profissional que assumiu o card conduz ponta-a-ponta. TL desbloqueia e cobre quando pedido.
+
+### SPECIALIST
+Especialista em área técnica ou disciplina específica
+- Expert em domínio particular (segurança, performance, etc.)
+- Consultoria técnica para times
+- Define padrões e melhores práticas
+- No fluxo downstream: dono ponta-a-ponta do card que assumiu
+
+### QA-ENGINEER
+Engenheiro de Quality Assurance
+- Planejamento e execução de testes (manuais e automatizados)
+- Reporte e rastreamento de bugs
+- Validação técnica de entregas antes da aprovação de produto
+- No fluxo downstream: apoia o DEV na validação — não move cards, apenas executa e reporta
+
+### PM
+Product Manager
+- Gestão de produto e roadmap
+- Define prioridades e features
+- Interface com stakeholders de negócio
+- No fluxo downstream: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
+
+### TPM
+Technical Product Manager
+- Product Manager com foco técnico
+- Ponte entre produto e engenharia
+- Decisões de produto com viés técnico
+- No fluxo downstream: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
+
+### GPM
+Group Product Manager
+- Gerencia múltiplos PMs
+- Visão estratégica de produto
+- Coordenação entre diferentes áreas
+- No fluxo downstream: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
+
+### TECH ANALYST
+Ponte técnica entre suporte operacional e squads de engenharia — posição de entrada em engenharia
+⚠️ Posição transversal — NÃO pertence a nenhuma squad de desenvolvimento. Squad no ENV.md = SUPPORT.
+- Diagnóstico e triagem técnica de chamados não resolvidos pelo suporte N2
+- Resolução de problemas dentro do escopo via backoffice, scripts e ferramentas internas
+- Escalonamento qualificado: avalia impacto antes de escalar, nunca escala por reflexo
+- Consulta banco de dados para diagnóstico (somente leitura — não escreve em produção)
+- Classifica e registra bugs no Jira com descrição clara, impacto avaliado e área identificada
+- Monitora e atualiza frequência de bugs recorrentes no Jarvis, alertando QA quando necessário
+- Não desenvolve features, não faz deploy, não define prioridades — isso é do PM
+- No fluxo downstream: responsável pela validação operacional pós-deploy e encaminhamento de problemas encontrados em produção
+
+### QUALITY_CHAMPION
+Designação secundária para devs com função parcial de qualidade dentro do squad.
+Não é uma posição de senioridade — o dev mantém seu cargo (JUNIOR, PLENO, SENIOR, etc.).
+Registrado no campo Posição do `members.md` junto com o cargo principal.
+- Responsável por cobertura de testes em features de baixo/médio risco do squad
+- Executa quality gates e orienta outros devs via eng-qa-dev-guide
+- NÃO substitui QA em features críticas, decisões de bloqueio ou sign-off de release
+- Dedicação típica: ~30% do tempo em atividades de qualidade
+- No fluxo downstream: apoia o QA-ENGINEER na cobertura — não toma decisões de bloqueio
+
+### CTO
+Chief Technology Officer
+- Direção estratégica de tecnologia
+- Responsável por toda organização técnica
+- Decisões de alto nível sobre arquitetura e stack
+
+### GENERALIST
+Profissional que acumula funções de outras posições (SPECIALIST, PM, dev, QA etc.) conforme a demanda — típico de times pequenos sem gente dedicada por função
+- Cargo principal (como SPECIALIST), não designação secundária (diferente de QUALITY_CHAMPION)
+- Transita entre ENGINEERING e PRODUCT — não fica restrito a uma única área
+- Em qualquer verificação de POSITION ou AREA, é tratado como coringa/superusuário: satisfaz qualquer valor exigido
+- No fluxo downstream: dono ponta-a-ponta do card que assumiu, com autonomia equivalente a TECH LEAD/staff (ver eng-rules.md)
+
+---
+
+## 📊 Areas (Áreas de Negócio)
+
+Áreas funcionais da organização.
+
+### ENGINEERING
+prefix: eng
+Área de Engenharia
+- Desenvolvimento de software
+- Infraestrutura e operações
+- Inovação tecnológica
+
+### PRODUCT
+prefix: prod
+Área de Produto
+- Gestão de produto
+- Discovery e research
+- Roadmap e estratégia
+
+DOMAIN:
+
+---
+
+## 🌐 Domain (Domínio de Email Corporativo)
+
+Define o domínio de email corporativo para validação e padronização de emails.
+
+**ADICIONAR APENAS UMA LINHA APÓS AREAS:**
+
+```markdown
+DOMAIN:
+```
+
+### Como Funciona
+- Todos os emails devem terminar com `@DOMAIN`
+- Usado na validação de ENV.md durante `/init-jarvis`
+- Garante que apenas emails corporativos sejam registrados
+- Exemplo: `pedro@domain.com.br`, `ana@domain.com.br`
+
+### Para Open Source (Sem Restrição)
+Deixe em branco ou remova a linha:
+
+```markdown
+DOMAIN:
+```
+
+---
+
+## 📝 Como Adicionar Novas Opções
+
+Para adicionar uma nova opção:
+
+1. Adicione o nome em MAIÚSCULAS sob a categoria apropriada
+2. Inclua os campos estruturados (se aplicável)
+3. Inclua uma breve descrição
+4. Execute `/init-jarvis` - as novas opções aparecerão automaticamente
+
+**Exemplo — Squad com channel_id e modules:**
+```markdown
+### MOBILE
+channel_id: C0123456789
+board_code: MOB
+modules: app-ios, app-android, push-notification, deep-link
+Time focado em desenvolvimento mobile nativo (iOS/Android)
+```
+
+> Membros da organização são gerenciados em `members.md`.
+
+**Exemplo — Area com prefix:**
+```markdown
+### DESIGN
+prefix: design
+Área de Design, UX e pesquisa com usuários
+```
+
+> Use `/taxonomy-manager add` para adicionar opções com validação automática.
+
+---
+
+## 🔄 Sincronização
+
+Quando este arquivo é atualizado:
+- Execute `/init-jarvis` para recriar ENV.md com novas opções
+- Ou edite manualmente `$IDE/ENV.md` se já existir
+- As validações nos workflows usarão automaticamente as novas opções
+
+---
+
+## ⚠️ Notas Importantes
+
+1. **Mantenha nomes sem espaços**: Use `-` ou `_` para separar palavras
+   - ✅ `CORE`
+   - ❌ `ENGINEERING CORE`
+
+2. **Use MAIÚSCULAS**: Facilita padronização e busca
+   - ✅ `SENIOR`
+   - ❌ `Senior` ou `senior`
+
+3. **Evite caracteres especiais**: Apenas letras, números, `-` e `_`
+   - ✅ `RPA`, `TECH-LEAD`
+   - ❌ `RPA!`, `TECH/LEAD`
+
+4. **Mantenha consistência**: Uma vez definido, evite mudar nomes existentes
+   - Impacta ENV.md de projetos existentes
+   - Se necessário mudar, comunique toda a organização
+
+5. **Domínio de Email**: Configure uma única vez no início
+   - ✅ `DOMAIN: seudominio.com.br` (validará emails @seudominio.com.br)
+   - ✅ `DOMAIN:` (em branco para sem restrição)
+   - ❌ Múltiplos domínios (use apenas um)