Plano de execução em fatias

A decisão de desenhar tudo antes de executar entregou o que prometia: hoje qualquer dev recebe o sistema inteiro desenhado, sem ambiguidade e sem retrabalho de código por mudança de ideia. O inventário da fase de desenho:

• Telas: 100% mockadas e deployadas (tela única do caso com 5 etapas, filing, documento, notes, cliente + modelos de edição) — com a rede de I.As e ferramentas integradas.
• Fluxos: 5 boards navegáveis (caso, documentos, I.A conceitual, I.A por tecnologias, FigJam replicado).
• Specs: 24 atividades com tarefas, QA e critérios; guia de engenharia de agentes com template; handoff de frontend com goal + loop.
• Validação: auditoria da taxonomia (filings/documentos) contra a prática USCIS/EOIR e a base AILA, com 7 recomendações prontas para decisão.

Este plano é a colheita dessa fase — não uma mudança de estratégia. Mockar primeiro tirou o risco do desenho; executar em fatias agora tira o risco da entrega.

• Fatia vertical: cada entrega atravessa front + back + integração e termina em produção, usada por um advogado real. QA verde em dev não conta como pronto.
• Desenho congelado: ideia nova entra no backlog, não vira board/mockup novo — salvo decisão explícita da weekly.
• Disciplina de delta: tarefa dada como concluída não reabre; incremento vira tarefa nova (já é o padrão das specs).
• Ciclo por tarefa: implementar → QA com evidência → code review → concluído (goal + loop do handoff).
• Medir: cada fatia liga 2 métricas no KPI existente — adoção (quem usou) e SLA da etapa. Sem número, não há como provar que o sistema novo é melhor que o Airtable.

Fatia 1 — Intake/Setup em PRODUÇÃO semanas 1-2 quase tudo pronto

Por quê primeiro: está implementada em dev há semanas (triagem, relatório, wizard inline, finalize) — é a Fase 1 do roadmap parada esperando promoção. Menor fatia que prova o ciclo inteiro em prod.

• Falta: promover migrations 042-050 + env/GUCs para prod · finalize atômico (RPC) · finalize avançar flow_stage.
• Pronto quando: um Coordinator faz o setup de um caso real em produção com o relatório do agente ao lado.
• Métricas: % de casos novos com setup pela tela nova · tempo do setup.

Fatia 2 — Agendamento end-to-end semanas 2-5 a mais madura das grandes

Por quê: o backend está pronto em dev (ativ. 7), o contrato Google só espera o smoke DWD (ativ. 21, testes unitários verdes) e o canal de WhatsApp é o Yousa Chat (canal trocado na ativ. 37: webhook em tempo real + varredura do CRM a cada 2 min; primeira mensagem por template na conexão oficial). É o "uau" para os advogados: o agente marcando kickoffs reais no WhatsApp + Google Calendar.

• Falta: smoke DWD (decisão acima) · template aprovado da primeira mensagem (Yousa Chat, ativ. 37) · frontend do pacote de handoff (ativ. 17 T-11/T-12 + ativ. 23 T-1..T-8), handoff: specs/_ref/handoff-tela-caso-pre-kickoff.md.
• Pronto quando: um kickoff real é agendado pelo agente (cliente escolheu a data no WhatsApp) e aparece no Calendar do Attorney, com a tela refletindo o estado do bot.
• Métricas: % de kickoffs agendados sem humano · tempo intake→kickoff agendado (SLA).

Fatia 3 — Document Collection MVP semanas 5-8 início da saída do Airtable

Por quê: é onde a vida do advogado mais melhora e onde começa a desativação do Airtable de verdade — por módulo, não big-bang. Tudo desenhado: fluxo de 6 raias, telas com rede de I.As, contrato do Agente do Documento (ativ. 24), auditoria da taxonomia.

• Falta: tabela de taxonomia nossa no Supabase (seed do legado limpo + R1-R7 aceitas) · spec de implementação do Agente do Documento (usar o template da ativ. 24) · telas de documento/filing reais (mockups prontos).
• Pronto quando: um documento real do cliente entra pelo APP, é validado pelo agente (Doc feedback), revisado pelo time nas telas novas e entra num filing — sem tocar o Airtable.
• Métricas: % de docs validados pelo agente sem retrabalho · tempo de coleta por documento.
• Módulo que já existe (não construir): o Editor de Exhibit (repo exbt: exhibit-panel + document-template-node) já roda em produção com revisão da composição, editor de páginas e geração do PDF. Aqui o trabalho é integrar: trocar a leitura do Airtable pelas nossas tabelas, embutir na tela do filing com o login do sistema e receber a ordem sugerida do Agente do Filing. Este serviço entra na conta do desligamento do Airtable.

• CocoIndex — o pipeline atual (rag.py) atende o volume; reavaliar quando as fontes contínuas escalarem (fica no board como proposta).
• Desativação big-bang do Airtable — a saída é por módulo (documentos primeiro); o sync segura o resto.
• Guia dinâmico de kickoff · Google Docs · kanban de produção detalhado · caminhos por perfil de cliente — já adiados nas specs; continuam adiados até as 3 fatias entregarem.