jarvis-ai-framework 1.0.0

package/templates/AGENTS.md

@@ -0,0 +1,189 @@
+# AGENTS.md - Pasta templates/
+
+Instrucoes especificas para agentes de IA que manipulam a pasta de templates.
+
+---
+
+## Proposito desta Pasta
+
+A pasta `templates/` contem **modelos de documentos** usados pelo framework para gerar artefatos padronizados (ARD, RFC, Tech Spec, PR, etc.).
+
+---
+
+## Estrutura
+
+```
+templates/
+├── engineering/                    # Templates tecnicos
+│   ├── architecture-template.md    # Template de arquitetura
+│   ├── ARD-template.md             # Architecture Review Document
+│   ├── RFC-template.md             # Request For Comments
+│   ├── RFC-Playbook@1.0.0.md       # Playbook para RFCs
+│   ├── tech-spec-template.md       # Especificacao tecnica
+│   ├── plan-template.md            # Plano de execucao
+│   ├── work-progress-template.md   # Progresso de trabalho
+│   ├── PR-template.md              # Pull Request
+│   ├── c4-model-template.md        # Diagramas C4
+│   ├── AGENTS-template.md          # Template de AGENTS.md
+│   ├── CONTACTS-template.md        # Template de contatos
+│   └── qa/                         # Templates de QA
+│       ├── test-plan-template.md
+│       └── quality-gate-template.md
+└── product/                        # Templates de produto
+    ├── PRD-template.md             # Product Requirements Document
+    ├── FRD-template.md             # Feature Requirements Document
+    ├── epic-template.md            # Epicos
+    ├── story-template.md           # User Stories
+    └── issue-template.md           # Issues/Tasks
+```
+
+---
+
+## Convencoes de Nomenclatura
+
+| Tipo | Padrao | Exemplos |
+|------|--------|----------|
+| Template padrao | `{nome}-template.md` | `ARD-template.md` |
+| Template com versao | `{nome}@{versao}.md` | `RFC-Playbook@1.0.0.md` |
+| Template de QA | `qa/{nome}-template.md` | `qa/test-plan-template.md` |
+
+---
+
+## Estrutura de um Template
+
+Todo template deve seguir o padrao:
+
+```markdown
+# {Nome do Documento}
+
+> Template para {proposito}. Substitua os placeholders {...}.
+
+## Metadados
+
+| Campo | Valor |
+|-------|-------|
+| Autor | {autor} |
+| Data | {data} |
+| Versao | {versao} |
+
+## Secao 1
+{conteudo}
+
+## Secao 2
+{conteudo}
+
+---
+
+**Notas para o agente**:
+- Instrucao 1
+- Instrucao 2
+```
+
+---
+
+## Placeholders
+
+Use chaves `{...}` para indicar campos a serem preenchidos:
+
+| Placeholder | Descricao |
+|-------------|-----------|
+| `{nome}` | Nome do documento/feature |
+| `{autor}` | Autor do documento |
+| `{data}` | Data de criacao |
+| `{versao}` | Versao do documento |
+| `{descricao}` | Descricao do conteudo |
+| `{...}` | Conteudo especifico |
+
+---
+
+## Templates por Dominio
+
+### Engineering
+
+| Template | Uso | Comando |
+|----------|-----|---------|
+| `architecture-template.md` | Design arquitetural | `/eng.start` |
+| `ARD-template.md` | Revisao de arquitetura | `/eng.create-ard` |
+| `RFC-template.md` | Proposta de mudanca | `/eng.create-rfc` |
+| `tech-spec-template.md` | Especificacao tecnica | `/eng.build-tech-spec` |
+| `plan-template.md` | Plano de execucao | `/eng.plan` |
+| `PR-template.md` | Pull Request | `/eng.pr` |
+
+### Product
+
+| Template | Uso | Comando |
+|----------|-----|---------|
+| `PRD-template.md` | Requisitos de produto | `/prod.spec.prd` |
+| `FRD-template.md` | Requisitos de feature | `/prod.spec.frd` |
+| `epic-template.md` | Epicos | `/prod.spec.epic` |
+| `story-template.md` | User Stories | `/prod.spec.issue` |
+
+---
+
+## Regras
+
+### Nunca
+
+- Modificar template sem atualizar workflows dependentes
+- Remover campos obrigatorios de um template
+- Criar template sem placeholders claros
+- Usar formatacao inconsistente entre templates
+- Criar template duplicado (verifique antes)
+
+### Sempre
+
+- Manter consistencia visual entre templates do mesmo dominio
+- Documentar campos obrigatorios vs opcionais
+- Incluir notas para o agente quando necessario
+- Versionar templates com mudancas significativas
+- Atualizar este AGENTS.md ao adicionar novo template
+
+---
+
+## Relacao com Outros Componentes
+
+| Componente | Relacao |
+|------------|---------|
+| Workflows | Workflows usam templates para gerar documentos |
+| Skills | Skills referenciam templates para outputs |
+| Commands | Commands disparam workflows que usam templates |
+| Rules | Rules definem quando usar cada template |
+
+---
+
+## Criando Novo Template
+
+1. Identificar necessidade (nao duplicar existente)
+2. Seguir convencao de nomenclatura
+3. Definir placeholders claros
+4. Incluir metadados padrao
+5. Adicionar notas para o agente
+6. Atualizar este AGENTS.md
+7. Vincular ao workflow correspondente
+
+---
+
+## Validacao de Template
+
+Checklist ao criar/editar:
+
+- [ ] Nomenclatura segue padrao
+- [ ] Placeholders usam `{...}`
+- [ ] Secao de metadados presente
+- [ ] Notas para agente incluidas
+- [ ] Consistente com templates do mesmo dominio
+- [ ] AGENTS.md atualizado
+- [ ] Workflow vinculado (se aplicavel)
+
+---
+
+## Referencias
+
+- `../workflows/` - Workflows que usam templates
+- `../skills/` - Skills que referenciam templates
+- `../commands/` - Commands que disparam uso
+- `../rules/` - Rules que governam templates
+
+---
+
+**Ultima atualizacao**: 2026-01-26

