# 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:

| Problema | Evidência atual | Consequência |
|---|---|---|
| A jornada acaba no envio | `v3.2/prototipo-fluxo-etapas.html`, `ETAPAS`, linhas 470–476 | Receber, revisar, adotar demanda e fechar ficam fora da jornada. |
| Estado é derivado da página visitada | `modoAtual`, `ir`, linhas 487–529 | Visitar a etapa final já exibe “enviado”; entrar na etapa 3 compromete implicitamente o plano. |
| País e ciclos não filtram a base | `aplicarEscopoBase`, linhas 418–429 | Totais e envio podem conter linhas de fora do recorte anunciado. |
| Chave não contém ciclo nem código de promoção | `chave`, linha 448 | O mesmo CV/descrição/veículo em dois ciclos colide. |
| Estado salvo aceita seleções falsas como verdadeiras | `restaurar`, linhas 1266–1271 | Ao recarregar, uma linha retirada pode voltar ao plano. |
| Normalização perde regras comerciais | `FONTE_REAL`, linhas 325–339 | Código, tipo de linha, VNP, distribuição vertical, benefícios e governança se perdem. |
| Itens de receita zero são descartados | Filtro de `precoDe` e `qtd`, linhas 328–329 | Benefícios e doações deixam de ter representação no plano. |
| Metas ausentes herdam outro ciclo | `alvoDefault`, linhas 556–560 | A tela apresenta uma meta que não pertence ao ciclo. |
| Fila pode ser resolvida sem corrigir a causa | `resolvidasK`, `resolverCarta`, linhas 1043–1049 | Um marcador permanente suprime pendências; não existe comprovação da correção. |
| Desfazer não restaura preço | `desfazerCarta`, linhas 1055–1060 | O histórico diz “desfeito”, mas o dado permanece alterado. |
| Teto de corredor vira crítico | `fora`, linha 460, e `montarPendencias` | Regra de teto não corresponde ao mapa de dependências, que restringe o piso Boy. |
| Faixa de público incompatível | Comparação de `precoPor` com `cbBoy` | Um preço CF pode ser comparado com piso CB. |
| Desconto global diverge entre vistas | `agrega(descGlobal)` versus cards/quadro sem `descGlobal` | A revisão e o snapshot podem mostrar preços diferentes do resumo. |
| Snapshot aplica o primeiro ciclo a todas as linhas | `etapaEnviar`, linhas 1218–1222 | Perde a identidade ciclal e registra unidades planejadas como se fossem unidades EOS. |
| Mudanças não invalidam envio/verificação | `enviado` booleano e `maiorVisitada` | O usuário pode revisar dados posteriores ao envio mantendo a aparência de plano válido. |
| Comprometer não publica o estado compartilhado | `comprometido=true`; grava somente a jornada | O discurso “valendo no ciclo” não corresponde ao estado dos demais módulos. |
| Calendário trimestral é heurístico | `TRIMESTRES`, linhas 350–358 | Pode divergir do Calendário Ciclal oficial, que aceita classificação por trimestre. |

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](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

| Estado | Alterações | Próxima ação principal | Condição |
|---|---|---|---|
| Em planejamento, sem alterações | Permitidas conforme permissões | Montar ou verificar | Dados disponíveis |
| Alterações no rascunho | Permitidas | Salvar alterações | Validação do campo; erro estrutural não persiste como válido |
| Salvo | Permitidas | Estimar em Montar ou verificar | Revisão gerada; seleção validada ao solicitar |
| Verificado | Permitidas, invalidando verificação | Conferir fechamento | Demanda aplicada e zero bloqueios do plano |
| Aguardando estimativa | Demanda/composição protegidas | Acompanhar | Pedido aceito pelo destino |
| Retorno parcial | Revisar linhas recebidas | Aguardar/reprocessar faltantes | Sem adoção completa prematura |
| Estimativa recebida | Decidir adoção | Aplicar demanda | Justificativa de ajustes |
| Demanda revisada | Alterar invalida dependências | Revisar fechamento | Revisão corresponde à adoção |
| Em aprovação | Conforme workflow oficial | Acompanhar aprovação | Aprovador e objeto definidos |
| Concluído | Somente consulta | Consultar / criar revisão | Snapshot e confirmação de integração |
| Desatualizado / falha | Conforme causa | Corrigir e reprocessar | Retorno anterior preservado |

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

| Objeto | Campos / responsabilidade |
|---|---|
| Plano | `planId`, `revision`, país, canal, ciclos, filtros autorizados, status, revisão-base, criado/alterado por e quando |
| Promoção | `promotionId`, código comercial, iniciativa, mecânica e versão da regra, descrição, público, segmentação, configuração |
| Linha | `lineId` estável, promoção, ciclo, CV, veículo, grupo, papel, step, região/segmento; não usar descrição na identidade |
| Premissas | Valores e versão de preço, comissão, impostos, custo, royalties, pontos, vigência, ativas e corredores |
| Draft | Alterações não aplicadas com `baseRevision`; recuperação automática sem mover o Cenário Inicial |
| Validação | `planId`, `revision`, versão das regras, instante, pendências por regra/alvo, ações bloqueadas |
| Pedido EOS | `requestId`, revisão, escopo, tipo, gate, idempotência, foto dos inputs, estados e mensagens do destino |
| Retorno EOS | Pedido de origem, identidade da linha, quantidade, modelo/qualidade, recebido em; decisão separada |
| Aprovação | Revisão e conteúdo aprovados, aprovador, decisão, comentário, instante |
| Snapshot | Conteúdo imutável, contexto por linha, versão, metadados e referências de cálculo/adoção |
| Evento | Quem/quando, ação, contexto, valores anterior/novo, motivo e correlação com pedido/job |

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.

| Regra | Tipo | Comportamento recomendado | Momento |
|---|---|---|---|
| Contexto herdado no cadastro | F: A59–A63 | Pesquisar somente CVs do recorte; validar em todos os ciclos escolhidos | Incluir/aplicar |
| Mesmo código em vários ciclos | F: A60 | Código único da promoção; linhas independentes por ciclo | Criação/duplicação |
| Vigência por ciclo | F: A57; P: mapa | VNPs elegíveis; impedir incluir produto sem vigência | Inclusão/validação |
| Campo obrigatório | F: Botão B42 + imagem | Marcação visível, erro junto ao campo e resumo navegável | Aplicar formulário |
| CV exato | F: Botão B43–B44 | Códigos como string; lista colada com encontrados/ausentes | Busca/inclusão |
| Preço ↔ desconto | F: A67; Botão B47–B48 | Atualização bidirecional imediata, guardando precisão acordada | Edição |
| Corredores | F: Botão B49; P: mapa | Avisar no salvamento; Boy bloqueia aprovação; bloqueio pré-EOS proposto, a validar | Salvar/avançar |
| Sem corredor | P/R | Mostrar “não validado”; encaminhar não resolve | Aviso; política de bloqueio D |
| Régua de pontos | P: mapa, regra 4 | Ausência impede input, com origem e ação | Incluir |
| Comissão/pontos | F: A124 | Consumir comissão e régua vigentes; exceção CPV requer definição completa | Cálculo |
| Inicial/trabalhado | F: A71–A75 | Base inicial estável; comparações com população equivalente | Durante edição/salvar |
| Autoria e data | F: A68/A87/A91 | Registrar quando aplicar/salvar, também no bloqueio | Mutação persistida |
| Cadeado de linha | F: A85–A91 | Trava todos os atributos e demanda | Editar/excluir/adotar |
| Ciclo/veículo bloqueado | F: A69; P: promocoes.js | Prevalece sobre desbloqueio de linha | Toda mutação do recorte |
| Exclusão | F: A69/A77 + imagem | Prévia da promoção, requisito/benefício e impacto; confirmar antes de executar | Excluir |
| Benefício pago/doado | F: A70 | Qtd benefício > 0; desconto 100% = Doado; demais = Pago | Cálculo da linha |
| ZEST e combo | F: A78–A80 | Expandir filhos, preservar pai, quantidade de componentes, sem dupla soma | Inclusão/cálculo |
| Agrupador | F: A81 | Expandir CVs e validar por ciclo | Inclusão |
| Segmento/grupo | F: A82–A83 | Picklist integrada com código + descrição | Cadastro |
| Edição em massa | F: A96–A106 | Percentual + operação + Unidades/UPC + prévia; validar conjunto | Aplicar lote |
| Unidades/UPC | F: A112–A114 | Conversão com ativas do próprio ciclo; sem ativas não dividir | Edição/cálculo |
| Passou pelo EOS | F: A120–A121 | Check somente após envio e estimativa recebida | Retorno |
| Mecânicas e descrição | F: Botão B50; aba Mecânicas | Campos condicionais e uma descrição por step quando necessário | Cadastro |
| Multiciclo Forecast | P: item 83 e promocoes.js | Escopo explícito e resposta por ciclo/linha | Solicitação/retorno |
| Quantidade revisada | P: Aurora, bloco 4 | Adoção explícita; ajuste exige justificativa | Revisão EOS |
| Foto imutável | P: RF-10.010 | Copiar valores e contexto da revisão, não referências mutáveis | Snapshot |
| Meta financeira | R | Aviso por ciclo; justificativa ao concluir com desvio | Revisão final |
| Aprovação | D | Definir papel, alçada e objeto antes de ativar gate oficial | Produção |

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.

| Métrica | Definição / situação |
|---|---|
| Desconto | `1 − Preço Por CF / Preço De`, com vínculo reverso. Base CB exige sua comissão/regra, não a fórmula CF aplicada diretamente. |
| UPC por ciclo | `Unidades / Ativas`. Ativas ausentes/zero produzem indisponibilidade e erro de edição por UPC. |
| Unidades a partir de UPC | `UPC × Ativas`, com regra de arredondamento a homologar. Demonstrador usa inteiros arredondados. |
| Produtividade | `RB / Ativas` do mesmo contexto. Não usar só o denominador do primeiro ciclo num consolidado multiciclal. |
| RB da planilha | BH14 registra `Unidades × Preço De × (1−Comissão) × (1−Desconto)`. |
| RB no código atual | `receitaDe` usa `Unidades × Preço Por`; a comissão é descontada depois em uma variável chamada RL. Isso diverge da planilha. |
| Margem bruta | Planilha BI14: `Receita Líquida − CMV − Royalties`. É preciso homologar a construção de RL, incidência de impostos e base de royalties. |
| Margem % consolidada | `Soma(MB) / Soma(RB)`, nunca média simples de percentuais de linha. RB zero deixa percentual indefinido. |
| Meta consolidada de MB% | Se metas estão em RB e MB%, ponderar pela RB alvo, somente quando todos os ciclos têm meta. Comparar também cada ciclo separadamente. |
| Variação | Proposta: `Trabalhado − Inicial`, com MB% em pontos percentuais. M4/O4 da planilha de exemplo usam sinais/razão diferentes dos demais campos; não copiar essas fórmulas sem homologar. |
| VNP anulado | Preservar linha para consulta e rastreio; contribuição quantitativa/financeira nula enquanto a condição de anulação vigorar. Excluir a promoção que anulava reavalia o baseline. |
| Vertical | Distribuir o volume total pelos ciclos efetivos uma única vez, conciliando o total de distribuição. Não alocar toda a quantidade ao ciclo inicial nem replicar 100% em cada ciclo. |
| Kit/combo | Somar a granularidade escolhida: pai ou filhos; jamais ambos. Preservar quantidade do kit × composição para demanda dos filhos. |

**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.

| Fonte na planilha | Destino no fluxo | Cobertura |
|---|---|---|
| A55, oito veículos | Montar / visão por veículo | Demonstrado, com público e cor; grade e quadro usam as mesmas linhas |
| A56, CRUD por superusuário | Administração contextual | Especificado; não criar nova etapa para o planejador |
| A57–A58, vigentes/VNP e promoções anteriores | Carregamento do plano / Base vigente | Carga automática por ciclo, sem duplicação e com promoções anteriores preservadas; cinco produtos demonstrativos, carga oficial ainda necessária |
| A59–A63, filtros e multiciclo | Preparar + Nova promoção | Demonstrado; catálogo local limitado, sem RBAC real |
| A64, anulação VNP | Promover / resultado do ciclo / retirada | Desconto simples, exceção RI, vínculo VNP/promoção, subtotais e restauração executados; parametrização oficial das demais mecânicas pendente |
| A65, cálculos de todas as colunas | Motor financeiro e campos derivados | Demonstrado núcleo RB/RL/CMV/MB/UPC; demais cálculos exigem contratos |
| A66–A68, salvar, desconto/preço, auditoria | Montar | Demonstrado |
| A69, excluir e cadeados | Seleção + confirmação + motor | Demonstrado; política por papel depende do backend |
| A70, benefício pago/doado | Nova promoção / grupos | Regra no motor; criação do grupo não demonstrada |
| A71–A75, cenários | Comparativo na etapa 2 | Demonstrado; iniciais preservados até salvar |
| A76, limites de caracteres futuros | Schema de campo configurável | Fonte não define números; não foram inventados |
| A77 / imagem Exclusão | Confirmação contextual | Confirmação demonstrada; prévia completa de grupos especificada |
| A78–A81, kits/combos/agrupadores | Grupos e precificação | Especificado; editor completo ainda necessário |
| A82–A83, códigos + descrições | Campos segmentação | Especificado; depende de picklists integradas |
| A85–A91, bloquear/desbloquear | Cadeado por linha | Demonstrado, com prioridade do ciclo/veículo no motor |
| A93, várias promos do mesmo produto | Identidade/composição | Estrutura permite; precedência e acumulação comercial pendentes |
| A96–A106, massa Unidades/UPC | Ajustar demanda em massa | Demonstrado com prévia e aplicação atômica na interface |
| A112–A114, conversão | Cálculo/edição de demanda | UPC calculado e ajuste percentual demonstrados; input absoluto de UPC no editor completo especificado |
| A120–A121, EOS | Montar / painel EOS | Estados separados e retorno simulado; integração não construída |
| A124, pontos | Motor oficial por país | Especificado; base/step/exceção CPV pendentes de homologação |
| Botão B42 + imagem de configuração | Campos obrigatórios | Editor simples demonstrado; obrigatoriedade condicional completa especificada |
| Botão B43–B44, CV exato | Nova promoção | Busca exata demonstrada; lista colada/agrupador especificados |
| Botão B45, população conforme mecânica | Editor em três seções | Especificado para todas as mecânicas |
| Botão B47–B49, CF/CB, slider e corredor | Precificação | Preço/desconto e aviso demonstrados; CB por nível no editor completo |
| Botão B50, descrição semiautomática | Nova promoção | Exemplo simples + catálogo completo; descrição por step especificada |
| Aba Picklists | Campos avançados | Fonte preservada; configuração de administração a implementar |
| Aba Visualização G4–G6 | Gerenciar campos / perfis master | Especificado; fora do demonstrador |
| Imagem Harmonização | Ajustes com prévia | Percentual de demanda demonstrado; harmonização por receita requer alavanca definida |
| Mecânicas B2:M29 | Configuração por mecânica | 28 modelos extraídos; desconto simples executável; demais disponíveis para consulta da estrutura |

### 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.

| Decisão | Evidência / por que importa | Recomendação para validação |
|---|---|---|
| RB, RL e comissão | BH14/BI14 divergem do código de `promocoes.js` | Homologar um exemplo numérico por país/público, com impostos e royalties, e usá-lo como teste de contrato. |
| Piso Boy e momento do bloqueio | Planilha pede aviso ao salvar; mapa afirma bloqueio de aprovação | Permitir salvar rascunho; definir se impede Forecast ou apenas aprovação/publicação. A proposta bloqueia antes do Forecast como hipótese visível. |
| Anulação do baseline | A64 depende da mecânica; mapa e código divergem sobre verticais e exceções | Configuração por país/mecânica/papel/requisito/veículo; não aplicar “toda ciclal anula” indiscriminadamente. |
| Acumulação de promoções do mesmo CV | A93 é uma pergunta aberta | Permitir identidade distinta; decidir coexistência, sobreposição, exclusividade e tratamento da demanda. |
| Mecânicas com flags vazios | H:M não está completo para as 28 linhas | Completar matriz com negócio; campo não definido não é opcional automaticamente. |
| Aprovação e alçadas | Documentação reconhece papel de aprovador não fechado | Definir quem aprova, se aprova linha/promoção/ciclo/plano, que desvios exigem alçada e qual evento libera publicação. |
| Preço alterado durante estimativa | CicloEstado permite preço editável; forecast usa inputs comerciais | Invalidar retorno para revisão alterada até contrato EOS permitir compatibilidade seletiva. |
| Metas, piso e exceções | Fluxo atual permite enviar mesmo abaixo da meta | Avisos por ciclo e justificativa na conclusão; definir quem pode aceitar e se falta de meta bloqueia algum gate. |
| Pontos / Crer Para Ver | A124 excepciona CPV, mas não define o resultado completo | Não assumir “CPV = zero” sem a regra oficial da régua e sua exceção. |
| Doações e DRE | Código diz “sem impacto financeiro”; preço zero não prova custo zero | Validar onde entram CMV/doações, sem apagar a linha da demanda ou inventar custo. |
| Harmonizar por receita | A imagem demonstra percentual e receita alvo, sem fórmula da alavanca | Definir se o sistema altera quantidade, preço ou composição; mostrar a prévia dos campos que serão modificados. |
| Produção multiciclal | Fontes admitem promoção e Forecast multiciclais | Definir aprovação/fechamento por ciclo ou conjunto. Padrão recomendado: resumo por ciclo e operação sobre conjunto explicitamente confirmado. |

## 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

| Cenário | Resultado esperado |
|---|---|
| Planejar 202701 e 202702 | Cada linha conserva seu ciclo; totais por ciclo conciliam com o consolidado. |
| Trocar para Chile | Dados brasileiros não aparecem no recorte chileno; continuam preservados no plano. |
| Incluir CV exato 713 | Somente 713 é considerado, respeitando permissão/vigência; não encontra outro CV por sufixo. |
| Criar mesma promoção em dois ciclos | Código comercial compartilhado; duas identidades de linha independentes. |
| Editar preço/desconto | Ambos se atualizam; receita, margem, corredor e resumo usam o mesmo valor. |
| Selecionar uma linha | Comparação usa os mesmos produtos/ciclos, incluindo VNP e promoções antes/depois; resumo global não muda. |
| Recarregar com rascunho | Alterações são recuperadas; Cenário Inicial continua sendo a versão salva. |
| Salvar ou descartar | Salvar move a referência; descartar restaura valores, não apenas o status. |
| Promo anula VNP | Baseline não duplica demanda/receita; excluir a promo reavalia o VNP. |
| Item bloqueado numa edição em massa | A seleção é reportada e não há aplicação silenciosa parcial. |
| Corrigir preço abaixo do Boy | Pendência some por cálculo; mudar novamente para abaixo traz a pendência de volta. |
| Solicitar sem salvar/verificar | Não cria pedido; informa a ação necessária. |
| Duplicar clique ou timeout de pedido | Mesma operação/idempotência, sem envio duplicado. |
| Alterar preço depois do envio | Foto enviada preservada; revisão e retorno incompatíveis são sinalizados. |
| Receber só parte das linhas | Mostra recebidas/faltantes e permite completar a mesma solicitação, preservando decisões; não conclui o conjunto prematuramente. |
| Adotar sugestões pendentes | Preserva ajustes manuais e demandas bloqueadas; linhas sem retorno continuam pendentes. |
| Consultar meta parcial | Nunca mostra “Na meta” como comparação completa; desvio de uma meta conhecida exige justificativa. |
| Alterar unidades EOS | Exige justificativa e preserva valor sugerido e adotado. |
| Concluir abaixo da meta | Aviso por ciclo e justificativa; política de aprovação segue decisão de negócio. |
| Gerar snapshot | Foto contém ciclo correto, preço efetivo, quantidade adotada, justificativa e premissas/revisão. |
| Reabrir plano concluído | Nova revisão com motivo; snapshot anterior permanece inalterado. |
| Falhar persistência/integração | Sem falso sucesso; mostrar estado recuperável e ação específica. |

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.