Skip to main content

Requisitos — [Front][App] Ajuste de layout nova vitrine

Task #197313​

Task pai: US 196053 ADRs relacionados: — AS-IS validado: context/AS-IS.md

Status: refinado Sessão de grilling: 25/06/2026 — refinamento com base na US 196053, contrato de API (frontend-contract-diff.md), referências visuais e código do App

Visão geral​

Adaptar o fluxo de Minhas Vitrines no App Flutter (coezzion_vendas_app) para suportar a modalidade Vitrine de Estoque da Loja (showCaseType = 4 / SellerStock), coexistindo com a vitrine personalizada atual (showCaseType = 1 / Store).

A task cobre exclusivamente alterações de layout e DTOs no App: bottom sheet de escolha de modalidade, integração do endpoint v2 da listagem com hasSellerStock, fluxo de criação sem seleção de produtos e tela de detalhe condicionada ao tipo de vitrine.

Papéis​

PapelResponsabilidade
VendedorCria, visualiza, compartilha e edita data de expiração das vitrines no App
App (Flutter)Renderiza layouts, consome APIs show-case-new e aplica regras por showCaseType
API Show CasePersiste vitrines, retorna hasSellerStock, showCaseType e totalItems

Requisitos​

RF-01 — Listagem com endpoint v2 e flag hasSellerStock​

User Story: Como vendedor, eu quero que a listagem de Minhas Vitrines reflita se já possuo uma Vitrine de Estoque da Loja ativa, para que o App saiba quando bloquear uma nova criação dessa modalidade.

Acceptance Criteria:

  1. WHEN o App carrega a listagem de Minhas Vitrines THEN o App SHALL consumir GET /api/show-case-new/v2/store/{storeId} no lugar do endpoint v1.
  2. WHEN a API retorna a listagem paginada THEN o App SHALL parsear os campos data, total, pageNumber, pageSize e hasSellerStock conforme o contrato em frontend-contract-diff.md.
  3. WHEN hasSellerStock é true THEN o App SHALL armazenar esse estado no controller da listagem para uso no bottom sheet de criação.
  4. WHEN hasSellerStock é false THEN o App SHALL permitir a criação de uma nova Vitrine de Estoque da Loja.
  5. WHEN a listagem é exibida THEN o App SHALL manter o comportamento atual de busca, paginação infinita e navegação para o detalhe ao tocar em um item.

RF-02 — Bottom sheet de escolha de modalidade ao criar vitrine​

User Story: Como vendedor, eu quero escolher o tipo de vitrine ao clicar em "CRIAR VITRINE", para decidir entre compartilhar o estoque completo da loja ou criar uma vitrine personalizada.

Acceptance Criteria:

  1. WHEN o vendedor toca no botão CRIAR VITRINE na tela Minhas Vitrines THEN o App SHALL exibir um bottom sheet com título Escolha uma opção e botão de fechar, conforme referência visual context/image-1.png.
  2. WHEN o bottom sheet é exibido THEN o App SHALL apresentar a opção Vitrine do estoque da loja com badge Nova e descrição Crie uma vitrine com todos os produtos do estoque da loja..
  3. WHEN o bottom sheet é exibido THEN o App SHALL apresentar a opção Criar nova vitrine com descrição Crie vitrines personalizadas escolhendo os produtos ideais para cada cliente..
  4. WHEN o vendedor seleciona Criar nova vitrine THEN o App SHALL iniciar o fluxo atual de criação via ShowCaseSearchProducts (showCaseType = 1).
  5. WHEN o vendedor seleciona Vitrine do estoque da loja e hasSellerStock é false THEN o App SHALL iniciar o fluxo de criação da Vitrine de Estoque da Loja (RF-03).
  6. WHEN hasSellerStock é true THEN o App SHALL manter a opção Vitrine do estoque da loja visível porém desabilitada para toque.
  7. WHEN hasSellerStock é true THEN o App SHALL exibir abaixo do título da opção a mensagem Você já possui uma Vitrine de Estoque ativa. Apenas uma vitrine desta modalidade é permitida por vez., conforme context/image-2.png.
  8. WHEN o vendedor fecha o bottom sheet sem selecionar THEN o App SHALL retornar à listagem sem alterar o estado.

RF-03 — Criação da Vitrine de Estoque da Loja​

User Story: Como vendedor, eu quero criar uma vitrine com todo o estoque da loja sem selecionar produtos manualmente, para compartilhar o catálogo completo com menos esforço operacional.

