El CustomerRoom se dibuja entero, y con datos de verdad cambian los requerimientos

Maqueta navegable en agentroom.io/panel/muestra —noindex y rotulada—, con el mismo componente y los mismos tokens del sitio. Se llenó con el informe real de www.junngla.com, corrido ese día con el motor 2.2.0 y sondas: 23 páginas, 48 de 100 sobre los 16 puntos aplicables, y cero de cinco asistentes. Los requerimientos quedaron anotados en CustomerRoom.

La idea que ordena el panel: no es el informe con login. El informe contesta «cómo estoy»; el panel contesta «qué me falta y qué hago ahora». De ahí sale que cada brecha lleve dueño y que cada bloque termine en una acción o en el motivo de que no haya ninguna. Y se navega con el mismo mapa de dos capas que explica el producto: etapas arriba, herramientas al lado.

Dibujarlo con datos reales corrigió tres cosas que con una tienda inventada calzaban. No hay histórico contra qué comparar el puntaje, así que dice «Primer informe» en vez de un +0; no hay registro de lecturas, así que ese bloque queda vacío explicando por qué; y las brechas muestran la severidad que trae el motor y no un «+8 de puntaje» que el motor nunca calculó. Una maqueta con datos de relleno habría validado un panel que no funciona.

Apareció una promesa sin respaldo: la landing dice que las brechas que solo puede cerrar el cliente «te las decimos con la instrucción exacta», y el motor no emite ninguna instrucción —tiene que_significa y arregla, ninguno dice qué hacer—. Se escribieron a mano las nueve que fallan en junngla.com y las otras diecisiete muestran el hueco. El requerimiento correcto es un campo en el check.

Y dos errores propios, encontrados por el motor y por el reloj. Se daba llms.txt por presente en junngla.com porque responde 200: devuelve el HTML de la portada —el sitio trata la ruta como segmento de idioma—, o sea que comprobar por código de respuesta da falso positivo. Y la fecha de la corrida se mostraba un día antes: new Date("2026-09-04") es medianoche UTC, que en Chile es el día anterior. Una fecha ISO sin hora es un día, no un instante, y habría envejecido mal justo en el dato que ahora va destacado.

Entran dos colores de estado —verde listo y rojo falla— como tokens en los tres temas, solo dentro del CustomerRoom. En la web pública el estado se sigue diciendo con peso, opacidad y borde, porque ahí ámbar y azul ya significan lados de una conversación. El panel es privado y un informe de 26 puntos se recorre salteado: es el caso donde el color hace el trabajo.

Colaborar se adelanta a Operar: la escalera cambia de orden en el tramo de pago

Colaborar · A2ARoom pasa a ser la 05 y Operar · TrxRoom la 06. El tramo gratis no se toca —Ver, Existir y Catálogo siguen 01, 02 y 03— y la frontera del cobro tampoco: sigue en 04, Responder. Lo que se invierte es el orden de las dos últimas.

Por qué importa el orden y no es cosmético. La escalera no es una lista de funcionalidades: es lo que le decimos a un cliente que viene después de lo que ya tiene. Con Operar en la 05, el paso siguiente a que tu agente conteste era que tu agente cobre —lo que exige medios de pago, compromiso de stock y precio, y disputas—. Con Colaborar en la 05, el paso siguiente es que tu agente hable con el agente de otra organización, que no mueve dinero y no necesita nada de eso. Es el escalón más corto de los dos, y transaccionar queda al final, que es donde está el riesgo.

Qué se corrigió y qué no. Se reordenó todo lo que afirma el estado actual: el eje del mapa, las columnas (Agent Exchange se corre a la 05 y el hueco «sin solución» a la 06, que sigue siendo Operar), la ficha de Agent Exchange, la tabla de las seis etapas y la equivalencia del embudo viejo. No se tocaron las entradas de bitácora anteriores: la del 25-ago dice «Operar es 05 y Colaborar 06» y así se queda, porque era cierto ese día. Esta entrada es la que manda.

Ojo con lo que quedó fuera. Ninguna de las 42 piezas cambia de dueño ni de estado: A2ARoom sigue en 0 de 6 y TrxRoom en 2 de 8. Adelantar Colaborar en el relato no la adelanta en el catastro, y conviene no confundir las dos cosas: hoy la etapa 05 es la que menos código tiene.

El BBP se reestructura en tres niveles, y lo que se ordena no es la web: es qué se vende

Hasta hoy el BBP estaba organizado por etapas —una sección por ARAIS, ARTwin, TalkRoom, TrxRoom—, y eso hacía creer que cada etapa era un módulo de software por construir. No lo es. Las etapas son el recorrido, no piezas. Desde esta versión hay tres capas separadas y no se mezclan: las seis etapas son nomenclatura del journey; las diez soluciones son lo que se construye y se vende; las 42 piezas P## son lo único que un desarrollador toma.

Soluciones pasa a ser su propio grupo, con El mapa como entrada: las diez como bloques que abarcan las etapas donde operan. Cada una trae cuatro cosas en el mismo orden —qué hace, requerimiento técnico para construirla, consumo en tokens y un tablero de avance por subfuncionalidad—. Son 66 subfuncionalidades con 112 semáforos: es la primera vez que el estado de avance no se cuenta por módulo sino por lo que efectivamente falta hacer.

Pricing se reescribió en torno al token: primero cuánto vale uno, después cómo se consume en cada solución. Las gratis muestran cero, que es la forma más corta de decir dónde empieza a facturar el producto.

Se eliminó la sección Inicio. Su escalera ya vivía en el mapa y su glosario, en el diccionario; lo que no estaba repetido —el problema que resuelve, qué es en una línea y las tres industrias— quedó al pie del mapa. Borrar una sección no puede significar perder lo que decía.

