Atlas Passaporte: auditoria de produto, design e jornadas

Data: 28/09/2026. Ambiente: portal de desenvolvimento. Avaliação feita no Chrome, com navegação autenticada, telas públicas e inspeção do DOM renderizado.

Parecer

O Atlas tem peças úteis de operação, mas ainda não demonstrou uma jornada completa e confiável da base até a empresa publicada. Eu não liberaria escala de campo nem aquisição pública com a experiência observada. Primeiro, corrigiria os bloqueios da vistoria, da conferência do empresário e da publicação. Depois, construiria a experiência de descoberta e conversão.

Não se trata apenas de trocar cores ou melhorar espaçamento. O produto mistura portal institucional, ferramenta de campo, administração, anuário e vitrine. Cada parte usa conceitos e caminhos diferentes. O usuário precisa interpretar estados técnicos e descobrir como passar de uma etapa à próxima.

A tese do benchmark é boa: identidade local verificada, descoberta e geração de demanda. Hoje, a parte mais concreta está na coleta e conferência interna. A promessa pública ainda não aparece com a mesma força nas telas acessíveis.

O que impede o avanço

1. Ações essenciais ficam ilegíveis no celular. Na vistoria, os botões do rodapé têm 951,56 px de largura dentro de uma tela de 390 px. O texto fica fora da área visível. O rodapé ocupa cerca de 28% da altura útil.
2. Uma ficha acessada pelo pipeline não abre. Em DIVINO SABOR CASEIRO, o botão Ficha leva a uma mensagem de ficha não encontrada, com identificador técnico e sem recuperação.
3. O empresário não consegue explicar uma correção. O botão Corrigir informações enviou o pedido imediatamente. Não abriu formulário, seleção de campos ou revisão.
4. A publicação tem uma condição pouco clara. O anuário informa que a homologação não publica sozinha e depende do aceite do Assist. Isso não forma uma sequência compreensível para a operação e exige decisão de produto.
5. O destino público está fragmentado. A home apresenta o anuário como em construção. Existem /anuario-digital, /guia/santos e /vitrine/..., com experiências diferentes. Não encontrei uma jornada pública consistente entre elas.

O que deve ser preservado

Há histórico de alterações, sinais de procedência BASE/WEB/CAMPO, confirmação por bloco, GPS, evidência da visita, rascunho, opções para contatos inexistentes, hierarquia de usuários e permissões territoriais na interface. A home respeita a preferência de movimento reduzido nas animações CSS examinadas. Há link para pular ao conteúdo na área interna.

Esses recursos são bases úteis. A presença na interface não comprova persistência correta, isolamento de acesso, funcionamento offline ou validade do aceite.

Fontes e limite da evidência

Os falantes da transcrição principal aparecem em vários trechos como Participant 1, 2 e 3. Não atribuí falas individuais a Paulo ou Mauro com base apenas nesses rótulos. Os tempos citados abaixo são aproximados, desde o início da gravação.

O workspace continha o benchmark e configuração de memória, sem código da aplicação ou repositório Git utilizável. Portanto, esta é uma auditoria do produto em execução. Não há parecer sobre componentes, APIs, tabelas, migrations, testes, CI/CD ou segurança do backend. O mapa técnico separa superfícies observadas de hipóteses a verificar.

As telas móveis foram testadas por viewport no Chrome: 390 × 844 e 768 × 1024. Isso não substitui Safari no iPhone, teclado virtual, câmera, GPS real, conectividade de rua e leitores de tela. Não executei Lighthouse nem medi Core Web Vitals. Não confirmei todos os ramos de gravação, publicação ou envio externo.

Os números de audiência e empresas do Listamais são declarações reproduzidas no benchmark. Não foram verificados nesta sessão. A avaliação não depende desses números.

O que as reuniões realmente pedem

Avaliação das jornadas

Gestor: base, território, equipe e rota

O gestor entra em Minha Rota vazia. Esse é um início fraco para quem precisa preparar a operação. A primeira tela deveria mostrar o que impede a equipe de trabalhar: base a revisar, rotas sem responsável, visitas em atraso, correções e empresas prontas para publicação.

Na criação de rota, a seleção por cidade e caderno é um começo. Em Santos, apareceram 2.012 empresas elegíveis. A interface exibiu registros como **** e nomes cadastrais pouco úteis para uma visita. Faltam sinais de qualidade e uma representação territorial clara. Não há mapa, estimativa de carga diária ou ordenação por proximidade na superfície examinada.

O assistente pede seleção de empresas, nome e operador. O texto menciona um ou mais consultores, mas o controle final é singular. Tentar avançar sem empresas não apresentou orientação visível. A etapa final não ofereceu um resumo completo de território, quantidade, responsável e carga antes da gravação.

A tela Equipes pede chave da rua e ID do membro. Isso revela uma interface de administração técnica exposta como ferramenta de operação. Substituir por seletores pesquisáveis de território, rota e pessoa. Resolver também a sobreposição entre Equipes, Usuários e Gestão de rotas.

Jornada proposta: revisar qualidade da base → delimitar território → selecionar empresas → estimar carga → atribuir responsável → conferir resumo → publicar rota para o consultor. A operação deve explicar o que aconteceu com empresas já atribuídas, fechadas, duplicadas ou sem endereço.

Consultor: visita e coleta

A ficha examinada tem 35 campos de entrada ou seleção, 86 botões e altura de 6.868 px no desktop. No viewport móvel, chega a 9.733 px. As quantidades descrevem a tela, não o número de ações obrigatórias. Ainda assim, evidenciam custo de navegação e excesso de decisões concorrentes.

O título Novo estabelecimento aparece em uma empresa já nomeada. O texto diz que não há dados pré-carregados, embora existam dados. Isso compromete a compreensão sobre atualizar uma empresa ou criar outra.

As confirmações se acumulam: confirmar cada contato, confirmar o bloco, confirmar classificações, resolver checklist e aceitar declaração. A confirmação BASE/WEB em lote pode incentivar aprovação automática de dados ainda não conferidos. Não se deve transformar procedência em sinônimo de verdade.

Jornada proposta em cinco blocos:

1. Chegada: empresa, endereço, status do ponto e localização. Confirmar visita iniciada após ação clara. Abrir a ficha remotamente não comprova presença.
2. Identidade e endereço: apresentar dados existentes e diferenças. Editar apenas o necessário.
3. Contato e funcionamento: telefone, WhatsApp, redes existentes, horários e responsável. Usar Não possui e Não foi possível confirmar como estados distintos.
4. Classificação e evidências: buscar atividade em linguagem comum, sugerir caderno, coletar fachada e materiais com indicação de progresso.
5. Revisão e conclusão: resumir mudanças e pendências, registrar responsabilidade e check-out, finalizar com próximo passo explícito.

Manter uma ação principal por etapa. Rascunho deve indicar salvo localmente, sincronizando, salvo no servidor ou falha. O formulário deve permitir retorno sem perda e sem exigir reconfirmação de campos que não mudaram.

Correção imediata: arrumar o rodapé antes de redesenhar o fluxo inteiro. O botão primário precisa caber, mostrar seu texto e continuar acessível com teclado aberto. O painel de pendências deve recolher e levar ao campo correto.

Vistoria móvel com rodapé desproporcional e ações sem texto visível

Empresário: conferir, corrigir e autorizar

A conferência tem uma boa intenção: mostrar o que será publicado. Porém, o resumo observado privilegia identidade, endereço e categorias. Contatos e horários não apareceram no conjunto examinado. É preciso garantir correspondência entre a versão mostrada e o conteúdo que será publicado.

O defeito mais grave está em Corrigir informações. O clique enviou uma solicitação sem permitir apontar o erro. A mensagem de sucesso afirma que a equipe revisará os pontos apontados, mas nenhum ponto foi coletado. Durante a requisição, os dois botões exibiram mensagens de carregamento diferentes, como se ambos os caminhos estivessem em execução.

Jornada proposta: abrir link válido → identificar estabelecimento e responsável → ver versão completa com data → escolher campos a corrigir ou conferir todos os dados → revisar o pedido → enviar. A operação recebe os campos, motivo, autor e versão. Após corrigir, reenvia uma nova versão. O aceite anterior não deve aprovar silenciosamente dados alterados.

O aceite deve separar conferência cadastral, publicação digital e eventual contratação ou presença no impresso. O texto e a regra de autorização exigem definição de negócio e revisão jurídica própria. Esta auditoria não certifica validade jurídica.

Operação: filas, exceções e publicação

O pipeline mostrava 2.554 clientes: 2.546 pendentes, seis em visita e dois em verificação, antes do teste de correção. Foram renderizados 258 cartões, sendo 250 da coluna pendente. Não apareceu paginação evidente na inspeção. A diferença exige explicar limite e continuidade; não prova perda de registros.

O cartão oferece Briefing IA, Ficha e Excluir com forte concorrência visual. A ação principal deveria representar o próximo passo da empresa. Excluir deve ficar em menu de ações secundárias, com regra de proteção e recuperação a validar.

Faltam filtros visíveis por responsável, idade da pendência e motivo de bloqueio. Sem isso, o pipeline descreve estoque, mas ajuda pouco a concluir o trabalho.

Separar três estados: visita concluída, dados autorizados e perfil publicado. Uma empresa pode ter uma visita concluída e ainda aguardar correção. Um perfil pode estar publicado no digital e não participar de uma edição impressa. A condição do Assist precisa ser explicitada ou retirada conforme decisão de produto.

Consumidor: encontrar, escolher e entrar em contato

A home funciona como vitrine genérica do ecossistema Atlas. A primeira tela não oferece busca de empresas ou escolha de cidade. No celular, o emblema ocupa boa parte do primeiro viewport. O usuário chega ao valor prático depois do elemento decorativo.

O anuário público está vazio no ambiente. Isso é um estado de dados, não prova de defeito. A experiência de vazio, porém, não orienta suficientemente o visitante. O caminho /guia/santos oferece cadastro da empresa; /anuario-digital usa outra apresentação. A home ainda encaminha o anuário para uma página em construção.

A vitrine Teste abriu, mas mostrou apenas nome, endereço, categoria e atributos. Não apareceram ações de contato, rota, horário, galeria, avaliações ou reivindicação do perfil. Como o registro tem poucos dados, isso não comprova ausência global de cada recurso. Comprova que a experiência acessível não demonstra a proposta de conversão.

Jornada proposta: escolher cidade → buscar necessidade ou categoria → comparar resultados → abrir perfil → conferir horário, distância e confiabilidade → ligar, conversar ou traçar rota. Priorizar essas ações antes de favoritos, cupons e recomendações por IA.

Empresário: manter o perfil e perceber valor

A personalização examinada oferece três cores e URL de vídeo. É uma camada estética pequena para a proposta de presença digital. O empresário precisa atualizar contatos, horários, descrição e fotos; visualizar a página; compreender o status de verificação; e acompanhar ações recebidas.

O cadastro público existe e valida a ausência de CNPJ e razão social na primeira etapa. Não concluí o cadastro nem testei os ramos seguintes. Não encontrei, nas superfícies examinadas, uma jornada clara de Sou responsável por esta empresa com prova de vínculo e tratamento de disputas.

Direção de design e UI

Identidade visual e hierarquia

Preservar os elementos reconhecíveis da marca, mas reduzir sua ocupação nas tarefas. Azul profundo e dourado podem permanecer. O dourado precisa representar ação principal ou identidade, sem competir com cada legenda e detalhe. Cores de status devem ter semântica própria, acompanhadas de texto.

Separar três contextos visuais: institucional, operação e experiência pública. Compartilhar tipografia, componentes e vocabulário. Na operação, usar superfícies planas e previsíveis. Fundo espacial, brilhos e grandes emblemas têm pouco valor durante uma visita sob luz externa.

Não é necessário impor tema claro a toda a marca. É necessário testar legibilidade em rua e oferecer contraste suficiente nas superfícies de trabalho. A decisão entre tema claro, escuro ou seleção de tema deve vir de teste com consultores.

Tipografia, densidade e componentes

A home usa Sora nos títulos, com H1 de 53,6 px no desktop observado. Na ficha, há textos auxiliares entre 11,2 e 12,8 px. O tamanho pequeno, a densidade e o uso recorrente de caixa alta dificultam leitura rápida.

Como ponto de partida de design, usar corpo de 16 px em formulários móveis, rótulos de 14 a 16 px e textos auxiliares de 13 a 14 px. Validar zoom e preferências do sistema. Esses valores são proposta de projeto, não uma exigência universal da WCAG.

Criar componentes compartilhados para campo com procedência, estado de salvamento, pendência acionável, seletor de atividade, cartão de empresa, mapa/endereço, upload, resumo de autorização e estado vazio. Manter unidades consistentes de espaço e uma hierarquia clara entre ação primária, secundária e destrutiva.

O nome do arquivo de evidência tem texto preto sobre fundo rgb(13,27,46). A razão calculada é aproximadamente 1,21:1, abaixo do mínimo de 4,5:1 para texto comum. Isso foi medido nesse elemento, não extrapolado para a aplicação inteira. Referência: WCAG, contraste mínimo.

Acessibilidade e responsividade

Há checklist com alvos de cerca de 29 px de altura e botão de menu próximo de 34 × 30 px. Para campo, recomendo controles principais de 44 a 48 px e espaço entre ações. A WCAG 2.2 AA usa mínimo de 24 CSS px com exceções, não 44 px para todo controle. Referência: WCAG, tamanho mínimo de alvo.

Verificar rótulos programáticos, foco visível, navegação por teclado, retorno de foco de modais, leitura de erros, estados anunciados e ordem de tabulação. Atributos representados só por ícones precisam de texto também no toque. Não depender de hover.

A ficha não mostrou rolagem horizontal do documento em 390 px. Mesmo assim, seus botões internos ultrapassaram a tela. Testar apenas scrollWidth não detecta toda quebra responsiva. A aceitação exige verificar os controles e executar a tarefa.

Transições e animações

As animações examinadas na home incluem entrada de conteúdo de 800 ms, entrada visual de 1 s, pulsação de 3,5 s e flutuação de 4 s. Links e cartões usam transições de 200 a 250 ms. O movimento reforça a cenografia, mas não ajuda a compreender a jornada.

Com prefers-reduced-motion: reduce, as animações CSS de conteúdo foram reduzidas a 0,00001 s e uma iteração. A pulsação do logotipo deixou de aparecer na lista de animações. Este comportamento deve ser preservado. Referência de implementação: web.dev, prefers-reduced-motion.

