Caso de estudio · Rutina
Diagnosticar y reparar un sistema que ya no se comunica
Piezas que funcionaban cada una por su lado, pero cuyos enlaces se habían roto sin hacer ruido. Cuatro relevamientos, un mapa, un repaso de todas las flechas, correcciones comprobadas en su origen y, después, una vigilancia que constata sin reparar.
Idea
¿Qué problema, en una frase?
Constatar que las piezas ya no se comunican
Cada pieza funcionaba sola: la clasificación del correo, el panel de control, las tareas programadas, el centinela. Pero las flechas entre ellas se habían roto sin hacer ruido. El síntoma no era una avería visible, sino un silencio: nada indicaba que nada circulaba.
DificultadUna decisión pendiente desde hacía días que nadie presentaba: dormía en un informe que nada releía.
SoluciónToda pregunta pendiente va a una única cola de decisiones, que lee el panel de control.
DificultadPasadas de rutina marcadas como «correctas» que no habían producido nada.
SoluciónUna pasada solo es correcta si deja un rastro con la fecha del día: registro, archivo o fila de tabla.
DificultadTareas programadas que no veían los plugins instalados en la sesión interactiva.
SoluciónCada tarea declara lo que necesita y comprueba al arrancar que está disponible; si no, se detiene y lo dice.
DificultadUn centinela que no veía las averías, porque leía los mismos registros que las piezas que vigilaba.
SoluciónEl centinela comprueba los productos (archivos, páginas, filas), no las declaraciones.
!Un sistema silencioso no es necesariamente un sistema sano: la ausencia de alertas también debe comprobarse.
Concepto
¿Qué será la herramienta y qué hará?
Hacer cuatro relevamientos
Antes de reparar, relevar lo existente en cuatro partes: las conversaciones (lo que se ha pedido y hecho), las skills y los conectores (lo que está instalado, dónde y para qué), las tareas programadas y el panel de control (lo que funciona y lo que se muestra), el sitio público (lo que está publicado). Cada relevamiento lleva fecha y dice lo que no ha podido leer.
Qué decirle a Claude«Haz cuatro relevamientos de mi sistema sin modificar nada: conversaciones de los dos últimos meses, skills y conectores instalados, tareas programadas y panel de control, sitio público. Para cada elemento: dónde vive, qué lee, qué escribe y su último rastro fechado. Termina con lo que no has podido consultar.»
DificultadLas mismas skills instaladas en dos sitios, en dos versiones distintas.
SoluciónEl relevamiento anota la versión y la ubicación de cada copia; una sola fuente es la de referencia y las demás derivan de ella.
Dibujar el mapa y repasar todas las flechas
Un mapa del sistema: cada pieza es una caja y cada intercambio una flecha (quién escribe qué, quién lo lee y cuándo). Después, un repaso de todas las flechas, una por una: ¿la fuente escribe de verdad? ¿El destino lee en el mismo sitio? Una flecha sin lector, o un lector sin fuente, es una avería en espera.
DificultadRutas de archivo escritas para un ordenador antiguo, que algunas tareas seguían usando.
SoluciónLas rutas se reúnen en un único archivo de configuración, que cada pieza relee.
!Varias decenas de flechas: no comprobarlas de memoria, sino una por una, con una prueba.
Realización
¿Qué pedir a Claude, y en qué orden?
Probar en vacío y listar problema → solución
Cada elemento se ejecuta en vacío, sin escribir nada, para ver qué leería y qué produciría. Cada desviación se convierte en una línea problema → solución en una página donde un botón copia el prompt de corrección, listo para pegar en una nueva conversación.
DificultadUna prueba en vacío que escribía igualmente en el registro real.
SoluciónUn modo de prueba explícito, que escribe en una carpeta de pruebas y lo anuncia al principio de su salida.
Presentar el resultado en cuatro bloques
El resultado se presenta en cuatro bloques: lo que Claude corrige sin autorización (una errata en un archivo de reglas), lo que requiere autorización (modificar una tarea, tocar una página publicada), las rutas que hay que armonizar, y lo que solo depende de la persona: volver a conectar una cuenta, instalar un plugin en un puesto, elegir entre dos opciones. Este último bloque se titula «solo queda usted».
Qué decirle a Claude«Aquí está la lista problema → solución. Coloca cada línea en uno de los cuatro bloques: sin autorización, con autorización, rutas, solo queda usted. Para cada línea del bloque «con autorización», escribe la pregunta que debes hacerme y la opción que recomiendas.»
DificultadUna lista de varias decenas de correcciones, ilegible de un tirón.
SoluciónEl bloque «solo queda usted» es corto y va al principio: es la única parte que espera una acción humana.
Prueba
¿Cómo demostrar que funciona?
Ejecutar lo autorizado y releer cada escritura desde su fuente
Una vez dadas las autorizaciones, Claude ejecuta y después comprueba cada escritura con un viaje de ida y vuelta: relee el archivo, la página o la fila desde el lugar donde la leerá la pieza destinataria, y no a partir de lo que cree haber escrito.
DificultadUna corrección anunciada como hecha, pero escrita en una copia que nadie leía.
SoluciónNinguna corrección se da por hecha sin releerla desde la fuente real, con la prueba (fecha, extracto).
!Una corrección no releída es una hipótesis, no un hecho.
Añadir dos controles nacidos del diagnóstico
Dos controles nuevos se suman a la vigilancia: «tarea correcta pero sin registro del día», que detecta las pasadas vacías, y «la ruta del usuario corresponde al puesto actual», que detecta las rutas heredadas de un ordenador antiguo.
Puesta en servicio
¿Cómo entregarla, publicarla y hacerla durar?
Un monitor de pilotos
Un monitor agrupa los pilotos por área (correo, agenda, panel de control, tareas, sitio, conectores). Prueba los conectores en directo, muestra alarmas que se pueden dar por atendidas con su historial, y un mapa del sistema en el que parpadea la flecha averiada.
DificultadAlarmas que seguían en rojo tras la corrección y acababan ignoradas.
SoluciónCada alarma se da por atendida a mano, con la fecha y el motivo; una alarma atendida que reaparece sube al principio.
Una auditoría dominical, un juez separado, una página de decisiones
Cada domingo, una auditoría relee el sistema con la antigüedad de cada alerta y la latencia de los proyectos. El juez está separado de lo que juzga: el centinela constata, nunca repara. Las preguntas que plantea van a una página de decisiones del sistema, una ficha por pregunta con una opción recomendada, y nada cambia antes de la respuesta.
DificultadUn centinela que corregía por su cuenta lo que encontraba, y así ocultaba las averías recurrentes.
SoluciónConstatar y reparar son dos papeles distintos; la reparación pasa por la decisión y después por una relectura.
!El detalle de la auditoría semanal y de la página de decisiones figura en la ficha sobre el inventario cruzado.