4
Frentes auditadas no código
1
Correção factual aplicada
4
Veredictos de exequibilidade
!
Aviso de cache
Se você acabou de abrir a URL da pauta principal e ainda enxerga 5 frentes e o agregado em 20 a 30 dias, é cache do navegador. A versão atual em produção tem 4 frentes e agregado de 17 a 25 dias. Faça refresh forçado (Ctrl+F5, ou Cmd+Shift+R no Mac) ou abra em aba anônima.
Bloco zero · contexto
O que mudou entre a v1 e a v2 da pauta
Durante a tarde, identificamos que uma das oportunidades listadas na primeira versão já está em produção há tempos. Corrigimos isso antes de sair pro cliente.
DOCX padrão autoral, removido da lista de oportunidades
A primeira versão da pauta listou "DOCX padrão autoral do escritório" como oportunidade #1 (3 a 5 dias, risco médio). Ao revisar o código do worker, confirmamos que essa frente já está implementada e rodando em produção. O endpoint /ai/fill-template recebe template_id e campos, executa RAG por campo do template, e devolve o documento preenchido no padrão visual do escritório. Listar como oportunidade futura geraria promessa redundante e abriria flanco com o Engº Sergio: ele poderia perguntar por que estamos "propondo" algo que já consome todo dia.
Correção aplicada na pauta atual: o item foi movido do bloco 04 (oportunidades futuras) para o bloco 02 (confirmações consolidadas), ao lado da entrega do acervo AR30 de 11/05. Vira evidência de evolução real, não promessa.
Pauta v1 (antes da correção)
- 1. DOCX padrão autoral · 3 a 5 dias
- 2. Plantas CAD vetoriais · 8 a 12 dias
- 3. Cronogramas MPP · 5 a 7 dias
- 4. Visibilidade de versão · 1 a 2 dias
- 5. Latência do draft · 3 a 4 dias
- Agregado: 20 a 30 dias dev
Pauta v2 (atual, em produção)
- 1. Plantas CAD vetoriais · 8 a 12 dias
- 2. Cronogramas MPP · 5 a 7 dias
- 3. Visibilidade de versão · 1 a 2 dias
- 4. Latência do draft · 3 a 4 dias
- Agregado: 17 a 25 dias dev
- DOCX virou confirmação no bloco 02
Bloco principal · auditoria caso a caso
As 4 frentes, frente a frente
Para cada frente, cruzamos: o que está prometido na pauta, o que o sistema tem hoje, o risco real e o veredicto de exequibilidade. Auditoria feita por leitura do código em /Users/maca/peritopro-trabalho/worker/src/worker.js e do schema.sql do D1.
1
Plantas e desenhos CAD vetoriais
Pauta: esforço 8 a 12 dias · custo $80 a $150 (ingestão única) + ~$5/mês · risco alto
Veredicto: prazo otimista, alto risco de promessa não cumprida
P
O que está prometido na pauta
Tratar plantas e desenhos como vetor (DWG ou PDF vetorial), com legendas e referências cruzadas indexadas. Permitir que o parecer cite planta com referência precisa, não com print achatado de baixa resolução.
S
O que o sistema tem hoje
O upload do worker aceita apenas as extensões pdf · doc · docx · xls · xlsx · jpg · png · gif · eml · msg. DWG não está na lista. Não há parser CAD instalado no projeto. O schema do D1 não reserva nenhum campo de metadado de planta (escala, projetista, número de prancha). Plantas que chegam hoje entram como imagem rasterizada via OCR genérico, perdendo a informação vetorial.
R
Risco real, em linguagem simples
Ler DWG dentro de um Cloudflare Worker é praticamente inviável. As bibliotecas de parsing CAD em JavaScript pesam mais do que o limite de CPU do worker permite executar com folga (50ms por requisição). Pra entregar isso de verdade, ou pedimos pro Engº Sergio converter o DWG em PDF vetorial antes de subir (joga trabalho pra ele), ou movemos parte da pipeline pra fora do Worker, em Durable Object ou serviço externo. Os 8 a 12 dias da pauta são otimistas. Caminho honesto: 15 a 25 dias, e somente se aceitarmos a versão "PDF vetorial só".
V
Recomendação pra reunião
Reposicionar essa frente como "estudo de viabilidade técnica, 5 dias" e não comprometer prazo de entrega nesta reunião. Após o estudo, voltamos com proposta formal e prazo realista. Levar como promessa fechada de 8 a 12 dias é abrir flanco.
2
Cronogramas físicos e financeiros (MPP)
Pauta: esforço 5 a 7 dias · custo zero adicional · risco médio
Veredicto: factível, com condição de fluxo declarada
P
O que está prometido na pauta
Ler arquivos .mpp (MS Project) e extrair marcos, linhas-base e desvios, de modo que o parecer referencie atraso com base no cronograma do próprio empreendimento, não em narrativa.
S
O que o sistema tem hoje
A extensão .mpp não está na lista de extensões aceitas no upload. Se o cliente subir .mpp, cai em tipo='outro' e o sistema não roteia pra nenhum parser. Não existe precedente de parser não-PDF no worker (email entra mas é armazenado criptografado, sem desserialização estruturada). As bibliotecas JavaScript que leem .mpp puro (mpxjs, office-parser) pesam de 3 a 5 MB, o que é proibitivo dentro do worker.
R
Risco real, em linguagem simples
O caminho realista é pedir pro Engº Sergio exportar o .mpp pra XML do MS Project ou XLSX, ambas opções nativas do MS Project. Aí o parsing é trivial e fica perfeitamente dentro do worker. Sem essa conversão prévia, ou inflamos prazo (3 semanas pra resolver embedding das libs), ou prometemos algo que não cumpre. Se o Sergio entender "manda o .mpp direto e funciona", a promessa quebra na primeira tentativa.
V
Recomendação pra reunião
Manter na pauta como factível em 5 a 7 dias, mas declarar o fluxo explicitamente: "Sergio exporta o cronograma do MS Project em XML ou XLSX, sistema absorve". Tem que estar escrito no contrato técnico. Sem essa cláusula, prazo escapa.
3
Visibilidade de versão na resposta
Pauta: esforço 1 a 2 dias · custo zero adicional · risco baixo
Veredicto: 70% já está pronto, frente mais segura
P
O que está prometido na pauta
Carimbar no rodapé do parecer qual versão do documento-base foi usada, pra Sergio saber se a IA respondeu sobre contrato versão 1 ou aditamento versão 2. Rastreabilidade total entre resposta e fonte consultada.
S
O que o sistema tem hoje
O endpoint /ai/ask já retorna a lista de documentos consultados (campo sourcesUsed com source_file, page e doc_id). O frontend já exibe "Fontes do acervo consultadas". A tabela documents do D1 tem o campo created_at com timestamp de upload. Falta só carimbar essa lista no rodapé do DOCX gerado e adicionar a data e hora de upload visíveis pro perito.
R
Risco real, em linguagem simples
Existe um único risco, e é semântico. Se o Engº Sergio entender que "o sistema vai detectar automaticamente qual aditamento substitui qual contrato", aí o escopo explode. Esse modelo de versionamento semântico exige migração de schema, lógica de detecção de aditamento por NLP, e nova UI de upload com marcação explícita. Vira 5 a 7 dias, não 1 a 2. Como "exibir o nome do arquivo e data de upload no rodapé", é mesmo 1 a 2 dias.
V
Recomendação pra reunião
Frente mais barata e mais segura. Sugiro começar por essa se o Engº Sergio toparrer alguma. Entrega visível em uma semana, baixo risco de quebra. Só precisa deixar escopo bem delimitado no diálogo: "exibir versão consultada", não "modelar aditamento".
4
Latência do draft de parecer
Pauta: esforço 3 a 4 dias · custo zero adicional · risco baixo
Veredicto: já está shipped, vira aviso de entrega
P
O que está prometido na pauta
Progresso visível em etapas (lendo acervo, estruturando análise, redigindo conclusões) e cache parcial entre regenerações próximas, para que a UX deixe de parecer travada durante os 127 segundos típicos de geração de parecer denso.
S
O que o sistema tem hoje
O streaming SSE (Server-Sent Events) já está implementado no endpoint /ai/ask com stream: true. O frontend já lê o stream e atualiza progress bar a cada 400ms, mostrando etapa atual e contagem de caracteres em tempo real. Isso JÁ está em produção, o Engº Sergio só não foi avisado formalmente da entrega.
R
Risco real, em linguagem simples
O "cache parcial entre regenerações" é parcialmente mito. RAG por sua natureza recalcula contexto a cada pergunta. Cachear contexto entre regenerações da mesma pergunta no mesmo caso é viável, mas o ganho é pequeno (5 a 15 segundos), porque o que pesa de verdade é o tempo de inferência da Anthropic, não o tempo de busca no acervo. Resta um polimento de UI: 1 a 2 dias, talvez 3 com cache de contexto idêntico.
V
Recomendação pra reunião
Praticamente shipped. Sugiro reposicionar como "entrega já consolidada, ainda não comunicada formalmente". Pode até virar bandeira positiva no início da conversa: "Engº Sergio, semana passada subimos o feedback em tempo real do parecer, queremos demonstrar". Inverte tom da reunião.
Bloco 06 da pauta · esclarecimento
O que é o SEJZ-03 condicional
O que é
SEJZ-03 é a terceira juntada do caso Silveira & Ejzenberg (o escritório do Engº Sergio). É uma frente de versionamento de chunks (pedaços indexados de documentos) que ficou pendente desde 05/05. Tem dois caminhos mapeados: o Caminho A já está em produção (70 chunks da juntada SEJZ-01 filtrados), o Caminho B está com o esqueleto pronto localmente, aguardando decisão do próprio Sergio.
Por que está como "não puxar"
A reunião de amanhã foi enquadrada como consolidação de entregas + abertura de melhorias. SEJZ-03 é um caso pendente, com decisão técnica ainda na mesa do Engº Sergio. Trazer ativamente sem necessidade poluiria a pauta e desviaria foco. Se ele puxar o assunto por iniciativa própria, retomamos com o que está mapeado e o que falta dele para decidir. Se não puxar, fechamos a reunião sem mexer no tópico.
O que fazer se ele puxar
Resposta curta: "Caminho A está em produção, Caminho B está pronto pra ativar, dependemos do seu retorno sobre o critério de filtragem que combinamos em 05/05". Sem entrar em detalhe técnico durante a reunião, marcamos um ponto separado para essa frente. Não fechamos prazo nem promessa nesta janela.
Pode tirar do documento se quiser
O bloco 06 não vai a campo, é só uma prontidão interna nossa para o caso de o Engº Sergio puxar. Se você (Marcos) achar que mantê-lo na pauta polui ou desvia, posso removê-lo da v3 sem prejuízo. Funciona dos dois jeitos.
Síntese · recomendação operacional
Tabela de risco e reposicionamento
Como cada frente deve ser tratada na conversa com o Engº Sergio amanhã, na minha leitura. Sua chamada final, Marcos.
Frente
Status real
Recomendação
1. CAD vetorial
Promessa otimista
Reposicionar como "estudo de viabilidade, 5 dias", sem comprometer prazo de entrega ainda.
2. Cronogramas MPP
Factível com condição
Manter, mas declarar fluxo: cliente exporta .mpp pra XML ou XLSX antes de subir.
3. Visibilidade de versão
70% pronto
Manter, limitar escopo a "exibir versão", não a "modelar aditamento". Começar por essa.
4. Latência do draft
Praticamente shipped
Reposicionar como entrega já feita, ainda não comunicada. Vira bandeira positiva.
Como prossigo, Marcos
Tenho duas estradas, ambas suportam a reunião de amanhã. Sua chamada define qual versão da pauta o Engº Sergio recebe.
Opção A · Reescrever a pauta
Aplico essas ressalvas na pauta principal: frente 1 vira viabilidade, frente 4 vira aviso de entrega já consolidada. Redeploy hoje à noite. Engº Sergio abre amanhã a versão revisada e fechamos o tom com mais segurança.
Opção B · Manter pauta, usar este doc como cola
A pauta principal segue como está. Este documento aqui fica como cola interna nossa para a dupla na reunião. Você e eu temos as notas de exequibilidade na cabeça, ajustamos o tom no momento do diálogo com o Engº Sergio.