Diccionario ahora es exhaustivo: 71 términos en siete familias —actores, etapas, nombres propios, análisis, publicación, cowork, códigos—, más las diez soluciones y una tabla de lo que ya no se dice. Cada entrada marca si es pública o interna, que es la distinción que faltaba: no hay términos secretos, hay términos que no significan nada para un cliente. Solo entra lo que no existe fuera de AgentRoom: JSON-LD y MCP no son nuestros y no se definen acá.

Los ids de sección cambiaron, así que un enlace viejo del tipo /#bitacora o /#arais apuntaba a nada. Se agregó un mapa de alias en el propio HTML que los redirige al destino nuevo. El costo de reordenar lo paga quien reordena, no quien guardó el enlace.

Riesgo que se corrió y conviene dejar escrito: la maqueta tenía marcadores vacíos donde el BBP real tenía la bitácora, los dos backlogs, el embudo y la arquitectura —casi 156 KB—. Publicarla tal cual habría borrado todo el registro histórico de un solo cp. Se rescató sección por sección desde el archivo en disco antes de reemplazar, con respaldo previo. Una maqueta se juzga por lo que muestra; un reemplazo, por lo que no destruye.

Un mapa de los seis componentes y las diez soluciones — y lo que muestra

Nueva sección Overview en Técnico: el sistema en una pantalla. Los seis componentes de la escalera en columnas, y cada solución puesta donde efectivamente opera. Cuatro no caben en una columna porque cruzan varias, así que van en bandas con su rango: Identity, Reputation y Certification desde la 03; Policy Engine y Trust & Audit desde la 04.

Puesto todo junto aparece algo que en las secciones separadas no se ve: las dos únicas soluciones vendibles están en la misma columna, la 01, que es donde no se cobra. Todo lo verde vive en el tramo gratis y todo lo que factura está en rojo. El producto tiene su parte terminada exactamente donde no gana plata.

Y una dependencia que el mapa vuelve obvia: tres de las cinco transversales —Reputation, Certification y Trust & Audit— dependen de Agent Identity, que hoy es AR-16. Es una sola pieza que no existe sosteniendo tres soluciones ya publicadas. También queda escrita la restricción que el mapa hace cumplir: auditoría y controlador nunca cuelgan de Ver ni de Existir, porque antes de que exista una sala no hay interacción que gobernar ni que registrar.

Fe de erratas de fechas. Esta sesión lleva días abierta y las últimas entradas se fecharon por inercia. Corregidas contra los commits: el rediseño de las diez soluciones fue el 30-ago y el ARDoor el 31-ago, no el 27. Las de 23 a 26 pueden tener el mismo corrimiento y no hay commit que las fije. En una bitácora la fecha es la mitad del contenido, y la única defensa es fecharla contra algo externo —un commit, un archivo— y no contra lo que uno recuerda.

ARDoor: el sello que invierte el CAPTCHA

Nombre nuevo de Francisco. El ARDoor es la cara visible del ARTag, no una pieza aparte: un solo acto de activación con dos manifestaciones —el archivo que lee el agente por servidor, y el sello que ve la persona—. Dice «Soy un agente» donde el CAPTCHA decía «No soy un robot», y lo marca la máquina en vez del humano.

El argumento, textual de Francisco: «el CAPTCHA protege excluyendo; el ARDoor protege gobernando». Invitar agentes a entrar solo es sensato si sabes quién entra (P24), si solo pueden hacer lo autorizado (P34, P37) y si queda constancia (P36). O sea que el sello no es decoración: es la promesa cuyo respaldo son las tres piezas que faltan.

Y resuelve un problema de venta que el ARTag tenía solo: pedirle a un comercio que instale algo que nadie ve es difícil. Con sello obtiene además una insignia de «listo para agentes». Cierra también la analogía del cowork: el comercio tiene su ARDoor; AgentRoom tiene su ARDoorMan en el counter.

El matiz que hay que decir en voz alta: un agente por servidor no hace clic en botones. Si esto se vende como «un botón que los agentes presionan», la mayoría nunca lo presiona y quien revise se da cuenta. El sello es para humanos y para agentes con navegador; lo que realmente encamina es la declaración. Quedó escrito así en la norma y en la ficha.

Y desbloquea una colisión que venía durmiendo: «puerta» ya significaba otra cosa —las Puertas A/B/C/D del código—, y era AR-15, deuda de prolijidad. Con ARDoor pasa a ser un choque con fecha: en cuanto se publique, la misma palabra va a nombrar el sello del cliente y el modo de servir el ARTwin. Se resuelven juntas o no se resuelve ninguna.

Nota que vale por el contraste: esta vez el nombre llegó a la norma antes que a producción —está en la maqueta, no en el repo ni en la web—. Es lo contrario de lo que pasó ayer con Agent Reputation y Agent Certification, y de lo que pasó con el «gratis» del counter.

La web ordena la oferta en diez soluciones, y el backlog se entera después

El rediseño dejó diez soluciones con página propia, todas en vivo: AI Radar, Agent Score, AI Presence, Agent Registry, Agent Identity, Policy Engine, Trust & Audit, Agent Reputation, Agent Certification y Agent Exchange. Cada sección de Técnico lleva ahora, arriba de todo, cuál es la solución que vende lo que ahí se describe, y el BacklogTI tiene la tabla puente completa: qué pieza construye cada una.

Solo dos de las diez son vendibles hoy —las dos del ARAIS—. Las otras ocho describen algo que no existe, en distintos grados: AI Presence está a medias, las seis restantes en cero.

