---
title: "Sistemas de regras e orientação de comportamento"
description: "Controlando o comportamento do Verdent por meio de sistemas de regras"
---

Arquivos de regras são documentos Markdown que definem como o Verdent se comporta e responde durante as sessões de codificação. Eles orientam o comportamento do agente de IA, a formatação da saída, a tomada de decisões e a aderência aos padrões do projeto.

**Objetivo:** As regras permitem que você personalize o comportamento do Verdent sem alterar código ou configurações. Elas estabelecem convenções de codificação, padrões preferidos, estilo de comunicação e preferências de execução de tarefas que persistem entre as sessões.

**Como as regras funcionam:** O Verdent consulta continuamente os arquivos de regras durante as conversas, aplicando diretrizes à geração de código, análise, documentação e tomada de decisões. As regras influenciam todas as respostas do agente para garantir consistência com as preferências do usuário.

**Três categorias:**

- **Preferências globais** (VERDENT.md) - Estilo pessoal de codificação, preferências de idioma
- **Padrões específicos do projeto** (AGENTS.md) - Convenções da equipe, padrões arquiteturais
- **Personalização de plano** (Plan.md) - Formato e conteúdo da saída do Plan Mode

**Precedência de regras:** Quando as regras entram em conflito, o Verdent aplica a seguinte precedência: **AGENTS.md** (mais alta) → **VERDENT.md** (média) → **padrões** (mais baixa)

---

## Regras do usuário (VERDENT.md)

O VERDENT.md define preferências globais que se aplicam a todos os projetos e sessões. Ele estabelece o estilo pessoal de codificação, ferramentas preferidas, preferências de comunicação e comportamentos padrão.

### Localização e escopo

**Localização do arquivo:** `~/.verdent/VERDENT.md`

**Escopo:** Global para todos os projetos

**Acesso:**

- Settings → Rules → User Rules
- Edição direta do arquivo em `~/.verdent/VERDENT.md`

**Quando as alterações entram em vigor:** As regras se aplicam imediatamente em novas conversas e influenciam as respostas da conversa atual.

---

### Casos de uso

<Tabs>
  <Tab title="Preferências de codificação">
    **Preferências de codificação**

    - Estilo de indentação (2 espaços, 4 espaços, tabs)
    - Convenções de nomenclatura (camelCase, snake_case, PascalCase)
    - Recursos de linguagem preferidos (ES6+, modo strict do TypeScript, type hints)

    Defina seu estilo pessoal de codificação e convenções aplicadas em todos os projetos.
  </Tab>
  <Tab title="Idioma da saída">
    **Idioma da saída**

    - Idioma padrão das respostas (por exemplo, "Sempre responda em espanhol")
    - Tratamento de termos técnicos ("Use termos em inglês quando não houver equivalente em francês")

    Controle o idioma que o Verdent usa nas respostas e explicações.
  </Tab>
  <Tab title="Comentários de código">
    **Comentários de código**

    - Nível de detalhe preferido ("Comentários detalhados" vs "Apenas comentários mínimos")
    - Idioma dos comentários ("Escreva comentários em francês")

    Especifique quanto e em qual idioma o código deve ser comentado.
  </Tab>
  <Tab title="Documentação">
    **Estilo de documentação**

    - Como o código deve ser documentado (JSDoc, TSDoc, docstrings)
    - Incluir exemplos de uso na documentação

    Defina padrões para a documentação do API e o formato de documentação de código.
  </Tab>
  <Tab title="Comunicação">
    **Comunicação**

    - Tom e nível de detalhe das respostas ("Explicações breves" vs "Explicações detalhadas")
    - Estilo de explicação ("Mostre o código primeiro, explique depois")

    Personalize como o Verdent se comunica e apresenta informações para você.
  </Tab>
</Tabs>

---

### Formato e sintaxe

O VERDENT.md usa o formato Markdown simples com marcadores ou listas numeradas.

**Estrutura:**

```markdown
# User Rules

## Code Style Preferences
- Always use TypeScript strict mode
- Prefer functional components in React
- Include JSDoc comments for exported functions

## Documentation
- Add JSDoc comments for all exported functions
- Include usage examples in component documentation

## Communication
- Provide explanations before showing code
- Highlight breaking changes explicitly
```

