PLANO DE EXECUÇÃO — SubBond Tracker (portfólio de bonds do sub + capacidade de bonding cross-surety)

PLANO DE EXECUÇÃO — SubBond Tracker (portfólio de bonds do sub + capacidade de bonding cross-surety)

May (Marty) · Missão 1 · Estágio 3 (PLANEJADA) · M1-016 · 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-M1-016.md (seções citadas como §N) · decisão Felipe 07/09 12:28 EDT = APROFUNDAR (deep link; DEC-011 fechada em ops/acoes.csv; decisao_felipe gravada em ops/ideias.csv pelo agente pai — este documento NÃO alterou CSVs) · dedup NOVO (hash 7f81bc4249d415b3) · NÃO alterou CSVs. ⚠️ PONTO CRÍTICO — OS 3 RISCOS DO QA CARREGADOS DE FRENTE (§9, §11): o espaço vive entre dois substitutos $0 — a planilha (resolve "para 60%+" do ICP, risco nº 1 do dossiê §9/§11.1) e o portal grátis da surety (single-surety, fragmentado — mas as agencies têm incentivo para unificar grátis: "a janela pode ser ilusória", §11.3). Este plano ancora o produto na camada que NENHUM dos dois entrega — a capacidade de bonding cross-surety consumida × disponível, vinculada a obras (a mecânica "aggregate limit − utilized = available for next bid" é o MOAT de workflow do dossiê §10) — e converte os três riscos do QA em critérios de morte medidos no Gate 0 (planilha resolve ≥60% → morre; genérico cobre a camada ≤ US$ 100/mês → morre; portal da agência já cruza as sureties grátis → morre). Vencimento standalone (alerta de data) é comoditizado (calendário US$ 0 / Expiration Reminder US$ 99 — §7) — o alerta só existe acoplado ao risco do projeto ("este bond vence em 14 dias e a obra X só termina em 6 meses → renova ou fica descoberto"). Regra de ouro deste plano: NADA de construção, gasto ou publicação acontece antes do GATE 0 passar (teste-48h do dossiê §10 — ver seção 5.2). A ressalva M13 do dossiê (nenhum trial testado — §6/§8, caso contra §11.2) vira critério explícito de passagem do Gate 0. Nota operacional: o vínculo link_plano em ops/ideias.csv é gravado pelo OPS/agente pai (este documento não toca CSV). Nota de família: irmãs vivas do mesmo ICP-escritório aprovadas/planejadas no mesmo lote — M1-004 AddendaWatch (12:24, plano 12:28), M1-005 WarrantyDesk, M1-006 BidQualifier: problemas e dados distintos (bond/capacidade vs addenda vs garantia vs go/no-go), sem módulo compartilhado no MVP, página própria por produto (M19). Fronteiras mortas preservadas como critério de drift (§5.2): M1-R01 COI tracking GC-side, M1-R22 licença/EMR lookups, R51 certs do time (→ M1-008), M1-R19 prequal GC-side, WIP standalone p/ surety (→ M1-013).

---

0. RESUMO EXECUTIVO (3 linhas)

A sub de obra pública/comercial (US$ 3-20M) rastreia os próprios bonds em planilha — 1-2 h/semana do office manager/CFO — e quando o vencimento passa despercebido ou a capacidade de bonding já foi consumida em outro projeto, perde um bid cujo valor esperado é US$ 100-500k de receita (US$ 10-50k de lucro); pior: descobre no meio da obra que a surety cortou a capacidade (dossiê §1-3). O produto é o portfólio de bonds do sub, cross-surety: lê os bond documents e as cartas de capacidade (aggregate/single limit), calcula capacidade usada × disponível para o próximo bid por surety e no total, vigia vencimento contra o prazo de cada obra (alerta 30/14/7 dias — nunca no dia, §2 E5), apoia a renovação e gera o proof-of-bond que o GC pede — concierge → self-serve, US$ 549/mês ou US$ 4.200/ano (~36% de desconto, premissa explícita §9; qualifica os dois pisos M4). Antes de construir: GATE 0 executa o teste-48h do dossiê (§10) — 15 entrevistas com office managers/CFOs de subs US$ 3-20M que usam bond + trials de Expiration Reminder/Quickbase + recon do portal de agência + 1 portfólio real processado — e mata se <4/15 confirmam dor real e usam ≥2 sureties, se ≥60% dizem "planilha resolve", ou se o portal da agência já cruza as sureties grátis (critérios §5.2, derivados de §9/§11).

---

1. ESPECIFICAÇÃO DA SOLUÇÃO

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

"Eu tenho performance/payment/license bonds espalhados por 2-3 sureties e uma planilha que ninguém alimenta. A data de vencimento passou e eu perdi a licitação; ou estou no meio da obra e descubro que a capacidade de bonding já estava esgotada em outro projeto — a surety me cortou e o GC quer proof of bond atualizado hoje."