Não há evidência de que a aplicação precise de mais animações. Precisa de feedback de estado e continuidade entre telas. As durações propostas são parâmetros iniciais, sujeitos a teste.

Funcionalidades: o que evoluir e em qual ordem

Fundação operacional

Identidade única de empresa e estabelecimento; deduplicação assistida; base com qualidade; catálogo governado; atribuição territorial; rota verificável; ficha móvel; salvamento e sincronização; evidências; correção por campo; autorização por versão; publicação observável. Esses itens sustentam a promessa de dado verificado.

Não confundir CNPJ, estabelecimento físico, ficha de visita, perfil público e participante da edição. O vínculo errado entre essas entidades pode explicar erros de ficha, mas essa causa ainda precisa de código e API para ser confirmada.

Valor público mínimo

Busca por cidade, categoria, nome e bairro; perfil completo; contatos acionáveis; mapa/rota; horários; selo explicável; data de atualização; QR estável; cadastro/reivindicação; SEO por entidade; eventos básicos de conversão. Um perfil gratuito precisa ser útil, conforme a tese do benchmark.

Selo de verificação deve informar o que foi verificado e quando. Pagamento por destaque não pode comprar veracidade. Separar visibilidade comercial de confiança cadastral.

Monetização e impresso

Consolidar planos. A ficha usa Gratuito, Destaque QR e VIP. A FAQ menciona Índice, VIP e Prime. O benchmark propõe Free, Verificado, Pro e Growth. São três taxonomias diferentes, sem evidência de aprovação da terceira.

Para o impresso, definir edição, cidade, fechamento, prova de arte, capacidade, reservas, formato, cancelamento e reimpressão. O QR deve continuar apontando para o perfil vivo após o fechamento. A arte aprovada da edição precisa permanecer congelada e rastreável.

Só vender inventário de destaque quando houver regra de capacidade e entrega verificável. Leads e orçamentos exigem distribuição, consentimento, prazo, prevenção de duplicidade e medição de resposta. Não basta acrescentar um botão de orçamento.

IA depois da confiabilidade

Há ações e configurações de IA na interface. Não gerei novos briefings nem validei custo, precisão ou persistência. Priorizar assistência à coleta: sugerir classificação, extrair cartão/material e apresentar diferenças com fonte. A confirmação humana deve preceder qualquer alteração de dado validado.

Busca semântica, concierge e motor de oportunidades entram depois de catálogo, horários, localização e eventos confiáveis. Sem esses dados, a IA apenas torna a inconsistência mais difícil de perceber.

Avaliar precisão por campo, cobertura, custo por perfil e taxa de correções. Não usar uma confiança agregada para esconder erro em telefone ou endereço.

Plano de execução recomendado

As etapas não têm prazo estimado aqui. O código, a equipe e as dependências ainda não foram inspecionados. A matriz de evolução contém prioridade, impacto, esforço relativo, dependências e critérios de aceite por item.

Decisões necessárias antes de fechar o backlog

Como comprovar a evolução

Medir o funil base elegível → atribuída → visitada → coleta completa → enviada ao empresário → corrigida/autorizada → publicada → acionada pelo consumidor. Cada evento precisa de identificador estável, ator, data e versão. Não registrar conteúdo sensível desnecessário na telemetria.

Usar mediana e percentil 90 do tempo de visita; abandono por etapa; campos reconfirmados; retrabalho; falha de upload; recuperação de rascunho; tempo até autorização; tempo até publicação; perfil sem contato; e idade da última verificação. Os valores atuais não foram medidos.

A métrica de conexões qualificadas do benchmark precisa de definição. Clique em WhatsApp, telefone ou rota é intenção de contato. Não comprova conversa, lead qualificado ou venda. Separar clique, contato confirmado e resultado comercial.

O roteiro de aceite deve incluir empresa da base, cadastro novo e CNPJ já existente; estabelecimento fechado; contato inexistente; GPS negado; foto interrompida; sessão expirada; rascunho offline; duas pessoas editando; empresário pedindo correção; link vencido; alteração após aceite; publicação e retirada; QR de edição antiga; e usuário fora do território autorizado. Esses cenários estão detalhados no mapa técnico e não foram todos executados.

Registro de ações da auditoria

Não houve implementação, deploy, criação de usuário, nova rota, aprovação de dados, aceite de termos ou publicação realizada por mim. O formulário de rota foi fechado sem salvar. Não usei os botões de declaração de presença ou confirmação do empresário.

Ocorreram duas alterações no ambiente de teste durante a exploração:

1. Massas Veneza: ao clicar em Corrigir informações para inspecionar o fluxo, a aplicação registrou imediatamente um pedido de correção. O comportamento foi informado durante a sessão. Não confirmei entrega de notificação externa e não reverti o pedido por meio de uma aprovação artificial.
2. Importação: Iniciar importação criou um job concluído com zero linhas, sem escolha de arquivo. Não importei base ou arquivo. A resposta de sucesso sem conteúdo é um achado de UX. Job observado: 5817d9e6-dd8f-47ce-ae36-fda2e05155bf.

As capturas 09 e 13 registram esses resultados. As alterações de viewport e preferência de movimento usadas no teste foram restauradas. Não foram feitas mudanças de configuração do produto.

ATLAS PASSAPORTE: especificação para evolução

Versão 1.0, 28/09/2026. Destinatário: time de tecnologia Mosten. Base: auditoria do portal de desenvolvimento, reuniões de 23 e 24/09 e benchmark fornecido. Este é um documento de refinamento e execução por entregas. As estimativas e soluções propostas ainda precisam de confronto com o código real.

Resultado esperado

Permitir que o gestor prepare uma rota, o consultor conclua uma visita sem perder dados, o empresário corrija ou autorize uma versão e a operação publique o conteúdo correto. Em seguida, permitir que o consumidor encontre a empresa e execute uma ação de contato útil.

Não implementar os 46 itens como um único projeto fechado. Corrigir os bloqueios comprovados, fechar as decisões de negócio, testar o percurso completo e liberar as ondas seguintes por critério de saída. P3 é descoberta futura, não compromisso de implementação.

Autoridade das fontes

1. O comportamento observado sustenta os defeitos reproduzidos.
2. As reuniões registram necessidades e propostas. Não substituem aprovação de todas as regras discutidas.
3. O benchmark orienta oportunidade e produto futuro. Não é contrato comercial.
4. Esta especificação propõe solução e ordem. Não afirma conhecer código, API ou banco que não foram inspecionados.

O workspace contém o estudo, não o código da aplicação. Arquivos e funções do Atlas devem ser localizados antes de abrir tarefas de código. Os nomes C01-C12 são contratos conceituais propostos, descritos em contratos e decisões. Não criar endpoints novos se os existentes puderem atender com uma alteração focada.

Priorização por esforço e ganho

O índice serve para comparar candidatos. Não mede ROI financeiro, probabilidade estatística nem dias de trabalho.

Índice = (2 × ganho + redução de risco) × confiança / esforço.

Os pontos são relativos a esta carteira e ainda não foram calibrados pela equipe. Não são story points históricos do time. Não converter nem somar em dias ou orçamento. Item de 13 pontos precisa de decomposição e investigação antes de entrar em uma iteração.

A ordem efetiva considera: dependências → onda → bloqueadores P0 dentro da onda → índice decrescente → ID como desempate. Uma dependência sempre precede o item dependente. A fila é reproduzida por scripts/build_specs.py. Itens independentes podem avançar em paralelo se houver capacidade. A ordem não representa atribuição de pessoas ou datas.

P0 mantém o bloqueio da auditoria original. P1 entrega consistência e valor público mínimo. P2 evolui qualidade, receita e escala. P3 testa hipóteses de inteligência. A42 permanece P2 na matriz histórica, mas sua verificação foi antecipada à onda 1 por ser requisito de exposição em produção. Se revelar falha de acesso ou segredo exposto, o defeito confirmado vira P0.

Ondas e ganhos

Critérios de prontidão por item

• Localizar arquivos, componentes, API e persistência envolvidos. Registrar caminhos reais no ticket.
• Reproduzir o problema ou criar cenário controlado quando for evolução.
• Identificar dono de produto e responsável técnico. João e Elias são destinatários do estudo, não responsáveis automaticamente atribuídos a cada item.
• Fechar decisões de negócio que afetam o item, sem interromper correções independentes.
• Refinar esforço conforme código, testes existentes e dependências externas.
• Delimitar alteração e regressões necessárias. Não incluir refatoração sem relação com o aceite.

Padrão de implementação

Para bug, escrever ou ajustar teste que demonstre o defeito quando isso trouxer proteção real. Aplicar a menor mudança que cumpra o contrato. Rodar verificações da entrega e regressões atingidas. Para ajuste puramente visual, usar prova visual e interação em viewport/aparelho relevante; não escrever teste que apenas repete valores CSS.

Não adotar framework, banco, fila ou microsserviço novo por causa deste documento. Preservar padrões adequados do repositório real. Para contrato existente, preferir extensão compatível e migração explícita a uma segunda implementação paralela.

Protocolo de implantação e reversão

1. Registrar versão base, migrações e dados afetados.
2. Separar alteração visual de mudança de regra quando isso facilitar a reversão.
3. Validar em ambiente de teste com empresas controladas e usuários por papel.
4. Se houver migração, conferir contagem, vínculos e amostra de registros antes/depois. Preparar recuperação testada.
5. Implantar com mecanismo de reversão adequado ao sistema existente. Não exigir feature flag nova para toda mudança pequena.
6. Verificar cenário crítico na versão implantada e acompanhar erros e indicadores definidos.
7. Reverter ou suspender a função se houver perda de dados, acesso indevido ou publicação de versão incorreta. Não executar rollback cego de banco após novas escritas.

Definição de pronto

O ticket contém evidência inicial, decisão de regra, alteração focada, teste de aceite, cenário negativo, regressão relevante e prova da versão implantada. A prova visual não substitui a persistência quando há gravação. CI verde, deploy concluído e aceite humano são estados distintos. Funcionalidade só entra como concluída após cumprir seu contrato de saída.

Decisões e medição

O ganho descrito em cada item é esperado. Nenhuma redução percentual de tempo, aumento de conversão ou retorno financeiro foi demonstrado neste estudo. Coletar baseline antes da mudança sempre que possível. Comparar cenário e população equivalentes depois da implantação.

Fonte detalhada: auditoria, matriz original, evidências, mapa técnico, contratos propostos e plano de validação.

Ordem sugerida de refinamento e execução

Especificação por entrega

A01: Ações móveis da vistoria

Prioridade: P0. Onda: 1. Ordem sugerida: 1. Complexidade: Baixa. Esforço: 2 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 90%. Índice: 6.75.

Evidência atual: R. Ações da vistoria ilegíveis em 390 px. Botões de 951,56 px, deslocados para fora da tela. E05/E06

Resultado esperado: Corrigir largura, alinhamento, quebra de texto e rodapé. Recolher pendências.

Ganho a acompanhar: Conclusão da vistoria sem assistência para localizar botões. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Mudança localizada, com baixa coordenação entre camadas.

Responsabilidade sugerida: Frontend + design / S-M / nenhuma

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: Contrato de layout: largura do controle não excede viewport menos margens, texto completo e alvo de 44 px. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A01.1: Remover largura mínima indevida e alinhar botões ao contêiner.
• [ ] A01.2: Reorganizar checklist recolhível com acesso direto à pendência.
• [ ] A01.3: Reservar área para rodapé e teclado sem cobrir o campo ativo.

Aceite funcional: Salvar e finalizar têm rótulo visível em 320, 360, 390, 768 px; rodapé não cobre campo focado; repetir com teclado real.

Cenário negativo obrigatório: Rótulo longo, zoom de 200% e teclado aberto não podem ocultar a ação.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não alterar regras de conclusão ou criar nova etapa de negócio.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A02: Abertura e vínculo de ficha

Prioridade: P0. Onda: 1. Ordem sugerida: 2. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 90%. Índice: 2.70.

Evidência atual: R. Ficha indisponível ao abrir cliente da base. DIVINO SABOR CASEIRO. E03

Resultado esperado: Investigar vínculo cliente/ficha. Criar ou abrir a ficha correta. Oferecer recuperação e mensagem útil.

Ganho a acompanhar: Redução de falhas de abertura e de cadastros duplicados. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Backend + frontend / M / acesso a código e dados

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: C01 AbrirFicha: estabelecimentoId, visitaId opcional e contexto do ator; retorno fichaId, versão e estado. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A02.1: Mapear identificadores de cliente, estabelecimento e visita no clique Ficha.
• [ ] A02.2: Resolver ficha existente ou iniciar visita por operação idempotente autorizada.
• [ ] A02.3: Criar estado de erro com voltar e tentar novamente, sem UUID como explicação principal.

Aceite funcional: Base sem ficha, ficha existente e cadastro in loco abrem o registro correto; nenhuma criação duplicada ao repetir ação.

Cenário negativo obrigatório: Duplo clique ou abertura simultânea não cria empresa/ficha duplicada; sem permissão não revela dados.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não unificar tabelas ou migrar todos os clientes sem diagnóstico.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A03: Correção por campo pelo empresário

Prioridade: P0. Onda: 1. Ordem sugerida: 3. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 90%. Índice: 2.70.

Evidência atual: R. Corrigir informações envia sem coletar motivo. Massas Veneza. E08/E09

Resultado esperado: Abrir seleção de campos e justificativa. Enviar apenas após revisão explícita.

Ganho a acompanhar: Pedidos acionáveis e menos retorno por falta de contexto. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + frontend + backend / M / contrato de correção

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: C02 SolicitarCorrecao: revisão, campos permitidos, justificativa, ator e chave de idempotência. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A03.1: Separar ação de abrir revisão da ação de enviar pedido.
• [ ] A03.2: Coletar campos, motivo e resumo antes do envio.
• [ ] A03.3: Persistir pedido e criar fila vinculada à versão com resposta ao empresário.

Aceite funcional: Cancelar não altera estado; pedido inclui campos, motivo, versão e autor; aparece na fila; reenvio preserva histórico.

Cenário negativo obrigatório: Cancelar não escreve; repetição não duplica; revisão antiga exige atualização antes de enviar.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não aprovar dados nem disparar correção ao abrir a tela.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A04: Elegibilidade e publicação explícitas