**Estilo de escrita:**

- Use linguagem clara e diretiva ("Sempre use...", "Prefira...", "Nunca...")
- Organize em seções lógicas com cabeçalhos
- Use marcadores para regras individuais
- Seja específico sobre o comportamento desejado

---

### Exemplos por tipo de desenvolvedor

<Tabs>
  <Tab title="TypeScript">
    ```markdown
    # User Rules

    ## TypeScript Preferences
    - Use strict mode in tsconfig.json
    - Prefer interfaces over type aliases for object shapes
    - Include return types on all functions
    - Use const assertions where appropriate

    ## Code Organization
    - One component per file
    - Named exports instead of default exports
    - Organize imports: external, internal, types

    ## Documentation
    - TSDoc comments for public APIs
    - Include @param and @returns tags
    ```

    **Aplicação:** Quando você pede ao Verdent para criar um novo componente React, ele automaticamente:

    - Usa TypeScript com modo strict
    - Cria uma exportação nomeada (não default)
    - Adiciona comentários TSDoc com tags @param/@returns
    - Organiza imports por categoria
  </Tab>
  <Tab title="Python Data Science">
    ```markdown
    # User Rules

    ## Python Style
    - Follow PEP 8 conventions
    - Use type hints for function signatures
    - Prefer list comprehensions over map/filter

    ## Data Analysis
    - Use pandas for data manipulation
    - Include DataFrame.head() after transformations
    - Document assumptions about data

    ## Output Format
    - Show shape and info() after operations
    - Include visualization examples
    ```

    **Aplicação:** Quando você pede ao Verdent para escrever código de análise de dados, ele irá:

    - Usar pandas para operações de dados
    - Incluir type hints em todas as funções
    - Mostrar DataFrame.head() e shape após transformações
    - Adicionar comentários inline documentando suposições sobre os dados
  </Tab>
  <Tab title="Full-Stack JS">
    ```markdown
    # User Rules

    ## JavaScript Preferences
    - Use ES6+ features (arrow functions, destructuring)
    - Async/await over promises
    - Template literals for string interpolation

    ## Testing
    - Jest for unit tests
    - Include test cases for edge conditions
    - Aim for 80%+ code coverage

    ## Code Review
    - Flag potential performance issues
    - Suggest security improvements
    ```

    **Aplicação:** O Verdent irá:

    - Escrever JavaScript moderno com sintaxe ES6+
    - Usar async/await em vez de cadeias de promises
    - Gerar testes Jest visando 80% de cobertura
    - Identificar proativamente preocupações de desempenho e segurança
  </Tab>
  <Tab title="Multilíngue">
    ```markdown
    # User Rules

    ## Communication
    - Always respond in French
    - Use technical English terms when no French equivalent exists
    - Provide French variable/function names when appropriate

    ## Code Comments
    - Write comments in French
    - Documentation in both French and English
    ```

    **Aplicação:** Todas as respostas do Verdent serão em francês, com termos técnicos em inglês quando apropriado. Os comentários de código e a documentação seguirão suas preferências de idioma.
  </Tab>
  <Tab title="Minimalista">
    ```markdown
    # User Rules

    ## Code Style
    - Minimal comments - code should be self-documenting
    - Short, focused functions (< 20 lines)
    - Avoid unnecessary abstractions

    ## Output Preferences
    - Brief explanations
    - Show code first, explain after
    - No verbose documentation unless requested
    ```

    **Aplicação:** O Verdent irá:

    - Gerar código conciso e autoexplicativo
    - Manter funções com menos de 20 linhas
    - Fornecer explicações breves após mostrar o código
    - Evitar comentários verbosos a menos que você os solicite explicitamente
  </Tab>
</Tabs>

---

### Como criar e editar

