134 lines
4.1 KiB
Markdown
134 lines
4.1 KiB
Markdown
# Decisions Log
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Posicionar a solução como app de gestão operacional de revenda de roupa e não apenas como app de inventário.
|
|
|
|
### Motivo
|
|
O principal valor está no controlo do fluxo completo: encomenda, receção, registo, preparação, venda e envio.
|
|
|
|
### Impacto
|
|
A arquitetura funcional será orientada a estados e workflows operacionais.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Excluir integração automática com Vinted da V1.
|
|
|
|
### Motivo
|
|
A prioridade é resolver as dores operacionais principais sem aumentar complexidade técnica inicial.
|
|
|
|
### Impacto
|
|
As vendas serão registadas manualmente na primeira versão.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Documentar o projeto em múltiplos ficheiros Markdown curtos e temáticos.
|
|
|
|
### Motivo
|
|
Facilitar continuidade entre sessões e colaboração com agentes de IA.
|
|
|
|
### Impacto
|
|
A documentação passa a ser a fonte de verdade do projeto.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Adotar uma stack full-stack baseada em Next.js 16, TypeScript, PostgreSQL, Prisma ORM, Supabase, Tailwind CSS, shadcn/ui, React Hook Form e Zod.
|
|
|
|
### Motivo
|
|
Esta combinação maximiza velocidade de desenvolvimento, simplicidade arquitetural, boa compatibilidade com agentes de IA e capacidade de crescimento sem infraestrutura excessiva.
|
|
|
|
### Impacto
|
|
O MVP será desenvolvido numa única codebase full-stack com frontend e backend no mesmo projeto.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Não criar backend separado na V1.
|
|
|
|
### Motivo
|
|
A operação inicial não justifica microserviços nem uma API separada. O foco é reduzir complexidade e acelerar entrega.
|
|
|
|
### Impacto
|
|
As rotas, ações no servidor, serviços e acesso à base de dados ficam dentro do projeto Next.js.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Usar PostgreSQL como base de dados principal e Prisma ORM como camada de acesso aos dados.
|
|
|
|
### Motivo
|
|
É uma combinação robusta, legível, type-safe e adequada ao domínio operacional da aplicação.
|
|
|
|
### Impacto
|
|
O schema do domínio será modelado em Prisma e evoluído por migrations.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Implementar rastreabilidade por unidade de inventário em vez de stock agregado.
|
|
|
|
### Motivo
|
|
A documentação do domínio especifica que a V1 deve favorecer rastreabilidade por unidade sempre que possível para dar visibilidade operacional completa.
|
|
|
|
### Impacto
|
|
O schema Prisma foi modelado com InventoryUnit como entidade principal, permitindo rastrear cada artigo individualmente desde a receção até à venda.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Criar DOC_INDEX.md como registo centralizado da documentação do projeto.
|
|
|
|
### Motivo
|
|
Facilitar a navegação e continuidade entre sessões de desenvolvimento com agentes de IA, garantindo que todos os documentos nucleares são facilmente encontráveis.
|
|
|
|
### Impacto
|
|
O projeto tem agora um índice completo com 27 ficheiros documentais, todos classificados por status e função.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Modelar todos os estados definidos na documentação como enums no schema Prisma.
|
|
|
|
### Motivo
|
|
Garantir consistência entre a documentação de estados e a implementação técnica, evitando ambiguidades nos ciclos de vida das entidades.
|
|
|
|
### Impacto
|
|
Os enums PurchaseOrderStatus, ReceiptStatus, InventoryStatus, ListingStatus, SaleStatus e ShipmentStatus foram implementados exatamente conforme definido em `09_STATES_AND_LIFECYCLES.md`.
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Corrigir problemas de integridade relacional no schema Prisma.
|
|
|
|
### Motivo
|
|
Validação do schema revelou relações em falta e inconsistências que poderiam causar problemas de integridade de dados.
|
|
|
|
### Impacto
|
|
- Adicionada relação User.createdReceipts para Receipt.created_by
|
|
- Corrigida relação StatusHistory com índices para performance
|
|
- Mantida integridade referencial em todas as relações
|
|
|
|
---
|
|
|
|
## 2026-04-21
|
|
### Decisão
|
|
Criar estrutura completa do projeto Next.js com stack aprovada.
|
|
|
|
### Motivo
|
|
Estabelecer base técnica sólida para desenvolvimento do MVP seguindo exatamente a stack definida na documentação.
|
|
|
|
### Impacto
|
|
Projeto configurado com Next.js 16, TypeScript, Tailwind CSS, Prisma, estrutura de pastas conforme `20_PROJECT_STRUCTURE.md`, pronto para instalação de dependências e início de desenvolvimento.
|