Prioridade: P0. Onda: 1. Ordem sugerida: 5. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 70%. Índice: 1.31.

Evidência atual: V/I. Publicação depende de aceite do Assist, sem sequência clara. Anuário vazio e texto da tela. E11

Resultado esperado: Definir pré-requisitos e expor estado, bloqueio e próxima ação. Validar necessidade da dependência.

Ganho a acompanhar: Menor tempo entre autorização e publicação e menos intervenção técnica. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Produto + operação + backend / L / decisão de publicação

Dependências técnicas entre itens: A05

Dados e contrato proposto: C03 AvaliarPublicacao e PublicarVersao: versão autorizada, status e bloqueios tipados. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A04.1: Formalizar a função de elegibilidade com códigos de bloqueio.
• [ ] A04.2: Exibir requisito faltante, responsável e ação possível.
• [ ] A04.3: Separar publicação digital de fechamento do impresso e registrar transição.

Aceite funcional: Uma empresa percorre coleta, correção, autorização e publicação. Operação explica todo bloqueio. Não publica versão não autorizada.

Cenário negativo obrigatório: Mudança concorrente ou revogação entre prévia e publicação impede publicar versão divergente.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não remover condição do Assist sem decisão D03.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A05: Autorização vinculada à versão

Prioridade: P0. Onda: 1. Ordem sugerida: 4. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 70%. Índice: 1.31.

Evidência atual: V/I. Conferência inicial não evidencia versão e escopo completo. Contatos/horários não apareceram na amostra. E08

Resultado esperado: Mostrar conteúdo publicável integral, versão, responsável e escopo de autorização. Auditar tokens.

Ganho a acompanhar: Rastreabilidade entre o que foi visto, autorizado e publicado. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Produto + backend / L / definição de aceite; revisão jurídica própria

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: C04 AutorizarVersao e RevisaoPublicavel; política D02 define validade e campos sensíveis. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A05.1: Versionar o conjunto publicável e mostrar prévia integral.
• [ ] A05.2: Persistir autorização com escopo, ator, data e referência da versão.
• [ ] A05.3: Revogar ou pedir nova autorização quando mudar campo sensível conforme política.

Aceite funcional: Mudança após autorização invalida ou exige nova autorização conforme regra; links vencidos/reutilizados seguem contrato; registro exportável identifica versão e escopo.

Cenário negativo obrigatório: Link vencido, token revogado, responsável sem vínculo e versão superada não autorizam.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não afirmar validade jurídica do mecanismo sem revisão responsável.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A06: Rascunho e sincronização recuperáveis

Prioridade: P0. Onda: 1. Ordem sugerida: 7. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 50%. Índice: 0.58.

Evidência atual: I. Offline, persistência e retomada sem prova atual. Rascunho existe; reunião descreve offline.

Resultado esperado: Testar e instrumentar armazenamento local, sincronização, sessão e conflitos antes de operação em rua.

Ganho a acompanhar: Menos perda de coleta e menor retrabalho após instabilidade. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Engenharia + QA / L / aparelhos e dados controlados

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: C05 SalvarRascunho: revisão base, sequência local, operações e chaves de anexos. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A06.1: Diagnosticar armazenamento atual e garantir fila local por usuário/estabelecimento.
• [ ] A06.2: Implementar confirmação de persistência, reenvio idempotente e conflitos.
• [ ] A06.3: Recuperar rascunho após interrupção, sem misturar contas.

Aceite funcional: Modo avião, fechamento do app, reconexão e upload interrompido não perdem dados; estado salvo distingue local/servidor; conflito não sobrescreve silenciosamente.

Cenário negativo obrigatório: Rede cai durante salvamento; logout troca usuário; servidor recebe revisão concorrente.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não prometer funcionamento completo offline de recursos que dependem de terceiros.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A07: Escopo territorial e autorização

Prioridade: P0. Onda: 1. Ordem sugerida: 6. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 50%. Índice: 0.94.

Evidência atual: V/I. Nenhuma cidade selecionada significa acesso amplo no cadastro de usuário. Não é prova de falha de autorização.

Resultado esperado: Tornar abrangência explícita; preferir escopo restrito por padrão; verificar enforcement no servidor.

Ganho a acompanhar: Menor risco de acesso indevido e menos ambiguidade administrativa. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Segurança + backend + produto / M-L / contas de teste

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: C06 EscopoEfetivo: papel, territórios explícitos, herdados e exceções autorizadas. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A07.1: Mapear papéis, herança e territórios com negação por padrão quando a regra exigir.
• [ ] A07.2: Centralizar checagem no servidor em leitura, escrita, exportação e anexos.
• [ ] A07.3: Tornar concessão ampla explícita no cadastro e na revisão de usuário.

Aceite funcional: Matriz admin/líder/membro e dois territórios bloqueia leitura/escrita fora do escopo inclusive por URL/API direta; criação exige ciência do escopo amplo.

Cenário negativo obrigatório: URL direta, ID de outro território e link de anexo não contornam autorização.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não criar novos papéis ou ampliar acesso de contas existentes.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A08: Aceite em iPhone e Android

Prioridade: P0. Onda: 1. Ordem sugerida: 8. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 70%. Índice: 2.10.

Evidência atual: I. Compatibilidade real de campo pendente. Reunião cita iOS; auditoria atual usa Chrome com viewport.

Resultado esperado: Executar roteiro em Safari iPhone e Chrome Android com câmera, localização, teclado e rede instável.

Ganho a acompanhar: Confiança para piloto de rua e redução de falhas específicas de plataforma. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: QA + operação / M / aparelhos e A01-A06

Dependências técnicas entre itens: A01, A02, A03, A06, A07

Dados e contrato proposto: Matriz de execução com versão do build e ID dos casos, sem usar dados pessoais reais. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A08.1: Preparar contas e empresas descartáveis com roteiro comum.
• [ ] A08.2: Executar câmera, GPS, teclado, rolagem, offline e retomada em aparelhos físicos.
• [ ] A08.3: Registrar aparelho, navegador, passos, vídeo/captura e resultado persistido.

Aceite funcional: Jornada concluída e retomada nos dois sistemas; negativa de permissões tem alternativa; GPS não é criado por mera abertura remota da ficha.

Cenário negativo obrigatório: Negação de permissões e mudança de orientação devem manter progresso.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Emulação de viewport não conta como aprovação em aparelho real.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A09: Vistoria por etapas de trabalho

Prioridade: P1. Onda: 2. Ordem sugerida: 21. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 3/5. Confiança: 70%. Índice: 1.14.

Evidência atual: V. Ficha longa e confirmações concorrentes. 35 campos, 86 botões, 9.733 px móveis. E04-E07

Resultado esperado: Dividir por etapas de trabalho; confirmar diferenças; resumo final; evitar confirmação cega BASE/WEB.

Ganho a acompanhar: Menor tempo mediano/p90 e menos confirmações sem leitura. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Design + frontend + operação / L / A01 e regras de validação

Dependências técnicas entre itens: A01, A02, A03

Dados e contrato proposto: C05 com estado da etapa e C04 com revisão final; política de obrigatoriedade por situação. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A09.1: Agrupar chegada, identidade, contato, classificação e revisão.
• [ ] A09.2: Preservar valores e confirmação de campos intactos entre etapas.
• [ ] A09.3: Transformar checklist em navegação para pendências e mostrar mudanças no resumo.

Aceite funcional: Consultor encontra pendência e retoma etapa sem reconfirmar dados intactos; medir tempo e retrabalho contra baseline.

Cenário negativo obrigatório: Voltar, recarregar ou pedir ajuda não desfaz dados confirmados; ponto fechado usa ramo próprio.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não reduzir controles exigidos pelo negócio apenas para encurtar formulário.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A10: Distinguir cadastro, empresa e visita

Prioridade: P1. Onda: 2. Ordem sugerida: 11. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 90%. Índice: 2.16.

Evidência atual: R/V. Novo estabelecimento descreve registro já preenchido. E04

Resultado esperado: Distinguir empresa da base, nova empresa, nova visita e edição.

Ganho a acompanhar: Menos duplicidade e maior compreensão da tarefa. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + frontend + backend / M / identidade única

Dependências técnicas entre itens: A02

Dados e contrato proposto: Empresa, estabelecimento e visita têm identificadores distintos; C01 resolve contexto. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A10.1: Definir estados novo estabelecimento, empresa da base, visita e edição.
• [ ] A10.2: Consultar correspondência antes de criar por CNPJ.
• [ ] A10.3: Ajustar títulos e ações para origem real e vínculo correto.

Aceite funcional: Título, explicação e ação final refletem origem; CNPJ existente leva à empresa certa, sem duplicar.

Cenário negativo obrigatório: Mesmo CNPJ com mais de um ponto exige decisão explícita; não fundir por nome parecido.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não presumir que CNPJ sozinho modela todo ponto físico.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A11: Catálogo de atividades governado

Prioridade: P1. Onda: 2. Ordem sugerida: 17. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 4/5. Confiança: 70%. Índice: 1.22.

Evidência atual: V. Catálogo desalinhado. 27 cadernos, 21 nichos, atividade geral e nicho Oi. Reunião pede catálogo completo.

Resultado esperado: Definir taxonomia oficial, limpar testes, importar versão validada e mapear registros legados.

Ganho a acompanhar: Maior precisão de classificação e busca pública. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Operação de dados + produto / L / fonte oficial do catálogo

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: CatalogoVersao com códigos estáveis, rótulos, relações, vigência e mapeamento anterior. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A11.1: Escolher fonte e versão oficial de cadernos, nichos, atividades e atributos.
• [ ] A11.2: Construir busca e validação com relações permitidas.
• [ ] A11.3: Executar migração revisada com relatório de órfãos e valores legados.

Aceite funcional: Atividade válida e pesquisável; caderno/nicho coerentes; migração não perde dados; relatório de órfãos e duplicatas revisado.

Cenário negativo obrigatório: Atividade removida preserva histórico; importação não apaga classificação válida sem mapeamento.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não tratar diferença de contagem como defeito sem validar a fonte.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A12: Horários estruturados

Prioridade: P1. Onda: 2. Ordem sugerida: 12. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 90%. Índice: 1.98.

Evidência atual: V. Horários em presets/texto livre.

Resultado esperado: Editor por dia, intervalos, fechado, 24 horas e exceções. Manter campo de observação.

Ganho a acompanhar: Menos informação ambígua e buscas por funcionamento confiáveis. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + frontend + backend / M / modelo de horário

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: HorarioSemanal, ExcecaoData e timezone IANA; campos desconhecidos são explícitos. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A12.1: Modelar dias e múltiplos intervalos com fuso.
• [ ] A12.2: Criar editor de fechado, 24 horas e exceções por data.
• [ ] A12.3: Derivar apresentação pública e aberto agora do mesmo contrato.

Aceite funcional: Aberto agora usa fuso e exceções; horário de almoço e período que atravessa meia-noite têm teste.

Cenário negativo obrigatório: Intervalo atravessa meia-noite, feriado e horário desconhecido não viram aberto por padrão.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não extrair texto antigo por IA e publicar sem confirmação.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A13: Rotas com resumo e vínculo confiável

Prioridade: P1. Onda: 2. Ordem sugerida: 18. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 4/5. Confiança: 70%. Índice: 1.22.

Evidência atual: V. Assistente de rota não mostra carga e resumo adequados. 2.012 candidatos; seleção vazia sem orientação visível. E01

Resultado esperado: Validar cada etapa, reconciliar um/vários responsáveis, resumir seleção e avisar alocações existentes.

Ganho a acompanhar: Mais rotas concluídas sem retrabalho e vínculos ausentes. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Frontend + backend / M / contrato de atribuição

Dependências técnicas entre itens: A07

Dados e contrato proposto: Rota, Atribuicao e versão da seleção; C06 limita cidades e membros. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A13.1: Validar seleção e conflito de atribuição em cada etapa.
• [ ] A13.2: Exibir resumo com cidade, quantidade, responsável e critérios.
• [ ] A13.3: Salvar rota e vínculos atomicamente ou com recuperação explícita.

Aceite funcional: Não avança vazio sem mensagem; total selecionado e responsável persistem; salvar cria vínculos corretos; repetir envio não duplica.

Cenário negativo obrigatório: Empresa ocupada por outra rota entre seleção e envio retorna conflito identificável.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Mapa e otimização automática não são pré-requisito desta correção.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A14: Qualidade da base e deduplicação

Prioridade: P1. Onda: 2. Ordem sugerida: 27. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 5/5. Redução de risco: 4/5. Confiança: 70%. Índice: 0.75.

Evidência atual: V. Registros impróprios para visita e dúvida sobre duplicidade. Nome , nomes cadastrais numéricos e cadastros em andamento.

Resultado esperado: Criar fila de saneamento; distinguir nome fantasia e razão social; validar endereço; sugerir duplicatas.

Ganho a acompanhar: Menos visitas improdutivas e menos empresas repetidas. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Dados + backend + operação / L / identidade/estabelecimento

Dependências técnicas entre itens: A10, A11

Dados e contrato proposto: QualidadeCadastro por regra e proposta de fusão com origem/destino, visita e perfil. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A14.1: Criar diagnóstico de nome, endereço, classificação e possíveis duplicatas.
• [ ] A14.2: Oferecer revisão e fusão assistida com prévia de efeitos.
• [ ] A14.3: Preservar IDs históricos e vínculos ao consolidar.

Aceite funcional: Não remover empresa legítima só pelo nome; fusão preserva visitas, autorização e histórico; pendências de dados explicadas antes da rota.

Cenário negativo obrigatório: Nome numérico pode ser legítimo; mesclar exige revisão e caminho de recuperação.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não executar limpeza destrutiva em massa nem invalidar empresa só pelo nome.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A15: Paginação e total do pipeline

Prioridade: P1. Onda: 2. Ordem sugerida: 14. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 70%. Índice: 1.54.

Evidência atual: V/I. Pipeline exibe estoque grande sem continuidade evidente. 2.546 pendentes versus 250 cartões pendentes renderizados. E02

Resultado esperado: Paginação ou carga progressiva explícita, contagem de exibidos, busca consistente e estados vazios.

Ganho a acompanhar: Acesso previsível ao conjunto e menor carga de renderização. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Frontend + backend / M / contrato de consulta

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: ConsultaClientes: cursor, limite, filtros e ordenação; resposta itens, próximo cursor e total. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A15.1: Definir paginação, ordem estável e total por mesmo filtro.
• [ ] A15.2: Expor quantidade exibida e carregar próximos resultados.
• [ ] A15.3: Cancelar resposta obsoleta após troca de filtro.