• Quem sente: CFO/Controller/Office Manager da subcontratada (não o GC — o sub é dono do próprio portfólio, §4, §7 "o sub é objeto, não dono dos dados" nos GC-side tools), US$ 3-20M de receita, que faz obra pública/comercial exigindo bond (bid/performance/payment/license/maintenance) com ≥2 sureties — a dor central do dossiê (teste-48h §10, caso contra §11.1).
• Custo atual (método do dossiê §3, estimativas rotuladas): 1-2 h/semana de rastreio manual a US$ 30/h = US$ 1.560-3.120/ano; 1 bid perdido/ano por bond vencido ou capacidade esgotada (de 20-40 bids/ano, hit rate 15-20%) = US$ 100-500k de receita esperada / US$ 10-50k de lucro; prêmio de bond 0,5-3% do contrato (sub de US$ 5M paga US$ 25-150k/ano) e rate increase de 0,5-1 p.p. por gestão ruim = US$ 2.500-5.000/ano. Dor mediana: US$ 3.500-8.000/ano direto + US$ 10-50k de oportunidade — o ticket US$ 549/mês se paga evitando 1 bid perdido a cada 2-3 anos (§3).
• Por que existe o espaço: o barato (planilha US$ 0) ganhou o registro de datas; os genéricos (Expiration Reminder ~US$ 99/mês) lembram a data; os portais das agencies são grátis mas de 1 surety só (sub com 2-3 sureties = múltiplos logins, §7/§8); os GC-side (Procore/TradeTapp/SubVault) tratam o sub como objeto da prequalificação, sem devolver o portfólio a ele (§7). O que NÃO existe (matriz §7): um SaaS dedicado ao subcontratante gerenciando o próprio portfólio cross-surety com capacidade utilizada × disponível ligada a projetos/bids. Veredito do dossiê: GAP PROVÁVEL (§8) — não comprovado por uso (M13: nenhum trial testado, §11.2).

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 irmãos:

1. Fase concierge (prova de valor): 3 subs piloto encaminham os bond documents ativos + as cartas de capacidade das sureties (aggregate/single limit — o que a surety manda na renovação) e citam as obras/bids em vista; o agente CONCIERGE monta o portfólio, roda o motor de capacidade, revisa 100% e entrega o relatório "usado × disponível" + riscos de vencimento × obra + resposta "dá para cotar o projeto X?". Cada correção do sub vira caso de aprendizado e teste automatizado. É a isca de prova (seção 2.1) e a fábrica de regras — ninguém paga ainda.
2. Fase self-serve (produto): o mesmo motor atrás de um onboarding guiado (upload dos bonds/cartas → wizard de confirmação do que o motor leu com dúvida → vínculo a projetos → dashboard de capacidade → alertas por e-mail). A decisão é sempre humana (o motor calcula sobre o declarado pela surety e rotula "confirme com sua agência" — ver contrato de saída).

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

Pipeline único, reutilizado pelo concierge e pelo self-serve. Unidades: surety/programa = fonte de capacidade (aggregate/single limit); bond = instrumento ativo (tipo, nº, obrigado, valor, datas, prêmio); obra/bid = onde o bond é exigido.

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

• Por portfólio montado: mapa de capacidade (usada × disponível por surety e total, com a data de validade de cada carta), status de cada bond vs obra (NA COBERTURA / VENCE ANTES DA OBRA / VENCIDO), agenda de renovação com docs que faltam. Por evento: alerta 30/14/7 com a consequência ("bond X vence em 14 dias; obra Y só termina em 6 meses — renove ou o projeto fica sem cobertura") e resposta à pergunta "dá para cotar o projeto Z?" (disponível vs exigido). Sob demanda: proof-of-bond (PDF) + export total — dados 100% do cliente; cancelamento sem multa (mensal) / pró-rata (anual).
• Prazo: portfólio completo montado em até 48h no concierge (docs enviados até qua 12:00 → relatório sex 18:00). Correção apontada em até 24h se o erro for nosso (regra vira teste).
• O que NÃO entra no contrato (limite de responsabilidade explícito): o software não emite, não renova e não negocia bond (o fluxo com a agência/surety segue o de sempre — o produto vigia e prepara), não é a surety (todo número de capacidade é calculado sobre o declarado pela carta e rotulado "confirme com sua agência"; nunca "garante" extensão de capacidade), não decide o bid (a decisão de cotar é do dono), não é advisory de underwriting/jurídico (Miller Act e afins são informados como regra estável, não como parecer), não é preqüal GC-side (o GC não ganha acesso ao portfólio no MVP — o proof-of-bond é exportado pelo sub) e não rastreia COI/seguro/licença/certificações (fronteiras mortas — seção 5.2). Documentos do sub nunca saem do cofre (regra CostSense).

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

ENTRA (v1, até a semana 12):

