Planejar por etapas

Proposta de jornada, regras e critérios de aceite · Nexo / Natura · 10 de setembro de 2026

O planejamento deve acontecer sobre um plano versionado, do recorte inicial à demanda revisada e ao snapshot final. A navegação organiza o trabalho; ela não muda a validade comercial do plano. A recomendação é manter quatro etapas: Preparar → Montar → Verificar → Concluir, com estimativa e revisão de demanda dentro de Montar.

Esta proposta parte da planilha Tela 7 - Cadastro de Promoções Ciclais.xlsx, das sete abas e das imagens embutidas, e do código atual da pasta v3.2. A planilha tem precedência como evidência dos requisitos da Tela 7; comentários e documentos anteriores são evidência do projeto, não decisões novas do solicitante. Divergências foram mantidas explícitas.

O protótipo em index.html demonstra a jornada completa com persistência local e dados de exemplo, incluindo carga de VNPs vigentes por ciclo, promoção a partir do VNP, desconto simples, edição, validação, solicitação/retorno simulado e fechamento. Ele não implementa integralmente o cadastro das 28 mecânicas, não integra o catálogo oficial, EOS ou Databricks e não substitui autenticação, permissões e validações de servidor. A especificação abaixo cobre esses contratos e separa o que falta construir do que falta decidir.

1. Entendimento do produto

Nexo substitui o planejamento comercial de venda direta por ciclo. O objeto de trabalho é uma decisão comercial por país, canal, ciclo, produto e público, com efeitos sobre preço, demanda e rentabilidade.

O sistema tem uma cadeia de dependências:

1. Calendário e acesso definem onde e quando o usuário pode atuar.
2. Taxonomia, categoria de planejamento, ciclo de vida e vigência definem os produtos elegíveis.
3. Preços, custos, impostos, royalties, comissão, régua de pontos, orçamento e ativas da OV sustentam os cálculos.
4. Ciclais, verticais, doados e alternativas do Plano B compõem o planejamento.
5. EOS estima demanda; Aurora permite analisar e adotar a estimativa.
6. Indicadores, snapshot e DRE/Outlook consomem a mesma versão revisada.

O fluxo guiado deve orquestrar esses módulos. O planejador não deveria precisar decorar qual tela abrir em seguida, nem reconstruir o contexto ao corrigir um dado.

Unidade de trabalho: plano com identificador e revisão. Unidade comercial: promoção, com mesmo código quando aplicada a vários ciclos. Unidade de cálculo: linha da promoção por ciclo, CV, veículo, público, grupo, papel e step. Esses três níveis não podem ser confundidos.

2. Problemas do fluxo anterior (v3.2)

Achados verificados no código, e não apenas inferidos da aparência:

Uma nova ordem de telas, sozinha, não resolve esses problemas. A mudança essencial é compartilhar o mesmo modelo e revalidá-lo em cada ação relevante.

3. A jornada recomendada

A reavaliação completa, com problemas corrigidos e limites ainda abertos, está em reavaliacao-fluxo.md.

O contexto aplicado aparece em uma linha discreta abaixo do título, com país, anos/quarters, ciclos e filtros ativos. O canal fixo não ocupa espaço nesse resumo. Como no fluxo original, os steps aparecem em uma faixa logo após o cabeçalho do aplicativo, antes do título e do conteúdo, desde a abertura. Essa faixa fica presa ao topo durante a rolagem. Os status do plano e do salvamento ficam junto aos botões da barra inferior. O conteúdo reserva espaço para as duas barras, incluindo a adaptação para celular.

Etapa 1 — Preparar

Pergunta respondida: onde vou planejar e quais resultados preciso alcançar?

O usuário recebe o país/canal autorizado e seu recorte de trabalho. Seleciona os trimestres por ano e visualiza os ciclos reais contemplados, com possibilidade de excluir ciclos individuais. Trimestre é um atalho de seleção; a unidade persistida é a lista de ciclos. As datas e a relação trimestre/ciclo vêm do Calendário Ciclal, sem intervalos inventados no front-end.

Canal não é um filtro de Preparar. A planilha Tela 7 lista Ciclo, Categoria Resultado, Categoria de Planejamento e Masterbrand em C3:C6; não exige um seletor de Canal. A matriz do projeto cita Canal nos requisitos de Preços e Ciclo de Vida, referentes a essas telas. Conforme ajuste solicitado, Preparar preserva o canal do contexto do plano (Venda Direta no exemplo) sem pedir nova seleção. Alterar país, período ou demais filtros conserva esse contexto para as regras e a carga de VNPs.