Aceite funcional: Usuário alcança todo conjunto autorizado; busca e total usam mesmo escopo; mudança de filtro não mistura resultados antigos.

Cenário negativo obrigatório: Mudança de estado entre páginas não duplica item; filtro antigo não sobrescreve novo.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não escolher virtualização antes de medir limite e necessidade.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A16: Filas orientadas à próxima ação

Prioridade: P1. Onda: 2. Ordem sugerida: 15. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 70%. Índice: 1.54.

Evidência atual: V. Pipeline pouco orientado a decisão. Sem filtros visíveis por responsável, idade ou bloqueio; Excluir compete com Ficha.

Resultado esperado: Mostrar próximo passo, responsável, prazo e motivo; filtros de trabalho; exclusão em menu secundário.

Ganho a acompanhar: Maior vazão da fila e menor tempo parado. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + frontend / M / estados oficiais

Dependências técnicas entre itens: A04, A15

Dados e contrato proposto: ProjecaoPipeline usa C03, Atribuicao e timestamps de entrada no estado. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A16.1: Definir próximo passo por estado e motivo de bloqueio.
• [ ] A16.2: Adicionar filtros por responsável, idade, cidade e pendência.
• [ ] A16.3: Rebaixar exclusão e ações auxiliares em hierarquia visual.

Aceite funcional: Gestor isola pendências antigas e reatribui por fluxo seguro; ação destrutiva informa efeitos e recuperação permitida.

Cenário negativo obrigatório: Cliente sem responsável entra em fila própria; prazo ausente não inventa SLA.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não equiparar quantidade de cartões a produtividade.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A17: Contraste do arquivo de evidência

Prioridade: P1. Onda: 1. Ordem sugerida: 9. Complexidade: Baixa. Esforço: 1 pontos relativos. Ganho: 3/5. Redução de risco: 3/5. Confiança: 90%. Índice: 8.10.

Evidência atual: R. Contraste de nome de arquivo: 1,21:1. Texto preto em fundo azul escuro.

Resultado esperado: Corrigir token herdado; revisar texto, foco e estados de upload.

Ganho a acompanhar: Evidência legível e menos erro ao identificar anexo. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Mudança localizada, com baixa coordenação entre camadas.

Responsabilidade sugerida: Design + frontend / S / nenhuma

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: Tokens de texto e superfície; arquivo mantém nome original em descrição acessível. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A17.1: Corrigir cor herdada do nome de arquivo no cartão.
• [ ] A17.2: Aplicar quebra de texto ou expansão acessível para nome longo.
• [ ] A17.3: Verificar foco, progresso, sucesso e erro do mesmo componente.

Aceite funcional: Texto comum com contraste mínimo 4,5:1; nome longo quebra/trunca com acesso ao nome completo; estados mantêm legibilidade.

Cenário negativo obrigatório: Nome extenso, teclado e tema não podem apagar informação de status.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não redesenhar a paleta inteira para corrigir um token.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A18: Acessibilidade dos controles

Prioridade: P1. Onda: 2. Ordem sugerida: 13. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 70%. Índice: 1.68.

Evidência atual: V/I. Alvos pequenos, ícones e rótulos exigem auditoria de acessibilidade.

Resultado esperado: Testar teclado/leitor de tela; rotular campos; dar nome aos atributos; melhorar alvos de toque.

Ganho a acompanhar: Menos assistência e maior autonomia de uso. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Design + frontend + QA / M / componentes compartilhados

Dependências técnicas entre itens: A01

Dados e contrato proposto: Semântica HTML/ARIA segue estado real; mensagem de erro referencia o campo. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A18.1: Auditar nomes acessíveis, foco, erros e ordem de leitura dos fluxos críticos.
• [ ] A18.2: Adicionar rótulos visíveis e alternativa textual a ícones.
• [ ] A18.3: Corrigir alvos e testar com teclado e leitor de tela.

Aceite funcional: Ordem de foco útil, erros associados, diálogos devolvem foco, leitura não depende de cor/hover; principais ações com 44-48 px por decisão de design.

Cenário negativo obrigatório: Ícone sem hover no toque, modal fechado e erro assíncrono mantêm contexto.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não declarar conformidade WCAG integral sem auditoria completa.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A19: Navegação por papel e tarefa

Prioridade: P1. Onda: 2. Ordem sugerida: 16. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 2/5. Confiança: 70%. Índice: 1.40.

Evidência atual: V. Navegação por perfil fraca e módulos escondidos. Admin inicia em rota vazia; Equipes/Dados/Cidades encontrados por outros caminhos.

Resultado esperado: Home por papel e navegação por tarefas. Unificar entradas e eliminar rotas legadas expostas sem contexto.

Ganho a acompanhar: Menos tempo para encontrar trabalho e menos treinamento de navegação. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + design + frontend / M / personas aprovadas

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: Mapa de navegação e permissões consultam C06; destinos indisponíveis têm explicação. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A19.1: Mapear tarefas principais de admin, líder, consultor e empresário.
• [ ] A19.2: Criar entrada por papel com próxima ação e filas relevantes.
• [ ] A19.3: Unificar nomes e ligar módulos hoje escondidos por tutoriais.

Aceite funcional: Admin encontra preparação e filas; consultor encontra próxima visita; empresário encontra perfil e pendências, com poucos passos e nomenclatura única.

Cenário negativo obrigatório: Papel múltiplo não perde contexto; voltar mantém seleção e pesquisa.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não mudar regra de acesso só por ocultar item de menu.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A20: Atribuição de equipes sem IDs técnicos

Prioridade: P1. Onda: 2. Ordem sugerida: 19. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 90%. Índice: 1.98.

Evidência atual: R/V. Equipes pede chave da rua e ID do membro. E15

Resultado esperado: Usar pessoas e rotas pesquisáveis. Integrar com Usuários e Gestão de rotas.

Ganho a acompanhar: Gestor atribui sem ajuda de desenvolvimento. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Frontend + backend / M / A07, A13

Dependências técnicas entre itens: A07, A13, A19

Dados e contrato proposto: AtribuirRota recebe IDs internos selecionados pela UI, nunca exigidos do operador. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A20.1: Substituir identificadores digitados por busca de pessoa, rota e território.
• [ ] A20.2: Validar vínculo com liderança e escopo territorial.
• [ ] A20.3: Exibir resultado da atribuição e caminho de edição seguro.

Aceite funcional: Operador atribui sem conhecer identificadores; vínculo fica visível e não permite membro/território incompatível.

Cenário negativo obrigatório: Pessoa removida ou rota alterada durante seleção produz mensagem acionável.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não duplicar cadastro de membros já governado por Usuários.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A21: Importação com fonte e diagnóstico

Prioridade: P1. Onda: 2. Ordem sugerida: 23. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 70%. Índice: 1.05.

Evidência atual: R/V. Importação sem arquivo conclui 0/0. Tela também expõe JSON de cadernos. E13

Resultado esperado: Definir fonte, arquivo e mapeamento; prévia, validação e relatório. Se for sincronização remota, nomear como tal.

Ganho a acompanhar: Importação auditável e menos correção manual de base. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Dados + frontend + backend / M-L / contrato da fonte

Dependências técnicas entre itens: A11

Dados e contrato proposto: C07 ExecutarImportacao: fonte, cidade, versão de catálogo e modo; JobImportacao com contadores. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A21.1: Definir se entrada é arquivo ou sincronização e explicar a fonte.
• [ ] A21.2: Validar mapeamento, formato, escopo e prévia antes da execução.
• [ ] A21.3: Registrar lidas, criadas, atualizadas, ignoradas e rejeitadas com motivos.

Aceite funcional: Não anuncia importação bem-sucedida sem entrada; informa zero mudanças e motivo; linhas rejeitadas e duplicatas têm diagnóstico.

Cenário negativo obrigatório: Entrada vazia informa nenhuma alteração; arquivo inválido não gera sucesso genérico.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não trocar conector nem importar dados reais sem validação da fonte.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A22: Escopo e contagens por cidade

Prioridade: P1. Onda: 2. Ordem sugerida: 20. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 50%. Índice: 1.20.

Evidência atual: V/I. Escopo de cidade pouco claro. Configurações listam 12; outras telas, seis. Dados mostra mesmos registros sob cidades distintas.

Resultado esperado: Distinguir habilitada, com dados, publicada e filtrada. Verificar se listagem manual obedece ao filtro.

Ganho a acompanhar: Menos interpretação errada e maior confiança no filtro. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + backend + frontend / M / A07

Dependências técnicas entre itens: A07

Dados e contrato proposto: CidadeStatus e parâmetros de filtro documentados por consulta. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A22.1: Definir cidade habilitada, com base, publicada e autorizada.
• [ ] A22.2: Aplicar escopo consistente às seções ou rotular explicitamente as globais.
• [ ] A22.3: Reconciliar contagens usando dados controlados.

Aceite funcional: Contagens têm definição; filtro afeta dados ou informa caráter global; nenhum vazamento territorial em testes de permissão.

Cenário negativo obrigatório: Cidade sem dados difere de acesso negado; total não revela dados privados de outro território.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não afirmar vazamento com base só em divergência visual de contagem.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A23: Entrada pública e links úteis

Prioridade: P1. Onda: 3. Ordem sugerida: 29. Complexidade: Média. Esforço: 3 pontos relativos. Ganho: 4/5. Redução de risco: 2/5. Confiança: 90%. Índice: 3.00.

Evidência atual: V. Home não orienta à descoberta. Anuário em construção; CTAs genéricos; links #. E16/E17

Resultado esperado: Definir entrada do Passaporte, busca/cidade e CTA de empresário. Corrigir destinos; retirar promessas indisponíveis do fluxo principal.

Ganho a acompanhar: Mais visitantes chegam à tarefa pretendida. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + conteúdo + design / M / decisão de marca e público

Dependências técnicas entre itens: A24

Dados e contrato proposto: Mapa de links e conteúdo aprovado; nenhuma ação usa # como destino fictício. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A23.1: Reescrever entrada do Passaporte para consumidor e empresário.
• [ ] A23.2: Ligar busca/cidade e cadastro ao percurso oficial.
• [ ] A23.3: Corrigir links institucionais, ajuda, contato e páginas em construção.

Aceite funcional: Consumidor chega ao diretório; empresário entende cadastro; links de ajuda, contato e políticas têm destino real antes de abertura pública.

Cenário negativo obrigatório: Diretório sem oferta publicada apresenta contexto e alternativa verdadeira.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não criar páginas de outros produtos do ecossistema neste pacote.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A24: Diretório e navegação unificados

Prioridade: P1. Onda: 3. Ordem sugerida: 28. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 3/5. Confiança: 70%. Índice: 1.14.

Evidência atual: V. Diretório, guia e vitrine fragmentados. E10/E12

Resultado esperado: Unificar navegação, busca, identidade e URLs canônicas. Definir redirecionamento de caminhos antigos.

Ganho a acompanhar: Busca previsível e redução de fragmentação. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Produto + frontend + backend / L / A04

Dependências técnicas entre itens: A04, A11, A22

Dados e contrato proposto: C08 BuscarDiretorio: cidade, categoria, termo, cursor; resultados apenas elegíveis. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A24.1: Definir rota canônica de cidade, categoria e empresa.
• [ ] A24.2: Unificar componentes de busca, filtros e navegação pública.
• [ ] A24.3: Planejar redirecionamentos e compatibilidade de links existentes.

Aceite funcional: Cidade → categoria → empresa → contato funciona; voltar preserva filtros; vazio oferece ação coerente; rotas antigas não viram becos sem saída.

Cenário negativo obrigatório: Voltar restaura filtros; URL antiga resolve; sem resultado não vira erro técnico.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não eliminar URLs existentes sem inventário de links e QR.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A25: Perfil público orientado a contato

Prioridade: P1. Onda: 3. Ordem sugerida: 30. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 3/5. Confiança: 70%. Índice: 1.14.

Evidência atual: V. Perfil público amostrado não demonstra conversão. Vitrine Teste é básica. E10

Resultado esperado: Completar perfil com contatos, horários, localização, fotos, serviços e verificação explicável; CTAs móveis.

Ganho a acompanhar: Mais intenções de contato por perfil útil. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Design + frontend + backend / L / dados e autorização

Dependências técnicas entre itens: A04, A05, A12, A24

Dados e contrato proposto: PerfilPublico deriva C04 e C03; contato canônico formatado por canal. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A25.1: Renderizar dados autorizados com CTAs reais e ausências explícitas.
• [ ] A25.2: Organizar horário, mapa, fotos, serviços e última verificação.
• [ ] A25.3: Preparar comportamento móvel de ligar, WhatsApp e rota.

Aceite funcional: Perfil com dados reais controlados mostra contato e rota corretos; ausências não geram botões mortos; medir cliques sem chamar de lead confirmado.

Cenário negativo obrigatório: Contato vazio não gera link morto; empresa suspensa não mantém oferta ativa.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não chamar clique de lead ou venda confirmada.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A26: Reivindicação e manutenção do perfil

Prioridade: P1. Onda: 3. Ordem sugerida: 34. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 4/5. Redução de risco: 5/5. Confiança: 50%. Índice: 0.50.

Evidência atual: P/V. Claim e edição do empresário não aparecem como jornada completa. Personalização limita-se a cores/vídeo.

Resultado esperado: Criar reivindicação com prova de vínculo, recuperação e tratamento de disputa; edição com revisão e prévia.

Ganho a acompanhar: Perfil mantido pelo responsável e menor custo de atualização. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Produto + segurança + backend / L / identidade e A05

Dependências técnicas entre itens: A05, A07, A25

Dados e contrato proposto: C09 ReivindicarEmpresa; estados solicitada, em revisão, aprovada, recusada e disputada. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A26.1: Definir prova de vínculo e disputa de responsabilidade.
• [ ] A26.2: Criar solicitação, revisão, concessão e recuperação de acesso.
• [ ] A26.3: Oferecer edição com prévia e revalidação de campos sensíveis.

Aceite funcional: Usuário não assume empresa alheia; disputa tem responsável; atualização sensível segue política de revalidação; contato alterado não contorna prova de vínculo.