• Cadastro de sureties + upload de bond documents e cartas de capacidade (PDF) com parser e wizard de confirmação; fallback 100% manual guiado.
• Motor de capacidade por surety e cross-surety (aggregate − utilizado = disponível) sobre o declarado, com rótulo de confirmação com a agência.
• Vínculo bond ↔ obra/bid + vigia de vencimento × obra com alertas 30/14/7 (e-mail) e status por bond.
• Agenda de renovação (o que/com quem/docs que faltam) + prêmio anual por surety como dado.
• Proof-of-bond (PDF) sob demanda por obra + export total CSV/PDF.
• Painel do CFO: capacidade usada × disponível, utilização por obra, riscos cruzados.
• Plano standard: 1 conta = 1 sub, até 3 sureties e 50 bonds ativos (cobre o ICP multi-surety com folga; limites de produto, não de negócio).
• Fase concierge (semanas 6-8) operada 100% por agente com revisão humana; depois self-serve.

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

• ❌ Não é lembrete de vencimento standalone (calendário US$ 0 e Expiration Reminder US$ 99/mês já ganharam a data — §7; vencimento sem capacidade/projeto = comoditizado = a morte M1-R22 da vida, §5.2): o alerta só existe acoplado ao risco da obra e à renovação.
• ❌ Não é portal/integração com a surety (API de agency, scraping de portal — o sub traz os PDFs; integração = pós-MVP e só por API oficial).
• ❌ Sem emissão/renovação/pagamento de prêmio (o fluxo segue na agência); sem cotação de bond (Swiftbonds/Jet Surety continuam donos da emissão — e são canal, seção 2.2).
• ❌ Não é COI/insurance tracking do GC (M1-R01, morta), nem licença/EMR lookups (M1-R22, morta), nem certs do time (M1-008), nem preqüal/passaporte GC-side (M1-R19/TradeTapp), nem WIP/contábil (input é a carta da surety, não números contábeis — R59 fundida na M1-013).
• ❌ Sem multi-idioma, app mobile, white-label para agencies (pós-MVP/canal P3), integração com Procore/preqüal.
• ❌ Fora do ICP: sub com 1 surety + 1 bond (o portal grátis resolve — §10 risco 3/§11.1); GCs (exigem, não possuem bonds próprios); trades sem obra que exige bond; conta que quer "só a data" (não é lead, é o risco do produto — §5.2).

---

2. ESTRATÉGIA DE ENTRADA

2.1 Isca de prova antes do pitch

"Mapa grátis da sua capacidade restante" — o prospect envia os bonds ativos + as cartas de capacidade das sureties (e, se tiver, o próximo bid em vista); em 48h recebe o relatório: capacidade usada × disponível por surety e no total, os riscos de vencimento × obra ("seu performance bond da obra Y vence em 3 semanas; a obra vai até dezembro") e a resposta "dá para cotar o projeto X?". Quem vê o próprio risco em números — o bond que vence no meio da obra, a capacidade que a planilha dizia cheia e não está (ou vice-versa) — sente a dor e vira lead quente (a mesma oferta do concierge do piloto). Custo: ~30 min de agente por prospect. Segundo estágio no self-serve: lista de espera da página com "mapa grátis no lançamento".

2.2 Canais (todos gratuitos; ordem de prioridade)

1. Agentes/surety brokers como canal de distribution (§10 "canal: parceria com bond agencies"): o broker independente que coloca bonds do sub em múltiplas sureties perde quando o bond vence sem renovar e ganha quando o sub está organizado — ele indica o produto ao sub (sem comissão no MVP) e é a melhor fonte de reconhecimento do ICP multi-surety. Vigia: se a demanda virar "a agência quer o produto grátis/white-label como feature própria" → é o risco §11.3 (janela ilusória) → morre no Gate 0 (critério 5.2d), não vira pivô.
2. Contadores/CPAs que atendem construção: o CFO pergunta "quanto de capacidade a gente ainda tem?" ao contador — canal de indicação natural (material de 1 página + a isca).
3. Resposta orgânica onde a dor fala (inbound com prova social): r/ConstructionManagers (as threads E1/E2 do §2 são a prova social pronta: "Need a P&P bond asap", "Wasn't able to provide a bid bond..."), r/Construction, r/Estimators, r/GovernmentContracting (Miller Act) — responder com ajuda real sobre capacidade/renovação. May redige; Felipe posta na conta dele.
4. Associações: AGC/ABC e, em especial, ASA (American Subcontractors Association — o ICP literal); capítulos com obra pública; webinar de 20 min "quanto da sua capacidade de bonding você já usou?".
5. SEO (vocabulário de capacidade, sem dono): "bonding capacity", "aggregate limit vs single limit contractor", "Miller Act $150k performance bond", "surety bond expiration checklist", "how much bonding capacity do I have" — os incumbentes vendem emissão/portal e não disputam esse vocabulário (§6/§7). Base de thresholds federais/estaduais (Miller Act > US$ 150k, little Miller Acts, DOT) alimenta o conteúdo — mantida pelo CONTEÚDO com fonte, §3.1.
6. Gatilho de projeto federal/DOT (§4 gatilho 4): conteúdo "novo projeto federal? Miller Act exige bond acima de US$ 150k (regra estável desde 1935, §10)" + GCs de obra pública como inbound (exigem proof of bond atualizado — §4 gatilho 3; o GC nunca é ICP — fronteira M1-R01/M1-R19).
7. LinkedIn do Felipe (post/manual; o susto "surety cortou minha capacidade no meio da obra" é o gancho) + lista de espera da página Orbitask.

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