package/templates/CDD aplicado a Prompts.md

@@ -0,0 +1,182 @@
+CDD aplicado a Prompts                                                                          
+                                                                                                  
+  1. Contexto como input primário (você já faz isso)                                              
+                                                                                                  
+  O ENV.md é CDD puro — ele injeta variáveis de contexto (WORKSPACE, SQUAD, POSITION,          
+  MAX_AI_EXECUTION_PERCENTAGE) que mudam o comportamento dos prompts sem alterar o prompt em si.  
+                                                                                                  
+  Pra ir além: os prompts poderiam adaptar seu nível de detalhe, tom e complexidade com base no   
+  contexto. Exemplo:                                                                              
+                                                                                                  
+  ## Comportamento Adaptativo                                                                     
+  - Se `POSITION` = junior → explicar decisões, sugerir leituras                                  
+  - Se `POSITION` = senior → ser direto, focar em trade-offs                                      
+  - Se `MAX_AI_EXECUTION_PERCENTAGE` > 80 → executar mais, perguntar menos                        
+  - Se `MAX_AI_EXECUTION_PERCENTAGE` < 30 → planejar mais, executar menos                         
+                                                                                                  
+  2. Rejeitar "best practices" universais                                                         
+                                                                                                  
+  CDD diz: não existe prompt universalmente melhor. O que muda:                                   
+  ┌────────────────────┬─────────────────────────────────────────────┐                            
+  │      Contexto      │              Impacto no prompt              │                            
+  ├────────────────────┼─────────────────────────────────────────────┤                            
+  │ Projeto greenfield │ Menos restrições, mais exploração           │                            
+  ├────────────────────┼─────────────────────────────────────────────┤                            
+  │ Projeto legacy     │ Mais análise de impacto, mais cautela       │                            
+  ├────────────────────┼─────────────────────────────────────────────┤                            
+  │ Hotfix em produção │ Skip de documentação, foco cirúrgico        │                            
+  ├────────────────────┼─────────────────────────────────────────────┤                            
+  │ Feature complexa   │ Forçar artefatos (ARD, RFC) antes de código │                            
+  └────────────────────┴─────────────────────────────────────────────┘                            
+  Seus workflows hoje seguem um fluxo linear (start → plan → work → pr). CDD sugeriria que o fluxo
+   se adapte ao contexto da tarefa, não o contrário.                                              
+                                                                                                  
+  3. Prompts que detectam contexto ao invés de assumir                                            
+                                                                                                  
+  Em vez de instruções rígidas, prompts CDD investigam antes de agir:                             
+                                                                                                  
+  ## Fase 0: Análise de Contexto                                                                  
+  Antes de executar, determine:                                                                   
+  1. **Tipo de mudança**: bug fix, feature, refactor, hotfix?                                     
+  2. **Risco**: Quantos componentes são impactados?                                               
+  3. **Maturidade do código**: Tem testes? Tem docs? Tem padrões claros?                          
+  4. **Pressão**: Tem deadline? É incidente?                                                      
+                                                                                                  
+  → Adapte o rigor das fases seguintes com base nessas respostas.                                 
+                                                                                                  
+  4. Regras como guardrails contextuais, não leis absolutas                                       
+                                                                                                  
+  Seus rules/ hoje são binários (NUNCA/SEMPRE). CDD sugere graduação:                             
+                                                                                                  
+  ## Regra: Documentação                                                                          
+                                                                                                  
+  ### Contexto A: Feature nova com impacto arquitetural                                           
+  - ✅ Obrigatório: architecture.md, tech-spec.md, ARD                                            
+  - ✅ Obrigatório: aprovação antes de código                                                     
+                                                                                                  
+  ### Contexto B: Bug fix isolado                                                                 
+  - ⚠️ Opcional: apenas comentário no PR explicando root cause                                    
+  - ❌ Desnecessário: architecture.md                                                             
+                                                                                                  
+  ### Contexto C: Hotfix de produção                                                              
+  - ❌ Skip total: documentar DEPOIS do deploy                                                    
+                                                                                                  
+  5. Agents com consciência contextual                                                            
+                                                                                                  
+  Seus agents hoje são personas fixas. Com CDD, eles se calibram:                                 
+                                                                                                  
+  ## Calibração do Agent                                                                          
+  Ao iniciar, avalie:                                                                             
+  - Se o dev pediu "rápido" ou "urgente" → reduzir cerimônia                                      
+  - Se existem testes no projeto → exigir testes                                                  
+  - Se NÃO existem testes → sugerir, mas não bloquear                                             
+  - Se o projeto usa TypeScript strict → impor tipagem                                            
+  - Se o projeto usa JS vanilla → não forçar tipos                                                
+                                                                                                  
+  6. Meta-princípio: o prompt deve perguntar, não assumir                                         
+                                                                                                  
+  O anti-padrão mais comum em prompts é assumir contexto que não existe. CDD resolve com:         
+                                                                                                  
+  - Perguntas de calibração no início do workflow                                                 
+  - Defaults inteligentes baseados no ENV.md                                                      
+  - Escape hatches — sempre permitir que o dev override o fluxo                                   
+                                                                                                  
+  ---                                                                                             
+  Resumo prático                                                                                  
+  ┌───────────────────────────────┬──────────────────────────────────────────┐                    
+  │         Princípio CDD         │           Aplicação em Prompts           │                    
+  ├───────────────────────────────┼──────────────────────────────────────────┤                    
+  │ Contexto > Processo           │ ENV.md + detecção automática de contexto │                    
+  ├───────────────────────────────┼──────────────────────────────────────────┤                    
+  │ Sem "best practice" universal │ Fluxos adaptativos por tipo de tarefa    │                    
+  ├───────────────────────────────┼──────────────────────────────────────────┤                    
+  │ Pessoas > Regras              │ Calibração por POSITION e preferências   │                    
+  ├───────────────────────────────┼──────────────────────────────────────────┤                    
+  │ Pensamento crítico            │ Fase 0 de análise antes de execução      │                    
+  ├───────────────────────────────┼──────────────────────────────────────────┤                    
+  │ Adaptação contínua            │ Regras graduais ao invés de binárias     │                    
+  └───────────────────────────────┴──────────────────────────────────────────┘                    
+  O Framework Jarvis já tem a infraestrutura pra CDD (ENV, agents, rules separados). O próximo   
+  passo seria tornar os prompts conscientes do contexto ao invés de apenas configurados por       
+  contexto.                                                                                       
+                                                                                                  
+  ---
+
+## ✅ Implementações Realizadas
+
+As seguintes mudanças foram aplicadas para tornar o framework aware:
+
+### 1. Workflows com Fase 0 de Análise de Contexto
+
+| Workflow | Mudança |
+|----------|---------|
+| `eng.start.md` | Nova Fase 0 que classifica tarefa (hotfix/bugfix/feature/refactor), calibra por POSITION e MAX_AI_EXECUTION_PERCENTAGE, define CONTEXT_PROFILE |
+| `eng.plan.md` | Fase 0 que herda contexto e ajusta granularidade do plano por tipo de tarefa |
+| `eng.work.md` | Fase 0 que herda CONTEXT_PROFILE e calibra testes/validações automaticamente |
+
+### 2. Rules Graduais por Contexto
+
+Em `eng-rules.md`, nova seção "Regras Graduais por Contexto (CDD)" com tabelas para:
+- Documentação obrigatória/opcional/desnecessária por tipo de tarefa
+- Rigor de testes por contexto do projeto (cobertura existente)
+- Code review por tamanho de PR
+- Autonomia da AI por POSITION
+
+### 3. Agents com Calibração Contextual
+
+| Agent | Mudança |
+|-------|---------|
+| `eng.agent.md` | Seção "Calibração Contextual (CDD)" com detecção automática de projeto (testes, TypeScript strict, CI/CD), detecção de urgência por palavras-chave, ajuste silencioso de comportamento |
+| `eng.qa.testing-engineer.md` | Calibração por cobertura existente, tipo de tarefa, POSITION e urgência |
+
+### 4. CONTEXT_PROFILE
+
+Novo padrão que flui entre workflows:
+
+```
+CONTEXT_PROFILE:
+  tipo: [hotfix|bugfix|feature|refactor]
+  rigor: [mínimo|padrão|alto]
+  comunicacao: [didático|direto|estratégico]
+  autonomia: [baixa|média|alta]
+```
+
+- Definido no `eng.start` (Fase 0)
+- Herdado por `eng.plan` e `eng.work`
+- Permite consistência de contexto ao longo do ciclo
+
+### 5. Skill de Detecção de Contexto
+
+Criado o skill `/context-detect` em `$IDE/skills/context-detect/SKILL.md` que:
+- Centraliza toda a lógica de detecção CDD
+- Detecta tipo de tarefa pela branch e jira key
+- Analisa características do projeto (testes, TypeScript, CI/CD, linter)
+- Lê POSITION e MAX_AI_EXECUTION_PERCENTAGE do ENV.md
+- Gera arquivo `context.md` com CONTEXT_PROFILE completo
+- Suporta override manual via parâmetros
+
+**Uso:**
+```
+/context-detect [jira-key]
+/context-detect --override tipo=hotfix urgencia=alta
+```
+
+**Fluxo de integração:**
+```
+/context-detect → context.md
+        ↓
+eng.start (Fase 0) ← lê context.md
+        ↓
+eng.plan (Fase 0) ← herda
+        ↓
+eng.work (Fase 0) ← herda
+```
+
+---
+
+## Próximos Passos Sugeridos
+
+1. ~~**Aplicar CDD nos agents de QA restantes**~~: ✅ `eng.qa.test-architect.md`, `eng.qa.test-planner.md`
+2. ~~**Criar skill de detecção de contexto**~~: ✅ Implementado em `/context-detect`
+3. ~~**Adicionar escape hatches explícitos**~~: ✅ Implementado via `--override`
+4. **Integração com Jira**: Detectar tipo de tarefa automaticamente via API do Jira

