lucid.page PRD + SDD + Plano de Implementação — Grupo JB Pescados
Text size
Read time15 min

# PRD + SDD + Plano de Implementação — Grupo JB Pescados

# 1. Protocolo obrigatório para o agente implementador

Este documento é a fonte de verdade do projeto. O agente deverá trabalhar em uma etapa por vez e não iniciar a próxima antes de cumprir o respectivo critério de saída.

# Ordem das fontes de verdade

  1. Decisões registradas neste plano.
  2. Dados oficiais fornecidos pelo Grupo JB.
  3. Direção visual escolhida pelo usuário.
  4. PRD e SDD atualizados no repositório.
  5. Código e testes existentes.
  6. Suposições, somente quando explicitamente autorizadas.

# Regras contra alucinação

# Documentos que deverão ser mantidos

# 2. PRD — Product Requirements Document

# 2.1 Visão do produto

Criar uma plataforma digital própria do Grupo JB Pescados para representar institucionalmente o grupo, conectar clientes às quatro lojas, divulgar ofertas, direcionar contatos e registrar as principais interações digitais.

A primeira versão será uma plataforma operacional, composta por:

# 2.2 Públicos

# Clientes

Pessoas que desejam consultar ofertas, encontrar uma loja, falar pelo WhatsApp, entrar no Grupo VIP ou avaliar uma unidade.

# Marketing

Equipe responsável por encartes, ofertas, campanhas, links, conteúdo, SEO e métricas de todas as lojas.

# Gestores das lojas

Responsáveis por atualizar e acompanhar exclusivamente sua unidade.

# Administração geral

Responsável por usuários, permissões, configurações, auditoria e toda a plataforma.

# 2.3 Resultado esperado

# 2.4 Escopo funcional

# FR-01 — Site institucional

# FR-02 — Página da loja

Cada /lojas/[slug] deverá apresentar:

  1. Encarte/ofertas vigentes.
  2. Como chegar.
  3. WhatsApp.
  4. Grupo VIP.
  5. Avaliação no Google.
  6. Horários e contatos.
  7. Instagram, quando informado.
  8. Trabalhe Conosco.
  9. SAC.

A página deverá possuir conteúdo, metadados e Schema LocalBusiness próprios.

# FR-03 — Encartes

# FR-04 — Ofertas cadastradas

Cada oferta deverá conter:

Não haverá estoque, carrinho, pagamento ou reserva.

# FR-05 — Painel administrativo

Módulos:

# FR-06 — Usuários e permissões

# FR-07 — Campanhas, UTMs e QR Codes

# FR-08 — Analytics

O painel deverá medir:

Os eventos também serão enviados ao GA4 e Meta quando houver consentimento aplicável.

# FR-09 — SAC

# FR-10 — Trabalhe Conosco

# FR-11 — SEO

# FR-12 — LGPD e consentimento

# 2.5 Fora do escopo

# 3. SDD — Software Design Document

# 3.1 Arquitetura escolhida

As versões deverão ser estáveis, fixadas no lockfile e registradas no SDD durante a Etapa 1.

# 3.2 Estrutura de rotas

# Públicas

# Administrativas

# 3.3 Modelo de dados

# stores

Identidade, slug, descrição, endereço estruturado, coordenadas, contatos, horários, links externos, imagens, dados de SEO, destinatário do SAC e estado de publicação.

# user_profiles

Referência ao usuário autenticado, nome, perfil, filial associada e estado ativo.

# flyers e flyer_stores

Título, slug, imagem, PDF, período, estado, destaque, ordem e associação com filiais.

Regra: uma filial poderá ter vários encartes vigentes, mas apenas um marcado como principal.

# offer_categories

Nome, slug, ordem e estado.

# offers e offer_stores

Produto, categoria, preço decimal, unidade, imagem, descrição, período, destaque, ordem e lojas participantes.

# campaigns

Nome, slug, período, canais, UTMs padrão, observações e estado.

Código único, tipo, destino, filial, campanha, estado e datas.

# interaction_events

Evento, filial, encarte, oferta, campanha, link, sessão anônima, página, origem, UTMs, dispositivo, versão do consentimento, horário e metadados sanitizados.

# audit_logs

Autor, ação, entidade, filial, resumo anterior/posterior, horário e identificador técnico da requisição.

# sac_delivery_logs

Filial, categoria, provedor, identificador do envio, resultado e horário. Não armazenará nome, contato, assunto ou mensagem.

# site_settings

Configurações globais como ATS, e-mail central, redes, identidade, consentimento e integrações.

# 3.4 Matriz de permissões

