PLANO DE EXECUÇÃO — AddendaWatch (vigia de addenda/versões dos documentos de bid para estimator de sub)

PLANO DE EXECUÇÃO — AddendaWatch (vigia de addenda/versões dos documentos de bid para estimator de sub)

May (Marty) · Missão 1 · Estágio 3 (PLANEJADA) · M1-004 · 2026-09-07

Status: rascunho completo → auto-revisão QA N1 (seção final) → pronto para 🔔 do Felipe (1 APROVAR = começa GATE 0 · 2 PEDIR AJUSTES · 3 ARQUIVAR). Fonte: dossiê marty/dossies/ideia-b1-addendawatch.md (seções citadas como §N) · decisão Felipe 07/09 12:24 EDT = APROFUNDAR (deep link; DEC-005 fechada em ops/acoes.csv; decisao_felipe gravada em ops/ideias.csv pelo agente pai — este documento NÃO alterou CSVs) · dedup NOVO vs M1-001 (payroll), M1-002 (claims CA), M1-003 (WC audit) e as 6 irmãs mortas da varredura B1 (§16: SubmittalBuilderAI, SubmittalChase, SpecWatch, LookaheadSub, TakeoffAI-Div, RFIstandalone). ⚠️ PONTO CRÍTICO — A RELAÇÃO COM O M1-006 BidQualifier (a irmã, AGORA já planejada): o dossiê do BidQualifier e o plano produto-bidqualifier.md (02/09) trataram este M1-004 como "possível irmã/módulo" e deixaram a decisão de família pendente, com recomendação condicional explícita: "se o Felipe aprofundar o M1-004 → FAMÍLIA (módulo do mesmo bid desk); se o M1-004 for arquivada/morta → BidQualifier ISOLADO" (M1-006 §5.2a e pivô P2). O Felipe aprofundou o M1-004 (07/09) — a condição da recomendação do M1-006 foi atendida. Este plano espelha o tratamento: (a) a decisão isolado × módulo do bid desk é parte do Gate 0 (pergunta ao Felipe no 🔔, §5.2), com recomendação agora pendendo para FAMÍLIA; (b) a fronteira entre os dois produtos é traçada explicitamente (§5.2a) para o MVP não canibalizar o irmão nem duplicá-lo; (c) o risco de "planilha cara" (registro bonito que ninguém alimenta) é critério de morte explícito (Gate 0, G1, G2 — anti-reciclagem com o M1-R18 BidFunnel, já arquivado: tracking-only sem WTP). Regra de ouro deste plano: NADA de construção, gasto ou publicação acontece antes do GATE 0 passar (teste-48h do dossiê §14 — ver seção 5.2). A ressalva M13 do dossiê (prova de uso pendente: nenhum trial testado — §2 nota, §6 nota, §15) e as correções do QA (§15: WTP em 2 pontos, trial obrigatório, datar threads, re-validar fração de mercado) viram critérios explícitos de passagem do Gate 0; a ressalva de redundância com M1-006 vira a decisão de família dentro do próprio Gate 0. Nota operacional: o vínculo link_plano em ops/ideias.csv é gravado pelo OPS/agente pai (este documento não toca CSV).

---

0. RESUMO EXECUTIVO (3 linhas)

O estimator de specialty sub cotando 10-30 obras ao mesmo tempo (§1) recebe addenda, desenhos revisados e especificações novas a qualquer hora — muitas vezes em cima do bid day (prova 2: addendum com desenhos novos 2 dias antes do bid; prova 1, fresca de 31/08/2026: obra ganha com escopo perdido por addendum não visto = "royally f*cked", e a auditoria pós-desastre começa por "você foi notificado dos addenda?") — e o substituto atual é o ritual manual de conferência (0,5-2 h/bid, US$ 750-13.500/ano por estimator em horas, §3) + portais de GC que avisam dentro de cada plataforma, sem visão do sub através dos N GCs (matriz §7c: as 4 fatias de watch/agregação/diff/ligação-com-a-estimativa estão vazias). O produto é um vigia de bid: o estimator registra o bid em aberto (forward do e-mail ou 2 cliques) e conecta uma pasta/regra de e-mail; o motor detecta addendum/desenho/spec novo, faz o diff contra a versão anterior (motor CostSense), extrai "o que mudou e em qual Divisão/trade" e manda o alerta com o checklist de re-verificação ligado à estimativa em curso ("addendum 4 mudou Div 26 → re-verifique estes itens") — e mantém a trilha versionada do que foi cotado em qual revisão, concierge → self-serve, US$ 549/mês ou US$ 4.200/ano (qualifica os dois pisos M4, §11). Antes de construir qualquer coisa: GATE 0 executa o teste-48h do dossiê (15 entrevistas WTP em 2 pontos + trials de STACK Version Compare/ProEst/Bluebeam Max fechando o M13 + pré-venda de 1 página), valida a fração de mercado e a NÃO-REDUNDÂNCIA com o M1-006 BidQualifier (teste de família), e traz a decisão isolado × módulo do bid desk no mesmo 🔔 — mata barato se <4/15 pagam o piso, se ≥6/15 dizem "portais + Excel + ritual resolvem", ou se um trial já vigiar ≤ US$ 100/mês equivalente.

---

1. ESPECIFICAÇÃO DA SOLUÇÃO

1.1 Necessidade (do dossiê — §1, §2, §3)

"Estou cotando 10-30 obras ao mesmo tempo, cada uma com desenhos que revisam, addenda que caem a qualquer hora (muitas vezes em cima do bid day) e especificações que mudam — se eu cotar em cima de um jogo de desenho velho ou perder um addendum, ou perco a obra (cotei caro) ou GANHO a obra com escopo faltando e como o prejuízo. Não existe ferramenta que vigie meus bids abertos, me avise 'caiu addendum 4 e ele muda a Div 26' e me diga o que eu preciso re-verificar na minha estimativa."