Disponível no protótipo: seleção de um ou mais anos entre 2026 e 2029, com Q1–Q4 independentes por ano. Adicionar um ano inclui inicialmente Q1; selecionar um quarter inclui seus ciclos, que podem ser desmarcados em “Ajustar ciclos individualmente”. Remover um ano não altera os demais. “Aplicar recorte” ou avançar para outra etapa salva o período; anos, quarters e exclusões são recuperados ao recarregar. Rascunhos anteriores conservam seus ciclos. O plano exige ao menos um ano, um quarter em cada ano selecionado e um ciclo no conjunto. Metas de ciclos novos permanecem sem cadastro quando a fonte não as fornece.

Limite do calendário demonstrativo: a distribuição segue o exemplo anterior — Q1: C01–C05; Q2: C06–C10; Q3: C11–C14; Q4: C15–C19. Não representa a classificação oficial de cada país/canal. Na integração, as opções e relações devem vir do Calendário Ciclal. A lista de ciclos continua sendo a referência para filtrar e calcular; os quarters também são guardados para restaurar a seleção visual.

Masterbrand, Categoria de Planejamento e Marca são filtros dependentes da taxonomia e das permissões. Categoria Resultado é outra dimensão; não deve substituir a categoria usada para planejar. “Todas” significa todas as opções autorizadas do contexto.

O orçamento do ciclo e recorte comercial tem prioridade como proposta de receita alvo e margem piso. Na falta dele, o demonstrador oferece o histórico simulado do mesmo ciclo do ano anterior, explicitamente identificado e sem ajuste de crescimento. Sem referência correspondente ao recorte, o usuário define a meta manualmente. Aceitar ou editar confirma os dois valores; o aceite em lote preserva metas já ajustadas e o orçamento de referência. Uma comparação consolidada incompleta deve dizer quantos ciclos têm meta; não exibir um percentual de atingimento global como se estivesse completo.

Reavaliado no demonstrador: metas ficam vinculadas a país, canal, masterbrand, categoria e marca; a base de ativas fica vinculada a país/canal, com valor por ciclo. Trocar recorte não reaproveita o orçamento consolidado como se fosse a meta da categoria. Voltar recupera os valores cadastrados daquele recorte. Recortes sem fonte mostram ausência. Ajustes de meta são auditados e têm revisão própria; enquanto houver solicitação ativa, os campos ficam em consulta. A separação definitiva das chaves de orçamento e ativas depende da integração.

Ao aplicar novo recorte com edições de linhas pendentes, o comando passa a indicar Salvar alterações e aplicar recorte. A ação salva as edições e aplica a seleção sem perder os filtros.

No produto completo, a interface deve oferecer Consultar plano trimestral dentro da jornada, com até três registros da chave de país/ciclo/versão/masterbrand, conforme o contrato de Snapshot. A consulta não troca silenciosamente a versão em trabalho. Iniciar a partir de uma foto deve ser uma ação explícita de cópia.

Saída: contexto válido e metas confirmadas para todos os ciclos. Receita e margem precisam ser maiores que zero; a margem não pode superar 100%. A tela informa quantos ciclos faltam e impede avançar inclusive pelos steps. Essa confirmação obrigatória é uma melhoria de fluxo aprovada nesta revisão do protótipo, não uma exigência literal atribuída às RFs. Fotos já concluídas continuam consultáveis.

CTA: Montar plano.

Etapa 2 — Montar

Pergunta respondida: quais condições comerciais quero oferecer e qual o impacto?

A grade contém VNPs vigentes nas revistas impressas e promoções já cadastradas. “Cardápio” deixa de ser uma fonte paralela da verdade. A seleção por checkbox delimita análise e ações em massa; ela não inclui/exclui produtos comercialmente.

Grade de planejamento implementada: a opção fica junto a Planejar produtos e Por veículo, dentro de Produtos do ciclo. O controle Resumida / Completa, no canto superior direito da tabela, alterna a densidade sem trocar as linhas, perder edições ou alterar os cálculos. A preferência fica salva neste navegador. O seletor de ciclo continua valendo; Consolidado mostra os ciclos selecionados lado a lado na mesma grade.