Cenário negativo obrigatório: Contato público comprometido não basta para assumir empresa; troca de responsável preserva rastro.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não liberar edição por simples conhecimento do CNPJ.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A27: SEO por cidade, categoria e empresa

Prioridade: P1. Onda: 3. Ordem sugerida: 31. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 50%. Índice: 1.10.

Evidência atual: V/I. SEO da página pública examinada é genérico. Sem canonical, robots meta ou JSON-LD no DOM; title/descrição genéricos.

Resultado esperado: Definir SEO por cidade/categoria/empresa; dados estruturados válidos; sitemap e ambiente de teste separado.

Ganho a acompanhar: Melhor descoberta orgânica quando existir conteúdo válido. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Frontend + plataforma / M / A24-A25

Dependências técnicas entre itens: A24, A25

Dados e contrato proposto: Metadados derivados do perfil/cidade/categoria; dados estruturados sem campos inventados. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A27.1: Mapear URLs indexáveis e ambiente de teste.
• [ ] A27.2: Gerar títulos, descrições, canonical e dados estruturados factuais.
• [ ] A27.3: Verificar sitemap, redirects, robots e HTML servido.

Aceite funcional: Verificar HTML servido e renderizado, headers e robots; produção tem URLs e metadados específicos; teste não compete com produção; não concluir indexação só pela ausência de meta.

Cenário negativo obrigatório: Perfil suspenso, URL duplicada e empresa sem endereço seguem política editorial.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não prometer ranking ou indexação pelo acréscimo de schema.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A28: QR estável por empresa e edição

Prioridade: P1. Onda: 3. Ordem sugerida: 32. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 50%. Índice: 1.10.

Evidência atual: P/I. QR precisa ligar impresso ao perfil vivo. Há cidade/guia, sem prova de ciclo completo por empresa.

Resultado esperado: QR por identificador estável, com resolução e analytics; vincular edição sem congelar o destino vivo.

Ganho a acompanhar: Ponte mensurável entre impresso e perfil atualizado. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Produto + backend + editorial / M / A04-A25

Dependências técnicas entre itens: A04, A25

Dados e contrato proposto: C10 ResolverQR: identificador estável, edição opcional e destino permitido. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A28.1: Definir identificador público estável e resolvedor de QR.
• [ ] A28.2: Registrar origem da edição sem acoplar destino ao slug.
• [ ] A28.3: Gerar prova e testar leitura em aparelhos distintos.

Aceite funcional: QR de prova impressa abre empresa certa em iOS/Android; alteração de slug não quebra; suspensão/fechamento tem destino explicativo.

Cenário negativo obrigatório: Mudança de nome, retirada e edição antiga preservam destino explicativo.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não colocar token privado de edição no QR público.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A29: Componentes e hierarquia visual

Prioridade: P2. Onda: 4. Ordem sugerida: 39. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 3/5. Redução de risco: 2/5. Confiança: 70%. Índice: 0.70.

Evidência atual: V. Identidade e densidade variam entre áreas. Fundo espacial na operação, caixa alta e texto pequeno.

Resultado esperado: Sistema de componentes e tokens por contexto; manter marca com superfícies funcionais.

Ganho a acompanhar: Consistência e menor custo de novas telas. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Design + frontend / L / A09, A19

Dependências técnicas entre itens: A09, A19

Dados e contrato proposto: Contrato de componente inclui variantes de erro, vazio, loading, foco e leitura. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A29.1: Extrair tokens e padrões já aprovados em componentes compartilhados.
• [ ] A29.2: Revisar hierarquia, densidade e estados por contexto.
• [ ] A29.3: Migrar primeiro fluxos críticos com comparação visual e funcional.

Aceite funcional: Mesma ação tem mesmo nome, cor e hierarquia; teste de leitura em rua e zoom; componentes cobrem erro, vazio, loading e sucesso.

Cenário negativo obrigatório: Troca de token não reduz contraste ou muda significado de status.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não reescrever framework nem trocar marca Atlas pela Mosten no produto.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A30: Movimento com propósito

Prioridade: P2. Onda: 4. Ordem sugerida: 35. Complexidade: Baixa. Esforço: 2 pontos relativos. Ganho: 2/5. Redução de risco: 1/5. Confiança: 90%. Índice: 2.25.

Evidência atual: V. Movimento decorativo domina a home. Entradas de 800-1.000 ms; pulsação/flutuação; redução de movimento funciona.

Resultado esperado: Reduzir cenografia móvel; manter reduced-motion; priorizar feedback útil.

Ganho a acompanhar: Leitura mais direta e feedback sem espera. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Mudança localizada, com baixa coordenação entre camadas.

Responsabilidade sugerida: Design + frontend / S-M / A23

Dependências técnicas entre itens: A23

Dados e contrato proposto: Tokens de movimento, duração e propriedades; fallback sem biblioteca. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A30.1: Inventariar animações e sua finalidade por frequência de uso.
• [ ] A30.2: Reduzir entrada decorativa e criar feedback curto onde falta.
• [ ] A30.3: Preservar preferência reduce e remover animação de teclado repetitiva.

Aceite funcional: Conteúdo acionável não espera animação; nenhuma repetição indispensável; preferência reduce preservada; validar uso de CPU antes de alegar ganho.

Cenário negativo obrigatório: Redução ativada durante uso interrompe movimento sem esconder conteúdo.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não adicionar efeitos sem causa nem alegar ganho de performance sem medição.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A31: Feedback de requisição e recuperação

Prioridade: P2. Onda: 2. Ordem sugerida: 24. Complexidade: Média. Esforço: 3 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 90%. Índice: 3.60.

Evidência atual: R/V. Estados de requisição ambíguos. Correção mostrou dois carregamentos; importação teve sucesso sem conteúdo.

Resultado esperado: Estado por ação, bloqueio de duplicidade, erro recuperável, atualização contextual e próxima ação.

Ganho a acompanhar: Menos dúvida sobre o que foi salvo e menos duplicidade. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Frontend + backend / M / A03-A04-A21

Dependências técnicas entre itens: A03, A04, A21

Dados e contrato proposto: EstadoRequisicao usa requestId, erro tipado e chave idempotente quando há escrita. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A31.1: Modelar estados idle, pending, success e error por ação.
• [ ] A31.2: Adicionar recuperação e prevenção de envio repetido.
• [ ] A31.3: Vincular texto de sucesso ao resultado confirmado pelo servidor.

Aceite funcional: Uma ação não indica execução da oposta; timeout permite retomar sem duplicar; sucesso corresponde ao resultado persistido.

Cenário negativo obrigatório: Timeout após gravação deve consultar resultado antes de reenviar.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não usar toast genérico como única prova de conclusão crítica.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A32: Suporte contextual da operação

Prioridade: P2. Onda: 4. Ordem sugerida: 38. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 70%. Índice: 0.96.

Evidência atual: V. Suporte existe, mas fluxo operacional é raso. Status open e 1 mensagem(ns); sem prioridade/SLA visível.

Resultado esperado: Traduzir estados, vincular ficha/rota, atribuir responsável e prazo; definir canal de WhatsApp citado em reunião.

Ganho a acompanhar: Menor tempo de resolução de bloqueios em campo. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Operação + produto + backend / M / definição de suporte

Dependências técnicas entre itens: A19

Dados e contrato proposto: Chamado com estabelecimento/visita, mensagens, responsável e prazos configurados. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A32.1: Definir assunto, urgência, vínculo e responsável do chamado.
• [ ] A32.2: Traduzir status e permitir acompanhar resposta e histórico.
• [ ] A32.3: Integrar canal escolhido com evidência de entrega e SLA aprovado.

Aceite funcional: Chamado acompanha contexto; usuário vê resposta e situação; atraso gera ação conforme SLA aprovado, sem promessa fictícia de cinco minutos.

Cenário negativo obrigatório: Canal indisponível preserva chamado; atraso não desaparece no histórico.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não prometer resposta em cinco minutos sem capacidade operacional aprovada.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A33: Ajuda coerente com produto entregue

Prioridade: P2. Onda: 4. Ordem sugerida: 37. Complexidade: Média. Esforço: 3 pontos relativos. Ganho: 3/5. Redução de risco: 2/5. Confiança: 90%. Índice: 2.40.

Evidência atual: V. FAQ e tutoriais misturam personas e promessas. 52 perguntas; reservas, vouchers e outras frentes não demonstradas.

Resultado esperado: Separar ajuda por tarefa/papel; revisar documentação contra versão entregue; retirar caminhos técnicos do texto comum.

Ganho a acompanhar: Menos dúvidas e menos treinamento contraditório. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Conteúdo + produto + QA / M / A19

Dependências técnicas entre itens: A19, A34

Dados e contrato proposto: ArtigoAjuda com público, rota, estado da função e revisão editorial. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A33.1: Inventariar artigos e separar persona/tarefa.
• [ ] A33.2: Reproduzir instruções na versão atual e remover promessas não entregues.
• [ ] A33.3: Criar ajuda contextual curta com referência à versão.

Aceite funcional: Toda instrução operacional reproduzida; artigos indicam contexto e atualidade; produto não depende da leitura de tutorial para tarefa básica.

Cenário negativo obrigatório: Link antigo redireciona ou explica substituição; recurso futuro é identificado.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não ampliar escopo para implementar tudo que a FAQ menciona.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A34: Planos e benefícios unificados

Prioridade: P2. Onda: 4. Ordem sugerida: 36. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 70%. Índice: 1.68.

Evidência atual: V/P. Três modelos de planos competem. Ficha, FAQ e benchmark divergem.

Resultado esperado: Matriz única de benefícios, preço, limite, disponibilidade e regra de patrocínio.

Ganho a acompanhar: Oferta compreensível e menor retrabalho comercial. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Comercial + produto / M / decisão comercial

Dependências técnicas entre itens: Nenhuma dependência entre IDs. Ver decisões e critérios de prontidão globais.

Dados e contrato proposto: PlanoVersao e beneficios estruturados; selo de verificação independente de compra. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A34.1: Consolidar benefícios e nomenclatura com comercial.
• [ ] A34.2: Definir limites, elegibilidade, patrocínio e direitos de perfil gratuito.
• [ ] A34.3: Alinhar textos de venda, formulário, suporte e anuário.

Aceite funcional: Nome/benefício iguais em venda, cadastro, anuário e suporte; verificação não equivale a destaque pago.

Cenário negativo obrigatório: Mudança de plano preserva condições contratadas conforme decisão comercial.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não adotar automaticamente Free/Verificado/Pro/Growth do benchmark.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A35: Inventário e fechamento do impresso

Prioridade: P2. Onda: 4. Ordem sugerida: 40. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 50%. Índice: 0.58.

Evidência atual: P/I. Inventário e produção do impresso precisam de contrato próprio. Reunião discute páginas e VIP.

Resultado esperado: Edição, capacidade, reserva, prova, aceite de arte, fechamento e status de produção.

Ganho a acompanhar: Menos risco de venda sem entrega e retrabalho de impressão. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Editorial + comercial + engenharia / L / A05-A34

Dependências técnicas entre itens: A05, A28, A34

Dados e contrato proposto: C11 ReservarInventario e FecharEdicao com versão e capacidade disponível. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A35.1: Modelar capacidade e reserva por cidade/edição/formato.
• [ ] A35.2: Criar prova de arte, revisão e autorização antes do fechamento.
• [ ] A35.3: Congelar snapshot editorial e tratar cancelamentos e reimpressão.

Aceite funcional: Não vender mais posições que a capacidade; prova aprovada imutável por edição; PDF reproduz conteúdo e ordem autorizados; cancelamento libera reserva conforme regra.

Cenário negativo obrigatório: Duas vendas da última posição não excedem limite; correção pós-fechamento segue procedimento.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não misturar atualização digital com alteração retroativa da edição fechada.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A36: Proveniência e revalidação por campo

Prioridade: P2. Onda: 2. Ordem sugerida: 25. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 50%. Índice: 0.94.

Evidência atual: P/I. Proveniência precisa virar confiança auditável. Sinais existem, persistência por campo não foi inspecionada.

Resultado esperado: Versionar valor, fonte, coleta, validação, ator e justificativa. Definir validade e revalidação.

Ganho a acompanhar: Confiança explicável e auditoria de mudanças. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Backend + produto / L / modelo de dados

Dependências técnicas entre itens: A05

Dados e contrato proposto: ValorComProveniencia: valor, fonte, datas, ator, versão e status de validação. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A36.1: Mapear fontes e valores atuais por campo sem apagar versões.
• [ ] A36.2: Registrar coleta, validação, ator, confiança quando aplicável e razão da mudança.
• [ ] A36.3: Exibir selo e política de revalidação consistentes com dados.

Aceite funcional: Histórico reconstrói versão aprovada; alteração mantém original; selo mostra escopo/data; IA não se apresenta como visita humana.

Cenário negativo obrigatório: IA não vira CAMPO; dado ausente não vira confiança zero sem definição.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não exigir cálculo de confiança para fonte que não oferece estimativa válida.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A37: Funil e métricas com definição

Prioridade: P2. Onda: 3. Ordem sugerida: 33. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 3/5. Confiança: 50%. Índice: 0.81.

Evidência atual: P/I. Não há baseline de operação e conversão nesta auditoria.

Resultado esperado: Instrumentar funil, erros e intenção de contato; painel por papel.

Ganho a acompanhar: Decisões baseadas em uso e gargalos medidos. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Produto + dados + engenharia / M-L / A04-A25

Dependências técnicas entre itens: A04, A25

Dados e contrato proposto: C12 EventoProduto com eventoId, tipo, entidade, versão e instante; sem conteúdo pessoal livre. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A37.1: Aprovar dicionário de eventos e denominadores.
• [ ] A37.2: Instrumentar funil operacional e intenção de contato sem dados excessivos.
• [ ] A37.3: Reconciliar painel com amostra de registros e eventos deduplicados.

Aceite funcional: Eventos reconciliados com amostra de registros; deduplicação de eventos; métricas têm definição e denominador; empresário não vê PII indevida.

Cenário negativo obrigatório: Reenvio e múltiplos cliques não inflacionam contato confirmado.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não estimar receita ou conversão comercial sem fonte confirmatória.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A38: Processo de orçamento e lead

Prioridade: P2. Onda: 4. Ordem sugerida: 41. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 50%. Índice: 0.46.

Evidência atual: P/I. Orçamentos e leads exigem processo, não apenas formulário. Benchmark.

Resultado esperado: Definir opt-in, distribuição, elegibilidade, prazo, spam, duplicidade e retorno.