Y dos se publicaron sin pieza que las construyera. Agent Reputation y Agent Certification entran al catastro recién hoy como P41 y P42, después de que su página estuviera publicada. Es el mismo patrón del «gratis» del counter (AR-19): primero se dijo, después se decidió. Las diez páginas ordenan bien la oferta —el problema no es el diseño—, pero conviene que el backlog se entere antes que la web.

Las dos nuevas traen preguntas que no son de ingeniería. Una reputación sin identidad verificada no es reputación, es un promedio de anónimos, así que P41 depende de P24; y hay que definir quién la escribe, porque si la escribimos nosotros somos juez. Y certificar es afirmar algo sobre otro: antes de construir P42 hay que decidir quién responde si un agente certificado se porta mal.

AR-17 quedó resuelto a medias: Trust & Audit y Policy Engine son nombres comerciales, y la norma exige un par. Si no se fija el técnico, el código va a inventar el suyo.

El ARU pasa a llamarse token

Decisión de Francisco. La unidad de cobro deja de ser ARU y pasa a ser token: minúscula, plural normal, sin reglas de sigla. El cambio se aplicó en el BBP (41 ocurrencias), en la norma y sus copias, en el CLAUDE.md del repo, en la skill y en la web —pricing.ts centraliza el rótulo, así que casi todo salió de ahí—. Verificado: cero ARU en agentroom.io y en bbp.agentroom.io, y el agent-card lo declara deprecado.

Deja dos cosas abiertas. AR-22: token ahora significa tres cosas —la unidad de cobro, los tokens de los modelos y el token de acceso—, y la colisión visible es de pantallas contiguas: el onboarding entrega «tu token» como credencial y dos pantallas después se cobra «por tokens» como dinero. Hay una peor y es externa: en un producto de IA token ya significa unidad de texto de un modelo para todo el mundo, así que «cobramos por tokens» va a leerse como que facturamos consumo de LLM. Eso no se arregla renombrando nada nuestro.

Ampliado al verificarlo: el costo en tokens de modelo viaja en el JSON del informe pero no se renderiza —la ambigüedad con la industria es real y la interna todavía no llega al cliente, aunque se vuelve visible si alguien expone ese campo—. La que sí ve el cliente es la credencial. Y quedó anotado el precedente de la categoría: «créditos» resuelve las tres colisiones de una vez. La familiaridad que hace atractiva a «token» es la misma que la vuelve engañosa.

AR-23: los identificadores TypeScript siguen en ARU a propósito —Francisco lo derivó al squad—. Copy en tokens, código en ARU: estado intermedio consciente, no descuido.

Y un detalle de método que vale guardar: el reemplazo automático dejó cinco frases mal, y la peor metió token en la lista de deprecados del agent-card —declarando obsoleto justo el término que se acababa de adoptar—. Se revisaron una por una en el diff. Un sed no distingue cuando un texto habla de la palabra en vez de usarla, y en un documento de nomenclatura la mitad de las apariciones son del primer tipo.

El informe entrega 22/16: aritmética rota en lo que se le da al cliente

Lo que el BBP anotó ayer como un rótulo desactualizado resulta ser peor. Sobre 279 informes generados, 92 —un tercio— muestran un numerador mayor que el denominador, y el peor caso dice 22/16. Reproducido acá contra los informes en disco. motor/render.ts:288 imprimía {evaluados}/16 [corregido el 26-ago en d8e7420; verificado el 2-sep-2026, ver bitácora] mientras el análisis mide 26, y el correo manda el total correcto: los dos se contradicen. Rompe I5 justo donde el producto promete que el puntaje siempre va con denominador.

Corregido al verificarlo: no hay que regenerar nada. Los 279 informes no tienen el 16 guardado —271 llevan total: 26, ocho llevan 24, ninguno 16—. El literal vive solo en el render, al lado del dato bueno, así que cambiarlo por inf.puntaje.total arregla todo lo ya entregado. La disyuntiva que este mismo BBP planteó hace un rato —regenerar o corregir al vuelo— se disuelve. «Un tercio de lo entregado quedó mal» y «un tercio se arregla con una línea» son dos noticias muy distintas para quien prioriza.

Y los ocho informes de 24 revelan lo de fondo: el denominador varía legítimamente entre versiones del motor, o sea que el literal estaba mal desde que se escribió, no desde que el análisis creció. Por eso la prueba correcta no es «numerador ≤ denominador» —un 26 fijo la pasaría y seguiría mintiendo en los de 24— sino denominador impreso idéntico a puntaje.total.

Y los dos blobs públicos resultaron ser dos riesgos distintos, no uno. Publicarlos juntos habría sobredimensionado el menor y escondido el grave:

AR-20 — el ARTwin se puede calcular. Su id es sha1(dominio|construido_en) a 12 hex, y quien dispara el análisis conoce las dos entradas. Acá la defensa no puede ser que la URL no se adivina, porque se calcula.

AR-21 — el informe no se puede revocar. Su id es randomUUID(), 122 bits, no derivable de nada: eso es una capability URL, patrón legítimo. El problema es que se guarda con caché de un año, se sirve con s-maxage=3600, y no hay un solo del() en el repo. La defensa sí es que no se adivina, y sería suficiente si se pudiera revocar. Un enlace filtrado queda filtrado para siempre.

La distinción es del squad y es la que hace defendible el hallazgo. Vale como método: dos cosas que comparten la causa técnica —blob público— no comparten el riesgo, y juntarlas en una ficha habría llevado a priorizar mal.

El squad auditó el documento de requerimientos, y tenía razón

La corrección que más urgía: el BBP publicaba «Cobertura de pruebas 0%» de cara a terceros. Es falso. Corrí npm test y pasan cuatro suites: sondas prueba resumir() directo, invariantes recorre 25 capturas reales, más acceso y costo. La cifra honesta es «cuatro suites, sin gate»: lo que falta no son pruebas, es que nadie está obligado a correrlas —una prueba que no bloquea un merge es documentación—.