• Resumida: produto/CV, ciclo, veículo, tipo, preço CF, unidades, UPC, receita, margem, situação e ações. Preço, unidades e UPC podem ser editados diretamente quando a linha permite alteração.
• Completa: apresenta as 123 colunas A–DS da linha 13 da planilha Cadastro de Promoções Ciclais, agrupadas em Produto e ciclo, Contexto, Promoção e mecânica, Demanda e EOS, Preços e descontos, Resultado e pontos, Execução comercial, Públicos e segmentos, Auditoria, Corredores e Outros cálculos. Atalhos levam a cada grupo. Em telas amplas, seleção, CV, descrição e ciclo permanecem fixos durante a rolagem horizontal; os cabeçalhos acompanham a rolagem vertical.
• Preço/desconto são bidirecionais e UPC usa a base de ativas do ciclo da própria linha. Os campos comerciais habilitados usam as listas da fonte quando disponíveis e acompanham rascunho, salvamento, autoria e snapshot. Mecânicas e dados de origem permanecem protegidos; cadeados, plano concluído e solicitação de estimativa continuam governando a edição.
• A tabela ocupa a largura disponível. Na grade, uma faixa compacta fixa abaixo dos steps mantém visíveis receita VNP, receita dos promocionados, receita bruta total, margem bruta (valor e percentual) e unidades. O ciclo ou Consolidado identifica o escopo; busca e seleção não mudam esses indicadores. Expandir abre a composição por VNP/promoção/total e as metas do ciclo, em um painel sobre a área de trabalho. Recolher, Fechar, Escape ou clicar fora fecha o painel sem mudar a posição da tabela. O painel permanece atualizado durante as edições. O card grande de resultado fica nas outras visualizações; na grade, a faixa fixa assume essa função. Totais das linhas exibidas continuam abaixo da tabela. O VNP substituído permanece visível na grade com contribuição financeira zero.

Limite da visão completa: cobertura de colunas não equivale à homologação de todas as integrações e fórmulas. Campos sem dado de origem ou regra implementada mostram “—”, com indicação de indisponibilidade. Não são inventados preços CB por nível, pontos ou corredores a partir dos exemplos da planilha. As projeções EOS disponíveis continuam identificadas como simulação.

Caminho implementado para planejar cada ciclo:

1. Escolher o ciclo nos botões C01, C02 etc. A montagem inicia no primeiro ciclo selecionado; o botão “Consolidado” permite conferir o conjunto. A faixa de ciclos é o único seletor, sem dropdown repetido. A área Produtos do ciclo, com apoio “Planeje os produtos vigentes e as promoções deste ciclo”, separa opções de visualização, busca e dois painéis: Base vigente e Promoções do ciclo. No consolidado, o título passa a “Produtos dos ciclos”. Ações em lote aparecem no painel correspondente somente quando há seleção; descartar fica na barra inferior, junto ao salvamento. O cabeçalho compacto aproxima os produtos da área inicial da tela. Trocar o ciclo conserva o rascunho dos demais.
2. Consultar Base vigente: produtos vigentes no recorte, com ou sem promoção cadastrada. A lista reúne as condições carregadas por país/canal/CV/ciclo, inclusive promoções sem VNP associado, em um único cartão por produto e ciclo. Os chips Todos, Só VNP, VNP + promo e Promo têm seleção única e contagens; Todos inicia ativo e volta a ser selecionado ao trocar ciclo ou recorte. O chip Promo reúne VNP substituído e promoção sem VNP; os quatro chips ficam em uma única linha, com rolagem horizontal somente quando a largura disponível não comporta o conteúdo. A classificação considera todas as condições antes da busca; as contagens refletem a busca e o recorte, antes do chip. No consolidado, contam-se produtos por ciclo, para conservar estados diferentes do mesmo CV. Os chips filtram somente a coluna da esquerda, preservando promoções à direita, totais, metas e dados do plano. Trocar chip ou busca limpa a seleção da base, e ações em lote usam somente produtos visíveis e elegíveis. Os cartões compactos identificam preço, unidades e receita VNP; quando há somente promoção, mostram os valores promocionais. Detalhes permite consultar cada condição, e Ver promoção/Ver promoções abre as condições existentes. Bloqueios continuam respeitados, e uma lista vazia oferece retorno a Todos.
3. Acionar Promover, ou selecionar VNPs e usar Promover selecionados. Produtos com VNP ativo e desbloqueado oferecem essa ação; em Promo, a ação é consultar ou editar a promoção existente. A definição de múltiplas promoções do mesmo produto continua pendente em A93, sem ampliar regras de criação nesta alteração. O painel herda os produtos e ciclos escolhidos, recebe veículo, desconto e unidades específicas por produto/ciclo. A demanda VNP aparece como referência editável para a nova promoção; não é transferida destrutivamente. A prévia mostra a regra do VNP e a receita antes/depois.
4. Conferir Promoções do ciclo, reunindo as já cadastradas e as adicionadas neste planejamento. Preço, demanda e condição podem ser ajustados. O resultado permanece visível como receita dos VNPs mantidos + receita das promoções = receita total, com margem total. Logo abaixo aparecem receita alvo, margem piso, diferença para o alvo e situação do ciclo; meta parcial não aparece como atingida. A busca e as seleções operacionais não retiram produtos desse cálculo.
5. Usar Retirar promoção para desfazer a condição comercial. A confirmação mostra o impacto e quantos VNPs voltam a contribuir. Salvar aplica o rascunho; descartar volta à versão salva. Seguir para os próximos ciclos e verificar o conjunto.