Recurso Administrador Marketing Gestor
Configurações globais Editar Consultar Não acessar
Usuários Gerenciar Não acessar Não acessar
Todas as lojas Gerenciar Gerenciar Não acessar
Própria loja Gerenciar Gerenciar Gerenciar
Encartes e ofertas Todas Todas Própria loja
Campanhas e QR Codes Todas Todas Própria loja
SEO Todas Todas Própria loja
Dashboard geral Acessar Acessar Não acessar
Dashboard da loja Acessar Acessar Própria loja
Logs Todos Próprias ações Próprias ações

A restrição deverá existir no banco e no servidor; ocultar botões não será considerado segurança.

# 3.5 Interfaces

# POST /api/events

Recebe somente eventos de uma lista permitida. Valida e remove metadados não reconhecidos. Aplica limitação de requisições e não aceita PII.

# GET /r/[trackingCode]

Valida código ativo, registra qr_redirect ou tracked_link_redirect e redireciona para a URL cadastrada.

# POST /api/sac

Valida campos, consentimento e desafio antispam, envia o e-mail e grava somente o resultado técnico da entrega.

# Operações administrativas

O CRUD interno deverá usar Server Actions ou serviços de servidor tipados. Nenhuma alteração administrativa deverá ser feita diretamente pelo navegador no banco sem RLS.

# 3.6 Eventos padronizados

A atribuição usará, nesta ordem:

  1. UTMs da URL.
  2. Metadados do link/QR Code.
  3. Referrer conhecido.
  4. Acesso direto.

A atribuição não direta mais recente será mantida na sessão por até 30 dias, respeitando o consentimento.

# 3.7 Regras operacionais

# 3.8 Segurança e retenção

# 4. Plano de implementação por etapas

# Etapa 0 — Fechamento de insumos

# Entradas obrigatórias

# Trabalho

# Critério de saída

PRD aprovado e nenhuma informação estrutural marcada como ambígua. Dados ainda ausentes podem permanecer pendentes, mas devem possuir responsável e bloquear apenas a publicação, não o desenvolvimento.

# Etapa 1 — Fundação técnica

# Trabalho

# Testes

# Critério de saída

Projeto executa localmente e o pipeline passa sem avisos críticos.

# Etapa 2 — Direção visual obrigatória

# Trabalho

# Regra

Nenhum frontend definitivo deverá ser implementado antes da escolha visual.

# Critério de saída

Uma única direção visual aprovada e documentada com referências suficientes para impedir interpretações do agente.

# Etapa 3 — Banco, autenticação e permissões

# Trabalho

# Testes

# Critério de saída

Autenticação, permissões e migrations validadas por testes automatizados.

# Etapa 4 — Site público e páginas das lojas

# Trabalho

# Testes

# Critério de saída

Site público funcional com dados DEMO claramente identificados e fidelidade visual aprovada.

# Etapa 5 — Encartes e catálogo de ofertas

# Trabalho

# Testes

# Critério de saída

Marketing e gestores conseguem publicar e remover ofertas sem alterar código.

# Etapa 6 — Campanhas, rastreamento e QR Codes

# Trabalho

# Testes

# Critério de saída

Matriz de eventos validada com evidência de cada ação prioritária.

# Etapa 7 — Dashboard

# Trabalho

# Testes

# Critério de saída

Os números do painel são reproduzíveis a partir do banco de eventos.

# Etapa 8 — SAC, ATS e consentimento

# Trabalho

# Testes

# Critério de saída

Fluxos validados com e-mails e URLs de homologação.

# Etapa 9 — SEO, acessibilidade e performance

# Trabalho

# Critérios de aceite

# Etapa 10 — Conteúdo real e homologação

# Trabalho

# Bloqueio automático

O build de produção deverá falhar caso encontre TODO_CONTENT, credenciais de teste ou links demonstrativos.

# Critério de saída

Checklist de homologação assinado e zero defeitos críticos ou altos.

# Etapa 11 — Publicação e acompanhamento

# Trabalho

# Critério de saída

Site público acessível no domínio oficial, painel protegido, analytics recebendo eventos e plano de reversão testado.

# 5. Testes globais obrigatórios

# 6. Formato de entrega entre agentes

Ao concluir uma etapa, o agente deverá entregar:

Contents
  1. Etapa concluída e critério de saída.
  2. Comportamentos implementados.
  3. Migrations e variáveis adicionadas.
  4. Testes executados com resultado.
  5. Evidências visuais quando houver interface.
  6. Pendências reais, sem sugestões especulativas.
  7. Riscos identificados.
  8. Próxima etapa permitida.
  9. Pergunta objetiva ao usuário somente quando existir um bloqueio decisório.

# Premissas finais

A primeira ação do agente implementador deverá ser executar somente a Etapa 0 e devolver a matriz de informações confirmadas, pendentes e bloqueadoras.

End