Nova SPINDLE-OS

Esto es el formato típico de Devpost. Te lo lleno basándome en lo que realmente construiste. Puedes copiarlo tal cual o ajustar detalles.

Inspiration En un taller de reparación de equipo industrial (husillos, motores), nadie sabía qué había en el almacén. Cada pieza se buscaba a mano y se pedía tarde, frenando las reparaciones. Nos inspiró cerrar ese ciclo: un inventario que se entere de todo lo que pasa en el taller en tiempo real y responda al instante, sin que nadie tenga que capturar nada manualmente.

What it does SPINDLE-OS es el servicio de inventario del taller. Escucha los eventos del taller por Kafka (Redpanda) y cierra el ciclo completo de forma automática:

Cuando se aprueba una inspección, reserva las piezas disponibles para esa orden. Si no alcanzan, levanta un faltante y genera una sugerencia de compra. Cuando llega la compra, la relaciona con el catálogo, la ingresa al almacén y surte el faltante. Cuando el técnico retira la pieza, el stock baja y queda registrado. Todo se guarda en un libro mayor inmutable: el stock nunca se edita, se calcula sumando movimientos. Expone una API REST, pantallas de almacén/orden/kardex y una vista de piso.

How we built it Backend: FastAPI (Python) con un consumidor Kafka asíncrono que procesa los 4 tópicos del taller. Base de datos: PostgreSQL (Supabase), con el inventario modelado como movimientos inmutables. Mensajería: Redpanda (compatible con Kafka) para consumir eventos del taller y publicar los propios en inventory.events. Frontend: Dashboard web con tema industrial para almacén, órdenes de trabajo, kardex y operaciones de piso. Challenges we ran into Eventos desordenados y duplicados: los tópicos no garantizan orden entre sí, así que una inspección podía llegar antes que el catálogo de su pieza. Lo resolvimos con reintentos, deduplicación y una cola de errores (DLQ). Relacionar compras sin ID de pieza: las recepciones traen texto libre, no un part_id. Tuvimos que hacer matching tolerante por SKU y mandar lo ambiguo a revisión manual. Evitar reservas dobles: una orden puede tener varias inspecciones aprobadas; implementamos reemplazo por línea para no duplicar. Flujo de piso con cámara: el escaneo móvil requiere HTTPS, lo que nos dio problemas de red y túneles durante el desarrollo. Accomplishments that we're proud of Un libro mayor 100% inmutable, auditable y reconstruible desde cero releyendo los eventos. Idempotencia garantizada: reenviar un evento no cambia el estado. Tolerancia a fallos con cola de errores inventory.dlq que no detiene el consumo, probada end-to-end. Integración en tiempo real procesando semanas de operación del simulador con cientos de faltantes y recepciones. What we learned Diseñar sistemas event-driven idempotentes y tolerantes al desorden es muy distinto a un CRUD normal. El patrón de libro mayor inmutable (event sourcing) hace que el estado sea auditable y reconstruible, a cambio de más cuidado en los cálculos. La importancia de los contratos de datos: respetar nombres y formatos exactos para que todo integre. What's next for Nova SPINDLE-OS Terminar y pulir el escáner de piso móvil con HTTPS estable para retirar y contar en 2-3 toques. Extras del reto: pronóstico de demanda por modelo, valuación de inventario a costo promedio y tablero de rotación (piezas críticas y sin movimiento). Observabilidad: métricas de lag del consumidor y panel de errores del DLQ. Liberar reservas con mayor granularidad por inspección individual.