Anulação executada no demonstrador: desconto simples, com requisito de uma unidade, substitui a contribuição do VNP vinculado no mesmo país/canal/CV/ciclo quando o veículo não é Revista Interativa. Na Revista Interativa, a regra do exemplo mantém o VNP impresso. Mecânicas anteriores que exigem duas unidades ou não anulam continuam preservando o VNP. A linha VNP permanece guardada: anular significa contribuição zero, não apagar o produto. O subtotal de VNPs e a visão por veículo consultam o cenário completo para não reativar um VNP quando a promoção que o anula está fora da visualização.

Carga demonstrativa e limite de cobertura: portfolio-demo.js contém cinco produtos de exemplo, com janelas de vigência e demandas explicitamente demonstrativas para 2026–2029. No ciclo 01 há três VNPs; no ciclo 02, quatro. Ekos Castanha entra no ciclo 02, Kaiak no ciclo 03 e Tododia deixa a base após o ciclo 02. Esses intervalos são fixtures de teste, não uma homologação da vigência oficial. A carga usa país/canal/ciclo/CV/veículo, não duplica linhas e preserva promoções e edições já salvas. Países e anos sem fonte não recebem o catálogo brasileiro por fallback. A integração deverá substituir as fixtures por todos os registros oficiais autorizados, inclusive as premissas financeiras e demandas de origem.

A carga de VNP é registrada como preparação da base e incluída nas referências de cenário sem salvar as edições manuais pendentes. Versões enviadas, recebidas, com demanda adotada ou concluídas não recebem carga automática de novos VNPs. Reabrir uma revisão permite atualizar a base. A solicitação EOS e o resultado final usam VNPs ativos mais promoções; o snapshot também preserva as linhas VNP de origem, inclusive as anuladas, para auditoria.

Manter o comparativo Inicial / Trabalhado / Variação, com dois níveis claros:

• Resumo do plano completo, independente da seleção.
• Comparação da seleção ou do recorte, com a mesma população nos dois cenários.

A referência inicial é o último estado salvo, estabelecido ao carregar a página. Preço ou demanda alterados atualizam o cenário trabalhado. Salvar aplica as alterações e atualiza a referência inicial, como exigido em A72–A75. Persistir um rascunho para recuperação automática não equivale a aplicá-lo ao plano.

Ações principais: Nova promoção, salvar alterações, editar selecionados. Excluir, duplicar, harmonizar, movimentos e visualização ficam na barra contextual ou em “Mais ações”. A seleção informa quantas promoções, linhas e ciclos serão afetados.

Criação no mesmo contexto: abrir um painel amplo dentro da etapa, com três seções progressivas:

1. Configuração e público: veículo, público compatível, REs, nível, segmento, CRM e mecânica. Herdar país/ciclos/categoria. Mostrar obrigatórios na própria seção.
2. Grupos de requisito e benefício: busca exata de CV, lista colada, agrupador ou kit. Apenas itens autorizados e vigentes em cada ciclo. Papéis, quantidades e steps ficam visíveis.
3. Preço e demanda: Preço De de origem, Preço Por CF/CB conforme aplicável, desconto vinculado, unidades ou UPC, pontos e prévia dos corredores. Descrição semiautomática editável, sem apagar texto manual ao atualizar outro campo.

Escolher a mecânica revela somente campos relevantes. Um código de promoção é gerado uma vez; as linhas são expandidas por ciclo, grupo, CV e step. Conservar o código do produto como string, sem completar, truncar ou fazer busca por substring na inclusão. CV 713 não é 100713.

Diferentes iniciativas, uma bancada: Ciclal, Vertical e Itens Doados são tipos de iniciativa; Plano B é alternativa vinculada ao Plano A. Alternativas não entram no total principal enquanto não forem ativadas. Benefícios de preço zero permanecem representados. Receitas e custos dos doados dependem do contrato de negócio indicado na seção 8.

