MEMORY-CONTRACT | Contrato Canônico do Vault

governanca contrato agente

Contrato que define o que pode ser lido e escrito neste vault, por quem, onde, e com qual disciplina. Aplica-se a todos os agentes (Axios, agentes Costal, agentes Colliers futuros) e à equipe humana. Em caso de conflito, este arquivo prevalece sobre documentações locais de cada agente.

1. Princípios

Vault é a memória canônica do projeto. Slack, e-mail, Teams e reuniões são interfaces efêmeras. Nada relevante existe até estar registrado aqui.
Nada relevante sem dono. Nada relevante sem registro. Todo item materialmente relevante tem owner humano identificado e rastro documental.
Separar explicitamente fato, hipótese, premissa e gap. Nunca inferir status sem marcá-lo.
Camadas canônicas não se duplicam. Cada fato vive em um único arquivo canônico. Agentes produzem derivados (snapshots, briefs, audits) que referenciam — não substituem — o canônico.
Mudança material → registro. Se uma reunião mudou decisão, risco, gap ou dependência, isso sobe à camada canônica no mesmo dia.

2. Camadas canônicas

#	Camada	Arquivo canônico	Papel
1	Visão e contexto	visao-geral	Por que o projeto existe
2	Glossário	glossario	Termos padronizados
3	Stakeholders (mapa)	stakeholders	Mapa executivo resumido
4	Stakeholders (relacional)	06-directory	Memória operacional de pessoas
5	Decisões	decisoes	Log datado de decisões tomadas
6	Riscos	riscos	Riscos ativos com mitigação
7	Gaps	gaps	Lacunas abertas com owner e prazo
8	Dependências	dependencias	Dependências entre frentes, sistemas e pessoas
9	Arquitetura técnica	03-arquitetura	Data lake, conectores, governança técnica
10	Arquitetura empresarial	05-arquitetura-empresarial	Modelo global de dados, 12 domínios
11	Plano Costal	costal-plano	Plano estratégico e roadmap
12	Agentes Costal	costal-agentes	26 agentes operacionais
13	Agentes Colliers	colliers-agentes	Agentes da frente Colliers
14	Agentes core	agentes-core	Axios e futuros agentes estratégicos

Derivados (snapshots, não canônicos):