• Quem sente: estimator sênior / chief estimator e o dono/VP de estimativa de sub especializada (elétrica, mecânica, hidráulica, chapa, concreto, fundações, pintura comercial, div. 9), US$ 3-20M de receita, que licita ≥30 obras/ano contra múltiplos GCs (comercial privado e/ou obra pública) — §4; a office manager que organiza os bids no sub menor é usuária secundária; GC pequeno (US$ 5-50M) que também cota contra GCs maiores entra como ICP secundário.
• Custo atual: ritual manual de conferência 0,5-2 h por bid (ESTIMATIVA §3) × 50-150 bids/ano = 25-300 h/ano; a US$ 30-45/h carregado = US$ 750-13.500/ano por estimator (cenário central US$ 3-5k). Custo do erro: escopo perdido de 1-3% do contrato num contrato de US$ 0,5-3M = US$ 5.000-90.000 por evento (ESTIMATIVA, §3), evento raro (1 a cada 2-5 anos) mas documentado e fresco no thread 1w45xcs de 31/08/2026 (§2.1).
• Por que existe o espaço: o barato (Excel US$ 0, Contractor Foreman US$ 49/mês) já ganhou o registro; os incumbentes têm o motor de comparação sob demanda (Bluebeam Max AI drawing comparisons US$ 590/usr/ano; STACK "Version Compare" quote-only — §6.3/6.4) mas nenhum tem o watch — detectar que um set novo EXISTIU e puxá-lo, agregar os N portais do GC sob o ponto de vista do sub, nem ligar o addendum à estimativa em curso (matriz §7c: 5 linhas da stack, 4 fatias vazias). Veredito do dossiê: GAP PROVÁVEL — NÃO COMPROVADO POR USO (M13: trials pendentes — §7c, §15).

1.2 Forma concierge → self-serve

O produto nasce concierge (semanas 6-8) e vira self-serve (semanas 8-12), mesmo padrão do CostSense e dos planos M1-001/002/003/006:

1. Fase concierge (prova de valor): 3 subs piloto registram os bids em aberto (forward do ITB ou 2 campos) e conectam a pasta de documentos/regra de e-mail; o agente CONCIERGE roda o motor, revisa 100% dos alertas, entrega "caiu addendum X na obra Y — o que mudou — re-verifique: itens Z" e confirma com o estimator se o alerta foi útil (não sabia / já sabia mas o checklist pegou item / alarme falso). Cada correção vira caso de aprendizado e teste. É a isca de prova (seção 2.1) e a fábrica de regras de impacto por divisão — ninguém paga ainda.
2. Fase self-serve (produto): o mesmo motor, atrás de um onboarding guiado (registrar bid → conectar pasta/regra de e-mail → wizard de confirmação do que o motor classificou com dúvida → alertas automáticos → trilha → painel). O estimator marca "revisto" no checklist; o sistema nunca decide por ele (ver contrato de saída).

1.3 Motor etapa por etapa (entrada → saída)

Pipeline único, reutilizado pelo concierge e pelo self-serve. Ordem deliberada: o registro do bid vem ANTES do watch (sem bid registrado não há o que vigiar — mas o registro é forward/2 cliques, nunca planilha, anti M1-R18); o diff e o impacto vêm ANTES do alerta (alerta sem "o que mudou e onde" é spam que o estimator desliga — §13.1/§13.5):

1.4 Contrato de saída (o que o cliente recebe — e o que NÃO recebe)

• Por bid ativo: alerta em minutos/horas após a detecção — "addendum 4 (rev. C) chegou na obra X; o que mudou (diff); onde re-verificar (checklist por divisão)". A trilha mostra a última revisão vigente vs. a revisão cotada.
• Pós-bid day: fechamento de 2 cliques; trilha versionada completa exportável (CSV/PDF) — o ativo do cliente (§9).
• SLA: documento detectado até as 17:00 → análise na manhã seguinte (concierge); self-serve = automático no polling de 15 min. Correção apontada em até 24h se o erro for nosso (regra vira teste).
• Dados e privacidade: 100% do cliente; desenhos/addenda são documentos do projeto que o sub já tem licenciados para cotar (§12); vivem no cofre/R2, nunca em log/prompt de terceiro (guardrail 4, política CostSense).
• O que NÃO entra no contrato (limite de responsabilidade explícito): o software não vigia fora do que o cliente conecta (portais do GC entram por upload/forward no MVP — sem API de portal, sem login alheio), não opina sobre direito ("mudou X" ≠ "você perdeu direito" — disclaimer de minutas como o M1-002, §12), não refaz a estimativa/takeoff (Bluebeam/STACK/ProEst continuam donos do "estimar"; o entregável é o checklist de re-verificação), não decide por você (marcar "revisto" é humano), não é CRM de leads nem plan room (ConstructConnect/portais seguem sendo a fonte de convites).

1.5 MVP — o que entra e o que fica de fora (explícito)

ENTRA (v1, até a semana 12):

• Registro de bid em 2 cliques ou por forward do ITB (com baseline documental).
• Watch por pasta de documentos/regra de e-mail (IMAP) + upload manual (sem API de portal no MVP).
• Diff de PDF entre versões (reuso do motor CostSense), com tolerância para raster e viés de alarme falso.
• Classificação do evento (addendum/desenho/spec/extensão de prazo) + extração "o que mudou" por Divisão/trade.
• Alerta com checklist de re-verificação por item + registro de "revisto".
• Trilha versionada por bid + painel de bids ativos (revisão vigente × revisão cotada × addenda pendente de revisão).
• 1 conta = 1 sub; até 3 usuários (estimator + office manager + dono); até 30 bids ativos vigiados (cobre o "10-30 obras ao mesmo tempo" da dor §1 e o volume de 50-150/ano com folga).
• Histórico consultável + export total.

