Seazone · Sapron · API v1 · Manutenção Recorrente
7 gaps entre a API /maintenance/ e o Processo v2.1. Cada item indica se a origem do problema está no Sistema (Sapron não implementa) ou no Processo (regra ainda em aberto). Cada gap tem botão ✦ Enviar ao Claude — abre uma conversa nova com todo o contexto e os critérios de aceite prontos pra virar código.
Ordem de prioridade. Marque cada item conforme resolver — o progresso salva no navegador.
listing_status.activation_date — feito no data-lake, não no SapronGET /api/v1/maintenance/?property_min_age_months=12 como filtro nativoPOST /api/v1/maintenance/preview-cycle retorna quem entra, quem barra e em qual pergunta parouPOST /api/v1/maintenance/notifications/dispatch agrupado por franchise_idPATCH /api/v1/maintenance/{id}/pause + campo sla_paused_at no cardGET /api/v1/maintenance/overdue?bucket=d7|d14|d21|post + webhook por bucketPOST /api/v1/maintenance/{id}/validate-certificate — bate CNPJ na Receita e RT no conselhofinalizado, criar entrada em maintenance_schedule com due_date = today + 12 mesesDocumentos que o dev precisa ao lado.
Processo de Manutenção Recorrente v2.1 · 17/09/2026 — autoria Ray, revisão técnica Vinicius
API atual: https://api.sapron.com.br/api/v1/maintenance/ — hoje retorna 401 sem token
Tabela do lake que já resolve o gate 1: sirius.saprondata.listing_status — campos activation_date, churn, code (id_seazone)
Categoria de despesa conhecida: financial_expenses cat 2 (Enxoval), subcat 12 (REPOSIÇÃO), 13 (DANO). Mapear categorias de manutenção item a item
Filtro de água + caixa d'água (semestral vs revisão/troca) · Cadência de comunicação (canal, remetente, texto) · O que acontece depois do D+21 · Rateio e reembolso · Fechadura eletrônica · Troca de pilhas · Regulação estadual. Enquanto essas 7 não fecharem, itens 3 e 5 do check ficam parciais.
Achados complementares aos 7 gaps da seção 01. Aqui não há critério de aceite ainda — cada item tem botão ✦ Enviar ao Claude que abre uma conversa nova pra transformar o achado em desenho técnico (Sistema) ou rascunho de decisão de retro (Processo).
Reconhecidos no §11 do processo v2.1 como "onde o sistema ainda não acompanha", mais alguns achados novos.
Reconhecido no §11. Despesa lançada com o item da regra deveria fechar o card em minutos, não em varredura diária. Impacto: o report da sexta sempre mostra cards "presos" que já foram executados e pagos — falso gargalo. Sugestão técnica: trigger no financial_expenses (ou webhook) que casa despesa ↔ card aberto do mesmo item/imóvel/ciclo e move pra "Finalizado".
Antes de agente de visão computacional (§11), uma etapa intermediária mais barata: no upload, exigir tipo=conclusão|parcial, data_servico e cnpj_prestador. Faz 70% da conferência humana virar checklist e alimenta o gap 06 (validação de certificado).
Hoje qualquer arquivo (§6, "Atenção") joga o card na fila de aprovação, mesmo serviço pela metade. Consequência: Manutenção precisa devolver muita coisa que nunca deveria ter chegado. Sugestão: botão explícito "concluído" separado do upload — anexo sem esse clique fica em "Em execução".
§11 admite: "varredura roda o ano inteiro; contorno = pausar as regras em 01/12 e reativar em 01/04". Sem flag nativa isso vira exceção manual todo ano. Sugestão: campo maintenance_rule.freeze_window que bloqueia abertura e vencimento no intervalo definido.
Dupla verdade hoje: cadastro do Sapron (78% falso, §11) vs. anúncio do Airbnb (fonte real, §7.4). Deprecar o campo de amenities para manutenção recorrente ou sincronizar automático via data lake (listing_status) toda madrugada. Enquanto existirem duas fontes, indefinidos vão continuar aparecendo.
Hoje o report da sexta é montado fora do sistema. Faltam nativos: tempo médio abertura→evidência por franquia, tempo médio evidência→aprovação, % de ciclos concluídos por item. Sugestão: endpoint GET /api/v1/maintenance/metrics?franchise_id=&cycle=.
Senha de fechadura, pilhas, filtro de água, caixa d'água (§7.1) hoje somem porque não abrem card — não existe métrica de "eventos ignorados". Sugestão: contador leve no cadastro do imóvel (checkouts desde a última troca de senha, meses desde o último alerta de bateria). Sem card, mas visível.
Complemento do gap 05 da seção 01. Hoje o §9 diz que D+7 é lembrete automático do Sapron, mas D+14 (BackOffice aciona o gestor) e D+21 (Coordenação assume) dependem de alguém ver o report da sexta. Enquanto o processo não fecha a tratativa do D+21 (decisão 3), pelo menos os disparos de notificação nos buckets deviam ser nativos.
Cálculo rápido: 3 itens simultâneos em setembro (AC · filtro exaustor · filtro água) × ~1.100 imóveis pós-gate = ~3.300 cards abertos numa única segunda-feira. Pedido ao dev: confirmar se a UX de listagem (filtro, busca, paginação, permissões por franquia) e o backend aguentam esse pico antes do escalar. Se não, priorizar antes de setembro/2027.
Compartilhado com o dev só como contexto — enquanto essas decisões não fecharem, alguns gaps da seção 01 ficam parciais.
§11: "ninguém checou a exigência praça a praça". Risco jurídico latente pra Seazone, não pra franquia. Varredura por município nas cidades top-10 antes da próxima retro tira o processo do escuro.
Franquia que estoura prazo repetidamente hoje não gera ocorrência. Sem consequência real depois do D+21, a régua de atraso é cosmética. Retro decide: reincidência = ocorrência Média? Grave? Direta?
§9 diz "Coordenação assume o caso" — sem definir como. Liga, escala, reatribui, multa? Sem padrão, cada caso vira negociação. Bloqueio direto do gap 05 da seção 01.
BackOffice aciona o gestor no D+14, mas o processo não define quantos dias o gestor tem pra destravar. No D+21 ninguém sabe se ele foi omisso ou se estava tratando.
3 avisos por franqueado antes de abrir card faz sentido pra quem tem 30 imóveis. Quem tem 1-2 recebe spam. Vale testar: cadência única (só sábado) pra franquia com <5 imóveis e medir se atrasa mais.
§7.8: "segue o caminho de qualquer manutenção do imóvel". Mas isso não fecha o card automaticamente, porque a despesa não é de manutenção recorrente. Regra precisa ser explícita — hoje esse caso trava o gap S1 (agente de fechamento).
§7.4 aceita indefinido sem tratativa. Multiplicando por 10 itens do ano = ~700 pontos-cegos/ano. Retro decide: quem cura indefinido, em quanto tempo, com que fonte?
§10. Se Carol viaja e Ray está em call, ninguém age até segunda. Cópia pra Coordenação (dona das regras) + SLA de leitura resolvem sem custo.
Qual é a meta? % de ciclos completos no mês? Tempo médio? Sem número, "está indo bem" é opinião. Sugestão: definir 2 KPIs na próxima retro e ligar no hub de KPIs.
v1.4 · 25/09/2026 · Ray (BackOffice Franquias) · complemento técnico ao Processo de Manutenção Recorrente v2.1. · Seção 03 adicionada em 25/09 (análise de melhorias sistema × processo).