ibarra-app

Imported from Briian3306/Transporte (ibarra-app/AGENTS.md). Install upstream with npx skills add Briian3306/Transporte --skill ibarra-app. Copyright stays with the author.

AGENTS.md — Peajes (Module Automation Tool) · Transporte Ibarra

Overview

Módulo Angular 19 (standalone components) + Supabase que se incorpora al proyecto existente ibarra-app/ (Transporte Ibarra), implementando el PRD docs/plan/peaje-prd-short.md.md: un asistente guiado que carga, transforma, mapea, valida y almacena pasadas de peaje, y las asocia a una factura.

El módulo peajes se construye como dominio aislado dentro de la app compartida: rutas propias, permiso propio (peajes:read), modelos y servicios propios, tablas propias. No debe modificar Checklists, Stock, Incidentes, Flota ni Neumáticos, ni reutilizar checklist_templates / ChecklistTemplateService.

Fuente de verdad (en este orden si hay conflicto)

1. docs/plan/peaje-prd-short.md.md — spec funcional y de datos. Ante cualquier duda, el PRD manda sobre cualquier supuesto de este archivo.
2. feature_list.json (raíz) — estado canónico de features, agente dueño y pasos de verificación.
3. docs/claude-progress.md — bitácora de sesiones / estado verificado actual.
4. docs/session-handoff.md — handoff entre sesiones/agentes (obligatorio si el trabajo queda a medias o se delega).
5. init.sh — instalación + verificación base (crear en Fase 0 si el repo host no lo tiene).

Modelo de agentes en paralelo (leer antes de tocar cualquier archivo)

Este módulo se construye con varios agentes/subagentes corriendo en sesiones separadas. Para evitar colisiones, cada agente tiene un alcance de archivos estricto. Nunca edites un archivo fuera de tu alcance: si necesitás un cambio ahí, anotalo en docs/session-handoff.md y que lo resuelva el agente dueño, o el agente 05 (Integrador) al final.

Reglas:

1. El agente 00 debe terminar y comitear antes de que arranquen 01/02/03: estos construyen contra los contratos que deja 00, no entre sí.
2. 01, 02 y 03 pueden correr en paralelo una vez que 00 terminó. Tocan carpetas disjuntas, así que los conflictos de archivo deberían ser raros; la única superficie compartida son los modelos/interfaces de 00 — nadie más los edita sin pasar por docs/session-handoff.md.
3. Si 02 o 03 necesitan una capacidad de backend que todavía no existe, construyen contra un mock tipado (of(mockData) / arreglo en memoria) que implemente la misma interfaz, y dejan el contrato exacto que necesitan para 01 anotado en docs/session-handoff.md.
4. El agente 04 solo documenta después de que 01/02/03 marcan una feature como passing en feature_list.json — no debe inventar comportamiento que aún no existe.
5. El agente 05 corre al final, en serie, y es el único autorizado a tocar peajes.routes.ts o el mapa de permisos si 01/02/03 agregaron rutas de forma independiente y hay que fusionarlas.

F09 — Plantillas recurrentes y reconocimiento de estaciones

F09 cruza plantillas, wizard, persistencia y documentación. La relación plantilla_estaciones_reconocidas es un snapshot de plantilla y no reemplaza estaciones_alias_proveedor: la prioridad de importación es plantilla → alias de empresa → reconocimiento normal. El backend posee migración/RPC/servicio; el wizard restaura mapeos y relaciones y solo salta a Factura si no quedan excepciones.

F14 — Auditoría de pasadas por patrones (normalización tarifaria)

F14 cruza contrato, backend, wizard, pantalla nueva, documentación y QA en cadena estricta: 00 entrega el destino CATEGORIA en PasadaColumnKey / PASADA_COLUMN_KEYS (opcional, nunca en PASADA_COLUMNAS_OBLIGATORIAS) y comitea antes de que arranque nadie; 01 crea tarifas_normalizadas, tarifas_parametros_peaje y tarifas_status_catalogo, extiende pasadas y publica los RPC peajes_*; 02 suma la detección y el mapeo en el wizard y la pantalla /peajes/auditoria-tarifas; 04 documenta lo que quedó passing; 05 fusiona ruta y permiso y corre el QA contra el dataset de referencia. Plan completo y apéndices en docs/plan/auditoria-pasadas-patrones/.