FICA DE FORA (explícito — não é escopo do MVP):

• ❌ Não é registro puro (tracking-only): a trilha só existe como consequência do watch — o produto que vira "bid register bonito" é o M1-R18 BidFunnel que já morreu (arquivada: tracking-only sem WTP) e a "planilha de US$ 549" do caso contra do QA (§15) → critério de morte explícito (Gate 0 (c), G1, G2).
• ❌ Go/no-go, win/loss analytics e debrief de perda: são o módulo M1-006 BidQualifier (já planejado) — se a decisão de família for módulo, entram como fase 2; se for isolado, ficam fora para sempre (fronteira §5.2a). O fechamento de 2 cliques deste MVP é só o resultado vinculado à trilha, não a base win/loss do irmão.
• ❌ Sem integração API com portais do GC (Procore/ACC/STACK rooms/BuildingConnected) no MVP; extensão de navegador sobre os portais = pivô P4 (§5.3).
• ❌ Sem re-estimativa/takeoff automático (a ligação com a estimativa é o checklist de itens, não integração com ProEst/STACK/Bluebeam).
• ❌ Sem envio de proposta/resposta ao GC; sem CRM de leads; sem opinião legal.
• ❌ Fora do ICP: GC/prime como comprador (é secundário; quem assina é o sub — §4); sub com <30 bids/ano (ticket não fecha — §7b/§11); conta que quer só o registro (Excel US$ 0, CF US$ 49 já cobrem — §6.5); o estimator que não conecta nenhum canal (churn anunciado, §13.1 — o produto morre de captura vazia).
• ❌ Multi-idioma, app mobile, white-label (pós-MVP).

---

2. ESTRATÉGIA DE ENTRADA

2.1 Isca de prova antes do pitch

"Vigiamos 1 bid seu em andamento por 2 semanas, grátis" — o prospect registra 1 obra que está cotando agora (forward do ITB + pasta de documentos) e recebe os alertas reais: quando cair addendum/desenho novo, o diff "o que mudou e em qual divisão" + o checklist. Para quem não tem bid caindo na janela, a isca instantânea é o diff de 2 versões que ele já tem na mão ("manda o desenho rev. A e o rev. B que chegou ontem — você vê o que mudou em 10 minutos"). Quem vê o próprio bid em andamento gritando "caiu addendum 4 — Div 26" sente a dor em tempo real (o concierge do piloto usa a mesma oferta). Custo: ~15-30 min de agente por prospect. Segundo estágio no self-serve: lista de espera da página (seção 6) com "vigia grátis de 1 bid no lançamento".

2.2 Canais (todos gratuitos; ordem de prioridade — mesmo ICP/canais do M1-006, família)

1. Resposta orgânica onde a dor fala: r/Estimators — as threads do dossiê §2 são a prova social pronta (a nº 1, 1w45xcs "Royally f*cked" de 31/08/2026, é o gancho: "a auditoria pós-desastre começa por 'você foi notificado dos addenda?'") + r/Construction + grupos de specialty trade (elétrica, mecânica, hidráulica — Facebook/LinkedIn). Responder com ajuda real (May redige o texto; Felipe posta na conta dele — May não posta).
2. E-mail direto/DM para o gatilho de compra: empresas recém-contratando estimator/bid coordinator (vaga ativa = volume subiu e o estimator virou gargalo — gatilho (c) do dossiê §4). A vaga data o momento de dor, mesma mecânica do canal 2 do M1-001.
3. GCs como fonte de inbound, não ICP: o GC é quem publica o addendum e vê o sub cotar versão velha; conteúdo "como os subs não perdem addendum no bid day" + GC que conhece o sub parceiro afogado indica (sem comissão no MVP). O GC não paga; ele aponta o sub.
4. LinkedIn do Felipe (post/manual: o caso 1w45xcs é o gancho) + lista de espera da página Orbitask.
5. SEO (categoria vigia): páginas "bid addenda tracking", "drawing version control for subcontractor estimators", "how to track addenda across GC portals" — categoria sem player dedicado (varredura §7a não achou nenhum; a matriz §7c mostra o vazio).
6. Irmã M1-006: se a decisão de família for módulo (Gate 0), a distribuição é única — mesma lista de espera e mesmo canal do BidQualifier (um bid desk); os dois planos não dividem o mesmo orçamento de aquisição duas vezes (§5.2a).

• Canal que NÃO existe no MVP: anúncio pago (gasto 🔔) e marketplace (produto cedo demais).

2.3 ICP (do dossiê §4, §5 — idêntico ao do M1-006)

2.4 Template de outreach (rascunho — 5 linhas, EN; envio só após 🔔 do texto, protocolo May/Marty)

Subject: Did addendum 4 change your bid on [GC]'s [project]?

>

Hi [First name],

>

Specialty subs price 10-30 jobs at once, and addenda with revised drawings drop whenever — often 2 days before bid day. One missed addendum and you either lose the job (priced high) or win it missing scope (the "royally f*cked" story from r/estimators last week).

>

We watch your open bids for you: connect a folder or email rule, and when addendum 4 lands we diff it against the previous set and tell you what changed and which division to re-check in your estimate — no more manual "am I on the right drawings?" ritual.

>

Want us to watch one of your live bids free for 2 weeks? Send the ITB — no strings.

>

[Nome] — Orbitask · AddendaWatch

---

3. ARQUITETURA DE AGENTES (construir e operar — padrão CostSense/Marty)