Visão por veículo: a grade e o quadro são duas visualizações das mesmas linhas. Remanejar requer prévia do público, comissão, preço/pontos e validação do destino. Arrastar é opcional; a ação “Mudar veículo” deve existir para teclado e precisão. O remanejamento acontece na etapa de montagem, evitando uma revisão separada que modifica dados já validados.

Saída: plano salvo, com alterações e autoria registradas. Salvar rascunho com aviso de corredor é permitido; avançar para ações governadas depende das validações.

CTA: Salvar alterações / Verificar plano.

Estimar e revisar demanda dentro de Montar

Pergunta respondida: qual demanda o EOS devolveu e qual adoto para o plano?

O botão ✦ Estimar demanda · EOS, fixo na barra de ações, abre um painel lateral sobre a montagem. O destaque visual identifica o apoio do EOS; não promete um agente de IA conectado. Solicitação, acompanhamento e revisão ficam no mesmo contexto:

1. Selecionar itens individuais ou conjuntos por ciclo dentro do escopo, tipo de Forecast configurável e gate D-110/D-30. Default do gate deve usar datas de negócio/calendário; a escolha manual não é sobrescrita.
2. Mostrar resumo final: país/canal/ciclos, revisão, número de promoções/linhas e condições enviadas.
3. Criar solicitação com identificador, chave de idempotência e snapshot de entrada imutável.
4. Mostrar estados aceito, em processamento, retorno parcial, recebido ou falhou. Não inventar percentual de progresso sem informação da integração.
5. Comparar planejado × EOS × adotado por CV/ciclo/linha. A adoção em massa aceita somente sugestões pendentes e preserva decisões manuais já registradas; aplicar o conjunto exige todas as linhas exigidas resolvidas.
6. Alterar a estimativa sugerida exige justificativa, individual ou em massa, preservada no snapshot.
7. Aplicar a demanda revisada cria uma nova revisão e recalcula os indicadores da montagem. Ao concluir os lotes, Verificar confere o plano antes do fechamento.

Três fatos separados: enviado, estimativa recebida e demanda adotada. O check “Passou pelo EOS” depende de enviado + recebido (Tela 7 A120–A121); ele não significa que a demanda foi adotada ou aprovada.

Demanda e composição ficam protegidas enquanto o pedido está ativo. O projeto atual permite editar preço após enviar: nessa proposta, o snapshot enviado permanece intacto e a revisão fica desatualizada quando o preço muda. Reutilizar o retorno somente seria permitido se o contrato EOS afirmar quais campos não afetam a estimativa. Não aplicar um retorno antigo sobre condições novas silenciosamente.

Reavaliado no demonstrador: retornos complementares são anexados à mesma solicitação. Um lote inválido é rejeitado inteiro; uma retransmissão idêntica preserva decisões, enquanto uma sugestão alterada pede nova decisão apenas da linha afetada. Recebimento e decisão pendente são contados separadamente. O comando Simular restante do retorno demonstra a complementação, sem fingir integração ao EOS.

Linhas bloqueadas preservam todos os atributos, incluindo as unidades planejadas. A estimativa recebida fica registrada, mas a decisão mantém a demanda bloqueada; as demais linhas podem ser adotadas. O bloqueio não pode ser alterado durante solicitação/recebimento. O contrato real deve definir como sinalizar ao EOS as demandas fixas.

Saída: demanda revisada e aplicada à revisão atual. Retorno parcial, outra solicitação, linha desconhecida, duplicada ou quantidade inválida não habilitam fechamento.

CTA no painel: Enviar ao EOS → Revisar sugestões → Aplicar demanda revisada, conforme o estado. O botão fixo muda para Acompanhar EOS ou Revisar estimativas. Fechar o painel conserva a posição da grade e a solicitação em andamento.

Envio e validação contextual: somente os itens marcados são enviados. VNPs mantidos podem fazer parte do lote; VNPs substituídos ficam fora dele. A validação de envio examina a seleção, apresenta a causa de cada bloqueio e permite corrigir o item no painel. O comando salva as alterações do plano antes de enviar. Um bloqueio em outro lote não impede este pedido. Enquanto houver solicitação ativa, o demonstrador mantém a proteção global de demanda e composição; não implementa pedidos simultâneos.

Cobertura do plano: lotes sucessivos podem revisar ciclos diferentes. A compatibilidade é conferida por linha, condições comerciais e demanda adotada, preservando resultados de outras linhas. Mudança relevante torna a linha pendente; abrir uma nova revisão de um plano concluído exige nova rodada. O snapshot preserva todas as solicitações que sustentam as quantidades finais. Concluir exige todos os itens efetivos revisados e uma verificação da revisão atual. A granularidade de fechamento permanece o conjunto do recorte.

