Arandu — Financial Procurement
Direção de produto v3.7: uma plataforma financeira B2B com ofertas-alvo Arandu Essencial, Arandu Gestão e Arandu Enterprise adaptadas à complexidade do cliente, além da experiência Arandu Instituições para bancos e adquirentes convidados. O comprador deve obter valor mesmo sem adesão bancária; contratos, relacionamento e propostas externas com proveniência fazem parte do ciclo pretendido. Isto é decisão estratégica, não anúncio de planos comercializados ou novas funcionalidades prontas. Leia docs/ARANDU_PRODUCT_ENGINEERING_GUIDELINES.md §§39–44, docs/ARANDU_SEGMENTED_PRODUCT_OPERATING_MODEL_V37.md e docs/ARANDU_V37_EVIDENCE_AND_DECISION_GATES.md. Até 29/10, link público fiel e estação local READY (§37) continuam P0.
Arandu é uma plataforma B2B de procurement financeiro. Ela ajuda empresas a
estruturar uma demanda financeira, solicitar propostas a vários bancos e
provedores, comparar as condições lado a lado, decidir com aprovação interna e
acompanhar o contrato até a renovação.
Produtos cobertos hoje:
- crédito empresarial (capital de giro, antecipação de recebíveis e afins);
- adquirência (MDR, PIX, antecipação, liquidação, gateway).
O Arandu não concede crédito, não decide crédito, não movimenta
dinheiro, não executa pagamentos e não recomenda instituição. A decisão
é sempre da empresa. Limites completos em
docs/FINANCIAL_PRODUCT_BOUNDARIES.md.
Demonstração: a demo canônica é o próprio produto (main) com
ARANDU_ENV=demo, um Supabase DEMO e a empresa fictícia Vitta Foods S.A.
Localmente: npm run demo:setup. Roteiro, dados, reset e travas:
docs/demo/README.md.
O problema
Uma tesouraria que quer crédito ou trocar de adquirente costuma pedir proposta
por e-mail, receber cada banco num formato, montar a comparação em planilha e
aprovar por mensagem. Não fica registro de quem pediu o quê, qual versão da
proposta foi comparada, quem aprovou e por quê, nem de quando o contrato vence.
O Arandu dá forma a esse processo, com trilha de auditoria, sem tomar a decisão
no lugar da empresa.
Como funciona
Empresa compradora (/finance/)
- Demanda — cria uma solicitação (RFQ) guiada por produto; o rascunho é
salvo no servidor enquanto se escreve.
- Convite — convida provedores; cada convite é de uso único e, quando o
provedor tem contato cadastrado, vinculado ao e-mail exato.
- Revisões — ajusta a demanda em novas revisões; cada provedor vê o que
mudou e responde à revisão atual.
- Comparação — compara propostas normalizadas campo a campo, com
cobertura por proposta e pesos definidos pelo próprio usuário (o Arandu não
pontua nem recomenda).
- Aprovação — política de aprovação sequencial por etapas; quem pediu não
aprova, e uma aprovação dada a uma versão antiga não vale para a nova.
- Decisão e contrato — decisão humana registrada, contrato com ciclo de
vida, marcos de 90/60/30 dias, aviso prévio e renovação.
- Colaboração — tarefas, comentários com menções, visibilidade interna ou
para o provedor, notificações, busca e central de comandos, documentos
privados com URL assinada e versionamento.
Provedor financeiro (/provider/)
- Aceita o convite e passa a ver a demanda completa só depois de aceitar.
- Responde com proposta versionada, com rascunho salvo automaticamente.
- Vê apenas o próprio processo: nunca propostas, perguntas, comentários ou
documentos de concorrentes.
- Depois do encerramento, o processo fica somente leitura.
Operação (/finance/ops.html)
Console de saúde para o papel de plataforma finance_ops, com MFA obrigatório,
métricas operacionais e outbox — sem dados de clientes.
Arquitetura
| Camada | Tecnologia | Onde |
|---|
| Front-end | HTML multipágina + JavaScript modular, build com Vite | finance/, provider/, demo/, páginas públicas na raiz |
| API | Funções serverless da Vercel; roteador único | api/[...path].js, domínio financeiro em lib/api/domains/finance.mjs e lib/finance/ |
| Banco | Supabase (PostgreSQL, Auth, Storage), RLS em todas as tabelas fin_* | migrations em docs/*.sql, ordem em docs/supabase-migrations.json |
| Jobs | Vercel Cron com segredo (/api/jobs/renewals) | lib/api/domains/finance-jobs.mjs |
| Demo | Produto real com ARANDU_ENV=demo e Supabase DEMO semeado (Vitta Foods); sandbox legado no navegador até a migração | scripts/demo/, finance/demo/ (legado) |
Modelo de dados: docs/FINANCIAL_DATA_MODEL.md.
Interface: docs/FINANCIAL_UI_ARCHITECTURE.md.
Produto: docs/FINANCIAL_PROCUREMENT_PRODUCT.md.
Segurança
- Multi-tenant no banco: RLS em todas as tabelas
fin_*; RPCs com
search_path fixo e inventário travado em teste; 43 ataques diretos entre
tenants e papéis recusados sem efeito colateral (npm run test:database).
- RBAC por organização (comprador, aprovador, provedor, admin) e papel de
plataforma
finance_ops com MFA aal2.
- Allowlist fail-closed no piloto: tabela vazia = ninguém cria organização.
- Documentos privados no bucket
fin-documents (privado, 10 MB, 5 tipos),
acesso só por URL assinada emitida depois da autorização.
- Service role só no servidor; o build falha se credencial real acompanhar a
demo, e
finance:env:check recusa chave de outro projeto.
- Superfície legada de arte fechada (404) em piloto, produção, qualquer
deployment Vercel de produção e na demo.
- Request ID em toda resposta de API, rate limit no banco, cabeçalhos de
segurança e CSP em
vercel.json.
Modelo completo: docs/FINANCIAL_SECURITY_MODEL.md,
docs/FINANCIAL_THREAT_MODEL.md,
docs/FINANCIAL_AUTHORIZATION_MAP.md.
Vulnerabilidades: SECURITY.md.
Ambientes
Uma base de código e dois ambientes hospedados permanentes planejados: Demo e Production. Pilot é uma etapa transitória de validação, não um terceiro ambiente permanente. Todos são derivados de commits aprovados da mesma main; não criar forks por cliente, versão comercial ou ambiente. A configuração diferencia ambientes sem compartilhar dados ou segredos.
| Papel | Projeto Vercel | Política de código | Modalidade ou banco exigidos para a operação canônica |
|---|
| Demo pública (P0-A) | arandu-demo | main aprovada | Visita M2 estática e sintética enquanto M3 permanecer bloqueada; não requer Supabase para visita |
| Demo canônica local / hospedada M3 (P0-B/P1) | código da mesma main | ARANDU_ENV=demo | Local: Auth/RLS/API/Storage e banco fictício; hosted: Supabase Demo exclusivo somente após recovery e cutover autorizados |
| Pilot (transição) | arandu-pilot | release candidato de main | Etapa de validação, com dados e controles compatíveis com os gates aplicáveis |
| Production | arandu | main aprovada e release governado | Ambiente próprio, legal/recovery e readiness M5 comprovados; não presumir deploy operacional |
A visita pública não atesta M3, e produção não é considerada pronta por ter código em main. Os destinos hospedados não podem compartilhar bancos/segredos fora da política de release. Diferenças de comportamento (e-mail, webhooks, modelo externo, documentos reais, fixtures) são governadas centralmente por lib/runtime-mode.mjs, não por cópias do software.
O build recusa a topologia errada (banco trocado, branch diferente de main,
sandbox em ambiente real, credencial no sandbox, produção sem ambiente
declarado). Fluxo feature/* → PR → main → ambientes, release e rollback:
docs/FINANCIAL_DEPLOYMENT_WORKFLOW.md.
Estado operacional
Estado histórico observado em 02/10/2026 (anterior à consolidação main canônica de 06/10/2026), separado por código e ambiente em
docs/ARANDU_CURRENT_STATE_2026-10-02.md:
- Código:
main com Onda 0 e CI verde; pilot 13 commits à frente e
0 atrás, em 187c032c após a PR #96, com Financial Passport v2.
O run #721 teve presentation cancelado; o #722 concluiu os quatro gates
com SUCCESS. A árvore validada é idêntica à do merge #96.
- Supabase Pilot:
financial-surface-hardening-1; aprovação sequencial e
Passport pendentes. Allowlist vazia, e-mail desligado, Storage privado.
- Demo pública: ainda sandbox em
main; o Supabase DEMO dedicado não
pôde ser criado por limite de dois projetos ativos no Free.
- Produção: deploy oficial antigo; não há Supabase Production dedicado.
- Dependências externas: backup/restore do Pilot, configuração Vercel,
capacidade Supabase, proteção de branches e preparação jurídica/comercial.
Lista em
docs/FINANCIAL_OWNER_ACTIONS.md.
Nenhum item acima é declarado pronto sem evidência verificável. Gates externos
de produção ficam em ops/release-evidence.json e não bloqueiam o piloto
financeiro.
Rodar localmente
Requisitos: Node.js 24, npm; PostgreSQL 16 para a suíte de banco; Chromium para
Playwright.
npm ci --include=optional
npm run dev # app em http://localhost:5173
ARANDU_DEMO_MODE=true npm run dev # com /demo/ habilitada
ARANDU_DEPLOYMENT_KIND=demo npm run build:demo # build igual ao do arandu-demo
Piloto completo em contêineres (Postgres, GoTrue, PostgREST e Storage da
Supabase): npm run pilot:local:up && npm run pilot:local:journey.
Validação local
Antes de qualquer push (cada push custa minutos do GitHub Actions — ver
docs/GITHUB_ACTIONS_MINUTES.md):
npm run audit:ci
npm run check:all # contratos, segurança, finanças, migrations, governança
npm run build
npm run check:dist-assets && npm run check:build-size && npm run check:seo:dist
npm run check:financial-surface && npm run check:financial-navigation
npm run test:e2e # jornadas financeiras (5 motores de navegador)
npm run test:e2e:presentation # demo e modo de apresentação
ARANDU_DATABASE_TEST_URL=postgresql://postgres:postgres@localhost:5432/postgres \
npm run test:database # instalação limpa, upgrade, rollback, RLS, ataques
Ambientes reais (somente leitura, nunca imprimem segredos):
ARANDU_ENV=pilot npm run finance:env:check
ARANDU_ENV=pilot npm run finance:pilot:doctor # 0 = GO, 1 = NO-GO, 2 = UNSAFE
npm run pilot:canary # isolamento buyer/provider/outsider
npm run pilot:backup:preflight # identidade, dependências e escopo
npm run pilot:restore:drill # backup lógico + restore + comparações de integridade
O CI (.github/workflows/ci.yml) roda os jobs validate, database,
deploy-boundaries e presentation.
Contribuir
Leia CONTRIBUTING.md. Em resumo: branch feature/* a
partir de main, PR para main com os quatro gates verdes no HEAD exato,
validação local completa e um push por lote. pilot está congelada
(histórica). Nunca registre segredo, e-mail real ou PII no Git.
Governança do repositório
A CI executa scripts/check-governance.mjs para impedir regressões nos
controles mínimos do repositório.
Critério de lançamento
Piloto (GO quando todos valerem):
- migrations do manifesto aplicadas até o schema esperado pelo código do piloto e
finance:pilot:doctor = GO;
arandu-pilot publicado da main com ARANDU_ENV=pilot;pilot:canary e pilot:restore:drill aprovados contra o piloto real;- CI verde no SHA de
main publicado no piloto;
- revisão jurídica concluída e empresa/provedores do piloto na allowlist.
Produção: Supabase próprio com as mesmas migrations, ARANDU_ENV=production
no projeto arandu, doctor GO contra ele e o mesmo SHA de main validado no
piloto realmente utilizado.
Nota histórica
O Arandu começou como marketplace de arte brasileira. Essa vertical foi
aposentada e removida da árvore atual; o Git preserva a história. Detalhes e
regras para não reintroduzi-la: docs/LEGACY_ART_RETIREMENT.md.
