---
type: rule
name: proibido-commit-ia
description: A IA nunca mexe no git da aplicação principal; commit e push são permitidos e obrigatórios exclusivamente no repositório da Wiki (../wiki)
scope: global
trigger: always_on
updatedAt: "2026-09-05"
---

# Regra: Proibido Commit pela IA na Aplicação e Exceção Obrigatória da Wiki

## Contexto

O controle de versão do código-fonte da aplicação principal é de responsabilidade exclusiva do usuário humano. A IA pode preparar alterações, criar arquivos, editar código e até sugerir mensagens de commit — mas NUNCA deve executar comandos que alterem o histórico do repositório da aplicação.

Por outro lado, o repositório central de documentação (`<base_projeto>/../wiki`), que hospeda a Wiki do Usuário (Pilar 3) e a Wiki de Desenvolvimento (Pilar 4), é uma base viva de documentação. Quando atualizado pelo agente (ex.: via `/doc`, `/documentacao` ou workflows DDD), o commit e o push DEVEM ser executados automaticamente pelo agente, restritos exclusivamente a esse repositório.

## Regra

### 1. Na Aplicação Principal (`<base_projeto>`) — RIGOROSAMENTE PROIBIDO MEXER NO GIT

A IA **NUNCA** deve executar comandos que alterem o histórico do repositório da aplicação (nem variações deles):

- `git commit` ❌
- `git push` ❌
- `git merge` ❌
- `git rebase` ❌
- `git tag` ❌
- `git reset` ❌
- `git revert` ❌
- `git cherry-pick` ❌
- `git stash drop` ❌
- `git branch -d` / `git branch -D` ❌

**Comandos permitidos na aplicação (somente leitura e staging):**

- `git status` ✅
- `git diff` ✅
- `git log` ✅
- `git add` ✅ (preparar alterações para o usuário revisar)
- `git stash` / `git stash pop` ✅ (preservar trabalho temporário)
- `git branch` (listar) ✅
- `git ls-files` ✅
- `git show` ✅

### 2. No Repositório da Wiki (`<base_projeto>/../wiki`) — COMMIT E PUSH OBRIGATÓRIOS

Sempre que a documentação em `<base_projeto>/../wiki` for criada ou modificada (manuais de usuário em `<modulo-id>/`, regras de negócio em `dev/<modulo-id>/`, ADRs em `dev/<modulo-id>/adrs/`, etc.), o agente **DEVE obrigatoriamente** realizar o commit e push das alterações:

```bash
# Executar estritamente apontando para a pasta ../wiki
git -C <base_projeto>/../wiki add -A
git -C <base_projeto>/../wiki commit -m "docs(<modulo-id>): <descrição sucinta das alterações>"
git -C <base_projeto>/../wiki push
```

**Fronteira Inegociável:** Esta permissão é restrita e isolada ao repositório `<base_projeto>/../wiki`. A IA **nunca** deve executar commit ou push na aplicação principal.

## Exemplos

### ❌ Errado — commitar automaticamente na aplicação
```sh
# Na raiz da aplicação (<base_projeto>): PROIBIDO
git add -A && git commit -m "fix: corrigir bug"
git push origin main
```

### ✅ Correto — na aplicação principal, apenas preparar e sugerir
```sh
git add -A
git status
# Informar ao usuário: "Alterações staged na aplicação. Revise e faça o commit quando estiver pronto."
# Sugestão de commit: git commit -m "feat: adicionar validação de schema"
```

### ✅ Correto — na Wiki, commitar e enviar automaticamente
```sh
# No repositório de documentação (<base_projeto>/../wiki): OBRIGATÓRIO
git -C ../wiki add -A
git -C ../wiki commit -m "docs(e-licencie): atualizar regras de negócio e manuais"
git -C ../wiki push
```

## Impacto

- **Segurança na aplicação:** O desenvolvedor mantém controle total sobre o histórico de código da aplicação.
- **Agilidade e perenidade na wiki:** A documentação fica sempre sincronizada e publicada imediatamente sem fricção manual.
- **Isolamento de escopo:** Fronteira clara e explícita entre repositório de aplicação e repositório de documentação.

## Referências

- Rule: `rules/ddd-documentacao-primeiro.md`
- Skill: `skills/documentacao/SKILL.md`
- Workflow: `global/workflows/documentacao.md`