AureaCustodiaMVP
Plataforma de trading da Áurea Custódia, em formato MVP simplificado para publicação imediata.
Refatoração do MVP monolítico (aurea-mvp-teste.html, 2.816 linhas num arquivo só) para
Next.js 15 (App Router) + TypeScript, pronta para publicar na Vercel.
| |
|---|
| Empresa | AUREA CUSTODIA LTDA — CNPJ 68.071.452/0001-06 |
| Origem | ../aurea-mvp-teste.html (v4) |
| Documentação de referência | ../Aurea_Custodia_Documento_Tecnico_MVP.md · ../Aurea_Custodia_Mapa_de_Telas_e_Rotas.md · ../Aurea_Custodia_Diagnostico_Mobile.md |
Subir o projeto
npm install
npm run dev
Abre em http://localhost:3000. Sem nenhuma variável de ambiente o app funciona: usa o
store em memória e semeia as 7 contas de teste (senha 12345678). O estado se perde quando o
processo reinicia — para persistir, veja Persistência abaixo.
O que mudou em relação ao MVP
1. O window.storage morreu, e era ele que segurava tudo
O MVP dependia de uma API de armazenamento compartilhado que só existe no ambiente de
artefatos — nenhum navegador oferece, nenhuma hospedagem fornece. Era o item registrado na
Seção 4.2 do documento técnico como "o parágrafo mais importante".
No lugar entrou uma interface de persistência plugável (src/server/store/), com três
implementações e seleção automática por variável de ambiente. O ponto único de troca que o
MVP preparou de propósito (loadState/saveState) virou src/server/state.ts.
2. A regra de negócio saiu do navegador
No MVP a lógica rodava no cliente, onde qualquer pessoa com o console aberto podia alterá-la.
Agora toda mutação é uma Server Action (src/server/actions/) que revalida no servidor:
posse da moeda, saldo, existência da oferta. O cliente pede; quem decide é o servidor.
3. Uma tela = uma URL
O MVP era página única, com display:none alternando containers e nenhuma URL por tela.
Agora cada tela tem rota real — o que a Seção 8 do mapa de rotas já propunha para produção.
4. As logos saíram do JavaScript
Eram dois data-URIs base64 de 41 mil caracteres dentro do bundle. Viraram arquivos em
public/brand/ (11 KB + 19 KB), servidos com cache.
O que não mudou (de propósito)
Isto é um port fiel. Mesmas regras, mesmos números, mesmas mensagens:
- comissão de 0,5% + R$ 1,00 por moeda negociada
- faixas de custódia anual R$ 5 / 15 / 25 / 30 / 60
- casamento de ordens por prioridade preço-tempo, uma unidade por volta
- mediana de 24h como valor estimado do recibo (agora calculada por tipo de moeda)
- dinheiro sempre em centavos inteiros
- senhas em texto puro — continua sendo ambiente de teste (ver Pendências)
As seis divergências autorizadas do port · LISTA ENCERRADA EM 28/08/2026
Registro histórico. Esta lista cobre o período de refatoração do monolito
aurea-mvp-teste.html para Next.js, concluído no commit 8e0f0a5. Ela provava que o port
foi fiel, exceto nos seis pontos abaixo, todos revisados e aprovados pelos sócios.
Está encerrada e não recebe itens novos. O monolito deixou de ser referência quando o
repositório passou a receber funcionalidade que nunca existiu nele. Mudanças de
comportamento a partir daqui são registradas em docs/diario/VERSION_COMPARISON_DAILY.md,
que é append-only e tem data e hora por entrada.
O que continua exigindo decisão dos sócios antes de mudar é a superfície protegida
descrita no CLAUDE.md: src/domain/constants.ts + fees.ts + market.ts +
types.ts, o contrato de src/server/store/types.ts e as Server Actions — não mais a
comparação com o monolito.
O port é fiel inclusive nos defeitos, com exatamente seis exceções, revisadas e aprovadas
pelos sócios. Quem comparar o comportamento com aurea-mvp-teste.html vai achar só estas:
parsePrice deixou de errar 100x. O original apagava todos os pontos antes de tratar a
vírgula, então 250.00 digitado no padrão americano virava R$ 25.000,00 em silêncio, num
campo de texto livre cujo valor vira ordem de venda real. A regra agora olha o último grupo
depois do ponto: 3 dígitos é milhar (1.500 → R$ 1.500,00), 1 ou 2 é decimal (250.00 →
R$ 250,00). Havendo vírgula, ela manda — todo formato brasileiro dá o mesmo resultado de antes.
matchOrders não permite mais compra fantasma. O motor movia o dinheiro e só então
chamava transferCoin, ignorando o retorno: se a oferta apontasse para uma moeda fora do
inventário do vendedor, o saldo trocava de mãos e a moeda não, com o histórico registrando
uma negociação que não aconteceu. A transferência passou a vir antes; falhando, a oferta
órfã sai do livro sem mover saldo nem gravar negociação.
buyLot também não permite mais compra fantasma. O mesmo defeito existia na compra
direta de um lote, num caminho de código separado do motor. Como aqui a compra é de N
moedas de uma vez, o resultado é por unidade: cada oferta órfã é descartada sozinha, sem
contaminar as boas do mesmo lote, e o comprador paga apenas pelo que recebeu. Se o lote
inteiro for órfão, nada de saldo nem de histórico — e as ofertas mortas saem do livro de
qualquer forma, para não reaparecerem ao próximo comprador.
O botão de vender em "Minhas moedas" voltou aos 44px no celular. A correção nº 6 do
diagnóstico mobile estabeleceu 44px como alvo mínimo de toque, mas
.acct-row .a-actions .btn{min-height:38px} derrubava isso por ser mais específico
(0,3,0 contra 0,1,0) — justamente no botão mais clicado da tela de conta no celular. O
override saiu de responsive.css em vez de ganhar o valor duplicado, então o alvo herda a
regra geral e não sobram dois números para divergir. O único efeito visual é a terceira
linha do cartão ficar 6px mais alta.
以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗
