Un espacio de trabajo de inventario y facturación para pequeñas empresas. Construí esquemas de productos flexibles, herramientas de inventario conversacionales y extracción de documentos de proveedores, junto con facturación electrónica ARCA.
Estas notas históricas de arquitectura describen un diseño FastAPI/Astro y no han sido reconciliadas con el codebase actual en Next.js. Las capturas del producto actual están disponibles en Trabajo seleccionado.
La mayoría de los proyectos de portfolio eligen un dominio. Stockear abarca IA, infraestructura SaaS y cumplimiento regulatorio — simultáneamente.
Hacé preguntas naturales a tu inventario.
En segundo plano, los embeddings (VoyageAI + Google GenAI) potencian la búsqueda semántica sobre tu catálogo. El agente orquesta llamadas a herramientas — CRUD, búsqueda, generación de facturas — en un único turno conversacional.
Cuotas por tenant sin abstracciones con fugas.
El diseño histórico contempla aislamiento por workspace y tiers de suscripción, con controles de cuotas en la capa de dependencias antes de ejecutar la lógica de negocio en los endpoints que incluyen la dependencia.
Emisión de comprobantes integrada con AFIP.
El diseño histórico de Stockear contempla integración con ARCA/AFIP para facturación electrónica. La arquitectura hexagonal propuesta separa los adaptadores AFIP para permitir pruebas con implementaciones mock.
Cuatro capas conectadas — cada una con límites claros y responsabilidades definidas.
Construido con Astro 6 + React islands para máximo rendimiento. Shell estático con hidratación selectiva — solo los componentes interactivos envían JavaScript. Lucia Auth maneja la gestión de sesiones con cookies seguras HTTP-only.
No toda elección es obvia. Estas decisiones arquitectónicas explican el porqué detrás del diseño de Stockear.
Las regulaciones fiscales argentinas (AFIP/ARCA) cambian frecuentemente. El módulo de facturación debe ser testeable sin llamadas reales a la API y debe permanecer desacoplado del framework HTTP.
Aplicar el patrón puertos y adaptadores (hexagonal) al dominio de facturación. La lógica de dominio no tiene imports de FastAPI, Motor ni arca_arg.
La interfaz de chat con IA necesita llamar a múltiples herramientas del backend (CRUD de inventario, búsqueda semántica, generación de facturas). Codificar el dispatch de herramientas de forma rígida crearía acoplamiento fuerte y haría costoso agregar nuevas capacidades.
Implementar un Tool Registry donde cada herramienta es un callable auto-descriptivo con un esquema. El agente lee el registry en runtime y enruta las llamadas a herramientas solicitadas por el LLM de forma dinámica.
Cada endpoint de la API debe respetar los límites de suscripción por tenant. Dispersar las verificaciones de cuota en la lógica de negocio llevaría a inconsistencias y bypasses.
Inyectar un QuotaVerifier como dependencia FastAPI en cada endpoint protegido. El verificador lee la suscripción del tenant desde MongoDB y lanza HTTP 429 antes de que ejecute la lógica de negocio.
El cumplimiento fiscal argentino requiere un log inmutable de todas las transacciones, cambios de esquema y acciones del agente. El sistema debe ser auditable y reproducible.
Usar MongoDB como event store append-only. Todas las acciones significativas (mensajes de chat, emisiones de facturas, cambios de esquema, eventos de cuota) se escriben como documentos de eventos inmutables.
Del navegador a la autoridad fiscal — cada capa mapeada.
Shell estático de Astro con hidratación selectiva de React. Cero JS para secciones estáticas.
Astro desplegado en Vercel. Páginas SSR renderizadas en el edge; assets estáticos con caché global.
Capa de orquestación principal: agente, tool registry, enforcement de cuotas, lógica de negocio.
Cada workspace recibe un esquema aislado. También actúa como event store para el audit trail.
Emisión legal de facturas via adaptador hexagonal. Entornos de staging y producción.
Generación de embeddings para búsqueda semántica. Vectores almacenados en MongoDB para retrieval.
La aplicación en vivo y perfiles de código relacionados.