# Wave 1 de aceleracao — plano mestre (5 frentes em paralelo, subagent-driven) > **For Claude:** REQUIRED SUB-SKILL: superpowers:subagent-driven-development por frente. Cada frente tem plano detalhado proprio em `docs/plans/2026-07-18-w1-f*.md` (produzido por agente de planejamento com G1 provado). Este documento e o contrato de orquestracao. **Goal:** Fechar em paralelo as 5 frentes pendentes (Partner Fase A, telas P0/P1, docs do cliente CORE, portal/Postman, capacidade extrema PIX) com qualidade blindada por gates de realidade — matando a classe de defeito "codou contra forma presumida". **Decisoes do dono (2026-07-18):** deploy CONTINUO a PRD (janela validada a cada subida, nunca durante operacao ao vivo); as 4 frentes + capacidade extrema juntas na Wave 1. --- ## Gates de realidade (obrigatorios em TODA task de TODA frente) - **G1 — Contrato provado ANTES de codar.** Sondar a forma REAL do que a task toca: schema vivo (`information_schema` via rpc read-only), payload real do fio (bacen_inbound/icom_received/DLQ/logs), XSD oficial (`/Users/luizpenha/cecresa/md/XSDDOCV512`), unidade monetaria (tabela do `Monetarie.Util.MoneyUnit` — DB/ledger=base units; v2/partner=centavos; eventos da cabine: created=reais, settled/return.*=centavos). Entregavel: bloco "CONTRATO PROVADO" no plano da task com a evidencia. Sem G1 nao se escreve codigo. - **G2 — TDD sobre a forma real.** O teste RED nasce do payload/schema capturado no G1. Fixture inventada de caminho feliz = task reprovada. - **G3 — Validacao viva = definition of done.** Exercitar em HML como usuario real (parceiro OAuth via tunel SSM 18080, tela com dado real, evento ida-e-volta) com evidencia colada no fecho da task. Suite verde sozinha NAO fecha task. **Checklist anti-infantil (vai no prompt de todo implementador):** unidade conferida na fronteira; IDs conferidos ENTRE eventos (transaction_id do created != do settled); zero acento em XML de fio; coluna que o codigo escreve existe na tabela VIVA (classe netting); reference/dedup keys unicos por caminho; nunca `LIKE '%x%'` sem indice em tabela grande de ambiente vivo; PRD/HML = leitura para investigacao, escrita SO pelo orquestrador. ## Orquestracao - **Fase P (planejamento, paralela):** 1 agente por frente le os relatorios-fonte + codigo real + roda sondas G1 read-only e escreve o plano detalhado (formato writing-plans, tasks bite-sized com arquivos exatos, testes, comandos) em `docs/plans/2026-07-18-w1-f-.md`. Ambientes: SOMENTE leitura. - **Fase E (execucao):** por frente, pipeline implementador -> revisor de spec -> revisor de qualidade por task (subagent-driven-development), em WORKTREE isolada por frente (F1/F2/F5 tocam codigo; F3 parte codigo parte docs; F4 so docs). Durante dev: testes FOCADOS; suite completa roda no gate de merge (serial, orquestrador). - **Merge/deploy:** orquestrador mergeia frente fechada na main (revisao adversarial de frente inteira antes), roda regressao completa, deploya HML, valida VIVO, e sobe PRD em janela propria (ICOM conferido pos-swap de pix; core antes de pix quando houver acoplamento). Capacidade extrema (F5): implementacao entra na wave; DEPLOY PRD so em janela dedicada com acompanhamento de logs. - **Vigias em paralelo (orquestrador):** netting 00:30 UTC (1a janela pos-DDL); snapshot 05:00 (card ~R$3,2M); proximo auto-return organico (rota nova); segunda 21/07 = cliente roda sequencias com acompanhamento 100% (freeze de deploy DURANTE as sequencias). ## Frentes e escopo ### F1 — Partner API Fase A (fonte: `docs/reports/2026-07-17-auditoria-fluxo-cliente-partner-api-telas.md`) Itens 1/2/3/4/6/17 + defeitos 2/3/4/8/9/10: infracoes (dispatch de escrita no dict_api_responder + rota POST + rota partner), claims (`GET /pix/claims` + `POST /pix/claims/:id/complete` + lifecycle do CONTEST), MED 2.0 (rotas cancel/list/refund/graph; fix `recovery_complete_refund` URL 404; **CautelarWorker/TimerEnforcer ao supervisor**; webhooks `pix.med.*`), defesas pelo lojista (fim do 403), devolucao de TED (rota partner + use case Core credito-ate-NumCtrlSTR + consumer `monetarie.spb.credits.return_status` + webhooks `ted.refund.*` + migration formal das colunas do DevolutionEngine + `SPB_AUTO_RETURN_ENABLED` em PROD = decisao do dono no deploy + matching com conferencia CPF/nome), `GET /accounts/:id/events`. ### F2 — Telas IB/merchant P0+P1 (fonte: `docs/reports/2026-07-17-mapeamento-ibfront-merchantfront-vs-aviv.md`) P0: QR das telas via motor REAL da cabine (matar o stub EMV sem CRC em `v2/pix_controller.ex:702`), copia-e-cola (`payQrCode` inexistente), cobranca paga visivel ponta a ponta (serializer paid->used + criacao pela tela 501). P1: TED agendada v2 (`ScheduledTed` nos controllers partner/v2 — scheduledDate hoje ignorado), limites reais (`/limits`), TEF via handler real do partner, PIX Automatico trilho unico (um dos dois vai a DLQ), rotas v1 `/pix/in|out` com `event`. Validacao viva pelas telas com dados reais. ### F3 — Docs do cliente, FRENTE CORE (fonte: `docs/reports/2026-07-17-mapeamento-4-docs-cliente-core-spb-pix.md`) Relatorio de movimentacoes CCS (8 colunas, export PDF/Excel) + notificacao CCS por e-mail; relatorios Vulci #1 (extratos 4 formatos incl. OFX), #2 (avisos de credito), #3 (movimentacoes analitico/sintetico), #14 (saldos por gerente), parte do #8; SISBAJUD B.3 (titular/natureza/vara) e B.4 (bloco de atendimento editavel); AMES (gerador + tracker + tela). ### F4 — Fase D: portal do parceiro + Postman + docs Regenerar portal + 2 Postman identicos com `POST /pix/qrcodes/static` (valor aberto/fechado), `GET /ping`, docs do refund novo (item 5) e dos webhooks novos; proposta de publicacao do `docs/partner-portal/` (zero infra Terraform — recomendacao para decisao do dono); relatorio de validacao por API nova no padrao do PDF de 17/07 (regra do dono: cliente nunca ve defeito interno). ### F5 — Capacidade extrema PIX (fonte: PROMPT da frente autorizada, CLAUDE.md) Empacotamento de ate 10 transacoes por pacs.008 (fluxo BACEN oficial), limites BACEN NUNCA estourando (budget ANS 1.6s), so POSTs reais/validos, backpressure. G1 pesado obrigatorio: catalogo v5.12 + XSD do envelope multi-tx + limites do manual ICOM ANTES de qualquer desenho. Recomendacoes 1k TPS que se provarem necessarias entram (C14N nativo, CertificatePool ETS, keepalive HSM). **Deploy PRD APENAS em janela dedicada com acompanhamento de logs (mandato).** ## Protocolo de qualidade por frente 1. Task: G1 -> G2 (RED) -> implementa -> GREEN -> testes focados -> commit na worktree. 2. Revisor de spec (fresh) compara com o plano da frente; revisor de qualidade (fresh) revisa o diff. Loop ate aprovar. 3. Fecho da frente: revisor adversarial da frente inteira + suite completa + validacao viva roteirizada. 4. Merge na main pelo orquestrador; deploy HML; validacao viva; PRD em janela (rollbacks anotados; revisoes vivas atualizadas no CLAUDE.md). ## Riscos e regras duras - Dois implementadores NUNCA no mesmo arquivo/worktree; router/config compartilhado = merge pelo orquestrador. - PRD: escrita e deploy SO pelo orquestrador; subagentes tem mandato read-only em ambientes. - Nunca deployar/reiniciar pix/spb durante operacao ao vivo; ICOM conferido apos todo swap de pix. - Flags de comportamento novo em PROD (ex.: SPB_AUTO_RETURN_ENABLED) nascem OFF; ligar = decisao do dono. - Migrations: sempre aditivas/idempotentes, aplicadas via rpc, arquivo no repo no MESMO commit do codigo que as usa (classe netting nunca mais).