2.3 ICP (do dossiê §4, §5, §9, §10 — tabela)

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

Subject: Your surety just re-underwrote you — what's your capacity number now?

>

Hi [First name],

>

Bond expiry dates live in a spreadsheet, and bonding capacity gets silently consumed by jobs you won months ago — until the day a GC asks for proof and the number isn't there. We read your bond documents and your sureties' capacity letters, and show you, per surety: aggregate used vs still available — before you commit to the next bid.

>

Want a free read of your current capacity? Send your active bonds + latest capacity letter(s); you get the used-vs-available map and any expiry-vs-project risks in 48h, no strings.

>

[Nome] — Orbitask · SubBond Tracker

---

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.

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 (sub real, release, página, e-mail). N2 nunca revisa o próprio trabalho e nunca recebe o raciocínio de quem produziu. Cálculo de capacidade tem QA-N2 obrigatório a cada release — erro de subtração de limite = sub cota achando que tem capacidade e não tem = bid perdido na certa (o erro que o produto existe para evitar).

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

• Diário 09:00 ET — DEV/OPS: roda a vigia de vencimento × obra (30/14/7 dias; nunca no dia — E5 §2) e enfileira alertas com a consequência; processa uploads novos.
• Seg 09:00 ET — CONCIERGE/DEV: agenda da semana de renovações (bonds que vencem em ≤ 30 dias + cartas de capacidade a pedir).
• 1ª seg do mês — DEV: retro de acurácia do parser e dos alertas (taxa de falso positivo/negativo) → ajuste + changelog.
• Jan (anual) — CONTEÚDO: revisão anual da base de thresholds (Miller Act/little Miller Acts/DOT) com fonte re-verificada → changelog + alerta interno.
• Sáb 10:00 ET — QA-N2: amostra 100% dos relatórios no 1º mês, depois 10% aleatória; taxa de erro → retro.
• Sex 17:00 ET — digest semanal (existente): entra o placar do produto (portfólios montados, alertas enviados, eventos de valor, pilotos pagantes).
• Diário — OPS: lembrete de aprovações pendentes ≥ 24h (ritual do May).

3.3 Sub-planos

Criados no Bloco 1, passo 14, em planos/sub-*.md no padrão CostSense: sub-dev-motor.md, sub-concierge.md, sub-conteudo.md (VALIDAÇÃO/COMPETIÇÃO/QA/OPS reutilizam os existentes + ops/). Critério: cada sub-agente com plano vivo antes de atuar.

---

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

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

Critérios de passagem/morte na seção 5.2. Nenhuma etapa deste bloco constrói produto.

