← Volver al BBP
AgentRoom · As-Is / To-Be
SuperArqDev · auditoría y arquitectura

AgentRoom · As-Is / To-Be

Catastro de lo construido, hallazgos de la auditoría, las veintiuna piezas que faltan y el plan de migración por fases.

Resumen ejecutivo

Un motor maduro con una casa a medio construir

El catastro deja una asimetría clara: lo que analiza y publica está maduro y en producción; lo que transacciona no existe todavía. El motor son unas 6.400 líneas bien documentadas, con decisiones registradas como ADR dentro del propio código — mejor que la mayoría de lo auditable. Alrededor no hay pruebas, ni CI, ni hasta hoy repositorio.

La consecuencia práctica: el producto que la landing describe necesita veintiuna piezas nuevas, pero ninguna se puede construir con seguridad hasta que exista la red de pruebas. Por eso la Fase 0 no construye producto.

Score68/100SQALE C. Baja por ausencia de pruebas y CI, no por calidad del código.
Cobertura de pruebas0%Cero archivos de test sobre un motor que ya corre en producción.
Piezas por construir21De ellas, 14 son bloqueantes para la promesa de la landing.
La regla que ordena todo el plan: verificar precio y stock en vivo antes de crear cualquier orden. Prometer desde una copia es vender lo que no existe, y con agentes eso escala más rápido que con personas.
Técnico · As-Is

Qué hay construido hoy

Cuatro capas, con madurez muy distinta entre ellas.