package/templates/ENV-template.md

@@ -0,0 +1,187 @@
+# =============================================================================
+# ENV.md — contexto do workspace para o Jarvis
+# =============================================================================
+# Copiado para $IDE/ENV.md pelo /init-jarvis.
+# Valores entre [colchetes] são opções — escolha UMA e apague o resto.
+# Deixe em branco o que não usar. Não coloque tokens/segredos no chat.
+# =============================================================================
+
+
+# --- Workspace e identidade --------------------------------------------------
+# Workspace = a pasta que contém $IDE/. Não é o nome de um repo.
+# Vazio: o CLI usa o nome dessa pasta. Preencha só se quiser outro slug.
+#
+#   meu-app/                    ← um git aqui
+#   ├── .windsurf/ENV.md
+#   ├── .jarvis/sessions/
+#   └── .git/
+#
+#   workspace-squad/            ← vários gits nas subpastas
+#   ├── .windsurf/ENV.md
+#   ├── .jarvis/sessions/
+#   ├── repo-api-1/
+#   └── repo-frontend/
+#
+# WORKSPACE_REPOS = allowlist opcional. Vazio = todas as subpastas com .git/.
+WORKSPACE=
+WORKSPACE_REPOS=
+USER=
+
+# Limite de autonomia da IA neste workspace (60–100). 80 = a IA executa até 80%.
+MAX_AI_EXECUTION_PERCENTAGE=80
+
+# Context-Driven Development — deixe true. O warm-up calibra o comportamento.
+ENABLE_CDD=true
+
+
+# --- Organização (obrigatório — opções vêm do taxonomy.md) -------------------
+SQUAD=[CORE, SUPPORT]
+HUB=[AI, FRONTEND, BACKEND, QA, DATA, FULLCYCLE]
+AREA=[ENGINEERING, PRODUCT]
+POSITION=[JUNIOR, PLENO, SENIOR, TECH LEAD, SPECIALIST, PM, TPM, GPM, CTO, GENERALIST]
+
+
+# --- IDE e pastas ------------------------------------------------------------
+# Qual IDE este ENV.md alimenta. FLOWS_FOLDER: workflows (maioria) ou commands (Claude).
+IDE=[windsurf, claude, cursor, codex, opencode, gemini, antigravity]
+DOCS_FOLDER=docs
+FLOWS_FOLDER=[workflows se IDE != claude | commands se IDE = claude]
+TEMPLATES_FOLDER=templates
+RULES_FOLDER=.$IDE/rules
+
+# Sessões de trabalho — relativo à pasta do workspace (a que contém $IDE/), não ao cwd.
+# jarvis init cria .jarvis/sessions/{eng,prod,qa} e adiciona .jarvis/ ao .gitignore.
+#   $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
+#   $SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/
+#   $SESSIONS_DIR/qa/
+# Cookie/HTTP session (auth) NÃO é esta pasta.
+SESSIONS_DIR=.jarvis/sessions
+
+# Pastas de produto (derivadas das de cima — em geral não precisa mexer)
+PROD_FOLDER_NAME=product
+PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
+PROD_FLOWS=.$IDE/$FLOWS_FOLDER/$PROD_FOLDER_NAME
+PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
+PROD_DOCS=$DOCS_FOLDER/$PROD_FOLDER_NAME
+
+
+# --- Task manager (opcional) -------------------------------------------------
+# Board de cards. Vazio = freelance: sem Jira/Linear/etc.
+# Nesse caso o workflow pergunta um número de controle próprio (TASK_MANAGER_KEY)
+# e usa isso na pasta da sessão e no nome da branch.
+# URL base para links nos alertas (ex: https://empresa.atlassian.net).
+TASK_MANAGER=[jira, linear, github, asana]
+TOKEN_TASK_MANAGER=
+TASK_MANAGER_URL_BASE=
+
+
+# --- Controle de versão (opcional) -------------------------------------------
+# Token NÃO vai aqui: GitLab → .npmrc; GitHub → gh auth ou GITHUB_TOKEN;
+# Bitbucket → BITBUCKET_TOKEN.
+VERSION_CONTROL=[gitlab, github, bitbucket]
+
+
+# --- Mensageria (opcional) ---------------------------------------------------
+MESSAGE_BROKER=[rabbitmq, kafka, sqs]
+MESSAGE_BROKER_URL_API=
+MESSAGE_BROKER_API_AUTH=
+
+
+# --- Banco de dados (opcional) -----------------------------------------------
+DATABASE=[mysql, postgres, mongodb]
+USER_DATABASE=
+PASSWORD_DATABASE=
+HOST_DATABASE=
+PORT_DATABASE=
+
+
+# --- Chat / comunicador (opcional) -------------------------------------------
+# slack: BOT_TOKEN + SIGNING_SECRET + APP_TOKEN (Socket Mode)
+# discord: BOT_TOKEN (Bot) + ALERTS_CHANNEL = ID do canal
+# teams: BOT_TOKEN = URL do Incoming Webhook (SIGNING/APP vazios)
+MESSAGE_COMUNICATOR=[slack, discord, teams]
+MESSAGE_COMUNICATOR_BOT_TOKEN=
+MESSAGE_COMUNICATOR_SIGNING_SECRET=
+MESSAGE_COMUNICATOR_APP_TOKEN=
+ALERTS_CHANNEL=
+
+
+# --- Object storage (opcional) -----------------------------------------------
+OBJECT_STORAGE=[aws_s3, gcs, azure_blob]
+TOKEN_OBJECT_STORAGE=
+
+
+# --- Observabilidade (opcional) ----------------------------------------------
+OBSERVABILITY=[sentry, datadog, grafana]
+TOKEN_OBSERVABILITY=
+OBSERVABILITY_ORG=
+
+
+# --- SMTP (opcional) ---------------------------------------------------------
+SMTP=[google, ses, sendgrid]
+
+
+# --- RTK — Token Killer (opcional) -------------------------------------------
+# Proxy CLI em Rust que comprime output de shell (economia 60–90% de tokens).
+# Instale com: cargo install rtk (requer Rust).
+# false = a rule RTK não é copiada para $IDE/rules/.
+RTK_ENABLED=false
+
+
+# --- Tech Analyst (opcional) -------------------------------------------------
+# Project key do board de triagem N2 (cards que chegam ao Tech Analyst).
+TASK_MANAGER_HUBS_BOARD=
+
+
+# --- Data Engineering (só se HUB=DATA) ---------------------------------------
+# Obrigatório quando HUB=DATA. Omitir o bloco inteiro se o HUB for outro.
+DATA_ORCHESTRATOR=[airflow, prefect, dagster, glue-scheduler]
+DATA_ETL_TOOL=[aws_glue, dbt, spark, pandas]
+DATA_QUALITY_TOOL=[great_expectations, soda, deequ]
+DATA_LAKE=[aws_s3, gcs, azure_adls]
+DATA_QUERY_ENGINE=[aws_athena, bigquery, redshift, trino]
+DATA_BI_TOOL=[metabase, looker, superset, power_bi]
+# Vazio se não houver warehouse dedicado.
+DATA_WAREHOUSE=[redshift, snowflake, bigquery]
+DATA_REPO=[data-pipelines, etl-jobs, analytics-pipelines]
+
+
+# --- Code quality (opcional) -------------------------------------------------
+# Análise estática / quality gate. Em branco = sem MCP de code quality.
+CODE_QUALITY_TOOL=[sonarqube, codeclimate, deepsource]
+# URL da instância (self-hosted).
+CODE_QUALITY_URL=
+CODE_QUALITY_TOKEN=
+
+
+# --- QA / suíte de testes (opcional) -----------------------------------------
+# Caminho relativo à raiz do projeto.
+# Cypress E2E: cypress | e2e | tests/e2e
+# Unit/integração: tests | test | src/__tests__
+TEST_FOLDER=
+
+
+# --- QA / release sign-off (opcional) ----------------------------------------
+# Branches que exigem sign-off QA antes do deploy (vírgula, aceita glob).
+# Em branco = validação no CI desligada.
+QA_SIGNOFF_BRANCHES=main,release/*
+# Validade do sign-off em horas. Mais antigo que isso o CI rejeita.
+QA_SIGNOFF_MAX_AGE=24
+
+
+# --- Reportar bug no próprio Jarvis (opcional) ------------------------------
+# URL ou path curto do repo do framework (ex: https://github.com/phelipperibeiro/jarvis-framework).
+# Usado pelo skill /report-issue. Alias: JARVIS_GITLAB_PROJECT.
+# Token: GitLab .npmrc | GitHub gh auth / GITHUB_TOKEN | Bitbucket BITBUCKET_TOKEN.
+JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework
+
+
+# --- Central docs (opcional) -------------------------------------------------
+# Repo de documentação canônica (PRD, FRD, ARD, RFC). Em branco = desligado.
+CENTRAL_DOCS_REPO=
+CENTRAL_DOCS_REF=main
+CENTRAL_DOCS_TARGET_BRANCH=main
+# Revisores padrão dos MRs (separados por vírgula).
+CENTRAL_DOCS_REVIEWERS=
+# TTL do cache opcional (redis-cli, se existir). 3600 = 1 hora.
+CENTRAL_DOCS_CACHE_TTL=3600

package/templates/engineering/AGENTS-template.md

@@ -0,0 +1,71 @@
+ AGENTS.md
+
+> Este arquivo segue a convenção [AGENTS.md](https://agents.md/) - um formato aberto para guiar agentes de IA em projetos de código.
+
+ Project Overview
+
+{WORKSPACE} é o workspace da área {AREA} do hub {HUB}, mantido pelo squad {SQUAD}.
+
+{PROJECT_DESCRIPTION}
+
+ Tech Stack
+
+{TECH_STACK}
+
+ Setup Commands
+
+```bash
+{SETUP_COMMANDS}
+```
+
+ Code Style
+
+{CODE_STYLE}
+
+ Testing Instructions
+
+{TESTING_INSTRUCTIONS}
+
+ PR Instructions
+
+- Formato do título: `{TASK_MANAGER_KEY}-{titulo-em-kebab-case}`
+- Mensagem de commit: `{tipo}({escopo}): {descrição}`
+- Sempre execute lint e testes antes de commitar
+- Referencie o TASK_MANAGER_KEY no commit: `Refs: {TASK_MANAGER_KEY}`
+
+ Security Considerations
+
+- Nunca commite credenciais, tokens ou senhas
+- Use variáveis de ambiente para dados sensíveis
+- Siga as práticas de segurança definidas em `{IDE_FOLDER}/rules/engineering/`
+- Reporte vulnerabilidades ao time de segurança
+
+ Available Workflows
+
+O projeto utiliza o framework JARVIS com os seguintes comandos principais:
+
+| Comando | Descrição |
+|---------|-----------|
+| `/init-jarvis` | Inicializar ambiente e criar ENV.md |
+| `/eng.start` | Iniciar nova tarefa (cria architecture.md) |
+| `/eng.plan` | Criar plano de execução faseado |
+| `/eng.work` | Implementar código seguindo o plano |
+| `/eng.pr` | Criar branch, commit e Merge Request |
+| `/eng.debug` | Investigar e resolver bugs |
+
+ For AI Agents
+
+Se você é um agente de IA trabalhando neste projeto:
+
+. Leia primeiro: `{IDE_FOLDER}/README.md` para entender o framework JARVIS
+. Regras: Siga as regras em `{IDE_FOLDER}/rules/`
+. Sessões: Use `{IDE_FOLDER}/sessions/` para contexto de tarefas em andamento
+. Templates: Use os templates em `{IDE_FOLDER}/templates/` para documentos
+. Idioma: Toda documentação deve ser em português do Brasil (pt-BR)
+
+ Additional Resources
+
+- README.md - Visão geral do projeto para humanos
+- {IDE_FOLDER}/JARVIS.md - Guia completo do framework
+- {IDE_FOLDER}/MCPs.md - Integrações MCP disponíveis
+- CONTACTS.md - Contatos do time