agent-mp 0.5.20 → 0.5.22

package/dist/commands/repl.js

@@ -405,12 +405,15 @@ async function cmdSetup(rl) {
     await writeJson(path.join(projectDir, '.agent', 'config.json'), agentConfig);
     console.log(chalk.green('  .agent/config.json generated'));
     const templates = {
-        '.agent/INDEX.md': `# ${projectName} - Agent Entry Point\n\n## Navegacion por rol\n| Si sos... | Lee primero... |\n|-----------|----------------|\n| ORCHESTRATOR | .agent/rules/workflow.md |\n| IMPLEMENTOR | .agent/tasks/{ID}/plan.json |\n| REVIEWER | .agent/rules/workflow.md |\n`,
-        '.agent/rules/workflow.md': '# Agent Workflow Contract\n\n## REGLA #1 - Separacion de roles\nUn rol NUNCA ejecuta acciones de otro rol.\n\n## Roles\n- ORCHESTRATOR: planifica\n- IMPLEMENTOR: ejecuta\n- REVIEWER: valida\n',
-        '.agent/rules/structure.md': '# Estructura\n\n## Aprobados\n.\n\n## Prohibidos\nnode_modules, dist, .git\n',
-        '.agent/rules/patterns.md': '# Patrones\n\n- kebab-case: archivos\n- PascalCase: clases\n- camelCase: variables\n',
-        '.agent/context/architecture.md': '# Arquitectura - NIVEL 0\n\n| Servicio | Stack | Puerto | Detalle |\n|----------|-------|--------|---------|\n| - | - | - | - |\n',
-        '.agent/AGENT.md': '# Sub-Agentes\n\n1. Lee .agent/INDEX.md\n2. Lee .agent/rules/workflow.md\n3. Actua SOLO dentro de tu rol\n',
+        '.agent/INDEX.md': `# ${projectName} — Agent Entry Point\n\n> Leé este archivo antes de cualquier accion.\n\n## Proyecto\n${projectName}\n\n## Navegacion por rol\n| Si sos... | Lee primero... | Luego... |\n|-----------|----------------|----------|\n| ORCHESTRATOR | .agent/rules/workflow.md | .agent/rules/orchestrator.md |\n| IMPLEMENTOR | .agent/rules/implementor.md | .agent/tasks/{ID}/plan.json |\n| REVIEWER | .agent/rules/reviewer.md | .agent/rules/workflow.md |\n\n## Contexto del proyecto\n- Arquitectura: .agent/context/architecture.md\n- Stack: ver .agent/config.json\n`,
+        '.agent/rules/workflow.md': `# Workflow Contract — ${projectName}\n\n## Flujo general\n\`\`\`\n[ORCHESTRATOR] planifica → genera plan.json\n       ↓\n[IMPLEMENTOR] ejecuta el plan → modifica archivos\n       ↓\n[REVIEWER] valida → genera result.md\n\`\`\`\n\n## REGLA #1 — Separacion de roles\nCada CLI opera SOLO en su rol. Nunca ejecuta acciones de otro rol.\n\n## REGLA #2 — Orden estricto\nOrchestrator siempre primero. Implementor no actua sin plan. Reviewer no actua sin implementacion.\n\n## REGLA #3 — Sin inventar\nCada rol trabaja con los archivos reales del proyecto. No asume ni infiere sin leer.\n`,
+        '.agent/rules/orchestrator.md': `# Rol: ORCHESTRATOR — ${projectName}\n\n## Responsabilidad\nAnalizar el requerimiento, leer el contexto del proyecto y generar un plan de tareas claro y ejecutable.\n\n## Antes de planificar\n1. Leer .agent/context/architecture.md para entender los componentes\n2. Leer .agent/rules/structure.md para saber qué dirs son validos\n3. Leer .agent/rules/patterns.md para respetar convenciones del proyecto\n\n## Al generar el plan\n- Dividir el trabajo en pasos atomicos (1 paso = 1 cambio verificable)\n- Especificar rutas de archivos REALES (no genericas)\n- Indicar dependencias entre pasos si las hay\n\n## Prohibido\n- Modificar archivos de codigo directamente\n- Ejecutar comandos de build o test\n`,
+        '.agent/rules/implementor.md': `# Rol: IMPLEMENTOR — ${projectName}\n\n## Responsabilidad\nEjecutar el plan generado por el Orchestrator. Modificar archivos de codigo siguiendo las instrucciones exactas del plan.\n\n## Antes de implementar\n1. Leer .agent/tasks/{ID}/plan.json completo\n2. Leer .agent/rules/structure.md — no crear archivos en dirs prohibidos\n3. Leer .agent/rules/patterns.md — respetar convenciones\n\n## Al implementar\n- Seguir el plan paso a paso, en orden\n- No agregar cambios fuera del scope del plan\n- Marcar cada paso como completado al terminarlo\n\n## Prohibido\n- Modificar el plan\n- Hacer refactors no solicitados\n`,
+        '.agent/rules/reviewer.md': `# Rol: REVIEWER — ${projectName}\n\n## Responsabilidad\nValidar que la implementacion cumple el plan y respeta las reglas del proyecto.\n\n## Checklist de revision\n- [ ] Cada paso del plan fue implementado\n- [ ] No se modificaron archivos fuera del scope\n- [ ] Se respetan las convenciones de .agent/rules/patterns.md\n- [ ] La estructura cumple .agent/rules/structure.md\n- [ ] No hay codigo muerto ni imports sin usar\n\n## Al generar result.md\n- Indicar cada item como OK / FAIL / SKIP con razon\n- Si hay FAILs: describir exactamente que falta y en que archivo\n\n## Prohibido\n- Modificar archivos de codigo directamente\n- Aprobar implementaciones incompletas\n`,
+        '.agent/rules/structure.md': `# Estructura del proyecto — ${projectName}\n\n## Directorios aprobados\n- . (raiz del proyecto)\n\n## Directorios prohibidos\n- node_modules/\n- dist/\n- .git/\n- build/\n- target/\n- __pycache__/\n`,
+        '.agent/rules/patterns.md': `# Patrones y convenciones — ${projectName}\n\n## Nombrado\n- Archivos: kebab-case\n- Clases: PascalCase\n- Variables y funciones: camelCase\n- Constantes: UPPER_SNAKE_CASE\n\n## Reglas generales\n- No dejar console.log de debug en codigo productivo\n- Un archivo = una responsabilidad principal\n`,
+        '.agent/context/architecture.md': '# Arquitectura — NIVEL 0\n\n> Ejecuta `agent-mp explorer` para generar documentacion automatica.\n\n| Componente | Stack | Puerto | Proposito |\n|------------|-------|--------|-----------|\n| - | - | - | - |\n',
+        '.agent/AGENT.md': `# Instrucciones para Sub-Agentes — ${projectName}\n\n## Paso 1: Identificar tu rol\nLee .agent/INDEX.md para saber que archivo leer segun tu rol.\n\n## Paso 2: Leer el contexto\nAntes de cualquier accion, lee .agent/context/architecture.md.\n\n## Paso 3: Actua SOLO dentro de tu rol\nVer .agent/rules/workflow.md para las reglas de separacion de roles.\n`,
     };
     for (const [fp, content] of Object.entries(templates)) {
         await fs.mkdir(path.join(projectDir, path.dirname(fp)), { recursive: true });

package/dist/commands/setup.js

@@ -293,12 +293,15 @@ export function setupCommand(program) {
         console.log(chalk.green('  ✓ .agent/config.json generated'));
         // Generate templates
         const templates = {
-            '.agent/INDEX.md': `# ${projectName} — Agent Entry Point\n\n> Leé este archivo antes de cualquier accion.\n\n## Proyecto\n\n## Navegacion por rol\n| Si sos... | Lee primero... |\n|-----------|----------------|\n| ORCHESTRATOR | .agent/rules/workflow.md |\n| IMPLEMENTOR | .agent/tasks/{ID}/plan.json |\n| REVIEWER | .agent/rules/workflow.md |\n`,
-            '.agent/rules/workflow.md': '# Agent Workflow Contract\n\n## REGLA #1 — Separacion de roles\nUn rol NUNCA ejecuta acciones de otro rol.\n\n## REGLA #2 — Un CLI NO cambia de rol\n\n## Roles\n- ORCHESTRATOR: planifica, genera plan.json\n- IMPLEMENTOR: ejecuta el plan\n- REVIEWER: valida, genera result.md\n',
-            '.agent/rules/structure.md': '# Estructura\n\n## Aprobados\n.\n\n## Prohibidos\nnode_modules, dist, .git\n',
-            '.agent/rules/patterns.md': '# Patrones\n\n- kebab-case para archivos\n- PascalCase para clases\n- camelCase para variables\n',
-            '.agent/context/architecture.md': '# Arquitectura — NIVEL 0\n\n| Servicio | Stack | Puerto | Detalle |\n|----------|-------|--------|---------|\n| - | - | - | - |\n',
-            '.agent/AGENT.md': '# Sub-Agentes\n\n1. Lee .agent/INDEX.md\n2. Lee .agent/rules/workflow.md\n3. Actua SOLO dentro de tu rol\n',
+            '.agent/INDEX.md': `# ${projectName} — Agent Entry Point\n\n> Leé este archivo antes de cualquier accion.\n\n## Proyecto\n${projectName}\n\n## Navegacion por rol\n| Si sos... | Lee primero... | Luego... |\n|-----------|----------------|----------|\n| ORCHESTRATOR | .agent/rules/workflow.md | .agent/rules/orchestrator.md |\n| IMPLEMENTOR | .agent/rules/implementor.md | .agent/tasks/{ID}/plan.json |\n| REVIEWER | .agent/rules/reviewer.md | .agent/rules/workflow.md |\n\n## Contexto del proyecto\n- Arquitectura: .agent/context/architecture.md\n- Stack: ver .agent/config.json\n`,
+            '.agent/rules/workflow.md': `# Workflow Contract — ${projectName}\n\n## Flujo general\n\`\`\`\n[ORCHESTRATOR] planifica → genera plan.json\n       ↓\n[IMPLEMENTOR] ejecuta el plan → modifica archivos\n       ↓\n[REVIEWER] valida → genera result.md\n\`\`\`\n\n## REGLA #1 — Separacion de roles\nCada CLI opera SOLO en su rol. Nunca ejecuta acciones de otro rol.\n\n## REGLA #2 — Orden estricto\nOrchestrator siempre primero. Implementor no actua sin plan. Reviewer no actua sin implementacion.\n\n## REGLA #3 — Sin inventar\nCada rol trabaja con los archivos reales del proyecto. No asume ni infiere sin leer.\n\n## REGLA #4 — Escalada\nSi un rol encuentra un bloqueante, lo reporta. No lo omite ni lo parchea silenciosamente.\n`,
+            '.agent/rules/orchestrator.md': `# Rol: ORCHESTRATOR — ${projectName}\n\n## Responsabilidad\nAnalizar el requerimiento, leer el contexto del proyecto y generar un plan de tareas claro y ejecutable.\n\n## Antes de planificar\n1. Leer .agent/context/architecture.md para entender los componentes\n2. Leer .agent/rules/structure.md para saber qué dirs son validos\n3. Leer .agent/rules/patterns.md para respetar convenciones del proyecto\n\n## Al generar el plan\n- Dividir el trabajo en pasos atómicos (1 paso = 1 cambio verificable)\n- Especificar rutas de archivos REALES (no genéricas)\n- Indicar dependencias entre pasos si las hay\n- Estimar impacto: qué puede romperse con cada cambio\n\n## Prohibido\n- Modificar archivos de código directamente\n- Ejecutar comandos de build o test\n- Tomar decisiones de arquitectura sin documentarlas en el plan\n`,
+            '.agent/rules/implementor.md': `# Rol: IMPLEMENTOR — ${projectName}\n\n## Responsabilidad\nEjecutar el plan generado por el Orchestrator. Modificar archivos de código siguiendo las instrucciones exactas del plan.\n\n## Antes de implementar\n1. Leer .agent/tasks/{ID}/plan.json completo\n2. Leer .agent/rules/structure.md — no crear archivos en dirs prohibidos\n3. Leer .agent/rules/patterns.md — respetar convenciones de nombres y estructura\n\n## Al implementar\n- Seguir el plan paso a paso, en orden\n- Si un paso no es claro, documentar la ambigüedad, no improvisar\n- Marcar cada paso como completado al terminarlo\n- No agregar cambios fuera del scope del plan\n\n## Prohibido\n- Modificar el plan (eso es rol del Orchestrator)\n- Hacer refactors no solicitados\n- Ignorar pasos del plan aunque parezcan redundantes\n`,
+            '.agent/rules/reviewer.md': `# Rol: REVIEWER — ${projectName}\n\n## Responsabilidad\nValidar que la implementacion cumple el plan, no rompe nada existente y respeta las reglas del proyecto.\n\n## Checklist de revision\n- [ ] Cada paso del plan fue implementado\n- [ ] No se modificaron archivos fuera del scope del plan\n- [ ] Se respetan las convenciones de .agent/rules/patterns.md\n- [ ] La estructura de dirs cumple .agent/rules/structure.md\n- [ ] No hay codigo muerto ni imports sin usar introducidos\n- [ ] Si hay tests, pasaron\n\n## Al generar result.md\n- Indicar cada item del checklist como OK / FAIL / SKIP con razon\n- Si hay FAILs: describir exactamente qué falta y en qué archivo\n- Si todo OK: marcar la tarea como DONE\n\n## Prohibido\n- Modificar archivos de código directamente\n- Aprobar implementaciones incompletas\n- Omitir items del checklist\n`,
+            '.agent/rules/structure.md': `# Estructura del proyecto — ${projectName}\n\n## Directorios aprobados\n- . (raiz del proyecto)\n\n## Directorios prohibidos (no crear ni modificar archivos aca)\n- node_modules/\n- dist/\n- .git/\n- build/\n- target/\n- __pycache__/\n- .venv/\n\n## Convenciones de ubicacion\n- Codigo fuente: src/\n- Tests: src/**/*.test.* o tests/\n- Config: raiz del componente\n- Scripts: scripts/\n`,
+            '.agent/rules/patterns.md': `# Patrones y convenciones — ${projectName}\n\n## Nombrado\n- Archivos: kebab-case (mi-archivo.ts)\n- Clases: PascalCase (MiClase)\n- Variables y funciones: camelCase (miVariable)\n- Constantes: UPPER_SNAKE_CASE (MI_CONSTANTE)\n\n## Estructura de commits\n- feat: nueva funcionalidad\n- fix: correccion de bug\n- chore: tareas de mantenimiento\n- docs: solo documentacion\n\n## Reglas generales\n- No dejar console.log / print de debug en código productivo\n- Un archivo = una responsabilidad principal\n- Preferir cambios pequeños y verificables sobre refactors grandes\n`,
+            '.agent/context/architecture.md': '# Arquitectura — NIVEL 0\n\n> Ejecuta `agent-mp explorer` para generar documentacion automatica.\n\n| Componente | Stack | Puerto | Proposito |\n|------------|-------|--------|-----------|\n| - | - | - | - |\n',
+            '.agent/AGENT.md': `# Instrucciones para Sub-Agentes — ${projectName}\n\n## Paso 1: Identificar tu rol\nLee .agent/INDEX.md para saber que archivo leer segun tu rol.\n\n## Paso 2: Leer el contexto\nAntes de cualquier accion, lee .agent/context/architecture.md.\n\n## Paso 3: Actua SOLO dentro de tu rol\nVer .agent/rules/workflow.md para las reglas de separacion de roles.\n`,
         };
         for (const [fp, content] of Object.entries(templates)) {
             await fs.mkdir(path.join(projectDir, path.dirname(fp)), { recursive: true });

package/dist/core/engine.js

@@ -1194,9 +1194,29 @@ INSTRUCCIONES:
         const agentDir = path.join(this.projectDir, '.agent');
         const contextDir = path.join(agentDir, 'context');
         const docsDir = path.join(agentDir, 'docs');
+        const rulesDir = path.join(agentDir, 'rules');
         await fs.mkdir(contextDir, { recursive: true });
         await fs.mkdir(docsDir, { recursive: true });
-        await fs.mkdir(path.join(agentDir, 'rules'), { recursive: true });
+        await fs.mkdir(rulesDir, { recursive: true });
+        // Seed rules files if they don't exist yet (idempotent — never overwrites)
+        const proj = this.config.project;
+        const rulesSeeds = {
+            'workflow.md': `# Workflow Contract — ${proj}\n\n\`\`\`\n[ORCHESTRATOR] planifica → genera plan.json\n       ↓\n[IMPLEMENTOR] ejecuta el plan → modifica archivos\n       ↓\n[REVIEWER] valida → genera result.md\n\`\`\`\n\n## REGLA #1 — Separacion de roles\nCada CLI opera SOLO en su rol.\n\n## REGLA #2 — Orden estricto\nOrchestrator primero. Implementor no actua sin plan. Reviewer no actua sin implementacion.\n\n## REGLA #3 — Sin inventar\nCada rol trabaja con los archivos reales del proyecto.\n`,
+            'orchestrator.md': `# Rol: ORCHESTRATOR — ${proj}\n\n## Responsabilidad\nAnalizar el requerimiento, leer el contexto y generar un plan de tareas ejecutable.\n\n## Antes de planificar\n1. Leer .agent/context/architecture.md\n2. Leer .agent/rules/structure.md\n3. Leer .agent/rules/patterns.md\n\n## Al generar el plan\n- Pasos atomicos (1 paso = 1 cambio verificable)\n- Rutas de archivos REALES\n- Dependencias entre pasos si las hay\n\n## Prohibido\n- Modificar archivos de codigo directamente\n- Ejecutar comandos de build o test\n`,
+            'implementor.md': `# Rol: IMPLEMENTOR — ${proj}\n\n## Responsabilidad\nEjecutar el plan del Orchestrator. Modificar archivos de codigo siguiendo las instrucciones exactas.\n\n## Antes de implementar\n1. Leer .agent/tasks/{ID}/plan.json completo\n2. Leer .agent/rules/structure.md\n3. Leer .agent/rules/patterns.md\n\n## Al implementar\n- Seguir el plan paso a paso, en orden\n- No agregar cambios fuera del scope\n- Marcar cada paso como completado\n\n## Prohibido\n- Modificar el plan\n- Hacer refactors no solicitados\n`,
+            'reviewer.md': `# Rol: REVIEWER — ${proj}\n\n## Responsabilidad\nValidar que la implementacion cumple el plan y respeta las reglas del proyecto.\n\n## Checklist\n- [ ] Cada paso del plan fue implementado\n- [ ] Sin archivos modificados fuera del scope\n- [ ] Convenciones de patterns.md respetadas\n- [ ] Estructura de structure.md respetada\n- [ ] Sin codigo muerto ni imports sin usar\n\n## Al generar result.md\n- Indicar cada item: OK / FAIL / SKIP con razon\n- Si FAILs: describir qué falta y en qué archivo\n\n## Prohibido\n- Modificar archivos de codigo\n- Aprobar implementaciones incompletas\n`,
+            'structure.md': `# Estructura — ${proj}\n\n## Directorios aprobados\n- . (raiz del proyecto)\n\n## Prohibidos\n- node_modules/, dist/, .git/, build/, target/, __pycache__/, .venv/\n`,
+            'patterns.md': `# Patrones — ${proj}\n\n## Nombrado\n- Archivos: kebab-case\n- Clases: PascalCase\n- Variables/funciones: camelCase\n- Constantes: UPPER_SNAKE_CASE\n\n## Reglas generales\n- Sin console.log de debug en produccion\n- Un archivo = una responsabilidad principal\n`,
+        };
+        for (const [name, content] of Object.entries(rulesSeeds)) {
+            const fp = path.join(rulesDir, name);
+            try {
+                await fs.access(fp);
+            }
+            catch {
+                await writeFile(fp, content);
+            } // only create if missing
+        }
         // NOTE: cleanup of stray files moved to AFTER successful parse, to avoid
         // wiping previous docs when the explorer fails (e.g. tool-call hallucination).
         // Build a quick filesystem snapshot to give the explorer context
@@ -1314,204 +1334,254 @@ ESTRUCTURA DE LOS 3 NIVELES
 ================================================================
 
 ────────────────────────────────────────────────────────────────
-NIVEL 0 — architecture.md (raiz de .agent/context/)
-Indice global. Objetivo: 50-150 lineas. Concreto.
 ────────────────────────────────────────────────────────────────
-Secciones obligatorias:
+NIVEL 0 — architecture.md  (raiz de .agent/context/)
+Objetivo: 80-150 lineas. Panorama global real, no generico.
+────────────────────────────────────────────────────────────────
 
-# ${this.config.project} — Arquitectura Global (NIVEL 0)
+# [Nombre del proyecto] — Arquitectura Global (NIVEL 0)
 
-> Indice de servicios y relaciones. Lectura escalonada:
+> Lectura escalonada:
 >   NIVEL 0: este archivo
 >   NIVEL 1: .agent/context/[componente]/architecture.md
 >   NIVEL 2: .agent/context/[componente]/modules/[modulo].md
 
 ## 1. Overview funcional
-2-4 lineas en lenguaje simple: que es el sistema, para quien sirve, que problema resuelve.
+2-4 lineas. Que es el sistema, para quien sirve, que problema resuelve.
+Si hay multiples componentes con roles distintos, nombrarlos y contrastarlos en el overview:
+ej. "X es la API de ingesta (escritura, batch), Y es la API de gestion (CRUD, portal Nexus)."
 
 ## 2. Componentes del proyecto
-| Componente | Tipo | Stack + version | Puerto | Proposito (negocio) | Entry point |
-|------------|------|-----------------|--------|---------------------|-------------|
-(una fila por componente, con datos REALES)
+| Componente | Stack (version exacta) | Puerto | Rol principal | Consumers tipicos |
+|---|---|---|---|---|
+(datos REALES del manifest. "Consumers tipicos" = quien llama a este componente: frontend, proceso batch, sistema externo)
 
 ## 3. Relaciones entre componentes
-| Origen | Destino | Tipo (HTTP / Import / DB / Queue / CORS) | Proposito |
-|--------|---------|------------------------------------------|-----------|
-(una fila por cada relacion confirmada)
+| Origen | Destino | Tipo | Proposito |
+|---|---|---|---|
+(incluir URLs/hosts reales si aparecen en .env o config: ej. "http://57.151.96.13:8000/v1/validate")
 
 ## 4. Diagrama de arquitectura
-\`\`\`
-[Frontend Web] ──HTTP──> [API Auth :8081]
-       │                        │
-       │                        v
-       └──HTTP──> [API Core :8080] ──> [MongoDB]
+Usar box-drawing (┌─┐│└┘┬┴├┤) y flechas (→ ──> ▼ ▲). Mostrar puertos REALES.
+Incluir endpoints clave inline en los componentes cuando se conocen.
+\`\`\`text
+┌─────────────────────┐         ┌──────────────────────┐
+│ componente-a :8083  │         │ componente-b :8084    │
+│ POST /api/sales     │         │ GET /api/nexus/combos │
+│ POST /api/stock     │────────>│ PUT /api/nexus/...    │
+└──────────┬──────────┘         └──────────────────────┘
+           │                               │
+           ▼                               ▼
+    ┌──────────────┐              ┌──────────────┐
+    │  SQL Server  │              │  Auth Service│
+    │  :31434      │              │  :8000       │
+    └──────────────┘              └──────────────┘
 \`\`\`
 
-## 5. Flujos end-to-end principales (3-5)
-Mappings funcional → tecnico, paso a paso. Ejemplo:
-- **"Un usuario crea un pedido"**: WebApp → POST /orders (API Core) → valida JWT contra API Auth → guarda en MongoDB → devuelve 201 con el pedido.
+## 5. Flujos end-to-end principales
+Concretos, con componentes, endpoints y acciones reales. 2-5 flujos.
+- **"Nombre del flujo":** Actor → POST /endpoint (componente-a) → valida JWT con auth-service → escribe en SQL Server → responde 201.
 
-## 6. Prerequisitos para levantar el proyecto
-Versiones REALES leidas de los manifests (no rangos genericos).
+## 6. Prerequisitos para levantar
+Solo lo que es real: acceso de red a hosts externos, herramientas requeridas. Sin generalidades.
 
-## 7. Comandos globales de desarrollo
+## 7. Comandos de desarrollo
 | Comando | Descripcion | Directorio |
-
-## 8. Decisiones de arquitectura globales (opcional, solo si hay)
+|---|---|---|
+(comandos reales del Makefile, run.sh, package.json scripts, mvnw, etc.)
 
 ────────────────────────────────────────────────────────────────
 NIVEL 1 — [componente]/architecture.md
-Detalle del componente. Objetivo: 80-200 lineas. Crear UNO POR CADA componente NO trivial.
+Objetivo: 120-250 lineas. Un archivo por cada componente no trivial.
 ────────────────────────────────────────────────────────────────
-Secciones obligatorias:
 
 # [componente] — Arquitectura (NIVEL 1)
 
 ## Que hace
-2-3 lineas en lenguaje simple, sin tecnicismos.
+Parrafo 1: describe el rol del componente en lenguaje de negocio + quien lo consume.
+Parrafo 2 (si hay componentes hermanos): contrasta con ellos. ej. "A diferencia de X que solo escribe en bulk, esta API expone CRUD con paginacion y filtros para el portal."
 
 ## Casos de uso principales
-3-6 bullets en formato negocio:
-- "Permite al usuario X..."
-- "El sistema usa este servicio para Y..."
+Tabla con: Caso de uso | Actor (quien lo dispara) | Descripcion + endpoint si se conoce.
+| Caso de uso | Actor | Descripcion |
+|---|---|---|
+| Ingesta de ventas | Proceso batch BAT | POST /api/sales — upsert bulk de ventas finales |
+| Consulta de productos | Portal Nexus | GET /api/products?eanCode=XXX |
 
 ## Stack tecnico
 | Item | Valor |
-|------|-------|
-| Lenguaje | TypeScript 5.3 |
-| Framework | NestJS 11.0.1 |
-| ORM | Mongoose 9.3.3 |
-| Auth | Passport JWT |
-(datos reales del manifest)
+|---|---|
+| Lenguaje | Java 21 (Temurin LTS) |
+| Framework | Spring Boot 3.5.6 |
+| ORM | Spring Data JPA + Hibernate |
+| Seguridad | Spring Security 6 + JJWT |
+(versiones REALES del manifest. Si hay librerias clave como POI, MapStruct, HikariCP: incluirlas)
 
 ## Puerto y URLs
-- **Puerto:** 8085 (de PORT en .env)
-- **Swagger / docs:** http://localhost:8085/api/docs (si aplica)
-- **Health check:** GET /health (si existe)
-
-## Estructura interna (arbol real)
-Listar DIRECTORIOS clave + los archivos que leiste (los CONTROLLER/ROUTER y SCHEMA/MODEL del prefetch).
+| Recurso | URL |
+|---|---|
+| API base | http://localhost:8084 |
+| Swagger / docs | http://localhost:8084/swagger-ui/index.html |
+| Perfil activo | development (application-development.properties) |
+
+## Estructura de capas / paquetes
+Arbol con los archivos y directorios REALES que leiste. Usar → para anotar inline que hace cada clase o directorio.
+\`\`\`text
+paquete.raiz/
+├── controller/        → endpoints REST, delegan a service, responden ApiResponse<T>
+│   ├── ClientController     → CRUD /api/clients
+│   ├── SaleController       → POST /api/sales, /api/sales/interim-sales
+│   └── ExportController     → GET /api/export/combos (genera .xlsx)
+├── service/           → interfaces de logica de negocio
+│   └── impl/          → implementaciones (@Transactional aqui)
+├── repository/        → Spring Data JPA Repositories
+├── domain/            → Entidades JPA (@Entity)
+│   ├── Client, InterimClient  → clientes finales y en staging
+│   ├── Sale, InterimSale      → ventas finales y en staging
+│   └── compositekeys/         → @IdClass para PKs compuestas
+├── dto/               → contratos de API (Request/Response DTOs)
+├── mapper/            → MapStruct: Entity ↔ DTO
+├── security/          → filtros JWT, validacion, handler 401
+└── configuration/     → CORS, Swagger, SecurityConfig
 \`\`\`
-src/
-├── main.ts                      # entry point, configura CORS y swagger
-├── auth/
-│   ├── auth.controller.ts       # endpoints /auth/login, /auth/refresh
-│   └── auth.service.ts          # logica de validacion JWT
-├── leads/
-│   ├── leads.controller.ts      # endpoints /leads
-│   └── lead.schema.ts           # modelo Lead { name, email, status }
-└── ...
+(Adaptar a la estructura real del proyecto: puede ser src/, app/, pkg/, etc.)
+
+## Endpoints reales
+SOLO los que se leyeron en los CONTROLLER/ROUTER files. Incluir columna Auth si se conoce.
+| Metodo | Ruta | Auth | Funcion |
+|---|---|---|---|
+| GET | /api/clients | JWT | Lista clientes (paginado, filtrable) |
+| POST | /api/sales | JWT | Upsert bulk de ventas finales |
+| GET | /api/export/combos | JWT/Azure | Descarga Excel con combos |
+(querystring params relevantes en la ruta, ej. ?eanCode= , ?page=&size= )
+
+## Formato de respuesta (si hay wrapper estandar)
+Si el codigo muestra un wrapper comun para todas las respuestas, documentarlo:
+\`\`\`json
+{
+  "status": 200,
+  "message": "Operacion exitosa",
+  "data": [...],
+  "pagination": { "page": 1, "size": 15, "totalElements": 120, "totalPages": 8 }
+}
 \`\`\`
-Para Java, usar el arbol de packages: src/main/java/.../controller/, .../domain/, .../service/, etc.
-Si no se leyo el codigo fuente, mencionar solo los directorios visibles en la estructura de archivos.
+Si no hay wrapper, omitir esta seccion.
 
 ## Modulos internos
-IMPORTANTE: nombrar cada modulo por su FEATURE (clients, sales, products), no por su capa (web, data, service).
-Los modulos surgen de los controllers que se leyeron: un controller → un modulo.
-| Modulo | Proposito (negocio) | Doc tecnica |
-|--------|---------------------|-------------|
-| auth | Login y validacion de tokens | modules/auth.md |
-| leads | Listado y consulta de negocios | modules/leads.md |
-
-## Endpoints principales
-| Metodo | Ruta | Modulo | Que hace (lenguaje simple) |
-|--------|------|--------|----------------------------|
-| GET | /leads | leads | Lista negocios filtrables |
-| GET | /leads/:id | leads | Detalle de un negocio |
-(SOLO endpoints reales extraidos de los controllers — metodo HTTP, ruta, y descripcion en 1 linea)
-
-## Variables de entorno
-| Variable | Default | Proposito |
-|----------|---------|-----------|
-| PORT | 8085 | Puerto del servicio |
-| MONGODB_URI | mongodb://... | Conexion principal |
-
-## Integraciones con otros servicios / sistemas
-| Servicio externo | Tipo (HTTP/DB/Queue) | Proposito |
+| Modulo | Proposito | Doc tecnica |
+|---|---|---|
+| seguridad | Autenticacion JWT/Azure, roles, filtro HTTP | modules/security.md |
+| acceso-datos | JPA, Specifications, pool, entidades | modules/data-access.md |
+| api-web | Controladores, DTOs, validacion, exportacion | modules/web-api.md |
+(Agrupar por responsabilidad tecnica real, no inventar modulos)
+
+## Variables de configuracion clave
+| Propiedad / Variable | Valor actual | Proposito |
+|---|---|---|
+| server.port | 8084 | Puerto de la API |
+| spring.datasource.url | jdbc:sqlserver://... | Conexion SQL Server |
+| auth.url | http://57.151.96.13:8000/v1/validate | Servicio externo de validacion JWT |
+(Valores REALES del archivo de config/env leido. Si no se leyo el archivo, omitir la tabla)
 
 ## Como levantar
-- **Instalar deps:** \`npm install\`
-- **Servicios necesarios:** MongoDB corriendo, security-api accesible
-- **Comando para iniciar:** \`npm run start:dev\`
-
-## Comandos disponibles
-| Comando | Que hace |
+Comando principal primero. Luego paso a paso si existe.
+\`\`\`bash
+./run.sh        # compila y levanta todo en uno (si existe)
+\`\`\`
+O paso a paso:
+\`\`\`bash
+source ./scripts/env.sh
+npm install && npm run dev
+\`\`\`
 
-## Decisiones tecnicas relevantes
-(solo si hay decisiones notables; si no, omitir esta seccion)
+## Testing (si hay tests en el proyecto)
+Frameworks, comando para correr, cobertura minima si se menciona en el manifest o config.
+\`\`\`bash
+npm test               # todos los tests
+npm test -- --watch    # modo watch
+\`\`\`
 
 ────────────────────────────────────────────────────────────────
 NIVEL 2 — [componente]/modules/[modulo].md
-Detalle de un modulo interno. Objetivo: 40-120 lineas. Crear UNO POR cada modulo significativo.
+Objetivo: 50-120 lineas. Un archivo por modulo significativo.
 ────────────────────────────────────────────────────────────────
-Secciones obligatorias:
 
-# Modulo: [nombre] — [componente]
+# Modulo: [Nombre] — [componente]
 
 ## Funcion (lenguaje simple)
-1-2 lineas: "Permite al usuario gestionar X" / "El sistema usa este modulo para Y".
+1-2 lineas: "Protege todos los endpoints /api/**. Cada request debe llevar un token JWT valido."
 
 ## Funcion (tecnica)
-1-2 lineas: como esta implementado a alto nivel.
-
-## Flujos / casos de uso (1-3)
-Escenarios paso a paso. Ejemplo:
-- **Crear un pedido:** Cliente → POST /orders → middleware valida JWT → service.create() → guarda en DB → responde 201
-
-## Endpoints / interfaces publicas (si aplica)
-| Metodo | Ruta | Body | Respuesta |
-|--------|------|------|-----------|
-
-## Modelos / schemas relevantes
-\`\`\`typescript
-// shape REAL extraido del archivo de schema/model
-{
-  _id: ObjectId,
-  name: string,
-  createdAt: Date,
-  ...
-}
+1-2 lineas: como esta implementado. ej. "Filtro OncePerRequestFilter que extrae el JWT del header Authorization, lo valida contra el servicio externo auth.url, y si es valido establece el SecurityContext."
+
+## Flujo principal (diagrama ASCII)
+Para modulos de seguridad, acceso a datos, o cualquiera con logica de decision/secuencia:
+mostrar el flujo con ASCII art y nombres REALES de clases/metodos.
+\`\`\`text
+HTTP Request
+    │
+    ▼
+AuthFilter (OncePerRequestFilter)
+    │
+    ├── X-User-Source == "Azure"?
+    │       ▼ SI
+    │   AzureHeaderValidator → construye usuario virtual desde headers
+    │
+    └── NO
+        ▼
+    JwtValidator → POST http://auth-service/validate → carga usuario de BD
+    │
+    ▼
+SecurityContextHolder.setAuthentication(...)
+    │
+    ▼
+@PreAuthorize("hasAnyAuthority('ROLE_A','ROLE_B')") en el controller
 \`\`\`
 
-## Reglas de negocio
-- Validaciones: ...
-- Condiciones especiales: ...
-- Excepciones: ...
+## Entidades / modelos relevantes (si aplica)
+Para modulos de acceso a datos: tabla de entidades con su proposito y notas.
+| Entidad | Proposito | Notas |
+|---|---|---|
+| Client | Clientes finales | Clave compuesta: ClientId |
+| InterimClient | Clientes en staging | Tabla intermedia antes de procesar |
+
+## Reglas del modulo
+- Rutas protegidas: /api/** → autenticacion obligatoria
+- Rutas publicas: OPTIONS /**, /swagger-ui/**, /*
+- Sin sesion: STATELESS — sin cookies
+- ddl-auto=validate → el schema nunca se auto-modifica
 
 ## Archivos clave
-OBLIGATORIO: listar los archivos FUENTE reales que encontraste en los pre-fetched data.
-NO poner solo el manifest. Si no hay fuentes leidas para este modulo, omitir la seccion.
-| Archivo (ruta relativa al componente) | Rol |
-|---------------------------------------|-----|
-| src/main/java/.../ClientController.java | Expone endpoints REST /clients |
-| src/main/java/.../Client.java | Entidad JPA mapeada a tabla CLIENTS |
-| src/main/java/.../ClientRepository.java | Acceso a datos via JPA |
-| src/clients/clients.controller.ts | Endpoints /clients (Node.js) |
-| src/clients/clients.service.ts | Logica de negocio (Node.js) |
+Rutas RELATIVAS al directorio raiz del componente (no rutas absolutas, no solo el manifest).
+| Archivo | Rol |
+|---|---|
+| security/AuthFilter.java | Filtro principal — intercepta y valida cada request |
+| security/JwtValidator.java | Extrae username del JWT, verifica firma y expiracion |
+| configuration/SecurityConfig.java | Define SecurityFilterChain, rutas publicas/protegidas |
+| application-development.properties | auth.url, security.token.secret, security.token.expiration |
 
 ## Dependencias
-- **Internas (mismo componente):** auth, common
-- **Externas:** mongoose, class-validator
-- **Cross-component:** llama a security-api via HTTP para validar JWT
+- Librerias clave con version si se conoce: io.jsonwebtoken:jjwt:0.9.1, spring-boot-starter-security
+- Cross-component si corresponde: "llama a http://auth-service:8000/v1/validate para validar tokens"
 
 ================================================================
 CALIBRACION DE DETALLE
 ================================================================
-- NIVEL 0: 50-150 lineas (no menos, no mas)
-- NIVEL 1: 80-200 lineas por componente
-- NIVEL 2: 40-120 lineas por modulo
-- Si te queda corto → leiste pocos archivos, no agregues relleno — simplemente genera con lo que hay
-- Si te queda largo → estas repitiendo o agregando relleno, recorta
+- NIVEL 0: 80-150 lineas
+- NIVEL 1: 120-250 lineas por componente
+- NIVEL 2: 50-120 lineas por modulo
+- Si te queda corto → incluir mas endpoints reales, mas clases en el arbol, mas config values
+- Si te queda largo → estas repitiendo entre niveles o agregando relleno; recorta
 
 ================================================================
 QUE NO HACER
 ================================================================
 - NO usar "Inferido", "Probablemente", "(asumido)", "(quizas)", "parece"
 - NO repetir lo mismo entre niveles sin agregar valor (cada nivel zoomea mas)
-- NO dejar tablas vacias ni con placeholders tipo "..."
-- NO mezclar lenguaje tecnico puro: SIEMPRE empezar funcional, despues tecnico
-- NO documentar componentes triviales (scripts, docs, configs sueltas) con su propia carpeta — mencionalos en NIVEL 0 y listo
-- NO inventar endpoints, env vars, puertos o schemas que no leiste
+- NO dejar tablas vacias ni con placeholders tipo "..." o "ver manifest"
+- NO escribir overview que podria aplicar a cualquier proyecto (tiene que ser especifico de ESTE proyecto)
+- NO documentar componentes triviales (scripts sueltos, configs simples) con carpeta propia — mencionalos en NIVEL 0 y listo
+- NO inventar endpoints, env vars, puertos, hosts, clases o schemas que no leiste en los archivos reales
 
 ================================================================
 FORMATO DE SALIDA — OBLIGATORIO

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-mp",
-  "version": "0.5.20",
+  "version": "0.5.22",
   "description": "Deterministic multi-agent CLI orchestrator — plan, code, review",
   "type": "module",
   "main": "./dist/index.js",