Acceptance Criteria:

  1. WHEN o vendedor inicia o fluxo de Vitrine de Estoque da Loja THEN o App SHALL exibir tela com título Estoque da loja, conforme context/image-3.png.
  2. WHEN a tela de criação é exibida THEN o App SHALL apresentar o campo Nome pré-preenchido com Estoque da loja e desabilitado para edição.
  3. WHEN a tela de criação é exibida THEN o App SHALL apresentar o campo Data de expiração editável, respeitando o intervalo já existente no fluxo de vitrines (mínimo amanhã, máximo 31 dias a partir de hoje).
  4. WHEN o vendedor confirma a criação THEN o App SHALL enviar POST /api/show-case-new com showCaseType = 4, showCaseItems = [] e os demais campos obrigatórios de CreateShowCaseRequest.
  5. WHEN a API retorna sucesso na criação THEN o App SHALL navegar para a tela de detalhe da vitrine criada ou exibir o bottom sheet de ações (Visualizar / Compartilhar / Copiar link), mantendo o padrão já usado em ShowCaseBottomSheet.
  6. WHEN a API retorna erro por vitrine SellerStock já existente THEN o App SHALL exibir mensagem de erro compreensível ao vendedor e não criar duplicata.
  7. WHEN o fluxo de criação SellerStock está ativo THEN o App SHALL NOT exibir etapa de busca ou seleção de produtos (ShowCaseSearchProducts).

RF-04 — Detalhe da vitrine condicionado ao showCaseType​

User Story: Como vendedor, eu quero visualizar e gerenciar vitrines de estoque da loja com layout e regras distintas das vitrines personalizadas, para não tentar editar campos que o negócio restringe.

Acceptance Criteria:

  1. WHEN o App carrega o detalhe via GET /api/show-case-new/app/{showCaseId} THEN o App SHALL parsear os campos showCaseType e totalItems em ShowCaseDetailResponse.
  2. WHEN showCaseType = 1 (Store) THEN o App SHALL manter o layout e comportamento atuais da tela de detalhe (nome editável, seleção/remoção de produtos, botão ADICIONAR PRODUTOS).
  3. WHEN showCaseType = 4 (SellerStock) THEN o App SHALL exibir o título da AppBar como Estoque da loja.
  4. WHEN showCaseType = 4 THEN o App SHALL exibir o campo Nome com valor fixo Estoque da loja desabilitado para edição.
  5. WHEN showCaseType = 4 THEN o App SHALL exibir a seção de produtos com label Confira os produtos e contagem "{totalItems} produtos recomendados", usando totalItems e não showCaseItems.length.
  6. WHEN showCaseType = 4 THEN o App SHALL exibir no máximo 4 cards de produtos a partir de showCaseItems (prévia) e link Todos os produtos quando totalItems for maior que 4.
  7. WHEN showCaseType = 4 THEN o App SHALL NOT exibir botão ADICIONAR PRODUTOS, ícones de remoção de produto nem fluxo de edição de listagem.
  8. WHEN showCaseType = 4 e o vendedor altera apenas a data de expiração THEN o App SHALL enviar PUT /api/show-case-new com showCaseType = 4 contendo somente dateExpiration efetivo (demais campos ignorados pela API).
  9. WHEN showCaseType = 4 THEN o App SHALL manter as ações Visualizar, Compartilhar e Copiar link na seção Escolha uma opção.
  10. WHEN showCaseType = 4 THEN o App SHALL manter os botões ATUALIZAR VITRINE (habilitado somente se a data de expiração mudou) e EXCLUIR VITRINE.

RF-05 — DTOs e requests atualizados​

User Story: Como desenvolvedor do App, eu quero que os models reflitam o contrato da API, para serializar e desserializar corretamente os novos campos da modalidade SellerStock.

Acceptance Criteria:

  1. WHEN o App serializa criação ou atualização de vitrine THEN CreateShowCaseRequest e UpdateShowCaseRequest SHALL incluir o campo showCaseType.
  2. WHEN o App desserializa o detalhe THEN ShowCaseDetailResponse SHALL incluir showCaseType (int) e totalItems (int).
  3. WHEN o App desserializa a listagem v2 THEN o model de resposta paginada SHALL expor hasSellerStock (bool) além da lista de vitrines.
  4. WHEN showCaseType = 4 na criação THEN o App SHALL enviar showCaseItems como lista vazia independentemente de estado local.

Fora de Escopo​

  • Experiência da cliente na vitrine web (abas Recomendados / Mais produtos) — coberto pela task 197194
  • Nova URL de vitrine SellerStock — coberto pela task 197189
  • Integração de eventos Rewards específicos da modalidade SellerStock — coberto pela task 197192
  • Alterações de backend e contratos de API — coberto pelas tasks 197190 e 197191
  • Vitrines recomendadas por cliente (recommend) e vitrines de marca (brand)
  • Testes automatizados e documentação de QA

Dependências​

DependênciaDescriçãoStatus
197190Backend com endpoints v2, showCaseType e hasSellerStock disponíveisPendente
frontend-contract-diff.mdContrato de API validado para DTOs e regras por tipoDisponível
AS-IS.mdMapeamento do código atual do AppDisponível
Referências visuais Figmacontext/image.png a image-3.pngDisponível
197192Eventos Rewards específicos pós-criação/compartilhamento SellerStockPendente (não bloqueia layout)