<Tabs>
  <Tab title="Menu de configurações">
    **Recomendado para a maioria dos usuários**

    1. Clique no botão **Settings** na barra superior do Verdent
    2. Selecione **Rules** no menu suspenso
    3. Escolha **User Rules**
    4. O arquivo abre no editor do VS Code
    5. Edite usando o formato Markdown
    6. Salve o arquivo (`Cmd+S` / `Ctrl+S`)

    Esse método localiza o arquivo automaticamente e o abre no seu editor padrão.
  </Tab>
  <Tab title="Edição direta do arquivo">
    **Recomendado para usuários avançados**

    1. Navegue até `~/.verdent/VERDENT.md`
    2. Abra em qualquer editor de texto
    3. Edite o conteúdo Markdown
    4. Salve as alterações

    Esse método é mais rápido se você prefere trabalhar diretamente com arquivos de configuração.
  </Tab>
</Tabs>

---

## Regras do projeto (AGENTS.md)

O AGENTS.md define regras específicas do projeto que controlam o comportamento do agente para o projeto atual. Ele estabelece padrões de codificação da equipe, padrões arquiteturais, requisitos de teste e fluxos de trabalho de desenvolvimento específicos do projeto.

### Localização e escopo

**Localização do arquivo:** Diretório raiz do projeto

**Escopo:** Apenas o projeto atual

**Controle de versão:** Pode ser commitado no git para compartilhamento com toda a equipe

**Acesso:**

- Settings → Rules → Project Rules
- Edição direta em `<project-root>/AGENTS.md`

---

### Casos de uso

<Tabs>
  <Tab title="Convenções da equipe">
    **Convenções da equipe**

    Padrões de codificação compartilhados que todos os membros da equipe seguem:

    - Indentação consistente em toda a equipe
    - Convenções de nomenclatura para componentes/funções
    - Padrões de organização de arquivos

    Imponha um estilo de codificação consistente em toda a equipe de desenvolvimento.
  </Tab>
  <Tab title="Arquitetura">
    **Padrões arquiteturais**

    Padrões de design específicos do projeto:

    - Estrutura MVC, microsserviços, monorepo
    - Abordagem de gerenciamento de estado (Redux, Context, Zustand)
    - Padrões de design de API (REST, GraphQL)

    Defina as decisões e padrões arquiteturais do projeto.
  </Tab>
  <Tab title="Testes">
    **Requisitos de teste**

    Cobertura de teste esperada e frameworks:

    - Limites mínimos de cobertura (80%, 90%)
    - Frameworks de teste (Jest, pytest, Vitest)
    - Convenções de nomenclatura de arquivos de teste

    Estabeleça padrões de teste e portões de qualidade para o projeto.
  </Tab>
  <Tab title="Fluxos de trabalho">
    **Fluxos de trabalho de desenvolvimento**

    Comandos de build, procedimentos de deploy, diretrizes de PR:

    - Como executar testes (`pnpm test`, `npm run test`)
    - Comandos de build para pacotes específicos
    - Requisitos de formato do título de PR

    Documente os fluxos de trabalho da equipe e os procedimentos de desenvolvimento.
  </Tab>
  <Tab title="Tecnologia">
    **Restrições de tecnologia**

    Bibliotecas aprovadas e versões de frameworks:

    - Dependências permitidas
    - Requisitos de versão de frameworks
    - Suporte de plataforma (iOS 14+, Android API 26+)

    Controle as escolhas de stack tecnológico e mantenha a consistência.
  </Tab>
</Tabs>

**Colaboração em equipe:** O AGENTS.md é armazenado na raiz do projeto e pode ser commitado no controle de versão, garantindo que todos os membros da equipe trabalhem com um comportamento de agente consistente.

<Tip>
  Compartilhe o AGENTS.md com sua equipe via controle de versão para garantir um comportamento de IA consistente entre todos os membros da equipe.
</Tip>

---

### Formato e sintaxe

O AGENTS.md usa o formato Markdown com seções estruturadas e marcadores, semelhante ao VERDENT.md, mas com foco em requisitos específicos do projeto.

**Estrutura:**

```markdown
# AGENTS.md

## Dev environment tips
- Command for navigating workspace
- Installation commands
- Environment setup instructions

## Testing instructions
- Test execution commands
- Coverage requirements
- CI/CD integration details

## PR instructions
- Title format requirements
- Pre-commit checklist
- Review guidelines
```

**Estilo de escrita:**

- Linguagem imperativa e diretiva
- Organizada por área de fluxo de trabalho (desenvolvimento, testes, deploy)
- Comandos e procedimentos específicos
- Padrões de toda a equipe, não preferências pessoais