A ideia é do May (Missão 1); construir é decisão humana do Felipe (guardrail 9). Aprovado o Gate 0 (🔔 AVANÇAR), a construção roda como linha de produto da Orbitask: sub-agentes efêmeros (sessões OpenClaw) com sub-planos próprios no padrão do CostSense, sob supervisão do Felipe. O May (fábrica) segue rodando em paralelo, sem conflito. Nota de família: se a decisão do Gate 0 for módulo do bid desk, o DEV compartilha o modelo de dados com o BidQualifier (um sub-dev, dois módulos — a trilha versionada do watch é insumo do score go/no-go do M1-006, §5.2a); o M1-006 já previu esse desenho (plano produto-bidqualifier.md §3.3: "um único sub-dev-bid-desk.md cobre os dois módulos").

3.1 Sub-agentes de produto

QA de dois níveis: N1 = revisão leve de produção (quem produz revisa — ex.: a auto-revisão na seção final deste arquivo); N2 = adversarial, sessão nova, sempre antes do que toca o mundo externo (cliente, GC, página, release). N2 nunca revisa o próprio trabalho e nunca recebe o raciocínio de quem produziu.

3.2 Crons (operação, após o Bloco 3)

• Polling 15 min (07:00-19:00 ET) — DEV: watcher de pasta/regra de e-mail dos clientes → classifica → diff → alerta. (Watch é o motor, não um cron diário; o polling é a cadência do produto.)
• Diário 18:00 ET — DEV/OPS: processa a fila do dia, enfileira análises pendentes e lembretes de "revisto" atrasado (addendum recebido há X dias sem confirmação de revisão).
• Seg 09:00 ET — DEV: varre bids com resultado (e-mail do GC/status/2 cliques do estimator) → vincula resultado à trilha.
• 1ª seg do mês — DEV: retro de acurácia do watch (falso-positivo vs falso-negativo; regras de divisão acertaram? onde o estimator corrigiu) → ajuste de regras + changelog. Falso-negativo é o número que mata (§13.5).
• Sex 17:00 ET — digest semanal (já existente): placar do produto (bids vigiados, alertas enviados, taxa de "revisto", alertas úteis, pilotos pagantes).
• QA-N2 — amostra semanal de alertas/trilhas no 1º mês, depois mensal; taxa de erro → retro.
• Diário — OPS: lembrete de aprovações pendentes ≥24h (mesmo ritual do May).

3.3 Sub-planos

Criados no Bloco 1, passo 12, em planos/sub-*.md no padrão CostSense: sub-dev-watch.md, sub-concierge.md, sub-conteudo.md (VALIDAÇÃO/COMPETIÇÃO/QA/OPS reutilizam os sub-planos existentes + ops/). Critério: cada sub-agente com plano vivo antes de atuar. Se família com M1-006: um único sub-dev-bid-desk.md cobre os dois módulos (watch + go/no-go), como já previsto no plano do irmão.

---

4. PASSO A PASSO (responsável · 🔔 aprovação · ✅ critério de pronto)

BLOCO 0 — GATE 0 · teste-48h do dossiê (pesquisa; custo US$ 0-10; proíbe construção/gasto/publicação)

Critérios de passagem/morte na seção 5.2, incluindo o teste de não-redundância com o M1-006 e a decisão de família no 🔔 final. Nenhuma etapa deste bloco constrói produto.

1. [PLANEJADOR] Montar lista de ≥30 candidatos a entrevista (meta 15): autores das threads do dossiê §2 (1w45xcs "Royally f*cked", 1bzwl0d "Bids Due to GC earlier than hard bid date", 1hjp4dn "Bid Management Software?"), empresas com vaga ativa de estimator/bid coordinator (gatilho c do §4), 29 alvos do Gate 0 do M1-001 (mesmo ICP); colunas: nome, empresa, papel, canal, link. → ✅ ≥30 contatos com canal identificado e fonte.
2. [PLANEJADOR → 🔔 Felipe] Redigir (a) convite de entrevista (DM/e-mail, 4 linhas), (b) roteiro (~12 perguntas: nº de bids/ano e de GCs; por onde os addenda caem hoje (e-mail? portal? ambos — quantos logins?); como sabe que o desenho mudou; ritual de conferência atual e horas; caso concreto de addendum/versão perdida ou quase em 24 meses; já ganhou obra e descobriu escopo faltando?; quem confere os docs antes de fechar; WTP em 2 pontos — US$ 200 vs US$ 549/mês + anual US$ 4.200 — com o mostruário da 1 página; teste de redundância com M1-006: apresentar as duas dores — "vigiar addenda/versões dos bids em andamento" × "decidir o que cotar e aprender com o resultado" — "é um problema só ou dois? compraria em 1 ferramenta ou 2?"; premissa de mercado: "quantos subs como você licitam esse volume na sua região?") e (c) e-mail de solicitação das 3 demos (STACK Version Compare/ProEst/Bluebeam Max). → 🔔 Felipe aprova os 3 textos (e-mail em nome do Felipe só após aprovação — protocolo May). ✅ Textos aprovados (ou ajustados).
3. [VALIDAÇÃO + Felipe] Executar 15 entrevistas: Felipe envia DMs (LinkedIn/Reddit, manual); VALIDAÇÃO envia e-mails aprovados e coleta respostas assíncronas; até 5 chamadas de 15 min com roteiro (Felipe na linha, VALIDAÇÃO registra). Correção do QA (§15): datar as threads do dossiê via arquivo/JSON nesta passada (6 das 7 têm data estimada). → ✅ ≥15 entrevistas concluídas, cada uma com resposta de WTP e do teste de redundância (fonte + data).
4. [COMPETIÇÃO] Executar os 3 trials/demos (STACK "Version Compare", Autodesk ProEst, Bluebeam Max): preferir vídeo/gravação + pricing por escrito; se live, Felipe entra 15-20 min. Foco da prova M13: eles vigiam (detectam que um documento novo existiu e avisam) ou só comparam sob demanda? a que preço? (Bluebeam Max = US$ 590/usr/ano compara sets que VOCÊ carrega — §6.4; STACK Version Compare exige carregar o set novo — §6.3). → ✅ Prova de uso M13 fechada: por concorrente, o que entrega self-serve de watch, preço real, sobreposição com a nossa camada. ⚠️ Se após 5 dias úteis alguma demo não ocorreu nem por vídeo/escrito → Gate 0 NÃO passa (bloqueado, não morto) até M13 fechar.
5. [CONTEÚDO] Pré-venda de 1 página com pricing (US$ 549/mês e US$ 4.200/ano, o que resolve — vigia + diff + impacto por divisão + trilha, CTA lista de espera) — usada como mostruário nas entrevistas; não publicada (publicação é M19, só no Bloco 3). → ✅ 1 página rascunhada e usada nas entrevistas.
6. [QA-N2] Revisão adversarial do relatório do Gate 0 (sessão nova: só relatório + critérios de morte da seção 5.2). → ✅ Veredito em ops/qa-verdicts.md.
7. [OPS → 🔔 Felipe] Alerta com resultado consolidado: WTP (X/15), achados das 3 demos (alguém vigia?), respostas "portais + Excel + ritual resolvem", fração de mercado re-validada, teste de redundância com M1-006 (Y/15 "é um problema só") + recomendação de família (§5.2a) — se o Gate 0 do M1-006 já tiver rodado e decidido, o dataset é o mesmo (passo 3 não re-entrevista os mesmos 15; §5.2 BLOQUEADO). → 🔔 1 AVANÇAR ISOLADO · 2 AVANÇAR COMO MÓDULO DO BID DESK (família com M1-006) · 3 AJUSTAR (preço/escopo/posição) · 4 ARQUIVAR (morte com motivo em ops/rejeitadas.csv — OPS/agente pai grava; PLANEJADOR não toca CSV). ✅ Decisão registrada.