Limite da integração: as RFs também preveem carga automática de predições Supernova ao criar promoções com mecânicas contempladas e entrada manual quando não houver previsão. A interface oficial não está conectada: o protótipo preserva as demandas demonstrativas e identifica os retornos simulados, sem inventar previsões automáticas.

Compatibilidade: rascunhos anteriores preservam linhas, revisões e snapshots. A antiga etapa 4 de estimativa abre o painel em Montar; Concluir passa a ser a quarta etapa.

Etapa 3 — Verificar

Pergunta respondida: o que realmente impede este plano de seguir?

Conferir o recorte completo, independentemente do ciclo que estiver em foco. Agrupar pendências em Impede avançar, Avisos e Informações, com contagens, filtros por ciclo/veículo e prioridade.

Cada pendência precisa conter: regra, item, contexto, valor atual, valor esperado ou dado ausente, origem responsável, ação concreta e momento em que bloqueia. Exemplo: “CV 100144 · 202701 · Revista Impressa CFT · preço CF 35,90; piso CF 50,00. Rever preço”.

Não usar “Resolver” como sinônimo de reconhecer a mensagem. Corrigir o preço, atualizar a fonte ou excluir uma promoção é o que elimina a causa. Encaminhar ao Pricing cria um encaminhamento pendente. Adiar reorganiza o trabalho e mantém o bloqueio.

Uma correção deve abrir o campo na própria jornada. Se precisar de módulo externo, preservar retorno ao item, recorte e posição; ao voltar, recarregar a fonte e revalidar. Desfazer restaura os valores anteriores e recalcula a fila.

Saída: revisão salva sem bloqueios da ação solicitada e um comprovante de validação vinculado à revisão. A verificação é invalidada por mudança relevante. A barra de progresso nunca usa “página visitada” como evidência de validação.

CTA: Continuar para conclusão quando os dados estiverem válidos e a demanda aplicada. Salvar e continuar salva correções compatíveis antes de registrar a verificação. Demanda pendente ou retorno em andamento oferece Revisar demanda em Montar ou Acompanhar EOS em Montar, sem envio automático. A situação e o motivo ficam visíveis no início da etapa e junto ao botão. Bloqueios de qualquer ciclo impedem o fechamento; avisos não impedem avançar. Falha ao persistir conserva o rascunho. Planos concluídos oferecem consulta do fechamento.

Etapa 4 — Concluir

Pergunta respondida: qual versão estou encerrando e que resultado ela produz?

Mostrar resultado por ciclo antes do consolidado: receita versus alvo, margem versus piso, quantidade, exceções e situação. Uma média consolidada não encobre um ciclo inviável.

O resumo financeiro usa o mesmo motor de cálculo da grade. Preços, unidades e premissas não podem ser recalculados por fórmulas diferentes em Snapshot, Indicadores e DRE.

O fluxo real depende da definição de quem aprova e qual gate exige aprovação. Recomenda-se Enviar para aprovação quando aplicável; o planejador não se torna aprovador por estar na etapa final. Após aprovação vinculada à revisão, gerar o snapshot da versão escolhida e acompanhar integração/publicação até confirmação do destino.

A origem para gerar snapshot é WIP. A versão destino nasce Carga, com a lista oficial configurada. Fora de Carga, sobrescrita exige confirmação e preservação/reclassificação da anterior; respeitar os três últimos registros por chave, sem apagar a auditoria histórica. O demonstrador oferece um subconjunto de versões e mantém histórico local; não demonstra sobrescrita oficial.

Fechar significa bloquear alterações na versão concluída. Criar nova revisão, com motivo, reabre o trabalho preservando a foto anterior. Aprovação, forecast ou validação que pertencem à versão anterior não migram automaticamente.

Saída de negócio: revisão aprovada quando exigido, snapshot íntegro e integração confirmada. Saída do demonstrador: foto local de demonstração. Após a gravação bem-sucedida, a tela exibe uma confirmação verde com check animado, escopo e versão, receita, margem, unidades, composição VNP/promocional e relatório por ciclo. Desvios e justificativas permanecem visíveis. O relatório HTML é independente e imprimível; os dados JSON e o histórico também podem ser baixados. Uma nova revisão preserva o snapshot anterior. Falha de validação ou armazenamento não mostra sucesso.

CTA: Enviar para aprovação / Gerar snapshot / Concluir, conforme o contrato e o estado.