---

### Exemplos por tipo de projeto

<Tabs>
  <Tab title="Monorepo">
    ```markdown
    # AGENTS.md

    ## Dev environment tips
    - Use `pnpm dlx turbo run where <project_name>` to jump to a package
    - Run `pnpm install --filter <project_name>` to add package to workspace
    - Check the name field in package.json to confirm the right name

    ## Testing instructions
    - Run `pnpm turbo run test --filter <project_name>` for all checks
    - From package root: `pnpm test`
    - Focus on one test: `pnpm vitest run -t "<test name>"`
    - Fix all errors before merge

    ## PR instructions
    - Title format: [<project_name>] <Title>
    - Always run `pnpm lint` and `pnpm test` before committing
    ```

    **Aplicação:** Ao trabalhar neste monorepo, o Verdent irá:

    - Usar comandos turbo para navegação e testes
    - Formatar títulos de PR com prefixo do nome do projeto
    - Executar comandos de lint e teste antes de sugerir commits
  </Tab>
  <Tab title="React/TypeScript">
    ```markdown
    # AGENTS.md

    ## Code Standards
    - Use functional components with hooks
    - TypeScript strict mode required
    - Named exports only (no default exports)
    - PropTypes or TypeScript interfaces for all components

    ## File Organization
    - One component per file
    - Components in `src/components/`
    - Hooks in `src/hooks/`
    - Utils in `src/utils/`

    ## Testing
    - Jest + React Testing Library
    - Test all user interactions
    - 80%+ coverage required
    ```

    **Aplicação:** Todos os componentes React que o Verdent criar irão:

    - Usar componentes funcionais com hooks
    - Incluir interfaces TypeScript
    - Ser colocados no diretório correto
    - Incluir testes Jest visando 80% de cobertura
  </Tab>
  <Tab title="Backend API">
    ```markdown
    # AGENTS.md

    ## API Standards
    - All endpoints include input validation
    - Use async/await for asynchronous operations
    - Consistent error format: { error: string, code: number }
    - Rate limiting on public endpoints

    ## Security
    - Never log sensitive data (passwords, tokens, PII)
    - Parameterized queries only (prevent SQL injection)
    - Validate and sanitize all inputs

    ## Testing
    - Unit tests for all business logic
    - Integration tests for API endpoints
    - Test success and error cases
    ```

    **Aplicação:** Ao criar endpoints de API, o Verdent irá:

    - Adicionar validação de entrada automaticamente
    - Usar consultas parametrizadas para operações de banco de dados
    - Gerar testes para casos de sucesso e de erro
    - Evitar registrar dados sensíveis nos logs
  </Tab>
  <Tab title="Aplicativo mobile">
    ```markdown
    # AGENTS.md

    ## Platform Support
    - iOS 14+ and Android API 26+
    - React Native 0.72+
    - Test on both platforms before PR

    ## State Management
    - Use Redux Toolkit
    - Async operations with Redux Thunk
    - Normalize state shape

    ## Performance
    - Images: WebP format, max 500KB
    - Bundle size: monitor with bundle analyzer
    - FlatList for long lists (>20 items)
    ```

    **Aplicação:** O código do aplicativo mobile irá:

    - Suportar versões mínimas de plataforma
    - Usar Redux Toolkit para o estado
    - Otimizar imagens para o formato WebP
    - Usar FlatList para desempenho em listas longas
  </Tab>
  <Tab title="Python Django">
    ```markdown
    # AGENTS.md

    ## Django Conventions
    - Follow Django best practices and PEP 8
    - Class-based views preferred
    - Django ORM for database operations
    - Migrations: never edit generated files

    ## Testing
    - pytest-django for all tests
    - Factory Boy for test fixtures
    - Coverage must be 90%+

    ## Deployment
    - Docker compose for local development
    - Environment variables in .env (never committed)
    - Run migrations before deployment
    ```

    **Aplicação:** O código Django irá:

    - Usar class-based views
    - Usar o Django ORM em vez de SQL puro
    - Gerar testes pytest com fixtures do Factory Boy
    - Visar 90%+ de cobertura de teste
  </Tab>