BLOCO 1 — REGISTRO + WATCH + DIFF (semanas 1-3 · após Gate 0 ✅ + 🔔 AVANÇAR)

A fundação na ordem certa: registro de 2 cliques (nunca planilha) + watch vivo + diff confiável antes de qualquer alerta bonito.

1. [DEV] Modelo de dados do bid desk (bid, GC, obra, trade, prazo, canais conectados, documentos, revisões, alertas, resultados) + registro de bid em 2 cliques/forward. → ✅ 5 bids reais dos pilotos registrados em <1 min cada, sem digitação longa.
2. [DEV] Watcher: polling de pasta de documentos + regra de e-mail (IMAP) + upload manual; detecção de "documento novo" por bid. → ✅ Documento novo largado na pasta/regra é detectado em ≤15 min em teste.
3. [DEV] Diff de PDF entre versões (reuso do motor CostSense; páginas alteradas; raster → comparação tolerante). → ✅ Diff detecta a mudança real em ≥9/10 pares de teste (docs reais da amostra do Gate 0) e 0 falso-negativo silencioso ("não mudou nada" quando mudou = falha bloqueante — §13.5).
4. [QA-N2] Release da base (sessão adversarial, casos-teste com documentos reais). → ✅ Veredito; 0 falso-negativo nos casos; viés de alarme falso confirmado por desenho.
5. [OPS] Sub-planos dos papéis de produto criados (seção 3.3). → ✅ Sub-planos vivos no padrão CostSense.

BLOCO 2 — IMPACTO + ALERTA + PILOTO CONCIERGE (semanas 4-8 · 3 subs reais · ninguém paga ainda)

1. [DEV] Classificador do evento (addendum nº/desenho rev./spec/extensão de prazo) + extração "o que mudou" (Divisões/trade). → ✅ ≥80% de classificação correta em 10 eventos-teste reais; ambiguidade nunca silenciosa (pede confirmação).
2. [DEV] Regras de impacto por divisão (biblioteca inicial + calibração com o estimator) + checklist de re-verificação por item + alerta acionável. → ✅ Em 10 alertas-teste, ≥8 trazem o checklist certo ("addendum 4 → Div 26 → itens X"); erra para alarme falso.
3. [PLANEJADOR → 🔔 Felipe] Texto do convite do piloto gratuito ("vigiamos 1 bid seu por 2 semanas" — isca, seção 2.1). → 🔔 Aprovação do texto. ✅ Aprovado.
4. [VALIDAÇÃO/Felipe] Recrutar 3 subs do ICP (prioridade: os de WTP do Gate 0 com gatilho recente — estimator recém-contratado, dono pós-desastre de addendum, bid day caótico recente). → ✅ 3 subs ativos com aceite por e-mail (sem NDA formal no piloto; se surgir termo → 🔔 Felipe assina).
5. [CONCIERGE] Operar o serviço 3-4 semanas: bid do piloto → watch → alerta com diff + checklist → estimator marca "revisto" e responde a utilidade (não sabia do addendum / já sabia mas o checklist pegou item / alarme falso); revisão humana 100% no início. → ✅ ≥2 pilotos com ≥5 bids vigiados cada; em cada um, ≥1 alerta útil (mudou a revisão que seria cotada OU pegou item que o estimator teria perdido).
6. [DEV] Feedback loop: cada correção do estimator vira teste/regra de classificação, diff e impacto por divisão. → ✅ 100% das correções da semana viram teste automatizado.
7. [CONCIERGE] Medir WTP pós-uso ("se custasse US$ 549/mês, continua?") e confiança no watch ("o alerta acertou quando você não sabia?"). → ✅ WTP registrado por piloto (fonte + data).
8. [QA-N2] Retro do piloto (taxa de alarme útil vs falso-positivo, falso-negativo reportado?, o que o estimator ignorou). → ✅ Relatório com taxa de adesão + lista de gaps.