Verificando sus hallazgos aparecieron dos que nadie había visto completos. El ARTwin y también el informe se guardan como blobs públicos con addRandomSuffix: false, y el nombre del ARTwin se deriva de dominio|construido_en, datos que conoce quien disparó el análisis. Contradice I7 justo donde el modelo promete lo contrario. El reporte apuntaba al handler; el handler exige tenant y está bien —la vía es el blob—. Es AR-20.

Y el «16» vive en tres superficies, no dos. La que faltaba es la peor: motor/render.ts:288 imprimía {evaluados}/16 [corregido el 26-ago en d8e7420; verificado el 2-sep-2026, ver bitácora] en el informe que se le entrega al cliente, mientras el correo manda el total correcto. Los dos se contradicen, y rompe I5.

Tres correcciones más que acepté: RQ-CR-1 decía que no dependía de nada —depende de P22, y es barato porque P22 ya está escrito—; D-01 daba un número de vulnerabilidades que se mueve solo, así que ahora va con fecha al lado; y dos de los cinco modelos por defecto de las sondas tienen problema antes de encenderse —grok-3 salió del catálogo de xAI y sonar se soporta hasta el 27-sep-2026—.

La escalera crece a seis: entra Catálogo, y es gratis

Commit 85c1a56. ARDoorMan dejó de ser solo el counter y pasó a ser una etapa propia: la 03, Catálogo, entre Existir y Responder. Su promesa es «te ofrecen cuando alguien pregunta»: un asistente llega buscando un problema, no tu marca, y la recepción responde quién puede atenderlo, en el orden en que llegaste.

Y es gratis, lo que mueve la frontera del cobro: la tarifa ya no empieza en la 03 sino en la 04. Todo texto que diga «empieza en Responder» sigue valiendo; el que diga «en el nivel 03» quedó falso. Las etapas de más arriba se corrieron: Operar es 05 y Colaborar 06.

Con eso ARDoorMan sale de cero. Está parcial, no en construcción, porque una parte sí existe: el endpoint MCP permite que un asistente pregunte qué tienes y en qué condiciones. Lo que falta es el counter conversacional —y la distinción es la etapa entera: hoy el asistente puede consultar a un comercio, pero solo si ya sabe a cuál preguntarle. Descubrir quién puede atenderlo es justo lo que no existe. Su recorrido quedó en 1 de 7, con el corte en el paso 02.

Un efecto lateral que ordena TalkRoom: sus dos pasos que funcionaban —encontrar y leer el catálogo— pertenecen ahora a Catálogo, que es gratis. Se dejan en su recorrido porque sin ellos no se entiende, pero marcados: de TalkRoom, que es la primera etapa que cobra, no hay nada construido.

Y AR-19 se cierra de una forma que conviene recordar: el «gratis» que el 24-ago era una deducción publicada sin decidir, el 25-ago quedó formalizado en el código como precio de la etapa 03. Salió bien —la etapa gratis es buena idea—, pero el camino fue al revés: primero se dijo, después se decidió.

Revisión de estado: el análisis dejó de botar el ARTwin

Se auditaron los siete recorridos de Técnico contra el código y la web en vivo. P22 está construida y se cierra: analizar.ts arma el ARTwin desde la misma captura, deja el gemelo_id en el informe y lo guarda, con el fallo aislado —si el gemelo no se puede construir, el informe se entrega igual—. Se implementó tal cual el requerimiento, y el código lleva escrita la regla que importa: «guardar no es publicar: sin tenant activo nada de esto se sirve». ARAIS sube a 9 de 11 y le queda un solo hueco, el 11: nunca vuelve a medir.

En CustomerRoom apareció media cuenta que no estaba anotada. motor/cuentas.ts y motor/sesion.ts existen: la sesión vive en cookies firmadas con HMAC y sin base de datos, y la cuenta es la dirección de correo verificada. Alcanza para entrar y ver lo tuyo, no para P1 —la cuenta de la organización, la que respondería de quién es el ARTwin—. Y motor/google.ts implementa OpenID pidiendo solo openid email, pero /entrar no lo ofrece: escrito y no expuesto.

Lo demás sigue igual, y ahora está verificado uno por uno: no existe ARTag, ni counter, ni apertura de sala, ni handshake, ni minuta, ni registro de demanda no servida, ni verificación en vivo, ni reserva, ni orden, ni metering. ARDoorMan 0/6 y A2ARoom 0/6 no tienen una sola línea.

Nota de método, porque casi se cuela: el primer barrido se hizo con una función que respondía sí/no, y falló en las dos direcciones —dio «no» a guardarGemelo, que sí existía, y «sí» a sala, minuta y handshake, que no—: las palabras aparecían en comentarios. Se rehizo pidiendo la línea como evidencia en vez de un booleano. Un barrido que solo dice sí o no no se puede auditar, y esta revisión existía justamente para auditar.

Se acabó el 0% de cobertura, y el requerimiento de las sondas destapó un bug de plata

npm test corre y pasa. Cuatro suites —costo, sondas, acceso, invariantes—, verificadas hoy junto con npm run typecheck. P21 pasa de no existe a a medias, y con eso cae el argumento que bloqueaba el plan entero: la auditoría decía que nada se podía construir con seguridad sin la red de pruebas. Lo cubierto son las piezas que deciden —la agregación de las Sondas, el contador de costo, el acceso, y las invariantes sobre 25 capturas reales de 279—; lo que falta es la prueba de cada uno de los 26 puntos, que era el hallazgo original.