</Tabs>

---

### Diferenças em relação ao VERDENT.md

**Escopo:**

- **VERDENT.md:** Preferências pessoais em todos os projetos
- **AGENTS.md:** Padrões da equipe apenas para um projeto específico

**Prioridade:**

- **AGENTS.md:** Precedência mais alta - sobrescreve user_rules para consistência do projeto
- **VERDENT.md:** Precedência mais baixa - aplica-se quando nenhuma regra do projeto conflita

**Foco do conteúdo:**

- **VERDENT.md:** Estilo individual de codificação, preferências de comunicação, ferramentas pessoais
- **AGENTS.md:** Convenções da equipe, arquitetura do projeto, fluxos de trabalho compartilhados, stack tecnológico

**Controle de versão:**

- **VERDENT.md:** Não compartilhado - permanece na máquina do indivíduo
- **AGENTS.md:** Commitado no git - compartilhado com toda a equipe

**Armazenamento:**

- **VERDENT.md:** `~/.verdent/VERDENT.md` (global)
- **AGENTS.md:** Diretório raiz do projeto (específico do projeto)

**Exemplo de resolução de conflito:**

```
VERDENT.md: "I prefer 2-space indentation"
AGENTS.md: "This project uses 4-space indentation"
→ Result: 4-space indentation (team standard wins)
```

**Quando usar cada um:**

- **VERDENT.md:** Preferências pessoais que você quer em todos os projetos
- **AGENTS.md:** Padrões que toda a equipe deve seguir para este projeto

---

## Regras de plano (Plan.md)

O Plan.md personaliza o conteúdo e o formato dos planos gerados no Plan Mode. Ele controla o nível de detalhe do plano, as seções incluídas, as preferências de formatação e as informações exibidas.

### Localização e escopo

**Localização do arquivo:** ~/.verdent/plan_settings.json

**Escopo:** Global para todos os projetos

**Aplicação:** Aplicado apenas durante o Plan Mode ao gerar planos

**Acesso:**

- Settings → Rules → Plan Rules
- Edição direta do arquivo em ~/.verdent/plan_settings.json

---

### Casos de uso

<Tabs>
  <Tab title="Estrutura do plano">
    **Estrutura do plano**

    Defina as seções a incluir:

    - Resumo, pré-requisitos, etapas, verificação
    - Avaliação de riscos, procedimentos de rollback
    - Estimativas de tempo, caminho crítico

    Controle quais seções e informações aparecem em cada plano.
  </Tab>
  <Tab title="Nível de detalhe">
    **Nível de detalhe**

    Controle a granularidade:

    - Visão geral de alto nível (fases de 1-2 horas cada)
    - Etapas detalhadas de implementação (tarefas de 15-30 minutos)
    - Especificidades em nível de função (assinaturas, caminhos de arquivos)

    Ajuste o quão granulares e específicos os planos de implementação devem ser.
  </Tab>
  <Tab title="Formato">
    **Preferências de formato**

    Escolha o estilo de apresentação:

    - Listas numeradas vs marcadores
    - Trechos de código vs descrições
    - Diagramas (descritos verbalmente)

    Personalize como as informações do plano são formatadas e exibidas.
  </Tab>
  <Tab title="Informações">
    **Inclusão de informações**

    Especifique elementos adicionais:

    - Estimativas de tempo inline
    - Níveis de risco (baixo/médio/alto)
    - Atribuições de papéis para colaboração em equipe
    - Requisitos de teste enfatizados

    Adicione contexto e metadados para tornar os planos mais acionáveis.
  </Tab>
</Tabs>

---

### Formato e sintaxe

O Plan.md usa o formato Markdown com seções que descrevem a estrutura e o conteúdo desejados do plano.

**Estrutura:**

```markdown

---
name: Plan Rules
version: 1.0.0
last_updated: 2025-11-26
---

## Plan Structure
- Start with brief summary (2-3 sentences)
- Include estimated time for each major step
- List prerequisites before implementation steps
- Identify potential risks

## Level of Detail
- Break tasks into subtasks of 15-30 minutes
- Include specific file paths for modifications
- List functions/components to create/modify

## Format
- Use numbered lists for sequential steps
- Use bullet points for options
- Include code snippets for complex changes
```