Cuatro invariantes que ningún agente puede romper. pasadas.categoria es el texto crudo que trajo el proveedor y nunca debe confundirse ni joinearse con patentes.categoria, que es el enum interno de flota (TRANSPORTE/REMIS/OBRA/AUTO): si hiciera falta relacionarlas, va una tabla de equivalencia explícita (RN-15). La concesión se deriva siempre por pasadas.estacion_id → estaciones.peaje_id y está prohibido agregar peaje_id a pasadas (RN-05); tarifas_normalizadas sí lleva peaje_id porque agrega a nivel de peaje. El campo diagnostico es algorítmico y fijo, mientras que status es entrada del usuario validada por trigger contra los dos códigos universales o el catálogo tarifas_status_catalogo de ese peaje — por eso no es un CHECK. Y la normalización corre como hook posterior al guardado final, disparada por peajes_confirmar_carga sobre el documento recién confirmado, no como paso del wizard.

Flujo de arranque (toda sesión, todo agente)

1. pwd, confirmar que estás dentro de ibarra-app/.
2. Leer docs/claude-progress.md y docs/session-handoff.md si existe.
3. Leer feature_list.json; filtrar por tu agent_owner; tomar la feature de mayor prioridad en not_started/in_progress y ponerla en in_progress.
4. git log --oneline -5.
5. Correr ./init.sh (crearlo en Fase 0 si no existe: instala deps + smoke test de ng build/ng test).
6. Si el baseline falla, arreglar eso antes de sumar features nuevas.

Antes de implementar cualquier cosa

1. Leer docs/plan/peaje-prd-short.md.md para el comportamiento exacto de la feature (Sección 4 = pasos del wizard, Sección 7 = motor/plantillas, Secciones 11-14 = modelo de datos, Sección 15 = reglas de negocio).
2. Leer tu skill en .agents/skills/ (ver tabla de arriba) antes de escribir código.
3. Confirmar que los pasos de verification de la feature en feature_list.json son los que realmente vas a correr; si están mal, corregirlos explícitamente y explicar por qué en docs/claude-progress.md.
4. No salir de tu alcance de archivos (tabla de arriba).

Definición de terminado (por feature en feature_list.json)

1. La implementación cumple el comportamiento del PRD para ese RF/RN.
2. Los pasos de verificación corrieron y pasaron (ng test, ng build, pnpm supabase db reset --local --no-seed, pnpm supabase test db, según corresponda).
3. Evidencia registrada en feature_list.json → evidence (comando + resultado).
4. Documentación actualizada (agente 04, después de la implementación), o diferida explícitamente con nota.
5. ./init.sh sigue corriendo limpio desde un clon nuevo.

Si falta algo, la feature queda in_progress/blocked — nunca passing.

Fin de sesión (todo agente)

1. Actualizar feature_list.json (status + evidence) solo de tus features.
2. Agregar entrada en docs/claude-progress.md.
3. Completar docs/session-handoff.md si el trabajo queda a medias o se delega, o si necesitás algo del alcance de otro agente.
4. Commitear con mensaje descriptivo una vez que la verificación pasa.

Preguntas abiertas — resueltas en Fase 0 (Agente 00)

Detalle y handoff: docs/session-handoff.md.

• Carpetas: src/app/components/... (host). Peajes en components/peajes/.
• UI: CSS/SCSS custom + Font Awesome; sin PrimeNG/Material/Bootstrap como kit.
• Permisos: accessibleModules ↔ system_modules.name / id de tarjeta; guard con ROUTE_PERMISSIONS (peajes:read).
• Supabase: CLI = testing, DESARROLLO = kfffigvyvtzyczeiadxh. Sin staging/prod separados. No refs OrdenCompra.
• SupabaseService: getClient() + auth; sin wrapper tipado de query/RPC — 01 encapsula en servicios de dominio.

Stack (PRD §17)

Angular 19 (standalone) · RxJS · Supabase/PostgreSQL · Supabase Edge Functions (solo si hace falta) · Supabase Storage (opcional, para conservar el archivo original) · Netlify (hosting frontend) · Auth/RLS/roles explícitamente fuera del alcance del MVP (PRD §5.2) — el módulo solo respeta el permiso peajes:read que ya existe en la app host para mostrar/ocultar la tarjeta del dashboard.