Colliers × Costal — Interno

decisoes

Leitura de 21 min

Log de Decisoes

decisao colliers costal

Registro centralizado de decisoes do projeto. Adicionar novas entradas no topo. Decisões pendentes (estruturais ainda não fechadas) ficam na seção logo abaixo, antes do log histórico.

🔓 Decisões pendentes (estruturais)

Decisões que ainda não foram tomadas mas já estão registradas porque seu peso afeta arquitetura, dados ou backlog. Cada uma tem owner, prazo e impacto declarado. Quando tomada, a entrada se move para o log abaixo na seção da data.

DP-5 — Escopo de monitoramento de plataformas de procurement (Costal Sourcing)

  • Aberta em: 2026-05-06 (após revisão Igor 05/05)
  • Owner da decisão: Pedro Villa + Igor Reginato + Taiany Campioni
  • Prazo alvo: sprint-semana-4 (≤ 2026-05-22)
  • Task: T-139
  • Peso: estratégico — define um eixo da camada de Sourcing (eventual agente Hunter)

Pergunta a decidir: quais plataformas de procurement são prioritárias para Costal? Modelo é monitorar oportunidades / capturar alertas / operar resposta dentro? Há viabilidade técnica/comercial/jurídica para integração ou modelo inicial será apenas acompanhamento assistido?

Plataformas a avaliar (Igor 05/05):

PlataformaOrigemNotas
AribaSAPLíder global
Coupa, Jaggaer, Zycusglobal
Mercado Eletrônico, LinkanaBrasil
Oracle Procurement, Ivalua, GEP Smart, HICXglobal
NimbiBrasilIgor: “muito utilizado por empresas no Brasil — concorrente do Ariba”

Riscos de não decidir: sourcing reativo (espera oportunidade chegar) vs ativo (monitora canais). Dor central do sourcing identificada por Igor: “perdermos algo por desconhecimento de que aquela oportunidade está viável; chegamos tarde demais ou nem chegamos.”

Documentos afetados: rfp-contratos-discovery-prep §1, eventual nova spec de Hunter (agente de sourcing).

DP-4 — Cadência operacional Orçamentos × Suprimentos × Obras (Costal)

  • Aberta em: 2026-05-04 (após revisão estrutural Igor 03/05)
  • Owner da decisão: Igor Reginato + Pedro Villa
  • Prazo alvo: sprint-semana-4 (≤ 2026-05-22)
  • Task: T-123
  • Peso: estrutural — pré-requisito organizacional do Atlas; sem essa cadência, modelo paramétrico vira referência de mercado externa, não inteligência operacional Costal.

Pergunta a decidir: qual a cadência formal de troca entre as três áreas e qual o mecanismo de padronização do aprendizado (forma dinâmica, consistente, registrada — G-046)?

Inputs Igor 03/05:

  • Parceria constante; mínimo conversa semanal ou mensal nas reuniões de liderança
  • Suprimentos → Orçamentos: valores fechados · taxa de saving · lista de fornecedores · avaliação de fornecedores (qualidade × preço × prazo)
  • Obras → Orçamentos: avaliação de fornecedores · índices de produtividade · perdas · consumo
  • Mecanismo de garantia da padronização: a estruturar

Por que importa: orçamento estima → suprimentos confirma custo real → obras confirma produtividade real → lake consolida → Atlas recalibra próximo orçamento. Sem esse loop, Atlas só estima — não aprende.

Documentos afetados: orcamentacao-spec §10.5, atlas (capacidades), gaps G-046, dependências D-031, D-032.

DP-3 — Modelo-alvo de Change Orders (Costal)

  • Aberta em: 2026-05-04 (após revisão estrutural Igor 03/05)
  • Owner da decisão: Igor Reginato + Pedro Villa
  • Prazo alvo: sprint-semana-4 (≤ 2026-05-22)
  • Task: T-122
  • Peso: estrutural — desloca o ownership de Change Orders para fora do escopo nominal de Orçamentação/Atlas.

Pergunta a decidir:

Como ficará o modelo-alvo de Change Orders Costal — quem é dono primário, qual a estrutura de alçadas, qual o limite de autonomia do time de campo, quem documenta formalmente ao cliente?

Posição declarada por Igor (03/05):

“Change Orders não devem ficar primariamente em Orçamentos. A tendência mais coerente é ficarem sob gestão do gestor do contrato / operação em campo, com apoio de orçamentos, controles e agentes de validação.”

Pontos resolvidos:

  • ✅ Captura: gerente do contrato (cliente solicita OU incompatibilidade/gap de projeto)
  • ✅ Análise de impacto (escopo/custo/prazo/contratual): gerente do contrato + engenheiro de planejamento/custos. Envolve Head Construção + Head Orçamentos quando necessário. Account manager sempre avisado
  • ✅ Quando Orçamentos retoma como dono: demanda do gerente do contrato (volume, complexidade, falta de domínio) OU valor individual da CO muito grande → reanálise integral

Pontos abertos:

  • ❓ Aprovação interna: estrutura de alçadas (a definir a partir de gerente do contrato)
  • ❓ Documento formal ao cliente: account manager OU gerente do contrato (G-045)
  • ❓ Limite de autonomia do time de campo (G-044)

Por que importa:

  • Trade-off explícito (Igor): ganho de agilidade × risco de despadronização e passivo invisível
  • Análise mínima obrigatória cobre 9 dimensões — alteração de escopo, preço, prazo, suprimentos, contratual, medições/faturamento, garantias/seguros/responsabilidades, passivo oculto, desgaste com cliente/litígio
  • “Change Order é oportunidade de upsell, mas também ponto clássico de geração de passivo invisível”

Implicação arquitetural: Atlas não absorve CO como dono primário. CO comporta um fluxo/agente próprio (a estruturar pós-DP-3). Atlas pode ser acionado para reanálise quando CO cruza thresholds.

Documentos afetados: orcamentacao-spec §14, atlas (capacidades fora do escopo), G-044, G-045.

DP-2 — Tratamento do drive-sync (governança)

  • Aberta em: 2026-05-03 (após audit do Axios em 30/04)
  • Owner da decisão: Pedro Villa
  • Prazo alvo: 2026-05-09
  • Task: T-117
  • Peso: governança operacional — afeta confiabilidade do daily-brief do Axios e fonte de verdade do vault publicado

Pergunta a decidir: o que fazer com o projects/colliers-costal/drive-sync (cópia do vault no Drive do Pedro, parada em ~22/04)?

Opções: A (substituir) · B (desligar) · C (sync bidirecional) · D (A+B combinados — recomendado).

Por que importa: sem decisão, o Axios continua reportando “duplicate IDs / HOME stale / wikilinks quebrados” no daily-brief — falsos-positivos que poluem o sinal e desconectam dos dados reais (que estão no vault canônico, saudável).

Dependência satisfeita: integração Google Workspace foi formalmente documentada em 2026-05-03 (google-workspace) — Axios tem acesso técnico via Service Account + 1Password CLI. Não há mais bloqueador de “como acessar” — só a decisão de “o que fazer”.

Progresso 2026-05-04 (Axios calibrado):

  • Folder 1_41m9rlWlTCryqaLEoxpY7_Y2kxQvXh2 validado em runtime — owner, modifiedTime, listagem de filhos batem com canônico
  • Axios escreveu via Drive API:
    • lessons.md no canônico (file ID 1prxA9ZM_wvUyh1oxOzpUbnuyNLBm0lyl)
    • operating-model.md atualizado (file ID 1F95dv53a-uVJBpHfEPp7q4daT6FrqVJX)
  • Default de leitura/escrita declarado como Drive API contra o folder canônico
  • Próxima rotina agendada: axios-meeting-prep-trigger em 2026-05-04 12:00 UTC — primeiro teste empírico do ciclo corrigido

