feat: [TESIS-156] seed four weeks of demo activity for Norte

[LauAubert]

Ticket de Jira

https://proyectofinalfrlp.atlassian.net/browse/TESIS-156

ID provisorio: se reemplaza por la clave real al cargar la card en Jira. Card: cards/023.md.

---

Descripción

Los seeds crean todas las órdenes en el momento en que se corren, así que caen todas el mismo día. Para la demo eso deja dos pantallas sin nada que mostrar: la curva de Reportes (proyecto-api#101 / proyecto-web#64) sería un solo punto, sin período anterior contra el cual calcular la tendencia; y la cola de eventos fallidos (proyecto-web#63) estaría vacía, sin forma de mostrar el criterio de aceptación de resiliencia. Este PR agrega cuatro semanas de actividad de Distribuidora Norte.

Decisiones que conviene mirar:

Archivo aparte. db/seeds/demo_activity.rb se carga con una línea al final de seeds.rb. La rama de Shopify (TESIS-138) reescribe buena parte de las plantillas y conexiones de seeds.rb; meter esto ahí habría sido un conflicto seguro.

Qué siembra. 17 ventas manuales repartidas en los últimos 27 días (hora de Argentina, con horarios distintos), sobre el catálogo real de Norte. La mayoría despachadas con Andreani o Correo Argentino con su bitácora completa (ready_to_ship → in_transit → delivered), porque Reportes fecha el despacho por ese evento. Una cancelada y dos pendientes. En la DLQ, un evento agotado que apunta al webhook inválido que ya cargan los seeds —si se lo reintenta desde la pantalla, vuelve a fallar por el mismo motivo, como pasaría de verdad— y uno pendiente con un 503.

Idempotente y relativo. Cada venta se reconoce por el nombre del cliente y cada evento por su error, como el resto de los seeds. Las fechas son relativas al momento en que se corre, para que «últimos 30 días» siempre las vea.

No mueve stock. Son ventas pasadas; el stock de la demo es el que cargan los seeds de arriba.

• Agrega db/seeds/demo_activity.rb y lo carga desde seeds.rb.
• Agrega spec/db/demo_activity_seeds_spec.rb: corre los seeds completos (no había spec que los ejecutara) y verifica que las ventas cubren muchos días dentro de los últimos 30, que hay despachos en días distintos, que una segunda corrida no agrega nada, y que la DLQ tiene un evento agotado y uno pendiente.

---

Evidencia visual

N/A

---

Cómo probar

1. bin/rails db:seed sobre una base sembrada → agrega las ventas históricas y los dos eventos; una segunda corrida no agrega nada.
2. Con proyecto-api#101: GET /api/v1/reports/overview?period=30d como usuario de Norte → la curva tiene ventas en muchos días y dispatched_units es mayor que cero.
3. Con proyecto-web#63: la pantalla «Eventos fallidos» muestra un evento «Agotado» y uno «Pendiente».

Verificación: bundle exec rspec (1572 ejemplos, 0 fallas), rubocop limpio.

---

Impacto y consideraciones

¿Introduce breaking changes?
No. Sólo datos de demo; producción no corre seeds.

¿Requiere nuevas variables de entorno?
No

¿Afecta la arquitectura o genera un nuevo patrón?
No. Introduce db/seeds/ para separar datos de demo de la configuración base.

🤖 Generated with Claude Code

[TomasMartin2004]

Revisado. No lo mergearía, salvo que entre #101.

Esto no es alcance: es escenografía para la demo. Y como escenografía está bien pensada —hoy los seeds crean todas las órdenes en el mismo instante, así que la curva de reportes es un solo punto y la cola de eventos fallidos está vacía—, pero no arregla nada del sistema.

La condición es simple: si entran #101 y proyecto-web#64 (reportes reales) y proyecto-web#63 (cola de eventos fallidos), esto se vuelve necesario, porque si no esas dos pantallas se defienden vacías y no se puede mostrar la tendencia contra el período anterior ni el criterio de aceptación de resiliencia. Si esos no entran, este tampoco tiene por qué.

Decidilo después de los otros tres, no antes.