1. [PLANEJADOR] Montar lista de ≥ 30 candidatos (meta 15): ICP multi-surety US$ 3-20M — via brokers/agentes de surety (indicam subs com 2+ sureties), listas de preqüal de DOT/estados (subs com bond em obra pública), membros AGC/ABC/ASA, autores das threads §2 (E1/E2), empresas com vaga de risk/bonding coordinator, contadores de construção; colunas: nome, empresa, papel, canal, link, fonte. → ✅ ≥ 30 contatos com canal identificado e fonte.
2. [PLANEJADOR → 🔔 Felipe] Redigir (a) convite de entrevista (4 linhas, EN), (b) roteiro de entrevista (~12 perguntas: quantas sureties usa; tipos e nº de bonds ativos; como rastreia hoje (planilha/portal/contador/nada); horas/semana (§3); já perdeu um bid porque o bond estava vencido ou sem capacidade — ou passou perto? (caso concreto); a surety já cortou capacidade no meio de obra?; o portal da sua agência cruza as sureties?; com quanto de antecedência renova?; projeto federal/DOT novo em vista?; "planilha + calendário resolvem?"; WTP em 2 pontos — US$ 200 vs US$ 549/mês e US$ 4.200/ano com o desconto ~36% explícito (549×12 = 6.588, §9), com o mostruário da 1 página; fronteira: "isso é tracking de COI/seguro/licença pra você?"), (c) e-mail de solicitação dos trials (Expiration Reminder/Quickbase/monday). → 🔔 Felipe aprova os 3 textos (e-mail em nome do Felipe só após aprovação — protocolo do May). ✅ Textos aprovados (ou ajustados).
3. [VALIDAÇÃO + Felipe] Executar 15 entrevistas: Felipe envia DMs (LinkedIn/Reddit/associação, manual); VALIDAÇÃO envia e-mails aprovados e coleta respostas assíncronas; até 5 chamadas de 15-20 min com roteiro (Felipe na linha, VALIDAÇÃO registra). → ✅ ≥ 15 entrevistas, cada uma com: nº de sureties, dor real sim/não (caso concreto), "planilha resolve", "portal da agência cobre", WTP (fonte + data).
4. [COMPETIÇÃO] Executar as provas de uso (M13): trial Expiration Reminder (~US$ 99/mês — §7/§8); teste de template de bond em Quickbase (US$ 35-85/usuário — §7/§8) ou monday (US$ 24-48 — §7); recon de portal de agência (Swiftbonds: grátis, single-surety? §8); recon GC-side (Procore/TradeTapp: o sub tem acesso ao próprio portfólio cross-surety? §7). Foco da prova: quem entrega capacidade agregada cross-surety vinculada a projetos ≤ US$ 100/mês equivalente, self-serve? → ✅ Prova de uso M13 fechada: por player, o que entrega/NÃO entrega da camada de capacidade + preço real. ⚠️ Se após 5 dias úteis alguma prova não ocorreu nem por vídeo/escrito → Gate 0 NÃO passa (bloqueado, não morto) até M13 fechar.
5. [CONCIERGE/DEV-rascunho] Processar 1 caso real no motor concierge (rascunho, sem produto): sub multi-surety envia bonds ativos + cartas de capacidade (anonimizável; NDA só se o sub exigir → 🔔 Felipe assina, guardrail 2) → portfólio + relatório usado × disponível + riscos de vencimento × obra + "dá para o próximo bid?". → ✅ Relatório do caso real: valor percebido pelo sub, o que o motor acertou/errou, o que faltaria (valida o motor, a isca e o pitch).
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: dor real + ≥ 2 sureties (X/15), "planilha resolve" (Y/15), "portal da agência cobre" (W/15), WTP ≥ piso (Z/15), achados dos trials (alguém entrega a capacidade ≤ US$ 100/mês?), resultado do caso real. → 🔔 1 AVANÇAR (Blocos 1-2, custo US$ 0) · 2 AJUSTAR (preço/escopo/posição) · 3 ARQUIVAR (morte com motivo em ops/rejeitadas.csv — OPS/agente pai grava; PLANEJADOR não toca CSV). ✅ Decisão registrada.

BLOCO 1 — MOTOR DE PORTFÓLIO + CAPACIDADE (semanas 1-3 · após Gate 0 ✅ + 🔔 AVANÇAR)

A fundação na ordem certa: sem o vínculo bond ↔ obra, o produto vira lembrete de data (a morte M1-R22/planilha — §5.2).

1. [DEV] Modelo de dados (surety/programa com aggregate/single/vigência da carta; bond com tipo/nº/obligee/penal/datas/prêmio; obra/bid com valor/prazo/status) + importador guiado. → ✅ Portfólio do caso real do Gate 0 (passo 5) importado sem erro.
2. [DEV] Parser de bond documents e cartas de capacidade (PDF/upload) + wizard de confirmação humana; ambiguidade nunca silenciosa; fallback manual guiado. → ✅ ≥ 80% de extração correta em 10 documentos reais de ≥ 2 sureties diferentes.
3. [DEV] Motor de capacidade: por surety (aggregate − utilizado = disponível) e cross-surety; cálculo sobre o declarado com rótulo de confirmação com a agência. → ✅ Cálculo bate com a carta da surety nos casos-teste (0 divergência — QA-N2 audita).
4. [DEV] Vigia vencimento × obra (status NA COBERTURA/VENCE ANTES DA OBRA/VENCIDO) + alertas 30/14/7 com a consequência por obra. → ✅ Alertas corretos nos casos de borda (bond que vence amanhã vs obra que termina em 6 meses; renovação em andamento).
5. [DEV] Proof-of-bond (PDF por obra) + painel do CFO (usado × disponível, utilização por obra, prêmio anual, riscos). → ✅ PDF e painel conferidos contra o caso real (auditoria de totais).
6. [QA-N2] Release do motor (casos incluem o portfólio real do Gate 0 + 1 carta ambígua + 1 borda de vencimento). → ✅ Veredito; 0 divergência de capacidade/datas nos casos-teste.
7. [OPS] Sub-planos dos papéis de produto criados (seção 3.3). → ✅ Sub-planos vivos no padrão CostSense.

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