Decisão remanescente (escopo reduzido): o que fazer com o drive-sync/* local agora que ninguém escreve nele. Opção mais provável: deletar quando conveniente (Pedro decide).

DP-1 — Atlas único × Atlas + agente irmão dedicado a fornecedores (decisão estrutural)

  • Aberta em: 2026-04-28 (post-discovery Leandro)
  • Owner da decisão: Pedro Villa
  • Co-decisores: Antônio Pavanelli, Gabriel
  • Prazo alvo: 2026-05-15 (sprint-semana-3 ou início da semana-4)
  • Task que rastreia: T-112 — priority: critica
  • Peso: estrutural — não é detalhe de feature. Define o catálogo de agentes Costal e potencialmente abre um agente transversal Costal + Compras Colliers + CREMS.

Pergunta a decidir:

Atlas absorve fornecedores e equalização (opção A), ou se cria um agente irmão dedicado que entrega propostas equalizadas para o Atlas consumir (opção B), ou solução intermediária com módulo lógico interno (opção C)?

O que motivou a decisão:

Discovery 28/04 com Leandro Delecrodio revelou que a equalização de propostas de fornecedores tem complexidade desproporcional ao restante do processo:

  • Decomposição semântica por componente (luminária e mobiliário)
  • Lógica por código de marca (ex: Deca AP51)
  • Cobrança ativa de fornecedores (e-mail + WhatsApp + ligação)
  • Benchmark cruzado com home center
  • Negociação contínua de formato com fornecedor (relacionamento de longo prazo)

Frase de Pedro: “parece que o tema de fornecedores e equalização de propostas de fornecedores é um tema sensível, talvez tenhamos que ter um agente específico para isso. Essa é uma decisão de projeto que quero tomar depois, para modificar o escopo do Atlas.”

Hipótese de plataforma associada (a validar com a decisão):

Um agente de fornecedores pode ser transversal — atender:

  • Atlas (orçamentação Costal — equalização de cotação)
  • Compras corporativas Colliers (Tatiana Souza — banco de >70 fornecedores homologados que Gianlucca já trouxe)
  • CREMS Property (manutenção predial: contratos diretos condomínio↔manutencista; OS no Smart Colliers)
  • CREMS Facilities (fretados, food, services em ML — qualidade de dados de fornecedores é o gargalo declarado)

Se confirmado, muda o status de feature local da Costal para plataforma transversal Anouk × Colliers/Costal. Não decidir essa hipótese antes de fechar DP-1.

Inputs empíricos necessários antes de decidir:

InputTaskPor que bloqueia
Estrutura real das pastas de propostas históricas na rede ColliersT-111Sem ver o formato real, decisão é especulação
Visão de Lucas (2º orçamentista) sobre equalizaçãoT-113Confirma se a dor de Leandro é universal ou idiossincrática
Pacote completo das 3 obras fechadas (Unimed, Sondotécnica, Aliar)T-115Baseline real para dimensionar volume e variação por categoria

Atualização 2026-05-04 (revisão Igor 03/05):

A revisão estrutural assíncrona de Igor reduz pressão em uma dimensão e mantém em outra:

  • Reduz — Change Orders saem do escopo nominal do Atlas (DP-3). Menos volume cognitivo no agente único favorece a Opção A.
  • Mantém — equalização semântica + disparo precoce paralelo a fornecedores continuam sendo argumentos para descolamento (Opção B).
  • Novo dado — boundary Costal/Colliers explicitada por Igor: Costal terá depto de compras 100% independente da Colliers. Se a Opção B for adotada, o agente irmão pode ser transversal Atlas + Compras Costal + Compras Colliers (Tatiana/CREMS) — argumento adicional para a Opção B.

Atualização 2026-05-06 (revisão Igor 05/05) — sinal forte para Opção B:

Igor articulou explicitamente o problema-alvo do agente irmão e propôs codinome:

“Para termos um alto grau de eficiência, teremos que disponibilizar para os nossos parceiros e fornecedores-chave, algum tipo de recurso (agente) que também os ajude com este processo, pois a nossa dificuldade é exatamente a dificuldade deles com os seus respectivos fornecedores, valores, históricos, etc.”

“Relay, o estagiário do Atlas (acho que esse é o agente pai)”

O que mudou:

  • Codinome explícito: Atlas = pai · Relay = estagiário (subordinado)
  • Articulação clara do problema: o Relay não é só infra para Costal — é assistência aos fornecedores-chave para reduzir a complexidade no nível abaixo (efeito cascata redutor de complexidade Costal)
  • Hierarquia organizacional sinalizada: “estagiário do Atlas” sugere modelo subordinado, não par independente — reforça Opção B (Atlas dirige, Relay executa especialização) e descarta variante de pares independentes

Recomendação 2026-05-06: Opção B parece ter ganhado consenso operacional do MD. Próximo passo é validar viabilidade arquitetural com Antônio + Gabriel (T-130), então fechar DP-1.

Risco de não decidir (rationale para a urgência):

  • Atlas segue com escopo ambíguo
  • Especificações de dados ficam vagas (não dá para modelar Bronze/Silver/Gold sem saber se equalização é módulo Atlas ou agente externo)
  • Backlog Onda 1 fica não-priorizável
  • Costal pode criar planilha-padrão por conta própria fora do desenho integrado (R-018) e a janela arquitetural se fecha

Documentos que reverenciam essa decisão e serão atualizados quando ela for tomada:

2026-05-12 — Assessment RFP Costal — Taiany Campioni

Contexto: Discovery completa do pipeline comercial da Costal construtora com Taiany Campioni, única responsável pelo ciclo (prospecção → entrega → pós-venda). Mapeamento de ferramentas, processos e dores. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. AS-IS do pipeline comercial Costal: 3 ferramentas fragmentadas (RD Station + Microsoft Lists + Excel) — RD para pré-venda, Lists (~2 meses) para pipeline, Excel para obras. CRM não suporta ciclo completo. Validado por Taiany.
  2. Ticket mínimo go/no-go: R$ 200.000 — abaixo disso, peso da equipe inviabiliza proposta. Exceção: cliente estrangeiro sem equipe local.
  3. Costal dividindo em dois perfis operacionais — tickets menores com time Colliers; obras pesadas (infraestrutura/industrial/logística, R$ 10M+) para a Costal. Estratégia Igor/Taiany.

2026-05-11 — Kickoff Semanal Anouk (Semana 4 do Assessment)

Contexto: Kickoff da quarta semana com apresentação do inventário Screener, status do Sienge, e definição do agente de conciliação NF. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. Agente de conciliação NF opera FORA do Sienge via API padrão, sem customização do ERP — consenso Pedro, Gabriel, Marcos. Base de conhecimento de “depara” (composição de itens) fica no banco Anouk, não no Sienge.
  2. MVP de arquitetura de dados para Colliers: simples (PDF→markdown), sem streaming — volume (~371 GB) menor que estimado. Costal precisa de mais processamento (AutoCAD, canteiro, tempo real).
  3. Apresentação a Bruno e Ricardo no dia 01/06. Envio do material ~25/05. Rascunho interno: 18/05 — Orçamento detalhado + rateio Colliers/Costal solicitado.
  4. Orçamento AWS: pedir cenário de 1TB (reduzido) — cenários anteriores de 2-4TB para Costal. Gabriel refina com Lucas.

2026-05-11 — Assessment Incorporações Colliers — Vlamir Mazotti

Contexto: Discovery da vertical de incorporações com Vlamir Mazotti. Mapeamento de modelo de negócio, equipe, segmentos e sinergias internas. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. Incorporações é 100% in-house, equipe mínima (Vlamir + Maara) — analista de arquitetura entrando em julho. Modelo de prospecção ativa (“Lego” de lotes).
  2. Fluxograma operacional completo de todas as áreas Colliers existe — feito pela consultoria Ambera para o jurídico. Solicitar via Tatiana (jurídico).
  3. Sinergia cross-functional validada: Incorporações + SPS + Office em projetos build-to-suit — exemplo: projeto Redbook. Amanda (SPS) é key person.

2026-05-07 — Devolutiva MI pt. 2 Colliers — Leandro Braga Cardoso

Contexto: Segunda sessão de follow-up sobre modelo de dados MI. Pedro apresentou subdivisão em três camadas; Leandro identificou gap de tracking de proprietário. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. Incluir dimensão de tracking histórico de proprietário (versionamento temporal) no modelo MI — gap identificado por Leandro: proprietário muda ao longo do tempo (XP → BTG → Itaú). Análogo ao tracking de ocupação.
  2. Proprietário é dimensão separada de transação de compra/venda — transação = evento pontual; proprietário = período de posse.
  3. Canal Slack de MI aberto para Leandro interagir com Axios assincronamente — mesmo modelo usado por Igor na Costal.
  4. Reunião pré-execução adiada: consolidação assíncrona primeiro — spec v3 publicada, Daniel retorna de férias, revisão conjunta, depois reunião final.

2026-05-05 — Devolutiva MI Colliers — Leandro Braga Cardoso

Contexto: Segunda sessão entre Pedro (Anouk) e Leandro Braga (Inteligência de Mercado Colliers). Pedro apresentou v2 da devolutiva com 27 problemas estruturais documentados e modelo de dados unificado. Leandro trouxe insight de geometria variável. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. Arquitetura de dados MI será Bronze-Silver-Gold com modelo unificado de 9+ entidades — validada por Leandro como “muito semelhante” à sua estrutura interna. Entidades: imóvel, subdivisão, ocupação, empresa, empresa-papel-período, venda, locação, controle, temporal.
  2. ID canônico único Colliers (id_colliers) com chaves múltiplas herdadas — Sila (descontinuado) e Buildings (vigente) mantidos como aliases. Resolve fragmentação de IDs entre fornecedores.
  3. Dimensão de agrupamento para geometria variável — conjuntos/módulos/galpões mudam de configuração (fusão/divisão/locação parcial). Pedro propôs nova dimensão pós-input de Leandro. A validar em 08/05.
  4. Power BI existente preservado durante migração gradual — alimentado pela nova estrutura até migração total. Sem impacto no trabalho operacional atual.

2026-05-04 — Kickoff Semanal Anouk (Semana 3 do Assessment)

Contexto: Alinhamento semanal interno da equipe Anouk. Recap da semana 2 (orçamentação, CREMS), distribuição de tarefas semana 3, decisões de arquitetura e operação. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. Quebrar agente Atlas em dois: um agente de orçamentação + um agente dedicado a fornecedores/equalização de preço — escopo único seria grande demais. Decisão de Pedro. Nota: alinha-se com DP-1 (Opção B favorecida).
  2. Retirar Lucas (2º orçamentista Costal) da agenda de discovery desta semana — informações já cobertas por Leandro Delecrodio. Confirmado por Antônio + Igor (Slack).
  3. Screener roda remoto via SharePoint, piloto nas pastas de Gianlucca antes de escalar — validar output com Michael, depois rodar à noite. Rodar com Cloud Code no terminal.

2026-04-30 — Colliers × Anouk: Acesso Drives e Segurança do Screener

Contexto: Reunião técnica com TI Colliers (Michael Sousa + Murilo Duarte) para alinhar segurança, privacidade e processo de autorização para o agente Screener acessar os drives corporativos. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. GMUD (Gestão de Mudanças) é pré-requisito obrigatório antes de qualquer execução do Screener — formaliza mudança, rollback, ativos afetados, stakeholders. Exigência de compliance TI Colliers.
  2. Screener terá acesso somente de leitura com nível de permissionamento zero trust isolado — Murilo cria perfil específico para a conta Anouk.
  3. Projeto de inventário de dados é confidencial — não discutir com outros colaboradores da Colliers (incluindo Igor) — preocupação de Michael com privacidade dos funcionários.

2026-04-24 — Discovery Inteligência de Mercado Colliers — Leandro Braga Cardoso

Contexto: Discovery emergente com Leandro Braga Cardoso (responsável operacional de Pesquisa e Inteligência de Mercado, Colliers). Reunião originalmente agendada com Leandro Delecrodio (erro de homônimo) — Pedro aproveitou para mapear a frente de inteligência de mercado corporativa. Corrobora e detalha o diagnóstico macro de Daniel Jackel (23/04). Ata: Minutes · Summary

Decisões tomadas:

  1. Inteligência de Mercado Colliers é uma nova frente de trabalho — adicionada formalmente ao escopo do assessment, com spec dedicada (inteligencia-mercado-spec).
  2. Primeira entrega técnica de Pedro: dicionário de dados as-is + arquitetura Bronze/Silver/Gold antes da sessão de 30/04 17h com Leandro Braga.
  3. Convenção operacional de homônimos: Leandro sempre referido pelo sobrenome — Braga = inteligência de mercado Colliers; Delecrodio = orçamentação Costal.
  4. Discovery de orçamentação reagendado para 2026-04-28 (ter) 16h com Leandro Delecrodio (correto) — Antônio conduz.

2026-04-23 — Assessment Colliers: Market Intelligence — Daniel Jackel

Contexto: Assessment informal de alto valor com Daniel Jackel (Head de Inteligência de Mercado / Research & Analytics — Colliers). Daniel se autoconvidou como facilitador da Anouk para as áreas comerciais. Diagnóstico do ecossistema de dados da Colliers — silos, planilha Excel 90MB como base de inteligência de mercado, dados de transações reais nunca consolidados. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. Discovery Colliers comercial em sessões conjuntas cross-área (não individual por departamento) — evita que cada área invente soluções fragmentadas; revela que 95% das necessidades são idênticas.
  2. Daniel Jackel como facilitador oficial da Anouk para as áreas comerciais Colliers — traduz negócio imobiliário para o time Anouk; acompanha reuniões de discovery como co-entrevistador.
  3. Foco atual Colliers = REAMS (Real Estate Asset Management) — áreas comerciais entram no próximo ciclo; delimitação de escopo mantida por Marcos Eduardo.
  4. Rafael faz mapeamento global de fontes de dados Colliers com Daniel — para agora — antes das férias de Daniel (semana que vem). Instrução explícita de Marcos.
  5. Abordagem top-down: começar com quem tem visão holística (Daniel → Ricardo → Sérgio de growth) antes de funilar por departamento.

2026-04-23 — Follow-up Costal: Mapeamento Sienge/Zepp e Controles para Agentes

Contexto: Follow-up operacional entre Igor Reginato (Costal) e Marcos Eduardo (Gescom — implantador Sienge), observado por Rafael Rossetto (Anouk). Revisão de matriz de sistemas Costal com foco em candidatos à automação por agentes Anouk. Ata: Minutes · Summary · Brief

Decisões tomadas:

  1. Zepp Aprovações será adotado na Costal. Sienge suporta apenas 2 alçadas nativas; Igor precisa de mínimo 3. Zepp estende para até 5 alçadas, com registros armazenados no Sienge.
  2. Lógica de alçadas por valor: até ~10k = gerente de obra; até ~50k = R da construção; acima = Igor. Estouro de linha orçamentária também aciona Igor independente do valor. (Valores ainda não formalizados — premissa.)
  3. Design híbrido Zepp + Sienge: 2 alçadas = tudo no Sienge. 3+ alçadas = alçadas iniciais no Zepp, última alçada sempre no Sienge. Pendente de validação técnica com Gescom.
  4. Budget corporativo (CAPEX/OPEX empresa) ficará em Excel — Sienge cobre fluxo da obra e conjunto de obras, não o budget empresarial completo.
  5. DDA bancário (API Itaú) será contratado e integrado ao Sienge — eliminando operação manual de pagamentos.
  6. Emissão de NF migra para o Sienge — contabilidade receberá acesso; antes feita no Viaics.
  7. Diário de obra ficará dentro do Sienge. Confirmado por Igor.
  8. Escrituração contábil e SPED: envolver contador da Conecta antes de decidir o fluxo — responsabilidade é do contador, não do sistema.
  9. Foco da Anouk = identificar riscos e controles candidatos a agentes (não gerenciar a implantação do ERP). Declarado por Marcos como delimitação de escopo.

2026-04-23 — Discovery Sistemas e Aplicações Colliers — Michael Sousa (TI)

Contexto: Primeira reunião formal entre equipe técnica Anouk (Gabriel Fernandes, Rafael Rossetto) e TI da Colliers (Michael Sousa, Coord. TI). Objetivo: mapear ecossistema de aplicações da Colliers para embasar a arquitetura do Data Lake. Ata: Minutes · Summary · Brief

Decisoes tomadas:

  1. Fontes de verdade para o Data Lake Colliers são Senior (ERP), RD Station (CRM) e SharePoint. Integração direta com o Flokzu não é o caminho — Flokzu é orquestrador de processo, não fonte primária de dados. Confirmado por Michael e sintetizado por Gabriel no debriefing pós-reunião.
  2. Flokzu não será adotado na Costal. Zepp Aprovações + Zepp Despesas assumem o papel de gerenciamento de despesas de obra na Costal, integrados ao Sienge. Decisão de Igor Reginato, confirmada por Michael.
  3. ERP Senior será o centralizador de tudo na Colliers — retroalimentará CRM (RD Station) e Flokzu via integrações de API. Horizonte declarado: 2027. Diretriz de Michael Sousa.

2026-04-22 — Reorganização estrutural do vault (Ondas 1–6)

Contexto: Vault Colliers × Costal apresentava problemas estruturais identificados pela equipe: 64 arquivos _index.md homônimos no Graph do Obsidian; 00-projeto/ com 19 arquivos flat misturando governança, canônico, assessment e missões; falta de visão executiva consolidada (tarefas, reuniões, definições); HOME-board.md frágil (35 linhas sem saúde/KPIs/decisões pedidas); ausência de STYLE-GUIDE e runbooks; taxonomia inconsistente entre perenes e datados. Plano aprovado em 2026-04-22.

Decisoes tomadas:

  1. Padrão folder note — renomear todos os 69 _index.md para <nome-da-pasta>.md ao nível pai. Cada nó do Graph agora tem nome único.
  2. Subpastas por função em 00-projeto/ — criar canonico/, governanca/, assessment/, missoes/, board/ (+ renomear 00-01-reunioes/ para reunioes/). 17 arquivos movidos.
  3. Camadas operacionais vivas na raiz — criar TASKS.md, MEETINGS.md, DEFINICOES.md como derivações de gaps/dependencias/atas. Não-canônicas, mas com cadência fixa de atualização.
  4. Bases dinâmicas expandidas — _bases/ agora com 7 bases (adição de tasks-abertas, proximas-reunioes, definicoes-recentes).
  5. Documentos metodológicos — STYLE-GUIDE.md (convenções práticas), 5 runbooks operacionais em 99-operacao/runbooks/, guia de uso do Obsidian.
  6. Pacote board completo — reescrita do HOME-board.md como portal executivo + revisão do brief Q2 com decisões pedidas detalhadas + novos roadmap-board.md (Mermaid 12 meses) + kpis-board.md (19 KPIs).
  7. Taxonomia formalizada — perenes sem data (camadas canônicas, missões, governança), datados com YYYY-MM-DD_ (eventos, atas). MEMORY-CONTRACT §4.1 atualizado; STYLE-GUIDE documenta exemplos.
  8. Axios re-treinado — AXIOS-HANDOFF.md e memory/context/project-map.md atualizados com nova estrutura.

Métricas finais: 69 arquivos renomeados + 170 wikilinks reescritos + 17 arquivos movidos + 23 arquivos novos criados + 1 órfão deletado + 0 _index.md sobreviventes. Histórico completo em changelog.

Owner do plano: Pedro Villa. Execução: sessão Cowork 2026-04-22.

2026-04-17 — Kickoff Meeting

Contexto: Reuniao inicial entre Anouk, Igor Reginato e equipe Colliers.

Decisoes tomadas:

  1. Priorizacao por orcamentacao — Iniciar automacao pelo modulo de orcamentacao para ganho competitivo imediato
  2. IA semi-assistida — Adotar modelos combinando LLMs de mercado com modelos proprietarios treinados nos dados da Colliers
  3. Execucao por etapas — Usar matriz de priorizacao (tipo BCG) para sequenciar modulos
  4. Data Lake como fundacao — Avancar com Databricks em AWS/Azure como base da solucao
  5. ERP como fonte transacional — Sienge sera sistema transacional; analytics e IA ficam no Lakehouse
  6. APIs obrigatorias — Exigir APIs em todas as ferramentas de mercado para evitar lock-in
  7. Multi-tenant — Arquitetura deve permitir replicacao para LatAm
  8. Dados legados autorizados — Uso do historico de ~500 projetos da Colliers para treinar modelos
  9. Assessment primeiro — Fase de assessment de 45-60 dias antes da execucao de modulos
  10. SaaS transitorio — Adotar 1-3 ferramentas SaaS com API enquanto o Lake e construido
  11. Apoio na Implantação do ERP — Marcos Eduardo fará uma proposta separada para apoiar a Costal/Igor na implantação do ERP Sienge (Camada transacional do ERP), será a interface com o time da Anouk para a integração com o data lake e com os agentes de IA.

2026-04-08 — Alinhamento Estratégico Pedro × Ricardo Betancourt (marco zero do projeto)

Contexto: Primeira reunião documentada do assessment — antecede em 9 dias o kickoff Costal com Igor (17/04). Pedro apresentou a ferramenta de Inteligência de Mercado (FII/CVM) já desenvolvida, e Ricardo definiu prioridades estratégicas Colliers/Costal e o método de implementação. Ata: 04

Decisões tomadas:

  1. Property Management = primeira frente Colliers para IA — alta repetitividade (book contábil mensal por condomínio, ordens de compra, cotações, aprovação de síndico), controle interno e baixa dependência externa. Sequência subsequente indicada: Áreas Corporativas → REMS (geral) → CTS → Avaliações (“ganho brutal”, redução de equipe pela metade). Aterrada em prep PM e prep Avaliações.
  2. Time mínimo e enxuto atendendo Costal e Colliers simultaneamente — não duas equipes em paralelo. Refletido na composição Anouk (Pedro, Gabriel, Antônio, Rafael, Blaschek + Marcos via Costal).
  3. Implementação “por camadas” vs “gestão por choque” — mudança cultural gradual, avaliação contínua da adaptação dos profissionais. Princípio que originou a estrutura de 3 Ondas (Quick Wins → Core Operations → Escala) e do período de 30 dias de “degustação” com MVPs (período 17/04 → 17/05).
  4. Tatiana Souza = ponto focal / braço direito Anouk na Colliers — coordena levantamento com áreas, conhece toda a empresa. Confirmada nas decisões posteriores.
  5. Leandro Braga Cardoso = “pai da criança” da ferramenta IM (FII/CVM) — interlocutor primário para evolução da ferramenta. Confirmado na discovery 04 (Braga responsável operacional de Pesquisa e Inteligência de Mercado Colliers).
  6. Ferramenta de Inteligência de Mercado (FII/CVM) liberada para uso da equipe Colliers — primeiro asset técnico da Anouk publicado e operando antes do kickoff oficial. 356 fundos ranqueados, score de compra, dashboard de fundos compradores, vacância crítica, radar por segmento (Logística, Shopping em alta), geolocalização de transações, BTGP Logística como caso-âncora. Próximo passo técnico: aplicar cap rate para estimar valor das transações.

Adicionar novas decisoes acima desta linha, seguindo o formato:

## YYYY-MM-DD — [Contexto]

**Contexto:** [Breve descricao]

### Decisoes tomadas:

1. **[Titulo]** — [Descricao]

Visão de gráfico

Backlinks