Y al escribir P23 apareció un bug que costaba plata. TARIFA solo conocía los modelos de Anthropic y Gemini; los adaptadores de Perplexity (sonar), ChatGPT (gpt-4.1) y Grok (grok-3) llamaban al contador con modelos que la tabla no tenía, caían a {entrada: 0, salida: 0} y sumaban USD 0,00. Las llamadas y los tokens sí se contaban; el dinero no. Lo mejor del hallazgo es cuándo se habría manifestado: exactamente al encender el segundo asistente. Un requerimiento que se escribió para pedir credenciales terminó encontrando el bug que esas credenciales iban a destapar (86b3828).

Un cruce entre la web en vivo y este documento sumó siete piezas más (P41–P47). La más seria es P41: el techo de gasto se promete, se describe y no lo hace cumplir ninguna pieza. P19 y P38 miden; ninguna corta. Y se vende con «pagar por uso solo funciona si el límite es tuyo»: sin corte es un medidor sin llave de paso. También apareció AR-18, que no es una brecha sino una contradicción entre dos documentos nuestros: la landing publica «prueba que actúa por tu cliente» como paso del recorrido, y el backlog dice de esa pieza que quizá no se construya nunca acá.

El catastro va en 49 piezas. Eran 21 el 20-ago. Ninguna de las 26 nuevas apareció escribiendo código: salieron de definir los modelos y de comparar lo publicado contra lo anotado. La web va por delante del backlog, y la distancia crece cada vez que se publica.

AgentRoom es un cowork: counter, salas y minuta

Francisco cerró el modelo del recorrido del asistente. AgentRoom es una oficina tipo cowork: un counter con recepcionista —ARDoorMan, nombre nuevo—, salas que se arriendan por rato (TalkRoom, TrxRoom, A2ARoom), alguien que levanta la minuta y un controlador de marco que cuida que la reunión no se salga de lo acordado. El recorrido son cuatro actos: llega y se autentica → counter → sala → se va y queda la minuta.

Cuatro reglas que son requisitos, no adorno: nadie entra anónimo; el orden lo da la antigüedad y el primer lugar no se vende; las salas son ciegas entre sí; y el contador de token parte al abrir la sala, porque el counter es gratis. La segunda es la que separa a AgentRoom de un directorio pagado: vender el orden convertiría la recomendación en publicidad, y con eso se cae la tesis entera.

El catastro pasó de 21 a 40 piezas en cuatro días sin escribir una línea de código: diecisiete entraron con este modelo (P24–P40), dos venían del modelo comercial. No es que el producto haya crecido: es que recién ahora está escrito lo que siempre faltó. De todas ellas la que más vale por su tamaño es P29, el registro de demanda no servida: no es una métrica sino el motor de adquisición —«treinta y siete asistentes preguntaron por esto y no había nadie» es el argumento para ir a buscar al comercio—, y es la única pieza que funciona con cero adheridos: mientras menos haya, más señal produce.

Y una contradicción en producción, verificada en vivo: el MCP responde tools/call sin credencial mientras el modelo declara que nadie entra anónimo. No es una fuga —el corte por tenant funciona y un dominio sin servicio activo no entrega nada—, es ausencia de identidad de la contraparte, y eso vacía la auditoría antes de construirla: una constancia de que «alguien» preguntó no sirve en una disputa, que es para lo que se vende. Es AR-16, en Bloquea. Quedan dos piezas sin bautizar —la auditoría y el controlador— en AR-17.

Aparte: se decidió que en las sondas el detalle informa y el agregado puntúa —el comercio ve en qué asistente aparece, sin que se convierta en un score por chat—, y la nomenclatura quedó versionada en el repo (0a538c4) después de días publicada sin commitear.

Las sondas: no falta cobertura, está roto el veredicto

Al escribir el requerimiento del paso 07 apareció que el problema es peor y más barato de arreglar de lo que decía el BBP. veredicto() da falla con cero y aprueba con mayoría estricta, así que con un solo asistente el estado «parcial» no existe: 0/1 falla, 1/1 aprueba. No hay punto medio.

Eso son 10 puntos de peso decididos de forma binaria por un modelo, una vez —S23 pesa 4, S24 y S25 pesan 3—. Un «falla» se le entrega al comercio como no apareces cuando preguntan por lo que haces, cuando lo que ocurrió fue no apareciste en Gemini, en esa corrida. Y la respuesta de un asistente ya demostró ser inestable entre corridas: es la razón por la que la posición dejó de puntuar. Con una sola credencial, esa inestabilidad salta de aprueba a falla sin escala.

S26 es el único que se protege: exige MINIMO_PARA_COMPARAR = 2 y sale no_evaluado declarando el motivo. Los otros tres no tienen esa guarda. Y no hace falta tocar veredicto(): con dos asistentes la regla ya funciona bien, el problema desaparece solo al encender el segundo.

Queda como P23, y es la única pieza del backlog que se destraba con una decisión administrativa y no con código: cuatro credenciales. Los cinco adaptadores están escritos y se activan solos al encontrar su variable. Requerimiento en 05-Notas/req-sondas-multiasistente.md, con un riesgo que conviene decidir antes: los puntajes ya publicados en el Radar se midieron con un asistente y al pasar a cinco dejan de ser comparables —o se recorre el Radar de nuevo, o se marca la fecha de corte—.

Nace el ARTag, y con él la frontera entre lo nuestro y lo suyo

La contraprestación del ARTwin gratis ya tiene nombre: ARTag, la señal que el comercio deja en su web para activar su ARTwin. Y con ella quedó definida una regla que faltaba: el ARTwin se le avisa, no se le entrega. Lo construimos con una captura que pagamos nosotros, así que antes del ARTag es nuestro activo —el comercio sabe que existe, ve cuántos productos y políticas trae, y no puede llevárselo—. Después del ARTag es suyo y se publica. Sin ARTag el ARTwin existe pero no se sirve, que es lo que hace que activar signifique algo.