graph TB
    P["Persona
en su asistente"] IA["Asistente de IA
ChatGPT · Claude · Perplexity"] C["Comercio
su sitio web"] subgraph AR["AgentRoom · lo construido"] MA["Motor de análisis
16 checks · 2 capas"] GE["Gemelo digital
catálogo normalizado"] PU["Publicación
llms.txt · JSON · páginas"] MCP["Servidor MCP
solo catálogo"] EN["Corte de servicio
por solicitud"] end BL[("Vercel Blob
informes y gemelos")] LLM["LLM
Anthropic o Gemini"] RS["Resend
verificación"] C -->|"se analiza una vez"| MA MA -->|"captura pura"| GE MA -->|"4 de 16 checks"| LLM GE --> PU GE --> MCP PU --> BL EN -.->|"consulta en cada request"| PU EN -.-> MCP IA -->|"lee superficies"| PU IA -->|"JSON-RPC"| MCP P --> IA MA --> RS
El único camino que existe hoy va del comercio al asistente en modo lectura. No hay ninguna flecha de vuelta: nada de lo construido puede cerrar una compra ni responder por un pedido.

Las cuatro capas

CapaEstadoQué contiene
Análisis● madura · producción Captura sin navegador (490 L) · perfilado · 16 checks en dos capas, legibilidad L01–L08 y transaccionabilidad T09–T16 (1.056 L) · puntaje sobre checks aplicables · juicio LLM con doble proveedor y tabla de costos · informe HTML autocontenido (599 L) · comparación antes/después
Gemelo● madura · producción Gemelo como función pura sobre la captura (467 L) · superficies generadas al vuelo: llms.txt, catálogo JSON, índice y producto · Puertas C y D con el mismo código · corte de servicio por solicitud · servidor MCP (241 L), hoy solo catálogo
Comercial◐ parcial Leads con verificación por correo · promociones y ofertas validadas en servidor · precio de diagnóstico. Sin cuenta de comercio ni metering.
Web◐ nueva, sin desplegar Landing Next 16, tema claro, 15 secciones, desktop-first · BBP y panel heredados

Flujo de análisis, tal como corre hoy

sequenceDiagram
    autonumber
    participant U as Comercio
    participant A as /api/analizar
    participant G as guardas.ts
    participant K as captura.ts
    participant I as informe.ts
    participant L as llm.ts
    participant B as Blob
    U->>A: dominio en un formulario público
    A->>G: valida destino y presupuesto
    Note over G: la URL la escribe un desconocido:
superficie hostil por diseño (ADR-0016) G->>K: destino aprobado K->>K: robots.txt, HTML, sin ejecutar JS K-->>I: Captura inmutable Note over I: de aquí en adelante nadie toca la red (ADR-0013) I->>I: perfil + 12 checks deterministas I->>L: 4 checks que el determinismo no alcanza L-->>I: juicio + costo por token I->>B: informe y gemelo B-->>U: informe navegable
La separación captura/evaluación (ADR-0013) permite reevaluar los checks sin volver a golpear el sitio del comercio. Es lo que hace barato iterar sobre los 16 checks — y lo que haría baratos los tests que faltan.

Hallazgos de la auditoría

Alta · H1

Dependencias vulnerables

4 high y 1 moderate. next tiene fix no mayor (16.2.12 → 16.3.1) que resuelve las cuatro high. @vercel/blob requiere salto mayor para la moderate.

Fix: npm i next@16.3.1 y verificar build. El de blob, evaluar aparte contra el store real.

Alta · H2

Cero pruebas automatizadas

Ni un archivo de test en todo el repo, incluidos los 16 checks que producen el puntaje que se le vende al comercio. Agrava que src/lib/handler-vercel.ts es código nuevo, sin pruebas, en el camino de las nueve funciones.

Alta · H3

Sin CI/CD

No hay .github/. El deploy es manual, sin gate de typecheck, lint ni auditoría.

Media · H4

Fixtures fuera de control de versiones

78 MB de capturas, informes y gemelos reales quedaron en el repo original. Son justamente los insumos que permitirían escribir los tests de H2 sin tocar la red.

Media · H5

El motor estuvo en producción sin repositorio

Corregido hoy con el commit inicial. Hasta el 20-ago-2026 no había historia, ni rollback, ni revisión sobre lo que sirve vado.junngla.com.

Baja · H6

Deuda de nombres tras la absorción

Quedan referencias a la marca anterior en correos, créditos y el user-agent VadoBot/1.0. No tocar el user-agent sin pensarlo: puede estar en listas de permitidos de comercios.

Lo que se revisó a mano y salió limpio

Guardas de destino y presupuestoDonde esperaba encontrar SSRF, está tratado explícitamente como superficie hostil (ADR-0016).
Corte de servicioSe consulta por solicitud, sin artefacto que sobreviva al corte (ADR-0008). Verificado en vivo: responde 410.
Promociones en servidorEl descuento lo emite y guarda el servidor, no el cliente.
Sin secretosgitleaks sin filtraciones; credenciales por entorno, fuente única en Infisical.

Herramientas ausentes en el equipo (semgrep, trivy, checkov, hadolint): la revisión de inyección y control de acceso fue manual sobre los nueve puntos de entrada. No se afirma exhaustividad.

Técnico · To-Be

La arquitectura objetivo

Monolito modular sobre serverless. Con un desarrollador, extraer servicios sería ceremonia sin beneficio: los límites se fuerzan con módulos y reglas de dependencia, no con red.

graph TB
    IA["Asistentes de IA"]
    C["Comercio"]
    subgraph AR["AgentRoom"]
        subgraph EX["Construido"]
            AN["Análisis
16 checks"] GE["Gemelo"] PUB["Publicación"] MCPC["MCP catálogo"] end subgraph N1["Fase 1 · adhesión y distribución"] CU["P1 Cuenta
del comercio"] IN["P2 Ingesta
continua"] FR["P3 Frescura
con vencimiento"] DE["P7 Declaración
.well-known"] OB["P18 Métricas de
distribución"] end subgraph N2["Fase 2 · la caja"] AG["P5 Registro de
agentes"] PV["P16 Postventa"] VI["P14 Vínculo
cliente-tienda"] RE["P13 Recibo
verificable"] ME["P19 Metering"] end subgraph N3["Fase 3 · transacción"] VE["P9 Verificación
en vivo"] RS["P10 Reserva"] OR["P11 Checkout
y Order"] DB[("P17 Persistencia
real")] end end C --> CU C --> IN IN --> GE GE --> FR FR --> PUB CU --> AG AG --> MCPC DE -.->|"vive en el dominio
del comercio"| IA IA --> MCPC IA --> PUB MCPC --> PV PV --> VI VE -->|"antes de cualquier orden"| RS RS --> OR OR --> RE RE --> ME OR --> DB VE -.->|"consulta en vivo"| C IA -.-> OB
Las líneas punteadas son las dos que deciden si el producto funciona: la declaración que vive en el dominio del comercio —que es lo que produce distribución— y la verificación en vivo contra el comercio antes de comprometer una compra.

Modelo de datos objetivo

erDiagram
    MERCHANT ||--o{ AGENT : publica
    MERCHANT ||--|| CATALOG : mantiene
    CATALOG ||--o{ OFFER : contiene
    MERCHANT ||--o{ ORDER : recibe
    OFFER ||--o{ CHECKOUT_SESSION : origina
    CHECKOUT_SESSION ||--o| RESERVATION : sostiene
    CHECKOUT_SESSION ||--o| ORDER : concreta
    ORDER ||--|| RECEIPT : deja
    ORDER ||--o{ POST_SALE_CASE : puede_abrir
    CUSTOMER_LINK ||--o{ POST_SALE_CASE : habilita
    MERCHANT { string id string dominio string estado_servicio }
    AGENT { string id string tipo string capacidades }
    CATALOG { string fuente datetime sincronizado_en }
    OFFER { string sku money precio string procedencia datetime observado_en }
    CHECKOUT_SESSION { money precio_bloqueado datetime vence_en }
    RESERVATION { string estado datetime vence_en }
    ORDER { string estado money total }
    RECEIPT { string hash json terminos }
    CUSTOMER_LINK { string prueba_de_vinculo }
    POST_SALE_CASE { string tipo string estado }
    
El único objeto que existe hoy es el catálogo con sus ofertas. Todo lo demás es nuevo. OFFER lleva procedencia y momento de observación porque de ahí depende si el dato puede publicarse — y CHECKOUT_SESSION lleva precio bloqueado con vencimiento porque de ahí depende no sobrevender.

Las 21 piezas

#PiezaDominioEstadoPor qué importa
P1Cuenta y sesión del comercioComercioHoy no hay a quién pertenece un gemelo. Bloquea todo lo demás.
P2Ingesta continuaComercioLa captura es puntual. Faltan sincronización, webhooks y conectores de plataforma.
P3Frescura con vencimientoComercioLa procedencia existe; falta TTL y marcar lo viejo como no publicable.
P4Agent Room ManagerComercioLa administración conversacional que la landing promete.
P5Registro de agentesDistribuciónHoy se publica un catálogo, no agentes. Es lo que se le va a vender al comercio.
P6MCP ampliadoDistribuciónSolo catálogo. Faltan pedido, postventa y disponibilidad en vivo.
P7Declaración estándarDistribuciónLa pieza de distribución. Convierte cada comercio adherido en un nodo en su propio dominio.
P8Adaptadores por superficieDistribuciónUn conector por protocolo, sin tocar el núcleo.
P9Verificación en vivoTransacciónLa más crítica. Sin esto se promete desde una copia y se sobrevende.
P10ReservaTransacciónSostiene el ítem mientras se confirma la compra.
P11CheckoutSession y OrderTransacciónNo existe el objeto compra.
P12Mandato del consumidorTransacciónLa autorización con límites. Territorio de Pepe.
P13Recibo verificableTransacciónEl activo defendible: qué se ofreció, se acordó y se cobró.
P14Vínculo cliente-tiendaTransacciónSin esto no existe el escenario de postventa.
P15Atención sobre productoServicioCubierto en parte por el MCP de catálogo.
P16PostventaServicioEstado, devoluciones y reclamos. Es la demanda que sí existe hoy.
P17Persistencia realPlataformaHoy Blob. ADR-0018 pospuso el esquema a propósito; P9–P14 lo van a exigir.
P18Métricas de distribuciónPlataformaCrawlers, citas y conexiones MCP: las tres que prueban la tesis.
P19Metering y billingPlataformaLa tabla de precios de la landing no tiene nada detrás.
P20CI/CDPlataformaHallazgo H3.
P21PruebasPlataformaHallazgo H2.

Plan de migración As-Is → To-Be

FASE 0 · 30d
La red de seguridad

No construye producto: hace que construir sea seguro. Subir Next a 16.3.1 y cerrar las cuatro high. Escribir las pruebas de los 16 checks usando las fixtures reales que ya existen — y las del adaptador nuevo. Montar CI con typecheck de ambos tsconfig, lint, audit y build. Desplegar agentroom.junngla.com en un proyecto Vercel nuevo, sin tocar el de VADO.

FASE 1 · 60d
Que la adhesión exista de verdad

P1 cuenta del comercio. P2 ingesta continua, con un conector de plataforma primero, no cinco. P3 frescura con vencimiento, condición para poder prometer algo después. P7 declaración estándar en el dominio del comercio: la pieza que produce distribución. P18 para medir si está funcionando.

FASE 2 · 90d
La caja

P5 registro de agentes — vender agentes, no catálogos. P16 postventa y P15 atención, que es la demanda que existe hoy. P14 vínculo cliente-tienda, condición de P16. P13 recibo, que nace aquí y sostiene lo que viene. P19 metering, para que la tabla de precios deje de ser decorativa.

FASE 3 · 6-12m
La transacción

P9 verificación en vivo y P10 reserva, en ese orden y antes que nada más. P11 checkout y orden. P17 persistencia real: aquí sí se justifica el esquema que ADR-0018 pospuso. P6 MCP ampliado y P8 adaptadores. P12 mandato, o se resuelve con Pepe.

La regla de secuencia que no conviene romper: P9 antes que P11. Crear órdenes sin verificar precio y stock en vivo es vender lo que no existe.

Estrategia por pieza (7R)

QuéEstrategiaCómo
Motor de análisis y gemeloRetainFunciona y está documentado. No se toca salvo para agregarle pruebas.
Nueve funcionesReplatformHecho: adaptador en vez de reescritura. 900 líneas probadas quedaron intactas.
Persistencia (Blob → esquema)RefactorBranch by Abstraction: almacen.ts ya es una interfaz de tres funciones, pensada para esto.
Superficies del gemeloRetain + extenderStrangler Fig: /apps/agentroom nace al lado de /apps/vado, que se sirve para siempre.
PagosRepurchaseCommodity. Se integra, no se construye — y no custodiar evita el perímetro regulado.