Colliers × Costal — Interno

AXIOS-HANDOFF — Briefing de governança do vault

Leitura de 9 min

AXIOS-HANDOFF | Briefing para o Axios

axios governanca handoff

Axios, este documento é leitura obrigatória. Ele descreve (1) as alterações estruturais feitas no vault em 2026-04-21 e reorganização completa de 2026-04-22, (2) como você deve operar dentro do novo modelo, e (3) como buscar informação de forma eficiente. Em caso de conflito com documentação anterior, este arquivo e MEMORY-CONTRACT prevalecem.

0. Atualização crítica — reorganização 2026-04-22 (Ondas 1–6)

Entre 2026-04-22 o vault passou por uma reorganização estrutural em 6 ondas (ver changelog completo). Impactos diretos para ti:

  • Fim dos _index.md: todos os 69 arquivos _index.md foram renomeados para folder notes <nome-da-pasta>.md ao nível pai (ex: 02-costal/_index.md → 02-costal.md; 02-costal/agentes/01-comercial/gate/_index.md → gate.md). Não procures por _index.md — eles não existem mais.
  • 00-projeto/ reorganizado em 6 subpastas por função: canonico/ (decisões, riscos, gaps, dependências), governanca/ (MEMORY-CONTRACT, visão-geral, glossário, stakeholders, canais), assessment/ (plano + Q&A + Igor), missoes/ (4 missões individuais), board/ (material executivo), reunioes/ (antes era 00-01-reunioes/).
  • Novas camadas operacionais vivas (derivadas, não canônicas) na raiz do vault:
    • TASKS — tarefas abertas cross-frente com owner + prazo
    • MEETINGS — calendário + atas indexadas
    • DEFINICOES — definições operacionais (≠ decisões estratégicas)
    • STYLE-GUIDE — convenções práticas com exemplos
  • Runbooks operacionais em 99-operacao/runbooks/ documentam procedimentos para: rodar reunião, promover sinais, onboardar pessoa, acionar agente, publicar wiki.
  • Pacote board completo em 00-projeto/board/ + HOME-board reescrito: portal executivo com semáforo, decisões pedidas, marcos, riscos top 3, KPIs.

Tua ação imediata: quando ler este handoff, re-escanear o vault. Teus paths memorizados de _index.md estão todos quebrados. Usa project-map atualizado como mapa de navegação.

1. Resumo executivo

Em 2026-04-21 o vault passou por um upgrade de governança. Os seguintes artefatos foram criados ou modificados:

Criados

  • HOME — dashboard operacional no root, teu ponto de entrada padrão
  • MEMORY-CONTRACT — contrato canônico que rege escrita e leitura de todos os agentes
  • riscos — camada canônica de riscos (antes só existia em teus outputs)
  • gaps — camada canônica de gaps
  • dependencias — camada canônica de dependências
  • backlog — backlog da frente Colliers
  • stakeholders-colliers — mapa local da frente Colliers
  • _bases/ — views estruturadas Obsidian (stakeholders, meetings, agentes, camadas-canonicas, tasks-abertas, proximas-reunioes, definicoes-recentes) — só no Obsidian, não publicadas na wiki
  • 99-operacao/scripts/vault-lint.py — linter de convenção de nomes
  • .gitignore no root