Ganho a acompanhar: Contato comercial rastreável e resposta útil. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Comercial + produto + engenharia / L / A25-A34-A37

Dependências técnicas entre itens: A25, A34, A37

Dados e contrato proposto: Lead com finalidade, destinatários autorizados, estado e histórico de encaminhamento. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A38.1: Definir solicitação, elegibilidade e distribuição do lead.
• [ ] A38.2: Implementar prazo, aceite, resposta, spam e duplicidade.
• [ ] A38.3: Apresentar situação ao consumidor e entrega ao empresário.

Aceite funcional: Lead tem destino e estado; cliente entende quem recebe; falha de entrega recupera; conversão não se limita ao clique.

Cenário negativo obrigatório: Nenhum fornecedor elegível gera alternativa clara; recusa não perde solicitação.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não distribuir dados pessoais indiscriminadamente nem vender o mesmo lead sem regra.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A39: Reputação, favoritos e ofertas

Prioridade: P2. Onda: 4. Ordem sugerida: 42. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 3/5. Redução de risco: 3/5. Confiança: 50%. Índice: 0.35.

Evidência atual: P/I. Avaliações, favoritos e ofertas são camadas futuras de engajamento. Não localizadas no perfil amostrado.

Resultado esperado: Priorizar após contato básico; prever moderação, denúncia, expiração e atendimento.

Ganho a acompanhar: Retenção e confiança quando houver uso suficiente. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Produto + operação / L / tráfego e governança

Dependências técnicas entre itens: A25, A26

Dados e contrato proposto: Avaliacao/Oferta/Favorito separados; autenticação e finalidade proporcionais ao recurso. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A39.1: Escolher um recurso por hipótese e preparar política de moderação.
• [ ] A39.2: Implementar denúncia, resposta e expiração antes de ampliar publicação.
• [ ] A39.3: Testar abuso e critérios de visibilidade.

Aceite funcional: Avaliação não mistura publicidade com reputação; oferta expira; abuso pode ser tratado e auditado.

Cenário negativo obrigatório: Oferta vencida, avaliação abusiva e solicitação de remoção têm tratamento.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não lançar três módulos juntos sem medir a hipótese de cada um.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A40: Desempenho medido por jornada

Prioridade: P2. Onda: 2. Ordem sugerida: 22. Complexidade: Média. Esforço: 5 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 50%. Índice: 1.10.

Evidência atual: I. Desempenho sem medição apropriada. Muitos cartões e tela longa são sinais, não diagnóstico.

Resultado esperado: Medir carregamento e interação em rede/aparelho representativos; avaliar paginação, imagens e bundle.

Ganho a acompanhar: Redução comprovada do tempo até executar tarefa. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Ajuste de jornada ou consulta, com integração e verificação focal.

Responsabilidade sugerida: Frontend + plataforma + QA / M / acesso técnico e ambiente de teste

Dependências técnicas entre itens: A15

Dados e contrato proposto: Protocolo com build, dispositivo, rede, massa, repetições e p75/p90 quando aplicável. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A40.1: Medir jornadas com massa e dispositivos definidos.
• [ ] A40.2: Localizar gargalo entre rede, servidor, renderização e mídia.
• [ ] A40.3: Aplicar otimização focal e repetir o mesmo cenário.

Aceite funcional: Baseline e orçamento aprovados; repetir com dados volumosos; medir LCP, INP, CLS e erros por rota sem inventar ganho.

Cenário negativo obrigatório: Cache quente não substitui primeira visita; rede lenta não mascara falha de API.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não usar número de cartões como prova de servidor lento.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A41: Recuperação, exclusão e concorrência

Prioridade: P2. Onda: 2. Ordem sugerida: 26. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 4/5. Redução de risco: 5/5. Confiança: 50%. Índice: 0.81.

Evidência atual: I. Recuperação, exclusão e concorrência não auditadas.

Resultado esperado: Verificar soft delete quando aplicável, restauração, efeitos em rota, bloqueio otimista e backup.

Ganho a acompanhar: Menor risco de perda silenciosa e recuperação praticável. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Backend + QA / L / fixtures descartáveis e política

Dependências técnicas entre itens: A02, A13

Dados e contrato proposto: ExcluirRota/Restaurar e versão esperada; trilha administrativa. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A41.1: Mapear efeitos de exclusão e política de recuperação.
• [ ] A41.2: Controlar concorrência por revisão e operações idempotentes.
• [ ] A41.3: Testar restauração e backup com dados descartáveis.

Aceite funcional: Excluir rota não apaga empresa/visita indevidamente; restauração testada; duas edições não geram perda silenciosa; ação administrativa auditada.

Cenário negativo obrigatório: Rota excluída não remove empresa ou autorização por cascata indevida.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não executar testes destrutivos em registros compartilhados.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A42: Proteção de dados antes de produção

Prioridade: P2. Onda: 1. Ordem sugerida: 10. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 5/5. Redução de risco: 5/5. Confiança: 50%. Índice: 0.94.

Evidência atual: I. Proteção de dados e acesso público não certificados. Credenciais fixas são intencionais neste teste.

Resultado esperado: Antes de produção, auditar segredos, autenticação, arquivos, tokens, logs, retenção e políticas reais.

Ganho a acompanhar: Menor risco antes de exposição pública. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: Segurança + plataforma + produto / L / código e infraestrutura

Dependências técnicas entre itens: A07

Dados e contrato proposto: Matriz de acesso, classificação de dados e configuração de produção, sem copiar segredos para relatório. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A42.1: Inventariar segredos, sessão, tokens públicos e acesso a anexos.
• [ ] A42.2: Verificar segregação de ambiente, logs, retenção e exposição.
• [ ] A42.3: Corrigir falhas confirmadas e registrar provas de fechamento.

Aceite funcional: Nenhum segredo de serviço no cliente; acesso a anexos e links respeita regra; ambientes segregados; revisão técnica e de privacidade concluída.

Cenário negativo obrigatório: URL de anexo, token revogado e ambiente de teste não concedem acesso de produção.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Credenciais fixas autorizadas no teste não são por si só achado de produção.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A43: Briefing IA com fontes e avaliação

Prioridade: P3. Onda: 5. Ordem sugerida: 43. Complexidade: Alta. Esforço: 8 pontos relativos. Ganho: 3/5. Redução de risco: 4/5. Confiança: 50%. Índice: 0.62.

Evidência atual: V/P. Briefing IA e provedores aparecem na interface; qualidade não foi testada.

Resultado esperado: Fontes, data, limites de custo, comparação com dado confirmado e avaliação por campo.

Ganho a acompanhar: Menor esforço de pesquisa com qualidade mensurável. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Contrato entre camadas, regras de negócio e regressão em vários fluxos.

Responsabilidade sugerida: IA + dados + produto / L / A11-A36

Dependências técnicas entre itens: A11, A36

Dados e contrato proposto: SugestaoIA guarda fonte, campo, valor, modelo e decisão humana, sem substituir revisão autorizada. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A43.1: Definir campos, fontes permitidas e limite de custo do briefing.
• [ ] A43.2: Exibir origem, data, divergência e ação humana de aceitar/rejeitar.
• [ ] A43.3: Avaliar precisão e cobertura em conjunto rotulado por campo.

Aceite funcional: Sugestão não sobrescreve dado validado; falha não bloqueia visita; precisão/cobertura/custo medidos em amostra rotulada.

Cenário negativo obrigatório: Sem fonte ou timeout preserva visita; sugestão divergente não sobrescreve dado.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não afirmar precisão a partir de exemplos isolados.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A44: Captura assistida de materiais

Prioridade: P3. Onda: 5. Ordem sugerida: 44. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 4/5. Redução de risco: 4/5. Confiança: 50%. Índice: 0.46.

Evidência atual: P. Smart Capture é oportunidade do benchmark e das reuniões.

Resultado esperado: Extrair cartão, fachada e material com sugestão estruturada e revisão humana.

Ganho a acompanhar: Menos digitação sem perda de controle. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: IA + frontend + backend / L / upload confiável e A36

Dependências técnicas entre itens: A06, A36, A43

Dados e contrato proposto: ExtracaoDocumento com origem do arquivo, sugestões e confirmação, ligada a C05/A36. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A44.1: Definir tipos de material e campos extraíveis.
• [ ] A44.2: Extrair para prévia comparativa com destaque de incerteza.
• [ ] A44.3: Salvar apenas seleção confirmada e medir correções por campo.

Aceite funcional: Telefone/endereço errados são visíveis na comparação; campo sem evidência não é inventado; revisão e rejeição rastreáveis.

Cenário negativo obrigatório: Imagem ilegível ou telefone ambíguo exige revisão e não inventa valor.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não publicar extração automaticamente nem enviar imagem a provedor sem regra de dados.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A45: Busca por intenção e concierge

Prioridade: P3. Onda: 5. Ordem sugerida: 45. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 4/5. Redução de risco: 3/5. Confiança: 50%. Índice: 0.42.

Evidência atual: P. Busca semântica e concierge dependem de dados atualizados.

Resultado esperado: Experimentar busca por intenção com filtros factuais e saída para contato.

Ganho a acompanhar: Melhor encontro entre necessidade e empresa com evidência. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Busca + IA + produto / L / A11-A12-A24-A25

Dependências técnicas entre itens: A11, A12, A24, A25, A43

Dados e contrato proposto: ConsultaIntencao gera filtros/consulta, resultados verificáveis e indicação de limite. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A45.1: Definir intenções atendidas e filtros factuais obrigatórios.
• [ ] A45.2: Comparar busca convencional e semântica em consultas rotuladas.
• [ ] A45.3: Dar resposta com empresas elegíveis e ação de contato.

Aceite funcional: Aberto agora, bairro e atributos respeitam dados; resultado sem evidência explica limite; qualidade comparada à busca convencional.

Cenário negativo obrigatório: Horário desconhecido não satisfaz aberto agora; resultado patrocinado não finge relevância factual.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não substituir busca determinística antes de provar ganho.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

A46: Sugestões de oportunidade comprováveis

Prioridade: P3. Onda: 5. Ordem sugerida: 46. Complexidade: Muito alta. Esforço: 13 pontos relativos. Ganho: 3/5. Redução de risco: 3/5. Confiança: 50%. Índice: 0.35.

Evidência atual: P. Motor de oportunidades depende de sinais reais.

Resultado esperado: Sugerir ação ao empresário a partir de incompletude, demanda e resposta.

Ganho a acompanhar: Empresário corrige gargalos comprováveis. Nota ordinal proposta, ainda sem baseline quantitativo.

Justificativa de complexidade: Vários estados, persistência ou integrações. Decompor antes de comprometer capacidade.

Responsabilidade sugerida: Dados + IA + produto / L / A37 e volume suficiente

Dependências técnicas entre itens: A37, A43

Dados e contrato proposto: Oportunidade com sinais de origem, período, regra/modelo e resultado da ação. Nomes conceituais, sujeitos ao mapeamento do código real.

Decomposição para implementação:

• [ ] A46.1: Definir sinais de completude, demanda e resposta que sustentam uma recomendação.
• [ ] A46.2: Gerar sugestão explicável com ação possível e opção de ignorar.
• [ ] A46.3: Medir adoção e efeito contra grupo/período adequado.

Aceite funcional: Cada sugestão explica evidência e ação; não inventa demanda nem receita; teste comprova utilidade antes de automação comercial.

Cenário negativo obrigatório: Baixo volume produz dados insuficientes, não alerta de queda inventado.

Verificação: registrar estado inicial, executar o fluxo descrito, conferir o resultado visível e a camada persistida quando houver escrita. Repetir o cenário negativo e anexar a prova ao item. Para evolução proposta, preparar fixture controlada antes de validar.

Limite de escopo: Não automatizar campanha ou prometer receita com correlação fraca.

Implantação e reversão: usar o protocolo global deste documento. A entrega só encerra após validar seu aceite na versão implantada, sem confundir publicação do código com adoção pelo usuário.

Atlas Passaporte: decisões e contratos propostos

Versão 1.0. Estes contratos especificam comportamento. Não são descrição de endpoints existentes, DDL ou recomendação de reescrita. Os nomes servem à discussão; o time deve mapeá-los às interfaces reais.

Decisões de negócio

Decisões em aberto não bloqueiam a correção de largura dos botões, contraste ou mensagens claramente erradas. Impedem apenas fechar comportamentos que dependem delas.

Invariantes

• Identificadores de empresa, estabelecimento, visita, ficha, revisão, perfil e edição não são intercambiáveis.
• O perfil publicado referencia uma revisão autorizada. Mudança de conteúdo sensível segue política de nova autorização.
• Conhecer um ID não concede acesso a ficha, rascunho ou anexo privado.
• Leitura de ficha não constitui comprovação de presença física.
• Fonte WEB/IA não se transforma em validação CAMPO sem evento de confirmação correspondente.
• Escrita repetida com a mesma chave e mesmo conteúdo retorna o mesmo resultado lógico.
• Mesmo identificador idempotente com conteúdo diferente retorna conflito, sem sobrescrever.
• Excluir rota não apaga empresa, autorização ou evidência por efeito colateral não previsto.
• Edição impressa fechada preserva sua prova. Perfil digital mantém ciclo próprio.
• Clique em contato não equivale a conversa ou venda.

Formato comum de comandos e erros

Comandos autenticados recebem o ator da sessão validada no servidor. Não confiar em actorId livre no corpo. Links de empresário usam token opaco, limitado a uma finalidade e revisão conforme D02. Evitar expor conteúdo privado em URL, analytics e mensagens de erro.

Quando há risco de escrita concorrente, incluir versão esperada. Quando há risco de reenvio, incluir chave idempotente. Retornar identificador do resultado, versão persistida, estado e próxima ação. Não expor segredos ou mensagens internas de banco na UI.

Os códigos e respostas HTTP finais devem seguir a convenção real da API. A especificação fixa a semântica, não impõe um novo envelope incompatível.

Contratos por domínio

C01: abrir ficha, A02/A10

Entrada: estabelecimento identificado, visita opcional e contexto autenticado. Processo: checar acesso, resolver visita/ficha correta e aplicar regra de criação idempotente apenas quando autorizada. Saída: ficha, revisão, origem e estado. Se o cliente ainda não tiver ficha, a UI oferece iniciar visita conforme regra. Não redireciona um ID de empresa diretamente para uma ficha inexistente.