El orden del flujo importa y quedó fijado: avisar → ofrecer → revisar y completar → entregar el ARTag → instalar → verificar con un botón que sondea su dominio → publicar → recalcular el ARAIS. Revisar viene antes de recibir el ARTag, no después: así nadie publica dato inferido sin haberlo mirado —y en el 95% de los sitios el precio sale de heurística—, y el comercio llega a instalar habiendo invertido trabajo en su propio ARTwin. Invertir ese orden convierte la revisión en un trámite que se salta.

Una salvaguarda escrita en la norma, en mayúsculas: el ARTag es un archivo, no un script. El nombre evoca el Google Tag y el Meta Pixel, y ese es justamente el riesgo: un agente no ejecuta JavaScript —nuestro propio motor tampoco, y L04 mide exactamente eso—, así que implementarlo como snippet entregaría un ARTwin que nuestro análisis declara invisible. Es un estático en /.well-known/agentroom.json. Los recorridos de ARTwin (16 pasos) y CustomerRoom (16) se rehicieron con este flujo.

Los recorridos se rehacen contra el modelo comercial

Los journeys se habían escrito antes de que Francisco cerrara el modelo, así que describían el sistema y no el recorrido del cliente. Tres cambiaron.

ARAIS pasa de 9 a 10 pasos: se sumó el 04, armar el borrador del ARTwin desde la misma captura, y entra en rojo. Esa sección decía «hasta acá está en producción, es la única etapa completa»; ya no lo es. Su único hueco es botar algo que ya está pagado.

ARTwin pasa de 11 a 15: se le insertó entera la adhesión —vista previa, revisar lo inferido, subir el archivo, verificar el dominio— más el paso 10, recalcularle el ARAIS, que es el que cierra la venta, y el 15, el cobro a los tres meses. Su corte se movió del 07 al 04: el problema ya no es que nadie sea dueño de lo publicado, es que el ARTwin se construye y nadie se lo muestra al dueño.

CustomerRoom pasa de 10 a 13, con el mismo tramo visto desde el cliente, y su corte baja del 06 al 05. La frase que queda es la que resume el estado del producto: le muestra al comercio su problema y le esconde el remedio que ya tenemos armado.

TalkRoom, TrxRoom y A2ARoom no se tocaron: el modelo comercial no cambia lo que les falta, solo confirma que su tarifa sigue en TBD.

El modelo comercial queda cerrado, y el ARTwin resulta ser un subproducto

Decidido por Francisco: el ARAIS es gratis siempre, el ARTwin gratis por 3 meses y después token, y la contraprestación del tramo gratis es que el comercio ponga algo en su sitio, «tras bambalinas, como el pixel de Meta o el tag de Google». Eso precisa AR-03, que hasta hoy decía «a cambio de acciones» sin que nadie supiera cuáles.

El hallazgo que cambia cómo se lee el modelo: construirGemelo() es una función pura sobre la misma captura del ARAIS —no necesita app, API ni credenciales—. Cada análisis gratis ya produce todo lo necesario para armar el ARTwin, y hoy se desecha. Los tres meses gratis no cuestan una construcción: cuestan dejar de botar lo que ya se hizo.

Y una advertencia con número: solo 13 de 237 sitios —un 5%— tiene catálogo por API o feed. En el resto el precio sale de heurística, así que publicar ARTwins gratis a escala sería publicar poco o publicar inferido bajo el nombre de otro. publicable() ya lo impide, pero la tensión comercial queda: el producto que se regala es justo el que menos dato verificado tiene.

A quién conviene armarle uno, con números. De los 42 sitios con puntaje bajo 35 —conjunto distinto de los 42 sin puntaje, sin un dominio en común—, 23 son legibles y solo declaran mal: el mejor caso comercial, número feo y remedio en la misma pantalla. 16 tienen páginas que piden navegador —pero L04 no es binario: mide cuántas páginas de cuántas, y sobre 40% marca falla—, así que en realidad son 5 graves, a los que corresponde diagnóstico y no ARTwin, y 11 leves con una o dos páginas sueltas, a los que sí se les puede armar con menos cobertura. Y 3 se leen perfecto pero están cerrados con noindex —Utaru, BEXER e Inmediatos, los tres nuestros y los tres cerrados a propósito—: tienen contenido de sobra y ningún asistente los va a encontrar mientras esa línea siga puesta. Repone cae entre los leves, con 1 página de 8.

Ese cuadro se escribió mal dos veces, las dos por tratar como una sola cosa lo que el motor distingue: primero «ilegible» mezclando dos umbrales, después L04 leído como sí/no —lo que mandaba a diagnóstico a dieciséis cuando eran cinco, once conversaciones que sí se pueden tener—. Lo que lo destapó no fue volver a medir, sino discutir la palabra.

Recomendación técnica, aún no decidida: que la «acción» sea un archivo en /.well-known/agentroom.json y no un snippet de JavaScript —un agente no ejecuta JS, nuestro propio motor tampoco, y L04 mide exactamente eso: pedir un pixel sería entregar un ARTwin que nuestro producto declara invisible—. Se abrió además AR-15: las Puertas A/B/C/D no están en la norma y ya aparecen en este documento.

Cada bloque técnico muestra su recorrido y dónde se corta

Las seis secciones de Técnico tienen ahora una vista del recorrido completo, paso a paso, con el estado real de cada uno y una línea que marca dónde termina lo construido. En total 52 pasos, de los cuales funcionan 23.