agentes-core/axios/outputs/* — estado operacional vivo do Axios
_briefs/* — resumos executivos derivados
_summaries/* — summaries de reuniões

Camadas operacionais vivas (derivadas, com cadência fixa de atualização):

Camada	Arquivo	Atualização	Diferença vs. canônica
Tarefas pendentes	TASKS	Após cada reunião + sextas	Visão consolidada de gaps + dependências + action items das atas. Não é canônica: status materiais sobem para gaps / dependencias
Calendário e atas	MEETINGS	Ao agendar / ao publicar ata	Índice de reuniões; cada ata mora em `XX-empresa/meetings/`
Definições operacionais	DEFINICOES	Após cada reunião	Definições táticas (rituais, papéis, ferramentas) — diferentes de decisões estratégicas em decisoes

3. Matriz de permissões por agente

3.1 Axios (agente core de governança)

Ação	Permissão	Escopo
Ler	✅ total	vault inteiro
Escrever em outputs	✅ total	`agentes-core/axios/outputs/*`
Escrever em camadas canônicas	⚠️ condicional	apenas com autorização explícita de Pedro por item
Criar arquivos de meeting	✅ com template	`XX-empresa/meetings/` usando `_templates/meeting.md`
Renomear / mover arquivos	❌ proibido	requer autorização de Pedro
Apagar arquivos	❌ proibido	requer autorização explícita de Pedro
Falar com stakeholders externos	❌ proibido	Pedro é o único porta-voz

3.2 Agentes operacionais Costal (26 agentes)

Ação	Permissão	Escopo
Ler	✅ restrito	sua própria pasta + `02-costal.md` (folder note) + `05-arquitetura-empresarial/` + `03-arquitetura/` + `_templates/`
Escrever	✅ restrito	apenas em sua própria pasta `02-costal/agentes/<area>/<codinome>/`
Consumir dados de outras pastas	✅ via referência	leitura ok, não deve copiar conteúdo integral para sua pasta
Acessar 06-directory	✅ leitura	necessário para entender owners
Escrever em camadas canônicas	❌ proibido	propõe alteração via Axios
Interagir com Pedro	✅ por canal definido	conforme operating-model de cada agente

3.3 Agentes Colliers (em construção)

Mesmas regras que 3.2, adaptadas para 01-colliers/agentes/<codinome>/.

3.4 Humanos da equipe Anouk

Ação	Permissão
Leitura total	✅
Escrita em qualquer pasta	✅
Escrita em camadas canônicas	✅ com disciplina de commit (data, owner, contexto)
Remoção / renomeação	✅ com cuidado de links

Pedro é owner final de todo o vault.

4. Regras de escrita

4.1 Nomenclatura

Documentos datados (atas, eventos): YYYY-MM-DD_descricao-curta.md
Documentos perenes (camadas canônicas, missões, governança): nome-descritivo.md (sem data)
Folder notes (índices de pasta): <nome-da-pasta>.md, ao lado da pasta — não dentro (padrão adotado na Onda 3, 2026-04-22)
Sempre minúsculas, hífens, sem acentos, sem espaços
Templates: _template.md ou _templates/*.md
Exceção documentada: PDFs originais em 04-referencia/pdfs/ podem manter nome de origem (mas devem ter um .md extraído com nome normalizado)

Para exemplos práticos (perenes vs datados, frontmatter por tipo, antipadrões), ver STYLE-GUIDE.

4.2 Marcação explícita de estado epistêmico

Todo item relevante deve ser marcado como:

[fato] — verificado, com fonte
[hipótese] — plausível, precisa ser validado
[premissa] — aceito como verdade operacional até prova em contrário
[gap] — informação faltando, precisa de owner e prazo

Exemplo:

- [fato] Kickoff ocorreu em 17/04/2026. Fonte: [[meetings/2026-04-17_kickoff-operacional_meeting_minutes]].
- [hipótese] Orçamentação tem ganho esperado de 87%. Fonte: proposta inicial — precisa validação com base real.
- [premissa] Sienge é o ERP transacional definitivo da Costal até 2027.
- [gap] Blueprint da camada de ingestão — owner Gabriel, prazo curto.

4.3 Links internos

Use [[caminho/relativo/arquivo]] ou [[nome-arquivo]] (Obsidian resolve)
Todo arquivo citado em outro deve existir ou ser marcado como [[futuro: nome-arquivo]]
Evite links externos (http://, file://) exceto para recursos públicos documentados

4.4 Tags padrão

Use tags para filtragem — ver README para lista completa. Mínimo por documento:

Tag de frente: #colliers ou #costal (ou ambas)
Tag de tipo: #meeting, #spec, #agente, #decisao, #risco, #gap, etc.

5. Promoção de sinais (meetings → camadas canônicas)

Após toda reunião, o responsável pela ata deve, no mesmo dia:

Publicar minutes em XX-empresa/meetings/YYYY-MM-DD_topico_meeting_minutes.md
Extrair e promover:
- Decisões → decisoes
- Riscos novos ou modificados → riscos
- Gaps abertos ou fechados → gaps
- Dependências novas ou resolvidas → dependencias
Atualizar owners em … se relevante
Notificar Axios para refresh dos outputs vivos

A minute não substitui a camada canônica. A minute é o registro bruto; a camada canônica é o estado do projeto.

6. Dados sensíveis e segurança

Não incluir no vault: senhas, tokens, credenciais, PII sensível de terceiros (CPF, RG, dados bancários completos).
Informações de remuneração e negociação comercial: apenas resumos estratégicos, nunca valores específicos sem autorização.
Documentos contratuais em discussão ficam em 04-referencia/pdfs/ com access control do Drive — não replicar conteúdo em md.
Se um agente receber dados sensíveis em input, deve marcar o documento com #sensivel e restringir escopo. Ver security-guardrails.
Publicação em wikis externas: controlada por publish-contract. Denylist absoluta bloqueia memory/, scripts/, #sensivel em qualquer wiki, independente de frontmatter. Publicação a cliente/board requer publish: explícito — default é interno.

7. Manutenção deste contrato

Owner: Pedro Villa
Revisão: mensal ou quando houver mudança material no modelo operacional
Alterações: via commit direto com entrada em decisoes referenciando este arquivo

8. Referências

README — visão do projeto
HOME — dashboard operacional
system-prompt — prompt principal do Axios
security-guardrails — guardrails do Axios
operating-model — modelo operacional do Axios
regras-de-comunicacao — comunicação por perfil

Colliers × Costal — Interno

Explorador

MEMORY-CONTRACT — Contrato Canônico do Vault