1. [PLANEJADOR → 🔔 Felipe] Texto do convite do piloto gratuito ("mapa grátis da sua capacidade restante" — isca, seção 2.1). → 🔔 Aprovação do texto. ✅ Aprovado.
2. [VALIDAÇÃO/Felipe] Recrutar 3 subs do ICP (prioridade: os de WTP do Gate 0 com gatilho recente — perdeu bid por bond/capacidade ou projeto federal novo, §4). Aceite por e-mail; se NDA/termo surgir → 🔔 Felipe assina (guardrail 2). → ✅ 3 subs ativos com ≥ 2 sureties cada.
3. [CONCIERGE] Operar 3-4 semanas: monta o portfólio real de cada sub (todos os bonds ativos + cartas de capacidade), entrega relatório usado × disponível + alertas de renovação com recomendação ("renove X antes de [data]: a obra Y vai até [data]"), revisão humana 100%. → ✅ 3 portfólios completos montados; ≥ 1 evento de valor por piloto: (i) vencimento evitado que deixaria obra/retenção descoberta OU (ii) decisão de bid mudada pela capacidade ("não tínhamos o que a planilha dizia" / "temos mais do que pensávamos").
4. [DEV] Feedback loop: cada correção do sub vira teste/regra de parser e de cálculo. → ✅ 100% das correções da semana viram teste automatizado.
5. [CONCIERGE] Medir WTP pós-uso ("se custasse US$ 549/mês, continua?") e se o sub ainda depende do portal de 1 surety para decidir. → ✅ WTP registrado por piloto (fonte + data).
6. [QA-N2] Retro do piloto (o que o sub rejeitou, onde o motor errou, se puxou para fronteira morta — COI/licença/GC-side/vencimento standalone). → ✅ Relatório com taxa de adesão + lista de gaps + sinal de drift (seção 5.2).

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

1. [DEV] Self-serve: onboarding (upload docs → wizard → vínculo a obras → dashboard → alertas por e-mail), proof sob demanda, export total; integração com calendário Google/Outlook somente se o piloto mostrar adesão fraca ao dashboard (pivô P4). → ✅ Jornada ponta a ponta testada pelo QA-N2 com 2 pilotos sem assistência.
2. [PLANEJADOR/CONTEÚDO → 🔔 Felipe] Pricing final (US$ 549/mês / US$ 4.200/ano com desconto ~36% explícito — §9; qualquer ajuste não pode descer abaixo do piso M4 — abaixo disso = arquivar a ideia com motivo) + página Orbitask versão final (seção 6; versão EN/US derivada para o mercado). → 🔔 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 (inclui as páginas SEO de capacidade/Miller Act como porta de entrada). → 🔔 Aprovação do texto E da publicação (M19 — 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: 8-12 semanas; stack Next.js + PostgreSQL + parser de PDF + alertas/e-mail; integração de calendário condicionada ao P4). A partir daqui o produto vive em regime de operação contínua com retro semanal (QA + OPS) 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, brokers, associações, e-mail) são gratuitos; libs PDF/CSV open-source; página em free tier (Netlify/Cloudflare, padrão CostSense); base de thresholds em fontes públicas (Miller Act 1935, little Miller Acts estaduais, DOT specs). Stripe só entra com a 1ª receita (~2,9%/transação — 🔔 na ativação).

Premissa de preço explícita (padrão dos planos irmãos, lição QA-2 M1-007): US$ 549 × 12 = US$ 6.588; o plano anual é US$ 4.200 (= ~US$ 350/mês) → desconto ~36% sobre o mensal — premissa declarada (§9 do dossiê já a registra assim), nunca dois números soltos equivalentes. O mostruário das entrevistas e a página mostram os dois valores E o desconto. Piso M4: mensal ≥ US$ 500 ✅ (549) e anual ≥ US$ 3.500 ✅ (4.200) — qualifica os dois pisos.

5.2 GATE 0 — OBRIGATÓRIO, ANTES DE QUALQUER CONSTRUÇÃO (teste-48h do dossiê §10, com os riscos do QA §11 como critérios medidos)

O dossiê já definiu o teste (15 entrevistas, custo US$ 0-10, morte < 4/15 dor real + ≥ 2 sureties — §10); o caso contra do QA (§11) aponta os 4 modos de morte (mercado estreito, genéricos cobrem 80%, agência grátis, WTP hipótese). Este plano torna os quatro critérios de morte do QA parte do portão, medidos, não opiniã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 Nota de família e fronteiras (declarada, para o Gate 0 não reabrir o que já morreu)