Teste contratual: duas chamadas simultâneas sobre o mesmo início de visita produzem uma única visita lógica. Uma ficha encerrada não é reaberta silenciosamente.

C02: solicitar correção, A03

Entrada: revisão apresentada, campos selecionados de uma lista permitida, justificativa e chave idempotente. Processo: validar token/ator e revisão, registrar pedido e encaminhar à fila. Saída: pedido, data, estado e próximo passo. Abrir ou cancelar o formulário não grava.

Teste contratual: comentário sem campo ou campo desconhecido segue validação definida; revisão antiga produz conflito; reenvio após timeout não duplica pedido.

C03: avaliar e publicar, A04

Entrada da consulta: estabelecimento e revisão candidata. Saída: elegível ou lista de bloqueios com código, mensagem, responsável e ação. Entrada da publicação: revisão, versão esperada e chave idempotente. Processo: recalcular elegibilidade no momento da escrita. Saída: versão publicada e URL canônica.

Teste contratual: revogar autorização entre prévia e publicação impede a escrita. Busca e perfil deixam de apresentar uma empresa suspensa conforme política editorial. A condição do Assist é parte de D03, não um booleano escondido.

C04: autorizar versão, A05

Entrada: revisão imutável, escopo, identidade/vínculo verificados e intenção explícita. Persistência: referência ou hash da revisão, ator, data de servidor, texto/versão dos termos aplicáveis e escopo. Saída: autorização e próximo estado. A estratégia técnica de assinatura depende da revisão jurídica, sem pressupor certificado ou tecnologia específica.

Teste contratual: alterar telefone depois do aceite não herda autorização para esse dado sem regra aprovada. Um token de visualização não concede edição de perfil.

C05: salvar e sincronizar, A06/A09

Entrada: ficha, revisão base, sequência local, alterações e referências de anexos. Saída: confirmação da revisão persistida ou conflito tipado. Estados na UI: salvo neste aparelho, sincronizando, salvo no servidor, falha e conflito. Reenvio: ordem preservada ou consolidação determinística que não perca alteração.

Teste contratual: desligar a rede antes e depois da resposta, fechar a aba e reabrir recupera o rascunho permitido. Trocar usuário não expõe rascunho do anterior. Anexo pendente não aparece como recebido.

C06: escopo efetivo, A07

Entrada: sessão e ação sobre entidade. Processo: calcular papel, cidades explícitas, herança e exceções. Saída: permitido/negado e explicação administrativa sem revelar conteúdo privado. A mesma política rege consulta, exportação, escrita e acesso a mídia.

Teste contratual: usuário de uma cidade não acessa ficha/anexo de outra por URL direta. Nenhuma seleção no formulário precisa de semântica explícita; mudança da regra exige tratar contas legadas.

C07: importar, A21

Entrada: fonte identificada, escopo, catálogo, configuração e modo de execução. Prévia: formato, linhas e diagnóstico antes de mutação quando aplicável. Saída: job e contadores lidas/criadas/atualizadas/ignoradas/rejeitadas. A soma deve ser reconciliável com a definição de linha.

Teste contratual: entrada vazia informa zero alterações e motivo; repetir arquivo/fonte não duplica estabelecimentos; erro parcial produz relatório e política clara de retomada.

C08: buscar diretório, A24

Entrada: cidade, categoria, termo, filtros e cursor. Saída: empresas publicáveis, total/continuidade com definição e ordenação. Regras: filtros factuais respeitam dados conhecidos; não inferir horário aberto quando desconhecido.

Teste contratual: resultado e perfil concordam sobre versão e estado. Voltar ao resultado mantém filtros e posição quando possível.

C09: reivindicar empresa, A26

Entrada: empresa e solicitação de responsabilidade com comprovação definida. Estados: solicitada, em revisão, aprovada, recusada e disputada. Saída: acesso limitado após aprovação. Recuperação: processo independente de simples edição de contato público.

Teste contratual: trocar telefone do perfil não permite sequestrar acesso. Transferência mantém trilha e remove poderes anteriores conforme política.

C10: resolver QR, A28

Entrada: identificador público estável e origem editorial opcional. Saída: URL do perfil ou estado explicativo. Medição: acesso por QR com origem, sem tokens privados.

Teste contratual: mudar slug/nome mantém destino. Edição antiga e estabelecimento encerrado não redirecionam para outra empresa.

C11: inventário editorial, A35

Entrada: edição, cidade, formato e quantidade; depois, prova e versão autorizadas para fechamento. Processo: reserva atômica e controle de capacidade. Saída: reserva/posição, snapshot e histórico. Cancelamento: libera ou mantém capacidade conforme estágio definido em D05.

Teste contratual: duas reservas da última posição não excedem a capacidade. Fechamento não pode usar arte sem autorização correspondente.

C12: eventos de produto, A37

Envelope: eventoId, tipo, instante, entidade, versão, origem e contexto mínimo autorizado. Eventos iniciais: rota_atribuida, visita_iniciada, rascunho_persistido, visita_concluida, conferencia_enviada, correcao_solicitada, versao_autorizada, perfil_publicado, contato_clicado e contato_confirmado quando houver fonte real.

Teste contratual: evento reenviado não duplica contagem. Clique e confirmação têm definições e denominadores distintos. Não enviar comentários livres, telefone ou token para analytics.

Atlas Passaporte: validação e aceite por entrega

Este é o roteiro para o time executar na aplicação. Os testes abaixo não foram todos realizados na auditoria. Resultados atuais estão limitados ao caderno de evidências.

Preparação

Separar empresas descartáveis por cenário. Preparar admin, líder e membro de dois territórios, além de responsável empresarial. Registrar build, ambiente, catálogo e estado inicial. Nunca reutilizar credenciais de produção na massa. Testes de exclusão, publicação e envio externo usam destinatários e dados controlados.

Casos obrigatórios

Métricas sem promessa artificial

Registrar tempo mediano/p90 de visita, abandono por etapa, perda/retomada de rascunho, correções sem contexto, falha de abertura de ficha, tempo até autorização e publicação, perfil sem contato útil e intenção de contato por perfil. Definir janela, população e denominador antes de comparar. Não atribuir melhoria ao produto se a composição da amostra mudou.

Evidência por ticket

Registrar passos, dados de teste, versão, resultado esperado, resultado obtido e prova. Quando há escrita, incluir referência ao registro persistido e ao histórico. Quando há integração, distinguir fila, aceitação do provedor, entrega e resposta. Registrar falha com causa ainda desconhecida como falha observada, sem inventar diagnóstico.

Revisão do HTML desta entrega

A apresentação também precisa de verificação própria: arquivos presentes, 46 IDs, fórmula consistente, dependências sem ciclos, filtros, busca, impressão, links internos, imagens, teclado, viewport móvel e movimento reduzido. Os resultados desta verificação serão registrados em validacao-entrega.md. Essa aprovação valida o dossiê, não corrige a aplicação.

Atlas Passaporte: matriz de evolução

Data: 28/09/2026. Leia junto com o parecer de produto, o mapa técnico e as evidências.

Esta matriz contém 46 itens. Não representa 46 bugs comprovados. Separa defeitos reproduzidos, melhorias da experiência, verificações pendentes e propostas de produto. Prioridade é recomendação desta auditoria, não compromisso aprovado pelo negócio.

P0: bloqueia a liberação da jornada ou exige prova antes dela. P1: necessário para operação consistente e valor público mínimo. P2: evolução de qualidade, escala e receita. P3: hipótese para depois da fundação.

Evidência: R = reproduzido na interface; V = superfície verificada, implementação completa não comprovada; I = incerto, precisa de investigação; P = proposta baseada em reuniões/benchmark. Esforço relativo: S = localizado; M = vários componentes/uma jornada; L = vários domínios ou dependências. São estimativas iniciais de abrangência, sem análise de código e sem conversão em dias.

P0: liberar a jornada com segurança operacional

P1: reduzir retrabalho e entregar valor público

P2: qualidade, escala e receita

P3: assistência e inteligência após a fundação

Ordem prática para o primeiro ciclo

Começar por A01, A02 e A03. Em paralelo de planejamento, fechar as regras de A04 e A05. A liberação de campo depende da prova A06-A08, não só de correção visual. A09-A22 reduzem o retrabalho da operação. A23-A28 tornam o resultado útil ao público. As demais entregas dependem desse percurso funcionando.

O aceite de cada ciclo deve incluir captura da interface, resultado persistido, permissões e comportamento publicado quando aplicável. Um teste local verde ou uma tela bonita não substitui essas provas.

Atlas Passaporte: mapa técnico observado e roteiro de verificação

Data: 28/09/2026. Este documento não descreve uma arquitetura de backend confirmada. O código da aplicação não está presente no workspace analisado. O mapa usa apenas URLs e comportamento observados no portal de desenvolvimento.

Superfícies observadas

Modelo conceitual recomendado

Esta é uma proposta para organizar o produto. Não afirma que existam tabelas ou serviços com estes nomes.

flowchart LR
  B[Base de empresas] --> E[Estabelecimento]
  E --> R[Rota e atribuição]
  R --> V[Visita]
  V --> F[Ficha versionada]
  F --> C[Conferência do empresário]
  C -->|Correção| F
  C --> A[Autorização da versão]
  A --> P[Perfil público]
  A --> I[Participação em edição]
  I --> Q[QR estável]
  Q --> P
  F --> X[Revisão de exceções]
  X --> C

Empresa, estabelecimento, visita e perfil não são a mesma entidade. Uma empresa pode ter mais de um ponto físico. Um estabelecimento pode ter várias visitas. A edição impressa precisa referenciar uma versão autorizada, enquanto o perfil digital pode evoluir.

Separar três eixos de estado evita sobrecarga de uma única coluna de pipeline:

O fluxo de revisão por exceção continua sujeito à validação do negócio. A reunião discutiu simplificação, mas também pediu confirmação de sua aceitação para auditoria.

Hipóteses técnicas que não devem virar fatos

Verificações técnicas necessárias

Identidade e integridade

Rastrear CNPJ, estabelecimento, endereço, cliente, ficha, rota, responsável, perfil e edição. Identificar unicidade e regras de fusão. Exercitar requisição repetida e dois operadores em paralelo. Conferir se remover rota preserva empresas e evidências. Não executar testes destrutivos sobre registros compartilhados.

Autorização e publicação

Verificar autorização no servidor para cada leitura e escrita. Testar administradores, líderes e membros de territórios distintos. Inspecionar links de empresário, validade, revogação, finalidade e versão. Verificar se prévias não são confundidas com páginas publicadas. O simples conhecimento de um UUID não deve substituir a regra de acesso para conteúdo privado.

Campo, GPS e evidências

Executar check-in/check-out reais com consentimento de localização. Diferenciar falha de permissão, baixa precisão e ausência de sinal. Não registrar presença física por mera abertura de ficha. Testar foto da câmera, arquivo grande, orientação, compressão, reenvio e tipos não permitidos. Conferir origem, autoria, hora e retenção dos anexos.

Rascunho e concorrência

Verificar onde o rascunho é salvo, o que ocorre após logout e troca de conta, como a sincronização retoma e como conflitos são apresentados. Expiração de sessão não deve apagar coleta. Em aparelho compartilhado, dados locais precisam respeitar o escopo do usuário. O texto salvo deve corresponder à camada efetivamente persistida.

Integrações

Separar link de WhatsApp, envio via API, aceitação pelo provedor, entrega e leitura. A UI não pode declarar que o empresário recebeu só porque abriu um link. Aplicar a mesma distinção a PDF gerado, PDF enviado e conteúdo autorizado. Mapear Assist, IA e importação sem assumir que configuração implica integração funcionando.

Observabilidade e desempenho

Medir operações por rota e entidade, com correlação de erro sem expor segredos ou dados excessivos. Instrumentar falhas de publicação, upload e sincronização. Medir carregamento e interação com volume realista. Contagem de cartões e extensão de formulário justificam investigação, mas não comprovam lentidão de servidor.

Roteiro de aceite por cenário

Esses testes ainda precisam de código, ambiente preparado, contas por perfil e fixtures. Este documento define a prova necessária. Não declara os testes aprovados.

Atlas Passaporte: caderno de evidências

Data: 28/09/2026. Capturas obtidas na sessão de teste do portal de desenvolvimento. Os arquivos são JPEG. Os registros da aplicação podem mudar com outros testes. Contagens e estados descrevem o instante da observação.

Leia o parecer e a matriz de evolução para impacto e critérios de aceite. As imagens comprovam a apresentação da interface. Não comprovam sozinhas banco, autorização ou entrega de integrações.

Inventário

As capturas desktop usam 2560 × 1267. As exceções são E05, E06 e E17, com 390 × 844, e E07, com 768 × 1024. Nenhuma captura contém credenciais ou chave de acesso da vitrine. Não salvei a tela de personalização que exibia uma chave.

Medições do DOM

A preferência de movimento reduzido foi restaurada após o teste. Os tamanhos do viewport também foram restaurados.

Casos reproduzidos

E03: ficha não encontrada

1. Entrar como administrador de teste.
2. Abrir Clientes.
3. Localizar DIVINO SABOR CASEIRO na base.
4. Clicar em Ficha.
5. Observar erro em /campo/validar-ficha/b3cdeec1-351c-48c0-8449-734c279b5f05.

Não foi demonstrado que todos os clientes falham. Uma ficha existente de CHEIRIN BÃO abriu por outro registro. O vínculo entre cliente e ficha é hipótese técnica a investigar.

Ficha indisponível

E05/E06: ações móveis

1. Abrir a ficha existente /campo/validar-ficha/b38c906b-d863-4618-8144-d335052c2c65.
2. Usar viewport 390 × 844.
3. Conferir as ações do rodapé e sua caixa geométrica.

O registro já tinha check-in, check-out e foto. A auditoria não produziu presença física ou evidência de visita.

Ações da vistoria móvel

E08/E09: correção sem detalhes

1. Abrir a conferência de Massas Veneza em /homologar/3a521833-a190-4dd6-8fd8-d33c9e9a81c6.
2. Clicar em Corrigir informações.
3. A aplicação envia imediatamente e mostra sucesso, sem formulário intermediário.

Efeito registrado no ambiente: pedido de correção. Não houve confirmação de dados, publicação ou prova de notificação entregue. A auditoria não reverteu esse pedido por uma aprovação artificial.

Pedido de correção enviado sem motivo coletado