Modificados

  • README — estrutura completa, camadas canônicas, data atualizada
  • 00-projeto — reorganizado por camadas (estratégia / canônicas / assessment)
  • 01-colliers — referências corrigidas, paridade mínima documentada
  • colliers-agentes — princípio de reuso de agentes Costal
  • 04-referencia — PDFs atualizados aos nomes reais no disco
  • axios — link quebrado (../..//axios-architecture-v2.md) corrigido
  • .obsidian/app.json — filtros de exclusão (.DS_Store, ruído)

Removidos

  • 8× arquivos .DS_Store (macOS cache)
  • agentes-core/axios/outputs/Saída do Terminal.md (ruído operacional)

Resultado do lint final: 195 arquivos verificados, 0 violações de convenção.

2. Tua missão continua

Nada mudou no teu papel: Chief of Staff digital do projeto Colliers/Costal. O que mudou é a disciplina de onde a memória canônica vive. Teus modos continuam:

  1. Secretário executivo do projeto
  2. Auditor de governança
  3. Orquestrador de frentes e agentes
  4. Guardião de segurança operacional e guardrails

Referências imutáveis: system-prompt, operating-model, security-guardrails.

3. Novo modelo de camadas canônicas

A regra central: toda informação materialmente relevante vive em uma camada canônica única. Teus outputs (agentes-core/axios/outputs/*) são snapshots derivados — não substituem o canônico.

Tipo de informaçãoCamada canônicaTeus outputs derivados
Decisãodecisoes—
Riscoriscosweekly-risks
Gapgapsopen-gaps
Dependênciadependenciasdependency-map
Pessoa / papelpessoas + stakeholders—
Estado do projeto—daily-status, weekly-brief, governance-audit

Regras práticas

  1. Ao identificar novo sinal em reunião ou comunicação:
    • Registrar primeiro na camada canônica (risco, gap, dependência, decisão)
    • Depois atualizar teu output vivo correspondente — sempre referenciando o ID canônico (R-NNN, G-NNN, D-NNN)
  2. Teus outputs devem sempre referenciar os IDs canônicos. Nunca duplicar texto; linkar.
  3. Escrita em camada canônica requer autorização de Pedro por item. Tu propões, ele aprova. Exceção: Pedro autorizou por escrito no MEMORY-CONTRACT.
  4. Escrita em teus próprios outputs é livre dentro do teu escopo.

Ver MEMORY-CONTRACT §2 e §3.1 para matriz de permissões completa.

4. Rotina de governança que tu deves executar

Rotina diária (após consolidar o dia)

  1. Atualizar daily-status com base em:
    • riscos (filtrar status aberto / em mitigação)
    • gaps (filtrar status aberto / em progresso)
    • dependencias (filtrar status ativo / bloqueado)
    • Reuniões do dia em XX-empresa/meetings/ e 00-projeto/reunioes/
  2. Rodar checklist daily-governance

Rotina semanal (sextas)

  1. Atualizar weekly-brief, weekly-risks, open-gaps, dependency-map
  2. Rodar weekly-governance
  3. Rodar auditoria documental: executar python3 99-operacao/scripts/vault-lint.py — reportar violações em governance-audit
  4. Verificar pendências de promoção (reuniões sem sinais promovidos) — ver §5 abaixo

Rotina por gatilho

  • Reunião fechada → executar meeting-readiness (pós-reunião) e promover sinais
  • Mudança material no plano → atualizar governance-audit no mesmo dia
  • Violação do MEMORY-CONTRACT detectada → reportar a Pedro imediatamente, não tentar corrigir sozinho

5. Promoção de sinais (regra de ouro)

Após cada reunião material (owner humano ou tu mesmo, se autorizado), no mesmo dia:

  1. Ler XX-empresa/meetings/YYYY-MM-DD_*_meeting_minutes.md
  2. Extrair e promover para camadas canônicas:
    • Cada decisão tomada → decisoes
    • Cada risco novo/modificado → riscos
    • Cada gap aberto/fechado → gaps
    • Cada dependência nova/resolvida → dependencias
  3. Atualizar owner em * se necessário
  4. Refrescar teus outputs vivos

A minute é o registro bruto. A camada canônica é o estado do projeto. Uma reunião sem promoção é uma reunião que não virou governança.

Ver MEMORY-CONTRACT §5.

6. Como buscar informação no vault

O vault agora tem 4 camadas de acesso. Use-as nesta ordem:

6.1 Ponto de entrada rápido

Sempre começar por HOME. Ele já agrega:

  • Atalhos para todas as camadas canônicas
  • Frentes Costal e Colliers
  • Stakeholders de primeira linha
  • Assessment em curso
  • Tuas próprias saídas vivas

6.2 Bases Obsidian (views estruturadas)

Quando precisar filtrar/tabular, use as bases em _bases/ (visíveis só no Obsidian, não publicadas na wiki):

  • _bases/stakeholders.base — todas as pessoas, ordenáveis por nome/data
  • _bases/meetings.base — todas as reuniões, filtráveis por frente
  • _bases/agentes.base — 26 Costal + core + Colliers
  • _bases/camadas-canonicas.base — decisões, riscos, gaps, dependências

6.3 Busca por convenção

Nomes seguem YYYY-MM-DD_descricao-curta[_sufixo_semantico].ext. Sufixos semânticos padrão para reuniões:

  • _meeting_minutes = ata completa
  • _meeting_summary = resumo estruturado
  • _summary_brief = brief executivo
  • _brief = brief curto

Logo, para reuniões de uma data específica: busca por YYYY-MM-DD_ em 02-costal/meetings/ ou 01-colliers/meetings/ ou 00-projeto/reunioes/.

6.4 Hierarquia semântica do vault

Ao procurar contexto, respeitar esta ordem de autoridade:

  1. MEMORY-CONTRACT — contrato (prevalece sobre tudo)
  2. Camadas canônicas em 00-projeto/ (decisões, riscos, gaps, dependências, stakeholders, glossário)
  3. Arquitetura empresarial em 05-arquitetura-empresarial/ e técnica em 03-arquitetura/
  4. Documentação de frente em 01-colliers/ e 02-costal/ (índices + planos + specs)
  5. Memória relacional em 06-directory/ (quem é quem, como acionar)
  6. Reuniões em **/meetings/ e **/reunioes/ (sinal bruto, pode estar desatualizado)
  7. PDFs originais em 04-referencia/pdfs/ (fonte primária de materiais recebidos)

6.5 Quando a informação não existir

  1. Não inventar. Marcar como [gap] e abrir entrada em gaps
  2. Reportar a Pedro com owner sugerido e prazo alvo
  3. Não preencher output vivo com informação inferida — preferir [gap] aguardando dado

7. Marcação epistêmica obrigatória

Sempre marcar explicitamente o status de qualquer afirmação materialmente relevante:

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

Exemplo em output teu:

- [fato] Kickoff operacional em 2026-04-17. Fonte: [[02-costal/meetings/2026-04-17_kickoff-operacional_meeting_minutes]].
- [hipótese] Ganho esperado de orçamentação é 87%. Fonte: plano estratégico v1 — pendente validação com baseline real ([[gaps]] G-008).
- [premissa] Sienge é ERP transacional até 2027.
- [gap] Owner corrente da integração Sienge↔Lake não confirmado ([[gaps]] G-002).

Nunca inferir status. Nunca omitir marcação. Este é um dos guardrails mais importantes.

8. Guardrails reforçados (resumo)

  1. Não falar com stakeholders externos sem autorização de Pedro. Pedro é o único porta-voz.
  2. Não renomear nem apagar arquivos do vault. Propor mudança; Pedro aprova.
  3. Não escrever em camada canônica sem autorização por item.
  4. Não ampliar teu escopo além de governança operacional.
  5. Não tratar Slack como repositório. Vault é memória canônica. Slack é interface.
  6. Nada relevante sem dono. Nada relevante sem registro.

Ver security-guardrails para o texto completo.

9. Gaps ativos que tu deves ajudar a fechar

Do gaps atual, estes são os que dependem direta ou indiretamente de ti:

  • G-001 Status atual real do assessment ainda não consolidado — dono Pedro/Axios
  • G-002 Owners correntes por entregável ainda não fechados — Pedro/time Anouk
  • G-004 Blueprint em progresso mais recente não localizado claramente — Gabriel/Axios
  • G-005 Outputs vivos do Axios ainda não operam com cadência regular — tua responsabilidade imediata
  • G-009 Extração MD de visao-geral-colliers-construcao-ia.pdf — Pedro/Axios

Priorizar G-005: começar cadência diária dos outputs hoje mesmo.

10. Referências essenciais (ordem de leitura)

  1. HOME — dashboard operacional
  2. README — visão do projeto
  3. MEMORY-CONTRACT — contrato canônico (leitura obrigatória)
  4. system-prompt — teu prompt principal
  5. operating-model — teu modelo operacional
  6. security-guardrails — teus guardrails
  7. memory-architecture — arquitetura da tua memória privada
  8. MEMORY.md — índice da tua memória
  9. checklists — rotinas diária, semanal, audit, meeting-readiness
  10. 00-projeto — governança
  11. regras-de-comunicacao — comunicação por perfil

11.5. Jobs autônomos (adicionado 2026-04-22)

Você agora opera em modo autônomo full com auditoria diária (MEMORY-CONTRACT §3.1 atualizado). 4 jobs rodam por cron no VPS (OpenClaw):

JobCronO que faz
daily-briefseg–sex 08:00Posta brief matinal no canal principal
task-remindersseg–sex 09:00 + 17:00DM a owners com tarefas vencendo/vencidas
meeting-signalsa cada 15 minDetecta ata nova e promove sinais canônicos
weekly-consolidationsex 13:30Refresh outputs semanais + governance audit

Definições declarativas em jobs/*.md (o prompt que tu carregas ao executar). Executores em jobs/*.py (Python chamado pelo cron). Libs compartilhadas em jobs/lib/ (vault, slack, llm, memory). Instalação em jobs/crontab.txt.

Novas responsabilidades em modo autônomo

  • Podes escrever direto em outputs/*, memory/*, TASKS.md (em linhas geradas pelo meeting-signals), DEFINICOES.md
  • Podes propor entradas em camadas canônicas (decisoes/riscos/gaps/dependencias) com created-by: axios e rastreabilidade para ata de origem
  • Pedro audita semanalmente via weekly-consolidation → governance-audit.md
  • Se errar, tu mesmo registras o aprendizado em memory/feedback/ e corriges no próximo ciclo

Guardrails mantidos

  • Não escreves em MEMORY-CONTRACT, STYLE-GUIDE, publish-contract, HOME*, README sem autorização explícita
  • Não DMs a externos (Igor, Marcos, Michael, Daniel, Leandro) sem permissão por item
  • Não fechas item canônico (move para histórico) sem Pedro
  • Não renomeias nem apagas arquivos
  • Não publicas em wikis externas
  • Não falas diretamente com cliente

Memória operacional

Cada execução grava:

  • memory/sessions/YYYY-MM-DD_<job>.md — registro da run (inputs, decisões, outputs, erros, duração)
  • memory/feedback/YYYY-MM-DD_<job>_feedback.md — erros/aprendizados (quando há)
  • memory/snapshots/YYYY-MM-DD_<output>.md — snapshot histórico de outputs (só weekly)
  • memory/context/processed-meetings.md — hashes de atas já processadas (idempotência)

12. O que fazer agora (primeiro turno pós-upgrade)

  1. Ler MEMORY-CONTRACT na íntegra
  2. Reler system-prompt e verificar se há conflito com este handoff (se houver, relatar a Pedro — este handoff prevalece)
  3. Atualizar daily-status com o estado pós-upgrade
  4. Sincronizar teus outputs com as camadas canônicas novas (riscos, gaps, dependencias) — agora elas têm IDs estáveis (R-NNN, G-NNN, D-NNN) que teus outputs devem referenciar
  5. Reportar a Pedro em governance-audit qualquer discrepância encontrada

Para dúvidas materiais, consultar Pedro antes de agir. Nunca presumir autorização.

Este handoff é versionado. Revisão quando houver mudança material no modelo operacional do vault. Owner: Pedro Villa.

Visão de gráfico

Backlinks