BLOCO 3 — SELF-SERVE + LANÇAMENTO (semanas 8-12 · 🔔 em cada passo externo)

1. [DEV] Self-serve: onboarding (registrar bid → conectar pasta/regra de e-mail → wizard de confirmação → alertas automáticos → trilha → painel → export). → ✅ Jornada ponta a ponta testada pelo QA-N2 com 2 subs do piloto sem assistência.
2. [PLANEJADOR/CONTEÚDO → 🔔 Felipe] Pricing final (US$ 549/mês / US$ 4.200/ano; qualquer ajuste não pode descer abaixo do piso M4 — abaixo disso = arquivar a ideia com motivo) + página Orbitask versão final. → 🔔 Aprovação (M19). ✅ Aprovado.
3. [OPS → 🔔 Felipe] Converter 2-3 pilotos em 1ºs pagantes (preço de lançamento, carta simples) + ativar cobrança (Stripe/Felipe; May não move dinheiro — guardrail 1). → 🔔 Felipe autoriza cobrança. ✅ ≥2 pilotos pagantes OU ≥3 pré-vendas na lista de espera.
4. [CONTEÚDO → 🔔 Felipe] Publicar a página na Orbitask (em breve → disponível) + anúncio de lançamento. → 🔔 Aprovação do texto E da publicação (M19 — ver seção 6). ✅ Página no ar + anúncio enviado.
5. [OPS] Ligar crons de operação (seção 3.2) + ledger de gastos. → ✅ Operação rodando 2 semanas sem intervenção manual crítica.

Fim do passo a passo → 1º cliente pagante em ~12 semanas (SOLO: SIM, dossiê §10: 1-3 watch+diff, 4-6 alerta+checklist, 6-8 concierge, 8-12 self-serve+pricing). A partir daqui o produto vive em regime de operação contínua com retro semanal (QA + OPS + retro mensal de acurácia do diff) e a Missão 1 do May segue em paralelo rumo às 100 ideias.

---

5. ORÇAMENTO MÍNIMO + GATES/PIVÔS PRÉ-DESENHADOS

5.1 Orçamento mínimo

Padrão = grátis. Cérebro (DeepSeek/OpenClaw) e infra base já existem; canais e fontes (Reddit, LinkedIn, e-mail, trials dos portais) são gratuitos; libs PDF/CSV open-source; página em free tier (Netlify/Cloudflare, padrão CostSense). Stripe só entra quando houver 1ª receita (custo ~2,9%/transação — 🔔 na ativação).

5.2 GATE 0 — OBRIGATÓRIO, ANTES DE QUALQUER CONSTRUÇÃO (teste-48h do dossiê §14)

O dossiê já definiu o teste; este plano o torna portão de entrada — e acrescenta o teste de não-redundância com o M1-006 e a decisão de família (ponto crítico do QA §15 + ponto crítico herdado do plano irmão). O plano NÃO avança para construção sem o Gate 0 passar. Silêncio ≠ aprovação (lembrete 24h pelo cron).

5.2a A DECISÃO DE FAMÍLIA (isolado × módulo do bid desk com o M1-006) — perguntar ao Felipe no 🔔 do Gate 0, com recomendação

• (a) A pergunta: AddendaWatch e BidQualifier compartilham ICP (estimator de specialty sub US$ 3-20M), fase (bid) e até o bid register (matriz §7c do dossiê). São dois produtos (cada um US$ 549/mês no mesmo comprador, mesma conta G&A = canibalização e confusão de mercado interno) ou um bid desk com dois módulos (ticket único)? O plano do irmão (M1-006 §5.2a) já recomendou: "família se o M1-004 for aprovada; BidQualifier como módulo 2 do mesmo bid desk, watch primeiro". O Felipe aprofundou o M1-004 (07/09) — a condição foi atendida. Recomendação do PLANEJADOR: FAMÍLIA — um bid desk ("Bid Desk by Orbitask"), AddendaWatch como módulo 1 (a vigia; dor fresca de 31/08/2026 §2.1; entrada mais automática — pasta/e-mail) e BidQualifier como módulo 2 (go/no-go + debrief, já planejado e desenhado para ser fase 2 — M1-006 §5.3 P2). O 🔔 do Gate 0 (passo 7) decide com os dados do teste de redundância na mão.
• (b) O que justifica o isolado (se a decisão for essa): são decisões e inputs diferentes — AddendaWatch responde "o escopo/desenho do meu bid em andamento mudou?" (entrada: addenda/versões; momento: durante o bid; ativo: trilha versionada por bid); BidQualifier responde "esta RFQ vale a pena cotar? e por que ganhei/perdi?" (entrada: RFQ + histórico win/loss; momento: antes de entrar no funil e depois do resultado; ativo: win rate calibrado por GC/trade/tamanho). O watch não decide entrada e o go/no-go não vigia versões — complementares, não sobrepostos. Isolado faz sentido se: Felipe quiser dois lançamentos independentes (timing/risco separados), se o teste de redundância mostrar <40% de sobreposição percebida, ou se o M1-006 não avançar (a vigia não depende do score para viver; depende de o sub registrar bids e conectar canais). Nesse caso a fronteira do MVP (§1.5) garante que nenhum produto invade o terreno do outro.
• (c) O risco de planilha cara se tracking-only: o AddendaWatch só se sustenta como camada de watch + diff + impacto — a camada registro já está ganha pelo barato (Excel US$ 0, Contractor Foreman US$ 49/mês, §6.5). Se as entrevistas/piloto mostrarem que o sub quer "só organizar os documentos dos bids", o produto é o M1-R18 BidFunnel (já arquivado: tracking-only sem WTP) e morre no Gate 0 (critério c) ou no G1/G2 (ninguém conecta canais nem marca "revisto"). Este risco é critério de morte explícito, não ressalva.