E13: importação sem entrada

1. Abrir /admin/dados.
2. Clicar em Iniciar importação.
3. Observar job concluído com zero linhas, sem seletor de arquivo.

Efeito registrado no ambiente: um job vazio, ID 5817d9e6-dd8f-47ce-ae36-fda2e05155bf. Nenhum arquivo foi enviado. A interpretação de defeito de backend depende do contrato: pode ser uma sincronização remota rotulada como importação. A interface não explicou a fonte nem a ausência de dados.

Importação concluída com zero linhas

Observações sem captura específica

Configurações, Usuários, Atendimentos, Tutoriais, FAQ, Guia e personalização também foram lidos no navegador. Os achados correspondentes usam snapshots de DOM e inspeção da tela durante a sessão. Não existe imagem local individual de cada aba ou estado desses módulos.

Na personalização, a interface mostrou cores, URL de vídeo e informação de acesso. Nenhum valor foi alterado. Em Usuários, o texto de escopo amplo foi observado no formulário; não foram criadas contas para provar autorização. Em Atendimentos, houve leitura da lista, sem criação ou envio de mensagem.

Referências de reuniões

• Reunião com Paulo e Mauro, 24/09: trecho próximo de 39 minutos menciona ficha indisponível; de 60 a 70 minutos discute simplificação; perto de 100 minutos volta à necessidade de confirmar se a proposta será aceita.
• Conversa com Mauro, 24/09: governança de requisitos, entendimento do produto e definição de responsáveis.
• Implantação e Operação da Plataforma Comercial, 23/09: jornada, catálogo, horários, suporte, impresso e personalização. O conteúdo utilizado foi resumo e ações, sem validação literal de cada fala.

Não foram copiadas transcrições completas, dados pessoais de participantes ou credenciais para estes documentos.

Atlas Passaporte --- Visão de Produto e Benchmark Lista Mais

Data: 28/09/2026\ Papel: PO sênior de discovery local, marketplaces, presença digital de PMEs, operação de campo e AI First.

1. Tese

O Atlas não deve ser apenas um guia de empresas nem um anuário digital. A oportunidade é ser uma plataforma de identidade comercial local verificada + descoberta + geração de demanda, conectando consumidor, empresário, consultor de campo e operação Atlas.

Tese: a Lista Mais ajuda uma empresa a ser encontrada. O Atlas deve ajudá-la a ser encontrada, validada, escolhida, acionada e convertida, mantendo dados vivos e comprováveis.

O moat não é a lista de CNPJs. É o grafo de dados locais validados: identidade, localização, categoria, contatos, horários, fotos, evidências, origem, histórico, aceite, reputação, demanda e performance.

2. Benchmark Lista Mais

Pontos positivos observados: - busca por nome, categoria, endereço e telefone; - páginas de cidade/categoria; - perfil individual; - mapa e rota; - telefone e WhatsApp; - avaliações; - pedidos de orçamento; - cadastro gratuito; - planos patrocinados; - destaque nos resultados; - página personalizada; - fotos/vídeos; - produtos/serviços; - palavras-chave; - relatórios; - monetização da exposição; - arquitetura favorável a SEO local.

A Lista Mais divulga mais de 2 milhões de empresas cadastradas, mais de 10 milhões de acessos/ano e mais de 50 mil empresas recebendo pedidos de orçamento/ano. São números declarados pelo próprio concorrente.

Aprendizado de monetização

A lógica Gratuito → Destaque → Exclusivo é boa. O Atlas deveria usar: - Free: perfil básico, endereço, telefone, WhatsApp, mapa, horário. - Verificado: selo, claim, atualização, fotos, analytics básicos. - Pro: destaque, mídia, serviços, ofertas, analytics, IA de conteúdo. - Growth: leads, campanhas, automações, CRM leve e inteligência.

3. Diferenciais recomendados

Empresa Verificada Atlas

Selo baseado em data da validação, confirmação pelo estabelecimento, GPS/foto quando aplicável, responsável, aceite e histórico.

Claim Business

"Sou responsável por esta empresa" → validar identidade → assumir perfil → atualizar → completar → contratar recursos.

Profile Score

Score de completude para contatos, horário, redes, fotos, serviços, pagamentos etc.

Proveniência

Cada campo relevante deve poder guardar valor, fonte, data_coleta, data_validacao, confidence, validado_por e versao.

Smart Capture

Não limitar a OCR. Foto de cartão/panfleto/material → extrair → interpretar → estruturar → comparar → sugerir → humano confirmar. IA nunca sobrescreve silenciosamente dado validado.

Busca semântica e Concierge

Ex.: "restaurante italiano aberto agora no Gonzaga com espaço para crianças". A resposta deve terminar em ação: WhatsApp, ligação, rota ou orçamento.

Opportunity Engine

IA identifica perfil incompleto, poucas fotos, baixa conversão, demanda crescente e divergências cadastrais.

4. SEO/GEO como Produto

Arquitetura cidade → categoria → empresa, com URLs estáveis, sitemap, canonical, breadcrumbs, Schema.org/LocalBusiness, horários, localização, FAQ, avaliações e ofertas. SEO/GEO não deve ser pós-projeto.

5. Página pública

Dados: nome, categoria, endereço, mapa, contatos, horários, fotos, descrição, serviços, pagamentos, redes.\ Conversão: WhatsApp, ligar, rota, orçamento, compartilhar, salvar.\ Confiança: selo, última atualização, reviews, respostas, fotos verificadas.\ Comercial: promoções, cupons, produtos, serviços e campanhas.

6. Físico + digital

Cada empresa deve ter QR Code único. O anuário deve ser canal de aquisição do ecossistema digital. O impresso envelhece; o QR leva ao perfil vivo e mensurável.

7. Operação de campo como moat

território → base → rota → consultor → visita → GPS → evidência → validação → empresário → aceite → publicação

Isso pode gerar qualidade difícil de replicar por scraping. Auditoria humana obrigatória para tudo, porém, destruiria a escala; usar revisão por exceção.

8. Arquitetura funcional

1. Identity --- empresas, estabelecimentos, CNPJ, responsáveis, deduplicação.
2. Territory --- cidades, regiões, categorias, nichos.
3. Field Operations --- rotas, Minha Rota, vistoria, GPS, evidências.
4. Verification --- claim, aceite, versionamento, exceções.
5. Directory --- busca, categorias, mapas, perfil público.
6. Engagement --- reviews, favoritos, compartilhamento.
7. Lead Marketplace --- orçamentos, leads, distribuição.
8. Digital Presence --- vitrine, landing page, conteúdo.
9. Advertising --- destaques, banners, campanhas.
10. Atlas AI --- Smart Capture, enriquecimento, busca, Concierge, Opportunity Engine.
11. Analytics --- empresário, operação e comercial.
12. Physical --- anuário, QR Codes, edições.

9. Priorização

P0 --- Fundação

Identidade única, deduplicação, base, categorias, territórios, rotas, exclusão segura de rota, vistoria, GPS, foto, formulários, aceite, versionamento, iOS/Android, performance, RBAC e segurança.

P1 --- Valor público

Busca, páginas públicas, SEO, mapas, WhatsApp, Claim Business, QR, analytics básicos e compartilhamento.

P2 --- Monetização

Planos, destaque, anúncios, orçamento/leads, ofertas e analytics avançado.

P3 --- Inteligência

Smart Capture avançado, enriquecimento, busca semântica, Concierge e Opportunity Engine.

10. North Star

Conexões qualificadas entre consumidores e empresas verificadas por mês.

WhatsApp, ligação, rota, orçamento ou outra ação comercial mensurável. "Empresas cadastradas" isoladamente é métrica de vaidade.

---

PROMPT MESTRE --- Auditoria do código-fonte

Copie para Claude Code ou Codex na raiz do repositório:

MISSÃO

Você está no repositório real do Atlas Passaporte/Sou-Clube. Atue como Principal Product Manager/PO, Staff Engineer, Software Architect, especialista em UX mobile-first/field operations, banco e integridade, segurança/LGPD/RBAC, SEO/GEO/local search, AI First/Document Understanding, SaaS B2B2C e QA Lead.

Nesta fase NÃO implemente nada. Investigue, prove e planeje.

Regras absolutas

• NÃO altere código, banco, migrations ou infraestrutura.
• NÃO faça deploy nem corrija bugs ainda.
• NÃO crie mock.
• NÃO invente funcionalidades.
• Diferencie: EXISTE / PARCIAL / NÃO ENCONTRADO / INCERTO.
• Toda afirmação técnica relevante deve citar arquivo, componente, função, rota, tabela/migration e linhas quando possível.
• Preserve regras existentes até compreendê-las.
• Não exponha secrets ou PII.

Contexto P0

Fluxo alvo: base → rota → consultor → vistoria → GPS/foto → validação/correção → empresário → aceite → versionamento → publicação.

Investigue especialmente: 1. exclusão de rota sem excluir empresas; 2. lentidão/travamento de rotas; 3. retirada de Auditoria/Homologação do happy path, preservando exceções; 4. vistoria pré-preenchida x cadastro novo; 5. revisão/correção/aceite pelo empresário; 6. trilha de versão e evidência; 7. WhatsApp manual agora e API futura; 8. Smart Capture; 9. GPS/check-in/foto; 10. iOS/Android/tablet; 11. duplicidade; 12. categorias/atividades; 13. permissões por território; 14. base por região/nicho; 15. vitrine pública; 16. anúncios; 17. enriquecimento com confirmação humana.

Auditoria obrigatória

A. Arquitetura

Mapeie stack, packages, frontend/backend, auth, banco, migrations, storage, APIs, jobs, integrações, observabilidade, testes e CI/CD.

B. Modelo de dados

Reconstrua entidades e relações: empresa, estabelecimento, CNPJ, usuário, consultor, território, categoria, rota, vistoria, GPS, foto, evidência, aceite, versão, auditoria, homologação, anúncio, anuário e lead. Procure FK ausente, cascade perigoso, status conflitantes, falta de audit trail, RLS e tenant leakage. Gere ERD textual.

C. Jornadas

Reconstrua pelo código: criar/excluir rota, Minha Rota, vistoria, cadastro in loco, upload, GPS, auditoria, homologação, aceite, publicação, vitrine e anúncios. Para cada uma, liste telas, APIs, tabelas, estados, validações, permissões e gaps.

D. Mobile

Audite viewport, overflow, teclado, câmera, file input, GPS, upload, loading, retry, conectividade intermitente, rascunho e touch targets. Não declare compatibilidade real sem teste físico.

E. Performance

Investigue N+1, queries sem índice, payload, processamento sequencial, loops, refetch, joins, renderização e paginação. Para cada hipótese, mostre evidência e como medir.

F. Segurança/LGPD

Auth, RBAC/RLS, território, URLs públicas, storage, uploads, secrets, PII, logs, consentimento, retenção, aceite e trilha. Classifique Critical/High/Medium/Low.

G. SEO/GEO

SSR/SSG, metadata, canonical, sitemap, robots, schema, LocalBusiness, URLs cidade/categoria/empresa, indexabilidade, conteúdo duplicado e Core Web Vitals.

H. IA

Mapeie providers, prompts, inputs, outputs, custo, segurança, fallback e confirmação humana. Avalie Smart Capture como imagem → extração → estrutura → comparação → sugestão → confirmação. Não use IA onde regra determinística é melhor.

Gap Analysis

Crie: Capability | Estado atual | Evidência | Gap | Impacto | Esforço | Dependência | Prioridade

Use P0/P1/P2/P3.

Entregáveis

Crie, sem alterar aplicação: - docs/atlas-product-audit.md - docs/atlas-gap-matrix.md - docs/atlas-architecture.md

O relatório principal deve conter Executive Summary, arquitetura atual, ERD, módulos/telas, jornadas, bugs confirmados, dívida técnica, segurança, performance, mobile, SEO/GEO, IA, gaps, impacto×esforço, prioridades, plano por fases, dependências, critérios de aceite, testes e perguntas que só negócio pode responder.

Princípio final: primeiro descubra o que o sistema realmente é. Depois compare com o produto que deveria ser. Só então proponha implementação.

Plano da entrega para tecnologia

Este trabalho entrega documentação e uma apresentação navegável. Não executa mudanças na aplicação Atlas nem substitui a aprovação das regras de negócio.

• [x] Recuperar auditoria, matriz, fontes e evidências locais.
• [x] Consultar Superpowers, brandbook, Impeccable, UI/UX Pro Max, Animate e Emil Design Engineering.
• [x] Conferir contexto, assets, fontes e fronteira institucional da marca.
• [x] Detalhar os 46 itens com esforço relativo, ganho, risco, confiança, dependências e aceite.
• [x] Registrar contratos propostos, decisões de negócio e plano de validação.
• [x] Construir HTML com conteúdo integral e navegação acessível.
• [x] Validar filtros, teclado, responsividade, movimento reduzido, fontes e links.
• [x] Gerar ZIP com inventário e verificar integridade.
• [x] Preparar destinatários, assunto e corpo do rascunho. A anexação é conferida após o empacotamento e registrada no recibo de distribuição, externo ao ZIP.

Método aplicado

Superpowers orienta compreensão, decomposição e revisão. Writing-plans orienta tarefas verificáveis. Não há código do Atlas neste workspace; por isso não foram inventados caminhos de componentes, tabelas ou comandos de teste da aplicação. O plano de implementação de código deve ser fechado pelo time após mapear essas unidades reais.

Karpathy-guidelines e gsap-core não foram localizadas como skills instaladas nos diretórios consultados. Não se declara execução dessas skills. Foram adotadas premissas explícitas, solução simples, alterações focadas e verificação por resultado. Para a biblioteca GSAP, foi consultada a documentação oficial de matchMedia: https://gsap.com/docs/v3/GSAP/gsap.matchMedia()/.

A referência tom-de-voz.md citada pela skill Mosten não está presente em sua pasta. O tom segue as instruções do usuário, o posicionamento oficial e a seção de usos incorretos. A pesquisa UI/UX sugeriu outra tipografia e paleta; elas foram descartadas em favor da marca solicitada.

Critério de conclusão

Os 46 identificadores originais precisam existir na especificação, no JSON, no CSV e no HTML. A priorização deve ser reproduzível. O HTML deve carregar sem rede. O ZIP deve conter os documentos de origem, as evidências e os arquivos editáveis necessários para regenerar a entrega. O e-mail deve conter os dois anexos, não apenas links locais.