En "Dónde atiende", el canal correo: el agente lee una casilla y responde solo
los correos que llegan, con su base de conocimiento, igual que atiende WhatsApp.
Como el correo no tiene webhook, se revisa por intervalo — y el intervalo lo
elige el cliente por canal (2 a 60 minutos): una inmobiliaria quiere 2, a un
estudio contable con 30 le sobra. El cron corre cada minuto pero cada casilla
se revisa solo cuando le toca, con un pool de 8 para que 100 casillas no salgan
a la red en el mismo instante.
Las guardas que separan "asistente" de "incidente", cada una con su test:
nunca responde correo automático ni se responde a sí mismo (el bucle con otro
autoresponder); la revisión se marca ANTES de conectar, así una contraseña
cambiada no martilla el login cada minuto hasta que el host del cliente nos
bloquea; y el correo se marca leído recién cuando la respuesta salió — si el
envío falla, queda sin leer y se reintenta.
En "Lo que sabe", las cuentas de correo: casillas que el agente consulta a
pedido — "revisame los correos de hoy y haceme un resumen" — sin nada de fondo.
Solo lectura en serio: Peek, INBOX en read-only, y un test que falla si alguien
le agrega un marcado. Ahora se pueden conectar varias por agente; con más de
una, el modelo pregunta cuál en vez de adivinar — resumirle a alguien la
casilla que no pidió no es un error menor. El alta pide correo y contraseña:
el host se deduce (mail.<dominio>) y el campo técnico aparece recién si eso
falla. Se prueba la conexión antes de guardar, con la persona mirando.
Enviar por una cuenta conectada está bloqueado a propósito: para responder
correos está el canal, con sus guardas. Una tool de envío sin límites es una
máquina de spam con el dominio del cliente.
La navegación acompaña: "Lo que sabe" agrupa Información, Cuentas de correo y
Herramientas — tres formas de saber, no tres pantallas sueltas — y Avanzado
queda solo con Problemas.
El SMTP se unificó en una sola implementación que comparten soporte y el canal:
el bug de STARTTLS que abría dos conexiones ya se pagó una vez.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Una fuente crawleada decía "9 fragmentos" y nada más. Las notas y archivos al
menos tienen Editar, que muestra su texto; un sitio no tiene nada — era una
caja negra, sin forma de saber si el crawler leyó los precios o el pie de
página. Y cuando el agente contesta mal, la primera pregunta es justamente
qué tiene cargado de verdad.
Cada fuente gana un "Ver" que abre sus fragmentos tal como quedaron indexados,
numerados y en orden, con la advertencia que importa: esto es exactamente lo
que el asistente puede consultar — si acá falta algo, eso mismo le va a faltar
en las respuestas.
El botón se apaga cuando la fuente no tiene fragmentos todavía (procesando o
con error): abrir un visor vacío no informa nada.
El endpoint pasa por accesoDocumento como todos los sub-recursos, y devuelve
solo el contenido — el embedding no viaja: son miles de números que no le
sirven a nadie en pantalla.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Dos mitades de la misma experiencia: el primer día y todos los días después.
El primer día. Un agente recién creado mostraba tres avisos ámbar sueltos —"no
atiende", "no sabe nada"— sin ningún orden: el dueño sabía que faltaban cosas
pero no cuál iba primero. Ahora hay una guía de tres pasos (contale de tu
negocio → hacele una pregunta → ponelo a atender) donde solo el siguiente paso
pendiente se resalta, porque una guía donde todo grita a la vez no guía nada.
Mientras falte algo, la guía reemplaza al estado — una sola voz por etapa; con
los pasos hechos desaparece para siempre y el estado operativo toma su lugar.
Todos los días. La bandeja de conversaciones mostraba el último mensaje de cada
sesión —casi siempre la respuesta del bot, "¡Hola! ¿En qué te ayudo?" cincuenta
veces— y el session_id crudo (tg:8812). Ahora cada conversación muestra lo que
el visitante preguntó al abrir, que es el dato que le importa al dueño: qué le
preguntan de verdad a su negocio. Con canal deducido del prefijo de la sesión
(WhatsApp, Telegram, Tu web, Prueba), cantidad de mensajes, y fecha relativa.
Las pruebas propias se separan detrás de un filtro: mezcladas inflan la lista y
el dueño no distingue cuáles son clientes reales. El contador del estado cuenta
solo las reales, por lo mismo — si arriba dice 4 y la lista muestra 3, el
número parece roto.
El hilo muestra la hora de cada mensaje, y el backend gana una consulta que
agrupa por sesión con el primer mensaje del visitante en vez de mandar filas
crudas; la vieja quedó sin usos y se fue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La pantalla estaba organizada por tabla de base de datos: siete pestañas que
eran nuestras siete entidades —documentos, herramientas, canales, conexiones,
eventos— y que se desbordaban a lo ancho. Un dueño de negocio nunca piensa "voy
a Conexiones": piensa "¿por qué contestó mal?" o "quiero que sepa mis precios
nuevos".
Tres cambios.
Un estado arriba que responde "¿está bien mi asistente?" sin un clic:
"Atendiendo en WhatsApp · Sabe de 2 cosas · 1 conversación", y en ámbar cuando
algo falta — "No está atendiendo en ningún lado", "Todavía no sabe nada de tu
negocio". Antes eso había que deducirlo entrando pestaña por pestaña. Cada
señal es un botón que lleva a donde se arregla, y si el destino está en
Avanzado, lo despliega.
Tres zonas en lugar de siete pestañas: Conversaciones, Lo que sabe, Dónde
atiende. Herramientas, Cuentas conectadas y Problemas pasan a "Avanzado",
plegado. No se sacan —hacen falta— pero dejan de competir todos los días con lo
que se mira todos los días.
Y el conocimiento con la prueba lado a lado. El bucle real es leer lo que sabe
→ probar → corregir → probar de nuevo; en dos pestañas separadas eso eran seis
clics por corrección. Desde 1024px van en dos columnas, con el chat fijo al
hacer scroll; abajo de eso se apilan, que es el orden en que igual se trabaja.
El vocabulario deja de ser el nuestro: "Base de conocimiento" es "Lo que sabe",
"Auditoría" es "Problemas", "Conexiones" es "Cuentas conectadas". Y la site_key
sale del encabezado: se usa una vez, al instalar el widget, y vive donde se
instala.
No se tocó ni el color ni la tipografía ni Umi. Esto es estructura, no pintura:
cambiando las dos cosas a la vez no se sabría cuál mejoró qué.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AgenteDetail tenía 1026 líneas con las siete pestañas adentro: el estado de
todas mezclado en un solo <script setup>, y cualquier cambio en una obligaba a
leer las otras seis para saber qué se rompía. Reorganizarla en ese estado sería
trabajar a ciegas.
Queda en 514 líneas —el encabezado, las pestañas y la carga de datos— más un
componente por zona: conocimiento sigue adentro por ahora, y salen auditoría,
conexiones, chat, conversaciones, herramientas y canales.
El padre sigue siendo dueño de los datos y cada pestaña emite "recargar" en vez
de tener su propia copia: con copias por pestaña, ir y volver entre dos mostraba
estados distintos de lo mismo.
Sin un solo cambio visible, y verificado como tal: se capturaron las siete
pestañas antes de empezar y se compararon píxel a píxel después de cada
extracción. Las siete dan idénticas — la única diferencia que reporta el
comparador está por debajo del umbral y cae exactamente sobre el punto que late
en una fuente "procesando", o sea la animación fotografiada en otro instante.
Este commit no cambia nada para el usuario. Es la base para poder reorganizar
la pantalla sin romperla.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
En la misma pantalla convivían dos lenguajes: emojis a color (🌙📊🧠✍️📄🌐🔁) y símbolos tipográficos monocromos (✎ ✕ ← ↻ ⚠ ⬇ ✓). Eso se lee como
descuido, y encima los emojis los dibuja el sistema operativo — el mismo panel
se ve distinto en Mac, en Windows y en Android, sin que podamos hacer nada.
Ahora hay un set propio de iconos SVG de trazo: mismo grosor de línea, misma
caja, y heredan currentColor, así que toman el color del texto que los rodea y
funcionan igual en tema claro y oscuro. Al lado uno de otro tienen el mismo
peso visual, que es lo que hacía falta.
El emoji suelto de la pantalla de inicio pasa a ser Umi, que ya es el personaje
del producto.
Un detalle de implementación que costó dos intentos: los iconos NO pueden
declararse como cadenas de HTML para v-html. Dentro de un <svg>, v-html parsea
como HTML y los <path> quedan sin el namespace de SVG: aparecen en el DOM pero
no dibujan nada, así que la primera versión se veía perfecta en el código y en
blanco en pantalla. Van declarados como pares [etiqueta, atributos] para que
Vue los cree con el namespace correcto.
Y AgenteDetail usaba cinco iconos sin importar el componente. Verificado ahora
sobre todos los archivos: cada componente usado está importado donde se usa.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un fondo animado corriendo todo el día en una herramienta de trabajo se ve bien
diez segundos y molesta las ocho horas siguientes, además de tener un canvas
comiéndose la batería. Así que el movimiento va donde hay algo pasando de
verdad, y el fondo queda quieto.
Al entrar, una vez por sesión: el campo de puntos conectándose durante poco más
de un segundo, y se destruye. Es el mismo lenguaje visual de la página pública
—puntos que se enlazan, como el espacio vectorial donde vive el conocimiento—
así que refuerza la marca en vez de inventar algo para adentro.
En los momentos de espera, que es donde el producto se veía muerto: el chat de
prueba decía "Pensando..." en gris y ahora muestra a Umi con los tres puntos,
el mismo gesto que ve el visitante en el widget. Y una fuente en "procesando"
tenía la etiqueta quieta, sin decir si seguía avanzando o se había colgado:
ahora late.
El fondo es una retícula de plano técnico, tenue y estática, que se desvanece
hacia abajo para no competir con las tablas y los formularios.
Dos cosas que aparecieron al verificar:
El apagado de la animación de entrada estaba dentro del requestAnimationFrame,
que el navegador no corre en pestañas de fondo — abrir el Studio en una pestaña
que no se está mirando dejaba el canvas puesto para siempre, tapando la
interfaz con una capa invisible. Ahora el temporizador se programa aparte.
Y una fuente sin procesar mostraba "leído sin procesar", que no quiere decir
nada: si no hay fecha de lectura, no se escribe la frase.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Las plantillas de rubro dejan las notas con valores entre corchetes y la propia
pantalla dice "abrilas y reemplazalas por tus datos" — pero no había con qué.
El endpoint para editarlas existía desde que se agregaron las fuentes de texto;
lo que nunca se agregó fue el botón, así que el flujo que el producto promete
no se podía completar. Se elegía la plantilla de restaurante y quedaban cuatro
notas diciendo "[12:00]" sin forma de arreglarlas salvo borrarlas y escribirlas
de nuevo.
Ahora cada nota tiene "Editar": abre el contenido, se corrige y al guardar se
rehacen los fragmentos, así que el agente pasa a contestar con lo nuevo en el
momento.
También se puede editar el texto que se le extrajo a un archivo: si el OCR de
un PDF salió torcido, corregirlo a mano es tan válido como escribir la nota, y
es el mismo código. Las URLs no — su contenido se rehace crawleando y cualquier
corrección se perdería en la próxima actualización.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La mascota. Umi sale del logo, no es un dibujo aparte: su cuerpo es la "u" del
monograma y el punto del logo pasa a ser su antena, así que símbolo y personaje
son la misma forma vista dos veces. Por eso puede estar al lado del logo sin
competirle.
Tiene estados, y no son decoración: cada pantalla vacía dice algo distinto y la
cara lo dice antes que el texto. Dormida cuando todavía no pasó nada, buscando
cuando falta cargarle información, contenta cuando no hay errores, alerta
cuando algo se rompió. Los ojos toman el color de la superficie de atrás en vez
de ser blancos, así se apoya sobre cualquier tarjeta y en modo oscuro no quedan
dos puntos flotando.
Las pantallas vacías. Había una buena y ocho que decían "Sin canales
configurados." y nada más — el usuario quedaba resolviendo solo qué significa
eso y qué hacer. Ahora las ocho explican qué va ahí y por qué importa: "No está
atendiendo en ningún lado", "Todavía no sabe nada de tu negocio".
El vocabulario. La misma cosa tenía dos nombres según la pantalla: tenant y
espacio, tool y herramienta. Un producto que se llama distinto a sí mismo en
cada lugar se siente como varios productos pegados. Queda: espacio, agente,
herramienta, fuente. Y "al AI" pasa a "a la IA", que además es el género que ya
usaba el resto del panel.
Y la barra de scroll de las pestañas, que se veía gris y gruesa sobre el
contenido: en escritorio las siete entran holgadas y no hacía falta, en móvil
siguen deslizándose pero sin la barra encima.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Hasta ahora la única forma de darle información a un agente era crawlear una
URL, una vez, para siempre. Tres cosas cambian:
Escribir a mano. Es la fuente más valiosa y la única que no está en ningún
documento: horarios, qué no hacen, la respuesta que dan quince veces por día.
También es la única que el dueño puede corregir en el momento en que ve al
agente contestar mal.
Subir un archivo. La lista de precios suele estar en un PDF, no en la web. Usa
el mismo extractor que los adjuntos de los canales, así que PDF, Word, texto e
imágenes entran sin código nuevo. El texto se extrae con la persona mirando la
pantalla: si el archivo no se puede leer, se dice ahí y no en un log.
Y lo importante: el conocimiento se congelaba el día que se cargaba. Si el
cliente cambiaba los precios en su sitio, el agente seguía dando los viejos con
total seguridad — sin error, sin aviso, nada. Ahora cada fuente muestra de
cuándo es ("leído hace 3 meses", en ámbar pasados dos meses), tiene botón de
actualizar, y las URLs pueden marcarse para releerse solas cada semana (cron a
las 4 AM). Reprocesar reemplaza los fragmentos en vez de sumarlos: si no,
quedaban las dos versiones compitiendo en la búsqueda y podía ganar la vieja.
De paso, el troceado dejaba fragmentos que arrancaban a mitad de palabra
("alabra…") porque el solape no se alineaba a un espacio.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Faltaba la tercera pata: audio pasaba por Whisper, imagen por OCR, y un PDF o
un Word adjunto se ignoraba en silencio. Ahora hay un interruptor por canal
—"Leer archivos adjuntos"— y los documentos que llegan por Telegram o WhatsApp
se convierten a texto antes de pasar al agente.
PDF se lee con stdlib cuando el documento es digital (facturas, cotizaciones,
lo exportado por cualquier programa) y cae al OCR si es un escaneo. Word .docx
es un zip con XML adentro; texto plano, CSV y JSON van directo.
El agente recibe el contenido con contexto ("el cliente adjuntó X, y escribió
Y"), no el chorizo pelado: sin eso el modelo contesta como si el cliente
hubiera tipeado una factura.
De paso la importación de plantillas gana PDF, que usa el mismo extractor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
En el portal, un cliente con un solo espacio y un solo agente tenía que
elegir dos veces antes de llegar a lo suyo. Ahora entra directo.
Y la primera pestaña deja de ser configuración: lo que le importa al dueño
es qué le están preguntando sus clientes, y poder probarlo. Para el staff
el orden queda igual.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Al navegar de /tenants/2 a /tenants/3, vue-router reusa la misma instancia
del componente porque es la misma ruta con otro parámetro. onMounted no
vuelve a dispararse, así que la vista seguía mostrando los agentes del
tenant anterior.
Las tres vistas tenían el mismo problema: TenantAgentes, AgenteDetail y
Uso. Ahora reaccionan al parámetro (watch con immediate) en vez de al
montaje.
En AgenteDetail se limpia el estado antes de pedir los datos nuevos: si no,
durante la carga se ven los documentos, canales y conversaciones del agente
anterior bajo el nombre del nuevo, que es peor que una pantalla vacía.
Verificado navegando de verdad entre dos tenants con agentes distintos: la
lista pasa de "Ventas T2" a "Soporte T3 / Cobros T3".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cuatro cosas que ya estaban a medio construir y no se usaban como canal.
1. El badge del widget ahora es un enlace con UTM. Cada cliente ya te
estaba dando exposición en su sitio y no se capitalizaba. El host sale
de la URL del propio script, así funciona igual en cualquier entorno.
2. Reporte del mes por agente en Excel: conversaciones atendidas, con qué
las abrió el visitante, y el consumo desglosado. Es lo que el cliente
necesita para justificar el gasto puertas adentro — un panel al que hay
que entrar no sirve para eso, un archivo que se reenvía sí. Reusa el
generador de xlsx del cronograma.
3. Aviso automático de agentes sin base de conocimiento (cron diario). Un
agente sin fuentes responde de memoria e inventa datos, el cliente
concluye que el producto no sirve y se va. Es el punto donde más gente
se cae y se detecta solo. Se avisa UNA vez por agente, usando el log de
auditoría como registro de envío para no necesitar tabla nueva ni
convertir el recordatorio en spam.
4. Tarjeta de uMind en el dashboard del portal: atajo si el cliente ya lo
tiene, oferta si no. Es el punto de contacto más barato que hay — ya
entró, ya confía, y el cobro se suma a la factura que ya recibe. El
mensaje lidera con notas de voz y fotos, que es lo más difícil de
copiar de lo que tenemos.
La consulta de conversaciones agrupa en SQL en vez de traerse el historial
entero para agrupar en Go.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
El SPA pasa a llamarse uMind Studio y vive en /studio (el nombre
"Orquestador" no le decía nada al cliente final, que ahora es quien lo usa).
Diseño:
- Los colores viven una sola vez como variables CSS + clases semánticas
(.card, .input, .btn-*, .badge-*). Antes cada elemento repetía el par
claro/oscuro a mano en cientos de lugares y cambiar un tono era buscar
y reemplazar.
- darkMode pasa de 'media' a 'class' con toggle propio persistido: el
usuario elige, no el sistema operativo. Se aplica antes de montar la
app para que no parpadee.
- Componentes compartidos (UiModal, UiBadge, UiEmptyState) donde antes
había markup duplicado inline.
Nueva pantalla de consumo (/tenants/:id/uso): filtros por fecha con
atajos, total del período, pendiente de facturar, barra contra el tope
del plan, desglose por tipo y gráfico por día. El gráfico son divs con
altura porcentual — no vale traer una librería de charts para esto.
Rename:
- /studio y /portal/studio; /orchestrator redirige 301 conservando la
ruta interna, así los enlaces guardados siguen funcionando. Los assets
del bundle quedan exentos (el `base` de Vite sigue en /orchestrator/):
redirigirlos rompería el SPA.
- El submódulo sembrado migra el mismo registro buscando por las tres
URLs históricas (/app/umind → /orchestrator → /studio) en vez de
dejar entradas duplicadas en el menú.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Acá es donde uMind deja de ser una herramienta interna: el cliente entra
a /portal/studio con su sesión de portal y gestiona lo suyo.
- UmindScopePortal/UmindScopeStaff es el ÚNICO punto donde se decide el
alcance. El del cliente sale de GetClienteIDsForPortalUser, el mismo
que ya autoriza el resto del portal. nil = staff sin restricción,
slice vacío = no ve nada; una ruta sin scope también cae en "no ve
nada" para que olvidarse el middleware falle visible y no abra todo.
- Un solo set de handlers montado bajo /app/umind y /portal/umind
(RegistrarRutasUmind). Duplicarlos sería duplicar las chances de
olvidar un chequeo.
- Guarda de acceso en TODOS los handlers, incluidos los sub-recursos que
llegan por :id (documento, tool, canal, conexión): hay que cargarlos
para saber de quién son, si no un cliente podría borrar el canal de
otro adivinando el id. Responden 404, no 403: un 403 confirmaría que
el recurso existe.
- Cierra un bug preexistente: las lecturas GET /app/umind/* no tenían
SoloAdmin ni pasaban por MenuMiddleware, así que cualquier usuario de
staff podía leer los tenants de todos los clientes.
- Límite de agentes por plan (409 con mensaje claro). Un tenant sin plan
no tiene límite: cortarles de golpe sería peor que dejarlos como estaban.
- /umind/ai-configs reemplaza con alcance a /app/api/ai-config/select,
que devolvía TODAS las configs del sistema.
- El SPA deduce por la URL si es staff o cliente (base del router,
prefijo de API y URL de login) y oculta lo que es solo de staff.
- Test de aislamiento entre clientes: 7 casos, incluido que un scope
vacío no se confunda con staff.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cada canal (Telegram/WhatsApp) de un agente ahora puede activar, de forma
independiente, que los audios entrantes se transcriban con el Whisper ASR
propio y que a las imágenes entrantes se les extraiga texto con el
servicio OCR propio, antes de pasarle el mensaje al agente. Antes esos
mensajes se ignoraban en silencio.
- UmindCanal gana usar_whisper_audio/usar_ocr_imagenes (default off).
- WhatsApp: se descarga el media vía Graph API (resolución de URL + fetch
con el mismo access_token del canal) y se enruta a Whisper/OCR según type.
- Telegram: se descarga el archivo vía getFile + CDN de archivos del bot,
mismo enrutamiento para voice/audio/photo.
- Panel: checkboxes en el alta de canal y toggles inline por canal ya
creado, en la tab Canales del agente.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nueva tabla umind_eventos_log + tab "Auditoría" en el panel: errores y
eventos que hasta ahora solo se podían ver pidiendo los logs del servidor
(fallos al llamar al AI, respuestas sin texto usable, tools/webhooks que
fallan, tokens de correo que no se pueden refrescar, firmas de WhatsApp
inválidas, errores procesando mensajes de Telegram/WhatsApp) quedan
registrados por agente, visibles directo en el panel con el JSON crudo
expandible para diagnosticar sin acceso al servidor.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Un tenant (negocio/sitio, dueño de los dominios permitidos) puede tener
varios UmindAgente independientes (ej. "Ventas", "Soporte"), cada uno con
su propia config de IA, tono, base de conocimiento, tools, canales y
conexión de correo. El site_key también pasa a ser por agente, así cada
uno tiene su propio <script> de widget embebible y su propio color.
Backend:
- Nuevo modelo UmindAgente (pkg/models/umind_agente.go), con SiteKey,
AiConfigID, Tono, MensajeBienvenida y Color — campos que antes vivían en
UmindTenant y se sacan de ahí (las columnas viejas quedan huérfanas sin
usar, no se hace DROP COLUMN).
- UmindDocumento, UmindChunk, UmindHerramienta, UmindCanal, UmindConexion y
UmindMensaje pasan de TenantID a AgenteID. El campo se agrega sin
"not null" para no romper el ALTER TABLE en Postgres sobre tablas que ya
tienen filas (ej. emetropolitana).
- migrations.MigrarUmindAgentes(): idempotente, crea un agente "Principal"
por cada tenant existente heredando lo que ya tenía configurado, y mueve
sus datos de tenant_id a agente_id. Corre en cada arranque normal, mismo
criterio que los Seed* — nada se rompe para los tenants ya en producción.
- Motor del agente, widget, canales (Telegram/WhatsApp) y OAuth de correo
ahora operan sobre UmindAgente; el tenant solo se consulta para el
chequeo de dominio permitido y el nombre del negocio que ve el visitante.
Frontend: nueva jerarquía de navegación tenant → lista de agentes
(TenantAgentes.vue) → detalle de un agente (AgenteDetail.vue, antes
TenantDetail.vue) con las mismas 6 tabs de siempre, ahora por agente. El
modal de tenant en el sidebar se achica a nombre/dominios/activo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