Puestos uno al lado del otro, el producto se lee distinto: ARAIS 8 de 9 —la única etapa completa—, ARTwin 6 de 11, CustomerRoom 4 de 10, TalkRoom 3 de 8, TrxRoom 2 de 8 y A2ARoom 0 de 6. La escalera de la landing sugiere avance parejo; el recorrido muestra que lo construido se concentra en el tramo gratis y se desploma justo donde empieza el cobro.

Los cortes dicen más que los conteos. ARTwin publica bien pero nadie es dueño de lo publicado; TalkRoom responde sobre la oferta pero no sobre el cliente; TrxRoom sabe mostrar y no sabe comprometer; y CustomerRoom se entra a mirar, no a administrar —el paso 09, administrar hablando, es la tesis del producto y no existe—. Cuatro de los seis se cortan en el mismo punto: donde la relación dejaría de ser anónima.

El deploy publica el disco, no el commit — y por eso nadie veía lo mismo

AR-11 cerrado: agentroom.io/llms.txt dice veintiséis puntos y trae el bloque de vocabulario. Commit 9b3c98e.

Lo que quedó en el camino vale más que la corrección. Dos sesiones verificaron el mismo archivo en vivo y vieron cosas distintas —una «dieciséis», otra «veintiséis»—, y no era caché: vercel --prod despliega el working tree, no el HEAD de git, y el repo vive en Dropbox compartido por varias sesiones. Cada deploy publica lo que haya en disco en ese instante, incluidos los cambios sin commitear de otra sesión. El riesgo real resultó ser el inverso del que parecía: no faltaba desplegar el archivo —ya estaba publicado—, faltaba versionarlo, y un checkout limpio o un deploy desde CI habría devuelto «dieciséis» a los asistentes sin que nadie lo notara. Queda como AR-13: commitear antes de desplegar, y no dar por versionado lo que se ve en producción. Se cierra solo con CI (P20).

La advertencia sobre public-scores.ts se cumplió dentro de la misma hora. Una sesión editó el titular del Radar a mano y la siguiente corrida del generador lo borró. Se recuperó en 6f9bd69 y se adoptó ese titular —«Cómo se ve un continente entero en IA», que dice lo que hace la sección sin usar la sigla—, ahora sí en la plantilla del generador, que es lo único que sobrevive.

Precisión de crédito: el vocabulary del agent-card.json no existía antes; se agregó hoy en 769c4ee, junto con corregir un «veinticuatro puntos» que también arrastraba.

CustomerRoom deja de ser promesa, y el análisis muestra qué mide de verdad

P4 se construyó. /entrar y /panel están en producción desde el 22-ago: acceso con un código de cinco caracteres y el informe de los 26 puntos abierto capa por capa, con su evidencia. Google OAuth está escrito y espera credencial. La pieza pasa de no existe a a medias: lo que funciona es el tramo de mirar; el de administrar conversando —que es la tesis del producto— sigue sin empezar. Vale anotar cómo pasó: era la única de las 21 piezas sin fase asignada y se construyó igual, antes que piezas priorizadas. El plan quedó atrás de la construcción, no al revés.

Las Sondas ya tienen números, y uno de ellos obligó a una decisión. Sobre 70 dominios: S24 «te nombran» al 99%, S25 «citan tu sitio» al 89%, y la posición en la lista al 70%. La posición se informa pero dejó de puntuar: varía demasiado entre corridas y no es una propiedad del sitio sino del asistente que contestó. Sigue habiendo una sola credencial —Gemini—; los adaptadores de Perplexity, Claude, OpenAI y Grok están escritos y nunca se ejecutaron, así que S26 no se puede evaluar de verdad todavía.

Dos cosas de operación. src/data/public-scores.ts se genera: el motor lo reescribe entero en cada corrida —cuatro esta semana—, así que el copy del radar se cambia en la plantilla del generador y toda edición manual se pierde. Y agentroom.io/bbp sigue sirviendo el BBP heredado, titulado «Vado · BBP», en el dominio de la marca nueva (AR-12).

Se homologa el lenguaje: un nombre comercial y uno técnico

Cada etapa queda con dos nombres y ninguno más: Ver · ARAIS, Existir · ARTwin, Responder · TalkRoom, Operar · TrxRoom y Colaborar · A2ARoom, más dos transversales: CustomerRoom —el panel donde la organización administra su agente, no el comprador— y token, token, la unidad de cobro por uso. La regla de uso: en la web y los portales van los dos —el comercial en titulares y botones, el técnico junto a él en la primera mención de cada sección, para que el usuario se familiarice—; en código, API, MCP, IDs y documentación técnica, solo el técnico.

La norma es un archivo, no un acuerdo verbal: 03-Documentos/NOMENCLATURA.md, con copia en el repo (01-agentroom-web/NOMENCLATURA.md) y resumen en su CLAUDE.md. Trae la tabla, las reglas de presentación, el glosario, la lista de deprecados y un bloque de prompt listo para pegarle a cualquier sesión o persona que escriba código o copy. Se dan de baja AgentRoom-AIScore, gemelo digital, «Agent Room Manager» y token separado.

Dos cosas que aparecieron al fijarlo. La etapa 05 no tenía sección propia: ahora existe A2ARoom, y al escribirla quedó a la vista que ninguna de las 21 piezas del catastro le corresponde —las cuatro fases cubren de Ver a Operar, y Colaborar parte de cero—. Y el renombre de gemelo a ARTwin en el motor no se hace todavía: atraviesa el código y hoy no hay cómo verificar que no rompió nada, así que espera a la red de pruebas (P21). Queda en AR-10. Tampoco se toca VadoBot/1.0 ni /apps/vado: hay comercios con ese agente en listas de permitidos y Puertas D desplegadas en esa ruta.

El BBP se reordena por bloques del sistema

El documento pasa de cuatro grupos a cinco y deja de estar ordenado por cómo se fue construyendo para estarlo por de qué parte del sistema habla. Overview queda en una sola sección, siguiendo a la landing (entrada siguiente): Inicio reúne la oferta de valor, el problema, las tres industrias y la escalera de cinco etapas. Técnico se abre en siete: ARAIS, Gemelo, TalkRoom, TrxRoom, CustomerRoom, Arquitectura general y BacklogTI. Y el modelo de negocios sale a su propio grupo, Pricing, porque estaba escondido como subtítulo de Overview. Comercial y Gestión no se tocaron.

Lo que apareció al reordenar importa más que el orden. El BBP decía 24 puntos en 3 capas cuando el motor ya va en v2.2.0 con 26 puntos en 4: se agregó Sondas (S23–S26), que en vez de mirar el marcado le pregunta de verdad a un asistente y mide si la organización aparece, y la numeración se corrió sin huecos (L01–L06 · T07–T14 · R15–R22). Tampoco figuraba el radar de LatAm: 203 organizaciones medidas de 372 en veinte países, publicadas sin que nadie pague por aparecer ni por salir. Las cifras viejas se corrigieron donde eran dato vivo y se dejaron intactas en la auditoría y en esta bitácora, que son fotos fechadas.

Deuda que abre este cambio: los cinco nombres técnicos son de este documento y de ninguna otra parte —en el código el puntaje es AgentRoom-AIScore y el panel es Agent Room Manager; TalkRoom, TrxRoom y CustomerRoom no existen en el repo ni en la landing—. Queda como AR-10, para decidirlo antes de que lleguen a material comercial.

Una sola oferta de valor: se fusionan «Cómo funciona» y «Las cinco etapas»

En la landing vivían como dos secciones separadas —«Cómo funciona» (los cuatro niveles por industria) y «Las cinco etapas» (Ver, Existir, Responder, Operar, Colaborar)—, pero eran la misma escalera contada dos veces. No son dos cosas: son la oferta de valor. Se fusionaron en una sola sección (#how-it-works): las cinco etapas como la escalera, cada una con su nivel de precio (Gratis / Gratis 3 meses / token), su estado real y sus ejemplos por industria, con la línea de tarifa marcando dónde deja de ser gratis. Stages.tsx quedó como la sección única y HowItWorks salió del Landing; el nav colapsó los dos ítems en uno. Este BBP también unió sus dos secciones equivalentes.

Se abre el seguimiento comercial

Nuevo grupo Comercial con dos secciones: El embudo, que mapea los cuatro niveles del producto a etapas de venta, y Acciones, el registro de a quién se contactó, qué pasó y qué sigue. Parte en cero a propósito: no hay nada anterior documentado y no se va a rellenar hacia atrás.

Lo que obligó a escribir el embudo antes que el registro: hoy se puede entregar hasta el nivel 02 y no se puede cobrar el 03. No es precio pendiente de comunicar —no hay número (AR-02) y los servicios que justifican el nivel no están construidos (AR-04)—, así que el cero de ventas es estructural, no comercial. Quedaron fijadas cinco reglas RC-1–RC-5; la más dura es RC-3: no se cotiza el nivel 03 mientras la tarifa sea TBD, ni con un rango, porque un número dicho en una reunión queda de ancla aunque después se publique otro.

Backlog técnico: las 21 piezas salen del informe y entran al BBP

El catastro de piezas vivía solo en el informe de arquitectura, y el backlog de Gestión lo resumía en una línea (AR-06). Ahora tiene sección propia en Técnico, ordenada por las fases del plan y con la misma columna que el resto del backlog: por qué sigue ahí. La división quedó explícita —Gestión decide, Técnico construye— y se sumaron D-01–D-03 para la deuda de los hallazgos que no es una pieza de producto.

Dos cosas que aparecieron al ordenarlo. P4, el Agent Room Manager, no está en ninguna de las cuatro fases pese a estar anunciado en la landing: hay que ubicarlo o sacarlo del copy. Y la Fase 0 sigue diciendo «los 16 checks» porque se escribió el 20-ago, un día antes de que el análisis creciera a 24 puntos en 3 capas; el alcance real de P21 es 24. La auditoría no se toca —es una foto fechada—, la corrección va anotada en el backlog.

Tercera capa del análisis: de 16 a 24 puntos

Se agregó Resolución a las dos capas originales. Las dos primeras solo sabían preguntarle a una tienda: a un banco, un ministerio o una universidad les aplicaban cuatro puntos de dieciséis. El instrumento estaba mal, no los sitios. El análisis quedó en 24 puntos, 3 capas.

Dominio propio y redefinición del producto

agentroom.io pasó a ser la dirección; agentroom.junngla.com redirige con 308 permanente sin apagarse. El producto se redefinió: no es solo para tiendas —comercio, servicios, software e instituciones—, y el amarillo señal pasó a vestir también el llamado principal.

Fusión con VADO

AgentRoom absorbió a VADO: un gemelo digital es un agente en AgentRoom. El repo pasó a ser uno solo —landing, motor, funciones y CLI—, copiado del de VADO. Los nueve handlers no se reescribieron: se adaptan con src/lib/handler-vercel.ts. Dos tsconfig para validar web y motor por separado. La mudanza es por configuración (motor/marca.ts), no por código. El repo original de VADO quedó intacto y sigue sirviendo vado.junngla.com; el cutover es una decisión aparte (AR-01).

Ese mismo día se corrió SuperArqDev sobre el commit inicial: score 68/100 (SQALE C), 0% de cobertura de pruebas y el catastro de las 21 piezas que faltan con su plan por fases. Ver la auditoría As-Is/To-Be.