5.3 Gates seguintes e pivôs pré-desenhados

Pivôs pré-desenhados (baratos, decididos no gate, nunca em pânico):

• P1 · alerta genérico → checklist específico calibrado: se "caiu documento X" sem impacto não engajar, forçar a camada de valor: diff por divisão + checklist em linguagem de estimator ("mudou a especificação de chapa na Div 09 — re-verifique itens 4-9 da sua takeoff") — o estimator precisa ver o próprio bid falando, não um aviso de e-mail (derivado de §13.1/§13.5).
• P2 · isolado → módulo do bid desk (família com M1-006): se o Gate 0 decidir família, este plano roda como módulo 1 do Bid Desk by Orbitask — mesmo modelo de dados e ticket único com o BidQualifier como módulo 2 (já planejado; M1-006 §5.3 P2 desenhou exatamente esta ordem: watch primeiro). O B0 deste plano já produziu os dados do re-planejamento; o plano do irmão já prevê o sub-dev-bid-desk.md único.
• P3 · self-serve → serviço gerenciado: se o sub pequeno não quer operar regra de Outlook/pasta, entregar o mesmo motor como serviço (vigia operada pelo concierge permanente, alerta por e-mail) no mesmo ticket US$ 549.
• P4 · pasta/upload → extensão de navegador/hook IMAP automático: se o piloto mostrar que ninguém conecta pasta nem encaminha (captura morta = produto morto — §6.8/§13.1), a captura vira extensão de navegador sobre os portais do GC/inbox do estimator, sem depender de ação manual do usuário.

---

6. PÁGINA DO SERVIÇO NA ORBITASK — rascunho "EM BREVE"

Marca guarda-chuva Orbitask, produto filho. Rascunho de 3-5 linhas + CTA (M19). PUBLICAÇÃO SÓ COM 🔔 APROVAÇÃO DO FELIPE (passo 24, Bloco 3; nada de "em breve" no ar antes do Gate 0 ✅ — página externa é publicação). Versão final deriva deste rascunho após pricing validado no piloto. Se a decisão de família for módulo do bid desk, esta página nasce como seção do "Bid Desk by Orbitask" (uma página, AddendaWatch módulo 1 + BidQualifier módulo 2) — ajuste no Bloco 3.

AddendaWatch — em breve, by Orbitask

>

Estimator: quantas obras você está cotando agora — e quantos addenda vão cair nelas antes do bid day? O AddendaWatch vigia os seus bids em andamento: conecte uma pasta ou regra de e-mail e, quando cair addendum ou desenho revisado, ele compara com a versão anterior e avisa o que mudou e qual divisão re-verificar na sua estimativa — com a trilha do que você cotou em cada revisão.

>

Feito para specialty subs que cotam contra vários GCs ao mesmo tempo — para nunca mais ganhar uma obra com escopo faltando (ou perder por cotar desenho velho).

>

CTA: "Vigie 1 bid meu grátis por 2 semanas → [lista de espera]"

---

QA N1 — AUTO-REVISÃO ADVERSARIAL DO PLANO (2026-09-07, pelo PLANEJADOR)

Sessão de auto-verificação antes do envio ao Felipe; QA-N2 externo segue obrigatório no Gate 0 (passo 6) e em toda entrega externa. Checklist Missão 1 aplicado ao PLANO (não re-julga a ideia — o dossiê foi aprovado com ressalva pelo Felipe em 07/09 via DEC-005).

• [x] Executável solo? Sim — todo o trabalho pesado é de agente (registro, watcher, diff, classificador, regras, concierge, textos). Dependências humanas explícitas e mínimas: Felipe envia DMs, participa de demos/chamadas, clica 🔔 (R2).
• [x] Gates matam cedo? Sim — Gate 0 é 100% pesquisa, US$ 0-10, antes de qualquer linha de código/gasto/publicação; critérios de morte do dossiê §14 reproduzidos sem drift (a-c) + (d) fração de mercado (correção §15) + (e) teste de redundância com M1-006 + (f) veto do pai; M13 vira critério de passagem explícito; correções do QA §15 (WTP 2 pontos, datar threads, re-validar fração) incorporadas ao Gate 0. G1 mata o risco de falso-negativo (o erro que destrói confiança, §13.5) e o tracking-only (M1-R18) antes do alerta nascer; G2 mata o "ritual resolve" visto de perto.
• [x] Números batem com o dossiê? Conferido campo a campo: ticket 549/mês + 4.200/ano (qualifica os dois pisos M4, §11) · mercado 839.609 specialty (fato naics.com 02/09/2026) / fatia ICP 3-6% ≈ 25.000-50.000, pessimista 1% = 8.400 (ESTIMATIVA rotulada, §5) · horas do ritual 0,5-2 h/bid → US$ 750-13.500/ano por estimator (central US$ 3-5k) · erro de escopo US$ 5.000-90.000/evento, 1x/2-5 anos (ESTIMATIVAS §3) · 10-30 obras simultâneas (§1) · ≥30 bids/ano (piso do ICP) · Bluebeam US$ 260/330/440/590 por usuário/ano; Max US$ 590 compara sob demanda; CF US$ 49/mês (§6) · matriz §7c: 4 fatias vazias · SOLO: SIM 8-12 semanas (§10) · 7 evidências, 6 com data estimada (rotuladas §2, datadas no Gate 0) · morte §14 intacta. Zero drift.
• [x] Orçamento: US$ 0 padrão; todo gasto ≠ 0 com 🔔 (guardrail 1). Conforme.
• [x] Regras do May: M3 (plano só pós-Portão 2 ✅ — Felipe aprofundou 07/09), M4, M12/M13 (trials no Gate 0), M17 (piso com folga 8x até no pessimista, §5), M19 (publicação 🔔), guardrails 1/4/5/6/9 respeitados; anti-reciclagem em 3 camadas: dedup NOVO (não colide com M1-001/002/003 nem com as 6 mortas da varredura B1, §16), M1-R18 BidFunnel (tracking-only) vivo como critério de morte G1/G2, e a fronteira com M1-006 traçada (§5.2a) para o MVP não duplicar nem canibalizar o irmão.
• [x] O caso contra continua vivo no plano? Sim — seção 5.2 preserva as mortes do dossiê (§14: a/b/c) e acrescenta a da fração de mercado (d), a da redundância com M1-006 (e) e a do veto de duplicata (f); 5.3 acrescenta as mortes pós-piloto (falso-negativo = morte imediata; alerta nunca útil = enfeite; registro virou planilha = M1-R18).

