Crédito Colombia — 5 hubs y una billetera de plásticos

El Financial OS (credito.mateolondono.dev) dejó de ser un menú de 14 pantallas sueltas. En el corte del 22 de agosto el shell agrupa el producto en cinco hubs y la vista de instrumentos pasó de fichas de formulario a plásticos de billetera.

Las URLs no se rompieron: las pestañas solo agrupan rutas que ya existían.

Este es el post de entrada del proyecto Crédito Colombia: simulador de capacidad de crédito anclado a instrumentos reales (cupo, saldo, extracto), no a un presupuesto que se cumple porque lo escribiste.

Qué es (y qué no es)

Nació como simulador de capacidad de crédito + caja + patrimonio, no como core bancario ni como Open Banking. AuthPortal valida el grant del módulo credito. El runtime es Next.js 15, motor TypeScript en src/domain/finance, persistencia Neon + Drizzle.

Browser → Next.js (Vercel)
  ├── middleware AuthPortal /api/access?slug=credito
  ├── app/(app)/* UI por features
  ├── app/api/* Route Handlers delgados
  ├── domain/finance  motor puro TS
  ├── application/*   analyze / wealth / risk
  └── data/*          Drizzle MER → Neon

No es una preaprobación bancaria. El hub de home se llama ¿Me cabe el crédito? a propósito: responde si la cuota entra en caja bajo el escenario, con paridad de golden (fixtures/golden + npm run golden:compare).

No es el libro diario el presupuesto. Los techos viven en Plan; las compras viven en Gastos, dentro de Billetera. Mezclarlos era la idea optimista (“así quiero gastar”) contra la calle colombiana (“pagué $86k en Éxito con la Visa ****4412”).

Los 5 hubs

Secundario (fuera del menú principal): gráficas del escenario y academia (/analytics, /learn).

Hints en src/ui/nav.ts: cada hub dice en una frase qué no hace. Calculadora no compara tu vida; compara ofertas. Plan no anota el almuerzo. Billetera no es el feed de Gmail.

La regla de producto: presupuesto no es el libro de compras. Un avance no es un instrumento: es cargo sobre una TC. Gastos es bandeja + hábitos, no el MER de “línea de comida”.

Imagen de ejemplo (mockup), no captura de producción. Los plásticos y montos son ilustrativos.

Billetera: plásticos, no formularios

Alta de instrumento y carga de extracto salen de la vista principal. El hub muestra el plástico; el detalle se abre al elegir uno. Agrupación por tipo (crédito, débito, cuenta, digital).

El CSS huérfano que rompía el build (ec25c41) es el tipo de detalle que solo aparece cuando dejas de tratar la tarjeta como un <form> con bordes redondeados.

PDF de extracto: contraseña, match de instrumento para no duplicar fichas, crear o actualizar desde el extracto. El apalancamiento de home se ancla a instrumentos reconciliados, no al feed de avisos.

Qué cambió en git (22 ago)

• c39e146 — Agrupa la navegación en 5 hubs con pestañas, sin cambiar las URLs.
• acdd697 — Muestra las tarjetas como plásticos en la billetera, no como fichas de formulario.
• ec25c41 — Corrige CSS huérfano que rompía el build de las tarjetas plásticas.
• 9ac1e01 — Ajustes de configuración y estilos.

Antes de eso, en el mismo ciclo de producto (9 ago): Next-only (se retiró el legado Python/Vite), MER app_users / escenarios, dual-write, grant contra AuthPortal, layout móvil, presupuesto dinámico y la bandeja Gmail Nequi/Bancolombia.

Por qué importa

El cambio de esta nota es de arquitectura de UI, no del motor: menos páginas competiendo por atención, misma persistencia. El usuario deja de “buscar la pantalla de tarjetas” entre catorce ítems; ve cinco preguntas.

Siguiente: libro editable y clasificador de intención.

Serie · proyecto

• 5 hubs y billetera (este post)
• Libro + intención
• Prod: credito.mateolondono.dev
• Ficha: Proyectos