---

### Exemplos por estilo de planejamento

<Tabs>
  <Tab title="Técnico detalhado">
    ```markdown
    ---
    name: Detailed Technical
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Executive summary (2-3 sentences)
    - Prerequisites and dependencies
    - Numbered implementation steps
    - Testing and verification strategy
    - Rollback procedures

    ## Level of Detail
    - Break into 20-30 minute tasks
    - Specific file paths for all modifications
    - Function signatures for new code
    - Database schema changes with migration steps

    ## Format
    - Numbered lists for sequence
    - Code blocks for complex logic
    - Diagrams for architecture changes (describe verbally)
    ```

    **Aplicação:** Os planos incluirão:

    - Resumo executivo no topo
    - Divisões de tarefas de 20-30 minutos
    - Caminhos de arquivos específicos como `src/components/Auth/Login.tsx`
    - Assinaturas de funções como `async function authenticateUser(credentials: UserCredentials): Promise<AuthResult>`
    - Procedimentos de teste e rollback
  </Tab>
  <Tab title="Estratégico de alto nível">
    ```markdown
    ---
    name: High-Level Strategic
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Brief overview (1 paragraph)
    - Major phases only (3-5 high-level steps)
    - Key decisions and trade-offs
    - Success criteria

    ## Level of Detail
    - High-level phases (1-2 hours each)
    - Avoid implementation specifics
    - Focus on approach and strategy

    ## Format
    - Bullet points for flexibility
    - Minimal code examples
    - Emphasize "why" over "how"
    ```

    **Aplicação:** Os planos serão de alto nível, com foco em:

    - Abordagem estratégica em 3-5 fases principais
    - Explicações do "porquê" em vez de detalhes de implementação
    - Pontos de decisão e trade-offs
    - Critérios de sucesso sem implementação específica
  </Tab>
  <Tab title="Consciente do tempo">
    ```markdown
    ---
    name: Time-Conscious
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Time estimates for each step
    - Total project duration estimate
    - Parallel tasks identified
    - Critical path highlighted

    ## Level of Detail
    - Tasks sized to 30-minute increments
    - Dependencies clearly marked
    - Blocking operations identified

    ## Format
    - Include time estimates inline
    - Mark parallel tasks
    - Highlight critical path with bold
    ```

    **Aplicação:** Os planos incluirão:

    - Cada etapa com estimativa de tempo: "Criar middleware de autenticação (45 minutos)"
    - Duração total: "Total estimado: 6 horas"
    - Tarefas paralelas marcadas: "Pode ser feito em paralelo com a etapa 3"
    - Caminho crítico em negrito para mostrar operações bloqueadoras
  </Tab>
  <Tab title="Focado em riscos">
    ```markdown
    ---
    name: Risk-Focused
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Risk assessment for each phase
    - Mitigation strategies included
    - Rollback procedures defined
    - Testing requirements emphasized

    ## Level of Detail
    - Identify potential failure points
    - Document error handling approach
    - Include recovery procedures

    ## Format
    - Risk levels: low, medium, high
    - Separate "Risks" section for each phase
    - Mitigation steps in sub-bullets
    ```

    **Aplicação:** Cada fase incluirá:

    - Avaliação de risco: "Risco: alto (migração de banco de dados em produção)"
    - Mitigação: "Execute a migração em staging primeiro, verifique com consultas de teste"
    - Rollback: "Reverta a migração com o down script se ocorrerem problemas"
  </Tab>
  <Tab title="Colaboração em equipe">
    ```markdown
    ---
    name: Team Collaboration
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Role assignments for each task
    - Coordination points identified
    - Review checkpoints included
    - Communication requirements

    ## Level of Detail
    - Specify who handles each component
    - List integration points between team members
    - Include pair programming opportunities

    ## Format
    - Use mentions for role assignments
    - Mark collaboration points
    - Include "Review required" markers
    ```

    **Aplicação:** Os planos especificarão:

    - "Backend API (Equipe de Backend): Criar endpoints de autenticação"
    - "Ponto de integração: A equipe de frontend aguarda a especificação da API do backend"
    - "Revisão necessária: Revisão da equipe de segurança antes do merge"
  </Tab>
</Tabs>

---

### Quando as regras de plano são aplicadas?

**Aplicação das regras de plano:**

- **Momento:** Aplicado apenas durante o Plan Mode ao gerar planos
- **Escopo:** Controla o formato e o conteúdo do plano, não a geração de código
- **Independência:** Não conflita com o VERDENT.md ou o AGENTS.md

**Aplicação dos outros tipos de regra:**

- **VERDENT.md:** Aplicado continuamente em todos os modos (Agent, Plan, Chat)
- **AGENTS.md:** Aplicado continuamente em todos os modos para comportamento específico do projeto

**Exemplo de interação:**

```
Plan Mode activated:
1. VERDENT.md: "Use TypeScript" → Applied to code in plan
2. AGENTS.md: "Follow project conventions" → Applied to approach
3. plan_rules.md: "Include time estimates" → Applied to plan format
→ Result: Plan shows TypeScript code following project conventions with time estimates
```

**Comportamento específico de cada modo:**

- **Agent Mode:** VERDENT.md + AGENTS.md aplicados (sem plan_rules.md)
- **Plan Mode:** VERDENT.md + AGENTS.md + Plan.md todos aplicados
- **Chat Mode:** VERDENT.md + AGENTS.md aplicados (sem Plan.md)

---

## Precedência de regras e resolução de conflitos

Quando as regras entram em conflito, o Verdent aplica a precedência para garantir um comportamento consistente.

### Ordem de precedência

**1. Regras do projeto (AGENTS.md) - Prioridade mais alta** As regras específicas do projeto sobrescrevem as preferências globais. Os padrões da equipe têm precedência sobre as preferências individuais para garantir consistência.

**2. Regras do usuário (VERDENT.md) - Prioridade média** As preferências globais se aplicam quando nenhuma regra específica do projeto conflita.

**3. Comportamento padrão - Prioridade mais baixa** Os padrões internos do Verdent se aplicam quando nenhuma regra é especificada.

**Exemplo de resolução de conflito:**

```
VERDENT.md: "Use 2-space indentation"
AGENTS.md: "Use 4-space indentation for this project"
→ Result: Verdent uses 4-space indentation (project rules win)
```

**Regras de plano:** O Plan.md se aplica de forma independente durante o Plan Mode e não conflita com as regras de usuário/projeto. Ele controla o formato do plano, enquanto o VERDENT.md e o AGENTS.md controlam o estilo de código dentro do plano.

<Note>
  As regras de plano afetam apenas o formato de saída do Plan Mode. Elas não mudam como o Verdent analisa ou implementa soluções.
</Note>

<Tip>
  Lembre-se da precedência: AGENTS.md (mais alta) → VERDENT.md (média) → padrões (mais baixa). As regras do projeto sempre vencem conflitos.
</Tip>

<Info>
  Algoritmos detalhados de resolução de conflitos, mecanismos para visualizar qual regra está sendo aplicada durante conflitos e mecanismos de override para suspensão temporária de regras estão atualmente em desenvolvimento.
</Info>

---

### Solução de problemas de conflitos de regras

Quando você observar um comportamento inesperado que contradiz uma regra, siga esta estratégia de depuração:

#### Etapa 1: Identifique o conflito

1. Observe o comportamento inesperado que contradiz uma regra
2. Verifique quais regras podem se aplicar à situação
3. Procure por contradições entre os arquivos de regras

#### Etapa 2: Verifique a precedência de regras

```
AGENTS.md (highest) → VERDENT.md (medium) → defaults (lowest)
```

As regras do projeto sobrescrevem as preferências pessoais.

#### Etapa 3: Teste isoladamente

**Desabilite o VERDENT.md:** Renomeie ou limpe temporariamente o arquivo, teste se o conflito é resolvido

**Teste sem o AGENTS.md:** Trabalhe no projeto sem o AGENTS.md para isolar o comportamento de user_rules

**Nova conversa:** Inicie uma sessão do zero para eliminar a influência do contexto da conversa

---

### Cenários comuns de conflito

#### Cenário 1: Conflito de formatação