4. Estados, salvamento e contratos

Estado do plano não é número da etapa

Navegar entre as etapas é livre para consulta. Botões que mudam estado têm validação na execução, não apenas disabled na interface. O servidor precisa repetir as validações e conferir revisão/permissão.

Dados mínimos compartilhados

Mesma promoção multiciclal: código comercial compartilhado; lineId diferente por ciclo. Mesma descrição ou CV não implica mesma promoção. Cancelar, excluir e duplicar precisam definir se a ação afeta só o ciclo em foco ou toda a promoção, com prévia dos afetados.

Invalidação e concorrência

• Mudar preço, demanda, mecânica, grupo, público, veículo, ciclo ou premissa que afeta cálculo invalida a verificação relevante.
• Mudar input enviado invalida a compatibilidade com o forecast. A foto antiga não se altera.
• Adotar demanda atualiza a base de cálculo e exige revisão final das metas e bloqueios. Os marcadores reconhecem a solicitação validada e a revisão adotada; visitar telas não valida o plano.
• Ajustar apenas uma meta no demonstrador tem revisão e auditoria próprias; não descarta a estimativa já adotada, pois orçamento não compõe os inputs do EOS simulado. O fechamento consulta as metas atuais e grava sua revisão. Se o contrato real usar orçamento como input, também será necessário invalidar a estimativa.
• Alterar versão em aprovação retira sua condição de aprovada, conforme workflow a definir.
• Alteração em outra aba/usuário deve gerar conflito por revisão, com comparação antes de sobrescrever.
• Salvar deve ser atômico. Falha de persistência não mostra “salvo” nem libera envio; o rascunho fica recuperável.
• Enviar é idempotente; repetir após timeout consulta o mesmo pedido, sem criar duplicação silenciosa.
• Campos de fonte externa ausentes continuam ausentes. Zero só é zero quando a origem informou zero.

5. Regras e momentos de bloqueio

F = requisito explícito da planilha; P = evidência do projeto; R = recomendação desta proposta; D = decisão pendente. Uma recomendação não deve ser tratada como requisito aprovado.

Não há regra universal “todo aviso impede tudo”. O retorno da validação deve dizer quais ações são impedidas. Salvar um rascunho incompleto é diferente de aprovar, solicitar forecast ou publicar o planejamento.

6. Cálculos e conciliação

Os cálculos devem ficar em um serviço de domínio compartilhado, com a mesma definição na tela e no output. O demonstrador não é uma homologação financeira.

Premissas demonstrativas: comissão 28%, imposto 10%, custo unitário 22% do Preço De, royalties 3% da RL; são fixtures identificadas, não regras da Natura. O protótipo usa a RB da planilha e calcula RL com imposto para demonstrar a conciliação. Essas premissas precisam ser substituídas por fontes oficiais. Um valor ausente não deve receber percentuais fixos automaticamente na implementação real.

7. Rastreabilidade da Tela 7 e cobertura da proposta

O arquivo requisitos-fonte.csv preserva 66 células de requisitos textuais, sem modificar a planilha original. O catálogo mecanicas.js preserva as 28 mecânicas e os flags H:M; campos em branco permanecem sem definição.

Mecânicas: não completar vazios com suposições

A aba define seis flags: quantidade requisito, quantidade benefício, grupo requisito, grupo benefício, vale-pontos e número de steps. Há linhas com flags ausentes. Ausência de preenchimento não equivale a “NÃO”.

Para cada país, publicar uma versão do catálogo com: obrigatórios, opcionais, ocultos, domínio numérico, passos permitidos, grupos, preço de requisito/benefício, descrição, código Capta/GSP, anulação de baseline e cálculo de pontos. Para progressivas, validar faixas ordenadas e sem sobreposição conforme contrato e gerar uma descrição por step. A imagem e B33 da aba avisam que o requerimento foi construído com base em Brasil e precisa ser revisto por país.

8. Decisões de negócio que faltam

Estas decisões não foram resolvidas artificialmente no protótipo. A entrega já está concreta para discussão com os responsáveis.

9. Usabilidade e acessibilidade