• Irmãs vivas, mesmo ICP-escritório (não-canibalização): M1-004 AddendaWatch (aprovada e planejada no mesmo lote, 07/09), M1-005 WarrantyDesk, M1-006 BidQualifier, M1-001 Certified Payroll — problemas e dados distintos (bond/capacidade da surety vs addenda de bid vs garantia pós-obra vs go/no-go vs payroll). Sem módulo compartilhado no MVP; página própria por produto (M19); o bundling futuro (um "back-office do sub" com N módulos) é decisão do Felipe quando houver ≥ 2 produtos vivos — este plano não assume hub.
• Fronteiras mortas preservadas (anti-reciclagem): o produto é o portfólio de bonds do próprio sub, cross-surety, com capacidade — se qualquer etapa do Gate 0/piloto puxar para COI tracking do GC (M1-R01, M12), licença/EMR (M1-R22, lookups grátis matam ticket), certs do time (M1-008), preqüal/passaporte (M1-R19), WIP/contábil p/ surety (R59 → M1-013) ou vencimento standalone (alerta de data = M1-R22 da vida) → matar/arquivar com motivo, não esticar o escopo (critério g acima).

5.3 Gates seguintes e pivôs pré-desenhados

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

• P1 · parser → cadastro guiado: se os bond documents/cartas variarem demais para extração segura, o cadastro vira formulário guiado campo a campo (o produto continua o mesmo; muda o UX e o tempo de onboarding). Se nem o guiado vender → arquivar.
• P2 · self-serve → serviço gerenciado: se o sub pequeno não quer operar software, entregar o mesmo motor como serviço (portfólio mantido pelo concierge permanente + relatório mensal + alertas operados) no mesmo ticket US$ 549 — coerente com o ICP e com a isca.
• P3 · venda direta → canal agência/broker: se o sub não compra direto mas o broker quer o portfólio dos clientes organizado, vender via o broker (ele indica e acompanha). Limite: se a agência quiser o produto grátis/white-label como feature própria → é o risco §11.3 → matar, não competir com grátis (5.2c).
• P4 · dashboard → alertas por e-mail + calendário Google/Outlook: se a adesão diária ao dashboard for fraca no piloto, a entrega principal vira alerta por e-mail/calendário (o stack do dossiê §10 já previa calendar integration) — sem mudar o motor.

---

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; versão EN/US derivada no Bloco 3 para o mercado (padrão dos produtos irmãos).

SubBond Tracker — em breve, by Orbitask

>

O bond venceu no meio da obra — ou a capacidade de bonding já estava esgotada em outro projeto, e você só descobriu na hora do bid. O SubBond Tracker lê os seus bonds e as cartas de capacidade das sureties, calcula o que já está usado vs o que sobra para o próximo projeto (por surety e no total), avisa 30, 14 e 7 dias antes de vencer — sempre com a obra na conta — e gera o proof of bond que o GC pede.

>

Feito para subs de obra pública e comercial que trabalham com 2 ou mais sureties e não podem descobrir no bid day que a capacidade acabou.

>

CTA: "Quero o mapa grátis da minha capacidade restante → [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 APROFUNDAR pelo Felipe às 12:28).

• [x] Os 3 riscos do QA (§11) são tratados como adversários nº 1 do plano? Sim — seção 5.2 converte cada um em critério de morte MEDIDO: planilha resolve ≥ 60% (5.2b), genérico/agência entrega a camada de capacidade ≤ US$ 100/mês (5.2d, com M13 obrigatório — ressalva "nenhum trial testado" vira passagem), portal da agência já cruza sureties grátis (5.2c), WTP hipótese vira medição com 2 pontos (5.2b/f) + o "só quero a data" (5.2e, anti-comoditização). O produto é ancorado na capacidade cross-surety × obra (MOAT §10), nunca em alerta standalone.
• [x] Executável solo? Sim — todo o trabalho pesado é de agente (parser, motor de capacidade, concierge, textos, base de thresholds). Dependências humanas explícitas e mínimas: Felipe envia DMs, participa de chamadas, clica 🔔, assina NDA se surgir (R1/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 quantitativos (4/15, 60%, ≤ US$ 100/mês) derivados sem drift do §10 e do §11; M13 e o caso real viram critérios de passagem; G2 mata a morte que o Gate 0 não vê (capacity math = enfeite); fronteiras mortas viram critério de drift (5.2g).
• [x] Números batem com o dossiê? Conferido campo a campo: ticket 549/4.200 → 6.588 anual-equivalente, desconto ~36% explícito (§9) · qualifica os dois pisos M4 · mercado 839.609 NAICS 238 (CBP 2023, fato §5) / fatia ICP 15% = ~126.000 (estimativa rotulada §5) · admin 1-2 h/semana = US$ 1.560-3.120/ano · bid perdido US$ 100-500k receita / US$ 10-50k lucro · prêmio 0,5-3%, rate increase 0,5-1 p.p. = US$ 2.500-5.000/ano (§3) · Expiration Reminder ~US$ 99/mês, Quickbase US$ 35-85/usuário, monday US$ 24-48, Procore US$ 400-700+, portal grátis single-surety (§6-8) · Miller Act > US$ 150k estável desde 1935 (§10) · alerta mínimo 2 semanas antes (E5 §2) · morte §10 reproduzida sem drift · hash dedup 7f81bc4249d415b3. 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 12:28 07/09), M4, M12/M13 (trials no Gate 0), M19 (publicação 🔔), guardrails 1/5/6/9 respeitados; anti-reciclagem em 3 camadas: fronteiras mortas declaradas (M1-R01/R22/R19/R51/R59→M1-013), irmãs vivas do mesmo ICP com fronteira de problema/dado explícita (5.2a), "alerta standalone" como morte (5.2e — o produto não pode virar o Expiration Reminder de US$ 549).
• [x] O caso contra continua vivo no plano? Sim — 5.2 preserva as 4 mortes do QA §11 e a morte original §10; 5.3 acrescenta a morte pós-piloto; o risco "portal grátis da agência" (§11.3) está no Gate 0 E no G2.