```
VERDENT.md: "Use 2-space indentation"
AGENTS.md: "Use 4-space indentation"
→ Resolution: AGENTS.md wins (project standard)
→ Fix: Accept project standard or discuss with team
```

#### Cenário 2: Regras contraditórias no mesmo arquivo

```
AGENTS.md:
- "Prefer functional components"
- "Use class components for complex state"
→ Resolution: Verdent interprets based on context
→ Fix: Clarify when each rule applies
```

Exemplo de correção:

```markdown
- Prefer functional components for simple UI
- Use functional components with hooks for complex state
- Only use class components for legacy code maintenance
```

#### Cenário 3: Regra muito vaga

```
"Write good tests"
→ Problem: What is "good"?
→ Fix: "Generate unit tests with 80%+ coverage, include edge cases"
```

---

### Estratégia de depuração

**1. Teste explícito:** Pergunte ao Verdent "Qual regra você está seguindo para [comportamento específico]?"

Exemplo:

```
You: "Which rule are you following for indentation?"
Verdent: "I'm using 4-space indentation from AGENTS.md (line 12),
which overrides your VERDENT.md preference for 2-space indentation."
```

**2. Refinamento incremental:** Adicione especificidade a regras ambíguas

<Tip>
  Ao depurar conflitos de regras, desabilite as regras uma a uma temporariamente para isolar qual regra causa o comportamento inesperado.
</Tip>

Antes:

```markdown
- Use appropriate error handling
```

Depois:

```markdown
- Wrap async operations in try/catch blocks
- Return error objects with message and code fields
- Log errors with context (function name, input parameters)
```

**3. Marcadores de prioridade:** Use "CRITICAL:" ou "REQUIRED:" para regras não negociáveis

```markdown
## Security Rules
- **CRITICAL:** Never log passwords, API keys, or tokens
- **REQUIRED:** All user inputs must be validated and sanitized
- Preferred: Use parameterized queries for database operations
```

---

### Boas práticas para escrever regras

**Seja específico e diretivo:**

- Use linguagem clara e imperativa ("Sempre use...", "Nunca...", "Prefira...")
- Evite frases ambíguas ("Tente..." → "Sempre...")
- Diga exatamente o que você quer, não o que você não quer

**Bom:**

```markdown
- Use async/await for asynchronous operations
- Include JSDoc comments for all exported functions
```

**Evite:**

```markdown
- Try to use modern JavaScript features
- Add comments when necessary
```

**Organize logicamente:**

- Agrupe regras relacionadas sob cabeçalhos de seção
- Separe responsabilidades (estilo, testes, documentação, segurança)
- Use uma estrutura consistente entre os arquivos de regras

**Mantenha as regras gerenciáveis:**

- Escreva regras concisas (um conceito por marcador)
- Revise e atualize as regras conforme o projeto evolui
- Remova regras obsoletas prontamente

**Priorize regras importantes:**

- Coloque as regras críticas primeiro em cada seção
- Use ênfase para padrões não negociáveis ("**NUNCA** faça commit de credenciais")
- Concentre-se em regras que previnem bugs ou problemas de segurança

**Teste a eficácia das regras:**

- Verifique se o Verdent segue as regras na prática
- Inicie uma nova conversa para testar a aplicação das regras
- Refine as regras com base no comportamento real do agente

**Equilibre detalhe e flexibilidade:**

- Específico demais → Comportamento rígido que não se adapta
- Vago demais → Comportamento inconsistente
- Busque uma orientação clara com espaço para decisões adequadas ao contexto

**Considerações de equipe (AGENTS.md):**

- Envolva a equipe na criação de regras
- Documente a justificativa para regras não óbvias
- Mantenha as regras da equipe focadas em padrões compartilhados, não em preferências pessoais

---

## Veja também

<CardGroup cols={2}>
  <Card title="Gerenciamento de subagentes" icon="robot" href="/docs/verdent-for-vscode/agents-rules/subagent-management">
    Crie e gerencie subagentes especializados para tarefas específicas do projeto
  </Card>
  <Card title="Boas práticas: prompts" icon="message-lines" href="/docs/verdent-for-vscode/best-practices/prompts">
    Escrevendo prompts eficazes para aproveitar ao máximo o VerdentP
  </Card>
</CardGroup>