# SheikBras Marketplace. Monorepo (pnpm + Turborepo) com web em Next.js, domínio em TypeScript puro e design system. ## Rodar ```bash pnpm install pnpm dev # gera tokens e abre http://localhost:3000 pnpm --filter @sheikbras/mobile start # app Expo (use o Expo Go ou um emulador) pnpm test # testes do domínio (busca, filtros, carrinho) pnpm typecheck ``` Requisitos: Node 20+, pnpm 9. ## Estrutura | Pasta | Função | |---|---| | `packages/tokens` | `tokens.json` (fonte única) → `tokens.css`. Tema claro padrão; escuro só com `data-theme="dark"` | | `packages/domain` | Tipos, catálogo de demonstração, **busca por intenção**, **filtros dinâmicos por categoria**, carrinho, pedidos. Sem React: reaproveitável no app mobile e no backend | | `packages/ui-web` | Design system web: Logo, ProductCard v2, Header, SearchBox, BottomNav, Hero, FilterGroups, Sheet, etc. Recebe o `Link` do roteador por contexto | | `packages/api-client` | Cliente tipado da API para web e app: renova a sessão sozinho (uma vez, compartilhado entre chamadas simultâneas), mapeia erros (`ApiError` com código e campos), chave de idempotência nos pedidos. Testado contra o núcleo do backend | | `packages/ui-native` | Design system nativo (React Native + SVG): tema, ícones/ilustrações (mesmo sprite da web), ProductCard, Button, Field, Sheet, BottomTabs | | `apps/mobile` | App Expo (Android/iOS, Expo Router): Início, Categorias, Carrinho, Pedidos, Conta, Busca com filtros, Produto, Login, Cadastro, Checkout | | `apps/api` | API NestJS: contas (login, refresh com rotação, 2FA, recuperação de senha, verificação de e-mail), LGPD, vendedores (KYC), catálogo e busca (OpenSearch), pedidos, pagamentos e frete (portas). Núcleo sem framework, testado | | `apps/web` | Next.js (App Router): Home, Busca, Produto, Carrinho, Checkout, Pedidos, Favoritos, Categorias, Conta | | `logo/` | SVGs da logo aprovada (Duplo arco) | | `prototype/` | Protótipos HTML (loja, app nativo, **painéis de vendedor e administrador**), referência visual | | `docs/` | ADRs | ## Dados e imagens O componente visual não conhece a fonte dos dados: `ProductCard` recebe um `Product` (`packages/domain/src/types.ts`). - Para usar foto real, preencha `imageUrl`; sem ela o card mostra a ilustração `art`. - O catálogo de demonstração está em `packages/domain/src/catalog.ts`. Troque por chamadas à API mantendo o tipo `Product`. ## Imagens reais dos produtos 1. Reúna as fotos (JPG, PNG ou WebP). Nomeie pelo **id do produto** (`3.jpg`) ou pelo **código da ilustração** (`p-phone.png`, vale também para as variantes do produto). 2. `pnpm images -- --in ./fotos` gera WebP em 400/800/1200 px (quadrado, fundo branco, sem cortar o produto) em `apps/web/public/products` e atualiza o manifesto `packages/domain/src/images.ts`. 3. Os cards e a página de produto passam a usar as fotos (com `srcset`). Produto sem foto continua com a ilustração. Em produção, as fotos vêm do upload dos vendedores (armazenamento + CDN + o mesmo processamento) e chegam pelo campo `imageUrl`. Use apenas fotos que você tenha direito de usar: próprias, do fornecedor ou de bancos com licença comercial. ## Backend (API) ```bash docker compose up -d # Postgres 16, Redis 7 e OpenSearch 2 para desenvolvimento cp apps/api/.env.example apps/api/.env # preencha os segredos (comandos no próprio arquivo) pnpm --filter @sheikbras/api migrate # aplica as migrações SQL pnpm --filter @sheikbras/api start:dev # API em http://localhost:3333/v1 pnpm --filter @sheikbras/api seed # vendedor de demonstração + 12 produtos publicados pnpm --filter @sheikbras/api test # 43 testes (núcleo, regras de negócio e contrato do cliente da API) ``` **Situação completa e o que falta: `docs/STATUS.md`.** Contrato em `docs/API.md`; regras de negócio assumidas em `docs/BUSINESS-RULES.md` (**confirme os valores**); segurança, LGPD e o que falta em `docs/SECURITY.md`. Provedores de pagamento e frete são “fake”: a API **recusa subir em produção** com eles até você implementar os adaptadores reais. **Verificado:** 43 testes do backend e do cliente da API (inclui avaliações verificadas e extrato do vendedor) (senha, JWT, TOTP com vetores do RFC, cadastro, login, bloqueio, refresh e reuso, 2FA, recuperação de senha, verificação de e-mail, vendedores e KYC, pedidos, estoque, comissão, idempotência, webhook assinado, cancelamento e reembolso, vencimento, LGPD, catálogo, busca, consulta OpenSearch); código inteiro compila em modo estrito com tipos simulados do Nest/pg; colunas do código batem com as migrações. **Não verificado (sem Postgres/Redis/OpenSearch/rede aqui):** execução das migrações, adaptadores `infra/*`, a camada NestJS rodando e a busca real no OpenSearch. Espere ajustes no primeiro `docker compose up` + `migrate` + `start:dev`. ## Contas na web e no app (login, cadastro, recuperação de senha) - **Web:** páginas `/entrar`, `/cadastro`, `/recuperar-senha`, `/redefinir-senha`, `/verificar-email`. Com `NEXT_PUBLIC_API_URL`, o login passa por rotas do próprio site (`/api/session/*`): o **refresh token fica em cookie httpOnly** (JavaScript não o enxerga, `SameSite=Strict`, checagem de origem contra CSRF) e o access token só na memória da página. Sem a variável, o site funciona em modo demonstração. - **App:** com `EXPO_PUBLIC_API_URL`, usa a API real e guarda os tokens no cofre do aparelho (`expo-secure-store`). Pede o código de 2 etapas quando a conta tem. - **Checkout** exige estar logado (web e app). - **Ainda em modo demonstração, mesmo com a API ligada:** catálogo, busca, carrinho e criação de pedidos. Eles dependem de uma única mudança (trocar o catálogo fictício pelo da API, que traz os ids reais); fazer isso antes de subir a API e testar contra o OpenSearch real seria chute. É o próximo passo. ## Estado de verificação Verificado: 10 testes do domínio (passam); todo o código compila com `tsc` (modo estrito no domínio); renderização no servidor de todas as telas e componentes conferida com um ambiente simulado. **Não verificado:** `pnpm install`, `next build` e `next dev` reais (sem acesso à rede no ambiente de desenvolvimento). Espere pequenos ajustes no primeiro build. ## App nativo: observações - Login e cadastro usam um **serviço de demonstração local** (`apps/mobile/lib/auth.tsx`, interface `AuthService`). Não é segurança: serve para validar a experiência. Na fase de backend troca-se pela API (Argon2/bcrypt, tokens, MFA) sem mexer nas telas. - Validações de conta (e-mail, força de senha, CPF) ficam em `packages/domain/src/auth.ts` e são as mesmas para web, app e backend. - As versões do Expo (SDK 53) e das bibliotecas devem ser confirmadas com `npx expo install --fix` no primeiro uso. - Verificação feita: compila com `tsc` (estrito) e as 12 telas renderizam num ambiente simulado. **Não testado em aparelho ou emulador.** ## Próximas etapas 1. Subir a API no seu servidor e testar ponta a ponta (migrações, Postgres, Redis, OpenSearch). 2. Trocar catálogo, busca, carrinho e pedidos pelos da API (web e app); telas de segurança da conta (2 etapas, trocar senha, excluir conta). 3. Escolher e integrar o provedor de pagamento e o de frete. 4. Devoluções, disputas, repasse ao vendedor e notificações. 5. Portar os painéis (`prototype/sheikbras-paineis.html`) para o Next.js e ligar as rotas HTTP de avaliações e financeiro.