Ressalvas (5 registradas):

1. R1 — a decisão de família agora depende de um M1-006 já planejado e da ordem dos Gate 0. O plano do irmão (02/09) condicionou a recomendação a "se o M1-004 for aprovada" — o Felipe aprofundou o M1-004 (07/09), então a recomendação deste plano pende para FAMÍLIA. Mas se o Gate 0 do M1-006 rodar primeiro e decidir isolado, ou se o Felipe preferir dois lançamentos, este plano roda isolado sem retrabalho (fronteira §5.2a + pivô P2 nos dois sentidos). Mitigação: dataset compartilhado de redundância (nunca entrevistar os mesmos 15 duas vezes — §5.2 BLOQUEADO) e o 🔔 do passo 7 pede a decisão com recomendação explícita.
2. R2 — dependência humana comprime o "48h". O Gate 0 depende de Felipe para DMs/chamadas e das agendas de vendedor para os trials; na prática pode levar 5-7 dias úteis. Mitigação já no plano: entrevistas assíncronas por e-mail aprovado, trials por vídeo/escrito, e atraso = bloqueio relembrado pelo cron de aprovações (nunca morte silenciosa).
3. R3 — amostra de 15 viesada + horas do ritual são ESTIMATIVA. Quem responde DM/Reddit tende a ser early adopter, e a quantificação §3 não tem fonte direta (rotulada). Mitigação: exigir resposta de WTP com valor concreto e caso concreto de addendum perdido nos últimos 24 meses (critério (a)); o mostruário com pricing ancora a conversa; o critério (b) testa os 2 pontos (US$ 200 vs US$ 549) que o QA §15 exigiu.
4. R4 — qualidade do diff em PDF raster só é testável com construção mínima. O Gate 0 usa os trials dos incumbentes (Bluebeam Max, STACK) como proxy do que o diff genérico faz; o teste real é o G1 com documentos reais (≥9/10 detecção, 0 falso-negativo). Por isso o falso-negativo é critério de morte em G1/G2, não ressalva — e o desenho erra para o alarme falso desde o dia 1 (§13.5).
5. R5 — fronteira fina com o que já morreu (M1-R18 BidFunnel, tracking-only) e com o irmão M1-006. O registro é necessário (sem bid registrado não há o que vigiar) mas nunca pode virar o produto; o go/no-go é do irmão e nunca entra no MVP isolado. Mitigação: registro de 2 cliques/forward por desenho, G1 mata se virar planilha, critério (c)/(f) do Gate 0 pega o comprador "só quero organizar", e a tabela §5.2a fixa a fronteira dos dois produtos.

Veredito QA N1: APROVADO COM RESSALVA — executável solo com as ressalvas acima; gates matam antes de qualquer gasto/construção; a relação com o M1-006 é tratada como decisão de produto explícita no Gate 0 (com a recomendação do irmão agora atendida), não como acidente; nada impede o envio ao Felipe.

---

ALERTA 🔔 PRONTO PARA O FELIPE (cópia para o OPS disparar; este subagente não enviou nada)

`` 💡 PLANO M1-004 — AddendaWatch (vigia de addenda/versões dos docs de bid do estimator de sub) Contém: especificação completa (bid aberto → forward/2 cliques + pasta/regra de e-mail → watch → diff (motor CostSense) → impacto por divisão → alerta com checklist de re-verificação → trilha versionada por bid; concierge → self-serve; MVP explícito, sem tracking-only e sem go/no-go — fronteira com o irmão) + estratégia de entrada (1 bid real vigiado 2 semanas grátis de isca; canais do ICP) + arquitetura de agentes + passo a passo com 🔔 e ✅ + página Orbitask rascunhada. GATE 0 obrigatório ANTES de construir: teste-48h do dossiê (15 entrevistas com WTP em 2 pontos + caso de addendum perdido em 24 meses + trials STACK/ProEst/Bluebeam Max fechando o M13 + pré-venda 1 página + re-validar fração de mercado) + teste de NÃO-REDUNDÂNCIA com o M1-006 BidQualifier (irmã de mesmo ICP/fase, já planejada — 02/09) e a DECISÃO DE FAMÍLIA no mesmo 🔔: produto isolado vs módulo do bid desk (recomendação: FAMÍLIA — a condição da recomendação do M1-006 foi atendida com o seu APROFUNDAR de hoje; AddendaWatch módulo 1, BidQualifier módulo 2). Critérios de morte incluem WTP < piso, "portais+Excel resolvem", trial que já vigia ≤ US$ 100/mês, fração <1%, tracking-only e duplicata do irmão. Orçamento: US$ 0-10; qualquer gasto 🔔. QA N1: APROVADO COM RESSALVA (5 ressalvas no arquivo, seção final). → 1 APROVAR (começa Gate 0) · 2 PEDIR AJUSTES · 3 ARQUIVAR ``