Catastro de lo construido, hallazgos de la auditoría, las veintiuna piezas que faltan y el plan de migración por fases.
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.
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.
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
| Capa | Estado | Qué 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 |
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
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.
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.
No hay .github/. El deploy es manual, sin gate de typecheck, lint ni auditoría.
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.
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.
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.
gitleaks 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.
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
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 }
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.| # | Pieza | Dominio | Estado | Por qué importa |
|---|---|---|---|---|
| P1 | Cuenta y sesión del comercio | Comercio | ⛔ | Hoy no hay a quién pertenece un gemelo. Bloquea todo lo demás. |
| P2 | Ingesta continua | Comercio | ◐ | La captura es puntual. Faltan sincronización, webhooks y conectores de plataforma. |
| P3 | Frescura con vencimiento | Comercio | ◐ | La procedencia existe; falta TTL y marcar lo viejo como no publicable. |
| P4 | Agent Room Manager | Comercio | ⛔ | La administración conversacional que la landing promete. |
| P5 | Registro de agentes | Distribución | ⛔ | Hoy se publica un catálogo, no agentes. Es lo que se le va a vender al comercio. |
| P6 | MCP ampliado | Distribución | ◐ | Solo catálogo. Faltan pedido, postventa y disponibilidad en vivo. |
| P7 | Declaración estándar | Distribución | ◐ | La pieza de distribución. Convierte cada comercio adherido en un nodo en su propio dominio. |
| P8 | Adaptadores por superficie | Distribución | ⛔ | Un conector por protocolo, sin tocar el núcleo. |
| P9 | Verificación en vivo | Transacción | ⛔ | La más crítica. Sin esto se promete desde una copia y se sobrevende. |
| P10 | Reserva | Transacción | ⛔ | Sostiene el ítem mientras se confirma la compra. |
| P11 | CheckoutSession y Order | Transacción | ⛔ | No existe el objeto compra. |
| P12 | Mandato del consumidor | Transacción | ⛔ | La autorización con límites. Territorio de Pepe. |
| P13 | Recibo verificable | Transacción | ⛔ | El activo defendible: qué se ofreció, se acordó y se cobró. |
| P14 | Vínculo cliente-tienda | Transacción | ⛔ | Sin esto no existe el escenario de postventa. |
| P15 | Atención sobre producto | Servicio | ◐ | Cubierto en parte por el MCP de catálogo. |
| P16 | Postventa | Servicio | ⛔ | Estado, devoluciones y reclamos. Es la demanda que sí existe hoy. |
| P17 | Persistencia real | Plataforma | ◐ | Hoy Blob. ADR-0018 pospuso el esquema a propósito; P9–P14 lo van a exigir. |
| P18 | Métricas de distribución | Plataforma | ⛔ | Crawlers, citas y conexiones MCP: las tres que prueban la tesis. |
| P19 | Metering y billing | Plataforma | ⛔ | La tabla de precios de la landing no tiene nada detrás. |
| P20 | CI/CD | Plataforma | ⛔ | Hallazgo H3. |
| P21 | Pruebas | Plataforma | ⛔ | Hallazgo H2. |
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.
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.
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.
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.
| Qué | Estrategia | Cómo |
|---|---|---|
| Motor de análisis y gemelo | Retain | Funciona y está documentado. No se toca salvo para agregarle pruebas. |
| Nueve funciones | Replatform | Hecho: adaptador en vez de reescritura. 900 líneas probadas quedaron intactas. |
| Persistencia (Blob → esquema) | Refactor | Branch by Abstraction: almacen.ts ya es una interfaz de tres funciones, pensada para esto. |
| Superficies del gemelo | Retain + extender | Strangler Fig: /apps/agentroom nace al lado de /apps/vado, que se sirve para siempre. |
| Pagos | Repurchase | Commodity. Se integra, no se construye — y no custodiar evita el perímetro regulado. |