El loop de mantenimiento son skills

Después de “cómo funciona”, la pregunta que sigue es quién lo cuida. El bot atiende unas seis mil conversaciones por mes, y en un volumen así siempre hay algo que salió mal ayer que nadie vio. La respuesta corta es que no lo cuida una persona mirando chats, sino un loop de cinco procedimientos escritos que corre Claude Code contra el repo y contra producción.

Cada procedimiento es un skill, y son cinco porque un bot no se rompe de una sola forma. Un dato que no salió de ninguna herramienta, una regla que el prompt dejó de sostener, un arreglo que arregló otra cosa: nada de eso dispara una alarma. Se nota recién cuando alguien lee la charla y la compara con lo que pasó por dentro, y ese es el trabajo que no quería hacer a mano.

El loop, de punta a punta

Cinco skills, cada uno con una entrada y una salida definidas. Dos encuentran problemas, uno ordena, uno arregla y uno vigila. Cada arreglo termina en una nota que lee la tienda. El resto del post recorre esas cinco etapas en ese orden: encontrar, ordenar, arreglar, vigilar, contar.

Encontrar: la auditoría y lo que reporta la tienda

La primera entrada es proactiva. El skill de auditoría toma una ventana de tiempo, lista las conversaciones donde el bot escribió y revisa cada turno contra los traces de producción. Verifica tres cosas por turno: que cada dato concreto de la respuesta salga de una herramienta del mismo turno, que la secuencia de herramientas tenga sentido para lo que pidió el cliente, y que el bot haya cumplido las reglas vigentes, que el skill lee del código en cada corrida en vez de recordarlas.

La regla que gobierna la auditoría es que cada hallazgo lleva evidencia de los traces, nunca una hipótesis suelta. Si un turno se ve mal y los traces no lo explican, el issue lo dice tal cual: “no pude determinar por qué”. Un hallazgo que un cliente notaría o que rompe una regla explícita entra. Una preferencia de redacción no.

La segunda entrada es la tienda. Tiene una página propia para reportar: sube la captura de WhatsApp, escribe qué le pareció mal, y eso ya es un issue en su tracker. Otro skill toma esa captura, ubica la conversación en Chatwoot por las palabras del mensaje y va a los traces del turno señalado. Lo que encuentra lo escribe como comentario en el issue que abrió la tienda, sin tocar lo que ella escribió, porque el tracker se lo muestra de vuelta.

Los dos caminos terminan en el mismo formato: la conversación, lo que hizo el bot por dentro con evidencia concreta, y una causa probable que apunta a un archivo. Así el skill que arregla no distingue de dónde vino.

Ordenar: triar antes de arreglar

Con el tiempo el backlog se ensucia. El mismo comportamiento aparece dos veces, una vez reportado por la tienda y otra encontrado por la auditoría, o vuelve algo que ya se había cerrado. El skill de triage lee los dos trackers juntos y agrupa por mecanismo, no por síntoma: dos issues van juntos si tocarían el mismo lugar del código.

Su principio es que ninguna acción se hace sin evidencia. Un issue no se cierra porque “parece resuelto” ni se marca duplicado porque “suenan parecidos”. Se cierra si el código actual contempla el caso y hay una prueba que hoy pasa. Si el código lo cubre pero no hay prueba, el issue sigue vivo, y el trabajo pendiente es la prueba.

Arreglar: la prueba primero

El skill que arregla toma un issue y lo lleva a producción en la misma sesión. Antes de proponer nada, verifica que el hallazgo siga vivo, porque un issue envejece entre el alta y la sesión. A veces el código ya lo cubre y sólo falta la prueba. A veces el archivo que señalaba ya no existe, y hay que diagnosticar de nuevo sobre el código de hoy en vez de implementar la hipótesis vieja.

Después viene la escalera que conté en el post sobre alucinaciones: datos, herramienta, guard, y el prompt último. Con una alarma extra: si es la segunda vez que se escribe la misma regla en el prompt, está prohibido, porque esa regla ya demostró que el prompt no la sostiene.

El paso que no se saltea es la prueba que falla antes del arreglo y pasa después. Y la prueba más barata primero: un test unitario cuesta cero, y un escenario con el modelo cuesta plata en cada corrida, como medí en el post sobre las pruebas. Por eso el orden es fijo, del unitario al escenario nuevo, y si el arreglo termina en el último escalón se dice en voz alta, no se agrega en silencio.

Antes de tocar código, el plan pasa por un interrogatorio: causa raíz, alcance, dónde va la prueba y qué puede regresionar. Es el único freno del skill. Con eso cerrado, el arreglo va a la rama principal y se despliega. El entregable son arreglos, no issues nuevos.

Vigilar quince minutos

Un deploy sin vigilancia está incompleto. El skill de después del deploy mira tres cosas durante unos quince minutos: que la versión esté viva y responda, que no haya errores nuevos de esa versión, y que el síntoma que se arregló no reaparezca en el flujo tocado. Si no hubo tráfico en ese flujo, quince minutos de silencio también cierran, y se dice. Si aparece el síntoma o un error de esa versión, se revierte y la causa se arregla ahí mismo.

Esa tercera condición no es un adorno, y lo aprendí de la peor forma.

Lo que salió mal: el arreglo que no arregló

El 18 de agosto hice un refactor grande de la función que decide qué recibe el cliente. Lo que no vi es que una parte del reintento llevaba tiempo muerta, y el refactor la dejó expuesta: cuando el bot rechazaba su propio borrador y volvía a intentar, el segundo intento fallaba delante del cliente. Ese mismo día vi los fallos y mandé un arreglo. Tocó el reintento y no encontró el hueco real. El arreglo que sí lo encontró llegó el 25.

Entre el 1 y el 17 de agosto, cerca del 1,2% de los turnos del bot terminaba en un fallo visible. Entre el 18 y el 24, cerca del 2,1%: noventa y siete fallos en siete días, contados cruzando los mensajes de fallo en Chatwoot con los turnos registrados en los traces. Durante una semana estuve convencido de haber arreglado algo que seguía roto.

Lo que quedó de esa semana está repartido en el loop. El skill que arregla exige una prueba que falle antes, porque el arreglo del 18 salió sin una que reprodujera el fallo, y nada me avisó que la causa era otra. Los skills que abren issues exigen traces, porque un fallo se ve en Chatwoot pero la causa sólo se ve en el trace. Y el skill de vigilancia pide un turno del flujo tocado sin el síntoma, porque un deploy que no se mira no se sabe si arregló.

Contar: la nota que lee la tienda

Cada arreglo lleva un archivo más en una carpeta de novedades. Una línea, en lenguaje de tienda: un título en negrita y un detalle. Hay novedades de la plataforma, que ven todos los clientes, y novedades de un cliente, que sólo ve él. Hoy son setenta y ocho.

Los títulos suenan así: “Ya no te vuelve a pedir la capacidad que ya dijiste”, “Aguanta un corte del CRM sin perder la respuesta”. No dicen guard ni reintento. Dicen qué cambió para el que atiende los chats. Una prueba de formato rechaza la entrada si no tiene esa forma, y un gancho del repo rechaza el commit si no trae novedad ni declara que no hace falta.

La tienda no las lee en el repo. Producción las expone como una herramienta del MCP, el servidor que la tienda consulta desde su propio Claude. Pregunta “¿qué cambió en el bot esta semana?” y recibe esas líneas. Es el mismo canal por el que consulta sus conversaciones, y el que sigue en esta serie.

Un bot no se mantiene mirándolo: se mantiene con un procedimiento que exige evidencia para abrir, una prueba para cerrar, y una frase en lenguaje de tienda para contarlo.