• Um CTA principal por estado; rodapé fixo com próximo passo e motivo de indisponibilidade.
• Contexto e situação do plano sempre visíveis. “Em planejamento”, “Aguardando EOS” e “Concluído” vêm do estado real.
• Navegação pelas etapas não salva, não compromete e não envia.
• Grade como bancada principal; quadro por veículo como visão alternativa, sem segundo estado de dados.
• Detalhes no próprio item; inputs inválidos mantêm o usuário no campo com orientação concreta.
• Botões explícitos para mudar veículo, corrigir, adotar e excluir. Gestos/drag não são o único caminho.
• Preservar foco, busca e seleção ao voltar de um painel. Seleção de um recorte não afeta automaticamente outros ciclos.
• Mostrar quantos itens/ciclos serão afetados antes de aplicar em massa, duplicar, excluir ou enviar.
• Não usar só cor: status textual, ícone e mensagem. Desvio não é comunicado apenas por gráfico.
• Valores monetários e percentuais têm unidades claras. Ausência usa “—” e explicação; não “0,00”.
• Corpo de leitura de 14px, controles de 40px e foco de teclado. Tabela pode ter rolagem horizontal; a página não deve transbordar.
• Diálogos acessíveis com título, foco contido, Escape e retorno ao acionador. Confirmações somente para ações consequentes, não para cada avanço.
• Visualização avançada agrupa identidade, demanda, financeiro, execução e auditoria; ocultar uma coluna não impede seu cálculo ou validação.
• Colaboração real exige detectar revisão concorrente, não apenas mostrar um toast de sucesso.

10. Aceite ponta a ponta

O motor do demonstrador tem 40 testes automatizados: 20 da jornada, 10 de VNPs e 10 da reavaliação (recorte de metas/ativas, metas parciais, auditoria, retorno complementar, preservação de decisões e demanda bloqueada). Os testes de navegador exercitam promoção por ciclo e em múltiplos ciclos, regra RI, retirada/restauração, edição VNP, correção, salvamento, solicitação, adoção, conclusão, reabertura e telas responsivas. periodos.test.js verifica anos e quarters independentes, ano completo, exclusão individual de ciclos, persistência, recuperação de rascunhos anteriores, propagação do recorte, seleções vazias e consulta de plano concluído. reavaliacao-navegador.test.js exercita troca de recorte com rascunho, meta no ciclo, atalhos de correção, retorno complementar, decisões manuais, demanda bloqueada, progresso, conclusão e steps fixos em diferentes larguras. Aprovação, integrações e cenários complexos de mecânicas precisam de testes com os contratos reais na implementação.

11. Sequência de implementação no produto

1. Contrato de plano e cálculos: identidade, recortes, versões, baseline, premissas, RB/RL/MB e persistência. Corrigir inconsistências antes de conectar novas vistas.
2. Bancada única: grade existente dentro da etapa Montar; editor completo como painel do fluxo, preservando todos os atributos da Tela 7. Substituir links que abandonam a jornada por navegação contextual com retorno.
3. Validação compartilhada: regras com severidade, motivo e ações bloqueadas; correção por causa e versão validada.
4. EOS/Aurora no fluxo: pedido versionado/idempotente, assíncrono, retorno parcial, decisões e adoção.
5. Aprovação e fechamento: estado de governança, snapshot imutável, outputs e confirmação de integração.
6. Escala e colaboração: virtualização da grade, processamento de lote, concorrência e auditoria no backend.

Não é necessário reescrever todos os módulos para oferecer uma jornada única. É necessário que todos leiam e alterem o mesmo plano por contratos consistentes.

Fontes consultadas

• Planilha original: sete abas, requisitos A55:A124; Botão de adicionar promoção B42:B50; imagens dos três blocos de criação, exclusão e harmonização; Mecânicas B2:M29.
• HANDOFF.md: propósito, stack alvo, papel de referência dos protótipos e integrações fora do escopo.
• 02-documentacao-produto.md: personas, cenário inicial/trabalhado, processo e lacunas de aprovação.
• DESIGN.md: tipografia, componentes, tokens, confirmação de exclusão e acessibilidade.
• mapa-dependencias.md: cadeia de fontes, vigência, pontos, Boy, baseline e pontos abertos.
• v3.2/prototipo-fluxo-etapas.html: implementação analisada da jornada atual.
• v3.2/promocoes.js e promocoes-dados.js: cadastro, veículos, modelos, baseline, publicação do plano e solicitação EOS.
• v3.2/ciclo-estado.js: estados e bloqueios operacionais do ciclo.
• v3.2/prototipo-calendario.html: calendário oficial/projetado e trimestre ciclal.
• v3.2/dev-notes-telas.js: contratos rastreados de Aurora, Snapshot, Indicadores, DRE e fluxo guiado.
• guia-conferencia-sprint3.html, relatorio-duvidas-sprint3.html e 06-plano-sprint3-dev.md: proposta em validação e decisões ainda abertas.