Ressalvas (4 registradas):

1. R1 — recrutar 15 na fatia multi-surety é mais difícil que no ICP largo (e viesa early adopter). Sub com ≥ 2 sureties é fração desconhecida do ICP (§11.1). Mitigação: lista ≥ 30 com brokers/contadores/ASA/DOT como fontes (passo 1), entrevistas assíncronas, e o 1 caso real como profundidade que a amostra não dá; se a própria varredura de recrutamento mostrar que a fração multi-surety é rara demais para achar 15, isso já é sinal de morte (mercado estreito, §11.1) — registrar no relatório, não maquiar.
2. R2 — dependência humana + dependência de terceiros comprimem o "48h". O Gate 0 depende de Felipe (DMs/chamadas), das agendas de trial (Expiration Reminder/Quickbase) e da boa vontade de um sub em compartilhar bond docs + cartas de capacidade (confidenciais). Mitigação: entrevistas assíncronas por e-mail aprovado, trials self-serve, caso real anonimizável (redação de nomes/partes; NDA só se o sub exigir → 🔔 Felipe assina, guardrail 2), e atraso = bloqueio relembrado pelo cron (nunca morte silenciosa).
3. R3 — dados de bond são sensíveis e o erro de cálculo é o erro imperdoável. Um número de capacidade errado (parser que leu aggregate errado, carta vencida tratada como vigente) faz o sub cotar sem lastro e perder o bid — o produto repetiria a dor que existe para resolver. Mitigação: todo número rotulado "confirme com sua agência"; cálculo 100% sobre o declarado na carta com vigência rastreada; wizard para toda ambiguidade (nunca silenciosa); QA-N2 obrigatório a cada release do motor; docs no cofre (regra CostSense); contrato de saída delimita que não é a surety.
4. R4 — o canal de distribution (agência/broker) é a porta do drift para o grátis. O broker que indica o produto é o mesmo que pode querer virar o produto (portal unificado grátis — §11.3). Mitigação: o canal só existe empurrando o sub-side pago; se a demanda do lado da agência crescer (white-label/grátis), é critério de morte 5.2c + P3-limite, não pivô de escopo; o ICP na tabela 2.3 é estrito (sub dono dos dados, §7).

Veredito QA N1: APROVADO COM RESSALVA — executável solo com as ressalvas acima; os riscos do QA §11 são carregados de frente e viram critérios de morte medidos no Gate 0, que mata antes de qualquer gasto/construção; 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-016 — SubBond Tracker (portfólio de bonds do sub + capacidade cross-surety) Contém: especificação completa (upload de bonds + cartas de capacidade → motor aggregate−utilizado=disponível por surety e total → vínculo bond↔obra → vigia de vencimento 30/14/7 contra o prazo da obra → apoio à renovação → proof-of-bond p/ GC → painel do CFO; concierge → self-serve; MVP explícito, SEM alerta standalone e SEM COI/licença/certs/GC-side) + estratégia de entrada (mapa grátis da capacidade restante de isca; brokers/agências como canal; ASA/AGC/ABC; SEO de capacidade e Miller Act) + arquitetura de agentes + passo a passo com 🔔 e ✅ + página Orbitask rascunhada. GATE 0 obrigatório ANTES de construir (teste-48h §10 + riscos do QA §11 medidos): 15 entrevistas com office managers/CFOs de sub US$ 3-20M que usam bond (nº de sureties, dor real com caso concreto, WTP 2 pontos com ~36% explícito: 549×12=6.588 vs 4.200/ano) + trial Expiration Reminder/Quickbase + recon de portal de agência + 1 portfólio real processado. Morre se <4/15 dor real + ≥2 sureties, se ≥60% 'planilha resolve', se o portal da agência já cruza sureties grátis, ou se genérico entrega capacidade ≤US$ 100/mês. Orçamento: US$ 0-10; qualquer gasto 🔔. QA N1: APROVADO COM RESSALVA (4 ressalvas no arquivo, seção final — recrutamento na fatia multi-surety, dependência humana/terceiros, sensibilidade do dado de bond, drift via canal agência). → 1 APROVAR (começa Gate 0) · 2 PEDIR AJUSTES · 3 ARQUIVAR ``