El problema
Mantengo un ecosistema personal amplio: briefings de IA programados, contenedores de automatización, una bóveda de conocimiento, un sistema de ejecución, varios sitios desplegados. Estaba bien documentado y su arquitectura era sólida. También era, descubrí, estructuralmente incapaz de detectar sus propios fallos.
Una auditoría de cuatro dominios sacó a la luz lo que llevaba meses siendo cierto en silencio:
- Tres de los cinco briefings programados estaban muertos en silencio — el diario, desde hacía unos tres meses
- Dos contenedores de automatización llevaban tres días caídos, sin política de reinicio ni notificación
- El disco consumía unos 5 GB al día en dirección a un estado crítico, sin diagnosticar
- Los documentos constitucionales llevaban semanas contradiciendo la realidad operativa
- La única rutina de comprobación de salud era estructuralmente incapaz de ver nada de lo anterior
Merece la pena nombrar el modo de fallo con precisión, porque se generaliza: cada componente estaba sano por separado y no reportaba a ningún sitio. No había ninguna superficie donde el sistema, en conjunto, hablara con su operador. Añadir otro panel habría sumado una decimosexta cosa que revisar. Lo que faltaba no era monitorización. Era orientación.
La verdadera restricción
La restricción dura no era técnica. Era la atención.
Tengo un diagnóstico de TDAH y soy superviviente de un traumatismo craneoencefálico. Una herramienta que exige vigilancia para ser útil es una herramienta que abandonaré en menos de dos semanas, y tengo un cementerio de apps de productividad abandonadas que lo demuestra. Así que el brief de diseño no era "mostrar todo el estado del sistema". Era más difícil:
"Diseña para la peor mañana, no para la mejor."
Esa única restricción generó casi todas las decisiones posteriores. Descartó la exhaustividad, descartó la configuración, descartó cualquier cosa que premie mirar con frecuencia y descartó todo el lenguaje visual de urgencia que las herramientas de monitorización adoptan por defecto.
Cinco decisiones que hicieron el trabajo
1. Observa, no posee
Compass no guarda ningún dato primario. Cada hecho que muestra vive en otro sitio y se lee, nunca se escribe. La prueba a la que lo sometí: borra Compass esta noche y no pierdes nada. Eso es lo que hace que sea seguro depender de él: nunca podrá convertirse en otro sistema que exija copias de seguridad, migraciones o cuidados.
2. La confianza es la funcionalidad
Cada dato lleva su antigüedad. Cada inferencia lleva su nivel de confianza. Y, sobre todo, "el propio monitor está caído" es un estado de primera clase: no un error, no una pantalla en blanco. Una herramienta de monitorización que no puede reportar su propio fallo es exactamente la herramienta que acababa de fallarme durante tres meses. Compass está construido para admitir cuándo no sabe.
3. Un tope estricto de tres elementos y un siguiente movimiento
La interfaz se niega a mostrar más de tres cosas que requieran atención y propone exactamente una siguiente acción recomendada al día. No una lista priorizada: un único movimiento. Las listas devuelven la decisión a quien lee; en una mala mañana, esa devolución es donde la herramienta pierde.
4. El silencio es un entregable
"Nada te necesita" es un estado de éxito, y se celebra como tal, diseñado con el mismo cuidado que cualquier alerta: no es un estado vacío ni un marcador de posición. La mayoría de las herramientas tratan la calma como ausencia de contenido. Aquí es el producto funcionando. El presupuesto de notificaciones es de cero a dos avisos por semana, por diseño.
5. Ajustes por defecto contra la vergüenza
Sin rachas. Sin porcentajes de completado. Sin muros rojos. Las tarjetas de fallo llevan causa, reparación y un arreglo de un toque sujeto a consentimiento, nunca una regañina. Un sistema que te hace sentir mal por el estado que reporta es un sistema que dejarás de abrir, y una herramienta de monitorización que no abres es peor que ninguna.
La marca lleva la tesis
El brief de identidad era "un instrumento silencioso, no una app exigente". La marca es una rosa de los vientos reducida a su forma mínima honesta:
- El anillo es un arco de 300° con una apertura deliberada: el sistema nunca está "terminado", solo orientado. También se lee como un anillo de progreso en reposo: en calma, sin contar.
- La aguja es la tesis entera del producto en una sola forma. La punta norte es sólida: lo que importa ahora. La punta sur está solo delineada: contexto que puedes ignorar sin riesgo. Señal frente a lo que se puede ignorar, dibujado.
- El punto de pivote eres tú. Todo gira alrededor de un centro fijo.
Es monocroma y hereda currentColor, así que la barra de navegación, el favicon, el modo oscuro y los embeds son el mismo recurso. Cero variantes que mantener, lo que ya es en sí una decisión pensada para el TDAH.
Silencio cromático
La interfaz base es casi monocroma y el color saturado se reserva exclusivamente para la semántica de estado, de modo que el color siempre significa algo. Cuando todo puede tener color, el color deja de transmitir información: así es como los paneles de monitorización se convierten en papel pintado.
El estado aparece como puntos pequeños y barras finas, nunca como fondos de tarjeta inundados de color. Un muro rojo es pánico, no información.
El color de acento, un ámbar llamado north-500, se eligió frente al azul o el turquesa evidentes por tres razones convergentes: se lee como luz de día cálida, sigue distinguiéndose del par semántico verde/rojo por seguridad ante el daltonismo, y el cálido sobre tinta sobrevive al Night Shift de iOS sin convertirse en barro. Un elemento ámbar por pantalla, como máximo.
La tipografía es la pila del sistema, a propósito: coste de descarga cero para una app que funciona primero sin conexión, y una sensación nativa; Compass debería leerse como parte del teléfono, no como un sitio web. Solo cuatro tamaños. El peso hace la jerarquía; el tamaño hace la estructura.
Una corrección que merece quedar registrada
La primera especificación daba por hecho que la pila de fuentes del sistema heredaría Dynamic Type de iOS, con el escalado de texto accesible gratis. No es así: Dynamic Type no se propaga al contenido web de una PWA. Una revisión de diseño lo detectó antes de construir.
Por eso Compass incluye su propio control de tamaño de texto como multiplicador rem en la raíz, con toda la tipografía definida en rem sobre la escala de cuatro roles, para que la jerarquía sobreviva al escalado. Es un arreglo pequeño que habría sido un fallo de accesibilidad lanzado en silencio, y para una audiencia de una sola persona que lo necesita, un fallo fatal.
Arquitectura
Dos componentes nuevos, todo lo demás reutilizado:
- Un recolector: un único script horario que lee señales que ya existen (JSON de salud, instantáneas de herramientas, latidos de archivos, estado de contenedores, del planificador, de git y del disco), comprueba cada una contra un contrato de cadencia declarado, ejecuta un diagnóstico determinista de fallos y publica un único objeto de estado autenticado. El estado personal nunca toca una URL pública.
- Una superficie: una PWA estática e instalable, plenamente funcional sin conexión. Cuatro pantallas, dos niveles de profundidad.
La capa de inteligencia tiene, a propósito, dos niveles: primero lo determinista, después la IA. Los latidos son aritmética sobre marcas de tiempo de archivos, no llamadas a un modelo. La IA anota los hechos; nunca es los hechos. Y el planificador corre en local en lugar de en la nube, precisamente porque el planificador en la nube es lo que falló en silencio durante tres meses. El fallo enseñó la arquitectura.
Coste recurrente: aproximadamente cero.
Estado — con honestidad
La fase 1 está lanzada y activa. El recolector funciona, la PWA está instalada en mi teléfono y el ciclo matinal de dos minutos es real. Su usuario previsto la usa a diario.
La fase 0, reparar los fallos que encontró la auditoría, está parcialmente completa; la tendencia del disco sigue abierta. La fase 2 (el motor de oportunidades y las narrativas de puntos ciegos) está especificada y sin construir. La fase 3 existe solo como condición: construirla solo si las fases 1 y 2 se convierten en hábito.
Los criterios de éxito con los que lo juzgaré a los seis meses son deliberadamente falsables: cero fallos silenciosos de más de 48 horas, al menos un hallazgo por semana que lleve a actuar, menos de quince minutos de mantenimiento al mes y lo que llamé la prueba Demuéstralo: siete días fuera, una pantalla, orientación completa recuperada.
Lo que me enseñó este proyecto
Diseñar para tu propia limitación es el brief más afilado que existe. No había ningún perfil de usuario tras el que esconderse ni investigación que interpretar: si una decisión era errónea, la sentiría a la mañana siguiente. Los ajustes por defecto contra la vergüenza, el tope de tres elementos y el silencio como éxito no salieron de una biblioteca de patrones; se eligieron porque las alternativas ya me habían fallado personalmente.
Lo más valioso que puede hacer una herramienta de observabilidad es admitir su ignorancia. Todo el proyecto existe porque un comprobador de salud no podía ver su propio punto ciego. Construir el "no lo sé" como un estado de primera clase, en lugar de como un hueco, es la decisión de diseño que me llevaría a cualquier producto que maneje incertidumbre, lo que hoy significa la mayoría de los productos con IA dentro.
Y la contención es más difícil de diseñar que la capacidad. Cada pantalla fue un argumento en contra de añadir algo.
Cómo se hizo
Compass se diseñó y construyó con asistencia de IA de principio a fin, trabajando con Claude en la auditoría, la especificación y la implementación, y se revisó con pasadas de agentes adversarios que detectaron errores reales, incluido el fallo de Dynamic Type descrito arriba.
La dirección de producto, las restricciones, los principios de diseño y cada decisión de criterio son míos. Dejo constancia del método explícitamente porque es como trabajo ahora, y porque un caso de estudio sobre confianza que fuera vago sobre su propia procedencia sería una mala publicidad del principio.