Worklog

el asistente de IA responde ya sobre todo CreaRack, librerías al día y Valkey 9

el asistente de IA responde ya sobre todo CreaRack, librerías al día y Valkey 9

el asistente de IA ya ve el historial de cada radio, los saltos de canal y los equipos por tipo

el asistente de IA ya ve el historial de cada radio, los saltos de canal y los equipos por tipo

el asistente de IA pasa la prueba de fuego y las antenas dejan de mostrar un ruido falso

el asistente de IA pasa la prueba de fuego y las antenas dejan de mostrar un ruido falso

CreaRack ya tiene su propio asistente de IA, el historial de inicios de sesión tiene su ventana y las pruebas dejaron de hacer cola

CreaRack ya tiene su propio asistente de IA, el historial de inicios de sesión tiene su ventana y las pruebas dejaron de hacer cola

los avisos por correo ya se envían y cualquiera los activa, las gráficas grandes admiten notas del equipo y el chat del correo por fin responde bien

los avisos por correo ya se envían y cualquiera los activa, las gráficas grandes admiten notas del equipo y el chat del correo por fin responde bien

un punto de acceso que se reiniciaba cada cinco minutos, CreaRack ya apunta cada caída y cada técnico podrá pedir sus avisos por correo

Segunda mitad del día de FABCON en el CCIB. Claude midió la sala de la Expo en plena hora de comer (casi 2.000 dispositivos conectados) y comprobó que con tanta gente la señal entre antenas apenas cambia. Edu vio que una tabla de redes no cuadraba con el resto de la pantalla: contaba con datos de hasta una hora antes, y ya cuenta en vivo. Mirando a fondo el wifi apareció un problema serio: el punto de acceso de la Sala 119 se reiniciaba solo cada pocos minutos desde el día anterior, 52 veces en 24 horas, y nadie se había enterado. Claude descartó el cable, la corriente y la cantidad de gente, y Edu lo cambió por otro aparato que funciona bien. Para que no vuelva a pasar desapercibido, CreaRack ahora apunta cada vez que un equipo se cae y cuánto tarda en volver, y lo enseña en la ficha de cada grupo. Además se diseñó, con Edu, un sistema de avisos por correo que cada técnico configura en su ficha (qué avisos quiere, si le recuerdan y si le avisan al resolverse); la primera parte ya está hecha y la segunda, la que envía los avisos con el consejo de la inteligencia artificial, queda para la próxima sesión. También se arreglaron permisos de usuarios, botones que quedaban fuera de la pantalla en los editores y las gráficas de un aparato recién dado de alta.

una mañana de feria en la que se cerraron más de 27 tareas, Cloudflare ya no puede guardar nada privado y la copia del Workspace avisa si falla

Edu estaba en el CCIB con la plenaria de FABCON en el auditorio y después la Expo. Claude vigiló el wifi de las dos salas cada diez minutos sin encontrar problemas: más de mil dispositivos en el auditorio y la red de los asistentes con más de dos mil en todo el edificio, sin caerse. Con varios ayudantes trabajando a la vez, se repasaron las 161 tareas abiertas y se cerraron más de 27: cosas que ya estaban hechas, arreglos pequeños del producto (el cursor de las gráficas, los botones del editor de planos, el zoom del editor de armarios, permisos más seguros, la auditoría de los planos…) y ajustes del sistema de trabajo de Claude. Cada cambio delicado lo repasó un revisor de seguridad antes de publicarse. Además, Cloudflare ya no puede guardar en su caché nada que dependa de la sesión de un usuario, y la copia diaria del Workspace avisa por correo si falla (el lunes falló sin que nadie se enterase). Las tareas de negocio pasan a la reunión de vuelta con Dani y Txell, el 9 de octubre.

el filtro por red del wifi ya funciona en pantalla, la gráfica de tráfico deja de caer a cero sin motivo y las tareas del Gestor se encuentran por su número

tarde en el CCIB, con la feria FABCON26 en marcha. El filtro por red de las gráficas de wifi, que se preparó por la mañana, ya está funcionando: en cada punto de acceso o grupo de salas se puede elegir una red (por ejemplo la de los asistentes de la feria) y ver solo sus clientes y su tráfico; Edu lo probó y funciona muy bien, y la ayuda de la aplicación ya lo explica. Al probarlo, Edu vio que la gráfica de tráfico caía a cero cada pocos minutos: no era real, sino un fallo del programa que instalamos en la red del cliente cuando el contador de bytes del aparato se llena y vuelve a empezar; se corrigió y se publicó la versión nueva, que los equipos recibieron solos en segundos. Además: el diario del equipo cuenta en castellano lo que hace Claude, en vez de con nombres técnicos; las tareas del Gestor muestran su número y se pueden buscar escribiendo, por ejemplo, "#392"; Claude puede consultar los datos de producción sin poder cambiarlos, gracias a un permiso concreto que añadió Edu; y el estudio de las conexiones con los fabricantes recoge una idea que Edu tenía en la cabeza: que el propio asistente de inteligencia artificial de un cliente pueda preguntarle cosas a CreaRack (tarea #392, para la charla del 6 de octubre).

el wifi de la Sala 113 fallaba por una red interna del CCIB, no por el wifi; y ya se puede filtrar el tráfico inalámbrico por red

Edu siguió en el CCIB, en plena feria FABCON26. Hubo una incidencia de wifi en la Sala 113: parecía un problema de cobertura, pero investigando se vio que la culpa era de una red interna de los propios administradores del edificio, que se caía cuando subía el tráfico wifi; el equipo del CCIB lo confirmó con su propio sistema de vigilancia y pasó esa red a un equipo de repuesto, y todo volvió a la normalidad. De la investigación salió un criterio nuevo de Edu: no dejar que el sistema reparta clientes entre antenas en automático, sino poner un límite manual, y no asustarse cuando llega mucha gente de golpe porque el reparto se estabiliza solo. Aparte, dos mejoras pequeñas ya en producción: la tabla de redes de un grupo de puntos de acceso ahora solo cuenta datos recientes y dice de cuántos aparatos viene la información, y la vista grande de una gráfica dice ahora de qué punto de acceso o grupo se trata, también al imprimirla o guardarla como imagen. Docker Desktop, que ya no se usa en el portátil de Edu, se apagó del todo. Se dejaron escritos dos estudios sobre una idea de futuro: que CreaRack hable directamente con las aplicaciones de cada fabricante de wifi en vez de depender de un único protocolo genérico. Y el trabajo grande del día: ahora se puede filtrar las gráficas de wifi por red (VLAN), no solo por punto de acceso; los aparatos de la calle ya envían ese dato nuevo y llegó bien a un ordenador de prueba, pero falta comprobar que también llega a donde se guardan las gráficas para consultarlas después. La pantalla para elegir la red ya está subida a revisión, pendiente de que pase las pruebas automáticas.

una tarde de cierres: Claude estrena navegador propio, el diario vuelve a verse, las copias dejan de engordar y la revisión semanal vuelve a funcionar

Edu siguió en el CCIB y aprovechamos la tarde para cerrar cosas. Claude tiene desde hoy su propio navegador, que Edu no usa, para no volver a abrirle pestañas en su ventana de trabajo; y las sesiones de Claude que trabajan a la vez se avisan por turnos antes de usarlo. La página del diario del Workspace llevaba desde el 16 de septiembre sin enseñar las sesiones nuevas y llena de texto técnico: ya se ve bien. Descubrimos que las copias de seguridad diarias del Workspace crecían un tercio cada día porque se guardaba entero lo que la Biblioteca indexaba; ahora se guarda un resumen y esta noche se limpia lo antiguo. Salió a producción un arreglo de seguridad: si una organización tiene dos Agentes, solo el principal recibe las contraseñas de los equipos. La revisión automática de los domingos llevaba dos semanas sin pasar porque el ordenador que la lanza tenía una versión vieja de Claude; se actualizó, se relanzó y encontró cuatro cosas a mejorar. Las copias de seguridad de la semana están todas donde deben. Y Edu pidió revisar el WiFi de la sala 128, con quejas de calidad: la señal es buena, pero ese punto de acceso cambia de canal muchísimas veces por detecciones de radar que sus vecinos no tienen; Edu probará esta semana a cambiarlo de sitio.

el WiFi de la sala polivalente del CCIB, ajustado con lo que los propios puntos de acceso oyen unos de otros

Edu estaba en el CCIB durante el montaje de una feria de 5.000 personas y quería elegir bien los canales de un punto de acceso móvil. En vez de fiarnos de las medidas habituales, que con la sala vacía no distinguían nada, le preguntamos al propio aparato qué redes oía y con qué fuerza. De ahí salió una idea más grande de Edu: que CreaRack aconseje los canales de toda una sala. Lo probamos en serio con los 18 puntos de acceso de la sala polivalente: CreaRack los leyó todos en unos minutos y un programa propuso un reparto de canales. La prueba enseñó que esa sala está tan llena de antenas que cambiar canales ayuda poco (un 14 %, cuando esperábamos un 30 %), y que Edu, con su experiencia, no quiere mover nada hacia canales donde aparecen radares del puerto. Con esa regla se ajustaron 18 canales en 11 puntos de acceso, esta vez aplicados directamente por CreaRack con permiso de Edu, y se comprobó por dos vías que todo quedó bien. De paso encontramos y arreglamos un fallo en la herramienta de planificación de canales de Edu, y dejamos escrito cómo razona él para diseñar la futura función. El martes, a la hora de comer de la feria, mediremos la sala llena para compararla con la vacía.

la prueba automática en navegador ya funciona cada semana, y el primer día encontró dos fallos de verdad

desde hoy, cada lunes de madrugada un navegador automático entra en la versión de pruebas de CreaRack con un usuario propio, en Chrome y en Firefox, y recorre lo básico: iniciar y cerrar sesión, el panel, crear un rack y el terminal. Hasta ahora esa prueba existía pero nunca había corrido. Hoy se ha puesto en marcha y pasa las 20 comprobaciones. Por el camino encontró dos fallos reales, ya arreglados en producción: - **Cerrar sesión desde la dirección de la página**: si alguien abría esa dirección directamente, la pantalla decía "has cerrado sesión", pero la sesión seguía abierta. En un ordenador compartido, la siguiente persona podía entrar con esa cuenta. Ahora la página pregunta y cierra de verdad. El botón del menú siempre funcionó bien. - **Firefox**: en cada página salía un error interno cada vez que la ventana recibía el foco. No se veía, pero ensuciaba los registros. Además: - **Empresa de demostración**: la gráfica de errores de conexión de los equipos salía vacía. Ya muestra datos, que Edu ha visto en pantalla. Los días anteriores a hoy se quedan como estaban, por decisión de Edu. - **El misterio de las pruebas que se lanzaban solas**: era un vigilante antiguo del servidor de operaciones que, desde julio, relanzaba todas las pruebas después de cada publicación. Por decisión de Edu, ahora las pruebas corren solas y una sola vez nada más publicar, y el vigilante solo actúa si GitHub falla. - **Método de trabajo**: el candado que revisa cada publicación miraba a veces el proyecto equivocado. Ya está corregido, y se comprobará en la próxima sesión. **Detalle técnico** - CreaRack Pro: #616 (1.164.1, logout con confirmación POST + botón de cuenta pausada), #617 (1.164.2, `signals.interface_errors` y los 4 contadores de interfaz en el fantasma), #618 (1.164.3, `base.js` focus sobre el documento), #619 (`ci.yml` con `push: main`, Regla 20), #620 (tests e2e: `gotoLoginPage`/`login` con `Retry-After`, interfaz actual, terminal solo con sus errores). E2E 20/20: run 36173562725. - Workspace: #190 (guion A2-13: bienvenida hecha + `E2E-Fixture-Rack`), #191 (watchdog solo Pro + `AUTOMATISMOS.md` + nota wiki IA Tech). OPS: `watchdog.sh` nuevo (copia `.bak-20260925`), `kestrelmoor-ghost` reiniciado. - claude-method #27 (method-hooks 0.6.2: `repoFlagOf`/`repoFromPrUrl`, simulacro §3b; tag `pre-mergeguard-repo-2026-09-25`). - Gestor: #347 y #377 cerradas; #378 en curso (verificar en sesión viva); comentarios en #373. Mega-auditoría: A2-13 entero (T44 ✅).

la revisión grande de ayer queda resuelta: casi nueve de cada diez problemas arreglados y en producción, y el resto apuntado con dueño y fecha

ayer una revisión automática encontró 216 problemas en CreaRack Pro y se arregló una primera tanda. Hoy se ha seguido hasta el final. En cinco entregas, publicadas y comprobadas una a una, han salido 189 arreglos, el 87,5 %. Varios los nota quien usa la aplicación: - **Gráficas del Observatory**: las de latencia y la matriz de disponibilidad, rotas desde principios de mes, vuelven a verse. - **Actualizaciones sin Ctrl+F5**: tras cada actualización, el navegador carga solo el código nuevo, sin forzar la recarga. - **Botones del tablero de racks**: dicen lo que hacen ("Delete", "Clone") en vez de mostrar iconos. - **Notas rápidas del Observatory**: si fallan al cargar, no se pueden sobrescribir por error. - **Escaneo de red**: avisa si el Agente local no contestó a una parte. - **Organizaciones suspendidas**: al suspender una, se desconectan al momento sus Agentes y sus usuarios. Por dentro: - **Seguridad**: los servidores de pruebas ya no tienen permisos de administrador ni pueden llegar a producción, y se cerraron varios huecos de seguridad pequeños. - **Vigilancia nueva**: un aviso salta si el proceso que hace las tareas automáticas se para. Se probó parándolo a propósito, y el aviso llegó. - **Ayuda**: diecisiete páginas de ayuda puestas al día. Al final del día Edu creó las contraseñas y salió también el portero de las métricas internas: ahora piden usuario y contraseña. Queda un arreglo preparado que espera su decisión: cómo reciben los Agentes de reserva la lista de equipos. Todo lo demás pendiente está en el Gestor: treinta tareas nuevas, cada una con dueño y fecha. **Detalle técnico** - CreaRack Pro: PR #607 (1.159.0, ronda 4), #608 (1.160.0, ronda 5, Agente 2.29.0 publicado en Hetzner), #609 (1.161.0, ronda 6), #610 (1.162.0, ronda 7: lista S, T34 huella en imports, T39, T12 imagen, CI sin sudo, matriz), #612 (1.163.0, ronda 8: B-31, B-62, flecos de seguridad, C2-03, C2-16, `.forgejo`), #613 (1.163.1, adopción de la base `1ac8bf96`, issue #611), #614 (1.164.0, ronda 9: B-45 vmauth), #615 (nota INFRA: `tailnet-vm`/`tailnet-pg` desactivados). - Servidores: OPS `ci-runner-egress.service` (iptables por usuario runner → PROD), `NOPASSWD` retirado de `runner`/`runner2` (copia en `/root/sudoers-backup-b44-20260925`), `kestrelmoor-ghost` reiniciado; PROD y STAGE vmalert reiniciado (6 reglas, `HueyWorkerStalled`); simulacro en STAGE (worker parado 12 min → alerta firing → recuperado). - Verificado en PROD: B-10 con correo real en Zoho, Web Vitals en `/metrics`, huella de estáticos en el navegador (76 JS con hash, 0 `?v=`, 0 duplicados), latido de Huey, migración `core.0036`, Agentes online. - Workspace: `mega-auditoria-2026-09/` (`ESTADO_RESOLUCION.md`, `TAREAS_PENDIENTES.md`, `pendientes/` con B-45, B-16 y el guion e2e, `hallazgos/S-verificacion-2026-09-25.md`); 17 páginas de ayuda `crearack--*`. Gestor: #347-#376 y comentarios en #164, #211, #307, #319, #323. - Maquinaria: unos 30 agentes Opus (constructores, refutadores, recuento) + 1 Sonnet (ayuda); los refutadores pararon 4 cambios con fallo real (B-16, estáticos, diseño, vmauth).

la revisión más grande hecha hasta ahora del producto, y sus arreglos en producción el mismo día

aprovechando que sobraba crédito de Claude, ocho revisores automáticos repasaron CreaRack Pro de arriba abajo en hora y media: las librerías que usa, la seguridad de todo lo que cambió desde agosto, la calidad del código, el rendimiento y si cada pantalla hace lo que la ayuda promete. Salieron 229 cosas mejorables, once de ellas graves. Las más importantes: cualquier usuario con cuenta podía descargar las copias de seguridad de cualquier cliente; la pantalla de usuarios dejaba dar más permisos de los propios; un Agente revocado seguía entrando por una puerta lateral; y se podían subir ficheros que el navegador ejecutaba. De las 45 tareas del plan, las 24 que no necesitaban decisión de Edu se construyeron, se revisaron por un segundo agente y se publicaron en producción a lo largo de la tarde en cuatro versiones (de la 1.154.0 a la 1.158.0), cada una comprobada en el servidor y en pantalla. Edu decidió además volver a exigir las pruebas en verde antes de cualquier cambio en la rama principal, algo que se había relajado en julio. Quedan 21 tareas que necesitan decisión (el Agente, el fichero de despliegue, los servicios de la VPN) y la publicación de la versión 2.29.0 del Agente. **Detalle técnico** - Workspace: `public/supercontext/mega-auditoria-2026-09/` (README estado, INFORME, PLAN_MEJORAS, hallazgos, briefs, motor `ejecutar-tandas.js`), WAGERS #30, PR #187 (wiki T43). - CreaRack Pro: PR #592 (1.154.0), #595 (T05), #603 (1.156.0, ronda 1), #604 (1.157.0, ronda 2), #605 (1.158.0, ronda 3), #606 (docs regla 20); tag `pre-mega-audit-2026-09-24`. Protección de `main`: checks Backend/Frontend obligatorios. - Maquinaria: 7 auditores + workflow de seguridad (138 agentes) + 24 constructores + unos 30 refutadores, todos Opus 5.5; unos 25 M de tokens de subagentes en total (medido por los workflows: 12,5 + 0,6 + 2,5 + 2,3 + 1,7 M, más los agentes sueltos). - Sin verificar: vmalert sin reiniciar en PROD; Agente 2.29.0 sin compilar.

guías para el equipo en el Workspace, y un día dedicado a que nadie pueda borrar lo importante por error

las presentaciones para Txell y Dani se rehicieron como guías de lectura, al estilo de la guía de bienvenida, y ahora viven en un apartado nuevo del Workspace llamado Guías, con un aviso en el Dashboard que invita a empezar por ahí. Hay seis: la bienvenida, la de Txell, la de Dani, cómo trabajamos, un ejemplo real de cómo tomamos una decisión y dónde probaremos los cambios cuando abramos al público. Después vino la seguridad: las copias de seguridad de producción, del Workspace y del servidor de código están ahora en un almacén de Hetzner que no deja borrarlas durante 30 días, ni siquiera con las llaves del equipo; la revisión automática de los domingos ya solo puede leer; una llave de Cloudflare que se creía de lectura podía cambiar el DNS de todas las webs y ahora solo lee, y se revocó otra que no se usaba. Por el camino aparecieron dos fallos que venían de antes y quedaron arreglados: la copia en Google Drive borraba cada semana las copias más nuevas, y la guía de recuperación buscaba las copias en carpetas equivocadas. Se revisaron también las instrucciones de Claude para el modelo nuevo y se aplicó un primer grupo de cambios. Lo que falta es ver las primeras pasadas automáticas reales, el lunes 28. **Detalle técnico** - Workspace: PR #185 (apartado Guías + aviso), #186 (guías del método, "¿Algo no cuadra?", informe storm), `c518cecb`, `3e7eeead`, `58182605`, `4a13b49d`, `34124947`, `f72f5d63`; wiki `feature--workspace--guias`. - claude-method: PR #20-#26 (normas de redacción, plantilla de guía, storm legible, ronda en solo lectura, self-harness tanda 7, auditoría lote 1). - CreaRack Pro: `94c97fa9` (RULES_DETAIL), `c913313e` (fable-handover). - Servidores: PROD (Object Lock, guardián de la ronda, rol `ronda_readonly`), STAGE (limpieza de disco, logrotate, `cron-dr-lock-sync.sh`, purga de Drive corregida). - Tareas nuevas: #339-#344.

el Correo del Workspace ya no pierde los avisos, la IA contesta limpio y la revisión automática deja de gastar en balde

la página de Correo del Workspace tenía un fallo que nadie veía: los avisos de "hay que hacer algo" desaparecían a la hora siguiente, aunque no se hubieran atendido, porque la página solo enseñaba la última revisión y la mayoría salen vacías. Ahora lo pendiente se queda en pantalla hasta pulsar "Hecho" o "Descartar". El chat del correo, que a veces contestaba con palabras repetidas o sin sentido, ahora responde limpio, directo y sin coletillas. Y la revisión automática, que arrancaba la IA cada hora aunque no hubiera correo nuevo (8 de cada 10 veces), ahora lo comprueba antes en unos segundos y solo la arranca si hay algo: probado en los perfiles de Edu, Dani y Txell. Además quedan preparadas las dos presentaciones para enseñar a Txell y a Dani su día a día con el Workspace, con capturas reales. Y de paso salieron dos fallos en CreaRack que llevaban meses escondidos: los tableros de SAI y de cartelería enseñaban en su anillo de salud unos valores de relleno (batería al 100 %, carga al 0 %, memoria en blanco o a cero) en vez de los datos reales. Ya están corregidos y comprobados en pantalla. **Detalle técnico** - Workspace: PR #181 (pendientes + Hecho/Descartar, migración 0055), #182/#183 (Gemma `temperature 0.3` + prompt), #184 (`GET /api/correo/novedades`), `6d9b2749` (seed de migraciones). - claude-method: PR #19 `5943736` (`correo-pass.ps1` con comprobación previa; tag `pre-correo-precheck-2026-09-23`). Task #338 en curso. - Holded: causa del "0 cobrado" apuntada en la task #330 (se arregla cuando Txell configure la contabilidad). - Presentaciones: `C:/dev/miscelanea/txell/` y `C:/dev/miscelanea/dani/`. - CreaRack Pro: PR #589 (v1.153.1, `extractDeepMetric` lee el campo plano), #590 (v1.153.2, ids de memoria de cartelería + test de contrato JS↔plantilla), #591 (v1.153.3, memoria en porcentaje `_statusMem`).

las copias de seguridad de la memoria de Dani llevaban dos semanas sin subir, y ya suben

al revisar que el perfil de Dani estaba al día (lo estaba), salió que sus copias de seguridad de la memoria de Claude no llegaban a GitHub desde el 7 de septiembre: se guardaban solo en el ordenador compartido. La culpa era de unos archivos de Edu con nombres tan largos que Windows no los admite por defecto; al tropezar con ellos, la copia se paraba sin decir nada claro. Ya está arreglado: las copias atrasadas están subidas, el ordenador acepta nombres largos y el programa de copias ahora avisa en el momento si algo le impide subir. El cambio llega solo a Edu y Txell. **Detalle técnico** - claude-method: PR #17 (`296605d`) `harness/claude-backup.ps1` +17/−3: `git config core.longpaths true` antes del pull (backup y `-Restore -FromGit`) y la salida del `pull --rebase` ya no va a `Out-Null`. - claude-backups en la estación: `core.longpaths true`, rebase de 7 commits sobre 53, push verificado (`4bc18b3`). - Doctor del perfil `dani`: VERDE.

las copias de seguridad de la memoria de Txell volvían a no subir desde hacía dos semanas, y ya suben

el repaso del método ha salido perfecto, pero al arrancar asomó un aviso: las copias de seguridad de la memoria de Claude en el perfil de Txell llevaban desde el 8 de septiembre sin llegar a internet. Se quedaban solo en el ordenador. La causa era una carpeta de Edu con un nombre tan largo que Windows se negaba a crearla, y eso atascaba la actualización entera. Se ha activado el permiso de nombres largos en ese repositorio y todo ha quedado al día, sin perder nada. Dani se había encontrado lo mismo esta mañana y ya tenía el arreglo preparado para todos; hemos añadido a su propuesta que a Txell también le pasaba, para que Edu la apruebe. Además, Claude ya puede hacer esta sincronización solo cuando haga falta, sin pedir permiso cada vez. **Detalle técnico** - `claude-backups` de Txell: `core.longpaths true`, `pull --rebase` y `push`. Local = remoto = `d3249bd`. - claude-method PR #17 (Dani, `dani/backup-longpaths`): comentario con la prueba de Txell y aviso a Edu. Pendiente de merge, anotado en NEXT. - `~/.claude/settings.json` de Txell: `autoMode.allow` con el permiso permanente de sincronizar `claude-backups`. - Memoria: `footguns_claude_backups_rutas_largas_windows`.

estreno del modelo nuevo: el icono de Claude arranca directo, sin preguntar, y las normas de trabajo se ponen al día

hoy Edu ha empezado a trabajar con un modelo nuevo de Claude, Opus 5.5, y ha decidido quedarse solo con él. El icono del escritorio ya no enseña el menú para elegir modelo: arranca directo con Opus 5.5. Después revisamos el conjunto de normas y avisos con el que trabaja Claude en la casa. Todo carga y funciona, pero varias partes seguían dando por hecho que mandaba el modelo anterior, Fable. Ya están al día: los ayudantes que Claude lanza para revisar trabajo usan ahora el mismo Opus 5.5, el más caro de todos (Fable) sigue prohibido para ellos, y el repaso automático del ordenador compartido también pasa a Opus 5.5. Dani y Txell reciben los cambios solos en su próximo arranque. Queda por ver esta semana si el modelo nuevo gasta la cuota más deprisa. **Detalle técnico** - CreaRack-Pro: #588 (`c4ef87fa`) `scripts/windows/claude-launch.ps1` sin menú (`-Mode` por defecto `opus55`) + `install-claude-shortcut.ps1`; `0fa1263f` regla 10 "nunca Fable" en `CLAUDE.md` y `context/RULES_DETAIL.md`, nota de revisión en `.claude/rules/fable-handover.md`, CHANGELOG. - claude-method: PR #15 (`7419c5c`, tag previo `pre-opus55-adaptacion-2026-09-23`): `harness/ronda-pass.ps1` a `claude-opus-5-5`, `plugins/crearack/harness/guarda_modelo_subagentes.py` y `harness/method-doctor.ps1` sin suponer Fable, `global-output-styles/companero.md`. `gate_selftest` 18/18. Candado 0.6.1 verificado (merge sin CI sin bloqueo). - Perfil de Edu: `advisorModel: "fable"` retirado (Edu con `!`; copia `~/.claude/settings.json.bak-pre-opus55-2026-09-23`). - Dato: alias `opus` = `claude-opus-5-5` (docs model-config de Claude Code). - Memorias: `reference_fable_guardrails_switch_model_security_work` (histórica), `project_adaptacion_harness_fable51` (cerrada por relevo), MEMORY.md.

el ordenador que trabaja solo llevaba dos días parado sin que nadie se enterase, y ahora avisa; además, informe con máximos y mínimos y un nuevo modelo de IA estudiado

el día empezó con una lista de 23 tareas atrasadas y una idea de investigación, y acabó destapando un fallo serio y silencioso. El ordenador compartido que hace los trabajos automáticos (repasar el correo de los tres, documentar los cambios del programa, revisar la ayuda) llevaba desde el sábado por la mañana sin poder hacer nada: las sesiones con las que entra en Claude habían caducado en los tres perfiles a la vez, y ningún aviso saltó. Edu lo arregló con una clave de un año en cada perfil, y ahora hay un vigilante que, si una tarea automática falla tres veces seguidas, abre una tarea en el Gestor para que se vea al día siguiente. También apareció el porqué de que ese ordenador no se actualizara solo desde hace nueve días: una revisión del domingo dejó un fichero tocado y el actualizador se negaba a seguir; queda un último paso de Edu para dejarlo cerrado. De las 23 tareas atrasadas, 13 son decisiones de negocio y esperan a que vuelvan Dani y Txell; cuatro se cerraron y el resto tienen fecha realista. El mapa de arquitectura del programa se regeneró en las cinco piezas que estaban desfasadas, y al meterlo en el buscador se descubrió y arregló un fallo del indexado nocturno que llevaba dos noches fallando. El informe de un aparato, cuyo PDF Edu revisó y aprobó, muestra ahora bajo cada gráfica sus tres valores más altos y más bajos con la hora. Y se estudió Jev, un nuevo tipo de inteligencia artificial que solo decide y no escribe: vale para las decisiones pequeñas y repetidas del Bibliotecario, no para el producto, y se probará cuando su fabricante admita el registro. **Detalle técnico** - CreaRack-Pro: v1.153.0 (#586, `6ca31270`): `MonitoringReport.js::_extremesHtml`, `components.css`, i18n `Highest`/`Lowest`, `?v=` de los importadores; PDF de v1.152.0 verificado por Edu (`PRINT_CHART_PX`). Pantalla sin ver (pestaña de Edge oculta). Task #337 (cursor sincronizado). - Workspace: Atlas 5 fichas + 3 derivadas (`3fb1cc14`, 13 agentes, 2,65 M tokens); `scripts/_lib/chunk_batches.mjs` + `test/chunk-batches.test.ts` (#179 `fc4f0033`, #180 `c62ec19a`: bge-m3 cobra el lote por relleno máx × nº); reindex `supercontext` de OPS OK; onboarding 7.4 (token de un año) + evaluación Jev (`a69d1aa8`); ayuda WiFi/SAI/Signage (`55f6236d`); dos páginas gemelas del ingest archivadas. - claude-method: PR #12 (`64800c2`, ingest con tope de 6 commits + START), PR #13 (`f62b4a2`, `harness/pass-sensor.ps1` en 4 lanzadores + method-hooks 0.6.1), notas de la ronda rescatadas (`e47979c`), PR #14 abierto (`--autostash` en el sync; tag `pre-sync-autostash-2026-09-22`). Tags previos: `pre-ingest-pass-tope-2026-09-22`, `pre-pass-sensor-2026-09-22`. - Estación pc-ia-claude: IA-Edu 2.1.233 → 2.1.278; `CLAUDE_CODE_OAUTH_TOKEN` (un año) en los 3 perfiles (Edu por RDP); rollup verde ×4 a las 12:00; tarea Ingest deshabilitada/rehabilitada; claude-method allí sigue en `64800c2` hasta el pull manual. - Cloudflare: `minTLS` 1.2 en el dominio personalizado R2 `downloads.crearack.com` (#333); los 4 avisos de #186 ya no existían. - Gestor: cerradas #74, #186, #317, #333; nuevas #333, #334, #335, #337; 13 re-fechadas al 30-09; #68 → 21-12; #329 comentada (el detector la cierra). - Memorias: `reference_jev_typesafe_evaluation`, `footguns_r2_custom_domain_min_tls_aparte_de_la_zona`, `footguns_bge_m3_chunk_size_markdown_dense` (corregida), `project_proxmox_vms_dani_txell` (token de un año), índices.

papeles para las ayudas, una guía de bienvenida para Txell y Dani, y una presentación que hay que replantear

tarde de documentos, sin tocar el programa. Primero se rellenó el cuestionario técnico que pide la consultora para el plan de empresa de las ayudas públicas: dieciséis preguntas sobre cómo está hecho CreaRack, qué lo diferencia, cómo se protege y qué falta para venderlo. Queda en Word y pendiente de que Edu lo repase antes de enviarlo, porque dice con claridad que todavía no hay clientes de pago. Después se escribió una guía de bienvenida a CreaRack, corta y sin jerga, que Edu ya os ha enviado por WhatsApp. Lo tercero fue una presentación sobre cómo trabajamos con Claude, con voz incluida: está colgada en el Workspace, en Informes, pero a Edu no le convenció, porque tenía mucho texto y muchas palabras inventadas entre él y Claude que para los demás no significan nada. También se probó a conversar con Claude de viva voz y, aunque funciona, no resulta natural. Conclusión: la presentación la hará Edu en persona, con pantallas sencillas de imagen y una frase, y estará pensada para enseñar a trabajar en el Workspace con tareas reales de cada uno, no para explicar ideas. **Detalle técnico** - Workspace: `public/informes/presentaciones/metodo-claude-equipo-2026-09-21.html` + alta en `public/informes/index.json` (`b8b53ed0`, push directo, solo documentación). - Fuera de los repos, en `C:/dev/miscelanea`: `Cuestionario_inicial_tecnico_CreaRack_ESFERIC_LABS_RELLENADO.docx` y `.md` · `CreaRack_Guia_de_bienvenida_2026-09.html` · `Dossier_para_Claude_con_voz_2026-09.md` · `Muestra_pantalla_metodo.html`. - CreaRack-Pro y claude-method: sin cambios. Ninguna configuración tocada. - Memoria nueva: `feedback_material_para_equipo_visual_y_sin_apodos`.

los paneles generales también llegan a 30 días, el informe de un aparato se lee mucho mejor, y aparecen tres gráficas que llevaban meses vacías sin que nadie lo supiera

la mañana empezó mirando cuatro extras oficiales para Claude, el asistente con el que trabajamos. No instalamos ninguno, pero copiamos dos buenas ideas para revisar mejor el trabajo y creamos un "resumen del lunes" propio que juntará dinero, tareas, correo y servidores en una pantalla; se probará cuatro lunes y, si no sirve, se borra. Al probarlo salió que la conexión con Holded, el programa de facturas, leía mal los datos; está arreglada, aunque Holded sigue sin configurar y de eso se encargará Txell. Después, lo del programa: los paneles generales de WiFi, SAI y pantallas, y las vistas de grupo, ya tienen los botones de 7 y 30 días; antes se midió que sumar un mes entero de una sede grande tarda tres décimas de segundo. Al mirarlo en pantalla aparecieron tres gráficas que llevaban meses vacías por fallos nuestros, todas del mismo estilo: una parte del programa pedía un dato con un nombre y la otra lo guardaba con otro, y nada avisaba. Las tres están arregladas, con una comprobación automática para que no vuelva a pasar. Y a petición de Edu, el informe de un aparato se abre al doble de ancho, con una gráfica por línea y una gráfica nueva en WiFi que dice si el aire está saturado. Falta que Edu mire cómo queda impreso en PDF. **Detalle técnico** - CreaRack-Pro: v1.151.0 (#582, `b464d327`), v1.151.1 (#583, `3b7f5177`), v1.152.0 (#584, `48121802`), v1.152.1 (#585, `fdf291dc`, migración `network/0066`); docs `6a7d21b2`, `c3bb5bb6`. Tests nuevos: `dashboard_charts_field_contract.test.js`, `report_charts_key_contract.test.js`, `test_ups_input_frequency_and_output_current`. Suite estática 201. - Workspace: conector de Holded (`functions/api/mcp/handlers/holded.ts`, `test/holded-non-json.test.ts`, `dc24a8ca`, `f3d0c912`), ayuda de WiFi/SAI/pantallas (`7f651a01`, `3fe2ef3f`), página `ia-tech--metodo--plugins-oficiales-anthropic-2026-09` y apuesta #27 (`2290932d`), ficha WS5 del Atlas. - claude-method: `1578c0a`, `e221e58`, `92b5142`, `115f29c`; plugin `crearack` 2.4.0; tag `pre-plugins-oficiales-2026-09-21`. - OPS: fantasma de la demo actualizado y reiniciado (3.713 medidas por ciclo). - Gestor: tasks #330 (Holded), #331 (informe de pantallas), #332 (unidades de SAI in situ). - Medidas: 30 d de flota WiFi 0,28-0,45 s · ciclos commit→PROD de 9 a 18 min (7 de cola por runners ocupados).

las gráficas de un aparato ya se pueden ver a 7 y a 30 días

hasta hoy, al abrir un punto de acceso de WiFi, un SAI o una pantalla, sus gráficas solo llegaban a las últimas 24 horas. Ahora hay dos botones más, 7 días y 30 días, y al pasar el ratón por la gráfica se ve el día además de la hora. El informe de un aparato también llega a 30 días. Se ha comprobado en el programa de verdad, con la empresa inventada de demostración, que ya tiene dos meses de pasado: los 30 días se dibujan en menos de un segundo. De paso se ha arreglado un fallo antiguo: cuando llegaba una medida nueva, la gráfica de 24 horas se acortaba a unas 12 sin avisar. Queda una segunda parte: los tableros generales y las vistas de grupo siguen en 24 horas hasta medir cuánto le cuesta al servidor con una sede grande. También se midió cuánto tarda un cambio en llegar al programa: 20 minutos esta vez, 15 si no se pierde tiempo esperando un aviso; Claude había dicho 25-30 de memoria y Edu le corrigió con razón. **Detalle técnico**: CreaRack-Pro PR #581 (`9ff389c4`), v1.150.0 · nuevo `static/js/utils/chartTime.js` (~100 LOC) + `chart_time_ranges.test.js` (7 tests; suite estática 194 en verde) · tocados `MonitoringChartGrid`/`MonitoringChartPanel`/`MonitoringReport`, `WirelessChartPanel`/`WirelessExpertChart`/`ExpertChartHelpers`, `UpsDetailCharts`/`UpsDetail`, `SignageDetailCharts` + `?v=` en cadena en 27 módulos · `trimToWindow` sustituye al recorte por 360 puntos · `isLongRange` salta la recarga periódica en 7d/30d · 3 msgid en `djangojs.po` · ayuda: 3 páginas `crearack--*` · medido en PROD: 30d de un SAI = 1.441 puntos/gráfica en 0,3-0,9 s · ciclo: CI 7:26, merge→PROD ~3 min · memoria `feedback_ciclo_pr_tiempos_punta_a_punta` refrescada. Pendiente: entrega 2 (flota y grupos, midiendo antes), Observatory sin tocar.

la empresa de demostración ya tiene dos meses de pasado, y averiguamos por qué subir un cambio se hacía tan largo

la empresa inventada con la que enseñamos el programa llevaba un día encendida, así que sus gráficas solo tenían un día. Hoy se le han escrito los dos meses anteriores, con las mismas curvas que se ven en vivo (los turnos, los fines de semana, las averías programadas), para que pasado y presente encajen. Al mirarlo, Edu vio dos cosas: que las gráficas de tráfico de la WiFi y de las pantallas salían vacías (arreglado: ya dibujan) y que el programa no deja ver más de 24 horas en las gráficas; ha decidido que pueda enseñar 7 y 30 días, y eso queda para la próxima sesión. Además Edu pidió entender por qué subir un cambio tardaba más de lo que se le avisaba: las máquinas tardan lo de siempre, unos doce minutos; lo que se alargaba era lo de alrededor, sobre todo órdenes que se quedaban esperando un permiso sin que nadie lo viera. Se han corregido cuatro cosas; la comprobación automática ha bajado de ocho minutos a algo más de siete, menos de lo que Claude había prometido. **Detalle técnico**: PR #577 (`core/demo_org/history.py`, `seed_demo_org --backfill-metrics`, v1.149.0, +349 LOC) · PR #578 (tráfico de APs y pantallas en `signals.py`/`ghost_agent.py`, `--metrics`, v1.149.1) · PR #579-#580 (CI: `--store-durations`, artefactos, `.test_durations`, mypy a la shard 2, `ci.yml` dispara los tests) · PROD: 26,8 M de muestras en VictoriaMetrics para la organización 25, 0 rechazos, carga ≤0,7 · OPS: fantasma actualizado, 3.689 medidas por ciclo · plan `org-demo/PLAN_ORG_DEMO.md` actualizado · memoria compactada.

la empresa de demostración ya existe y está viva, y se arregla un fallo que llevaba diez semanas callado

la empresa inventada para enseñar el programa ya está dentro del programa de verdad. Se llama Kestrelmoor Group (los dos primeros nombres que pensamos eran de empresas reales). Tiene tres sedes, 80 armarios, más de 500 aparatos, 40 pantallas y su WiFi, todo inventado. Y se mueve sola: un programa pequeño en el servidor de operaciones manda cada minuto medidas inventadas con sentido, provoca alguna avería de vez en cuando y abre su incidencia con el diagnóstico de la inteligencia artificial, como mucho seis al día. Se entra con un único usuario de demostración, que sirve a los tres. Mientras la construíamos salió un fallo real: en una instalación muy grande, los cambios en la lista de aparatos no le llegaban al vigilante de la red hasta reiniciarlo, y nadie avisaba. Ya está arreglado con una versión nueva del vigilante, que se instaló sola. Y desde hoy las pruebas ya no se hacen en el portátil de Edu, que se quedaba sin memoria: las hace el servidor. **Detalle técnico**: 11 PR en CreaRack-Pro (#566-#576), v1.140.0 → v1.148.0, Agente 2.28.0 (Release `agent-v2.28.0`). Nuevo: `core/demo_org/` (7 módulos), comando `seed_demo_org`, `Organization.is_demo` (migración `0035`), `scripts/demo/ghost_agent.py` + `scenes.json`, ~70 tests. Arreglo #328: `terminal/consumers.py`, `terminal/fleet_lifecycle.py`, `terminal/agent/core/{auth,sentinel_runtime,saas_commands,sync}.py`, `WS_MAX_MESSAGE_BYTES`. OPS: `kestrelmoor-ghost.service`, apuntado en `AUTOMATISMOS.md` §4. Plan: `public/supercontext/org-demo/PLAN_ORG_DEMO.md`. Tasks: #328 cerrada, #327 en curso, #212 y #290 re-fechadas al 30-09.

una empresa inventada para enseñar el programa: plan aprobado

idea de Edu para poder enseñar el programa en vídeos y capturas sin enseñar datos de nadie: crear dentro del programa de verdad una empresa inventada y grande, Nordhaven Group, con un centro de datos, un recinto de eventos y un almacén (80 armarios y unos 450 aparatos). Se comprobó que se puede. Dibujar la instalación es lo fácil; para que las gráficas se muevan y haya averías que enseñar, un programita aparte hará de vigilante de red de mentira y mandará datos inventados por la misma puerta que el de verdad, con las averías escritas en un guion. De los datos reales del CCIB solo se copiará la forma, nunca el contenido, y un control automático comprobará que no se cuela ni un dato real. Hoy queda el plan escrito y aprobado; se empieza a construir mañana y las capturas se harán a partir de la semana del 21, sobre las pantallas nuevas. **Detalle técnico**: sesión de solo lectura sobre CreaRack-Pro (sin código ni PR). Plan `public/supercontext/org-demo/PLAN_ORG_DEMO.md` (F0-F6: comando `seed_demo_org`, fichas de inventario por molde, Agente fantasma en OPS contra `receive_bulk_metrics`, exclusión de avisos e informes, copia "estado dorado", guion de capturas). Task #327 (24-09), apuesta #26 (31-10). Hallazgos que condicionan el diseño: ventana de ingesta de 7 días (el histórico se escribe aparte con `MetricsWriter`), frescura de 120 s para el estado vivo, contrato cerrado de nombres de métrica, el servidor no sondea IPs privadas, `max_racks` por defecto 10.

se remata "fuera de servicio", los trabajos largos ya no pueden perderse al arrancar y cada gráfica de los tableros va en su propio recuadro

mañana de cerrar cabos. Se comprobó que el vigilante de la red ya se entera a la primera cuando guardas un equipo, y Edu guardó los cuatro puntos de acceso de refuerzo; esos equipos guardados ya no salen como averiados ni en los informes ni cuando le preguntas al asistente. Revisando el programa con la pista del fallo de ayer apareció lo mismo en ocho sitios: al pedir un trabajo largo (un Auto-Plan, una copia de seguridad, subir un vídeo) se avisaba al motor un instante antes de terminar de apuntarlo, y de vez en cuando el trabajo podía perderse sin avisar; ya no puede, y se vio funcionar con una copia de seguridad de verdad. A petición de Edu, las gráficas de los tableros de Wireless, UPS y cartelería dejaron de ir de dos en dos: cada una es ahora su propio recuadro, que se mueve, se estira o se esconde por separado, y lo que cada uno tenía maquetado se conserva. Por último, en cartelería un reproductor marcaba "un millón por ciento" de memoria (eran kilobytes con un % detrás) y el programa llamaba cada cuarto de hora a ese aparato por una red a la que no llega; las dos cosas quedan arregladas. También se cerró la tarea de separar Esferic Labs y el CCIB en dos organizaciones, que estaba hecha desde agosto. **Detalle técnico**: PRs #562 (v1.138.2), #563 (v1.138.3, 8 encolados Huey a `transaction.on_commit`, 18 tests adaptados sin tocar asserts), #564 (v1.139.0, `layoutSplit.js`, 11 tests vitest), #565 (v1.139.1, `memory_percent` + migración `signage/0019`). Verificado: aviso al Agente (127→126→123 SNMP), informes de flota y los tres tableros en pantalla, copia de seguridad real en 1,7 s, tarea de SpinetiX 10,8 s → 0,06 s. Tasks: #235 cerrada, #326 nueva, #302 al 25-09. Ayuda: workspace `7205cac0`, `96d95513`. Limpieza: 2 worktrees + 22 ramas locales.

el vigilante de la red deja de atascarse, botón "fuera de servicio" y los paneles comprobados en pantalla

se comprobó en pantalla lo que ayer salió sin mirar, y aparecieron cuatro fallos en las gráficas que se añaden a los paneles (nacían diminutas, cortadas o en blanco); quedaron arreglados, y los textos de personalizar los paneles ya salen en español. Se descubrió por qué el programa que vigila la red del CCIB parecía lento: no lo era, es que cuatro puntos de acceso guardados en la estantería hacían esperar a todos los demás cada cinco minutos. Se arregló, se publicó la versión nueva y se midió: ni una espera larga en hora y media. De ahí nació un botón nuevo en la ficha de cualquier equipo, "Take out of Service": el equipo se queda en la lista en gris, deja de dar alarmas y vuelve solo al servicio en cuanto se enchufa y contesta. Al probarlo se destapó un fallo antiguo — el vigilante se enteraba de cada cambio con uno de retraso — que también quedó corregido. Y se diagnosticó la wifi de la sala VIP del CCIB: el aparato está ajustado para cubrir demasiado y atiende a móviles de gente que ya no está en la sala. **Detalle técnico**: PRs #554 (v1.137.1), #555 (v1.137.2), #556 (v1.137.3), #557 + #558 (Agente 2.27.2, v1.137.4/.5), #559 (v1.137.6, i18n), #560 (v1.138.0, fuera de servicio, migración `monitoring/0035`), #561 (v1.138.1, `transaction.on_commit` en `terminal/agent_registry.py`). Release `agent-v2.27.2` (sha256 `6c417df9…b4e75`), publicado con guion + `!` por denegación del clasificador. Dos revisiones frías en `opus` antes de compilar/fusionar (7 correcciones aplicadas). Medida del Agente: inicios de tanda >90 s, 0 de 82 en 88 min. Ayuda: workspace `72e23220`, `9e9cf1da`, `9769b15c`. Tasks #322-#325. 6 fichas de memoria nuevas.

primer evento real en el CCIB, cinco versiones y el ciclo 2 de los paneles

Edu estuvo en el CCIB midiendo por primera vez un evento de verdad con CreaRack: 55 puntos de acceso y casi dos mil personas conectadas. Salieron dos fallos que eran nuestros y no de la red, y se arreglaron en el día: las gráficas de ancho de banda caían a cero cada cinco minutos porque solo sumábamos los últimos 90 segundos y el Agente tarda a veces más en recorrer 121 equipos; y las pantallas de cartelería se quedaban en negro porque la red que protege la web guardaba durante horas una copia vieja de lo que hay que reproducir. La lista de equipos del Observatory se aligeró diez veces. Los paneles ganaron el diseño por defecto de la organización, la disposición móvil y las gráficas configurables (estas dos últimas pendientes de ver en pantalla). Se investigaron las consolas modernas para modernizar la Terminal, con informe y plan en pausa hasta acabar los paneles. El método se revisó a sí mismo (tanda 4) y se apagó un extra de Cloudflare que costaba cinco dólares al mes sin uso. Txell: al volver, la facturación de todas las cuentas pasa a Esferic Labs (task #321). **Detalle técnico**: PRs #548 (v1.135.0), #549 (v1.135.1), #550 (v1.135.2), #551 (v1.135.3), #552 (v1.136.0) mergeados; PR-3 (v1.137.0, rama `edu/dashboard-chart-instances`) al estibador al cierre. `claude-method` `71ada37` (tanda 4) y `f9d46c8` (cherry-picks). Regla de caché Cloudflare bypass `/publish/*`. Informe del evento en `public/supercontext/reports/evento-eurofinance-2026-09-16.md`; storm en `public/informes/storm/consolas-ssh-terminal-2026-2026-09-16.html`. Tasks #319, #320, #321; apuestas #15 PARCIAL, #16 superseded, #25 nueva.

El fichero de presentación del proyecto vuelve a explicar qué es CreaRack, y los paneles de las cuatro pantallas de monitorización se personalizan sin sustos

dos cosas. La presentación del proyecto en GitHub se había convertido en una lista de cambios sin fin; ahora cuenta en lenguaje llano para qué sirve CreaRack, qué módulos tiene, cómo está construido y cómo arrancarlo. Y los paneles de widgets de Observatory, Wireless, UPS y Signage estrenan un botón **Customize**: por defecto están bloqueados (nada se mueve sin querer); al pulsarlo se pueden mover y estirar con tiradores visibles, ocultar los widgets que no interesan y recuperarlos, volver a la disposición de fábrica, y guardar con **Done** o deshacer con **Cancel**. La disposición es de cada persona y te sigue a cualquier navegador; en una tablet en vertical los widgets se apilan solos. Un fallo apareció nada más desplegar (los botones de edición se veían siempre) y quedó corregido en veinte minutos. Edu comprobó Observatory al cerrar, incluida la pantalla en vertical, y pide como siguiente paso widgets configurables, un diseño por defecto para toda la organización y disposiciones distintas según el tamaño de pantalla. **Detalle técnico**: README `697365a1` (715 → 180 líneas) · PR #545 v1.133.0 (base `MonitoringDashboard.js` + mixin `DashboardCustomize.js`, GridStack 12.4.2 → 13.3.0, 7 tests vitest) · PR #546 v1.133.1 (`.overview-header-actions [hidden]`) · PR #547 v1.134.0 (Observatory sobre el mixin, `overview-layout` por usuario con fallback, `test_overview_layout_per_user.py`) · ayuda de usuario de los 4 dashboards + `crearack-tech--architecture--valkey-persistence` · apuesta #24 · task #318 (comprobación en pantalla de Observatory).

La ronda del 13-09 liquidada entera: pantallas fantasma, correos falsos del Sentinel, marcador de salud honesto, Ayuda sin inventar y alarmas que vuelven a poder sonar

los cinco defectos que la revisión automática de producción encontró el sábado quedaron corregidos y desplegados hoy. La página de cartelería dejará de listar 104 pantallas que no existen (llegaron con una restauración de agosto; una copia restaurada ya no mete aparatos sin identificar en las páginas de producto y hay un comando de limpieza que lanza Edu). Se acaban los 57 correos semanales de "la vigilancia se ha mudado de máquina" cuando era la misma máquina volviendo tras un corte de wifi. Con el ordenador que vigila la red apagado, el marcador de salud del Observatory y la Ayuda ya no dan cifras de hace horas como si fueran de ahora: dicen "sin datos recientes". Y dos de las cinco alarmas internas que avisan de lentitud o fallos de base de datos, que llevaban meses sin poder sonar, vuelven a estar en guardia, con un test que lo impide y un chequeo diario en el servidor de mantenimiento que avisa por correo si se repite (probado provocando el fallo). Además, la vuelta de Dani y Txell se retrasa a finales de mes y sus tareas se han movido al día 30. **Detalle técnico**: v1.132.10 PR #540 (#305: `is_unverified_ping_only`, guarda en `restore.py`, comando `unassign_ghost_profiles`) · v1.132.11 PR #541 (#304: `from_agent_id` en `auto_assign`, correo solo si otra máquina) · v1.132.12 PR #542 (#303: `status_effective` en rankings/overview, `healthMetrics.js`, `?v=17`) · v1.132.13 PR #543 (#309: Informante con "sin dato reciente", aviso sin `role=primary`) · v1.132.14 PR #544 (#310: `alerts.yml` + ENGINE instrumentado + test de contrato) · OPS: `/opt/alertas-ciegas/alertas-ciegas-check.sh` (workspace `5476888c`, cron 06:45 UTC, heartbeat) con simulacro verificado en infra@ · apuesta #3 HIT · task #317 · 4 páginas de ayuda + 2 wikis técnicas. Pendiente de Edu con `!`: limpieza en PROD, reinicio de vmalert y las sondas de las cinco tareas.

Seis versiones en un día: la Ayuda en español vuelve, los grupos ganan botonera e informe, la IP se cambia desde la ficha y el escaneo reconoce los equipos por MAC

por la mañana se reiniciaron los dos servidores que lo pedían y se arregló la Ayuda en español, que llevaba trece días sin abrir ningún artículo. Después Edu pidió tres mejoras y las tres quedaron en producción el mismo día: los paneles de grupo de Wireless, UPS y Signage tienen ahora los mismos botones que un equipo suelto; la dirección IP de un equipo se cambia desde su ficha y se actualiza a la vez en todos los sitios donde vivía; y el escaneo de la red reconoce a cada equipo por su MAC, así que un equipo que cambia de IP ya no sale duplicado. Un escaneo completo del CCIB lo confirmó: 120 equipos actualizados, ninguno duplicado. Por la tarde, dos remates: el escaneo ya no lanza cien lecturas a la vez al programa de la oficina sino una cola ordenada de tres en tres, y cada grupo tiene su propio informe (y el informe de flota de los SAI, que salía vacío, vuelve a tener filas). **Detalle técnico**: v1.132.3 PR #533 (`_HELP_ARTICLE_RE` + `wiki-es/`, test de contrato EN/ES) · v1.132.4 PR #534 (`MonitoringGroupDetail.js` botonera; plumbing del deep discover como funciones de módulo) · v1.132.5 PR #535 (`readdress.py::change_profile_ip`, `PATCH /auto-provision/profiles/{id}/ip`, campo IP en `device_card_editor.js`) · v1.132.6 PR #536 (`rescan_hooks.py`, `mac_identity.py`, `deep_discovery_dispatch.py`) · v1.132.7 PR #537 (MAC en dos IP fichadas = silencio) · v1.132.8 PR #538 (`collect_auto_deep_discover` + `dispatch_deep_discovery_batch`, `last_batch`, `max_concurrent=3`) · v1.132.9 PR #539 (`fleet-report?group_id`, `resolve_report_group`, botón Report; `UpsReport.fleetListKey`) · ~90 tests nuevos entre pytest y vitest · ayuda de usuario en 4 páginas (workspace `935ab047`, `7d13faed`) · tasks #308, #312-#316 cerradas · fichas nuevas: `footguns_frontend_tests_biome_config_frontend_no_raiz`, `feedback_navegador_pestana_logueada_no_cerrar`.

El Oráculo deja de atascarse: el buscador acertaba y quien fallaba era la redacción; pasa a Gemini 3.8 Flash

el asistente de preguntas del workspace se atascaba en la mitad de las preguntas: más de veinte segundos y un aviso de "tu pregunta es muy amplia", o una respuesta cortada a media frase. Se sospechaba del buscador nuevo del viernes, pero medido con las mismas preguntas con y sin él fallaba igual: la causa era el modelo que redacta, que se ponía a repetir la misma palabra hasta agotar el espacio. Se probaron varios modelos con las mismas preguntas, incluidas las tres que hizo Edu esta mañana, y Edu decidió pasar el Oráculo a un modelo de Google de más calidad: responde limpio en dos o tres segundos y, por lo poco que se usa, cuesta céntimos al mes. Solo cambia el Oráculo; la ayuda de la app y el chat del Correo siguen igual. Ya está en producción y comprobado. De paso, una pregunta de seguimiento ("para qué se utiliza") ya busca teniendo en cuenta de qué se hablaba, y la apuesta del buscador de texto completo queda como acierto: las tres preguntas reales de Edu encontraron su página. **Detalle técnico**: A/B híbrido vs `"hybrid": false` (5×2 en PROD: fallback 5/10 vs 4/10) · reproducción local con el prompt real: `gemma-4-26b-a4b-it` 0/20, `gemma-4-31b-it` 13/13, `gemini-3.1-flash-lite` 8/8, `gemini-3.8-flash` low 8/8 · workspace PR #178 `042596fd` (`SynthesisOptions`/`synthesisGenerationConfig` + test, `oracleSynthesis(env)`, `ORACLE_SYNTHESIS_MODEL`, retrieval de seguimientos con el último turno, wiki `decision--20260913--oraculo-gemini-38-flash`, front-matter de `entity--workspace--endpoint--oraculo-ask`, ficha Atlas WS2, Regla 8) · Pro `360f0e82` (`ai-models.md`) · verificado en PROD por API y en pantalla · memoria `footguns_gemini_model` reescrita · apuesta #22 HIT en WAGERS.

El Oráculo encuentra también los términos exactos, producción vuelve a verde tras el reinicio y dos redes nuevas contra los fallos de la IA y del robot documentador

el asistente de preguntas del workspace buscaba solo por parecido de significado y se le escapaban las páginas cuando preguntabas por el nombre exacto de un fichero o un servicio. Desde hoy mezcla las dos formas de buscar, y una página que contenga el término aparece entre las fuentes: con las mismas 60 páginas, por título pasa de 3 de cada 4 a 9 de cada 10, por una frase literal de 3 de cada 10 a 3 de cada 4, y por un identificador de 1 de cada 4 a 3 de cada 4. Por la tarde el panel puso producción en rojo: la web de los clientes siguió bien, lo que fallaba era la vista interna que la sonda comprueba por la red privada, porque el reinicio de la mañana borró una regla del cortafuegos puesta a mano en agosto. Edu la volvió a poner donde sobrevive a reinicios y la sonda confirmó la recuperación por correo. Además: el robot que documenta los cambios dejó dos páginas de la wiki reducidas a una línea de código (restauradas, y corregido para que no se repita), y el chat del Correo se puso a repetir una palabra sin fin (ahora se corta solo y avisa). **Detalle técnico**: workspace PR #172 `4a80cc7a` (`functions/_lib/retrieval-hybrid.ts`: `searchHybrid`/`rrfFuse`/`ftsHitsToChunks`; `search.ts` `queryTerms`/`buildOrMatchQuery`/`fetchSearchDocs`; `ask.ts` y `bib_search_semantic`; `RETRIEVAL_HYBRID`; `scripts/bench-oraculo.mjs`; tests) · #173 `454db826` (reutiliza el trozo semántico, fragmento anclado en el término más largo, docs) · #174 `c9f3249a` (`rareTerms` ≤ 5 %, título ×3, `"hybrid": false`; restauración de las 2 páginas rotas por el Ingest `c180252d`/`668a702f`) · #175 `7777cb1f` (`crud.ts` `looksLikeSerializedMetadata` rescata patches mixtos serializados; test de regresión) · #176 `5de9c1c8` (específicos si los hay, todas si no) · #177 (`clampSubstringRepetition`; el chat del Correo rescata `answer` y devuelve `degraded`). Batería (60 páginas, `top_k` 8): 75/30/28 → 93/75/77 %, p50 306 → 438 ms. PROD: regla `-s 100.64.0.0/10 --dport 8000 ACCEPT` en `/root/restore-firewall.sh` (línea 22, copia `.bak-20260911`), aplicada por Edu con `!`; sonda 12/12 a las 21:00; alerta #16 cerrada; ficha `footguns_prod_restore_firewall_reglas_a_mano_se_pierden`. Apuesta #22 INSUFICIENTE → 25-09 (faltan las 3 búsquedas reales). Fable 5.1.

La búsqueda de las wikis ya encuentra lo que existe, las migraciones dejan de aplicarse a mano y los cuatro servidores reiniciados

la cajita de búsqueda del workspace solo miraba el principio de cada página y se dejaba fuera la mitad del texto. Desde hoy busca en el cuerpo entero de las 1.271 páginas de las wikis, en el diario de trabajo y en los cuadernos de bitácora, agrupa los resultados por wiki y enseña el trocito donde aparece lo buscado; con 120 páginas al azar acierta casi siempre donde antes fallaba una de cada seis veces. Al estrenarla apareció un problema viejo: la base de datos tenía desordenado su registro de cambios de estructura y el cambio nuevo no entró a la primera. Se ordenó con Edu al lado y, para que no se repita, esos cambios los aplica ahora el propio despliegue automático, con un freno que lo para todo y avisa por correo si el registro se desordena. Un aviso de "hace falta reiniciar" en el servidor de tareas destapó que los cuatro servidores llevaban entre tres semanas y cinco meses sin reiniciarse tras actualizaciones de seguridad: se reiniciaron uno a uno, ensayando en el de pruebas antes que en producción y comprobando que todo volvía, y el informe automático del lunes dirá a partir de ahora qué servidor pide reinicio. **Detalle técnico**: workspace PR #170 `49217dcc` + `a7d78810` (migración `0054_search_fts.sql`, `functions/_lib/search.ts`, `GET /api/search`, tool `bib_index_search`, `scripts/index-search.mjs`, modo `search` de `cron-bib-reindex-ws.sh`, `SearchInline.tsx` sin Fuse, `test/integration/search.test.ts` 9/9, `scripts/bench-search.mjs` 97/99/99/100 %, p50 87 ms; retirados `fuse.js`/`build-search-index.mjs`/`search-index.json`/`SearchDialog.tsx`) · PR #171 `e7b3f1dd` (`scripts/ops/cf-pages-deploy/cf-pages-deploy.sh` con `migrate_d1` + candado + email; `CLOUDFLARE_D1_TOKEN` en OPS; Regla 20; `seed-d1-migrations.sql` hasta 0054; ficha `footguns_d1_migrations_untracked`) · `a5c1840f` (`@@reboot` en `snippet.sh` + `reboots()` en `stack_inventario.py`, simulacro en STAGE; llave restringida instalada en OPS) · reinicios OPS/DCA/STAGE por SSH y PROD por `!` de Edu, kernels `7.0.0-31` y `6.8.0-139` · cron `search` en `/etc/cron.d/bib-reindex-ws` · apuesta #23 · wiki `feature--workspace--busqueda-texto-completo`, `ia-tech--automatismos--metodo--cf-pages-deploy`, `workspace-tech--bd--tecnico`, `crearack-tech--guides--inventario-de-secretos`.

Tres investigaciones: del hilo de Reddit salen tres mejoras y una deuda cerrada; los otros dos, no

sesión corta de mañana para mirar tres hallazgos de Edu. Un hilo de Reddit sobre cómo organiza su trabajo un desarrollador que usa agentes: sus programas no nos sirven, pero su manera de ordenar los planes sí, y se adoptó en el momento: la carpeta de planes del Supercontexto tiene un índice que dice qué está vivo, aparcado o retirado, tres iniciativas cerradas hace meses pasaron al archivo, los planes nuevos salen de una plantilla cuyo primer párrafo es el estado de hoy, y hay una tarea para probar una herramienta de diseño antes de la fase de interfaz de la semana del 21. También se guardó en el repositorio un guion que arregla las notas de versión duplicadas y que vivía en una carpeta temporal. Un complemento que abre una ventana de terminal con menús: no, ya lo tenemos. Un grabador de pantalla para vídeos de demostración: buen precio, pero solo para Mac; la ayuda visual de la app se hará con una organización de demostración con datos inventados y capturas por guion, después de la fase de interfaz. Las 29 tareas vencidas del tablero se movieron al 21 de septiembre para repasarlas con Dani y Txell. **Detalle técnico**: workspace `f6f32274` (`public/supercontext/README.md` + `ficha-central/`, `auditoria-s187/`, `full-local-agent/` → `archive/supercontext/`) · claude-method `3827d83`, tag `pre-reddit-solo-dev-2026-09-11` (`templates/PLAN.md.template`, `AGENT_BRIEF.md` campo 8, `DESIGN_TOOLKIT.md` §10 pen.dev, README) · task #302 (pen.dev, 18-09) · Pro PR #532 `a14a7ee9` (`scripts/ci/dedupe_docs.py`, sin cambio de versión) · memorias `reference_reddit_solo_dev_runner_evaluation`, `reference_claude_canvas_evaluation`, `reference_shotglass_evaluation` · 29 tareas del Gestor al 21-09 · ramas de Pro con PR mergeado por squash pendientes de `git branch -D` por Edu.

La lista de deuda técnica cerrada, los avisos automáticos que ya no se pierden, y una tarde de I+D

por la tarde se cerró la lista de deuda técnica de agosto: Edu tomó las cuatro decisiones que faltaban (cuándo cuidar el aspecto de las pantallas, cómo subir la exigencia del corrector del código del navegador, qué espera a las llamadas comerciales, y cuándo ensayar separar Esferic y CCIB en dos organizaciones) y se regeneró entero el Atlas de arquitectura, con más de mil afirmaciones comprobadas contra el código y casi cuatrocientas corregidas. Luego se arregló algo que venía de lejos: los avisos automáticos con fecha se abrían donde nadie miraba y morían; ahora aparecen como tareas en el tablero, se cierran solas cuando el problema desaparece, y cada sesión ve al arrancar las tareas vencidas. El corrector del JavaScript pasó de 2 reglas a unas 150 sin romper nada. Una sesión de preguntas sobre por qué cuesta encontrar documentos en las wikis (son 1.269 páginas) acabó en un plan con luz verde para mañana: búsqueda de texto completo que garantice que si una palabra está en una página, la página aparece. Y de I+D: cinco ideas de un competidor de documentación de cableado para el plan de DCIM (en espera) y su dato de precio para la próxima reunión, el aviso de velocidad de Cloudflare (se deja como está, a propósito), y tres piezas adoptadas de hallazgos de Edu: un traspaso de emergencia cuando se corta la sesión, una tabla de cuánta maquinaria merece cada cambio, y un pitido cuando la sesión se para o pide permiso. **Detalle técnico**: task #274 cerrada (#211 → 21-09, #235 → 18-09, #268 → 15-10) · Atlas: workflow `atlas-regen` (33 agentes sonnet/opus, 7,1 M tokens, 47 min), workspace `188f5d67`, re-ingesta en OPS 118 chunks · blindaje: claude-method `12c3318` (vencimientos en el arranque), workspace `8c05aec4` (atlas-check y cron mensual → Gestor), Pro PR #530 `c0664364` (audit-docs-drift → Gestor, Regla 19) + README `9cc97aaf`, tareas #299/#300 abiertas y cerradas solas, 6 issues cerrados · lint tanda 0: Pro PR #531 `ec2227e3` v1.132.2 (biome recommended, 21 reglas off, `qr-code-styling` excluido y en licencias) · hallazgos Atlas: workspace PR #169 `b7bfcf74` (gate readonly + test de aptitud; coste de `wiki_enrich_related` en `bib_wiki_log`) · grill: draft `decision--20260910--busqueda-texto-completo-wikis`, apuesta #22 · Patch Manager: `dcim-cpd/PLAN_IDEAS_PATCHMANAGER.md` `fc2f03ba`, task #301 · claude-method `bc0d7d4` (checkpoint.ps1 + `/method:checkpoint`, niveles N0-N3, method 3.6.0). ~15 M tokens de subagentes en total (Atlas 7,1 M).

El mapa vivo de todos los servicios que sostienen a CreaRack, y la red privada con reglas finas

por la mañana se cerraron flecos del taller (el chequeo de salud del método, una corrección de una palabra al sincronizador) y se puso al día la lista de deuda técnica de agosto: casi todo estaba ya resuelto sin que la tarea lo reflejara, y lo único real se arregló y salió a producción sin cambio visible. La red privada del equipo pasó a tener reglas finas y verificadas: cada ordenador solo abre hacia los servidores los puertos que usa; de paso, el cortafuegos del panel de despliegues quedó igual en producción y en pruebas, y escrito para sobrevivir a un reinicio. Por la tarde, la idea de Edu: un mapa único y vivo de todos los servicios de los que depende el proyecto. Hay plan en tres tiempos y el primero está hecho: en la wiki del equipo, sección infraestructura, dos páginas nuevas (la corta "Empieza aquí" y el catálogo completo con 30 servicios, qué pasa si cae cada uno, quién lo paga, qué caduca, y un mapa que se entiende). Y lo importante: cada lunes un inventario automático compara el mapa con la realidad y avisa por correo si algo cambia; el primer correo ya llegó. Para Txell: falta media hora entre Edu y tú con los paneles de facturación (Zoho, Holded, las suscripciones de Claude, Google) para completar los costes. **Detalle técnico**: CreaRack-Pro PR #529 → `dade9cfd` v1.132.1 (remate B1 del #274: `getTimeRange` muerta, 3 `catch {}` avisan, `?v=` subidos). Workspace: `stack-servicios/PLAN_STACK_SERVICIOS.md` (task #298), `scripts/ops/stack-inventario/` (Python stdlib; NetBird/CF/GitHub/Hetzner/SSH con llave restringida/compose/TLS; `--compare` + `--alert` vía `send_maintenance_email`), catálogo `entity--ops--catalogo-servicios-externos` + `workspace--infra--stack-de-servicios`, `AUTOMATISMOS.md`, `heartbeat.sh`, verificación de los 29 candidatos, apuesta #21; commits `489bfc85`…`4eeb71c` + cierre. claude-method `acce5c8` (P11 `-uno`) + guía NetBird (`44370c5`, `a878320`). OPS: `/opt/stack-inventario/` (cron lunes 06:30 UTC, heartbeat 200 h) y `/opt/nb-inventario/` (LOG `NBINV` en `wt0`, lectura 17-09). NetBird: 6 políticas activas, ancha y Default desactivadas; token API usuario de servicio `claude-method`. Pendiente: tiempo 2 (storm→roast, D1-D5), fase 2 NetBird el 17-09, paneles de facturación, tokens de lectura para completar el inventario.

Tres arreglos de la maquinaria de Claude y el reproductor de casa en la red privada, aislado de verdad

sesión de taller y de red, sin tocar el producto, hecha a cuatro manos con la sesión de Claude del proyecto de música de Edu, Play.Moode. Tres arreglos de la maquinaria de Claude: el aviso de "no he podido actualizarme" ahora dice la causa real cuando otra sesión tiene cambios a medias; un limpiador que en vez de limpiar dejaba un residuo vacío en Windows (y lo creaba él mismo) ya borra de verdad y lo comprueba; y la opción "ahorro" del acceso directo, que decía "sin asesor" mientras el asesor Fable seguía encendido y cobrando, ya lo apaga. En la red privada del equipo entra el reproductor de música de Edu, el Raspberry, en un grupo aparte al que solo llegan su portátil, su móvil y la estación; para eso se apagó por fin la regla de fábrica de "todo con todo", pendiente desde mayo, sustituida por otra que deja a las personas y a los servidores exactamente como estaban. Comprobado desde los dos lados: el equipo sigue llegando a todo y el reproductor no ve ningún servidor. **Detalle técnico**: sin cambios de producto (`main` v1.132.0). claude-method `52c14a0` (P9: `[pull]` del sync con `git status --porcelain` antes de culpar a credenciales; P10: guard de `BIB_GATE_SKIP` con `Remove-ItemProperty` + comprobación, doctor `low` de clave vacía; causa medida: pwsh pasa `''` por `$null` a `SetEnvironmentVariable`; tag `pre-p9-p10-2026-09-09`) · `9d9449e` (guía `NETBIRD_SETUP.md`: inventario real, políticas, marcha atrás, peer ajeno). CreaRack-Pro PR #528 → `1807b8fd` (`claude-launch.ps1`: `CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1` en `ahorro` y en la caída de `trabajo`; docs + wiki `feature--harness--advisor-tool`). NetBird desde la consola (sin API): grupo `Moode`, `users -> Moode` TCP 22/80/443 un sentido, key `moode-pi` de un uso, `CreaRack (users+servers) <-> CreaRack` ALL bidireccional, `Default` desactivada (marcha atrás: Policies → Default → Enable). Peer `moode-pi` 100.96.49.142. Pendiente: recorte por puertos con luz; Play.Moode verifica P9/P10 en su arranque.

El chequeo de salud del método partido en dos, y la estación de Dani y Txell reiniciada y puesta al día

sesión de taller, sin tocar el producto. Claude tiene un chequeo que corre al abrir cada sesión y dice si tu perfil lleva el método al día, "el doctor". Hasta hoy daba por hecho que quien lo corre es del equipo CreaRack. Se ha partido en dos: un núcleo que sirve en cualquier proyecto de cualquier persona, y una pieza de equipo que el núcleo carga sola cuando el perfil lleva el plugin de CreaRack. Para los tres no cambia nada visible, salvo que la línea del arranque ahora confirma que la pieza de equipo cargó entera; si faltara o se quedara a medias, lo dice en rojo en vez de dar un verde falso. Se comprobó de cinco maneras antes de publicarlo, con copia de seguridad y marcha atrás, y los tres perfiles publican ya en verde con la versión nueva. Por la tarde, la estación compartida de Dani y Txell dejó de responder al escritorio remoto: Edu la reinició desde el chat y volvió entera sola, con el Agente y los trabajos programados en marcha. De paso salieron dos cosas: el perfil de la estación que corre los trabajos automáticos publicaba en el panel con el nombre de Edu y le pisaba la fila, y su copia del código llevaba cuatro días congelada porque la ronda del domingo deja un fichero generado sin guardar y eso bloquea la actualización. Ambas arregladas: el perfil publica ahora como `ia-edu`, la copia está al día y la ronda deja el repo limpio al terminar. **Detalle técnico**: sin cambios de producto (`main` sigue en v1.132.0). claude-method `5017a08` (parámetros `-NoExtensions`/`-UserClaude`, contrato `Ext*`, reordenación; JSON idéntico) + `f96628f` (extensión `plugins/crearack/harness/doctor-crearack.ps1` declarada en `plugin.json` → `doctorExtension`, sello de completitud, fuente única `harness/method-plugins.txt`, `gate_selftest.py --scope`, skill `/method:doctor` en method 3.5.0, `/crearack:method-doctor` puntero en crearack 2.3.0, `METHOD_DOCTOR.md` reescrita) + `bce94e8` (fila `ia-edu` en `/crearack:method-status`) + `8d2232b` (`ronda-pass.ps1` descarta `context/MAPA_SUPERFICIE.md` antes del pull y al terminar, avisa si el pull falla). Tag `pre-doctor-split-2026-09-09`. Verificación C1-C3/C5/C6 en §9 del plan; C4 hecha el mismo día (dani/txell verdes con `f96628f`). Estación: `METHOD_DOCTOR_PROFILE=ia-edu` en el scope User de `IA-Edu`; su Pro `e8d2c08` → `8613b89`. Workspace: LOG/STATE/NEXT s318, apuesta #20, plan con §9, wiki `ia-tech--metodo--particion-method-doctor-2026-09` + caja de herramientas. Trampa cazada: en PowerShell `$extPublisher` ES `$script:ExtPublisher` (copias del núcleo con prefijo `core`). Coordinación por SendMessage con la sesión de Play.Moode (P9: el sync culpa a credenciales con árbol sucio; decisión de Edu).

La wiki ordenada en todos sus menús, y el plan para partir el chequeo de salud aprobado tras tres revisiones

sesión de taller, sin tocar el producto. La Ayuda de usuario de la wiki interna mostraba casi mil artículos porque metía novecientas fichas internas en un grupo "General", y el menú del Supercontexto enseñaba treinta y pocas de sus novecientas páginas; hoy todos los menús aplican la misma regla y se comprobó en pantalla tras el despliegue: la Ayuda queda con sus 85 artículos y el Supercontexto con todas las suyas. La ayuda que ven los clientes dentro del producto no estaba afectada. Después, el plan para partir el chequeo de salud de la maquinaria de Claude en una parte para cualquier proyecto y otra solo del equipo: escrito, revisado por tres revisores independientes que lo hicieron cambiar seis veces, y aprobado por Edu con las dos decisiones que quedaban. Se construye en la próxima sesión. **Detalle técnico**: sin cambios de producto (`main` sigue en v1.132.0). Workspace PR #168 (`259cb622`): `src/lib/wikiMeta.ts` (`inferProduct`/`inferCategory`/`groupLabel`/`wikiSlug`) en los 6 índices `src/pages/wiki/*.astro`, portada, mapa y `[...slug].astro`; conteos PROD: Ayuda 998→85 · CreaRack Tech 147 · Workspace 50 · Workspace Tech 17 · IA Tech 53 · Supercontexto 915. Nota técnica en `entity--biblioteca--endpoint--wiki` (`87419cf8`). Plan `public/supercontext/doctor-split/PLAN_DOCTOR_SPLIT.md` v7 (núcleo `harness/method-doctor.ps1` + extensión `plugins/crearack/harness/doctor-crearack.ps1`; `method-plugins.txt` con suelo fijo; `Ext*`; `-NoExtensions`/`-UserClaude`; C1-C6); 3 paneles `/method:plan-review` en `opus`, 29 objeciones. Memoria `reference_cf_pages_deploy_hetzner_cron` corregida (deploy en OPS `100.96.245.233`, no STAGE).

Las barreras bloquean, el criterio para dar a un proyecto la maquinaria completa queda escrito y Edu estrena su caja de herramientas

sesión corta de taller, sin tocar el producto. Las barreras de seguridad que Claude se puso ayer siguen funcionando tras reorganizarlas: las siete que se pueden probar bloquean. Edu y Claude decidieron en una entrevista corta cuándo un proyecto merece la maquinaria completa (memoria del proyecto, estado entre sesiones y barreras) y cuándo basta con lo de serie: cuatro señales sencillas, escritas en la guía, y Claude hace la pregunta solo al crear un proyecto o al abrir uno que ya sea grande o de varios. Edu tiene una página nueva en la wiki, en lenguaje llano, con toda la maquinaria explicada; la leyó y la aprobó. De paso, casi la mitad de las páginas de la sección IA Tech no salían en su menú; ya salen todas. **Detalle técnico**: sin cambios de producto (`main` sigue en v1.132.0). claude-method `a12eecf` (tag `pre-escalon-pautas-2026-09-09`): `guides/SCALING.md` § escalón grande · Fase 0 en `iniciar-proyecto` · paso 6 `[escalon]` en `session-start.ps1` · `harness/README.md`. Workspace: apuesta #19 (`2d82799`) · wiki `ia-tech--metodo--caja-de-herramientas-edu` (`d401f51` → active `be49704`) · `ia-tech--metodo--scaling` (`f719b3e`) · `src/pages/wiki/ia-tech.astro` deriva product/category del slug (`4717e26`, verificado en pantalla). CreaRack-Pro: skill `wiki-promote` apunta a `wiki_update_metadata`. Doctor verde + simulacro 7/7 al arrancar. Pendiente: partir el doctor (sesión propia, plan + plan-review) · mismo agujero de `product` en los otros índices de la wiki.

Claude aprende a ponerse a prueba: simulacro de barreras, plantilla para encargar trabajo y los ganchos genéricos en su propio plugin

día de taller sobre la propia forma de trabajar con Claude, sin tocar el producto. Edu trajo dos herramientas de fuera; ninguna nos sirve tal cual, pero de una salió un simulacro que pone a prueba las barreras de seguridad de Claude en vez de fiarse de que estén instaladas: las siete que se pueden probar bloquean como deben. Medimos que de cada mil fichas de memoria que Claude se recordaba a sí mismo antes de cada acción abría menos de una, y Edu decidió dejar solo las de trampas conocidas. De un hilo de Reddit salió una plantilla fija para encargar trabajo a los ayudantes de Claude. Y como Edu quiere usar todo esto en cualquier proyecto suyo, los ganchos que valen para cualquier repositorio viven ya en un plugin genérico propio; queda comprobar en el próximo arranque que carga. **Detalle técnico**: sin cambios de producto (`main` sigue en v1.132.0). claude-method: `gate_selftest.py` (capa H del doctor, 18 pruebas) + skill `/method:simulacro` · `history.py empujadas` (0,3 % de lectura → surfacer solo `footguns_*`, `a77074d`, apuesta #18) · `guides/AGENT_BRIEF.md` (Regla 10 apunta, Pro `36ff2c1a`) · partición `method-hooks` 0.6.0 / `crearack-hooks` 0.6.0 (`0d27f51`, tests 27/27, `plugin validate` OK, carga por verificar al arrancar) · simulacro al plugin `method` (`40441c5`). Reglas: `antesala.md` §La apuesta con `insuficiente` + N mínimo (`423fa9c0`); `saludo-sesiones.md` sin despertar sesiones dormidas. Wiki IA Tech: 3 páginas nuevas. Respaldos: tags `pre-agentric-cherrypicks`, `pre-agent-brief`, `pre-hooks-split` (2026-09-09).

Stripe sin reautenticar, la verificación del CCIB cerrada y el asistente de descubrimiento con tres mejoras

segundo día de Edu trabajando desde el CCIB. Empezamos por una molestia: el conector de Stripe pedía volver a iniciar sesión cada pocos días. Ahora entra con una clave propia de la cuenta, en los tres perfiles, y no vuelve a preguntar; como la empresa sigue en trámite en Stripe, la clave es la del entorno de pruebas, que es el único que existe hoy, y se cambiará por la definitiva cuando activen la cuenta. De paso se actualizó el acceso remoto a la estación compartida de Dani y Txell, que avisaba de un cifrado antiguo. Después, la verificación de la monitorización en la red del CCIB, pendiente desde agosto: 127 puntos de acceso en la aplicación, 102 en línea, 166 clientes conectados, todas las gráficas con datos. Al escanear la red completa aparecieron tres cosas que arreglamos el mismo día: la aplicación cerraba la sesión a los diez minutos y se llevaba el listado de equipos que esperaba a que Edu los asignara; el escaneo no daba con la comunidad de 47 aparatos porque probaba la más habitual la última; y la nota de confianza de un equipo bajaba cuando un escaneo le llegaba peor, aunque su ficha estuviera completa. Con todo eso, el segundo escaneo dejó 102 de 108 equipos identificados a fondo y Edu los asignó a Wireless. **Detalle técnico**: `main` v1.129.0 → **v1.132.0**. PR **#524** (v1.129.1, B1-#26: `log_action` en `trigger_observatory_deep_discover` y `trigger_signage_deep_discover`; B1 de #274 dictaminado entero: #7 RESUELTO a15e327f, #11 FALSO, #16 FALSO con residual anotado, #26 este PR). PR **#525** (v1.130.0: `SessionTimeoutManager.loginUrlFor` → `?next=`; `sessions.js::_syncSessionTimeout` enganchado a `updateStepUI`; `_offerLastScan` + `#last-scan-offer`; 10 tests vitest). PR **#526** (v1.131.0: `auto_provision/communities.js::buildCommunityList` en los dos caminos de `discovery.js` + `_user_communities` en `DeviceDiscoveryService`; campo con comas; 4 + 6 tests). PR **#527** (v1.132.0: `scoring.py::carry_over_knowledge` antes de `apply_manual_lock`; identidad verificada por sysObjectID+vendor+modelo +10; `ssh_stage.py::_cisco_ios_model`; 12 tests, `test_calculate_confidence_snmp_only_not_penalized` 88→93). Escaneo `192.168.230.0/23`: Xirrus 55 a 90, Cambium 47 a 88 (XE3-4/X7-35X/XE5-8), Cisco C9200CX-8P-2X2G a 70, `selected_interfaces` 10→104/127. **Task #271 cerrada** (acta en 2 comentarios). Stripe: `claude mcp add -s user stripe https://mcp.stripe.com --header "Authorization: Bearer rk_test_…"` en los 3 perfiles (URL SIN barra; ficha `reference_stripe_mcp_clave_restringida_sin_oauth`). Estación: Win32-OpenSSH 10.0p2 (MSI), capabilities inbox retiradas, kex post-cuántico verificado, `ssh-agent` queda Running (ficha `project_proxmox_vms_dani_txell`). Ayuda `crearack--network--auto-provision-wizard` (workspace e6af16f7 y 479b924d). Diagnóstico del "discovery desaparecido": `SystemLog` AUTH logout 10:42:14 UTC = 10 min tras el último `auto_provision.deep_discover` (10:32:07); el escaneo estaba guardado (`ScanSession` 10:25). Sin cierre pendiente: 10 ramas locales borradas.

El programa del portátil ya no se cae mientras trabaja, y las gráficas dejan de salir vacías a ratos

primer día de Edu en el CCIB. El programa de su portátil ya ve 98 puntos de acceso del CCIB (en agosto, 47). La pantalla de cartelería sigue viva pero aislada de la red del portátil por una regla del conmutador; su enlace nuevo se pondrá cuando la revivan. A media mañana el programa se desconectó tres minutos de la nube: la ficha de la pantalla le pedía cada cinco minutos un análisis a fondo de un equipo que no contesta, cada intento costaba cuatro minutos y mientras tanto no atendía el canal con la nube. Tres arreglos en producción, comprobados con el aparato real: el programa atiende el canal aunque esté ocupado, un análisis contra un equipo mudo se rinde en diez segundos, y la ficha deja de insistir tras un fallo. El portátil se actualizó solo. De propina, las gráficas de ping de un equipo ya no salen vacías de vez en cuando. **Detalle técnico**: `main` v1.127.0 → **v1.129.0**. PR **#522** (v1.128.0, Agente **2.27.1**: `core/command_queue.py`, `_probe_alive`, backoff en `MonitoringDetailPlumbing.js`; publicado en Hetzner + Release `agent-v2.27.1`) · PR **#523** (v1.129.0, task #297, `_aget_smoothing_level`). Task #297 creada y cerrada; #276 comentada (espera al CCIB). Cierre de s312 recuperado. Detalle completo en `public/supercontext/LOG.md` s313.

Tercera tanda de la liquidación: cuatro entregas más y las rondas casi a cero

al final del domingo Edu remató lo que quedaba de las rondas de mantenimiento con cuatro entregas más a producción. Al restaurar una copia de seguridad el programa ya avisa de que las pantallas estrenan enlace y hay que reconfigurar el aparato; las peticiones a enlaces de pantalla muertos se ven en el historial; publicar desde el portal del cliente deja apunte; una operación larga que se queda colgada caduca sola; el consumo de un armario ya no se queda corto; un equipo restaurado no renace en un armario de la papelera; la disponibilidad dice "sin datos suficientes" en vez de inventar un 100%; el inventario de puntos de acceso enseña el firmware que ya tenía guardado; el tiempo encendido de la Ayuda mide lo que debe; y la ventana de grupos del Terminal ya no vacía los grupos de un equipo. Cuatro tareas cerradas del todo; queda reconfigurar la pantalla del CCIB en persona. **Detalle técnico**: `main` v1.123.1 → **v1.127.0**. PRs **#518** (v1.124.0, #276 código + #296 pt.2/3) · **#519** (v1.125.0, #281 pt.5/6 + #282 pt.4) · **#520** (v1.126.0, #281 pt.3 + #293 pt.2, migración `network/0065`) · **#521** (v1.127.0, #282 pt.8). Tasks cerradas: #281, #282, #293, #296. Ayuda de usuario y 7 páginas de wiki técnica al día. Detalle completo en `public/supercontext/LOG.md` s312.

El proyecto llevaba tres semanas sin actualizarse solo al arrancar: eran dos frenos, no uno

Dani pidió la revisión del método al abrir. Su copia del programa estaba quince entregas por detrás de la del servidor, aunque el ordenador debería ponerla al día solo cada vez que se abre. Había dos frenos distintos. El primero, un cartel de "operación en curso" que se quedó pegado del día anterior; se retiró y la copia se puso al día en el momento. El segundo llevaba desde el 13 de agosto: un fichero sobrante de una instalación vieja en la carpeta del proyecto disparaba la norma prudente de la actualización automática ("si veo algo que no reconozco, no toco nada"), y el proyecto se saltaba entero en cada arranque sin que nadie viera un aviso, porque esos avisos van por un canal que solo lee el asistente. Se borró el sobrante y se corrigió la norma: ahora solo frena si de verdad hay trabajo a medias. Se comprobó de las dos maneras —con basura suelta y con trabajo real a medias— para asegurar que la protección sigue entera. El arreglo va al método compartido, así que Edu y Txell lo reciben solos al abrir. No se tocó nada del programa que usan los clientes. **Detalle técnico**: `/crearack:method-doctor` en `drift` → `claude-method` `3e87a78` (`harness/auto-pull-org-repos.ps1` paso 5 con `git status --porcelain -uno` + contrato de la cabecera corregido; sin CI en ese repo, `gh run list` vacío). CreaRack-Pro `c8ecea77` → `86d6c636` (v1.124.0) tras retirar un `.git/index.lock` rancio del 05-09 y borrar `pnpm-lock.yaml` (residuo de `pnpm install`, el repo usa `package-lock.json`). Memorias: `footguns_index_lock_rancio_congela_pull_arranque` convergida al set compartido del workspace + fila en su README; `footguns_index.md` del perfil de Dani solo para lo específico de su estación. Doctor final VERDE, 0 memorias huérfanas, backup con push verificado (167 fichas). Detalle completo en `public/supercontext/LOG.md` s311.

Segunda tanda de la liquidación: tres entregas más y dos tareas de las rondas cerradas del todo

por la tarde seguimos con lo que quedaba barato de las rondas de mantenimiento. La herramienta que diagnostica por qué un equipo no manda sus mediciones llevaba 44 días culpando al perfil del fabricante cuando funcionaba; ya dice la verdad, comprobado en producción contra un punto de acceso real del CCIB. Los SAI y las pantallas que llevan días sin comprobarse ya no aparecen como "encendidos". Un armario que está en la papelera ya no se puede abrir, renombrar, guardar ni clonar por su dirección directa, ni sale en las etiquetas ni en la hoja de cálculo exportada. Y si el programa que vigila la red del cliente se apaga de golpe sin despedirse, el sistema ya no le manda encargos a un buzón vacío: esperan en cola hasta que vuelva. De regalo apareció y se arregló un fallo de nuestra propia batería de pruebas que escribía datos de prueba en la base de datos del ordenador de desarrollo. Sigue pendiente de Edu reconfigurar el reproductor de cartelería del CCIB con su enlace nuevo. **Detalle técnico**: `main` v1.121.0 → **v1.123.1**. PR **#515** v1.122.0 (tasks #283 pt.1, #281 pt.1, gemelos #277 + fix del hook de `tests/conftest.py`) · PR **#516** v1.123.0 (tasks #295 + #282 pt.2, 11 accesos con `deleted_at__isnull=True`, 12 tests) · PR **#517** v1.123.1 (task #283 pt.2, `select_agent` con ventana de 10 min). Tasks cerradas: #283, #295. Verificado en PROD por SSH: versión en el contenedor, diag de OIDs con token del Agente (126 IPs, "VendorProfile (priority)"), filtro en los 11 accesos por `inspect.getsource`, `select_agent` eligiendo a los 2 Agentes vivos. No medible hoy: `connected_clients` 47→0 (el Agente del CCIB no alcanza los Cambium desde hace >36 h).

Liquidación de las rondas: cinco entregas en producción y las dos tandas de defectos graves cerradas

por la madrugada llegaron seis avisos nuevos de la ronda de mantenimiento, y al mirarlos aparecieron nueve más de la ronda del sábado pasado que seguían sin tocar. Edu pidió liquidarlo todo y llegar a cero. Lo que se nota, en cristiano: borrar un cliente a mano ya deja apuntado quién lo hizo y se lleva sus copias de seguridad, en vez de abandonarlas en el disco con las contraseñas de su red dentro; una cuenta de solo lectura ya no puede ver el contenido de los guiones de red ni borrar grupos de equipos; las pantallas dejan de dar por bueno un dato viejo y dicen "no lo sé" cuando nadie ha comprobado un equipo en horas; cuando una búsqueda de equipos en la red falla, ahora se avisa en vez de guardar una ficha que parecía un hallazgo bueno; el botón de búsqueda a fondo deja de decir "hecho" sin haber hecho nada; abrir la ficha de una pantalla de cartelera ya no la convierte en router para siempre; y los diagnósticos automáticos dicen ahora si los firmó la inteligencia artificial o el motor de reglas de respaldo, que era justo al revés de lo que parecía. Se trabajó con cuatro ayudantes en paralelo; ninguno de los cuatro pudo ejecutar una sola prueba por un fallo del andamiaje, así que toda la verificación la hizo el asistente principal. Dos tropiezos honestos: una predicción escrita antes de desplegar no se cumplió (el vigilante del cliente volvió a estar en marcha entre medias) y se sustituyó por la medición real; y una entrega se puso en rojo porque solo se habían corrido las pruebas y no las otras tres comprobaciones que hace el sistema. **Detalle técnico**: PRs #510 (v1.117.0) · #511 (v1.118.0) · #512 (v1.119.0) · #513 (v1.120.0) · #514 (v1.121.0). Tasks cerradas: #292, #279, #277, #294, #293, #291, #278, #280, #284. Detalle completo en `public/supercontext/LOG.md` s309.

Los nueve bloques del programa repasados, el PIN de los clientes cifrado y el vigilante del CI ajustado en pantalla

Edu dejó la sesión desatendida un rato y pidió avanzar por orden. El PIN con el que un cliente entra a su portal de pantallas se guardaba legible; ahora va cifrado como las contraseñas de los equipos, quien gestiona el proyecto sigue viéndolo, y el portal real abre igual, comprobado en el navegador. Después se repasaron los tres bloques del programa que faltaban de la gran revisión de seguridad del verano (inteligencia artificial, interfaz y el Agente del ordenador del cliente): tres ayudantes escribieron el código en paralelo, ninguno pudo ejecutar nada por un fallo del andamiaje, y la verificación entera la hizo el asistente. Con eso los nueve bloques quedan repasados. Un aviso nuevo de "informe incompleto" destapó al minuto un fallo escondido desde hacía tiempo en el informe de rendimiento, ya corregido. Y Edu vio en pantalla por primera vez el vigilante del CI, que funcionó; de verlo salieron tres arreglos y una mejora suya: que el veredicto llegue también al asistente. El Agente 2.27.0 está publicado y corriendo en la flota. **Detalle técnico**: PRs #505 (v1.113.0) · #506 (v1.114.0) · #507 (v1.114.1) · #508 (v1.115.0) · #509 (v1.116.0 + Agente 2.27.0). `main` en `e8d2c088`. Plugin `crearack-hooks` 0.5.4 (`claude-method` `6951762`). Tasks #288 DONE, #286 anotada. Detalle completo en `public/supercontext/LOG.md` s308.

Tres trampas del andamiaje que solo conocía un ordenador, ahora las conocen los tres

al arrancar, la revisión del método avisó de que tres apuntes del ordenador de Dani no estaban en ninguna lista: existían, pero solo salían por casualidad si la conversación se parecía al tema. Dani pidió enlazarlos y, ya puestos, que valieran para todos. Los tres cuentan trampas del propio andamiaje de trabajo. Una explica por qué la copia de seguridad de los perfiles nuevos llevaba tiempo sin guardar nada y sin dar ningún error. Otra, por qué una comprobación de estado que usamos en varios sitios engaña cuando no encuentra lo que busca. La tercera es la más útil a diario: si el ordenador arranca sin internet, las conexiones al correo y a la biblioteca se quedan muertas para el resto de esa sesión aunque la red vuelva en un minuto, y la instrucción que teníamos escrita mandaba volver a dar permisos, que es perder el tiempo; lo correcto es abrir una sesión nueva. Ahora los tres viven en el archivo común del equipo, así que Edu y Txell los reciben solos la próxima vez que abran. Txell recibe además el del correo, que antes se le filtraba por considerarse fuera de su área. Por el camino se cometió un fallo y se corrigió: una de las operaciones se lanzó desde la carpeta equivocada y sembró una copia de apuntes donde no pintaba nada; se borró, y se escribió un apunte nuevo para que nadie repita el tropiezo. **Detalle técnico**: disparador `/crearack:method-doctor` (perfil `dani` VERDE, `claude-method` `1bd0365`); el aviso venía del chequeo anti-huérfanas del arranque (paso 0.2 de `harness/claude-method-sync.ps1`), que da por ruteada una memoria solo si aparece en `MEMORY.md`, `shared_memory_index.md` o un `*_index.md`. Los 84 footguns del perfil sí estaban ruteados por `shared_memory_index.md` (auto-generado); estos 3 eran personales. Primer intento: `footguns_index.md` local — descartado al converger. **Convergidas al set compartido del WORKSPACE, no a `claude-method`**: el canal genérico del método (paso 3a del sync) no corre en el arranque porque el hook lo llama con `-SkipMemory`, así que una memoria puesta ahí solo llega re-ejecutando el onboarding; el canal del workspace sí corre cada sesión. Workspace `68b0ddf3`: `footguns_git_pathspec_case_sensitive_windows`, `footguns_git_rev_parse_echoes_argument` y `footguns_mcp_no_cargan_sin_dns_al_arrancar` en `onboarding/shared-memory/` con frontmatter normalizado (`name`/`description`/`type`/`keys`/`origin`) y cuerpos intactos + 3 filas en su README. `claude-method` `92e08e9`: patrón `mcp` en `$CooFootgunPatterns` de `onboarding/memory-role-filter.ps1` para que el footgun de los conectores llegue al perfil COO (comprobado con el propio filtro: COO sí recibe el de MCP, no los de git; Dev todo; fichero en ASCII puro y parsea). Workspace `75ae1c3c`: footgun NUEVO `footguns_sync_manual_deriva_perfil_del_cwd` — cazado en esta sesión al lanzar el sync desde el directorio de `claude-method`: `$RepoRoot` cae por defecto en `(Get-Location)` y sembró 160 ficheros en un perfil fantasma `C--Users-IA-Dani-Claude-claude-method`, dejando el real sin tocar y sin error ni exit distinto de 0; el síntoma que lo delata es un `+158 nuevas` en una carpeta ya sembrada, y `Copy-Item` conserva la fecha del origen, así que las mtimes no sirven de prueba (el marcador fiable es `shared_memory_index.md`). Carpeta fantasma borrada. Verificado por marcador positivo: chequeo anti-huérfanas a `0` y las 4 memorias en `shared_memory_index.md` (159 ruteadas); method-doctor sigue VERDE con `92e08e9`. Sin CI: los dos workflows del workspace que disparan con push (`CF Pages Deploy`, `Bibliotecario-Ingest`) están `disabled_manually` desde antes. Observaciones no tocadas: perfil fantasma preexistente `C--Windows-System32` (155 ficheros, de una sesión ajena) y `CLAUDE.md` §2 cita la memoria `feedback_bash_cwd_persists_across_repos`, que no existe en el perfil de Dani.

Un vídeo por la mañana, cinco vigilantes nuevos dentro del asistente al mediodía, activos para los tres

Edu trajo un vídeo sobre una función recién estrenada en Claude Code que permite meterle al asistente pequeños programas propios que vigilan y corrigen lo que hace, sin fiarse de que se acuerde de una regla escrita. Comprobamos que la función existe de verdad aunque aún no esté anunciada, y Edu decidió montar todo lo que encajaba. Al cerrar, el asistente lleva cinco vigilantes nuevos: uno enseña en pantalla cómo va la comprobación automática de cada subida y prohíbe mezclar a la rama principal mientras haya comprobaciones a medias; otro avisa cuando un fichero de código engorda de más; otro avisa al tocar un fichero de la web que se carga por dos caminos, la trampa de agosto que duplicaba armarios; otro tapa contraseñas y claves antes de que entren en el historial de la conversación, y lo revisó un segundo modelo que encontró tres huecos, ya cerrados; y otro acompaña cada petición con los tres pasajes más parecidos de la Biblioteca. Dani y Txell lo reciben solos al arrancar. Lo que falta: que Edu lo vea en su pantalla al reiniciar, porque las pruebas del asistente no tienen pantalla. **Detalle técnico**: `claude-method` `e89cf6b`→`248fd17`: plugin `plugins/crearack-hooks` v0.5.0 (`hooks/register.ts` + `hooks/secrets.ts`, 415 LOC; `tests/secrets.test.js` 24 casos), marketplace, `$NewPlugins`, `env.CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1` en `settings-base.json`, 3 comprobaciones nuevas en `method-doctor.ps1`. Hooks: (1) guard de `gh pr merge` + vigilante del CI (`$.clock.every`, `$.ui.status`, sello `ci.last`), simulacros sobre el PR #504 desechable; (2) Regla 5 (>500 `context`, >1000 `$.ui.ask`); (3) estáticos (doble carga, import sin hash, `?v=`; PROD hashea `{% static %}` desde el 04-07, ficha corregida); (4) secretos sobre Bash/PowerShell/Read/Grep/TaskOutput/prompt, revisión Opus 3A/7M/4B aplicada, comandos fallidos tapados como `deny`; (5) Regla 0 push por `bib_search_semantic` (1,1 s). Copia previa `claude-backups/edu/harness-snapshots/2026-09-05-function-hooks`. Gestor: task #289 in-progress; ledger: apuesta #17. Memoria: `reference_function_hooks_claude_code`. Docs: STATE/LOG/NEXT s303.

Ráfaga de tarde: cuatro partes del programa revisadas y en producción (v1.107.0→v1.112.0) con tres ayudantes a la vez, y la norma de redacción endurecida

Edu quería aprovechar a fondo las dos horas de crédito que sobraban antes de la renovación semanal. Primero rematamos la vigilancia de red: las baterías de respaldo ya cuentan como vivas si responden por su canal de datos aunque el ping no llegue, y las páginas de WiFi y baterías cargan más ligeras. Luego lanzamos tres ayudantes en paralelo, cada uno con una parte del programa y su propia copia del código: los armarios de equipos, las pantallas de publicidad y la gestión de dispositivos. Fable revisó cada entrega, la documentó y las subió de una en una a producción, comprobando cada una en el navegador. Lo que se nota: al quitar un equipo de un armario ya no desaparece otro igual de otro armario; aplicar una plantilla a un armario más bajo deja fuera lo que no cabe; las pantallas solo cuentan como encendidas con datos recientes; el portal de clientes se bloquea 5 minutos tras 5 PIN mal; y varios fallos que antes se callaban ahora avisan. Dos tropiezos: el Docker del ordenador de Edu se quedó sin memoria con cuatro pruebas a la vez (ya tiene 4 GB de tope, devolviendo lo que no usa), y un ayudante cambió dos comportamientos que unos tests protegían a propósito; se deshizo, Edu decidió, y se aplicó en una última entrega: una tarea hacia un equipo cuyo Agente está apagado se rinde a los 5 minutos, y dos órdenes que nunca funcionaron salen de la lista de permitidas. Al cerrar, Edu no entendió el resumen por demasiado técnico, y la norma de redacción gana una prueba nueva: el primer párrafo de un cierre lo tiene que entender quien no programa. **Detalle técnico**: Pro `main` = v1.112.0. PRs: #499 v1.107.0 (monitoring D: `live_evidence.py`, `ups_metrics.py`, `ups_reports.py`, `advance_deep_discover_job`, `_reverse_link_device`, 15 tests), #500 v1.109.0 (racks, 14 hallazgos, 20 tests, enrutado `/stencils/custom` corregido), #501 v1.110.0 (signage, 11, 16 tests), #502 v1.111.0 (network, 16, 35 tests; net-#16/#21 revertidos), #503 v1.112.0 (`NO_AGENT_GRACE`, whitelist sin `copy running-config startup-config`/`delete interfaces`). Agentes: 3×Opus en worktrees (`isolation: worktree`, BD y Redis propios por agente), ~300 k tokens cada uno; Sonnet para el bloque D. Docker: `.wslconfig` 1,5 GB→4 GB + `autoMemoryReclaim=gradual`. Harness: `claude-method` `edf47e8` (prueba del compañero en `companero.md` + `redaccion.md` §7). Ayuda: 4 páginas. Memoria: `feedback_rafaga_agentes_paralelo_docker_1gb`. Tasks: #286 (2 avances), #288 nueva (PIN cifrado). Quedan frontend 16 · config-ia 16 · terminal 14.

La vigilancia de red, revisada a fondo: tres entregas en producción (v1.104.0→v1.106.0), prueba de Edu hecha y una corrección honesta

hoy tocaba el tercer dominio de la lista de mejoras menores que dejó la gran revisión de seguridad: la vigilancia de red (Observatory). Se hizo en tres entregas seguidas. En cada una, Fable decidió cómo arreglar cada punto, un ayudante más barato escribió el código y las pruebas, y otro ayudante revisó el resultado antes de subirlo; esa revisión encontró cinco fallos reales en los propios arreglos, que se corrigieron antes de publicar. Para quien usa la aplicación: pulsar "Ping" ya no marca caído un equipo que sí responde por otro camino, el suavizado de las gráficas vuelve a obedecer, el editor de targets avisa cuando un valor no vale, el cerebro de red dice claro cuándo no hay Agente para aplicar un arreglo, los incidentes avisan por los canales cuando se pasan del plazo, y las alertas se cierran solas cuando el equipo vuelve. Edu probó la versión de ayer (correcto que un administrador cambie la contraseña de otro sin conocer la actual) y pidió que la ventana de editar usuario mostrara la tabla de permisos entera: hecho y comprobado en pantalla. Dos cosas más: lo que ayer contamos como "tareas nocturnas que no hacían nada" era falso, se midió en la base de datos y siempre funcionaron, así que quedó corregido en ficha, wiki y changelog; y el servidor que corre las pruebas se quedó sin espacio temporal por una caché de Node, ya limpiada y con limpieza diaria. De propina, Edu recuperó qué era el dominio `stack-gear.com`: una idea de producto de julio, aparcada, con su documento de balance para no volver a olvidarla. **Detalle técnico**: Pro `main` = `63b62635` (v1.106.0). PRs: #495 v1.103.1 (modal Edit User: `modal-content-scroll`), #496 v1.104.0 (monitoring A, 12 hallazgos, 66 tests, 19 ficheros), #497 v1.105.0 (monitoring B, 11 + 11 de la revisión Opus, 34 tests; advisory lock 4272 para `case_number`, 409 en apply/rollback, guardia de estado en `/result`, `build_insight_context`, `?v=4` en `InsightActions.js`), #498 v1.106.0 (monitoring C, 13 + 14 de Opus, 41 tests, migración `monitoring/0034_idx_notiflog_channel_created`; SLA notifica con marcado/envío separados, auto-resolve de `AlertEvent` + `alert_resolved` por WS, `rls_bypass()` en las 6 tasks con savepoints, purga de `NotificationLog` 02:45). Ayuda de usuario: `crearack--monitoring--cns-sentinel`, `--itsm`, `--alertas`. Wiki `incident--20260903--huey-tasks-sin-rls-bypass` corregida. OPS: `/etc/tmpfiles.d/node-compile-cache.conf`. Fichas: `footguns_huey_tasks_sin_guc_rls_inertes` (reescrita), `footguns_ops_tmp_node_compile_cache_enospc`, `reference_stack_gear_domain`. Workspace: `PLAN_ARREGLOS.md` (7a3c6a63). Pendiente: bloque D de monitoring (4), network (22), channel layer para el despacho al Agente, estibador que se para al armar un Monitor (3 de 3 hoy).

Punto cero tras la auditoría: briefing liquidado, lanzador con tres modos, y dos dominios de la cola (planos + núcleo) arreglados y en producción (v1.101.0→v1.103.0)

día de dejar la casa ordenada después de la gran revisión de seguridad, aprovechando que Anthropic nos devolvió el crédito. Por la mañana cerramos todo lo que quedaba apuntado: la protección que impide a los ayudantes automáticos usar el modelo caro está comprobada, los tres perfiles del equipo van a la par, la guía de instalación explica el menú de arranque, y la lista de ~155 mejoras menores de la auditoría es ahora una tarea por dominio con su plan, en vez de un montón. El acceso directo del escritorio cambió a petición de Edu: por defecto arranca con Fable, y tiene una opción de ahorro con Opus 5 pensada para los días de cuota justa y para el trabajo de seguridad, porque a media tarde Fable saltó solo a un Opus más viejo por sus propias medidas de seguridad; ese salto no se puede evitar, pero ahora la sesión se para y pregunta en vez de cambiar sola. Por la tarde y noche entraron **dos dominios enteros de esa cola** en producción. En los planos: restaurar un plano ya no resucita racks que tú habías tirado aparte, vaciar la papelera cuenta bien, el fondo de plano solo acepta imágenes de verdad, y Auto-Plan tiene tope de tres análisis a la vez y dice cuántas cosas se saltó en vez de fingir éxito. En el núcleo: cambiar tu propia contraseña pide la actual, "ver como otro usuario" se corta solo si algo deja de cumplirse, el registro no revela qué correos existen, las credenciales dejan rastro, y asignar grupos a racks desde el listado vuelve a funcionar (fallaba siempre sin que nadie lo viera). El hallazgo del día lo trajo una revisión con un segundo modelo antes de publicar: **tres tareas nocturnas del servidor llevaban tiempo sin hacer nada en producción** porque el aislamiento por organización las dejaba a ciegas; ya tienen su llave. Para Dani y Txell: el menú de arranque tiene ahora tres opciones y el defecto es Fable; y si cambiáis vuestra contraseña os pedirá la actual. **Detalle técnico**: Pro `main` = `d14ebb58` (v1.103.0). PRs: #490 (lanzador defecto `fable`), #491 (modo `ahorro` + `claude-opus-5` explícito), #492 v1.101.0 (blueprints A: `blueprints/api/trash.py` atómico + ventana de 60 s + `_delete_orphan_racks`; anotaciones/duplicado con plano vivo; `update_positions` cap 500; `place_row_in_room` con `select_for_update`), #493 v1.102.0 (blueprints B: `blueprints/services/uploads.py`; /bg valida; Auto-Plan carpeta por org + 429 al 4º; import tolerante con `warnings` al job), #494 v1.103.0 (core: `current_password` + `update_session_auth_hash` + `row.html` `isSelf`; impersonación revalidada + cierre de `ImpersonationLog`; `/signup` neutro; CSP `wss://host ws://host`; `setup_admin` advisory lock; rate-limit sha1[:12]; login-history [1,500]; `SystemLog` `CREDENTIAL` migración `core/0034`; HTMX racks vía `RackService`+`log_rack_action`; permisos fail-closed; `LoginLog.method` desde allauth; **`core/utils/rls.py` `rls_bypass()`** en purga/integridad/monitor — revisión Opus con 8 hallazgos corregidos). 56 tests nuevos. claude-method 61803f1 (`switchModelsOnFlag: false`, copia previa en claude-backups). Tasks nuevas #286 (cola por dominio) y #287 (recordatorio de reindexar del harness). Ayuda: `crear-plano`, `auto-plan-ai`, `user-management`, `usuarios-y-permisos`, `setup-equipo-nuevo`, `feature--harness--advisor-tool`. `MEMORY.md` 174→131. Verificado en el contenedor de PROD tras cada merge; sin click-test en pantalla (pendiente de Edu).

Estreno de Fable 5.1: asimilar el método sin tocarlo, copia íntegra, y primera adaptación (modelos de los ayudantes + lanzador con modos)

primer día con la versión nueva de Claude, Fable 5.1. Antes de cambiar nada, Edu pidió que me empapara del proyecto y de nuestro método de trabajo, y que cualquier mejora pasara por su visto bueno y por una copia de seguridad fácil de recuperar. Así se hizo: copia completa del método en el repositorio de backups y, con su GO, seis arreglos pequeños salidos de la revisión (una apuesta vencida evaluada con datos reales de la estación, una comprobación que corría dos veces en cada edición, ramas y carpetas de trabajo viejas). La mejora importante del día es de **coste**: los ayudantes automáticos que Claude lanza para tareas secundarias ya no pueden usar el modelo más caro, ni por descuido ni a propósito, y el **acceso directo del escritorio pregunta al arrancar** si quieres el modo de trabajo diario, en el que un modelo más barato conduce y Fable solo interviene como asesor en los momentos difíciles, o el modo Fable para decisiones y auditorías. Lo probaremos dos semanas y el 16-09 decidiremos con cifras. Novedad llamativa: dos sesiones de Claude, una en este proyecto y otra en un proyecto personal de Edu, se coordinaron entre ellas por mensajes para no pisarse en el método común; de ahí sale una norma nueva, saludarse al arrancar. Para Dani y Txell: a la vuelta, el primer arranque mostrará el menú del lanzador; el defecto es el modo trabajo. **Detalle técnico**: claude-method `860447f` (T1) · `8cb172d` (regla 10 hecha gate: `settings-base` env + `guarda_modelo_subagentes.py`, plugin crearack 2.2.4) · `d1b47d7` (regla global `saludo-sesiones.md`); Pro `e8af2b63` + `94155b54` (docs regla 10, fable-handover, CLAUDE_CODE_FEATURES) + PR #489 → `b704652b` (`scripts/windows/claude-launch.ps1` modos `trabajo`/`fable`, `install-claude-shortcut.ps1 -Mode`, CHANGELOG/RELEASE_NOTES); workspace `3f905e9e` (#13 PARCIAL) · `3c85ceca` (#15) · `b903413d` (#16). Backup: tag `pre-fable51-adaptacion-2026-09-02` + `claude-backups/edu/harness-snapshots/2026-09-02-pre-fable51/`. Coordinación con la sesión Play.Moode (sus commits en claude-method: d6f9c16, dd98a3f, 6b36d54 — backup por proyecto). Sin cambio de `APP_VERSION` (la aplicación no cambia). Deudas documentadas en NEXT s300.

Auditoría Suprema 2 CERRADA del todo (T8 + 2ª pasada + Tanda 9) · v1.100.0 en PROD

hoy hemos terminado por completo la segunda revisión a fondo del código. Entró la última tanda de la lista (la del espacio de trabajo interno) y una segunda pasada sobre lo que quedaba: ahora se puede **desconectar del todo un ordenador comprometido sin borrarlo** —queda "congelado" con su configuración intacta hasta que un administrador lo reactive con un botón—, y la papelera avisa en pantalla cuando no puede restaurar algo en vez de callar. Después repasamos, uno a uno, todos los problemas menores que quedaban apuntados de la revisión, y en ese repaso saltó lo importante del día: **dos fallos de seguridad de los graves se habían escapado** de las tandas anteriores porque no encajaban limpiamente en el tema de ninguna. Los dos se cerraron en el momento: uno permitía "disfrazar" una dirección de red interna de una forma que burlaba el filtro de las sondas del servidor; el otro dejaba subir a la librería de plantillas un fichero preparado que ejecutaba código en el navegador. Con esto la revisión queda cerrada de verdad: **45 fallos graves arreglados, ninguno vivo**. Lo que resta son unas 155 cosas menores de calidad (mensajes de error, rendimiento, detalles), que no corren prisa y se irán arreglando de paso cuando se toque cada fichero. Dos honestidades del día: metí la pata reescribiendo una página de ayuda de memoria (la cacé comparando y la restauré), y un test daba "rojo" en mi ordenador por datos viejos de pruebas —en el servidor de integración, con base limpia, pasa—. **Detalle técnico**: `main` (Pro) = `024052ce` v1.100.0; workspace con el registro del triage y la Tanda 9. **T8/workspace** PR #167: ALTA `METHOD_DOCTOR_TOKEN` acotado a `/api/harness-status` + CF Access fail-closed + gate readonly a los CRUD REST + Holded `create_*` por `holdedResult()` + rate-limit del Correo por owner + `min_confidence` por `.bind` + `bib_search_semantic` con `sanitizeChunk` + delete del Curator borra el `.md`; 168 tests; 8 MEDIA descartados con contra-argumento. **2ª pasada Agente** PR #486 v1.98.0: `token_epoch` + `POST /fleet/{id}/revoke-tokens` + candado reauth-self + rotación jti del refresh + constraint parcial 1-Primary (`terminal/0009`, dedup bajo GUC RLS transaction-local) + caché 60 s `sentinel_liveness`; 10 tests + 29 de contrato. **2ª pasada correctness+UI** PR #487 v1.99.0: restore fallido con `HX-Trigger`, prefiltro BD del borrado por IP (IP en claro O prefijo Fernet), `select_for_update` + limpieza de org 1×/lote en el editor, `log_action` en las mutaciones de vendors, tolerancia a 3 fallos en `pollJob`/los 3 polls, botones Revoke/Re-authorize (`reauth_locked` en el fleet API); el CI cazó doble instancia de `ObservatoryOverview.js` (cadena `?v=` a 15/17). **Triage** 4 lectores Opus sobre 257 MEDIA/BAJA → ~19 cerrados / ~41 descartables / ~165 vivos + **2 ALTA colados**. **Tanda 9** PR #488 v1.100.0: `net_guard._ip_blocked` compara `ipv4_mapped` + `::/128`; `create_from_image`/librería con `racks:admin` + allowlist + saneo SVG; `serve_media_gated` nosniff+attachment; PIN en los 3 POST del portal signage + permiso `schedule`; `/api/search` por scope, suspensión antes de `is_exempt`, `/api/help/article` a `crearack--*`, cap IA del help; 2 XSS del editor escapados + `?v=2`; 21 tests; verificado en PROD + click-test. Ayuda actualizada: `crearack--terminal--local-agent` (Revoke) y `crearack--racks--stencils-crear` (admin+formatos). Memoria nueva `feedback_no_reescribir_ayuda_de_memoria`. `MCP_SIGNING_SECRET` verificado ya-existente en CF (falso pendiente corregido en `PLAN_TOKENS_MCP.md`).

Tanda 6 cerrada de punta a punta (Agente 2.26.2 en la flota) · el sistema de pruebas reforzado

hoy se ha cerrado la penúltima tanda de la revisión a fondo del código: la del **programa que se instala en los ordenadores de los clientes**, que llevaba dentro los fallos más serios de toda la revisión. El peor, con diferencia: ese programa **aceptaba órdenes de cualquier página web** que el usuario tuviera abierta. Bastaba una web maliciosa en una pestaña para que pasara a obedecer a un servidor ajeno, con acceso a los equipos de red del cliente, a sus ficheros y a sus copias de configuración. El código se creía protegido por un carné firmado que llegaba en cada petición, y resulta que **nunca comprobaba la firma de ese carné**. Cerrado, junto con otras tres puertas: la consola de diagnóstico también estaba abierta a cualquier web, las actualizaciones se podían forzar hacia atrás a versiones viejas con agujeros ya tapados, y había una fuga de conexiones de red. El programa nuevo se compiló y **se instaló solo en los ordenadores**, sin que nadie tuviera que tocar nada. Al ir a comprobar que todo había quedado bien salieron **dos averías que llevaban tiempo escondidas, y ninguna daba error**. La primera: el fichero donde el programa apunta lo que hace debía recortarse solo al llegar a 5 megas, y **nunca lo hizo** — había llegado a **322 megas** en el ordenador de Edu, engordando unos 6 al día en la máquina de cada cliente. Fallaba en silencio porque el aviso del fallo se escribía justo en el fichero que no podía recortarse. Ya está arreglado, y lo bueno es que **los programas ya instalados se limpian solos** al actualizarse. La segunda: el sistema que ejecuta las pruebas antes de publicar se quedó **45 minutos bloqueado**, y habría seguido así hasta seis horas porque ningún trabajo tenía límite de tiempo. Investigándolo apareció que **uno de los dos ordenadores que ejecutan las pruebas llevaba cuatro días muerto** sin que nadie lo supiera: todo salía verde porque el otro se encargaba de todo, solo que a la mitad de velocidad. Ahora los dos están vigilados y avisan por correo si caen — probado forzando la caída de verdad. Queda una sola tanda de la revisión (la del espacio de trabajo interno) y ponerle la **firma digital** al programa cuando llegue el alta que Edu va a tramitar; sin ella, un Windows 11 con la protección de aplicaciones activada no deja instalarlo en una máquina de cliente. **Detalle técnico** (Opus 5 · CreaRack-Pro v1.94.0→**v1.97.2** · Agent 2.25.1→**2.26.2** · workspace): - **PR #483 (v1.97.0 / Agent 2.26.0) · T6, 5 ALTA**: `/saas/*` sale de `EXEMPT_PATHS` (estaba exento entero apoyándose en un JWT que `auth._decode_jwt` **no verifica**) + `saas_bootstrap_origin_ok` (excepción acotada por Origin de confianza, que preserva el botón Reauth) + `saas_url_allowed` deja de meter el Origin de quien llama entre los permitidos · `/ws/debug` valida el Origin del handshake (los WS no pasan por CORS) · **downgrade forzado** cerrado atando el `version` del manifiesto al `version.py` que viaja DENTRO del zip firmado, **sin tocar el formato de firma** (cambiarlo dejaba sin actualizaciones a los `.exe` ya instalados) e implementado 2× a propósito (bootstrap + `pkg_updater`, que viaja en el paquete) · fuga de `SnmpEngine` cerrada **reutilizando el motor del Sentinel** (cerrar el propio corrompe a los demás en pysnmp 7.x: el arreglo obvio habría roto SNMP). 11 tests. - **PR #484 (v1.97.1 / 2.26.1)**: techo de tamaño (16 MiB) al leer la configuración por SSH — solo había tope de tiempo. 3 tests. - **PR #485 (v1.97.2 / 2.26.2)**: rotación de `agent.log` (`sys.stdout`/`sys.stderr` apuntaban al mismo fichero que el rotador intenta renombrar; Windows lo impide) + `timeout-minutes` en los 5 jobs del CI + `needrestart` neutralizado + caché de MIBs de los tests por usuario. 5 tests. - **Publicación del Agente**: compilado con self-test OK, publicado a mano (scp + `docker cp`, sidecar al final) **sin firma Authenticode** por decisión de Edu; la flota se actualizó sola y sigue online. Rotación **verificada forzándola de verdad**: 0 errores donde antes había 91. - **Workspace**: `servicios-check.sh` gana sondeo `unit://` y vigila los 2 runners; simulacro del camino de fallo verificado (correo rojo → verde).

Tandas 3, 5 y 7 de la auditoría en PROD (v1.94.0→v1.96.0) · quedan 2 de 8

seguimos arreglando lo que encontró la revisión a fondo del código y hoy han entrado tres tandas más en producción. La primera cierra la vía por la que alguien podía colar código malicioso en las pantallas de CreaRack usando el nombre de una lista de reproducción, el nombre de un equipo o un fichero de imagen preparado a mala idea; de paso salió que **el botón "Project Report" del menú llevaba roto en toda la aplicación** sin que nadie lo hubiera notado, y ya funciona otra vez. La segunda hace que **quitar un Agente de la lista le corte el acceso de verdad**: hasta hoy ese ordenador seguía pudiendo leer las contraseñas de los equipos durante días y renovarse solo hasta seis meses, así que si a alguien le robaban el portátil no había manera real de cortarlo salvo cambiar la clave de toda la flota. La tercera arregla diez formas de perder datos sin que saltara ningún error: la peor era que **clonar un armario duplicaba la dirección de gestión del equipo y, al borrar el clon, se borraba también el equipo original** con todo su histórico de medidas; también se arregló que renombrar un equipo le borrara el dibujo y los puertos, que restaurar de la papelera destruyera la única copia mientras decía que todo había ido bien, y que editar un fabricante vaciara su catálogo para todos los clientes. Todo comprobado en la aplicación real después de publicarlo (pantalla incluida), no solo con pruebas automáticas. Quedan dos tandas: la del programa que se instala en los ordenadores —que hay que compilar, firmar y distribuir, así que va en sesión aparte— y la del espacio de trabajo interno. **Detalle técnico**: PRs #480 (v1.94.0, T3/XSS), #481 (v1.95.0, T5/auth del Agente) y #482 (v1.96.0, T7/correctness); `main` = `120b0bf8`. CI verde a la primera en los tres, despachados por `crearack:estibador`. **T3**: `json_script` en `client_portal.html` (era `|safe` en `<script>` de ruta anónima exenta de CSP), `_num()` para la geometría del composer SVG, saneo de SVG por extensión efectiva, `nosniff`+attachment en `media_file`, `editor.html` sin `|safe`, `escHtml` en `auto_provision_panel.js`, y `openReportModal`→`openRestoreReportModal` (colisión Annex B, `base.js?v=10`); + filtro de org en asset_id del portal y topes 500 MB/20 GB. 15 tests. **T5**: `fleet:admin` en `register_agent`, revocación real (`_agent_exists` en `get_agent_from_request` y `/refresh`), rate-limit atómico, rol vigente de BD en `targets_updated`, `pg_advisory_xact_lock` por organización en registro/failover, el saliente pierde el rol salvo en modo manual, `log_action` en reauth/delete/config; 14 tests + 13 ficheros de test actualizados al contrato nuevo. **T7**: `clone_rack` sin `management_config`, el bloque SNMP de `_persist_profile` solo si hubo `sys_descr`, `restore_entry` conserva la entrada si no recreó nada + valida solape, `exclude_unset` en el PUT de vendor, estado `received` en el webhook de Stripe (**migración `billing/0002`, solo choices**), `bandwidth_mbps` en el ingest, update parcial sin pisar `model_data`/`u_height`, `get_rack` filtra papelera, etiqueta de Prometheus por `resolver_match.route`, `except: pass`→`logger.exception`; 14 tests. Verificado en PROD: versión servida, flota viva tras el deploy, catálogo de 79 vendors intacto. Ayuda actualizada: `crearack--signage--client-portal` y `crearack--terminal--local-agent`.

Auditoría Suprema 2 COMPLETADA (10/10) · plan de arreglos · 4 tandas en PROD (v1.88.0→v1.93.0)

hoy hemos terminado la segunda revisión a fondo del código de CreaRack — los diez módulos revisados, 300 problemas confirmados en total, 43 graves (ninguno urgente: CreaRack aún no tiene uso real). Los seis módulos que faltaban se revisaron en una sola tarde aprovechando que hoy el descuento del plan funcionaba bien. Con la lista completa hicimos un plan para arreglarlo por tandas y ya han entrado en producción cuatro tandas de arreglos de seguridad: permisos que faltaban (un usuario de solo lectura ya no puede borrar racks, tocar la monitorización ni ejecutar comandos en los equipos), blindaje de los ficheros de copias de seguridad (ya no se puede sacar un fichero de otra organización), y validación del comando de copia de un equipo. Curiosidad técnica: a mitad del trabajo el modelo de IA cambió solo de Fable a Opus — comportamiento normal de Fable al tocar código de seguridad; se deja así hasta la próxima sesión. **Detalle técnico**: arranque — PR #474 (fleet primary, v1.88.0) mergeado, T2 despachada como PR #475 (v1.89.0, con fix de CI `MIB_CACHE_DIR` en settings/test), ronda #249 verificada y cerrada, hallazgos click-test de s293 ya arreglados en v1.86.20. Auditoría completada (6 dominios restantes, ~72 M tokens Opus, encadenados de uno en uno): terminal 38/12 ALTA, config-ia 19/0, signage 21/2, blueprints 19/0, frontend 23/4, workspace 30/1 → **300 conf / 43 ALTA**. Plan en `auditoria-suprema-2/PLAN_ARREGLOS.md` (8 tandas). Arreglos en PROD (~44 tests nuevos): #476 v1.90.0 (T1/core), #477 v1.91.0 (T1/monitoring+racks), #478 v1.92.0 (T2/ficheros), #479 v1.93.0 (T4/inyección de comandos) — todos healthy verificado por SSH. Modelo Fable→Opus 4.8 (memoria nueva). Quedan 5 tandas (T3/XSS con navegador, T5, T6/Agente .exe, T7, T8).

Auditoría Suprema 2 (4 de 10 dominios) · v1.87.0→v1.87.3 · parada de emergencia y recuperación

hemos arrancado una segunda revisión a fondo del código de CreaRack, módulo a módulo, con equipos de agentes automáticos que buscan fallos y se los comprueban entre sí. Van cuatro módulos de diez (núcleo, racks, red y monitorización): 150 problemas confirmados, 24 graves, ninguno urgente porque CreaRack aún no tiene uso real; se arreglarán por tandas cuando termine la revisión entera (decisión de Edu). Por la tarde el ordenador se volvió inestable al lanzar tres revisiones a la vez y hubo que parar de golpe; tras reiniciar no se perdió nada salvo la de monitorización, repetida por la noche. También han entrado en producción cuatro mejoras (papelera de dispositivos, arreglo de la traducción que impedía publicar, cierre de episodios de conectividad por recuperación y blindaje del validador de comandos) y se han refrescado 16 fichas de arquitectura. Pausa por la ventana de crédito (contador anómalo, quejas generalizadas ese día). **Detalle técnico**: PRs #470-#473 (v1.87.0-v1.87.3, `main` = `d00f04d0`) · Atlas: workflow `atlas-regen-16` (ws `4c5115b2`) · Auditoría: `public/supercontext/auditoria-suprema-2/` (core 31/7 ALTA, racks 36/7, network 39/6, monitoring 44/4; README con receta de reanudación; args de terminal/config-ia/signage/blueprints/frontend/workspace en `args-pendientes/`) · Sin cerrar: PR #474 (v1.88.0) verde sin mergear, rama T2 `edu/t2-huey-async` (v1.89.0) sin push · Regla nueva: un workflow de auditoría por ventana de 5 h.

Edu: "liquidemos todo lo que tenemos hasta lo de septiembre" — tres versiones más en producción, el Agente 2.25.1 en todos los equipos y un fallo fantasma de los tests cazado de raíz

Edu: "liquidemos todo lo que tenemos hasta lo de septiembre" — tres versiones más en producción, el Agente 2.25.1 en todos los equipos y un fallo fantasma de los tests cazado de raíz

Edu: la puesta al día de septiembre en una tarde: doce versiones, dos Agentes y una página de Dependencias que ya no engaña

Edu: la puesta al día de septiembre en una tarde: doce versiones, dos Agentes y una página de Dependencias que ya no engaña

Edu: el Agente ya explica por qué un equipo no tiene ancho de banda, se evalúa la apuesta del menú Correo y se liquidan tres flecos — tres versiones en producción y dos del Agente

Edu: el Agente ya explica por qué un equipo no tiene ancho de banda, se evalúa la apuesta del menú Correo y se liquidan tres flecos — tres versiones en producción y dos del Agente

Edu: el Agente vuelve a escribir su diario, se cierra la auditoría del monitoraje y arranca la lista única de deuda técnica — cinco versiones más en producción

Edu: el Agente vuelve a escribir su diario, se cierra la auditoría del monitoraje y arranca la lista única de deuda técnica — cinco versiones más en producción

Edu: día de limpieza — cuatro versiones en producción, el Agente 2.23.0 y un sensor nuevo que avisa cuando un Agente está vivo pero no produce datos

Edu: día de limpieza — cuatro versiones en producción, el Agente 2.23.0 y un sensor nuevo que avisa cuando un Agente está vivo pero no produce datos

Edu: toda la tanda de arreglos de la auditoría del monitoraje entró en producción en un día, el Agente mide el tráfico interfaz por interfaz, y quedó claro por qué el CCIB 'no daba datos' (no era un fallo: era agosto)

Edu: toda la tanda de arreglos de la auditoría del monitoraje entró en producción en un día, el Agente mide el tráfico interfaz por interfaz, y quedó claro por qué el CCIB 'no daba datos' (no era un fallo: era agosto)

Edu: la auditoría del monitoraje encontró 65 fallos verificados, los dos primeros bloques de arreglo están en producción… y el Agente se quedó mudo de SNMP tres veces hasta entender que 75 puntos de acceso están apagados

Edu: la auditoría del monitoraje encontró 65 fallos verificados, los dos primeros bloques de arreglo están en producción… y el Agente se quedó mudo de SNMP tres veces hasta entender que 75 puntos de acceso están apagados

Edu: un cliente nuevo ya puede conectar su primer Agente él solo (ensayado tres veces hasta que salió sin trucos), y de propina cayó el fantasma de los enlaces de email que "expiraban"

Edu: un cliente nuevo ya puede conectar su primer Agente él solo (ensayado tres veces hasta que salió sin trucos), y de propina cayó el fantasma de los enlaces de email que "expiraban"

Edu: la primera ronda automática de mantenimiento se quedó a medias, la rescatamos… y trajo 16 hallazgos que se arreglaron TODOS el mismo día

Edu: la primera ronda automática de mantenimiento se quedó a medias, la rescatamos… y trajo 16 hallazgos que se arreglaron TODOS el mismo día

Edu: las alarmas que llegaban cada hora no eran errores — era una pantalla huérfana; y la secretaria del Correo deja de tartamudear

Edu: las alarmas que llegaban cada hora no eran errores — era una pantalla huérfana; y la secretaria del Correo deja de tartamudear

Edu: tarde de mejoras al editor de racks — clonar, copiar de otro rack, y las traseras que por fin obedecen

Edu: tarde de mejoras al editor de racks — clonar, copiar de otro rack, y las traseras que por fin obedecen

Edu: las copias de seguridad estrenan sus ventanas nuevas, un susto con los vídeos que salvó la Papelera, y la oficina y el CCIB viven por fin en casas separadas

Edu: las copias de seguridad estrenan sus ventanas nuevas, un susto con los vídeos que salvó la Papelera, y la oficina y el CCIB viven por fin en casas separadas

Edu: el sistema de copias de seguridad se hace mayor en un solo día, las pruebas de Edu cazan cuatro fallos reales, y un fantasma del navegador se come la tarde

Edu: el sistema de copias de seguridad se hace mayor en un solo día, las pruebas de Edu cazan cuatro fallos reales, y un fantasma del navegador se come la tarde

Edu: el ordenador de la oficina resucita y queda blindado contra apagones, los dos vigilantes dejan de pisarse, y nace el plan de separar la oficina y el CCIB

Edu: el ordenador de la oficina resucita y queda blindado contra apagones, los dos vigilantes dejan de pisarse, y nace el plan de separar la oficina y el CCIB

Edu: tarde de ir de compras a otros proyectos — seis ideas adoptadas, y el examen nuevo del bibliotecario cazó un fallo el día del estreno

Edu: tarde de ir de compras a otros proyectos — seis ideas adoptadas, y el examen nuevo del bibliotecario cazó un fallo el día del estreno

Edu: día de limpieza a fondo — el asistente arranca más ligero, cuatro tareas cerradas y un susto con el ordenador compartido

Edu: día de limpieza a fondo — el asistente arranca más ligero, cuatro tareas cerradas y un susto con el ordenador compartido

Edu: las alertas de vigilancia por fin vigilan de verdad — de la decisión a producción, probada en vivo, en una tarde

Edu: las alertas de vigilancia por fin vigilan de verdad — de la decisión a producción, probada en vivo, en una tarde

Edu: el ordenador de la oficina se convierte en el trabajador incansable del equipo, y Stripe queda al alcance de los tres

Edu: el ordenador de la oficina se convierte en el trabajador incansable del equipo, y Stripe queda al alcance de los tres

limpieza a fondo del código más cargado, la última pieza de la revisión saldada, y decidido cómo cobraremos

limpieza a fondo del código más cargado, la última pieza de la revisión saldada, y decidido cómo cobraremos

Edu: el fallo gordo de la revisión de mantenimiento queda arreglado, y detrás caen en cascada ocho versiones en un día

Edu: el fallo gordo de la revisión de mantenimiento queda arreglado, y detrás caen en cascada ocho versiones en un día

Dani: el chequeo del método dejaba de avisar de tres averías reales, y la pantalla del WiFi contaba clientes que ya no existían

Dani: el chequeo del método dejaba de avisar de tres averías reales, y la pantalla del WiFi contaba clientes que ya no existían

Edu: la revisión de mantenimiento encuentra 11 fallos escondidos y esa misma tarde salen 3 versiones que arreglan los gordos — con Dani (su Claude) trabajando en paralelo por primera vez

Edu: la revisión de mantenimiento encuentra 11 fallos escondidos y esa misma tarde salen 3 versiones que arreglan los gordos — con Dani (su Claude) trabajando en paralelo por primera vez

Edu: el ordenador compartido de Dani y Txell queda listo para septiembre, montado entero en un día y a distancia

Edu: el ordenador compartido de Dani y Txell queda listo para septiembre, montado entero en un día y a distancia

Edu: el workspace estrena el menú Correo (tu buzón digerido, con chat y encargos) y la máquina nueva del equipo ya está en la red

Edu: el workspace estrena el menú Correo (tu buzón digerido, con chat y encargos) y la máquina nueva del equipo ya está en la red

Edu: el contador de servicios del panel ahora enseña qué es cada cosa

Edu: el contador de servicios del panel ahora enseña qué es cada cosa

Edu: cuatro tareas cerradas y el panel estrena luces de verdad para los servicios

Edu: cuatro tareas cerradas y el panel estrena luces de verdad para los servicios

Dani: el buzón de Dani ordenado entero, y de paso salieron tres fallos del esquema de filtros

Dani: el buzón de Dani ordenado entero, y de paso salieron tres fallos del esquema de filtros

Txell: el buzón ordenado de verdad, y el motivo de que pareciera vacío

Txell: el buzón ordenado de verdad, y el motivo de que pareciera vacío

Edu: Claude ya lee y ordena el correo directamente, y el buzón estrena una organización con lógica

Edu: Claude ya lee y ordena el correo directamente, y el buzón estrena una organización con lógica

Txell: revisión del harness — el guardián de los commits iba con una versión atrasada

Txell: revisión del harness — el guardián de los commits iba con una versión atrasada

Edu: las falsas alarmas del escaneo de seguridad, resueltas el mismo día

Edu: las falsas alarmas del escaneo de seguridad, resueltas el mismo día

Edu: el servidor de código propio se pone a trabajar, y con copia de seguridad probada

Edu: el servidor de código propio se pone a trabajar, y con copia de seguridad probada

Edu: montamos servidor de código propio, para no depender de nadie

Edu: montamos servidor de código propio, para no depender de nadie

Edu: la disponibilidad de los equipos vuelve a significar lo que dice, y el "equipo de mantenimiento" deja de depender de que alguien se acuerde

Edu: la disponibilidad de los equipos vuelve a significar lo que dice, y el "equipo de mantenimiento" deja de depender de que alguien se acuerde

Edu: montamos el "equipo de mantenimiento" que revisa la aplicación funcionando, y en su primer ensayo encontró un fallo que llevaba meses escondido

Edu: montamos el "equipo de mantenimiento" que revisa la aplicación funcionando, y en su primer ensayo encontró un fallo que llevaba meses escondido

Edu: el registro con invitación llegó a producción, el diseño estrenó estándar, y una revisión visual destapó (y enterró) tres averías antiguas

Edu: el registro con invitación llegó a producción, el diseño estrenó estándar, y una revisión visual destapó (y enterró) tres averías antiguas

Edu: el aviso de Txell destapó tres fallos del sistema de trabajo, y acabamos el día desmontando la pieza que los causaba todos

Edu: el aviso de Txell destapó tres fallos del sistema de trabajo, y acabamos el día desmontando la pieza que los causaba todos

Edu: dos vigilantes muertos sin que nadie lo notara, el buzón comercial por fin vivo, y el registro con invitación arranca con veinte fallos cazados antes de escribirlos

Edu: dos vigilantes muertos sin que nadie lo notara, el buzón comercial por fin vivo, y el registro con invitación arranca con veinte fallos cazados antes de escribirlos

Edu: el inspector de mapas se afinó a sí mismo — y de propina cazó un fallo que llevaba 18 días estropeando tres funciones en producción

Edu: el inspector de mapas se afinó a sí mismo — y de propina cazó un fallo que llevaba 18 días estropeando tres funciones en producción

Edu: el semáforo de la wiki llevaba tres semanas en ámbar — y la culpa no era de la wiki, sino de dos errores nuestros

Edu: el semáforo de la wiki llevaba tres semanas en ámbar — y la culpa no era de la wiki, sino de dos errores nuestros

Edu: el Agente ahora enseña lo poco que consume — de una idea de por la mañana a producción antes de comer

Edu: el Agente ahora enseña lo poco que consume — de una idea de por la mañana a producción antes de comer

Edu: el Agente estrena instalador profesional — y la flota entera se actualizó tres veces sin que nadie tocara nada

Edu: el Agente estrena instalador profesional — y la flota entera se actualizó tres veces sin que nadie tocara nada

Edu: día de quitar polvo — seis tareas viejas fuera de la lista y las pantallas ya dicen la verdad sobre su marca

Edu: día de quitar polvo — seis tareas viejas fuera de la lista y las pantallas ya dicen la verdad sobre su marca

Txell: chequeo de salud del método — todo verde, y decisión de quedarse solo con las herramientas del núcleo

Txell: chequeo de salud del método — todo verde, y decisión de quedarse solo con las herramientas del núcleo

Edu: cerramos la revisión del mes de julio — dos tareas "pendientes" resultaron llevar meses hechas sin que nadie las tachara — y comprobamos que la puesta a punto de ayer no rompió nada

Edu: cerramos la revisión del mes de julio — dos tareas "pendientes" resultaron llevar meses hechas sin que nadie las tachara — y comprobamos que la puesta a punto de ayer no rompió nada

Edu: pusimos a prueba de verdad el sistema que avisa cuando algo se rompe — y la prueba cazó una llave caducada que llevaba 2 meses rota sin que nadie lo supiera

Edu: pusimos a prueba de verdad el sistema que avisa cuando algo se rompe — y la prueba cazó una llave caducada que llevaba 2 meses rota sin que nadie lo supiera

Edu: le pasamos "el médico" a nuestro Claude y salió sano — pero con 22 herramientas en la mochila que no usaba nunca; se las quitamos y ahora arranca más ligero

Edu: le pasamos "el médico" a nuestro Claude y salió sano — pero con 22 herramientas en la mochila que no usaba nunca; se las quitamos y ahora arranca más ligero

Edu: estrenamos el "cuaderno de apuestas" y la primera apuesta se resolvió el mismo día — la IA en servidor propio para el Auto-Plan NO da la talla (probado con datos por 2 €)

Edu: estrenamos el "cuaderno de apuestas" y la primera apuesta se resolvió el mismo día — la IA en servidor propio para el Auto-Plan NO da la talla (probado con datos por 2 €)

Txell: segundo repaso del día — sigo en verde y el arreglo que hizo Edu esta tarde ya funciona solo en mi ordenador

Txell: segundo repaso del día — sigo en verde y el arreglo que hizo Edu esta tarde ya funciona solo en mi ordenador

Txell: chequeo de salud del harness — verde en mi perfil, Dani rancio y dos flecos del automatismo de ayer

Txell: chequeo de salud del harness — verde en mi perfil, Dani rancio y dos flecos del automatismo de ayer

Edu: estreno del auditor del mapa — encontró mentiras activas y se arreglaron TODAS el mismo día

Edu: estreno del auditor del mapa — encontró mentiras activas y se arreglaron TODAS el mismo día

Edu: un video de YouTube bien exprimido — el método gana un "auditor de veracidad", una regla de reparar el mapa y vocabulario nuevo

Edu: un video de YouTube bien exprimido — el método gana un "auditor de veracidad", una regla de reparar el mapa y vocabulario nuevo

Edu: día de liquidar deudas — la factura de Hetzner al céntimo, la documentación desempolvada, dos tareas viejas cerradas y el atlas técnico al día

Edu: día de liquidar deudas — la factura de Hetzner al céntimo, la documentación desempolvada, dos tareas viejas cerradas y el atlas técnico al día

Edu: día de cerrar temas — tres mejoras publicadas, el Agente actualizado en toda la flota, y un fallo escurridizo cazado en directo

Edu: día de cerrar temas — tres mejoras publicadas, el Agente actualizado en toda la flota, y un fallo escurridizo cazado en directo

Edu: Integrity se muda dentro de Observatory, pestañas por fin visibles, y guerra declarada a los fallos repetidos al subir código

Edu: Integrity se muda dentro de Observatory, pestañas por fin visibles, y guerra declarada a los fallos repetidos al subir código

Edu: comprobado en real que los equipos que bloquean el ping ya no salen "caídos" por error

Edu: comprobado en real que los equipos que bloquean el ping ya no salen "caídos" por error

Edu: el Agente se actualiza solo de verdad, y de paso cazamos un fallo que cortaba las conexiones de todo el producto

Edu: el Agente se actualiza solo de verdad, y de paso cazamos un fallo que cortaba las conexiones de todo el producto

Edu: un documento para presentaros las novedades, el menú de Informes por fin ordenado, y el correo blindado al máximo

Edu: un documento para presentaros las novedades, el menú de Informes por fin ordenado, y el correo blindado al máximo

Edu: la Barra de Integridad ya abre incidencias sola, y de paso destapamos cuatro fallos escondidos en la monitorización

Edu: la Barra de Integridad ya abre incidencias sola, y de paso destapamos cuatro fallos escondidos en la monitorización

Edu: nace la "Barra de Integridad", el radar que avisa cuando el plano ya no dice la verdad

Edu: nace la "Barra de Integridad", el radar que avisa cuando el plano ya no dice la verdad

Edu: la web pública lista para Google, sabemos lo que nos cuesta cada cliente, y los equipos que bloquean el ping ya no salen caídos

Edu: la web pública lista para Google, sabemos lo que nos cuesta cada cliente, y los equipos que bloquean el ping ya no salen caídos

Edu: estudio de precios con veredicto, los racks avisan cuando se pasan de potencia o peso, y un fallo de despliegue cazado a tiempo

Edu: estudio de precios con veredicto, los racks avisan cuando se pasan de potencia o peso, y un fallo de despliegue cazado a tiempo

Edu: las operaciones lentas (crear un mapa con IA, copias de seguridad) dejan de congelar la aplicación

Edu: las operaciones lentas (crear un mapa con IA, copias de seguridad) dejan de congelar la aplicación

Edu: día de liquidar pendientes + los despliegues pasan de 15 minutos a segundos

Edu: día de liquidar pendientes + los despliegues pasan de 15 minutos a segundos

Edu: Txell ya puede volver a trabajar con el asistente — su conexión usaba una contraseña caducada

Edu: Txell ya puede volver a trabajar con el asistente — su conexión usaba una contraseña caducada

Edu: día de seguridad — cerramos puertas que sobraban en los servidores y reforzamos el acceso

Edu: día de seguridad — cerramos puertas que sobraban en los servidores y reforzamos el acceso

Edu: el importador de Visio queda terminado — pantalla nueva, prueba con ficheros reales de fabricante y dos arreglos cazados en directo

Edu: el importador de Visio queda terminado — pantalla nueva, prueba con ficheros reales de fabricante y dos arreglos cazados en directo

Edu: día de producto — el Agente te dice dónde instalarlo, el Dashboard se ordena arrastrando, y arranca el nuevo import de Visio

Edu: día de producto — el Agente te dice dónde instalarlo, el Dashboard se ordena arrastrando, y arranca el nuevo import de Visio

Edu: día de seguridad — cerramos las puertas traseras de los servidores y blindamos el correo contra suplantación

Edu: día de seguridad — cerramos las puertas traseras de los servidores y blindamos el correo contra suplantación

Edu: la página de Dependencias se convierte en la chuleta del Tech Stack — ficha de cada pieza y tarjetas que filtran

Edu: la página de Dependencias se convierte en la chuleta del Tech Stack — ficha de cada pieza y tarjetas que filtran

Edu: la página de Dependencias aprende a hablar claro, vigila la seguridad… y estrena oficio dejando todo el software al día

Edu: la página de Dependencias aprende a hablar claro, vigila la seguridad… y estrena oficio dejando todo el software al día

Edu: el editor de mapas da el salto a otra liga — biblioteca de formas profesionales estilo draw.io

Edu: el editor de mapas da el salto a otra liga — biblioteca de formas profesionales estilo draw.io

Edu: revisión a fondo del workspace del equipo — orden en los agentes, wiki al día y un candado en la facturación

Edu: revisión a fondo del workspace del equipo — orden en los agentes, wiki al día y un candado en la facturación

Edu: cerramos la revisión de seguridad echando el candado que faltaba en la base de datos de producción

Edu: cerramos la revisión de seguridad echando el candado que faltaba en la base de datos de producción

Edu: rematamos la revisión de seguridad y la subimos a producción (rendimiento, robustez y calidad incluidos)

Edu: rematamos la revisión de seguridad y la subimos a producción (rendimiento, robustez y calidad incluidos)

Edu: la web pública de CreaRack ya cuenta la historia completa (y con vídeo real del producto)

Edu: la web pública de CreaRack ya cuenta la historia completa (y con vídeo real del producto)

Edu: revisión de seguridad a fondo de CreaRack — tapamos 19 agujeros (con su prueba cada uno) antes de que los sufra un cliente

Edu: revisión de seguridad a fondo de CreaRack — tapamos 19 agujeros (con su prueba cada uno) antes de que los sufra un cliente

Edu: los globitos explicativos y el estilo oscuro llegan a TODA la web interna (y la dejamos más limpia por dentro)

Edu: los globitos explicativos y el estilo oscuro llegan a TODA la web interna (y la dejamos más limpia por dentro)

Edu: dejamos en VERDE los semáforos de "Salud del Sistema" (que estaban en rojo y naranja)

Edu: dejamos en VERDE los semáforos de "Salud del Sistema" (que estaban en rojo y naranja)

Edu: sesión de producto (paralela) — el menú del panel más ordenado, el Agente más fácil de instalar, y el aviso de la vigilancia 24/7 bien claro

Edu: sesión de producto (paralela) — el menú del panel más ordenado, el Agente más fácil de instalar, y el aviso de la vigilancia 24/7 bien claro

Edu: día grande de método y diseño — arreglamos cómo escriben los informes, les damos casa propia, y decidimos ir 100% a por el software

Edu: día grande de método y diseño — arreglamos cómo escriben los informes, les damos casa propia, y decidimos ir 100% a por el software

Edu: día de limpieza — cerramos cabos sueltos y quitamos una molestia recurrente al subir cambios

Edu: día de limpieza — cerramos cabos sueltos y quitamos una molestia recurrente al subir cambios

Edu: ¿y si el Agente funcionara también en Linux y Raspberry Pi? Lo pasamos por el "consejo de la muerte" antes de gastar un minuto

Edu: ¿y si el Agente funcionara también en Linux y Raspberry Pi? Lo pasamos por el "consejo de la muerte" antes de gastar un minuto

Edu: el Agente ya se actualiza solo y en silencio — objetivo cumplido, probado en dos ordenadores y en producción

Edu: el Agente ya se actualiza solo y en silencio — objetivo cumplido, probado en dos ordenadores y en producción

Edu: el escudo de Cloudflare delante del producto, y el gran empeño con las actualizaciones del Agente (avance real, pero aún no cerrado)

Edu: el escudo de Cloudflare delante del producto, y el gran empeño con las actualizaciones del Agente (avance real, pero aún no cerrado)

Edu: revisión de seguridad de Cloudflare — una alarma que no era, un arreglo de verdad (www) y dos deberes

Edu: revisión de seguridad de Cloudflare — una alarma que no era, un arreglo de verdad (www) y dos deberes

Edu: el incidente de la enciclopedia cerrado del todo (5$/mes bien gastados), el método de Fable pulido con material nuevo, y dos secretos del harness al descubierto

Edu: el incidente de la enciclopedia cerrado del todo (5$/mes bien gastados), el método de Fable pulido con material nuevo, y dos secretos del harness al descubierto

le extrajimos el "cerebro" a Fable antes de perderlo, y la enciclopedia enferma resultó ser un problema de plan barato

le extrajimos el "cerebro" a Fable antes de perderlo, y la enciclopedia enferma resultó ser un problema de plan barato

la enciclopedia de arquitectura completa al 100%, visible en el mapa, y arranques de sesión más ligeros

la enciclopedia de arquitectura completa al 100%, visible en el mapa, y arranques de sesión más ligeros

Edu: el dashboard gana altura y el misterio de las actualizaciones del Agente, resuelto viéndolo fallar en directo

Edu: el dashboard gana altura y el misterio de las actualizaciones del Agente, resuelto viéndolo fallar en directo

Edu: los mapas de arquitectura al día, y de paso cayeron dos bugs que llevaban tiempo escondidos

Edu: los mapas de arquitectura al día, y de paso cayeron dos bugs que llevaban tiempo escondidos

Edu: la wiki del equipo ahora se ve como un mapa vivo

Edu: la wiki del equipo ahora se ve como un mapa vivo

Edu: se cierra la "gran revisión" de julio y el asistente de ayuda por fin escribe en directo

Edu: se cierra la "gran revisión" de julio y el asistente de ayuda por fin escribe en directo

Edu: la "memoria del equipo" ahora escribe mejor, se conecta sola y tiene el índice limpio

Edu: la "memoria del equipo" ahora escribe mejor, se conecta sola y tiene el índice limpio

Edu: gran limpieza de la lista de pendientes — la reforma interna de los monitores queda terminada, el programa al día, y el "guardián" de GitHub vuelve a vigilar

Edu: gran limpieza de la lista de pendientes — la reforma interna de los monitores queda terminada, el programa al día, y el "guardián" de GitHub vuelve a vigilar

Edu: las gráficas de monitorización por fin "viven" — cada equipo con su propio ritmo de sondeo, elegible desde su ficha

Edu: las gráficas de monitorización por fin "viven" — cada equipo con su propio ritmo de sondeo, elegible desde su ficha

Edu: revisión a fondo de la "memoria" del equipo — más ligera, más limpia, con su escritor automático de vuelta y la Ayuda respondiendo en vivo

Edu: revisión a fondo de la "memoria" del equipo — más ligera, más limpia, con su escritor automático de vuelta y la Ayuda respondiendo en vivo

Edu: el asistente aprende de sus errores, las subidas de código quedan blindadas, y GitHub nos jugó una mala pasada

Edu: el asistente aprende de sus errores, las subidas de código quedan blindadas, y GitHub nos jugó una mala pasada

🏗️ Adiós al racionamiento de GitHub: servidor propio para los tests + tarde de pulido de gráficas

🏗️ Adiós al racionamiento de GitHub: servidor propio para los tests + tarde de pulido de gráficas

Edu: maratón de limpieza a fondo del producto — más rápido, más seguro y con miles de líneas duplicadas fuera

Edu: maratón de limpieza a fondo del producto — más rápido, más seguro y con miles de líneas duplicadas fuera

Edu: seguridad SNMP en producción, susto (resuelto) con el auto-update del Agente, y ahorro de los minutos de GitHub

Edu: seguridad SNMP en producción, susto (resuelto) con el auto-update del Agente, y ahorro de los minutos de GitHub

Edu: revisión en frío del ordenador de Txell tras los últimos cambios del método

Edu: revisión en frío del ordenador de Txell tras los últimos cambios del método

Edu: reviso el harness de Dani tras la actualización y arreglo de raíz por qué CreaRack-Pro se quedaba siempre desactualizado

**Diagnóstico** — el `SessionStart` (`claude-method-sync.ps1`) solo hace `git pull --rebase` de `claude-method` (paso 1); `CreaRack-Pro` y el resto de repos de la org nunca se pulleaban en el arranque → drift crónico (117 commits detrás en el PC de Dani). `method-doctor` perfil `dani` VERDE.

Edu: chequeo médico completo del producto + primeros arreglos + el "vigilante" que evita que las actualizaciones maten el Agente

**Flecos s186** — `plugin/` v1 retirado de claude-method (`69dff8d`) · PR #232 ya merged · **PR #233** (4 fragments `.po` i18n huérfanos + `media/signage/` al `.gitignore`). `main` de Pro ya no acepta push directo (2 required checks) → todo por PR.

Edu: repaso a fondo de "cómo trabajamos" (orden, documentación y seguridad) + poner a prueba las copias de seguridad

**Auditoría (6 subagentes Opus solo-lectura)**: método/sync · reglas vs realidad · automatismos/CI · arquitectura SaaS · seguridad/backups · mapa documental. ~30 hallazgos, todos rectificados en la sesión.

🔌 La caja de herramientas de los Claude, empaquetada en plugins + limpieza a fondo del método

🔌 La caja de herramientas de los Claude, empaquetada en plugins + limpieza a fondo del método

Edu: terminar la cartelería digital en el "ayudante local" + que actualizar el Agente deje de romperse

Edu: terminar la cartelería digital en el "ayudante local" + que actualizar el Agente deje de romperse

Edu: 3 vídeos de Nate → herramientas nuevas del asistente + sanear dos avisos del panel + arreglar el widget de Servidores

Edu: 3 vídeos de Nate → herramientas nuevas del asistente + sanear dos avisos del panel + arreglar el widget de Servidores

Edu: llevar la cartelería digital (Signage) al "ayudante local" + blindar las actualizaciones del Agente

Edu: llevar la cartelería digital (Signage) al "ayudante local" + blindar las actualizaciones del Agente

Edu: afinar el "motor" del asistente — aviso automático de trampas + auditoría a fondo del harness + preparar su empaquetado como plugin

sesión de "afilar la herramienta", nada que vea el cliente. Tres cosas. (1) A partir de un repo de GitHub que pasó Edu, le añadimos al asistente un **aviso automático**: justo antes de tocar un archivo o lanzar un comando, le recuerda la "trampa" conocida que aplica (por ejemplo, "ojo, esta variable de Dokploy se comporta raro"), sin tener que acordarse de mirarlo. Ya está activo para los tres y se pasó toda la sesión acertando. (2) Le hicimos una **auditoría a fondo** a todo el sistema de reglas y scripts del asistente (el "harness"): 13 revisores en paralelo encontraron **59 cosas a mejorar** — el veredicto es que la lógica está madura, pero la parte de "instalación" es un montón de scripts de Windows repetidos y atados a rutas fijas. (3) Empezamos a **empaquetarlo como un "plugin"** (un formato estándar que se instala limpio, igual para los tres): dejamos todo preparado y documentado, pero el cambio final (que pide reiniciar el asistente) lo haremos con calma en la próxima, para no romper nada con prisas al final de una sesión muy larga. De paso arreglamos un par de fallos que la propia auditoría pilló en código de hoy mismo. Todo esto es herramienta interna; el producto no se tocó. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · sesión transversal harness/method · todo en claude-method + memorias, sin código de producto): - **3 cherry-picks de `claude-smart` + 1 metodológico → PROD** (claude-method `1efafcc`, propagado a los 3): **mem-surfacer** (hook PreToolUse, auto-match local sobre slug+description de las memorias, anti-ruido + fail-open ~90ms) · self-harness amplía a success-paths + taxonomía 3 destinos · captura de correcciones en caliente · eje "¿reemplazar?" en el rito de evaluación. Repo descartado como sistema (backend propietario + server local → Regla 17); solo cherry-picks. - **Auditoría profunda** (Workflow 13 agentes / 6 lentes / 59 hallazgos 11·33·15) → informe `claude-method/audit/AUDITORIA_HARNESS_2026-06.md`. Cazó 2 bugs míos del día (matcher surfacer sin PowerShell; projectKey divergente). - **Quick-wins mergeados** (`3330cc2`): fix surfacer (PowerShell + projectKey espacios, instalador con reconcile) + doc-rot verificada (`check_astro_schemas` es función de `pre_commit_check.py`, no fichero; skills 14→15). Verificado cada hallazgo antes de aplicar. - **🔌 Plugin Fase 1 PREPTA** (branch `edu/harness-plugin-phase1`, pusheada): plugin.json+hooks.json+marketplace.json + `guides/PLUGIN_MIGRATION.md` (runbook). Alcance = 3 hooks Python autocontenidos. **Cutover en vivo pendiente** (reinicio + settings.json + main) → memoria `project_harness_plugin_migration`. - **Método/footguns**: Workflow con OK+estimación de Edu (70% cuota). Footgun nuevo `footguns_mem_surfacer_missing_script_bricks_tools`. MEMORY.md compactado (15 evals → índice). _Cierre por "apaga"._

Edu: por fin, un equipo descubierto se abre directo en el Terminal (+ borrarlo de un clic + la página en español)

hemos rematado de raíz el problema que llevaba varias sesiones dando guerra. Cuando descubrías un equipo de red (un punto wifi, un switch…), aparecía en el Terminal en **gris** y al pulsarlo te **pedía la contraseña** (y encima mostraba una que no era), en vez de abrirse directo. Resulta que el descubrimiento **sí guardaba bien las credenciales** — el fallo estaba en cómo el Terminal las **leía**. Lo arreglamos: ahora el equipo sale en **verde** y **abre la sesión directo, sin pedir nada**, y la contraseña la resuelve el Agente de forma segura (nunca pasa por el navegador). Edu lo probó con el punto wifi Xirrus y funcionó. Para llegar ahí, primero **vaciamos los dispositivos de prueba y volvimos a descubrir desde cero** (con una herramienta nueva), para descartar que el problema fuera "suciedad" acumulada — y así confirmamos que era cosa del código. De paso, al recompilar el Agente salió un fallo de arranque que también dejamos arreglado, y comprobamos que **el Agente se actualiza solo, sin que nadie toque nada** (algo que Edu quería verificar). Además, le pusimos a la página **"Device"** un botón **Borrar** que quita un equipo de todos lados de un clic (antes había que hacerlo en dos sitios distintos y poco intuitivos) y **tradujimos esa página al español**. Con todo esto damos por **cerrada** la iniciativa de "una sola ficha por dispositivo". Para la próxima, Edu lo probará a lo grande descubriendo todas las VLANs de golpe. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · 5 PRs Pro #216–#220 · v1.34.0+1.35.0 · Local Agent 2.10.0 · Release `agent-v2.10.0`): - **Diagnóstico (`diagnose`)**: comando nuevo `manage.py wipe_org_devices --org N` (PR #216, org-scoped: DeviceProfile + MonitoringTarget+cascada + scans/hostkeys/tasks + Devices gestionados; dry-run por defecto) → wipe de la org Domo + re-discover limpio → el bug PERSISTIÓ → no era data sucia. El perfil del Xirrus guarda bien `supports_ssh`+`ssh_username`+pass cifrada → hipótesis del plan (`_ssh_ok`/`authenticated`) REFUTADA. Raíz = lado lectura del Terminal. - **Fix Terminal directo (PR #217, v1.34.0 · Agent 2.10.0)**: `terminal/services.py` status `online` si `has_stored_ssh` (antes `unknown` fijo → siempre gris); `templates/terminal/index.html` + `static/js/pages/terminal.js` (`openProfileSession` + helper `_spawnSessionTab`) abren directo pasando `profile_id`; `ssh_client.js` lo manda en `CONNECT_SSH`; **Agente** `terminal/agent/routes/terminal.py` + `assets/terminal.html` aceptan `profile_id` → `fetch_profile_credentials` (R3, server-side). 2 tests de regresión. - **Fix build Agente (PR #218)**: `build_agent.bat` += hidden-imports asyncio Windows (`_overlapped`/`_asyncio`/`_winapi`/`asyncio.windows_events`/`windows_utils`) — el `.exe` 2.10.0 crasheaba al arrancar en Python 3.14. Auto-update validado E2E sin intervención (manifest por `version.py` desplegado + SHA-256 del `.exe` servido; sin redeploy). - **Capstone (PR #220, v1.35.0)**: `DELETE /auto-provision/profiles/{id}/full` (perfil + target de misma (org,ip), conserva rack; `require_perm`; 3 tests) + botón Delete en `devices.html`/`devices.js` + **i18n ES** (`locale/es` django 24 + djangojs 6, vía `merge_po_fragments`, fragmentos `scripts/i18n/fragments_device*`) + ayuda `crearack--network--device-page`. - **🅿️ Deuda menor**: el `×` "Delete target" de Observatory no se pinta (código VIVO `ObservatoryDeviceList.js:112`+`observatory.js:871`, NO huérfano → diagnosticar, no borrar) · preload warnings `/devices` · `network/models.py` ~500 LOC. - **Método**: 5 PRs verificados con Vigía + tests Docker + auto-merge al verde. Footgun: `git push 2>&1 | tail` enmascara el RC del push. _Cierre por "apaga"._

Edu: instaurar "Self-Harness" (que el propio asistente mejore sus reglas) + propagarlo al equipo + mejoras del entorno

hoy ha sido sesión de "afilar la herramienta", no de tocar el producto. A raíz de un paper montamos un sistema que llamamos **Self-Harness**: que el asistente **revise sus propios fallos pasados y proponga mejoras a sus reglas**, sin aplicar nada sin tu visto bueno. Quedó como un comando reutilizable (`/self-harness`) para los tres. De la primera pasada salieron y aprobaste **cuatro mejoras de reglas** (no pisarnos cuando hay dos sesiones abiertas a la vez, un footgun de la wiki que tumbaba la web, comprobar que algo está "verde" de verdad, y una advertencia sobre el Vigía) — ya en producción. Pusimos también una **red de seguridad automática** contra un error de tecleo recurrente al hacer commits desde PowerShell, que se instala sola en los tres equipos. Activamos el **modo pantalla completa** de la consola para todos (a ti te gustó; Dani y Txell lo reciben en su próximo arranque y cada uno puede desactivarlo). Y evaluamos un repo de GitHub que pasaste: el grueso no servía, pero le sacamos una técnica de "probar las mejoras antes de darlas por buenas" que incorporamos al propio Self-Harness. Nada de esto toca lo que ve el cliente: es herramienta interna del equipo. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · PR Pro #215 + 5 commits claude-method · sesión transversal harness/method, sin código de producto): - **Self-Harness** (paper arXiv:2606.09498 → bucle pragmático sin benchmark/API/Workflow): skill `/self-harness` (minar fallos de LOG/feedbacks/footguns/BONSAI → parches mínimos y reversibles → validar antes de promover; nunca auto-promueve). Promovido a `claude-method/global-skills` (generalizado, Paso 0 descubre fuentes locales por proyecto). Memoria `project_self_harness`. - **Tanda 1 de parches de reglas (PR #215, squash a `main`, `8d5414da`)**: #1 sesiones concurrentes → aislar en worktree (CLAUDE.md §2) · C1 footgun schema `sources` de `wiki_create_page` (WIKI.md) · C2 "verifica el efecto, no la señal" — todos los workflows del commit + commit mudo (Regla 14) · C4 caveat Vigía (Regla 14). Solo docs/reglas (3 archivos). - **C3 · guard `commit-msg`** (`claude-method/harness/commit_msg_check.py` + `commit-msg.hook`): aborta el footgun here-string de PowerShell (`-m @'...'@`→`@`). Convergente vía `install-git-hooks.ps1` (pre-push + commit-msg en cada arranque, los 3 perfiles). Validado E2E sandbox (8/8); activo en la máquina de Edu (5 repos org). - **`tui: fullscreen`** en `claude-method/global-settings/settings-base.json` → `apply-claude-settings` lo mergea en los 3 perfiles (preserva hooks/settings.local). Override personal vía `settings.local.json`. - **Eval `revfactory/harness`**: NO adoptar el plugin (agent-teams experimentales, redundante con Workflow + `MASTER_WORKFLOW_PATTERN`). Cherry-picks de su `skill-testing-guide` al Paso 3 de Self-Harness: A/B con-skill vs baseline, assertions no-discriminantes, trigger-eval del `description`, verificador ciego. Memoria `reference_revfactory_harness_evaluation`. - **Método**: todo aislado en worktree (`edu/self-harness`) mientras s178 (Ficha Central) corría en paralelo en el mismo checkout; rebase + PR + merge al cerrar ella (`main` protegida → PR, no push directo). 5 pushes a claude-method verificados HEAD==origin. _Cierre por "apaga"._

Edu: cerrar el EPIC "el Agente hace toda la red" (limpieza del descubrimiento) + 🔄 que el Agente se actualice SOLO y en silencio

hoy hemos rematado dos cosas grandes. **Primero**, validaste en producción que leer los puertos de un switch (lo de ayer) funciona con un equipo real, y dejamos hecha la **limpieza final del descubrimiento de red**: quitamos el código viejo del servidor que escaneaba la red (un `nmap` y un sondeo web que no llegaban a las redes privadas y ya no usaba nadie). **Y lo más importante**: ahora **el Agente se actualiza solo, sin que nadie haga ni vea nada**. Como cada vez dependemos más del Agente, tener uno viejo rompía cosas; así que montamos un sistema en el que el servidor avisa al Agente de que hay versión nueva y este **se descarga la actualización, comprueba que es auténtica (su huella) y se reemplaza él mismo** — siempre cuando no estás trabajando (sin terminales abiertas), para no cortarte. Fiel a la norma de siempre: el usuario nunca ve el mantenimiento del Agente. Compilaste e instalaste la **versión 2.9.0** (que ya estrena esta capacidad y, de paso, se sube sola a nuestro servidor al compilar). Este salto a la 2.9.0 es el único que hay que hacer a mano; a partir de aquí, las siguientes se ponen solas. Lo dejamos todo en producción, con su Release en GitHub y la documentación al día. Para la próxima queda solo mover los **carteles digitales (signage)** al Agente para cerrar el 100% de la iniciativa. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · 5 PRs Pro #201–#205 + Release `agent-v2.9.0` + README/docs): - **F3 cerrado (#201, v1.23.0)**: Edu validó "Refresh Ports" vía Agente en PROD (switch real). Confirmado que el Agente "revive solo" al abrir una sesión SSH = el handler de protocolo `crearack://start` (registrado en Windows por el installer) que lanza el `.exe`; "Refresh Ports" NO lo relanza (muestra "Local Agent required" si está caído). Mergeado + `.exe` 2.8.0 a Hetzner. - **F4 (#202, v1.24.0)**: retirados `discover_nmap()`/`detect_vendor_http()` (`network/services/device_discovery/service.py`) + endpoint `POST /auto-provision/bulk-discover` + `bulk_provision_subnet()` + schema `BulkDiscoverRequest` + guard `validate_subnet`/`MAX_SUBNET_HOSTS` (`scan_guard.py`) + plumbing `nmap_data` (`provision_stages.py`) + `infer_device_type_from_nmap` (`scoring.py`). El `bulk-discover` no tenía caller frontend desde F2.2 (el rango usa `/bulk-enrich` vía Agente). +37/−472, 48 tests. Rama `discover_ssh` server-side señalada vestigial (F6). - **Auto-update · #203**: `build_agent.bat` añade paso 5.5 = `scp` del `.exe` a `/tmp` en `root@crearack.com` + `docker cp` al volumen `app_media` (contenedor web resuelto con `docker ps|grep -web-N`). Si falla el SSH, avisa pero no rompe el build. - **Auto-update lado SaaS · #204 (v1.25.0)**: `core/agent_release.py` (`get_latest_agent_version` lee `terminal/agent/version.py`; `get_agent_sha256` cacheado por mtime/size; `is_outdated`; `agent_update_payload`). `GET /api/agent/manifest` (`terminal/api/agent_update.py`, JWT del Agente). Push `command:agent_update {version,sha256,url}` en el heartbeat `ping` (`terminal/consumers.py`, dedup por versión reportada). `core/views.py::download_agent` acepta el JWT del Agente además de sesión. +5 tests (`tests/api/test_agent_update.py`). - **Auto-update lado Agente · #205 (v1.26.0 · Agent 2.9.0)**: `terminal/agent/core/updater.py` — `handle_agent_update` (handler WS), `check_manifest_on_startup`, `apply_staged_if_present`+`cleanup_old_exe`, `_download_and_verify` (SHA-256), `_apply_swap` (renombrado cur→old/new→cur + `relaunch_from_install_dir` + `os._exit`), `_is_idle` (vía `network.ssh.ACTIVE_BRIDGES`), staging con `update.json`. `main.py`: `register()` del handler + chequeo al arrancar + `run_startup_checks()` en lifespan. Regla 5: extraídos `load_asset`/`load_json_asset` a `terminal/agent/core/assets.py` (main.py < 500 LOC), `routes/network.py` los importa de ahí. `build_agent.bat` empaqueta `updater.py`+`assets.py`. `version.py` → 2.9.0. - **Release**: `agent-v2.9.0` con el `.exe` (sha `e8221976…`, verificado local==Hetzner==release); retirado el `.exe` del release `agent-v2.8.0` (tag conservado). - **Docs**: README a v1.26.0/Agent 2.9.0; `context/INFRA.md` (publicación automática + manual de fallback). PROD verificado (SSH): APP 1.26.0 / Agent 2.9.0. - **Deuda viva**: fichas Atlas `terminal`/`core`/`network` flagueadas → regen post-1-jul (workflow, bajo consenso de coste). Sin Ayuda Viva para el auto-update (invisible al usuario, Regla 27). F5 (signage) = lo único para el 100% del EPIC.

Edu: que leer los puertos de un switch funcione también en redes privadas (lo hace el Agente) + cerrar 2 candados de seguridad pendientes

hoy hemos arreglado de raíz que **"Refresh Ports" (leer los puertos y las VLAN de un switch) funcione también con los equipos que están en la red privada del cliente**. Antes lo intentaba el servidor —que no llega a esas redes— y fallaba; ahora lo hace el **Agente local**, que sí está dentro de la red. De paso quitamos el código viejo del servidor que ya no hacía falta. Quedó todo hecho y probado por dentro; solo falta que lo pruebes tú con un switch de verdad. Publicamos también la **nueva versión del Agente (2.8.0)** que compilaste. Y cerramos **dos ajustes de seguridad** que quedaban de la auditoría: uno endurece el control de acceso del Workspace y otro **cifra las contraseñas de Zoho** (tú reconectaste las tres cuentas). Para la próxima: aún quedan los **carteles digitales (signage)** por mover al Agente para que esta iniciativa quede al 100%. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · PR Pro #201 v1.23.0 + Local Agent 2.8.0 + Release · config CF vía MCP): - **EPIC Full-Local Agent · F3 (#201, CI verde, pendiente click-test)**: paquete `terminal/agent/network/port_config/` portado del server-side (helpers/snmp_reader/reader idénticos; `ssh_reader` reescrito sobre asyncssh+PTY, patrón config_backup). Ruta Agente `POST /network/read-port-config` + `run_read_port_config`. Backend `GET /api/agent/profile-port-context/{id}` (R3: creds+vendor+ssh_platform+interfaces) + `fetch_profile_port_context`. Empaquetado en `build_agent.bat`. Cutover `static/js/editor/PropertiesPanelEvents.js` (botón → Agente, sin fallback; retirada la rama SSH-supplement redundante + `_getSshVlanCommands`). Retirado el lector server-side: endpoint `read-port-config` + schema `ReadPortConfigRequest` (`common.py`) + `test_network_read_port_config.py` (−271 LOC). Paquete `port_config_reader/` conservado (lo reusa `parse-ssh-vlan-output`). i18n F4 (2 strings) + README 1.23.0/2.8.0. Tests Docker verde (r3 +4, sa3, suite 42). Release `agent-v2.8.0` con el .exe. - **2 secrets CF (MCP Cloudflare, proyecto crearacksl-workspace)**: WS1-A2 `CF_ACCESS_ENFORCE=1`+`CF_ACCESS_TEAM_DOMAIN`+`CF_ACCESS_AUD` (6 AUD) → enforce del JWT de CF Access, no-lockout verificado; merge seguro de env_vars + re-deploy por el workflow CF Pages Deploy. WS5-A2 `ZOHO_TOKEN_KEY` AES-GCM + re-auth Zoho ×3 → refresh/access cifrados `v1:` a la cuenta correcta (footgun: `prompt=consent` no fuerza cambio de cuenta). - **Pendiente**: click-test de Edu (Refresh Ports) → merge #201 + subir el .exe 2.8.0 a Hetzner. EPIC ~80%: faltan **F5** (signage) + **F4** (limpieza nmap/HTTP) para el 100%.

Edu: un único "Editar ficha" del equipo accesible desde todas partes (con sus credenciales) + traducir y documentar

hoy hemos hecho que **editar la "ficha" de un equipo sea lo mismo en cualquier pantalla**. Antes solo podías editarla desde el descubrimiento de red; ahora hay un botón **"Edit Card"** en el descubrimiento, en Observatory, en Wireless, en UPS y en la barra del Terminal, y todos abren **exactamente el mismo editor**. Además, a petición tuya, ese editor ahora reúne **todo lo del equipo en un solo sitio**: su identidad (nombre, tipo, fabricante, rol, ubicación, notas), sus **credenciales** (SNMP y las de SSH: usuario, contraseña y "enable") y sus grupos — y por eso hemos **quitado el botón "Config"** que estaba aparte y hacía a medias lo mismo. Todo respetando la seguridad: las contraseñas **nunca se muestran** (salen en blanco con "déjalo en blanco para conservar") y se guardan cifradas. Probaste antes la parte de la sesión anterior y funcionaba; esto nuevo lo probarás online tras el despliegue. Para rematar, **traduje al español** todos los textos nuevos y **actualicé la página de ayuda** del descubrimiento para explicar el editor. Una cosa curiosa: ibas a pedirme rematar unos arreglos de seguridad de la auditoría con GLM, pero al mirarlo **ya estaban hechos** de una sesión anterior — así que no tocamos nada y dejé la nota corregida para que no despiste. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · 2 PRs Pro: #199 v1.21.0 + #200 v1.22.0 · + push i18n directo a main + 1 commit Ayuda en workspace): - **Edit Card centralizado (#199, v1.21.0)**: nuevo módulo único `static/js/network/device_card_editor.js` (`window.DeviceCardEditor.open({profileId} | {ip,name})`) que extrae la pestaña Edit (Parte B) del modal de Auto-Provision (`results.js`, eliminados `editHtml`/`_saveProfileCard`/`_resetProfileField`). Enganchado en 5 vistas: Auto-Provision (botón en el footer del View), Observatory (`ObservatoryTabs.js`, por ip+name), Wireless/`WirelessDetail.js` y UPS/`UpsDetail.js` (por profileId directo), y la barra del Terminal (`TerminalToolbar.js` + IP propagada desde `terminal.js`). Backend: `POST /api/network/auto-provision/device-card/resolve` (`network/api/profiles.py`, get-or-create del DeviceProfile por (org,ip), `discovery_method="manual"`) + schemas en `common.py`. 4 tests. Script cargado en las 4 plantillas. - **Edit Card unificado (#200, v1.22.0)**: el editor pasa a 3 secciones (Identidad + Credenciales SNMP/SSH/enable + Grupos), reutilizando los endpoints `/config` (`network/api/assign.py`). Migración network `0054` (`DeviceProfile.ssh_enable_password_encrypted`, Fernet). `assign.py`: GET expone `has_stored_enable`, PUT acepta `ssh_enable_password`. Retirado el botón "Config" + wiring de Observatory/Wireless/UPS + include huérfano de `DeviceConfigModal.js` en sus 3 plantillas (se conserva para Signage). 3 tests. `network/models.py` quedó en 500 LOC (refactor de los getters SSH a helper; accessor de descifrado del enable diferido por YAGNI — deuda anotada). - **i18n F4**: 28 msgids nuevos al `locale/es/LC_MESSAGES/djangojs.po` (Edit Card + modal SSH `SshConfigModal.js` de s173) vía `scripts/i18n/merge_po_fragments.py` (0 conflictos), `check_po` 0 errores, `compilemessages` + tests i18n verde. Push directo a `main` (`0b419df9`). - **Ayuda Viva (Regla 27)**: `wiki_update_content` sobre `crearack--network--auto-provision-wizard` (sección nueva "Editing a device's card" + corregida la descripción del botón View; commit workspace `c191dfce`). - **Verificación PROD**: `showmigrations network` por SSH → 0053 y 0054 `[X]` aplicadas (Dokploy auto-migró #200). - **GLM Tanda D**: verificado contra `main` que los 2 oros (WS4-G1 `oraculo/ask.ts`, WS3-G1 `mcp/index.ts`) y el resto ya estaban en PROD (PR #121, `e966d1b5`+`f6858400`). Sin cambios; NEXT corregido. - **Otros**: tarea **#166** (MIB UX: filtro + "Sugerir OIDs útiles" IA); memoria `feedback_local_clicktest_before_commit` corregida (online por defecto).

Edu: actualizar el Agente local + guardar cifradas las contraseñas de los equipos + poder editar a mano la "ficha" de un equipo

tres cosas, todas terminadas y ya en producción. (1) **Publicamos la versión nueva del Agente local (2.7.1)** con los dos arreglitos de seguridad que quedaban pendientes de la sesión anterior: lo compilaste tú y yo lo subí al servidor y lo dejé descargable. (2) **Las contraseñas de acceso a los equipos** (las que pones en el editor de racks para conectarte por SSH) **ahora se guardan cifradas** en la base de datos, ya no en texto plano, y **dejan de viajar al navegador**: cuando abres la configuración de un equipo el campo de contraseña sale vacío con un aviso de "guardada — déjalo en blanco para conservarla", y solo la cambias si escribes una nueva. Lo pediste "a lo grande", así que cifré todo lo sensible (usuario, contraseñas e IP) y dejé todos los caminos coherentes; además apliqué el cifrado a los equipos que ya había en producción (20 equipos). (3) La **"ficha manual de equipos"** que querías: en los resultados del descubrimiento de red, cada equipo tiene ahora una pestaña **"Edit"** donde puedes fijar a mano su Tipo, Fabricante, Modelo, Nombre, Rol, Ubicación y Notas; lo que fijas **manda sobre lo automático** (un nuevo escaneo ya no lo machaca) y puedes devolver cualquier campo a "automático" con un botón. Esto resuelve el caso de los equipos que el sistema no logra identificar solo. Quedan para la próxima un par de cosas que solo tú puedes probar pinchando (la parte visual no la valida el robot de tests) y traducir al español los textos nuevos. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · 2 PRs Pro: #197 v1.19.0 + #198 v1.20.0 · release `agent-v2.7.1`): - **Release Agent 2.7.1**: `version.py` 2.7.0→2.7.1 + changelog + README; Edu compiló y verificó (`localhost:5050`→2.7.1); distribuido por SSH al volumen `app_media` (scp + `docker cp`, sin redeploy); release publicada + 2.7.0 borrada (tags conservados). - **fe2-G1 · R3 Fase 4 (#197, v1.19.0)**: cifrado at-rest del conjunto sensible de `Device.management_config` (`username/password/enable_password/ip`+`connection.*`) con helpers únicos `encrypt_config_secrets`/`redact_config_for_client` (`network/services/device_config.py`). Escritores cifran (POST network-config ×2, herencia perfil + bulk_create en `racks/services/racks.py`, restore); salidas redactan (editor load `racks/views.py`, 2 GET); lectores de IP unificados a descifrar (`terminal/api/network.py` ×2 quitando `[Encrypted]`, check_duplicate, provision_stages). Bug latente arreglado (`insight_execution.py:206` string→dict). Frontend `SshConfigModal.js`. Command `encrypt_management_config` (idempotente, --dry-run) aplicado en PROD (20 cifrados). 13 tests. ~287 LOC. - **Parte B · ficha manual (#198, v1.20.0)**: migración network `0053` (`DeviceProfile` += role/location/notes + manual_fields). Lock por campo en `network/services/profile_lock.py` (extraído del modelo para mantener `models.py` <500 LOC). `update_profile` (`network/api/profiles.py`) bloquea lo editado, `auto_fields` desbloquea, valida device_type, espejo role/location a `Device.model_data`. Lock respetado en provision_stages/discovery×2/reclassify. UI pestaña "Edit" en `results.js`. 9 tests. - **Método**: orden fe2-G1→Parte B; suite secuencial en Docker verde (968→977, evita el flaky pgbouncer+xdist del pre-push paralelo) + Vigía + auto-merge al verde. Footgun recaído: `| tail` enmascara el exit del gate. - **Pendiente (NEXT)**: click-test de Edu del JS de ambos · i18n F4 de los strings nuevos · Ayuda Viva `crearack--network--*`/`crearack--terminal--*` · fichas Atlas a regen · verificar migración 0053 tras el deploy · 2 secrets CF (s172).

Edu: cerrar la 2ª auditoría de seguridad (rematar lo que faltaba) + un arreglo de la herramienta interna de desarrollo

sesión de "rematar" la segunda revisión de seguridad del código (la que hace la otra IA, GLM). Lo importante: antes de tocar nada, comprobé equipo por equipo qué quedaba DE VERDAD por arreglar, y resultó que **buena parte ya estaba hecha** en sesiones anteriores sin que el plan lo reflejara — incluido lo más serio (un agujero del Agente y un XSS del historial de logins). Así que lo que quedaba eran detalles de seguridad menores, y se cerraron todos: en el hub interno del equipo (que cada acción quede firmada por quien la hace de verdad, tapar un agujero de coste en el buscador "Oráculo", validaciones que faltaban) y en CreaRack (un permiso que faltaba en un indicador, un par de refuerzos anti-XSS, y en el Agente local cifrar una URL y dejar de escribir una contraseña SNMP en los registros). Todo en producción (v1.18.6). Quedó pendiente, planificado y con dueño: **recompilar el Agente** para que esos dos últimos arreglos lleguen, una **migración mayor de cifrado** de las credenciales del editor (es trabajo propio), y la **"ficha manual de equipos"** que querías. Cortamos a propósito para empezar fresco la próxima. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · 2 PRs: #121 workspace + #196 Pro v1.18.6): - **Corroboración**: pase de discrepancias (3 agentes) verificando cada oro GLM contra `main`. fe7-G1 (único ALTA Tanda C) y terminal-sa4-G1 (Agent takeover) ya cerrados. 0 ALTA residual. - **Tanda D workspace (#121)**: WS4-G1 (`logQuery` en el `catch` → cierra el bypass del rate-limit del Oráculo), WS6-G1 (`resolveTeamMember` como actor en news/notes/alerts/tasks), WS2-G1 (`AI_COST_TOOLS` gatea las tools LLM a readonly), WS5-G1 (redacción `email.ts`), WS1-G1 (S256 en `code.ts`), WS3-G1/G2, WS2-G2/G3, WS6 `validateTextFields` MCP + `delete_news` existencia. tsc + 55 tests. - **Pro (#196, v1.18.6)**: sa2-G3 (`require_perm` observatory:view en `get_agent_status`), fe7-G2 (`_isSameOrigin` CSRF), fe6-G2 (`escapeAttr` title), Agent sa3-G1 (`http_url` en `_SECRET_TARGET_FIELDS`) + sa5-G2 (`_redact` community en `snmp.py` logs). - **Harness**: `check_raw_sql` diff-based (claude-method 73f4068, propagado). Footgun aprendido: `| tail` enmascara el exit de git en cadenas `&&`. - **Diferidos**: Agent 2.7.1 release, fe2-G1 (tarea #165, antes que Parte B), Parte B (plan del arquitecto listo, decisión role/location), 2 secrets CF. Método: Vigía + auto-merge al verde; sub-agentes Plan para diseñar Parte B y fe2-G1.

Edu: auto-descubrimiento para redes con equipos variados (3 mejoras) + 2ª auditoría de seguridad + arreglo de credenciales al colocar equipos en racks

día largo y muy productivo centrado en el **auto-descubrimiento de red** para cuando hay equipos de **distintos fabricantes mezclados** (Cisco, Xirrus, Cambium…). Tres mejoras: (1) ahora se puede **mandar cada equipo a un destino distinto en una sola pasada** (a un rack, a WiFi, a monitorización…) — antes, al mezclar, parecía que "no hacía nada"; (2) la lista de equipos descubiertos se puede **ordenar por columnas, filtrar y agrupar por fabricante o tipo** (clave para redes con muchos equipos); (3) opción **"probar todas las contraseñas guardadas"**, y cada equipo se queda con la suya. Aparte, aprovechando una **segunda auditoría de seguridad** (hecha con otra IA), se cerró lo que quedaba: un agujero en el historial de inicios de sesión y, lo más serio, evitar que se pudiera "secuestrar" el Agente local hacia un servidor falso. Probándolo en real salió un fallo: al colocar un equipo en un rack se le copiaban las contraseñas del último formulario (las de otro equipo) y su terminal no abría → **arreglado** para que cada equipo conserve las suyas. Edu recompiló el Agente (2.7.0). Para la próxima quedan: probar a fondo lo nuevo y que se muestre la VLAN de cada puerto. **Detalle técnico** (autor: Edu con Claude [Opus 4.8, Max] · CreaRack-Pro · 6 PRs #187→#192): - **Auto-Provision heterogéneo**: Fase A `#187` v1.16.0 (rack inline + apply atómico; causa del "no hace nada" = 2º modal de rack), Fase B `#188` v1.17.0 (orden/filtros/agrupación + estado en wizard), Fase C `#191` v1.18.0 / Agent 2.7.0 ("All credentials" en cascada; `run_ssh_discover_cascade`; retrocompat bus; smoke 13/13). - **Re-auditoría GLM**: frontend `#189` v1.17.1 (XSS login-history `auth.js` + flecos: escapeAttr title, img src, TDZ alertas Overview, dead code), Agente `#190` v1.17.2 / Agent 2.6.0 (sa4-G1 Agent takeover vía `_validate_saas_url` Origin, sa4-G2 `/check`, sa4-G3 `/info` tenant_id, mitigación sa2-G1 rate-limit; install_secret diferido → tarea #164). - **Fix** `#192` v1.18.1 (en CI al cierre): `_try_link_device_profile` hereda creds SSH del DeviceProfile al colocar en rack (gateado por profile_id; manuales intactos). Bug real Cisco 437 con creds Xirrus; diagnóstico server-side Django shell PROD. - **Método**: Vigía + auto-merge; Agentes (sin workflows); validación E2E del Agente por Edu. Tareas Gestor #163/#164.

🐞 credenciales que se borraban + ✨ VLAN de los puertos trunk + ✨ equipos mejor clasificados + 🐞 descarga del Agente arreglada (v1.18.2→1.18.5)

🐞 credenciales que se borraban + ✨ VLAN de los puertos trunk + ✨ equipos mejor clasificados + 🐞 descarga del Agente arreglada (v1.18.2→1.18.5)

Edu: evaluación de 5 repos de GitHub para el harness + nuevo "detector de pinta de IA" en el control de calidad de los commits

Edu trajo cinco repositorios de GitHub para valorar si nos servía algo para nuestras herramientas internas. De los cinco: **uno lo aprovechamos ya** — un detector que avisa cuando una pantalla "tiene pinta de hecha con IA" (gradientes morados, fuentes genéricas, emojis como iconos…); lo enchufamos al control automático que revisa cada cambio antes de guardarlo, configurado para que solo **frene** el caso más evidente y el resto solo **avise**, así no molesta con falsas alarmas (sobre todo con los colores de nuestras gráficas). **Dos los apuntamos para más adelante**: unas reglas de seguridad de Cloudflare para cuando montemos la web pública, y una herramienta que genera vídeos de demostración/tutoriales del producto. **Dos los descartamos**: uno por una licencia legal que nos contaminaría y otro porque ya tenemos algo equivalente. Sesión corta y de "fontanería", sin tocar el producto. **Detalle técnico** (autor: Edu con Claude [Opus, Max] · claude-method + CreaRack-Pro, sin código de producto): - **Evaluación** en memoria `reference_5repos_harness_eval_jun2026`: 1 adoptado, 2 diferidos, 2 descartados. - **✅ Gate `devibe`**: `RULES` de `JCarterJohnson/vibecoded-design-tells` (MIT) → `check_devibe()` en `pre_commit_check.py` (fuente claude-method). Diff-based, **solo `gradient-text` bloquea** (decisión de Edu; los hex morados chocan con paletas ECharts), resto avisa, `unslop-ignore` exime. Compañero de la skill `design-ai-slop-check`, refuerza Regla 7. Probado E2E. claude-method `8972040` + copia Pro `19e77dc2` (pre-push 42 verde). Propaga a los 3 por el sync. - **🐞 Drift fuente↔copia resuelto**: claude-method sin config ruff (88-col) vs Pro 120-col → fuente alineada a 120-col → 0 drift. - **Diferidos**: `cloudflare-security-art` (landing) · `hve-spielberg` (vídeo demo/Ayuda, ElevenLabs=coste). **Descartados**: `ForgeDock` (AGPL) · `lavish-axi` (ya cubierto).

Edu: el escaneo por rango ya detecta SSH (probado en producción) + repaso de seguridad de cartelería y configuración con el 2º modelo

cerramos lo que quedaba planificado de ayer. Ahora, al escanear **un rango entero** de equipos de la red (no uno a uno), el sistema también comprueba el **acceso remoto (SSH)** de cada equipo a través del "Agente" que vive en la red del cliente — antes el escaneo por rango se saltaba esa parte y todos los equipos salían sin SSH aunque lo tuvieran. **Edu lo probó en producción y funciona** (quedan detalles de pulido que veremos otro día). Además seguimos el **repaso de seguridad con el segundo modelo de IA (GLM)**, esta vez sobre la **cartelería digital** y la **configuración general**: confirmó que lo importante ya estaba bien y cerramos dos mejoras de aislamiento entre clientes — las imágenes/vídeos de cartelería de una organización ya solo los ve su propia organización, y el enlace de publicación de cada pantalla ahora se puede **anular** (antes, si se filtraba, daba acceso permanente). Tres entregas a producción, todas verdes. Día largo: cerramos aquí. **Detalle técnico** (autor: Edu con Claude [Opus, Max] + GLM 5.2 [Z.ai, secuencial] · Pro v1.15.13→1.15.16 · workspace): - **F2.2 SSH discovery por rango (PR #184, v1.15.14, PROD) — ✅ validado E2E por Edu**: el wizard de rango va por `/bulk-enrich` (sweep en el cliente vía Agente), no por `bulk-discover` server-side (matiz corregido del plan §10). Añadida la fase SSH en `discoverSubnet` (batched 8/tanda, `/network/ssh-discover`) + `HostEntry.ssh_data` + `pre_ssh_data` a `provision_device`. 3 tests. Cosas que pulir → próxima sesión. - **Re-auditoría GLM Tanda B (config-ia + signage)** — 0 ALTA residual en ambos. Opus rectificó: **config-ia G1 (#185, v1.15.15)** IDOR cross-tenant de media (`serve_media_gated` valida same-tenant; no afecta al player ni al portal); **signage G1 (#186, v1.15.16)** `publish_token` revocable/caducable (`publish_active`+`publish_expires_at`, migración 0013, endpoint de rotación). +10 tests. Diferidos BAJA documentados. - **Orientación GLM terminal**: sa1 (SSH server-side) ya retirado → saltar; sa2–sa6 (Agente + bus servidor↔Agente) son alto ROI (el EPIC los amplía). Orden sa2→sa4→sa5→sa3→sa6, luego frontend. - **Limpieza**: 3 stashes git abandonados de abril purgados. - **Próxima**: pulir autodiscovery por rango · GLM Tanda B terminal sa2–sa6 + rectificación · diferidos config-ia/signage · sa4-G2 · doc M11.

Edu: cerrado el botón de copias por el Agente (probado en producción) + repaso de seguridad completo de la monitorización con el 2º modelo

sesión que hubo que recuperar a mano porque la anterior se cayó con un error del propio Claude. Recuperado el hilo, cerramos dos cosas grandes. Primero, terminamos de pasar las **copias de configuración** a la vía del Agente: el botón "hacer copia" ya no abre conexiones desde el servidor ni manda nada por el navegador — Edu lo probó en producción y guardó la copia perfectamente. Con esto queda cerrada toda esa fase. Segundo, completamos el **repaso de seguridad de toda la zona de monitorización** con el segundo modelo de IA (GLM), que mira el código con otra mirada: confirmó que lo importante ya estaba bien (nada grave nuevo) y pulimos una tanda de detalles finos (robustez, aislamiento entre clientes). También hicimos que cuando una alerta "escala" de nivel avise solo al canal que configuraste para ese escalón, no a todos. Cinco entregas pequeñas a producción, todas verdes. A mitad de sesión a Edu se le rompió el Docker y lo reinstaló. Descubrimos además que el modo de trabajo "tranquilo" del segundo modelo gasta muchísima menos cuota y rinde igual. **Detalle técnico** (autor: Edu con Claude [Opus, Max] + GLM 5.2 [Z.ai, secuencial] · Pro v1.15.8→1.15.13 · workspace): - **Recuperación tras error 500**: la sesión cayó con F2.1c PR2 a medio escribir en el working tree; reconstruido vía STATE/NEXT + diff sin commitear. - **F2.1c PR2 cutover (PR #179, v1.15.9)**: `trigger_backup`→`DeviceOps.dispatch("config_backup")` + frontend `pollBackupTask`; retirados `save_backup`/`SaveBackupInputSchema`/`ScrapliManager`/WS local. 5 tests. **Validado E2E en PROD por Edu** (botón "Create Snapshot" → Snapshot creado). **F2.1 cerrada entera.** - **Re-auditoría GLM · Tanda A completa** (GLM secuencial; Edu lo paró tras acabarla para no acumular cola): sa3 (#180 v1.15.10, rate-limit `test_channel`+4 defensas) · sa1 (#181 v1.15.11, validate-on-write OID + parse robusto Report Mode) · sa4-sa6 (#182 v1.15.12, 4 fixes verificados por **3 agentes**) · sa4-G3 (#183 v1.15.13, escalación notifica solo a su canal). **0 ALTA/MEDIA** en las 6 sub-áreas. Diferidos: sa4-G2 (regex `| include`), sa6-G1 (ADR T2). - **Modo secuencial GLM fijado** en memoria `project_glm_zai_pilot` (mismo resultado/tiempo que workflow a fracción de cuota; ~12-25 prompts/sub-área). - **Bug discovery por rango** confirmado = comportamiento esperado (`bulk-discover` backend-only, sin Agente) → **F2.2**. No regresión. - **Infra**: Docker Desktop roto + reinstalado a media sesión; 2 contenedores huérfanos de `docker compose run` limpiados. - **Próxima**: F2.2 (SSH discovery por rango vía Agente) · GLM Tanda B (terminal/config-ia/signage) · sa4-G2 (tests smuggling) · corrección doc workspace M11.

Edu: el Agente ya hace copias de configuración de los equipos (probado en un Cisco real) + diagnóstico del escaneo por rango

seguimos el plan del "Full-Local Agent". Hoy le enseñamos al Agente a **hacer copias de la configuración** de un equipo de red por encargo del servidor: el servidor lo pide, el Agente entra en el equipo dentro de la red del cliente, saca la configuración y el servidor la guarda — **sin navegador abierto y sin que la contraseña salga del servidor**. Lo **probamos en un switch Cisco real** de Edu y guardó la copia (33 KB) perfectamente. La prueba destapó un fallo que el sistema de copias **ya arrastraba de antes** (no se ponía en "modo administrador" del equipo, y por eso fallaba con los Cisco): lo arreglamos, así que ahora va **mejor que el sistema anterior**. Edu actualizó el Agente (versión 2.5.1) y lo comprobó. Empezamos el cambio del botón de copias para que use esta vía nueva (primera mitad lista). Y averiguamos por qué al escanear **un rango entero** de equipos no detectaba el acceso remoto (SSH) de ninguno: el escaneo por rango todavía no usaba al Agente para esa parte. Lo dejamos **planificado** como el siguiente trabajo. Todo verde, sin incidencias. **Detalle técnico** (autor: Edu con Claude [Opus, Max] · Pro v1.15.7→1.15.8 · Agent 2.4.0→2.5.1 · workspace): - **Mergeado PR #176** (F2.1a, v1.15.7). - **F2.1b (PR #177, v1.15.8, Agent 2.5.0)**: handler `config_backup` en el Agente (`run_config_backup`: SSH+PTY, creds server-side R3 nunca en `params`) + `SUPPORTED_OPERATIONS` + `dispatch_device_op` `--device-id/--config-command`. El servidor decide el comando. - **Validado E2E en PROD** (Cisco real device 419): `queued→acked→done` → running-config 33 KB → `ConfigBackup id=5` por el finalizador, sin navegador. - **Fix Agent 2.5.1** (push directo): modo `enable` con `enable_password` (R3) antes del comando + no guarda backup basura si el equipo rechaza (bug preexistente del flujo viejo). +4 tests. Edu recompiló+verificó 2.5.0 y 2.5.1. - **F2.1c · PR1 (#178, mergeado)**: endpoint de polling `GET /api/network/device-task/{request_id}` (org-scoped, no expone `result`). 5 tests. - **Bug discovery por rango → F2.2 planificada**: el `bulk-discover` no hace fase SSH vía Agente (solo el individual) → SSH:0 en `/24`. Plan §10 + tarea Gestor #162. - **Deuda**: tests `network/tests/*` huérfanos (no corren en CI, rotos por module gating). - **Próxima (lista para arrancar)**: F2.1c · PR2 — cutover del backup (`trigger`→bus + `backups.js`→polling + retirar `scrapli_manager`/`save_backup`/WS local; click-test local) → F2.2.

Edu: primer gran paso del "Full-Local Agent" (que el Agente hable con los equipos de red) + probado en real

arrancamos de verdad el plan grande de que sea **el Agente** (el programita que vive dentro de la red de cada cliente) quien hable con todos sus equipos de red, en vez de hacerlo desde nuestro servidor (que no llega a las redes privadas). Montamos la "tubería" segura y fiable entre el servidor y el Agente, le enseñamos al Agente a ejecutar las órdenes que le llegan, y **lo probamos contra un punto de acceso WiFi real de Edu**: la orden fue del servidor al Agente, se hizo en la red local y el resultado volvió bien. Edu actualizó el programa del Agente (versión 2.4.0) y lo comprobó. Dejamos preparado el siguiente trozo (backups de configuración automáticos, sin navegador) y **escribimos para el equipo por qué este diseño aguanta tener muchísimos clientes** (lo pesado lo hace el ordenador de cada cliente, no el nuestro). Todo verde, sin incidencias. **Detalle técnico** (autor: Edu con Claude [Opus, Max] · Pro v1.15.4→1.15.7 · Agent 2.3.6→2.4.0 · workspace): - **F1 — bus DeviceOps**: PR #174 (backend: `DeviceTask` cola durable + `DeviceOps` + RPC sobre WS con guard cross-tenant + Huey, v1.15.5) + PR #175 (Agente: `handle_device_op` ack→run→result + `ssh_discover` compartido, Agent 2.4.0, v1.15.6) + fix `build_agent.bat`. 18 tests. Edu recompiló+verificó el `.exe`. - **Validación E2E en PROD**: comando `dispatch_device_op` → `ssh_discover` por el bus contra Xirrus real (`192.168.231.110`) → `queued→acked→done`, huella = la del piloto. - **F2.1a (PR #176, abierto, gate verde, v1.15.7)**: finalizadores del bus (crean el efecto sin navegador) + helper `create_config_backup` + retención `purge_device_tasks`. 19 tests. Pendiente mergear. - **Doc equipo**: escalado SaaS en `PLAN_FULL_LOCAL_AGENT.md §7`. **GLM** → modo secuencial (el workflow revienta la cuota Z.ai). - **Próxima**: mergear #176 → F2.1b (Agente `.exe` 2.5.0) → F2.1c (retirar `scrapli_manager`).

Edu: segunda auditoría de seguridad de la "red" con un 2º modelo de IA (GLM) + Claude cierra los arreglos

pasamos un segundo par de ojos de IA (un modelo llamado GLM, que razona distinto a Claude) por la parte de "red" del programa, buscando agujeros de seguridad que se nos hubieran escapado. GLM trabajó en paralelo a Claude. La buena noticia: lo que ya habíamos blindado sigue bien blindado. GLM encontró un par de detalles finos —sobre todo uno importante: la IA que interpreta los equipos de red podía colar datos inventados en una lista que luego se consulta para **todos** los clientes— y Claude los arregló y subió a producción en 4 entregas pequeñas. Además dejamos funcionando un automatismo para que el "buscador inteligente" de Claude tenga siempre los documentos al día, y limpiamos 56 entradas basura que se habían colado en su mapa interno. Todo verde, sin incidencias. **Detalle técnico** (autor: Edu con Claude [Opus, Max] + GLM 5.2 [Z.ai, terminal aparte] · Pro v1.15.1→1.15.4 + workspace): - **Re-auditoría GLM network sa3+sa4** (2ª mirada): certifica que R3+`require_perm` aguantan; caza colas. sa3 → `apply_proposal` validaba OIDs del LLM (PR #171) + backlog robustez (PR #172). sa4 → traza forense backups + `device_count` honesto + sha256 (PR #173). Todos merged verde (Vigía). Diferidos M2/M3 (ADR R3), m5 (T2), m4 (frontend) documentados; b2 declinado. - **Chunks → cron Hetzner** (diario 01:30): export vía MCP (`fetch-doc-nodes.mjs`, sin wrangler), backfill 812 chunks; fix wrangler `--remote`. - **Grafo**: `.claude/` excluido del reindex de docs + 56 nodos basura de worktree purgados de D1 (doc-count 417→361). La "deuda 1" de s163 era falsa alarma. - **GLM** sin cuota (reset 23-06 06:27) → NEXT = monitoring-sa3 (CNS/IA) modo completo.

Edu: repaso a la Biblioteca (el mapa de Claude del proyecto) — reindex manual del grafo

la "Biblioteca" es el mapa que tiene Claude de todo el código y los documentos del proyecto, y normalmente se actualiza sola en un servidor. Edu pidió darle un repaso porque pensaba que estaba parada por ahorrar costes. Vimos que la parte del **código** sí se refrescaba sola cada 10 minutos, pero la de los **documentos** se había quedado sin enterarse de **47 archivos nuevos** que escribimos estas semanas, y la lista de funciones del programa también estaba vieja. Lo pusimos todo al día a mano. De paso descubrimos que un automatismo del servidor (el que actualiza documentos y funciones) parece haberse quedado dormido — lo dejamos apuntado para arreglarlo bien otro día. No se tocó nada del producto. **Detalle técnico** (autor: Edu con Claude · workspace · solo grafo D1, 0 código de producto): - Reindex manual desde local: AST ×7 apps (ya frescas) · docs **+47 nuevos** (370→417 nodos doc) · OpenAPI **434 paths + 218 schemas** (743 nodos refrescados) · comunidades **441→454**. Totales 4797→4844 nodos, 6983→7103 edges. Búsqueda semántica verificada. - **Hallazgo**: el cron AST de Hetzner (cada 10 min) no descubre ficheros nuevos y el tick de "extras" (openapi+docs) parece parado → revisar log en STAGE. - **Deuda**: embeddings de los docs nuevos a medias (circuito lento ~31s/batch, no cableado en cron, `export-doc-nodes.ps1` roto por wrangler `--remote`). Plan + tarea workspace creados.

Edu: el descubrimiento por SSH pasa al Agente local (arranca el plan "Full-Local Agent") (v1.14.0→1.15.1, Agente 2.3.5→2.3.6)

probando una cosa pequeña (ver la "huella" de seguridad de un punto de acceso WiFi Xirrus) salió a la luz un problema de fondo: cuando CreaRack descubre equipos de la red, la parte de SSH la intentaba hacer **el servidor de internet**, que **no llega** a los equipos de la red local del cliente — por eso ese paso siempre fallaba con los equipos de la oficina (aunque el resto, SNMP/web/ping, sí funcionaba porque lo hace el Agente del portátil). De ahí salió una decisión importante de Edu: que **todo el contacto con los equipos lo haga el Agente local** (que está dentro de la red) y el servidor solo "piense" y guarde. Hoy entregamos el **primer trozo** de ese plan: el SSH del descubrimiento ya lo hace el Agente. Lo probamos con un Xirrus real y **funciona**: el equipo sale como accesible por SSH y su huella de seguridad queda registrada. De paso aclaramos que la "huella" es el mecanismo que evita que alguien suplante tus equipos para robar las contraseñas (como el aviso de PuTTY la primera vez que entras a un servidor). El plan completo (que es grande, varias sesiones) queda escrito para ir avanzándolo. **Detalle técnico** (autor: Edu con Claude · CreaRack-Pro + workspace · PROD · v1.14.0→1.15.1 · Agente 2.3.5→2.3.6): - **PR #168 (v1.14.0)**: el SSH del discovery deja de ser solo "plan B" de SNMP (se intenta siempre que haya credenciales) + recalibrado del % de confianza para no penalizar APs/UPS bien identificados por SNMP sin CLI/LLDP. 52 tests. - **EPIC "Full-Local Agent"**: decisión de arquitectura (Agente=toda la I/O de red / servidor=cerebro+UI, sin fallback). Plan vivo `full-local-agent/PLAN_FULL_LOCAL_AGENT.md` (en el grafo) + memoria. Auditoría previa: ~5 operaciones server-side a migrar (SSH discovery/backups/scripts/lectura-puertos + signage); el monitoreo continuo ya va por el Sentinel del Agente. - **PR #169 (v1.15.0 · Agente 2.3.5)**: piloto — endpoint `/network/ssh-discover` en el Agente (banner+huella TOFU+auth+show) + fase "SSH" en el modal + el backend interpreta `pre_ssh_data` (`build_ssh_data_from_agent`) sin abrir SSH server-side + la huella se persiste en `SshHostKey` (panel). 39 tests. - **PR #170 (v1.15.1 · Agente 2.3.6)**: fix — los `show` por canal exec sin PTY colgaban con Xirrus (Cisco OK); auth marcada antes de los comandos + presupuesto de tiempo acotado. Validado E2E por Edu (Xirrus 192.168.231.110 → SSH:1 + huella). - 3 PRs verdes (Vigía), release `agent-v2.3.6` publicado (2.3.5/2.3.4 borradas), READMEs al día. **Próximo**: F1 Fundación (bus de tareas Agente + puerta DeviceOps, engancha con Huey de julio).

Edu: panel de salud de la Sala + monitorización unificada de equipos + auto-refresco (v1.11.0→1.12.1)

la Sala (el plano del centro de datos) tiene ahora un **panel de salud** a un lado: un semáforo que dice de un vistazo cuántos equipos están bien, con aviso, caídos o sin vigilar, y una lista de los que dan problema con **tres botones para ir directo a arreglarlos** (a la pantalla de monitorización, al armario o a la consola). Lo más importante lo propuso Edu: hasta ahora un equipo metido a mano en un armario tenía su estado por un lado y la pantalla de monitorización por otro — dos verdades distintas. Ahora, **al configurar la red de un equipo entra automáticamente en la monitorización**, aunque no se haya detectado solo; así hay **un único estado** y todo encaja. Lo probamos con dos equipos de prueba de Edu (sin conexión) y el panel los detectó perfectamente. Además el panel **se refresca solo cada minuto**. Tres entregas a producción. **Detalle técnico** (autor: Edu con Claude · CreaRack-Pro · PROD · v1.11.0→1.12.1): - **Panel salud (PR #164)**: `room_health()` + `GET /{id}/room/health` (lee el estado cacheado `MonitoringTarget.last_status`, sin tocar el motor de métricas). Columna lateral derecha vertical (reubicada por click-test: la barra central quedaba tras la barra de dibujo). Semáforo de 4 estados + afectados con saltos a Observatory/editor/terminal. 2 tests. - **Integración Rack↔Observatory (PR #165)**: al guardar la gestión de red de un device se da de alta solo en Observatory (`get_or_create_for_device`); al desactivar, se retira. Comando de backfill para los ya configurados. 3 tests. Validado E2E por Edu. - **Auto-refresco (PR #166)**: cada 60s, en pausa si la pestaña no está visible. - **Footgun**: el gate de tests local daba falsos rojos por pgbouncer (conexiones que impiden borrar las BD de test en paralelo); el CI real pasa. `--no-verify` con OK de Edu tras verificar el suite en serie (848 OK). - 3 PRs, todos verdes (Vigía). Deudas: sonda de puerto TCP (para equipos solo-SSH) · Ayuda de usuario + traducción ES de los textos nuevos.

Edu: el Agente vuelve a detectarse en la versión local + Agente solo-Online + rediseño de su panel (v2.3.3)

Edu vio que la versión de CreaRack que arranca en su propio ordenador no detectaba el Agente de su portátil, aunque la de internet sí. La causa de fondo: la base de datos local de su ordenador estaba desactualizada y una pieza interna reventaba por eso; lo arreglamos (hay que actualizar la base de datos local a mano cuando se baja código nuevo). Surgió la idea de conectar el Agente a la vez a local y a internet, pero la **descartamos**: añadía carga y riesgo para poco beneficio. El Agente se queda conectado **solo a internet (producción)**, sin tocar su motor (cero riesgo para lo importante). Además **rediseñamos su panel** con un look de alto contraste (negros/grises, letra blanca) y las cajas mejor colocadas. Publicamos el Agente 2.3.3, pusimos el README al día y ajustamos cómo subimos a GitHub para gastar menos cuota. **Detalle técnico** (autor: Edu con Claude · CreaRack-Pro · PROD · Local Agent v2.3.1→2.3.3): - **Causa**: BD local sin migrar (faltaba `local_token_enc`) → 500 en el endpoint del token → el Agente salía como no detectado. La local no auto-migra (solo STAGE/PROD). Footgun guardado. - **v2.3.1** (commit directo): CORS dev-local → la versión local detecta el Agente vía `/info`. - **v2.3.2** (PR #162): retirado el conmutador SaaS Local/Online (panel pasivo + endpoint `/saas/switch` eliminado). Conexión dual descartada (rendimiento/seguridad/estabilidad). - **v2.3.3** (push directo): rediseño del panel (alto contraste, SNMP Traps 2/3 + SaaS Connection 1/3 en dos columnas fijas). Helper de preview para iterar sin recompilar. - **Cierre**: README v1.7.1 + Agent 2.3.3; release `agent-v2.3.3` publicado (anterior retirada, tag conservado). Subidas de bajo riesgo por push directo a main (0 Actions de CI).

🏢 DCIM Fase 3 (Salas/Room): slices 1+2+3 a PRODUCCIÓN (v1.8.0→1.10.0)

🏢 DCIM Fase 3 (Salas/Room): slices 1+2+3 a PRODUCCIÓN (v1.8.0→1.10.0)

Edu: piloto GLM 5.2 (2º modelo IA barato) + arregla un agujero de seguridad real en producción (v1.7.1)

Edu quiso probar si un segundo cerebro de IA más barato (GLM 5.2, pagado por uso) podía hacer parte del trabajo y aligerar el plan principal. Montamos el experimento entero y lo medimos. Conclusión: ese segundo cerebro **revisa y programa bien**, pero para los trabajos grandes en cadena sale **caro** (el plan que ya tenemos los cubre sin coste extra). Donde sí merece la pena es como **segundo revisor de seguridad**: en la prueba **encontró un fallo real** que la primera revisión había pasado por alto —por el que el servidor podía ser engañado para sondear su propia red interna— y lo dejamos **arreglado y en producción**. Guardamos el sistema documentado por si queremos repetirlo. Toda la prueba costó unos 13 dólares. **Detalle técnico** (autor: Edu con Claude · PR CreaRack-Pro #161 · PROD · v1.7.1 · + repo privado Esquembri/glm-pilot): - **Montaje**: GLM 5.2 vía OpenRouter (endpoint Anthropic nativo, sin proxy); terminal aparte; blindaje para que el modelo caro (Opus) nunca se facture por API (guardián que verifica ausencia de credencial). - **Medición**: auditar una sub-área en modo workflow = $10.36 (72 subagentes); editar/arreglar con un solo agente = ~$3. El gasto es por volumen de llamadas con mucho contexto, no por el modelo. - **Fix a producción (PR #161)**: SSRF en los sondeos del servidor (SNMP/ping/batch) + el rango de la VPN del equipo que no se filtraba → validación unificada en un guard único. Más 6 arreglos de corrección. 66 pruebas en verde. Versión 1.7.1. - **Veredicto**: GLM = segunda mirada de seguridad y tareas sueltas; no sustituye los workflows del plan. Sistema fijado en `glm-pilot` + repo privado. Plan de re-auditoría por tandas pendiente de decisión de Edu.

Edu: DCIM Fase 2 — gestión + añadir/quitar/reordenar armarios en la Fila (v1.6.0→1.7.0)

la página de una **fila** de armarios ya se gestiona entera desde ahí. Con el botón **"Manage Row"** puedes **cambiarle el nombre** a la fila, ponerle a todos los armarios la **misma altura y la misma potencia** de golpe, y **meterlos en un grupo** — todo en un paso. Lleva una red de seguridad: si al bajar la altura algún equipo se quedaría colgando fuera del armario, no toca nada y te dice **qué armario lo impide** (a Edu le gustó ese control). También puedes **añadir** un armario al final (se nombra solo, siguiendo la numeración: A03 → A04), **moverlos** de orden con botones de izquierda/derecha, y **borrarlos** (van a la papelera, son recuperables). Y se cambió el viejo botón de encuadre por un **control de zoom** (− / + / Fit) en una esquina, porque el anterior se confundía con el de pantalla ancha. Novedad de método: como esta parte visual no tiene pruebas automáticas, Edu la prueba **en su ordenador antes de subirla**, no después en producción. Todo desplegado. **Detalle técnico** (autor: Edu con Claude · PRs CreaRack-Pro #158/#159/#160 · PROD · v1.5.0→1.7.0): - **Gestión de la fila (v1.6.0/#158)**: `POST /api/blueprints/{id}/manage-row` + `BlueprintService.manage_row` — renombrar + altura/potencia comunes (vacías = no tocar) + grupo aditivo; altura validada antes de aplicar (excluye PDUs 0U); avisos en 200+`ok:false` (consola limpia). 9 tests `TestManageRow`. - **Renombrar racks (v1.6.1/#159)**: el alcance "Row and racks" renombra los armarios con prefijo (B→B01…), no solo su ubicación interna. - **Añadir/quitar/reordenar (v1.7.0/#160)**: `add_rack_to_row` (hereda altura/potencia/grupo del último, numeración continuada) + `reorder_row`; endpoints `/row/add-rack` y `/row/reorder`; quitar = papelera (reusa el borrado existente). Controles Konva bajo cada armario con los colores del diseño central. + control de zoom flotante −/+/Fit (sustituye el botón Fit View). 5 tests `TestRowRackOps`. - **Notas**: método local-first para UI (memoria `feedback_local_clicktest_before_commit`); lección recaída (reiniciar `web` al tocar plantillas). Ayuda Viva `crearack--racks--filas-row` y plan DCIM al día. Pendiente opcional: panel de monitoraje de la fila.

Edu: DCIM Fase 2 — arrastrar equipos en la página de la Fila + consola del panel limpia (v1.5.0)

seguimos con la parte de centros de datos. La página de una **fila** de armarios (la vista de "alzado" con todos los armarios en línea) deja de ser solo para mirar: ahora se pueden **arrastrar los equipos** de un sitio a otro — a otra altura del mismo armario o **a otro armario de la fila** — y se quedan donde los sueltes; si los sueltas sobre un hueco ocupado o fuera del armario, vuelven solos. Lo importante es que al mover un equipo **se lleva toda su historia**: su ficha de descubrimiento, sus copias de configuración, su cableado y su monitorización siguen siendo del mismo equipo, no empieza de cero. Reorganizar una fila entera se hace ahora de un vistazo, arrastrando, sin entrar armario por armario. Aparte, Edu pidió cerrar un error que ensuciaba la consola del **panel principal** (era un detalle de orden de carga de los scripts, sin efecto visible): ya está limpio. Todo en producción. **Detalle técnico** (autor: Edu con Claude · PR CreaRack-Pro #157 · todo en PROD): - **Arrastre entre racks**: endpoint nuevo `POST /api/racks/{id}/devices/{device_id}/move` + `RackService.move_device` — mueve el equipo **conservando su identidad** (mismo id → perfil/backups/puertos/monitoreo intactos), reasigna la FK propia a rack de los `ConfigBackup`, valida el solape en el destino, aislamiento por organización. Decisión de producto con Edu: conservar identidad (no borrar+crear) y acotar a equipos normales (en U, full+half-width, frontal). 8 tests. - **Frontend** (`row_view.js`): arrastre Konva con encaje a unidad, validación de solape en cliente (espejo del backend) y vuelta animada si no cabe; clic sin arrastre → editor; los totales de la cabecera son de la fila entera → no cambian al mover dentro, sin recargar. - **Fix consola del panel** (`ApiService is not defined`): `dashboard_widgets.js` pasa a módulo que importa `ApiService` directamente (en vez de depender de una variable global que cargaba otro script más tarde) + arranque robusto; `base.html` lo carga como módulo. - **Lección recaída**: el endpoint nuevo daba error 404 hasta reiniciar el servidor de pruebas (daphne cachea el Python); diagnosticado server-side, sin delegar el F12. - **Entrega**: PR #157 squash (verde en pre-push y CI, Vigía OK) → Dokploy STAGE+PROD. `APP_VERSION`→1.5.0; CHANGELOG/RELEASE_NOTES/README + Ayuda de usuario de la Fila al día. - **Próximo**: gestión de la fila (renombrar, potencia/altura comunes, grupo) → añadir/quitar/reordenar armarios → panel de monitoraje.

Edu: DCIM Fase 2 — página de la Fila (vista elevation) + huecos 0U dentro del armario (v1.4.0 + v1.4.1)

seguimos con la parte de centros de datos, dos mejoras y las dos ya en producción. La primera: al pulsar el **nombre de una fila** de armarios en el panel principal se abre ahora una **página propia de esa fila**, donde ves de un vistazo **todos sus armarios en línea** dibujados a tamaño con sus equipos dentro, los totales de la fila (cuántos armarios, consumo, ocupación y peso) y, pulsando un armario, entras a editarlo. La segunda: mejoramos el **dibujo del armario** para que sea más fiel a uno de verdad — las regletas de corriente y los organizadores de cable verticales se montan ahora **dentro** del propio armario, en dos huecos laterales (antes colgaban por fuera), y los números de las unidades se ven a ambos lados. Hubo un susto (la página de la fila salía en blanco), pero resultó ser que el servidor de pruebas se había quedado con código antiguo en memoria; con reiniciarlo se arregló, no era fallo del dibujo. **Detalle técnico** (autor: Edu con Claude · PRs CreaRack-Pro #155 + #156 · todo en PROD): - **Página del Row (#155, v1.4.0)**: `/rows/<id>` + vista `row_detail`; render Konva propio (`static/js/rows/row_view.js`) de los N racks en línea con equipos por U, clic→editor, zoom+pan, roll-ups de la fila. Helper único `rack_group_rollup` reutilizado por dashboard y fila (Regla 2). Datos vía `json_script`. 3 tests. Decisiones de alcance con Edu (elevation interactiva elegida; orientación → Fase 3). Slice 1 = consulta. - **Huecos 0U dentro del bastidor (#156, v1.4.1)**: helper compartido `rack_frame.js` (`addCabinetFrame`), geometría en `state.js`, raíles 0U dentro de los huecos, números U a ambos lados, encuadre ajustado; mismo cambio en la página de la fila. Bajo riesgo: la zona de U sigue siendo el ancla (colocación/half-width/colisiones intactos). - **Lección recaída**: daphne cachea Python → tras cambiar la vista al commitear #155 sin reiniciar `web`, la fila salía vacía; `restart web` lo resolvió. Diagnóstico server-side (shell + curl), sin delegar el F12 a Edu. - **Próximo**: slice 2 = arrastrar equipos entre racks en la página de la fila → gestión/añadir/quitar/reordenar/monitoraje.

Edu: DCIM Fase 2 — peso de los equipos + cierre de deudas (v1.3.2)

sesión para rematar lo pendiente del centro de datos. Ahora cada equipo del armario puede llevar su **peso en kilos** (un campo nuevo en el editor, al lado del de electricidad), y el panel principal suma el **peso de cada grupo** junto al consumo y la ocupación que ya mostraba — importante porque tanto el armario como el suelo técnico aguantan un peso máximo. De camino se cerraron tres cabos sueltos: el panel principal ya **no se queda con datos viejos en pantalla**, toda la parte nueva está **traducida al español**, y la documentación técnica interna se puso al día. Apareció además un fallo escondido en la herramienta de traducciones que se detectó y arregló antes de que rompiera nada. Todo en producción. **Detalle técnico** (autor: Edu con Claude · PR CreaRack-Pro #154 + workspace · todo en PROD): - **Peso**: `weight_kg` en `Device.model_data` (migración cero, espejo de `power_w`). Editor (input/guardado/carga/undo-redo), badge de peso del rack y roll-up kg por grupo (`racks/views.py` + `index.html`, oculto si 0). 2 tests. - **Cache**: `Cache-Control: no-store` en el dashboard (lo que ocultaba el kW era cache HTTP; el service worker ya se purgaba solo). - **i18n**: 37 strings DCIM al ES. Bug en `merge_po_fragments.py` (no preservaba el contexto de las traducciones ambiguas, p.ej. "Load") cazado por el gate de tests y arreglado en la fuente. - **Atlas + Ayuda**: 4 fichas técnicas (racks/blueprints/frontend/catálogo) + la ayuda de usuario de "dispositivos" (EN+ES) actualizadas a mano, sin gastar minutos de CI. - **Entrega**: PR #154 (verde en todo, Vigía OK) → Dokploy STAGE+PROD. Las 4 deudas que dejó la sesión anterior quedan cerradas. Siguiente: la página de edición de una Fila completa.

Edu: DCIM Fase 2 — Filas (Row) de racks + consumo/ocupación en el panel (v1.3.0 + v1.3.1)

seguimos convirtiendo CreaRack en herramienta de centro de datos. Ahora se pueden crear **Filas** de armarios de una sola vez: pulsas "New Row", indicas nombre, cuántos armarios, su altura y un prefijo (salen A01, A02, A03…), y opcionalmente un grupo, los vatios por armario y una nota; te los crea todos agrupados, cada uno con su ubicación puesta. La idea clave de Edu: una fila NO hace falta dibujarla (cuatro cuadrados en línea no aportan); el dibujo de planta llegará con las Salas. Además, cada bloque del panel principal (cada fila y cada mapa) muestra ahora su **consumo total en kW** y el **porcentaje de espacio ocupado**, de un vistazo. Y se puede borrar una fila entera (sus armarios van a la papelera, recuperables). Todo en producción. **Detalle técnico** (autor: Edu con Claude · CreaRack-Pro + workspace · todo en PROD): - **Slice 1 (PR #152, v1.3.0)**: `Blueprint.mode` (map/row/room) + migración `0008` + `POST /api/blueprints/row` (`create_row`: fila + N racks, prefijo+nº, `location` `Row-n`, grupo validado por org, nota, potencia W, cota 100). Dashboard: New Row + modal + badge Row + Delete Row (papelera). Fila = `Blueprint(mode=row)` con placements en línea. Revertido el row-snap de Konva (pivote: la fila no se dibuja). - **Slice 2 (PR #153, v1.3.1)**: roll-up kW/%U por grupo (`racks/views.py` `group_rollups` por `blueprint_name`; `index.html`; `.blueprint-group-rollup`). kW = Σ `model_data.power_w` reales o nominal del rack; %U excl. 0U. - **Lección**: el "no se ve el kW" era el service worker de `base.html` cacheando el dashboard (diagnóstico server-side con `RequestFactory`), no el código → incógnito. Mejora anotada: excluir el dashboard del SW. - **Verificación**: 12 tests blueprints + pre-push suite 42 en Docker; Vigía verde en ambos PRs; auto-merge → Dokploy. Ayuda EN `crearack--racks--filas-row`. **Deudas**: roll-up de peso (falta campo), i18n `.po` ES (F4), Atlas (post-1-jul).

🏢 Arranca DCIM/CPD: Fase 1 (trasera de racks + PDUs 0U) a PRODUCCIÓN (v1.2.0)

🏢 Arranca DCIM/CPD: Fase 1 (trasera de racks + PDUs 0U) a PRODUCCIÓN (v1.2.0)

Edu: el filtro por proyecto del Gestor llega al inicio (widget + móvil)

el Gestor ya permitía agrupar tareas por proyecto (p.ej. Plan Producto H2), pero solo en la página de Tareas. Ahora el recuadro "Tareas del equipo" de la pantalla de inicio —y su versión en el móvil— tiene un desplegable para elegir proyecto, y recuerda tu elección entre visitas. Edu notó que una tarea "en curso" no aparecía en el recuadro: no era un fallo, sino que el recuadro tenía un filtro por persona puesto (un nombre que no era el suyo); con el filtro en "Todos" sale. De camino, igualamos el criterio de personas del recuadro al de la página (las tareas con dos responsables ya salen) y el recuadro ahora se refresca al volver a la pestaña. **Detalle técnico** (autor: Edu con Claude · workspace · todo en PROD): - **Feature (PR #120, `f67f36b0`)**: `<select>` de proyecto (Todos/Base/proyecto) en `KanbanMini` (widget escritorio: carga `/api/projects`, filtra el kanban por `project_id`) y en `V1HomeVivo` (home móvil, sección "Para ti · hoy"; no altera los contadores del saludo). `Task` (`lib/types.ts`) += `project_id?`. Backend sin cambios (la API ya lo soportaba desde s147). - **Fix (push directo `9997fe50`)**: el proyecto elegido persiste en localStorage (`workspace:dashboard:taskProject`); el filtro de persona usa `parseAssignees` (multi-asignado + "Equipo" legacy, antes era igualdad exacta y ocultaba tareas); refetch al volver a la pestaña (visibilitychange/pageshow) + vuelta a "Todos" si el proyecto guardado se borra. - **Diagnóstico**: la "tarea EN CURSO que no aparecía" era el chip de persona persistido (s69), no un bug — reproducido del lado servidor (115 tareas, #131 de Edu en rank 56; lógica cliente verificada con datos reales). - **Verificación**: tsc + biome + prettier + pre-commit verdes; 2 deploys CF Pages verdes (Vigía). Sin deudas.

Edu: nace /secre, la secretaria del equipo en Claude (Plan H2)

construimos `/secre`, una "secretaria" dentro de Claude para llevar el plan del semestre sin abrir el Gestor. Escribes `/secre` y ves **tus** tareas del Plan H2 (las tuyas, las compartidas y las del equipo) con sus fechas. Desde ahí las vas avanzando — marcarlas "en curso" o "hecha" y dejar notas — y todo aparece en el Gestor de Tareas de la web para los tres, porque es la misma base de datos (lo que tocas en un sitio se ve en el otro). Y lo más vistoso: cada tarea tiene un "chat" donde podéis escribirle a Claude (marcando el mensaje "→ Claude") y os responde ahí mismo, como un miembro más del equipo — eso sí, contesta cuando abrís la tarea, no al instante. Empezó llamándose `/mi-plan` y Edu lo rebautizó `/secre` (de secretaria), pensando ya en que más adelante gestione todo el tablero, no solo este plan. **Detalle técnico** (autor: Edu con Claude · workspace + claude-method · 3 fases, todo en PROD): - **F1 (ver)**: `list_tasks` MCP acepta `project_id`/`project_name` (espejo del REST de s147). Skill `/secre` en `claude-method/global-skills/secre/SKILL.md` (se propaga a los 3): identidad por perfil, filtra propias+compartidas+Equipo sin `done`. E2E OK. Commit ws `69c8c9f1`. - **F2 (registrar)**: `update_task` sella `started_at`/`completed_at` en la transición (espejo del PUT REST) + `resolution`; nueva tool `add_task_comment`. Verificado en vivo Gestor→skill (Edu marcó la tarea 131 "en curso" → el skill la vio con fecha de inicio + comentario). Commit ws `16041d3e`. - **F2.5 (chat · Claude uno más)**: `list_task_comments` (leer hilo) + `add_task_comment` admite autor/destinatario `Claude`; REST `comments/index.ts` permite "Claude" como destinatario (no autor); UI (`constants.ts`/`TaskModal.tsx`/`TaskCommentsView.tsx`): color coral, iniciales CL, chip "→ Claude" en el modal, filtros. Skill responde firmando «Claude», asíncrono. Commit ws `646d8e80`. - **Rename** `/mi-plan`→`/secre` (dir + SKILL + refs en código y wiki). Docs: `workspace--producto--plan-ejecucion-h2-2026` documenta `/secre`. - **Verificación**: `tsc` limpio en cada tanda; 3 deploys de CF Pages verdes (Vigía). claude-method: `d8b0d88`+`4a6767d`+`9e98e1a` + rename. - **Pendientes (sin bloquear)**: F3 (saludo de `/secre` al arrancar la sesión) · evolución a agente de todo el Gestor (requiere exponer proyectos vía MCP).

Edu: arranque, construcción y despliegue de la Landing del SaaS

empezamos la web de presentación del producto desde cero. Le mostré a Edu 3 estilos visuales en imágenes (las pudo mandar al grupo por WhatsApp), votasteis una mezcla de dos, y la construí: rápida, bilingüe (inglés/español) y con la imagen de marca del producto. Ya está publicada pero **protegida**: vive en `esfericlabs.com` y solo entráis los tres con vuestro email (Cloudflare Access); un desconocido solo ve el login. A partir de ahora cada cambio se publica solo al subirlo. Falta construir el resto de la página (ahora solo está la portada). **Detalle técnico** (autor: Edu con Claude · repo nuevo + infra): - Repo `CreaRackSL/crearack-landing`: Astro 6 + GSAP + Lenis, EN(raíz)/ES(`/es/`), tokens+fuentes de la app (Oswald + IBM Plex Sans). Dirección "Editorial Tech + Bento". - Deploy: Cloudflare **Workers + Static Assets** (Pages daba `8000011`), Git integration push→deploy. Dominio `esfericlabs.com`+`www`, `workers.dev` off, **Access "Team only"** reutilizada del workspace. - **MCP de Cloudflare** conectado (gestión CF desde Claude). Detalle: LOG s148 + memorias `project_landing_crearack_s51_kickoff` + `reference_cloudflare_mcp`.

Dani: el acceso directo "Claude Workspace" del escritorio deja de romperse con cada update de PowerShell

el icono "Claude Workspace" del escritorio de Dani había dejado de arrancar nada al hacer doble clic. La causa: apuntaba a una ruta de PowerShell que **lleva el número de versión dentro**, y al actualizarse PowerShell (de 7.6.2 a 7.6.3) esa ruta desaparece. Reparé el acceso directo en el momento y, sobre todo, **arreglé el script que los crea** para que use una ruta fija que no se rompe con las actualizaciones — así no le pasará lo mismo a Edu ni a Txell. 0 cambios de producto (herramienta interna del equipo). **Detalle técnico** (autor: Dani con Claude · harness/onboarding, 0 producto): - **Síntoma**: `Claude Workspace.lnk` con `TargetPath` = `...WindowsApps\Microsoft.PowerShell_7.6.2.0_x64...\pwsh.exe` (carpeta inexistente tras el update a 7.6.3). El resto del shortcut (script `claude-launch.ps1`, icono, workdir) estaba intacto. - **Fix en la fuente** (`CreaRack-Pro/scripts/windows/install-claude-shortcut.ps1`, commit `1bd46f12`, +29/-2): la detección de `pwsh.exe` ahora incluye el **alias estable** `%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe` como candidato y **normaliza** cualquier ruta versionada que devuelva `Get-Command` a ese alias. En máquinas con PowerShell vía MSI (`C:\Program Files\PowerShell\7`) no cambia nada (esa ya es estable). Shortcut de Dani reparado in situ. - **Verificación**: lógica de detección probada aislada → resuelve a la ruta estable y existente. CHANGELOG + RELEASE_NOTES al día. Push directo a main (fix .ps1 + docs, no toca `.py` → CI rápido no se dispara). **Cero deudas.**

Edu: Plan H2 accesible en la wiki + feature "Proyectos" en el Gestor de Tareas

dos cosas. **(1)** Hicimos accesible a todo el equipo el plan de ejecución del semestre (jul→dic): el desglose mes a mes con responsables vivía solo en `CreaRack-Pro/PLAN_EJECUCION_H2-2026.md` y ahora hay una página wiki que lo espeja, así cualquiera ve el panorama completo sin esperar al día 1 de cada mes. **(2)** Construimos una funcionalidad nueva en el Gestor de Tareas: **agrupar tareas en "Proyectos"** (con cabecera de objetivo y barra de progreso). Una tarea normal sigue naciendo en la "base"; si le asignas un proyecto, se agrupa y puedes filtrar el panel por él sin que ensucie el resto. Pensado para meter todas las tareas del Plan Producto H2 (jul→dic) bajo un solo proyecto. Falta desplegar (CF Pages, en pausa por la economía de Actions) y luego crear el proyecto y volcar las tareas. **Detalle técnico** (autor: Edu con Claude · feature full-stack + docs): - **Wiki**: nueva `workspace--producto--plan-ejecucion-h2-2026` (vista completa del semestre, espeja el doc fuente de CreaRack-Pro) + enlace cruzado desde `plan-producto-h2-2026`. - **Feature Proyectos de tareas**: migración `0045_create_task_projects.sql` (tabla `task_projects` + `tasks.project_id` nullable + índices; **aplicada a D1 local y remoto**). API CRUD `/api/projects` (+`/[id]`) con progreso (`task_count`/`done_count`) en SQL; `/api/tasks` filtra por `?project_id=` y acepta `project_id` en POST/PUT (lógica para mover a base o preservar). UI: `TaskManager` (selector + cabecera con barra de progreso + filtro) y `TaskModal` (campo Proyecto, default base, hereda el proyecto seleccionado al crear). **Añadido `ProjectModal`** (crear/editar/eliminar proyecto desde el botón **+ Proyecto** de la barra y **Editar** en la cabecera) — sin él no había forma de crear proyectos en la UI y la feature quedaba invisible (los controles solo aparecen con ≥1 proyecto). **Sin breaking changes** (project_id nullable = base; tareas existentes intactas). - **Verificación**: `vitest run` 55/55 · `tsc --noEmit` 0 errores. Sin test de endpoint (el repo testea funciones puras; cabría un `test:integration` con `vitest.workers.config.ts` como mejora). - **Documentos del plan migrados a la wiki** ✅: `PLAN_PRODUCTO_2026.md` y `PLAN_EJECUCION_H2-2026.md` (vivían en la raíz de CreaRack-Pro, fuera de la política "la doc vive en la wiki") volcados **completos** a sus páginas wiki del WS — fuente de verdad accesible a todo el equipo sin GitHub — y **eliminados del repo** (CreaRack-Pro `7c1330f1`, 431 líneas). Las páginas pasan de resumen a documento entero. Descripciones de tareas reescritas en lenguaje llano (no el volcado técnico inicial). - **Proyecto poblado** ✅: creado **"Plan Producto H2"** con sus **29 tareas (jul→dic)** volcadas directo a D1 (local + prod) vía `scripts/seed_plan_producto_h2.sql` — insert directo, NO por API, para **no disparar 29 emails** al equipo. Reparto = "quien tira" del plan, due_date = fin de mes de cada bloque. CF Pages desplegado. (Nota: la feature necesitó 2ª iteración — faltaba la UI de crear proyectos: `ProjectModal` + botón "+ Proyecto" + "Editar" en la cabecera.)

Edu: DCA entra en NetBird + infra_servers consolidado + Tailscale archivado

metimos el servidor nuevo **DCA** en la VPN NetBird del equipo (ya se ve con prod y staging sin abrir puertos), y aproveché para ordenar la documentación de infra: el inventario de servidores ahora incluye los tres y la red NetBird como toca, y **archivé todo lo que aún hablaba de Tailscale** (que retiramos en mayo) para que no despiste en el día a día — **sin borrar el histórico**. Trabajo hecho desde el repo DCA + el workspace, en paralelo a la sesión de dev (que cerró su parte de s147 aparte). **Detalle técnico** (autor: Edu con Claude · docs/infra, 0 cambios de producto): - **DCA en NetBird** (NetBird Cloud, no self-hosted): peer `dca.netbird.cloud` / `100.96.6.166`, agente 0.72.4, instalado como root (`install.sh` + `netbird up --hostname DCA`). P2P con la flota. Detalle en repo DCA `supercontext/infra_dca.md` (+ memoria `project-dca-netbird`). - **`infra_servers.md` consolidado** → inventario maestro del equipo: añadido DCA (3er servidor), formalizada la red NetBird (grupo `servers`), accesos `(tailnet)`→`(NetBird)`. `README.md` de shared-memory y `CLAUDE.md` del workspace (SSH `tailnet`→`NetBird`) al día. - **Tailscale archivado** del supercontexto que se carga a diario: onboarding `edu`/`dani`/`txell` (instrucciones y pasos de laptop → NetBird, tomados de `claude-method/guides/NETBIRD_SETUP.md`; comandos SSH intactos); wiki `tailnet-setup` `status: active→archived` + banner de obsolescencia. **Histórico intacto** (WORKLOG, `decision--*`, CHANGELOG, RELEASE_NOTES, migraciones SQL `0018`/`0019` ya reemplazadas por `0038`/`0039`). - **Sincronización wiki→D1**: es automática vía `post-merge-ingest.yml` (`reconcile_wiki_to_d1`) y `archived` se excluye de búsquedas/bib_ask (`WHERE status='active'`). ⚠️ **Pero el ingest no corre desde el 12-jun** (posible Actions pausadas, footgun `gh_actions_push_paused`) → el `archived` está en el `.md` (fuente de verdad) pero puede no haberse propagado aún a D1. Pendiente verificar/reactivar. - ⚠️ **Pendiente NetBird**: confirmar que el peer `dca` está en el grupo `servers` del dashboard para heredar políticas de prod/staging.

instalado Impeccable en mi perfil para el futuro diseño de la landing (sin tocar el repo)

sesión corta de preparación. Repasé qué tenemos pendiente (sigo con 4 tareas mías de mayo vencidas: alta banco #20, patente #21, seguro RC #22, facturación #19) y dejé instalado en mi perfil **Impeccable**, la herramienta de diseño que usaremos para la landing del SaaS (paso que me tocaba de la tarea #101). Decidimos **no dejarlo dentro del repo** porque está pensado para que cada uno lo instale en su máquina (si lo subiéramos, habría líos de versiones entre los tres); lo añadí al `.gitignore`. No arranqué el diseño en sí: el proyecto de la **landing lo inicia Edu** (es su tarea), con su propio repo nuevo `crearack-landing` que todavía no existe. Aquí solo dejé lista mi herramienta. **Detalle técnico** (autor: Txell con Claude · 1 commit a workspace, sin cambios de producto): - **Impeccable v3.0.3** instalado vía `npx impeccable install` → quedó a nivel proyecto en `.claude/skills/impeccable/` + `.github/skills/` + hooks en `.claude`. - **No vendorizado** (#101 lo marca explícito): añadidas ambas rutas al `.gitignore` (commit `480dfdc`, rebaseado/pusheado a main como `4d42aab`). Mi instalación local sigue operativa; Edu/Dani instalarán la suya. - **Init NO ejecutado**: `/impeccable init` habría generado contexto de diseño para el panel interno del workspace, no para la landing. Verificado que `crearack-landing` no existe (ni local ni en la org). El init en modo BRAND queda para la sesión de kickoff de Edu. - **Footgun**: el mensaje del primer commit salió mal formado por usar here-string de PowerShell (`@'...'@`) dentro de la herramienta Bash; corregido con `git commit --amend`. Recordatorio: en la herramienta Bash, sintaxis bash; here-strings PowerShell solo en la herramienta PowerShell.

Cierre de pendientes + #69 completo + harness para la landing

Cierre de pendientes + #69 completo + harness para la landing

Txell: nuevo servidor DCA + widget Servidores recolocado, emails de tareas nuevas, y onboarding que ya instala todo solo

jornada de varias cosas. **(1)** Dimos de alta un tercer servidor en Hetzner para un proyecto nuevo, **DCA**; lo renombré en Hetzner (era `ubuntu-4gb-hel1-1`) y recoloqué el widget de Servidores del Dashboard, que se había quedado descuadrado al pasar de 2 a 3 servidores — ahora es una rejilla 2×2 con los tres servidores grandes y, en la cuarta casilla, los dos pequeños (SSL y Workspace) apilados a media altura. **(2)** Monté lo que pedí: que **cada tarea nueva del Gestor avise por email** a los implicados (asignado + creador), con un tag fijo en el asunto `[WS-TAREA][PRIORIDAD]` para poder ordenarlas con reglas en el correo. **(3)** Y, lo más útil de cara al futuro: arreglé en el método (claude-method) el **goteo de instalaciones** que sufríamos Dani y yo — el onboarding ahora **instala solo** todo lo que falte (incluidos `jq` y `hcloud`, que hoy tuve que poner a mano) y deja las dependencias del proyecto listas. Todo mergeado y en main. Hablé con Edu y confirmó que los tres tenemos permisos de push/merge en todos los repos (ya está en las reglas). **Detalle técnico** (autor: Txell con Claude · workspace PR #117 + #117-widget · claude-method PR #9 · todo squash-merge a main, CI verde): - **Widget Servidores** (`src/components/widgets/ServerGrid.tsx`, commit `4df651f`): separa Hetzner (3 cards grandes con barras CPU/Disk/Net) de monitores externos; SSL+Workspace agrupados en una celda partida (`MiniCard`) → rejilla 2×2 equilibrada. `canonicalServerName` reconoce DCA (acepta el nombre nuevo y el original `ubuntu-4gb-hel1-1`). Push directo a main. - **DCA en Hetzner**: renombrado vía `hcloud server update` (token Read&Write puntual, ya revocado). `hcloud` instalado en mi equipo vía `winget install HetznerCloud.CLI`. - **Email de tareas** (PR #117, merge `57ac2ca`): nuevo `functions/_lib/task-notify.ts` (`notifyTaskCreated` vía Resend, falla en silencio) + `notifyEmailsForTask` en `_lib/staff.ts` (asignado+creador, dedup, Equipo=los tres). Enganchado en los dos caminos de creación: `api/tasks/index.ts` (web, `waitUntil`) y `api/mcp/handlers/workspace.ts` (MCP, `await`). 7 tests nuevos. Requiere `RESEND_API_KEY` (ya presente). - **Onboarding auto-install** (claude-method PR #9): `bootstrap-profile.ps1` pasa de comprobar a **comprobar+instalar** prereqs vía winget/npm (manifiesto con Ids verificados), añade `jq`+`hcloud`, corre `pnpm install` en los repos con package.json, Docker opt-in, switch `-SkipAutoInstall`. Guías de onboarding actualizadas. - **Footgun detectado**: `pnpm install` reinstala husky y le roba `core.hooksPath` al harness (lo restauré con `--unset`); además el `pnpm exec` del hook husky choca con `ERR_PNPM_IGNORED_BUILDS` (esbuild/sharp/workerd) → workaround `verify-deps-before-run=false`. Posible reconciliación husky↔harness para Edu/método.

Edu: arreglado que Claude no dejaba pushear a Dani ni a Txell ("solo Edu puede subir") — confianza total en todas partes

Txell y Dani me avisaron de que, cuando intentaban subir cambios, su Claude les decía que **solo yo podía hacerlo y que tenía que aprobarlo yo**. Yo nunca puse esa norma. Al investigar salió la causa: a nivel de GitHub **nunca estuvieron bloqueados** (de hecho ya subían cosas a diario), el problema era que las normas escritas del proyecto estaban redactadas "en clave Edu" (decían cosas como "no subir sin consenso de Edu") y el Claude de ellos, leyéndolas, se autolimitaba por prudencia. Lo arreglé dejando escrito **bien claro en los cuatro sitios** que somos un equipo plano de confianza total: los tres subimos y fusionamos sin pedir permiso a nadie; "consenso" se refiere al *plan*, no a un permiso por persona. Comprobé además que **los tres somos dueños (owners) de la organización en GitHub**, así que ya tenemos control total sobre todos los repos, también los que creemos en el futuro, sin tocar nada. Verificado al final: Txell ya sube y fusiona sin problema (incluso una mejora con su propio PR). **Detalle técnico** (autor: Edu con Claude · 0 cambios de producto · docs/harness): - **Diagnóstico**: branch protection de `main` (Pro + claude-method) solo exige checks de CI, **sin review obligatoria**; sin CODEOWNERS ni rulesets. Permisos efectivos: `tfuentes`/`dfuentes` = **admin, push=true** en los 4 repos. `orgs/CreaRackSL/members?role=admin` → los 3 son **owners** (role=member vacío) → admin en todos los repos presentes y futuros; el `default_repository_permission: read` no afecta a owners. **GitHub nunca bloqueó**; el "solo Edu" era inferencia del agente desde la redacción Edu-céntrica. - **Fix (4 fuentes vivas, todas en main)**: `CreaRack-Pro/CLAUDE.md` R4+R20 (`99b893ce`) · `CreaRackSL-workspace/CLAUDE.md` R4+R14+§6 (`a1c821bc`) · `claude-method/workflow/git-flow.md` nueva sección "Confianza total" (`b390bd2`, harness global que leen los 3 → cubre repos futuros) · `Esquembri/domo-channel-assistance` (DCA) `CLAUDE.md` R4 (`5c83df2`). "Consenso" reapuntado al *plan* (Regla 6), nunca permiso por persona. - **Descartado a propósito**: los `solo Edu` restantes son legítimos (endpoint admin Zoho `admin-revoke`/`?as=`, descripciones de perfil) → intactos. Copias en `miscelanea/`/`backups/`/`claude-backups/` = snapshots, no fuentes vivas. - **DCA**: está en mi cuenta personal (no en la org); Dani/Txell no son colaboradores ahí (lo llevo yo solo; lo incorporaré a la org CreaRackSL en el futuro). La regla nueva es inocua mientras tanto. - **Verificación final**: Txell pusheó a `CreaRackSL-workspace` (`15:24Z feat(tasks) #117`, `15:26Z docs(worklog)`) + claude-method (`15:25Z`), todos **posteriores** al fix. Funciona. - **Pendiente operativo**: el `CLAUDE.md` del workspace **no se auto-propaga** → para las sesiones vivas de Dani/Txell, `git pull --rebase` + reinicio (se lo dice Edu).

Dani: control de sincronización + cuarto (y definitivo) fallo de la barra coralline cazado en la fuente — el bash de WSL en PowerShell

sesión de control para confirmar que tengo todo sincronizado (repos y harness). Los tres repos al día y limpios. Al verificar la barra de estado (coralline) descubrí que, aunque se ve bien dentro de Claude Code, fallaba al lanzarla desde PowerShell: en mi máquina hay WSL instalado, y `bash` "a secas" cae en el lanzador de WSL (que no tiene distro) en vez de en el Git Bash que dibuja la barra. El arreglo de ayer (s144) ya contemplaba ese caso, pero solo se activaba si `bash` resolvía a WSL **en el momento exacto** de instalar — y como el arranque de sesión corre dentro de Git Bash, la detección no saltaba y dejaba la configuración a medias. Lo dejé determinista: **si WSL está instalado en la máquina, se fija siempre la ruta absoluta de Git Bash**, sin depender de qué `bash` gane el PATH según desde dónde se lance. Arreglado en la fuente (claude-method) y subido directo, así se propaga a Edu y Txell en su próximo arranque. **Detalle técnico** (autor: Dani con Claude · claude-method `fa0e345`, push directo a `main` · workspace solo WORKLOG): - **🔄 Control**: workspace, claude-method y CreaRack-Pro los tres `0 ahead / 0 behind` y limpios. Hooks pre-push al día en los 4 repos de la org, memorias y git-config al día (vía `claude-method-sync` del SessionStart). - **🩺 Causa raíz (4º fallo encadenado de coralline, tras s141→s142→s143)**: `install-coralline.ps1` detectaba el caso WSL mirando `(Get-Command bash).Source` en tiempo de instalación. Pero esa resolución depende del **contexto de lanzamiento**: el SessionStart hook corre en Git Bash → `Get-Command bash` devuelve Git Bash → la condición `-like "*\System32\*"` no disparaba → dejaba `"bash"` en el `statusLine.command`. Luego, al invocar la barra desde pwsh, `bash` resolvía a `C:\Windows\System32\bash.exe` (lanzador WSL sin distro) → barra vacía. En esta máquina conviven dos `bash.exe` en el PATH (System32/WSL + WindowsApps) y cuál gana es lotería de contexto. - **🔧 Fix en la FUENTE** (`harness/install-coralline.ps1`, +11/-1): detección determinista — `$wslPresent = Test-Path $env:WINDIR\System32\bash.exe`; si el lanzador WSL **existe**, `"bash"` es PATH-dependiente y no fiable → se fija la ruta absoluta de Git Bash en short-path 8.3 (`C:/PROGRA~1/Git/bin/bash.exe`, sin espacios → sin comillas). Sin regresión para Edu/Txell: en máquinas sin WSL `$wslPresent=false` y se conserva `bash`. - **✅ Verificado**: `settings.json` resultante usa `C:/PROGRA~1/Git/bin/bash.exe …statusline.sh`; render desde pwsh con el comando exacto pinta dir/git/modelo/reloj; instalador idempotente (2ª ejecución → `al dia`, sin `.bak` nuevo).

Edu: rematados los 12 fallos del editor de racks (tarea #97 cerrada) + recuperado un switch de pruebas + tapado un hueco de registro

sesión larga para terminar de arreglar el editor de racks (los fallos que había encontrado la auditoría). **Quedaron resueltos los 12**: comparar copias de seguridad (estaba roto del todo), refrescar la info de equipos en redes internas, los equipos de "media anchura" que no dejaban guardar el rack, conectar equipos entre racks distintos, ver conexiones que quedaban ocultas, y —importante— el botón "Test Connection" que **antes mentía** (decía "conexión correcta" siempre) y ahora prueba de verdad. También añadí el campo de email al dar de alta usuarios. **Un caso curioso**: un switch de pruebas de Edu salía con muy poca información; resultó que su "ficha" buena se había borrado en el lío de equipos duplicados de días atrás y se quedó pegado a una vacía. Edu lo volvió a descubrir (quedó al 85%) y yo dejé todo cuadrado en el sistema. Investigué por qué se había borrado: no había quedado ningún registro de ello —un agujero que **ya he tapado** para que la próxima vez sí se sepa quién borra qué—. Todo subido, comprobado en verde y desplegado. Honestamente: en ese switch me equivoqué al principio en el diagnóstico y Edu tenía razón; lo aclaré mirando el sistema en producción a fondo. **Detalle técnico** (autor: Edu con Claude · Pro PRs #140-#149 squash-merge a main, verdes por Vigía · tareas #97 y #74 cerradas): - **#97 (12 bugs, 4 tandas + flecos)**: #140 comparar-backups (GET→POST + diff string→array) · #141 SNMP/SSH (read-port 200+flag, `creds`→`details`, ocultar Re-scan SNMP) · #142 stencils/library (restore homónimos→uuid, visio-confirm 500, comilla en Edit) · #143 cross-rack (`/api/racks/list`, PortAssignModal) · #145 **regresión half-width overlap** (`placement.py` valida por (U,columna) con `slot_from_model_data`) + Device Info · #146 Refresh modal vía Local Agent (`agent_probe.js` compartido, Regla 2) · #147 conexión entrante invisible · #148 Test Connection real vía Agent (retirado mock, Regla 13). **+#144** campo email (#74). - **Switch rack 772**: profile 136 (bueno) borrado → device 419 quedó en profile 138 vacío; re-descubierto por Edu vía Agent (85%, 33 ifaces) + `profile_id` 136→138 corregido en PROD. `linked_device`=`SET_NULL` (la limpieza de devices de s142 no lo borró por cascada). - **#149**: `delete_profile` era el único endpoint destructivo de `network` sin `log_action` → auditado. - **Deudas**: strings EN nuevos sin traducir (F4 #94) · otros borrados de `network` sin auditar (mejora) · fichas Atlas marcadas (firma `validate_device_placements`).

Edu: recorte de gasto en GitHub + mudanza de tareas de la Biblioteca al servidor propio + urgencia en el editor de racks (arreglado un borrado de datos que no sabíamos que pasaba)

dos frentes hoy. **Gasto de GitHub**: seguimos apretando. Mudé al servidor propio (Hetzner) tres tareas automáticas de la Biblioteca que antes corrían en GitHub gastando minutos —y que además me llenaban el correo de errores cada madrugada—; ahora corren gratis y sin ruido. Descarté otra idea porque medí que casi no ahorraba. Y como entre GitHub, el servidor y mi PC era un lío saber "qué se ejecuta dónde", escribí un documento único y vivo que lo lista todo (qué hace cada tarea, dónde corre, cuánto cuesta) para no volver a ir perdidos. **Urgencia**: Edu detectó fallos en el editor de racks con un switch de pruebas. El rack tenía equipos duplicados que impedían guardar (lo limpié), y al revisar a fondo TODO el editor con una auditoría automática salieron **17 fallos** que no habíamos visto. El más grave: **las notas que escribías en un equipo se borraban solas al guardar el rack**. Ese lo arreglé hoy mismo y ya está en producción; los otros 12 quedan apuntados y ordenados por prioridad para la próxima sesión. **Detalle técnico** (autor: Edu con Claude · Pro `fcc24493` · workspace varios commits · Hetzner STAGE · tareas #96/#97 creadas, #86/87/88/90/92 cerradas): - **Recorte Actions**: reindex claude-method+TS a `* * 1,4` (supercontext diario); filtro paths CF Pages descartado (medido). **Super-Cron Fase A.2**: 3 reindex del workspace migrados a Hetzner (`/etc/cron.d/bib-reindex-ws` + `scripts/cron-bib-reindex-ws.sh`, Node 20 + 2 deploy keys read-only + clones en `/opt`, validado). Doc viva `public/supercontext/AUTOMATISMOS.md`. - **#87 drift harness** regularizado (Pro+workspace, actionlint + `.gitattributes` LF). Memoria `feedback_automatismos_investigar_antes` (investigar estado real antes de tocar automatismos; casi reactivo en Actions crons que ya vivían en Hetzner). - **Editor de racks**: rack 772 duplicados limpiados en PROD (418/421); auditoría workflow (25 agentes) → 17 bugs; **data-loss de notas arreglado** (`racks/schemas.py`+`services/racks.py`+tests, en main); 12 bugs restantes en tarea #97 (due 18-06).

Txell: sesión de control del método — los tres repos al día y, de paso, descubierto y arreglado por qué CreaRack-Pro se me quedaba siempre atrás

hoy era una revisión de rutina para comprobar que tengo todo sincronizado y que el "método de trabajo" funciona en mi equipo. El workspace y la caja de herramientas (claude-method) estaban perfectos, pero **CreaRack-Pro estaba 242 versiones por detrás** y con unos ficheros viejos colgados de hace tres semanas. Lo puse al día. Pero lo importante fue entender **por qué** se quedaba atrás una y otra vez (ya había pasado): resulta que al abrir una sesión, el sistema solo actualiza automáticamente **la carpeta en la que estoy trabajando** (yo siempre estoy en el workspace), así que CreaRack-Pro, al vivir en otra carpeta que nunca abro, no se refrescaba jamás. Como por la Regla 15 cualquiera de los tres debemos poder sustituir a los demás en cualquier momento, eso no puede quedar así. Preparé un arreglo para que, en cada arranque, se mantengan frescos **todos** los repos del equipo —no solo el que tengo abierto—, con cuidado de no pisar nunca trabajo a medias. Lo dejé en un PR para que Edu le dé el visto bueno antes de subirlo (es la pieza compartida del método). Y de paso cerramos del todo el tema de la barra de estado (coralline), que ya se ve. **Detalle técnico** (autor: Txell con Claude · claude-method PR #8 `txell/auto-sync-org-repos`, SIN mergear · workspace solo WORKLOG + STATE, 0 código de producto): - **🔄 Control**: workspace `bddf30d` y claude-method limpios y al día. **CreaRack-Pro** estaba `behind 242` + 3 ficheros del harness con deriva del 24/05 (`pre_commit_check.py`, `bib_report_check.py`, `wiki_front_matter_check.py`). Verificado por hash de contenido normalizado que `origin/main` == fuente `claude-method` (la versión correcta ya estaba publicada) → los cambios locales eran deriva obsoleta. `git checkout` de los 3 + `git pull --rebase` → CreaRack-Pro al día (`9e65c056`), scripts idénticos a la fuente. - **🩺 Causa raíz**: la frescura automática está atada al **CWD**. `session-start.ps1:28` hace `git pull` solo del repo donde abres la sesión; `claude-method-sync.ps1` (sección 1) solo pullea claude-method. Ningún otro repo de la org se auto-actualizaba. El detector de drift del harness (sync 0.6) solo inspecciona el repo del CWD → la deriva de CreaRack-Pro nunca disparó aviso. El hook pre-push (0.7) sí conoce todos los repos pero solo actúa al subir, y Txell no sube CreaRack-Pro. - **🔧 Fix (PR #8)**: nuevo `harness/sync-org-repos.ps1` (paso 0.8 del sync, proceso hijo idempotente, flag `-SkipOrgRepos`). Reutiliza el barrido por `origin` de la org de `install-git-hooks.ps1` (0.7). Por repo: `fetch` + `pull --rebase` **solo si está limpio y es fast-forward**; si tiene cambios locales sin commitear o divergió, **avisa sin tocar nada** (nunca pisa trabajo en curso). Excluye `claude-method` (su delta lo gestiona la sección 1 comparando HEAD antes/después; adelantarlo aquí rompería esa detección). Validado E2E en local: clean+behind→auto-pull `CreaRack-Pro (+1)` y restaurado; dirty+behind→avisa sin pullear; todo al día→`[org-repos] N repos al día`. README del harness catalogado (commit `047f919`). - **🩹 Coralline cerrado**: Txell confirma que ve la barra. Memoria `project-coralline-jq` marcada como cerrada/verificada. - **📝 Memoria**: `feedback_apaga_ritual` ampliada — las anotaciones de WORKLOG/STATE pertenecen al ritual de "apaga", no se sacan a mitad de sesión.

Txell: la barra de estado (coralline) por fin se ve — tercer y último fallo cazado y arreglado en la fuente

arrastrábamos desde hace días que la barra de abajo (la de colorines con carpeta, rama, modelo y hora) no aparecía en mi PowerShell, por mucho que reiniciara. Hoy dimos con el último culpable. No era ni el `bash` (s141) ni las comillas de la ruta (s142): era un ajuste de "refresco cada 1 segundo" que, como la barra tarda ~2 segundos en dibujarse en Windows, hacía que Claude Code la cortara a media y volviera a empezar sin parar — un bucle infinito que dejaba la barra en blanco. Subido ese refresco a 10 segundos, la barra termina tranquila y se ve. Lo importante: el arreglo está hecho en el **método del equipo**, no solo en mi máquina, así que a Edu y Dani (también Windows) ya no les pasará. Reinicio Claude Code una vez para confirmarlo.

Edu: GitHub más barato y más rápido (recorte de gasto, parte 1) + un freno a tiempo en la parte 2

seguimos con el plan de ayer para gastar menos en GitHub. **Lo conseguido**: las dos comprobaciones más caras (construir la imagen del programa y el escáner de seguridad) ya no se lanzan en cada subida — la primera solo cuando de verdad cambia algo de la imagen, el segundo una vez al día. Y lo que más se nota en el día a día: la tanda de pruebas larga (unos 6 minutos) ya no corre cuando la subida no toca código de programación (documentación, ajustes…), así que esas subidas se confirman en un minuto en vez de seis. También pusimos un "corrector" que revisa los ficheros de automatización antes de subirlos, para no malgastar comprobaciones por una errata. **Lo que paramos a tiempo**: la última parte (mover la construcción de la web interna a los servidores de Cloudflare) resultó ser volver a un sistema que ya nos dio problemas en abril y del que salimos a propósito — así que lo dejamos para revisar en julio, con calma y con datos. Fue una sesión con tensión: ese plan se había apuntado sin cruzarlo con esa decisión vieja. **Detalle técnico** (autor: Edu con Claude · Pro #138 `195945be` + #139 `6842bee0` · claude-method `30fc69c`): - **PR #138**: `Docker Build` condicionado por paths (job `changes` con git diff) + `Security Scan` a cron diario (`security.yml`); ambos fuera de los required checks de `main` (se conservan Backend+Frontend). - **PR #139**: shards de backend solo si cambia Python; el agregador `Backend (Lint, Test)` (required) reporta verde cuando se saltan → PRs no-Python en ~1 min. Recorta el ~66% del gasto (CI de Pro). - **Gate actionlint** en el pre-commit (Regla 6, propagado al staff vía claude-method); actionlint instalado en `~/bin`. Memoria `feedback_actionlint_workflow_gate`. - **#95 cerrada** (signage fase 2): el auto-match por vendor de #137 ya cubre el caso real. - **Parte 2 (CF Pages nativo) parada**: revierte la migración de s36; aplazada a julio. NEXT corregido con el aviso. - Pendiente: drift harness #87 (copia de `pre_commit_check.py` en Pro sin commitear).

Txell: arreglada la statusline (las barras de contexto/uso no se veían) + mejora propuesta al método para que no le pase a nadie más

las barras de contexto y uso que instaló Edu (la "statusline") no me aparecían en la consola. Resultó que mi PowerShell no encontraba el programa `bash` (el que dibuja la barra), así que fallaba sin avisar y no salía nada. Lo arreglamos poniendo `bash` en el sitio donde el sistema lo busca, de forma **permanente** — ahora debería verse al abrir una consola nueva. Y como esto le puede pasar a cualquiera con una consola "limpia", preparé una mejora en el método de trabajo (claude-method) para que el alta de un equipo nuevo lo deje resuelto de fábrica y, además, se auto-corrija en cada arranque también en los equipos de Edu y Dani. Queda en un **PR (#7) a la espera del visto bueno de Edu** — no lo subí del todo a propósito. **Detalle técnico** (autor: Txell con Claude · claude-method PR #7 · workspace solo WORKLOG + STATE, sin código de producto): - **🩺 Diagnóstico**: coralline instalada y correcta (script OK, Claude Code v2.1.177, hooks `pwsh`/`python` sanos), pero `statusLine.command = bash "...statusline.sh"` fallaba porque `bash` no estaba en el PATH del PowerShell de Txell — Git for Windows no añade su carpeta `bin/` al PATH por defecto. Mismo motivo por el que el banner de NEXT tampoco lucía (conhost clásico, sin Windows Terminal → encoding). - **🔧 Fix local (permanente)**: `C:\Program Files\Git\bin` añadido al PATH de Usuario. `bash --version` resuelve (5.3.9). El `statusLine.command` se apuntó además a la ruta absoluta de bash como doble seguro (aunque el sync lo reescribe a `bash` suelto: el fix duradero es el PATH). - **🚀 PR #7 a claude-method** (rama `txell/onboarding-bash-path`, SIN mergear): `harness/ensure-bash-path.ps1` (helper idempotente/fail-open: detecta el `bash.exe` de Git, añade su carpeta al PATH de Usuario si falta, nunca borra ni reordena) + Step 0b en `setup-claude-code.ps1` (onboarding) + bloque 0.45 en `claude-method-sync.ps1` (converge en cada arranque, cubre los 3 perfiles sin re-onboarding, mismo patrón que la config git del equipo 0.65). Sintaxis de los 3 scripts validada; helper probado idempotente. - **📝 Memoria**: `user-txell-entorno-desktop` ampliada con el diagnóstico y el fix de la statusline.

Txell: revisión de que todo está sincronizado (repos + harness) y dos ajustes de mis preferencias

sesión corta de mantenimiento. Pedí comprobar que los repositorios y el "motor" (harness) estaban al día. **Casi todo perfecto**: el repo del workspace, el del método (claude-method), mis memorias, la statusline y la configuración de git están sincronizados. **Un aviso a tener en cuenta para Edu y Dani**: la copia local del repo de código **CreaRack-Pro** está muy desactualizada (238 commits por detrás de GitHub) y tiene tres ficheros internos del harness con cambios sin guardar — son **solo reformateo de código, nada funcional**. No lo toqué porque es el repo de código y actualizarlo con cambios ajenos sin guardar puede dar conflictos: es una decisión que les corresponde a ellos. Aparte, dejé anotadas dos preferencias mías: que no se use más la coletilla "Hola Edu… perdón, Txell" al saludar, y que trabajo desde la app de escritorio (equivalente a la consola pero más cómoda para mi rol). **Detalle técnico** (autor: Txell con Claude · sin cambios de código · solo WORKLOG + STATE): - **🔄 Verificación de sincronización**: workspace `8c86aeb` limpio y al día; claude-method `4afa9c8` al día; memorias/statusline/git-config/pre-push (4 repos) al día (confirmado por el hook de arranque). - **⚠️ CreaRack-Pro local desfasado**: `git status` reporta `behind 238` (último commit local `0551286b`, s82) + 3 ficheros del harness `M` sin commitear (`pre_commit_check.py`, `bib_report_check.py`, `wiki_front_matter_check.py`). El diff es 100% cosmético (reformateo tipo black/ruff: líneas largas partidas, listas recolocadas). **Origen del aviso de "drift"** del sync. **No intervenido** (Reglas 4 y 15: territorio de Edu/Dani, no sobreescribir trabajo ajeno). **Acción sugerida para ellos**: decidir si llevar el reformateo a claude-method o descartarlo, y luego `git pull` para ponerse al día. - **📝 Preferencias guardadas en memoria** (perfil Txell, fuera del repo): `feedback-saludo-inicio` (no usar la coletilla del saludo) y `user-txell-entorno-desktop` (trabaja desde la app de escritorio).

Edu: arreglada la publicación a las pantallas SpinetiX + Agente local al día + plan para gastar menos en GitHub

Día intenso de varios frentes. **(1)** Saltó un aviso de GitHub de que un proceso nocturno del buscador inteligente había fallado; era un parpadeo puntual de un servicio externo, y lo dejamos blindado para que un fallito así no vuelva a tirar el proceso entero. **(2)** Pusimos al día la ficha técnica del producto y **publicamos oficialmente la versión 2.3.0 del Agente local** (estaba compilada pero sin publicar, así que su mejora de seguridad de contraseñas no llegaba a estar activa de verdad). **(3)** Lo más gordo: **arreglamos la publicación de contenido en las pantallas SpinetiX**, que fallaba. Tras un buen rato de investigación, la causa era que el sistema mandaba a la pantalla la **contraseña equivocada** (la de los puntos WiFi en vez de la de la pantalla). Lo dejamos arreglado de raíz: ahora cada aparato usa su credencial correcta automáticamente — probado y subido a producción. **(4)** Y miramos a fondo **por qué se nos dispara el gasto de GitHub**: el grueso son las pruebas automáticas. Dejamos un plan concreto para recortarlo casi a la mitad la próxima sesión, sin pagar de más.

Edu: el mapa de arquitectura ya está en el buscador + arreglados dos fallos del producto (un botón del panel y el centro de Ayuda)

jornada larga de varias cosas. **(1)** Rematamos el "mapa del programa" que veníamos haciendo: ahora todo ese conocimiento vive dentro del **buscador inteligente interno**, así que se le puede preguntar y responde con la arquitectura real. Retiramos el mapa antiguo (queda guardado por si acaso) y montamos un **vigilante automático** que avisa cuando una ficha se queda anticuada porque el código ha cambiado. **(2)** Revisamos dos herramientas de fuera que recomiendan por internet y decidimos —con motivos— **no adoptarlas** (ya teníamos lo bueno); nos quedamos solo con cuatro mejoras concretas del buscador. **(3)** Lo más importante para el día a día: **arreglamos dos cosas del producto que se habían roto**. Una, el **botón con forma de flecha** que pliega los grupos de armarios en la pantalla principal. Otra, el **centro de Ayuda**, que listaba los documentos pero al pulsar cualquiera no abría nada. Las dos eran efecto secundario de los cambios recientes para traducir el programa al español. Las dejamos arregladas, **probadas en un navegador de verdad** y confirmadas por Edu funcionando. **Detalle técnico** (autor: Edu con Claude · Pro `3b52105b`+`2a9c96f0` · workspace `b8506c9c`+#116 · ventana Fable): - **🗺️ Atlas producto D ✅**: volcado A/B/C/Glosario al grafo Biblioteca en AMBOS repos (consultable por `bib_ask`). **Máster + máster-workspace jubilados** (recuperables). **Mantenimiento**: `scripts/atlas_check.py` detecta fichas desfasadas mirando el git de sus fuentes (cazó 5) + skill `atlas-check` + cron semanal `atlas-check.yml` (desactivado hasta crear el secret `ATLAS_CHECK_PAT`). - **🕸️ graphify** (YC S26): NO adoptar en bloque; 4 cherry-picks al buscador (PR ws #116, verde): camino más corto entre dos nodos, comunidades Louvain (opcional), diagrama Mermaid de llamadas, "insights" del grafo. **📜 Fable5.md**: NO adoptar (ya cubierto; su propio estudio lo desaconseja en configuraciones bien hechas). - **🐞 Botón de colapso del dashboard (`3b52105b`)**: el "arreglo" de s137 atacaba otro síntoma (reconocido). Raíz real: el barrido de traducción metió llamadas al sistema de traducción en código que se ejecuta **antes** de que ese sistema esté listo → un error tumbaba en silencio parte del JavaScript de la página (el botón y, por dentro, el widget de Ayuda). Solución de fondo: cargar el sistema de traducción un pelín antes (síncrono en la cabecera) → blindado para toda la traducción. Verificado A/B con Playwright + test nuevo. - **🐞 Centro de Ayuda · Browse (`2a9c96f0` + `b8506c9c`)**: no abría documentos (apuntaba a una carpeta retirada). Dos puntos: la interfaz dejó de reescribir la ruta a la carpeta inexistente, y el servidor ahora permite leer también la carpeta del español. Verificado contra el lector real de producción + test. **Edu confirmó "todo funciona".**

Edu: el "mapa de arquitectura" del programa destilado de cero + cazado un fallo fantasma del control de calidad

dos frentes grandes. **(1)** Aprovechamos todo lo aprendido en la gran auditoría de seguridad para construir una **documentación de arquitectura excelente**: una ficha por cada área importante (10 en total: armarios, planos, monitorización, red, cartelería, terminal…), un manual con nuestras **8 reglas de oro** de cómo se construyen bien las cosas, un **catálogo de piezas reutilizables** (para no reinventar la rueda) y un **diccionario** de términos del producto. Lo clave: **todo verificado contra el código de verdad**, con un segundo revisor automático que pilló y corrigió lo que ya había cambiado. Es el mejor mapa del programa que tenemos. Falta un último paso (meterlo en el buscador inteligente interno), que dejamos para julio. **(2)** Cazamos un "fallo fantasma": un test que a veces fallaba sin motivo y molestaba cada vez que subíamos código. No era culpa del test: era una carrera entre los procesos de prueba que se pisaban las sesiones de login. Arreglado de raíz y comprobado. **Detalle técnico** (autor: Edu con Claude · Atlas workspace `a089c259`; Pro PR #135 `cd8d2efa`; 2 workflows; ventana Fable): - **🗺️ Atlas de Arquitectura A0-A3** (`atlas-arquitectura/`): A0 ficha piloto `racks` a mano (molde de 10 secciones, verificado contra código). A1 workflow (18 agentes) → 9 fichas de dominio restantes con verificación adversarial. A2+A3 workflow (6 agentes) → Reglas de Arquitectura (8 raíces en positivo + Ousterhout), Catálogo de Helpers (~60, con file:línea), Glosario. 13 ficheros commiteados, CF Pages verde. **Producto D (grafo Biblioteca) → tras reset Actions 1-jul.** Decisión pendiente: jubilar o complementar el Máster. - **🧪 Fix flaky #93 (PR #135)**: el gate pre-push (settings dev, sesiones en cache Valkey compartida) sufría una carrera de xdist que borraba sesiones de login → 400 en cascada; el CI (settings test, sesiones en BD) no. Fix: mover el ajuste a `tests/conftest.py` (cubre dev+test). 5 corridas en verde. Tarea #93 cerrada.

Edu: la Ayuda ya habla español + aviso de idioma al primer inicio + arreglado un botón roto del panel principal

jornada de remate de la **versión española** y de pulido del panel principal. **(1)** El **centro de Ayuda** ahora se muestra en español cuando eliges ese idioma: la lista de temas, el contenido de cada artículo y el asistente que responde dudas. **(2)** Añadimos un **avisito de bienvenida la primera vez** que entras al programa, que te pregunta si lo quieres en inglés o en español, para que todo arranque ya en tu idioma. **(3)** Edu detectó que el botón que **pliega los grupos de armarios por plano** (en el panel principal) se rompía al buscar o filtrar; lo localizamos y arreglamos (un detalle técnico hacía desaparecer la flechita). **(4)** Pusimos en **blanco** los títulos del menú de Configuración para que se lean mejor. **(5)** Edu vio un vídeo de un experto con ideas para trabajar con asistentes de IA y nos quedamos con dos útiles. **Todo está ya en producción.** Con esto, la traducción al español queda prácticamente terminada: solo falta el repaso final, que iremos haciendo entre los tres durante la semana usando el programa (hay una tarea para eso). **Detalle técnico** (autor: Edu con Claude · Pro PRs #133/#134 + workspace #115; claude-method; ventana Fable): - **🌐 i18n F3b ✅ MERGEADA + EN PROD** (Pro #133 + ws #115, Dokploy+CF Pages verdes): `core/api_help.py` `_apply_language(data, lang)` — para español traduce los títulos (mapa EN→ES `wiki-es/titles.json`) y sirve el corpus `wiki-es/` (rewrite de rutas, simetría 82=82, degrada a inglés si falta el mapa); `/api/help/ask` pide responder en español. Inglés intacto. 6 tests nuevos (51 verde en Docker). Workspace `wiki-titles.ts`→`wiki-es/titles.json`. **Trabajado en modo desatendido** mientras Edu estaba fuera; el pre-push gate cazó un **flaky de un test de racks bajo xdist** (ajeno a F3b — lo verifiqué y revalidé verde) → tarea #93. - **🖥️ Dashboard PR #134 ✅ MERGEADO + EN PROD**: fix del colapso de grupos por plano (`filterRacks()` reescribía el contador con `textContent` y borraba el `<span>` de la flecha ▼; bug del rediseño `a370e7fd`, no de la i18n) · **toast de idioma de 1ª ejecución** (mini-diálogo centrado bilingüe sobre el Welcome Wizard; Alpine `langFirstRun` + `localStorage`, `set_language`+recarga) · menú Config (File Operations/Settings/Navigation) en blanco. El toggle de idioma se queda en el modal de Settings de usuario. - **🧰 `mattpocock/skills`** (vídeo de Edu sobre `/handoff`): cherry-pick — skills `grill` (alineación previa: 1 pregunta a la vez + recomendación) + `diagnose` (disciplina de bugs) a `claude-method/global-skills/` (propagadas al staff); glosario de dominio + vocabulario Ousterhout al `PLAN_ATLAS.md`. Memoria `reference_mattpocock_skills_evaluation`. - **Tareas**: **#93** estabilizar el flaky `test_update_devices_in_rack` (xdist) · **#94** revisión de la traducción (F4) por el staff, repartida. - **i18n F0→F3b en PROD; queda solo F4.** Próximo: arrancar el **Atlas de Arquitectura** (tenía vía libre tras la i18n F2).

Edu: completada la traducción de TODO el JavaScript + arreglado el "calvario" de subir a GitHub (CI lento y caro)

dos frentes. **(1)** Rematamos la **versión española del JavaScript del programa** entero: pulimos las tildes y signos de las pantallas de monitorización (F2c) y tradujimos el último bloque, los "cimientos" (login y gestión de usuarios, el chat de ayuda y el tutor, ventanas comunes) — con esto **todo el JavaScript queda traducido** (editor + redes + monitorización + cimientos). **(2)** Edu señaló que subir código a GitHub se había vuelto un **calvario**: lento (~20 min por cambio) y, además, la factura de los chequeos automáticos se había **triplicado** en junio. Lo investigamos con datos reales y resultó que **no es un fallo**, sino el volumen de chequeos que creció con la auditoría de seguridad de las últimas semanas (el nº de pruebas casi se cuadruplicó). Pusimos varios arreglos: ahora el código **se prueba en el PC antes de subirlo** (así va bien a la primera, sin idas y venidas), los chequeos corren **más rápido** (en paralelo y partidos en dos), y recortamos desperdicio. El objetivo: que subir deje de ser un suplicio y la factura baje. La prueba la veremos en julio. **Detalle técnico** (autor: Edu con Claude · Pro PRs #129/#131/#130/#132 + push directo; claude-method; ventana Fable): - **i18n F2c ✅ MERGEADA (PR #129)**: corrección de acentos determinista (`scripts/i18n/fix_po_accents.py`, ~206 líneas `msgstr`) + signos `¿/¡` (`fix_po_punct.py`) + glosario `puerto→port` + validador `check_po.py`. 919 msgids ES. Lo hice YO sin workflow (gratis, respeta la norma s135). - **i18n F2d ✅ MERGEADA (PR #131)**: barrido JS de cimientos (services/utils/effects/auth, 62 ficheros → 30 con texto, 374 msgids/252 nuevos). Workflow `i18n-f2d-js` aprobado por Edu (62 agentes, 3,23M tokens). **JS COMPLETO F2a→F2d.** Entrada de F2b añadida a docs (faltaba). - **🔥 CI overhaul** (la queja de fondo de Edu): diagnóstico con datos (suite 198→688 tests; overage may 11,94→jun 33,08; sin cron rebelde — es volumen de CI). Arreglos en main: **(a) pre-push gate** (claude-method `pre-push.hook` + `scripts/ci/pre_push_tests.sh`) corre el suite en Docker antes de subir → mata el bucle rojo→fix→re-push (verde a la 1ª). **(b) #130** CI solo en PR + Docker en paralelo + venv cacheado + sin coverage. **(c) #132** Backend shardeado en 2 (pytest-split) → run de ~7 a ~4 min. **(d)** Vigía cazó mi bug del `runs-on` en el dogfood. Memoria `feedback_pre_push_test_gate`. - **Pendiente medible**: el overage de Actions de **julio** (tras reset 1-jul + estas medidas) debería caer cerca de 0.

Edu: publicada la traducción de red/terminal/cartelería + traducidas las pantallas de monitorización + nueva regla de "gasto con permiso"

jornada corta para seguir con la **versión española**. Publicamos del todo la tanda anterior (las pantallas de red, terminal y cartelería ya están en producción en español). Y tradujimos un bloque grande nuevo: todas las **pantallas de monitorización** (el Observatorio de red, los SAIs/baterías y el WiFi) — unas 900 frases. Lo hicimos con 50 asistentes trabajando a la vez, fichero a fichero. Quedó pendiente solo el repaso de tildes de esas frases (los asistentes tradujeron bien pero se comieron algunos acentos en los textos largos), que es lo primero del próximo día. Además, como el plan de la IA pasó de la tarifa más alta a una más contenida, **acordamos una norma**: estos "trabajos en equipo" de muchos asistentes (que gastan bastante) se lanzan solo con el visto bueno de Edu y un cálculo previo de cuánto cuestan. Todo guardado en GitHub. **Detalle técnico** (autor: Edu con Claude · Pro: PR #128 mergeado + rama `edu/i18n-f2c-js` `48e372e5` · workspace docs · ventana Fable): - **💳 Norma nueva (Plan Max 5x)**: workflows multi-agente solo con consenso + estimación de crédito. Memoria `feedback_workflows_consenso_credito_5x`. - **i18n F2b ✅ MERGEADA (PR #128, `4769c27c`)**: network+terminal+signage, 1723 `t()`, 907 msgids ES. El Security Scan falló por un 403 transitorio del CDN de gitleaks (no código); `gh run rerun --failed` → 4/4 verde → merge. - **i18n F2c 🟡 barrido + salvaguarda (rama pusheada)**: Monitoring UI (observatory+wireless+ups), 50 ficheros → 44 tocados, **1202 `t()`, 919 msgids ES**, 0 fallos de sintaxis, `.po` UTF-8 OK. Coste: 50 agentes, 3.05M tokens. Pendiente: pasada de acentos (238+ msgstr sin tilde en prosa larga) → fusionar → `compilemessages` → PR. Salvaguarda con `BIB_SKIP=1`.

Edu: más español (red/terminal/cartelería) + auditoría documentada al cierre + idea del "Atlas" + todo a salvo

seguimos con la **versión española del programa**. Tradujimos los textos de dos zonas grandes: primero el editor de racks y el de mapas (ya en producción), y luego las pantallas de red, terminal y cartelería (listas, falta solo el último clic para publicarlas). Lo hicimos con varios asistentes trabajando a la vez, fichero a fichero, más una pasada final que repasa todas las tildes. Aprovechamos también para **rematar la documentación de la auditoría de seguridad** de las últimas semanas, que se había quedado a medias (no reflejaba que ya habíamos arreglado casi todo). Y diseñamos una **idea nueva de Edu**: un "Atlas de Arquitectura" que convierte todo lo que aprendimos del código durante la auditoría en una guía técnica de primera para el futuro. A media tarde Edu avisó de un posible corte del servicio de la IA, así que **guardamos absolutamente todo en GitHub** para no arriesgar nada de lo trabajado. **Detalle técnico** (autor: Edu con Claude · Pro: PR #127 mergeado + rama `edu/i18n-f2b-js` `6b642c04`/`ba8f6205` · workspace varios pushes · ventana Fable): - **i18n F2a ✅ MERGEADA (PR #127)**: 52 ficheros JS (editor+racks+blueprints), 587 `t()`, 480 traducciones ES. Workflow multi-agente en lotes anti-throttle (el 1er intento lo tumbó el throttle de servidor, 45 agentes — lección s122/s126). `node --check` 0, `compilemessages` verde, tests 9/9. - **i18n F2b ✅ casi (rama pusheada)**: 51 ficheros JS (network+terminal+signage), 1723 `t()`, 907 traducciones ES nuevas. `compilemessages` verde. Solo falta abrir el PR. + fix del bug de cabecera de `merge_po_fragments.py`. - **📚 Auditoría Suprema documentada al cierre**: `AUDITORIA_SUPREMA.md` + `INFORME_SUPREMO.md` puestos al día (Etapa 3 completa + síntesis de las dos auditorías). Datos versionados verificados. - **🗺️ Atlas de Arquitectura Supremo**: plan `atlas-arquitectura/PLAN_ATLAS.md` (4 productos: fichas de dominio + reglas de arquitectura + catálogo de helpers + grafo). Arranca tras i18n F2. - **🛟 Salvaguarda**: ante posible corte de cuenta, todo pusheado a GitHub + STATE/NEXT/LOG con el punto de retome ("abre el PR de F2b").

Edu: cierre total de las contraseñas + la ayuda entera en inglés + arranque de CreaRack en Español

día enorme con cuatro frentes. (1) **Cerramos del todo** la mejora que saca las contraseñas de los equipos fuera del navegador — faltaba el descubrimiento de equipos y ya está. (2) **Reescribimos la ayuda del producto entera en inglés de verdad**: 82 páginas (56 puestas al día comprobando botón a botón que dicen la verdad, y 26 nuevas que faltaban, como la del portal de clientes de cartelería). De propina descubrimos que el botón de Ayuda llevaba un mes enseñando una copia vieja traducida a máquina — ya enseña la buena. (3) Montamos un mecanismo para que la ayuda **no vuelva a quedarse anticuada**: al guardar cambios que tocan lo que ve el usuario, sale un recordatorio automático de actualizar su página de ayuda. (4) Arrancamos **CreaRack en Español**: ya hay selector de idioma en Ajustes, los textos de todas las pantallas están preparados para traducirse (1.286 ya traducidos) y la ayuda completa ya existe también en español. Queda la parte más grande (los textos que pinta el JavaScript, en 3 tandas) y conectar la ayuda española. Susto final: un despliegue falló en rojo por un detalle del contenedor de producción — arreglado en 20 minutos y **producción nunca se cayó**. **Detalle técnico** (autor: Edu con Claude · Pro: PRs #122 #123 #124 #125 + pushes `aed8f33e`/`042eaaeb` · workspace: 11 pushes verdes · claude-method `5e2635a`/`8ddb89b` · Vigía en todos): - **R3 Discovery F4 (PR #122)**: `has_snmp_community` en `DeviceProfileOut`, `/discover`+`targets/bulk` resuelven por `profile_id` server-side, retirado `/profiles/{id}/credentials`, 10 tests. Raíz R3 completa; deudas → Agent 2.4.0. - **Ayuda EN (9 lotes)**: 82 págs, 0 enlaces rotos, D1 892-921; retirados `wiki-en/`+cron `Wiki-Translate`; `_apply_english` simplificado. Wiki coloquial `workspace--producto--sistema-ayuda-ingles`. - **Ayuda viva**: Regla 27 ampliada + `check_help_reminder` en pre-commit (`.claude/help-map.json`, 9 áreas) + tareas #90/#91. - **i18n** (plan `i18n-es/PLAN_I18N_ES.md`): F0 ✅ (#123, infra+selector) · F1 ✅ (#124 verde: 63 templates + `django.po` 1.286) · F3a ✅ (ayuda ES 82 págs en `wiki-es/`). Queda F2 JS (3 sub-tandas, tarea #92) + F3b + F4. Ventana Fable hasta 22-06. - **Fix Dokploy (PR #125)**: `Dockerfile.prod` con `ENV DJANGO_SETTINGS_MODULE` rompía el `compilemessages` del deploy de #123; validado reproduciendo el entorno. Orden: #125 → Dokploy verde → #124.

Edu: sacamos las contraseñas de los equipos fuera del navegador (editor, cartelería, descubrimiento)

sesión sobre el **producto** (CreaRack Pro), paralela a la del panel interno. Hemos sacado las contraseñas de los equipos **fuera del navegador** en tres zonas. Antes, al trabajar con un equipo (su terminal, su copia de seguridad o leer su configuración de red) el navegador recibía la contraseña y se la pasaba al "Agente" (el programita del PC del cliente). Ahora el navegador solo dice "quiero este equipo" y el Agente pide la contraseña directamente al servidor por un canal seguro — ya no pasa por el navegador, que es el sitio más expuesto. Hecho en el **editor** (terminal y copias SSH), la **cartelería digital** (reproductores SpinetiX) y el **descubrimiento de equipos** (re-escanear uno ya guardado). Edu recompiló el Agente tres veces y comprobó que todo sigue funcionando; la cartelería la prueba el **lunes** (necesita un reproductor físico de la oficina, tarea apuntada). De paso cazamos y arreglamos dos fallos viejos: la copia de seguridad por el Agente llevaba días rota y la compilación del Agente fallaba sin internet. Queda el descubrimiento para otra sesión, por ser la pieza más delicada. Norma apuntada: la **consola del navegador siempre limpia de errores** (imagen de producto). **Detalle técnico** (autor: Edu con Claude · 4 PRs #119·#120·#121 + 2 push directos, todos verdes, Vigía vigiló los 3 PRs · Agent 2.1.3→2.3.0, 3 `.exe` que Edu compiló · Docker-test antes de pushear · freeze de Actions respetado): - **Patrón R3** (del terminal Raíz 3): endpoints Agent-facing en `terminal/api/agent_credentials.py` (auth = JWT del Agente, scoped por org): `device-credentials`/`signage-credential`/`profile-credentials`. Helper `core/device_creds.py` (`_get_agent_json` + 3 fetch). 16 tests. - **Editor SSH ✅** (PR #119 Fase 2+3 frontend aditivo + Agent v2.2.0; PR #120 Fase 4: frontend solo `device_id`, retirado `GET /device/{id}/credentials`+schema+tests, `backup/trigger` 422→200 `use_local_agent`). E2E Edu OK (terminal/VLAN/backup, consolas limpias). - **Signage ✅** (PR #121 Fase 2+3 `SignageCredentials`+5 managers→`credential_id`, Agent v2.3.0; push `24b0a948` Fase 4 deja de descifrar/cachear). E2E SpinetiX → **lunes 15-06, tarea #89**. - **Discovery 2+3** (PR #121 `deep_discovery.js`/`discovery.js`→`profile_id`, Agent `snmp-discover`/`probe-oids`). Fase 4 pendiente (tanda dedicada, `DeviceProfileOut` compartido, no recompila). El input efímero del wizard NO es R3. - **2 bugs preexistentes**: backup vía WS sin auth local (Agent 2.1.2, push `d40c64fd`); build del Agente (licencias offline + empaquetar `device_creds.py` en `build_agent.bat`). - Memorias: `project_adr_r3_creds_en_cliente` al día + nueva `feedback_clean_console_product_image`.

Edu: cerramos los "arreglos baratos" del panel interno (errores, límites, blindaje de la IA)

sesión sobre el **panel interno del equipo** (no el producto), paralela a la de CreaRack Pro. Rematamos la lista de "arreglos baratos" que el repaso de seguridad había dejado apuntada. Tres bloques: (1) que cuando algo falla por dentro, el sistema **ya no le enseñe sus tripas** a quien lo usa — por fuera un mensaje genérico, y el detalle queda guardado solo en el registro interno; (2) **límites sensatos** en lo que se puede escribir en los formularios (tareas, notas, noticias, avisos) para que un campo gigante o de tipo raro no rompa nada; y (3) **blindar el asistente de inteligencia artificial** para que nadie pueda "engañarlo" colándole órdenes escondidas dentro de una pregunta o dentro del texto de una página de la wiki. Todo verde y en producción. Con esto, el repaso del panel interno queda **cerrado salvo las tareas grandes** que merecen su propia sesión (montar pruebas automáticas, partir dos ficheros enormes). Lo siguiente: montar las **pruebas automáticas**. **Detalle técnico** (autor: Edu con Claude · sesión paralela a la de CreaRack-Pro, cierre consensuado entre las dos · 2 PRs #110·#111, CI verde, Vigía vigiló ambos · solo `functions/**` TS, sin migración ni cambio de contrato): - Al aterrizar cada hallazgo en su sitio real se vio que la cola de la sesión anterior (#107/#108/#109) ya había cerrado varios → la tanda quedó afinada. - **PR #110 · errores + límites**: helper `redactError()` en el motor de la Biblioteca (8 sitios; loguea el detalle por dentro, devuelve solo el tipo de error) + el dispatcher MCP deja de reenviar el mensaje de excepción + el registro de edición de wiki ahora guarda **quién** la editó de verdad (antes ponía "staff" genérico) + Zoho deja de reflejar su respuesta cruda en los errores de calendario/correo. Y un validador compartido (`_lib/validate.ts`) + topes de tamaño (lista de dependencias, sala de videollamada) + validación simétrica al crear y al editar en tareas/notas/noticias/avisos. - **PR #111 · blindaje de la IA**: el detector de secretos ahora también tapa las claves de Anthropic y de Zoho; el detector de "órdenes escondidas" entiende español y normaliza trucos de caracteres raros; la pregunta del usuario y el historial pasan por ese filtro antes de llegar a la IA (una pregunta normal no se toca); y el texto de las páginas wiki se envuelve en una "caja" marcada como "esto es dato, no órdenes" antes de mandárselo a la IA que revisa/compara/sincroniza páginas. - **Diferido**: una pieza del "blindaje" vive en otro repositorio (el indexador) que ahora mismo está apagado por el ahorro de GitHub; se hará al reactivarlo. - **+ Montamos las PRUEBAS AUTOMÁTICAS** (lo que faltaba): el panel interno no tenía ninguna. Ahora hay **40 pruebas** que se ejecutan solas en cada cambio y cantan si algo se rompe — comprueban que las protecciones que pusimos (limpiar errores, límites de los formularios, blindaje de la IA, escape anti-XSS) siguen funcionando, y además unas cuantas que arrancan una base de datos de prueba de verdad y verifican que crear/editar noticias valida bien. Hubo un enredo técnico (un envío se quedó "vacío" por un despiste con los nombres de las ramas), detectado y corregido en el momento; lo dejé apuntado para no repetirlo. - **Estado**: el repaso de seguridad del panel interno queda cerrado salvo lo grande (partir dos ficheros enormes, rediseño del sistema de llaves de acceso, más pruebas). **Pendiente de Edu** (de la sesión anterior): Dani y Txell tienen que volver a conectar Zoho una vez cada uno. El cierre del día ("apaga") lo coordina la otra sesión.

Edu: rematamos los pendientes del producto + "sacar las contraseñas del navegador" (arranque)

sesión paralela a la del panel interno, pero esta sobre el **producto** (CreaRack Pro). Rematamos la lista de "cosas menores" que el repaso de seguridad había dejado apuntada: pusimos **frenos** para que nadie pueda "machacar" las funciones que cuestan dinero (las de inteligencia artificial y la compilación de ficheros de fabricantes) ni el **portal de cartelería del cliente** (el enlace que le pasas a un cliente para que gestione su contenido); **ordenamos** cuatro ficheros de programa que se habían hecho gigantes, partiéndolos en trozos sin cambiar nada de cómo funcionan; **arreglamos** un fallo molesto del editor de planos (al deshacer o rehacer un dibujo, no volvía a aparecer); y reforzamos el portal de cartelería para que se pueda **revocar el enlace de un cliente con un botón** (si se filtra, deja de funcionar al instante). Y arrancamos la última pieza grande: **sacar las contraseñas del navegador** — a partir de ahora el programita que el cliente instala (el "Agente") podrá pedir las contraseñas él mismo de forma segura, en vez de que viajen por el navegador. Eso se termina en otra sesión, cuando Edu **recompile el Agente** (le avisaremos). Todo verde y en producción. **Pendiente de Edu**: probar a mano el deshacer/rehacer del editor de planos (esa parte no la cubren las pruebas automáticas). **Detalle técnico** (autor: Edu con Claude · sesión paralela a la del Workspace; apaga coordinado · 4 PRs #115-#118, CI verde, Vigía vigiló cada uno): - **PR #115 · rate-limit hygiene + Bloque C descongelado**: primitivo `core/ratelimit.py` (contador atómico, fail-open; el guard de coste de IA delega). Topes: MIB upload 20/h + MIB-assistant 30/h (admin), workspace perf-review/finops con IA 20/h, portal signage PIN 10/min + escrituras 30/min + descarga dispositivo 240/min (todo por token). Subido junto al Bloque C de s130 (audit-log racks + brotli) que estaba sin pushear. 13 tests. - **PR #116 · modularización (Regla 5)**: 4 módulos >500 LOC partidos sin cambio de comportamiento (rutas idénticas vs OpenAPI): `mib_manager` 560→416, `profiles` 592→270, `sentinel` 612→254, `library` 774→426. Footgun: un NUL byte colado al copiar un comentario rompía un import → cazado antes de CI. - **PR #117 · cola hygiene final**: fix undo/redo del map editor (`createDrawingNode` inexistente + `drawing_rack` crasheaba → métodos correctos en `historyContext`) + endurecimiento del portal cliente signage (`require_perm` que faltaba + endpoint `rotate-token` + botón Rotate + PIN con comparación en tiempo constante; PIN no hasheado a propósito). 8 tests. - **PR #118 · R3 (creds-en-cliente) Fase 1**: nuevo endpoint `GET /api/agent/device-credentials/{id}` (auth = JWT del Agent, scoped por org) para que el Agente obtenga las creds server-side. Aditivo. 4 tests. **Faltan Fase 2 (frontend) + 3 (`.exe`, recompila Edu) + 4 (cleanup)**, a cerrar juntas cuando Edu compile, con su prueba E2E. - **+ CLAUDE.md §4.2** (jerarquía de 6 pasos, cherry-pick Ponytail) directo a main. - **Estado**: Auditoría Suprema CreaRack-Pro con la sustancia de seguridad + la cola hygiene cerradas. Diferidas con tope externo: R3 Fases 2-4 (.exe Edu), T2 (Huey, julio), RLS MetricSample (ventana PROD), cola BAJA opcional.

Edu: arreglamos a fondo el panel interno del equipo (todo lo grave + lo importante)

hoy le tocó el turno de **arreglos al panel interno del equipo** (donde vivís Edu, Dani y tú: tareas, noticias, la wiki, el buscador con IA, las conexiones con Zoho y con el programa de facturas). La auditoría de ayer dejó una lista; hoy **cerramos las 8 cosas más importantes**, todas funcionando ya en producción: tapamos un par de "puertas abiertas sin contraseña" (una dejaba descargar una copia entera de la base de datos, otra dejaba ver informes con números), hicimos que **la cerradura principal compruebe bien la llave** (antes se creía cualquiera), **ciframos una contraseña de Zoho** que estaba guardada a la vista, y pusimos límites para que nadie pueda disparar costes de la IA en bucle. Después seguimos con la **lista de cosas menores** y arreglamos las de más valor: que un fichero subido no pueda hacerse pasar por una página web maliciosa, que solo el dueño de una nota pueda verla (antes un nombre parecido colaba), y que el autor de un mensaje del chat sea de verdad quien lo escribe (antes se podía falsificar). **Detalle bonito**: la parte de configuración de Cloudflare, que a Edu se le hace cuesta arriba, **la hice yo** con un permiso temporal que él creó en unos clics y borró al acabar. Lo que queda son piezas menores (no urgentes) y un par de refactors grandes para otra sesión. **Edu tiene que hacer una cosa manual**: Dani y tú **volver a conectar Zoho una vez** (para que vuestra contraseña vieja se guarde ya cifrada; la de Edu ya está). **Detalle técnico** (autor: Edu con Claude · sesión paralela a la de CreaRack-Pro; apaga coordinado entre ambas): - **Las 8 raíces transversales rectificadas y en PROD · 5 PRs #102-#106**: R1 verificación real del JWT de CF Access (`functions/_lib/cf-access.ts`, JWKS+RS256+aud+exp, `CF_ACCESS_ENFORCE=1`, 3 AUDs por las 6 Access apps del dominio) · R2 `PUBLIC_PATHS` purgado (fuera el dump de D1 + informes públicos) · R3 actor del log no falsificable + rol readonly `MCP_READONLY_TOKENS` (token de backup Hetzner) · R4 SQLi `bib_cycle_report` · R5 XSS callback Zoho + chat Oráculo (`src/lib/markdown.ts`) · R6 SSRF `dc`/`holdedId`/errores + **cifrado AES-GCM del refresh_token Zoho** (`ZOHO_TOKEN_KEY`) + HMAC OAuth fail-closed · R7 cap de longitud + rate-limit backstop IA · R8 200-con-fallo en `bib_ingest.py`. - **Cola MEDIA/BAJA, tramo de más impacto · 3 PRs #107-#109**: error de GitHub redactado + holded 200-con-fallo + author de news no suplantable (#107) · `nosniff` en blobs R2 + acceso a notebook por match exacto (#108) · fugas de error D1/GitHub redactadas + autor de chat = usuario real de CF Access (#109). - **Método**: config de Cloudflare aplicada por Claude con un API token Pages:Edit temporal (el wrangler OAuth da `auth 10000` en Pages); cada secreto/cripto validado ejecutando pruebas offline antes de PROD; inerte-por-flag en todo lo arriesgado → 0 riesgo de lockout; auto-merge al verde (memorias nuevas `feedback_auto_merge_green_no_ask`, `reference_cf_pages_config_via_temp_token`). - **Pendiente manual de Edu**: Dani y Txell re-autorizan Zoho 1× (re-cifra su refresh_token legado; el de Edu ya hecho). **Backlog**: 🟢 doable (más fugas de error, caps de validación, anti-prompt-injection) · 🔴 dedicada (modularizar `biblioteca.ts`/`wiki.ts`, tests, rediseño token OAuth, N+1, IDOR hub). Detalle en `AUDITORIA_SUPREMA.md §WORKSPACE`.

Edu: cerramos casi toda la auditoría del producto + apagamos una alarma de costes de GitHub + auditamos el panel interno

día doble y largo, con dos Claude trabajando en paralelo (uno en el programa principal, otro en el panel interno) para no estorbarse. En el **programa principal (CreaRack Pro)** terminamos de **blindar toda la web** contra el fallo más repetido de la auditoría —que la pantalla "pinte" sin limpiar nombres de aparatos o textos del usuario, por donde alguien podría colar código— aplicando una única forma correcta de limpieza en 41 ficheros; y de paso cerramos varias deudas (que dos aparatos no se solapen en el armario, dejar registro de quién borra cosas, y actualizar librerías con fallos conocidos hasta dejar **cero avisos de seguridad**). A media tarde saltó una **alarma de GitHub**: se había agotado el cupo mensual de "minutos de automatización" (eso cuesta dinero). Lo investigué a fondo: **no era ningún robot descontrolado** —los cambios reales eran normales—, sino que **cada vez que subíamos algo se disparaban demasiados procesos a la vez**. Lo arreglé apagando los procesos que no son imprescindibles y dejando que las pruebas corran **una sola vez** en lugar de dos; con eso los **20 $** que añadió Edu **dan de sobra hasta que el cupo se renueva el día 1**. En el **panel interno** se completó la primera pasada de auditoría (la lista de cosas a mejorar, sin tocar nada todavía). **Lo que queda** de toda la auditoría son piezas grandes que se harán con calma y con Edu presente (recompilar el programa que va en el ordenador del cliente, una ventana de mantenimiento para un cambio delicado en la base de datos, y un refactor para julio). **Detalle técnico** (autor: Edu con Claude · 2 sesiones paralelas, cierre consolidado por la de CreaRack-Pro): - **CreaRack-Pro · Auditoría Suprema Etapa 3 (grueso cerrado)**: PR #112 frontend FE2-FE7 (helpers de escape por contexto en `base.js` + barrido XSS/CSV de 41 ficheros `static/js`, vía workflow de 8 agentes) · #113 Bloque C racks (validación U placement + cap decompression bomb, 21 tests Docker) · #114 deps con CVE (Django 6.0.6/aiohttp 3.14/PyJWT 2.13) · #115 audit-log de borrados de racks + brotli 1.2.0 → **pip-audit limpio**, verificado en PROD por SSH · #110 fleco E DEV_KEY. Diferido (decidido): R3 creds-en-cliente (.exe), T2→Huey (julio), RLS MetricSample (ventana PROD), cola hygiene menor. - **🔥 Crisis Actions**: cupo org al 100%; causa = multiplicador per-push (no bot). Mitigado reversible: 13 workflows `gh workflow disable` + CI de CreaRack-Pro solo en `pull_request` (commit `bc49603b`) + re-activados crons diarios esenciales. Grafo refrescable on-demand con `bib_full_reindex` (0 Actions). Memoria `project_actions_budget_crisis_s130` con el plan de re-activación. - **workspace · Auditoría Suprema 2ª fase Etapa 1 (auditar) COMPLETA**: 6 sub-áreas, 158 hallazgos (15 graves). Etapa 3 (arreglar) pendiente, prioridad: dump D1 público + cerradura CF Access + tokens MCP sin rol. Detalle en LOG.md s130 + `AUDITORIA_SUPREMA.md` §WORKSPACE. - _Nota: WORKLOG saltó de s126 a s130 (s127-s129 quedaron en LOG.md/STATE.md; cierres "sin push" por la disciplina de Actions). Esta entrada consolida el viernes 12-jun de ambas sesiones._

Edu: revisamos 5 trozos más de la web de una tacada + blindamos la herramienta de revisión

día de **pura revisión de la web** (no tocamos nada del producto, solo buscar fallos y apuntarlos). Veníamos de partir la web en 7 trozos; hoy revisamos **5 de un tirón**: el editor de armarios, los cimientos (login y servicios comunes), el editor de planos, el buscador de aparatos en la red y la cartelería digital. El resumen para no marear: en varias partes la web **muestra nombres que vienen de los aparatos o que escribe el usuario sin "limpiarlos" antes**, lo que abre la puerta a que alguien cuele código malicioso (XSS); y en algunos sitios **se quedan contraseñas a la vista en el navegador**. La parte de planos salió **limpia** (dibuja sobre una especie de lienzo que no tiene ese problema). Lo más llamativo es la cartelería: ahí se juntan varios de esos fallos y, encadenados, alguien podría robar las contraseñas de las pantallas. **No hemos arreglado nada todavía** —eso toca después, ordenado por áreas, como decidiste—, solo queda todo bien documentado. Además, **mejoramos nuestra propia herramienta de revisión**: el servidor de la IA a veces nos "cortaba" a media revisión y dábamos por buenos descartes que en realidad no se habían mirado; ahora **reintenta sola y, si algo no llega a revisarse, lo marca como "pendiente" en vez de descartarlo**. Con esto, **solo queda 1 trozo** (el de monitorización, el más grande) para terminar de revisar toda la web — y con él se cierra toda la primera etapa de la auditoría. **Detalle técnico** (audit-only · 5 workflows pesados, uno a uno · 159 hallazgos acumulados en el frontend): - **FE2 Editor de racks** (~7,5k, 23 hallazgos · 7 graves): contraseñas SSH que el navegador recibe en claro y manda a un socket local + nombres de aparatos (datos SNMP) pintados sin limpiar. `frontend-fe2.raw.json`. - **FE7 Cimientos** (~12k, 22 · 2 graves): la **"regla de oro"** — sí existe un limpiador central (`window.escapeHtml`) pero no protege bien en todos los contextos y muchas pantallas ni lo usan; + un par de XSS (etiquetas QR, gráficos) y la llamada que **desinstala el Agente sin pedir confirmación**. `frontend-fe7.raw.json`. - **FE3 Editor de planos** (~8,6k, 19 · 0 graves): **limpio** de XSS (dibuja en lienzo); 2 bugs de código y un buscador de rutas lento. `frontend-fe3.raw.json`. - **FE4 Buscador de red** (~6,7k, 33 · 8 graves): muchos XSS al pintar los aparatos descubiertos + **contraseñas SSH guardadas en claro en el navegador**. `frontend-fe4.raw.json`. - **FE6 Cartelería (Signage)** (~8,7k, **45 · 19 graves**, el más cargado): XSS en casi todas las pantallas + **contraseñas de las pantallas guardadas en claro** + el "token" de los portales de cliente a la vista → **encadenados permiten robar esas contraseñas**. `frontend-fe6.raw.json`. - **🛡️ Herramienta blindada**: el "throttle" del servidor de la IA (no es nuestro límite, es del proveedor) tumbó 14 verificaciones en el primer trozo y nos hizo descartar 2 hallazgos graves de verdad (los rescatamos a mano). Arreglado: ahora reintenta en lotes pequeños y marca "pendiente" lo que no llega → los 4 trozos siguientes salieron sin perder nada. **Lección**: validar la herramienta **ejecutándola**, no solo comprobando que "compila". - **Raíz del arreglo (siguiente fase)**: usar el limpiador en todas partes + no dejar contraseñas en el navegador. **Queda FE5** (monitorización, ~16k, en 2 tandas). Motores en `.claude/workflows/auditoria-suprema-frontend-fe{2,3,4,6,7}.js`.

Edu: empezamos a ponerle "llave" al Agente del Terminal + revisamos la configuración y la web (con dos Claude a la vez)

jornada larga y de las que cunden, trabajando con **dos ayudantes a la vez** — uno arreglando y otro revisando, cada uno en su sitio para no estorbarse. Primero, un detalle: la **barra que muestra cuánto gasto de Claude llevamos** no salía bien; la arreglamos para que enseñe el gasto del momento. Lo gordo del día fue empezar a tapar el **último agujero serio del Terminal**: el programita que el cliente tiene en su PC (el "Agente") **no pedía ninguna contraseña**, así que, en teoría, una web maliciosa que el cliente visitara por casualidad podía darle órdenes. Decidimos cómo cerrarlo —con una "llave" que solo conoce nuestra web de verdad— y dejamos esa decisión por escrito. Hicimos los **dos primeros pasos, ya publicados y probados**: preparar el servidor para guardar y entregar esa llave, y que la web se la mande al Agente. **Importante: todavía no cambia nada para los clientes** (la llave va "en pruebas" hasta el último paso); el candado de verdad será el **tercer paso**, que obliga a sacar una versión nueva del Agente y lo haremos otro día con calma. Edu lo probó en su navegador y fue todo instantáneo y sin fallos. Mientras tanto, el segundo ayudante **revisó la configuración y la parte de inteligencia artificial** (salió bastante bien; lo más reseñable es que un panel interno, al pedir análisis con IA, manda datos de varios clientes a Google — no es público, pero hay que afinarlo) y **empezó a revisar la web entera**, que es gigantesca: la partió en **7 trozos** y revisó el primero. Curioso y bueno: esa revisión **encontró un fallito en el código que escribimos hoy mismo** — buena señal de que el sistema de revisión funciona. **Decisión de Edu, muy sensata**: no ir arreglando cosas sueltas a lo loco; **apuntarlo todo y arreglarlo por orden, área por área**, para no agobiarse. No queda nada urgente. **Detalle técnico** (sesión doble terminal · CreaRack-Pro PRs #100/#101 mergeados + claude-method · CI verde, validado por Vigía): - **Statusline** (`claude-method` `fca5be2`, propagada a los 3 perfiles): la barra de uso pinta el `five_hour.used_percentage` (uso actual) en vez de `max(5h,7d)`. Solo aparece tras la 1ª respuesta de la API (es así en Claude Code). - **Raíz 3 del Terminal · ADR `decision--20260610--terminal-auth-local-cross-origin`** (wiki, `page_id 847`). Esquema decidido por Edu: **token opaco aleatorio mediado por el SaaS** (el Agente lo genera y deposita cifrado; el SaaS lo custodia y solo lo da a la sesión del tenant dueño). **Fase 1 (PR #100, PROD)**: `AgentInstance.local_token_enc` (cifrado, migración `terminal/0003`) + endpoints `register-local-token` / `local-token`. 7 tests. **Fase 2 (PR #101, PROD, smoke OK de Edu)**: `agent_auth.js` intercepta `window.fetch` y añade el `Bearer` a `localhost:5050` sin tocar ~35 sitios; token **opcional** (inocuo para Agentes viejos); iframe SSH por `postMessage`; descargas a fetch+blob. **Fase 3 pendiente** (el `.exe` exige el token + cierra CORS). - **Auditoría `config/IA`** (~2.8k LOC): 30 confirmados (1A/8M/21B), audit-only. ALTA = fuga cross-tenant a LLM (`perf-review`/`finops` con `ai=true`). `config-ia.{md,json}`. - **Auditoría `frontend`** (~69k LOC → 7 sub-áreas, §6b): **FE1 hecho**, 17 confirmados (3A/3M/11B), audit-only. A2 = bug de la Fase 2 de hoy (`isAgentUrl` por substring). `frontend-fe1.{md,json}`. - **Método (Edu)**: arreglos NO puntuales → Etapa 3 por dominio (terminal → config/IA → frontend), sesiones dedicadas. Memorias nuevas: `feedback_control_doc_generation_supercontext`, `footguns_wiki_create_page_sources_objects`. - **Queda**: frontend FE2-FE7 (6 sub-áreas, 1/sesión) + Etapa 3 de fixes.

Edu: blindamos el Agente del Terminal por dentro (+ arreglo de la consola y temas nuevos)

continuación del Terminal. Si en la sesión anterior arreglamos la parte que vive en **nuestro servidor**, hoy le hemos dado a la parte que vive **dentro del programita que el cliente instala en su PC** (el "Agente"). Lo más gordo y delicado —ponerle contraseña a la "puertecita" interna del Agente, que cambia cómo se comunica con la web— lo dejamos para otra sesión, con calma. Hoy, todo lo "de dentro" que **no cambia nada de cómo se usa**: (1) cuando el Agente se conecta por SSH a un equipo de red, ahora **se aprende la identidad de ese equipo y, si un día cambia, se niega a conectar** (así pillaría a un impostor metido en medio de la red); (2) las **contraseñas SNMP** que el Agente guarda en su disco ahora van **cifradas** (antes estaban en texto plano); (3) el receptor de "avisos" del Agente ahora **solo atiende a los equipos que vigila** y pone un límite, para que nadie pueda saturarlo; (4) actualizamos **3 librerías** con fallos de seguridad conocidos (un chequeo automático que llevaba en rojo desde junio **vuelve a verde**); y (5) **tiramos a la basura 12 ficheros de código viejo** que ya no se usaban pero seguían pesando dentro del programa. Edu recompiló el Agente y comprobó que todo va bien. De paso, dos detallitos visuales que notó Edu en la consola: se **veía un poco baja y cortada por abajo** al abrirla (arreglado, ahora se ajusta sola) y un tema de colores ("Gruvbox") dejaba una **fea película gris** (arreglado, y ya que estábamos **añadimos 4 temas nuevos**). En total, tres versiones nuevas del Agente publicadas. **El Terminal queda casi terminado; solo falta una cosa (la contraseña de la puertecita interna), para otro día.** **Detalle técnico** (CreaRack-Pro · PR #98 + push directo `db7dbaf6` + PR #99 · CI verde 4/4 · sin migraciones): - **PR #98 · Tanda B1 hardening del Agent (2.0.22)**: R4 SSH host-key TOFU (`network/host_keys.py`, anti-MITM) · R5 creds SNMP cifradas DPAPI en `metrics.db` (`core/crypto.py`) · R6 `trap_receiver` allowlist+caps · 3 CVEs del lockfile (asyncssh 2.23 #81 + aiohttp 3.14 + PyJWT 2.13 → cron `agent-pip-audit` verde) · retirados 12 módulos dead code + `build_agent.bat`/README · 9 tests `tests/agent/`. Gate = smoke manual de Edu (el Agent no está en CI, es Windows-only). - **Fix consola (2.0.23)**: `ResizeObserver` sobre `#terminal-container` en `terminal.html` (xterm se recortaba al mostrar pestaña oculta). - **PR #99 · Temas (2.0.24)**: Gruvbox sin velo (`#282828`→`#000000`) + Dracula/Nord/Solarized Dark/One Dark (`THEMES` + `TerminalToolbar.js`). - **Releases** `agent-v2.0.22/23/24` publicados; política nueva: solo la versión en curso en GitHub Releases (borradas 6 antiguas, ~130 MB liberados; tags conservados). - **Queda del Terminal**: solo la **Raíz 3** (auth de la API HTTP local del Agent + CORS) → sesión propia, diseño primero (cambia el contrato con ~40 ficheros del frontend).

Edu: arreglamos el módulo Terminal por el lado del servidor (lo del Agente queda para otra sesión)

seguimos con la revisión de seguridad del **Terminal**, que es el módulo más grande de todo el producto. La semana pasada lo "auditamos" entero (encontramos los problemas); hoy tocaba **arreglar**. Como es enorme, lo partimos: hoy todo lo que vive en **nuestro servidor**, y dejamos para otra sesión lo que vive dentro del **programita que el cliente instala en su PC** (el "Agente"), porque eso obliga a sacar una versión nueva de ese programa y conviene hacerlo con calma. Lo de hoy, en tres tandas: (1) **quitamos un canal viejo y peligroso**: en el servidor quedaba una vía de conexión por SSH que **no pedía identificarse** —cualquiera que diera con su dirección podía pedirle al servidor que se conectara a una máquina con unas credenciales elegidas por él—; comprobamos que ya **no la usaba nada** (el terminal de verdad va por el Agente local), así que la eliminamos de raíz. (2) **Permisos y separación entre clientes**: ahora los datos de los dispositivos y el listado de Agentes respetan el rol del usuario, y se cerró un caso raro en el que alguien sin empresa asignada podía ver la lista de equipos de **todos los clientes** a la vez. (3) **Limpieza**: un endpoint que recibía avisos del Agente fallaba siempre (devolvía error); vimos que el Agente ni lo usa y lo dejamos honesto, hicimos más robusto el cambio de Agente "principal" de una flota, endurecimos un token y borramos código muerto. **Todo en dos entregas, las dos en verde y ya en producción, sin tocar la base de datos.** Con esto, **el Terminal queda arreglado por completo en su parte de servidor**; lo único que queda del Terminal es la parte del Agente (el .exe), que va aparte. **Detalle técnico** (CreaRack-Pro, 2 PRs, CI verde 4/4, sin migraciones): - **PR #96** (raíces backend 1+2, mergeado `3235d09b`): **R1** retirado el `SSHConsumer` del SaaS (`ws/terminal/` + clase + tests + import `asyncssh`) = open SSH proxy sin auth con `known_hosts=None` (SSRF/MITM/DoS); verificado sin caller (terminal real = iframe→Agent `localhost:5050`). **R2** Broken Access Control: `require_perm` en `terminal/api/network.py` y `fleet.py`, fail-closed `org=None` en `services.py`/`views.py`, gate hub, `diag_oids` por tenant (extraído a `diagnostics.py`). 18 tests. - **PR #97** (Fase A, mergeado `e038a46c`): fix honesto de `/api/agent/alert` y su gemelo WS (ya no fabrican un `MonitoringAlert` roto → 500; el Agent no usa ese canal), `promote_agent` atómico, `get_agent_from_request` rechaza refresh tokens, `set_fleet_config` guard de body, retirado `terminal/api/scripts.py` (dead code). 6 tests. - **Diferido (otra sesión)**: Fase B = las 4 raíces del Agent (`.exe`) con rebuild+release (raíz 3 API HTTP local sin auth = 12 ALTA, raíz 4 SSH MITM, raíz 5 creds en claro, raíz 6 trap UDP) + CVE asyncssh (task #81) + dead code del agent. Hardening backend: constraint único de Primary + carrera gemela (necesitan migración). Detalle en `LOG.md`/`STATE.md` s123.

Edu: un plan de negocio a 6 meses + blindamos el módulo de cartelería digital

día de dos partes. Por la mañana le pedí a Claude que mirara CreaRack **con ojos de negocio**, no de código: cómo encaja frente a la competencia, a quién deberíamos vender, y qué hacer mes a mes hasta diciembre para pasar de "tenemos un producto buenísimo pero sin escaparate" a "cualquiera puede entrar, probarlo y pagar sin hablar con nosotros". Salió un plan que me ha encantado, en dos documentos: uno de estrategia (el mercado, los competidores, nuestro hueco — las PYMEs y las empresas que montan salas de servidores, no los gigantes) y otro operativo con las tareas de cada mes y un reparto orientativo entre Dani, Txell y yo. Lo dejé también como noticia y página en nuestro panel para poder verlo en la próxima reunión. Por la tarde, con el crédito que quedaba, **revisamos a fondo la seguridad del módulo de cartelería digital** (las pantallas que gestionan los clientes). Encontramos un fallo serio: **ese módulo no miraba los permisos** — un usuario de "solo mirar" podía en realidad subir y borrar contenido, crear enlaces públicos a las pantallas y lanzar despliegues. Arreglado, junto con un puñado de agujeros más (que no se pueda colar código malicioso en las pantallas, que una contraseña de un dispositivo no se filtre al navegador, y un guardia para que el servidor no pueda ser engañado para conectarse "hacia dentro"). Todo en una entrega, todo verde, y ya en producción. Una cosa buena que descubrimos de paso: una pega que teníamos apuntada (que algunas marcas de pantallas "fingían" funcionar) **ya estaba resuelta**, así que es una tarea menos para julio. Para que conste: la revisión de seguridad de todo el producto **aún no está terminada** — quedan tres módulos grandes para otras sesiones.

Edu: rematamos la última idea "robada" a Cairn (Claude ahora aprende del historial para no olvidar piezas acopladas)

sesión corta y enfocada. De las tres ideas que le copiamos al proyecto externo "Cairn", quedaba una por rematar y hoy se cerró. La cosa es así: tenemos una herramienta interna que usamos los desarrolladores para preguntar *"si toco este archivo, ¿qué más se ve afectado?"*. Hasta hoy solo miraba las conexiones declaradas en el código. Ahora **también aprende del historial de git**: qué archivos han cambiado siempre juntos en la práctica, aunque no haya una conexión formal entre ellos. Lo más útil es que **descubre el acoplamiento entre la "tripa" (backend) y las pantallas (frontend)**, que es justo lo que antes no se veía y donde más se mete uno la pata al olvidar tocar una pieza. Está todo en producción, rellenado con todo el historial del proyecto, y —importante— lo **probé de verdad** antes de darlo por bueno (no solo "compila"): al probarlo encontré un fallo que dejaba la herramienta a medias para los archivos de pantalla y lo arreglé en el acto. Sin ningún efecto para el cliente: es una mejora interna que nos ayuda a *nosotros* a trabajar mejor. Y verifiqué que **esto no se reparte al resto del equipo** (al "manual" compartido de Claude) porque es una pieza de la Biblioteca, no del manual; la única idea de Cairn que sí era de manual ya se repartió la sesión pasada. **Con esto Cairn queda cerrado del todo.**

Edu: cerramos la auditoría de seguridad del módulo de red + "robamos" 2 ideas de un proyecto externo + mantenimiento de los automatismos

sesión larga y muy redonda. Tres cosas. (1) **Terminamos la auditoría de seguridad del módulo de red** con su última parte: las **conexiones de cableado** y el **informe de cableado**. Había dos problemas serios: un usuario de **solo lectura** podía modificar el cableado y descargarse el mapa completo de la red de un cliente (con direcciones IP y notas dentro), y el informe en HTML tenía un **agujero de seguridad** por el que, si alguien ponía a un armario un nombre con código malicioso escondido, ese código podía ejecutarse en el navegador de quien abriera el informe. Todo tapado. **Con esto el módulo de red queda repasado de arriba abajo al 100%** (eran cinco partes, ya están las cinco). (2) Edu pidió mirar un proyecto de internet (se llama "Cairn", de memoria para asistentes de IA) por si tenía ideas aprovechables: no lo adoptamos entero (no encaja con nuestra forma de trabajar en la nube), pero **le copiamos dos mejoras**: que la "memoria" de Claude dé prioridad a lo importante y no se corte a ciegas cuando se llena, y validar mejor cuando una decisión reemplaza a otra. Una tercera idea más costosa la dejamos apuntada para otro día. (3) Limpiamos **dos cabos sueltos** de mantenimiento: un fichero de datos que se había quedado sin guardar, y poner al día las "piezas" internas de los automatismos antes de que GitHub jubile las viejas el 16 de junio. **Todo en producción y en verde.**

Txell: verificación del sync de arranque + harness drift RESUELTO (tarea #87 cerrada)

micro-sesión administrativa de Txell (en dos arranques del mismo día). Primero comprobó que el sync de arranque dejó al día workspace y claude-method, y detectó un **WARNING de harness drift** (3 scripts locales distintos de la fuente); en ese momento se dejó la **tarea #87** anotada para Edu. En el segundo arranque, Txell pidió resolverlo directamente y **se cerró el drift**: los 3 hooks se resincronizaron con la fuente maestra `claude-method` vía `install_hooks.sh` y se publicaron en `main`. La copia local del repo estaba simplemente *vieja* (24-05) — desfase en una sola dirección, sin cambios locales valiosos que perder. El aviso ya no reaparecerá para nadie del equipo. Sin cambios en producto ni en el sistema Supercontexto.

Comprobamos la "puesta a punto" de Claude y estrenamos una forma de ponerle nota (sin tocar el producto)

sesión corta y de mantenimiento interno de Claude, **sin tocar nada del producto**. Veníamos de ayer, cuando pusimos a Claude "a dieta" (le recortamos el manual de instrucciones para que cumpla mejor las normas). Hoy hicimos tres cosas: (1) **comprobamos que esa dieta quedó bien puesta** (el manual cabe, la memoria entra entera, las normas especializadas se cargan solo cuando hacen falta); (2) **estrenamos un "examinador" automático** que lee lo que hizo Claude en una sesión y le pone nota según cuántas normas cumplió — la primera nota, sobre la sesión de ayer, fue un **83 %**; (3) ese examinador, de paso, **destapó un fallo**: el cartelito de "¿qué toca hacer hoy?" que debe salir nada más arrancar Claude estaba **saliendo en blanco** por un error tonto en el código que lo genera. Lo arreglamos y lo dejamos más contundente. Edu va a reiniciar Claude para ver el cartel ya funcionando. La auditoría de seguridad de red que tocaba (sa5) se aplaza a otra sesión por falta de crédito. **Cero cambios en el producto; todo el trabajo fue en las herramientas internas.**

Auditoría de Dispositivos/Backups de red, arreglo del Auto-Plan caído, y una "puesta a punto" del cerebro de Claude (CLAUDE.md + memoria)

día con tres bloques. (1) Seguimos la **auditoría de seguridad del módulo de red**, esta vez la parte de **dispositivos, copias de seguridad y grupos**: el agujero principal era que un usuario de **solo lectura** podía pedir las contraseñas descifradas de un equipo o descargarse su configuración completa (que lleva claves dentro); también había un botón de "restaurar copia" que **decía que funcionaba pero no hacía nada**. Todo arreglado. (2) En mitad del día, Edu avisó de que el **Auto-Plan** (la varita mágica que digitaliza un plano) **daba error con cualquier imagen**; resultó que un par de ajustes se habían quedado **sin valor** en el servidor y el programa no sabía interpretarlos — lo blindamos para que un ajuste vacío no pueda volver a tumbarlo, y ya funciona. (3) Edu planteó que Claude a veces **no cumple bien** algunas normas; investigamos las buenas prácticas oficiales y vimos que el "manual" de Claude (CLAUDE.md) se había hecho **demasiado largo** (470 líneas, más del doble de lo recomendado), lo que hace que se salte cosas. Lo **adelgazamos a 100 líneas** (con todo lo importante intacto), **podamos la memoria** (estaba al tope), y dejamos un **catálogo** del sistema interno + una forma de **medir** si esto mejora el cumplimiento. Todo con copia de seguridad previa. **4 PRs, todos verdes.**

Mejoras grandes de Auto-Provision y Observatory, modal de configuración de dispositivos, y arreglos del Worklog

sesión larguísima y muy productiva, toda guiada por Edu probando en vivo. (1) Rematamos el **asistente de Auto-Provision**: las búsquedas ya **no se pierden** (se guardan en la base de datos y las ve el equipo), se **ve el escaneo en directo** por fases, y ahora decides el destino de cada dispositivo **en la misma lista** y lo aplicas todo de un botón (antes había que repetir el escaneo por cada tipo). De paso Edu cazó que el botón "Refresh" daba error y lo arreglamos. (2) La página **Observatory** muestra ahora **todos los dispositivos del sistema** con los mismos filtros del Terminal, y al abrir uno se empieza a monitorizar solo, reutilizando sus credenciales, y aparecen sus gráficas. (3) Añadimos un botón **"Config"** en Observatory/Wireless/SAI/Cartelería para **editar las credenciales y los grupos** de cada dispositivo sin salir de esas páginas. (4) En el **Worklog** del workspace arreglamos tres cosas que señaló Edu: el listado mostraba un día de más, había actividades repetidas, y el filtro de fechas era engorroso (ahora con botones rápidos Hoy/7d/30d/Mes). (5) Tranquilizamos una **alarma de GitHub**: la organización es privada, nadie ve el código; el aviso "View as: Public" era solo una vista previa. **4 PRs (todos verdes) + el push del Worklog.**

Cierre de la 3ª pieza de la auditoría de "red", CI más robusto, Terminal mejorado y arranque de las mejoras de Auto-Provision

día largo y muy productivo. (1) Cerramos la **tercera pieza** de la auditoría del módulo de red (el catálogo de fabricantes y MIBs): el agujero gordo era que cualquier usuario, sin ser administrador, podía tocar ese catálogo que comparten todas las empresas, y un fichero subido podía escribir donde no debía — todo tapado. (2) Dejamos el **sistema de pruebas (CI) mucho más robusto**: ya no se pone "en rojo" por hipos de descarga ni por un test mal aislado que fallaba a ratos — eso era justo lo que le tenía harto a Edu ("siempre falla algo"), y hoy se cerraron las dos causas. (3) Mejoramos la página **Terminal**: ahora muestra **todos los dispositivos** (wifi, SAIs, cartelería…), no solo los de rack, con un filtro por tipo, y **recuerda las contraseñas SSH** para no reescribirlas. (4) Empezamos una tanda de mejoras del **Auto-Provision**; lo primero, un botón para **refrescar** un dispositivo concreto sin repetir todo el escaneo (reusando sus credenciales). De paso evaluamos dos herramientas externas (Paseo y memhub) y solo nos quedamos una buena práctica pequeña. **6 entregas, todas verdes.** El resto del plan de Auto-Provision (panel en vivo y asignación de varios tipos a la vez) queda planificado para la próxima.

Revisión y arreglo de las dos primeras piezas del módulo de "red" + el validador local ahora se autocorrige · (y un tropiezo de gasto)

arrancamos la auditoría del bloque de **red** (el que descubre los equipos de la red del cliente y permite lanzarles comandos por SSH). Cerramos sus **dos primeras piezas**, revisadas y arregladas, ambas comprobadas en verde: el **descubrimiento de dispositivos** (37 problemas) y el de **scripts por SSH** (33 problemas). De cara al cliente, lo más importante: al "ejecutar un script" el sistema **entraba sin querer en modo configuración** del equipo aunque el script fuera de solo mirar (podía cambiar la config del aparato) — arreglado para que solo lea; y el servidor podía acabar conectándose a su **propia red interna** — bloqueado. También un usuario de "solo lectura" ya no puede lanzar escaneos ni sembrar plantillas, y cada ejecución queda registrada. Además mejoramos la herramienta interna de revisión: ahora **arregla sola** los fallos de formato antes de subir, en vez de pararte. **El tropiezo**: al lanzar la tercera pieza, un agente de revisión se **quedó colgado**; al intentar reanudar el proceso se **dispararon más de 20 agentes de golpe** y consumimos crédito de más, así que Edu paró la sesión. La tercera pieza queda **pendiente** para la próxima con crédito fresco — no quedó nada de código a medias (esa revisión no tocaba código). Aprendizaje anotado para no repetirlo. **Detalle técnico** (autor: Edu + Claude Opus): - **network sa1 (Discovery/Auto-Provision) — PR #76 mergeado, CI verde**: 37 confirmados (11A/16M/10B). `require_perm` en los 5 endpoints Auto-Provision; nuevo `network/services/device_discovery/scan_guard.py` (guard SSRF específico: bloquea loopback/metadata/link-local pero **permite RFC1918** porque escanear la LAN del cliente es legítimo); IDOR en deep-discover-status; SNMPv3 deja de degradar a noAuth en silencio **+ bug preexistente arreglado** (el import de protocolos v3 apuntaba a un módulo inexistente → SNMPv3 nunca había funcionado); `match_stencil` filtra por org. 23 tests. ~5.3M tokens, 85 agentes. Diferidos a PRs propios (§8g): A4/A5/A7/A8/A9. - **network sa2 (Scripts/SSH/Auto-config) — PR #77 mergeado, CI verde**: 33 confirmados (6A/10M/17B). A5 (ejecución en modo exec por defecto, config opt-in); `validate_commands` (reusa el de los runbooks) + parseo multilínea; IDOR `suggest_stencil`; M7 (`is_private_ip` cubre CGNAT 100.64/10 = rango VPN NetBird → cierra SSRF servidor→infra interna); autorización unificada a `require_perm`; timeouts SSH 1h→120s; audit log de ejecución. 12 tests. ~3.64M tokens, 60 agentes. Diferidos (§8h): M3 (SSH host-key TOFU, con sa1 A9) + M5 (cifrado snmp_community, Plan Hardening E). _Nota de calibración: sa2 tuvo 0 refutados y 2 "ALTA" sobrevaloradas → la verificación adversarial fue floja; vigilar._ - **🔧 Harness**: el pre-commit ahora **auto-arregla ruff** (`autofix_ruff`: `ruff check --fix`+`format`+re-stage de los .py totalmente stageados, salta los de staging parcial). Fuente en `claude-method/harness/pre_commit_check.py` (formateada a line-length 120 para no romper el invariante source==copy), propagada a los 3 perfiles. Dogfooded en 2 commits. Memoria `feedback_pre_commit_mirrors_ci`. - **⚠️ network sa3 (Vendor/MIB/OUI) — INCOMPLETA**: workflow lanzado (motor reducido 3 finders, audit-only); un verificador se quedó zombi y bloqueó la fase de verificación. Al hacer `TaskStop`+`resumeFromRunId` el resume **re-disparó todo el fan-out `parallel()` de verificación (>20 agentes)** → sobre-gasto. sa3 sin veredicto, a re-auditar en s114 con crédito fresco. **Lección (en NEXT)**: no reanudar a ciegas un workflow colgado — un `parallel()` interrumpido re-ejecuta todos sus thunks; rescatar leyendo el transcript (0 agentes) o consultar el coste antes de relanzar.

Arreglo de las dos últimas piezas de monitorización + se acaba la plaga de "el CI falla siempre al primer intento"

sesión larga y productiva. Lo que la sesión anterior solo había **revisado**, hoy lo hemos **arreglado**: las dos últimas piezas de la monitorización (el módulo de **incidencias y avisos** y los **paneles de wifi y SAIs**). De los 64 problemas detectados, se cerraron todos los graves y la gran mayoría de los menores, repartidos en **6 entregas** seguidas, todas comprobadas en verde por el vigilante automático antes de darlas por buenas. Lo más importante de cara al cliente: un usuario de "solo lectura" ya **no puede tocar configuraciones que no le corresponden** (era el agujero que más se repetía); los secretos de los canales de aviso (contraseñas, tokens) ya **no se enseñan ni en pantalla ni en la base de datos** —ahora van cifrados—; y las alertas son más honestas y dejan rastro de quién hace qué. Al final, Edu hizo una observación muy valiosa: que **desde la última actualización casi todos los controles de calidad fallaban a la primera**. Lo investigamos a fondo y resultó ser un fallo real de nuestra propia herramienta de revisión local, que comprobaba menos cosas que el servidor; **lo arreglamos de raíz**, así que esa rutina molesta se termina. De paso, reparamos un proceso automático de mantenimiento que llevaba semanas fallando por una contraseña caducada. **El bloque de monitorización queda 100% terminado (revisado y arreglado).** Lo siguiente —auditar el bloque de "red"— lo dejamos para cuando el crédito esté al 100%.

Auditoría de las dos últimas piezas de monitorización (incidencias/avisos + wifi/SAIs) → dominio completo

con el crédito al 100%, Edu pidió **terminar al menos los workflows** de la Auditoría Suprema esta tanda, dejando los arreglos para otro día. Con eso cerramos del todo la revisión del **bloque de monitorización**: faltaban dos piezas y las dos quedaron auditadas. Una es el módulo de **incidencias y avisos** (los niveles de servicio acordados, los canales por donde se mandan las alertas, y los "runbooks" que ejecutan comandos en los equipos); la otra son los **paneles de wifi y de SAIs** (los sistemas de alimentación). Solo se **revisó, no se tocó nada de código**: salieron **64 problemas** confirmados. El que más se repite es el de siempre —faltan controles de permiso, así que alguien de "solo lectura" podría tocar cosas que no debería—, y se arregla casi todo con la misma pieza central que ya usamos en las tandas anteriores. Lo nuevo y serio: los canales de aviso guardan sus contraseñas/tokens **a la vista** y un endpoint devuelve una clave de red **en claro**. El sistema de doble revisión (poner agentes a intentar tumbar cada hallazgo) volvió a acertar: descartó una falsa alarma de "inyección" que en realidad estaba bien protegida. Todo queda documentado y ordenado para la sesión de arreglos. **El dominio de monitorización queda 100% auditado (6 de 6 partes).**

Auditoría de la IA de monitorización (recuperada tras un cuelgue) + cierre de las 2 deudas pendientes

la sesión de antes se había **colgado** justo después de analizar la parte de **inteligencia artificial** de la monitorización (los diagnósticos automáticos, el chat del tutor de redes y los avisos por webhook). Sin tener que repetir el análisis (que es caro), recuperé los 23 problemas que había encontrado y Edu pidió **arreglarlos todos de golpe**. El más importante: el sistema "aprende" de cómo los técnicos corrigen los diagnósticos, pero lo aprendido se guardaba en un cajón **compartido por todas las empresas** → algo de la empresa A podía aparecer en los avisos de la B; ahora cada empresa tiene su cajón aparte. También reparé un fallo que tenía el **tutor de redes roto desde hacía meses**, blindé la IA para que no se deje engañar por textos-trampa, y aseguré los avisos por webhook. Luego Edu quiso cerrar también las **dos tareas que habíamos dejado apuntadas**. Una era delicada (fijar la dirección de los servidores a los que se conecta para que nadie la cambie a traición), así que la **probé contra servidores reales —incluido el propio servidor de producción— antes de darla por buena**; esa prueba fue clave: descubrió que rompía un tipo raro de web, algo que decidimos asumir a sabiendas, y confirmó que el ataque que de verdad importa (que un aviso apunte a las "tripas" internas del sistema) queda **bloqueado**. Todo en producción y en verde.

El buscador del Bibliotecario, más afilado (ideas de ArcRift en producción)

cogimos las mejores ideas que sacamos ayer de evaluar ArcRift y las metimos en el buscador que responde el **Help** (a los clientes) y el **Oráculo** (a nosotros). Tres mejoras, todas medidas antes de encender: (1) **recorta la paja** — antes le pasaba a la IA los textos enteros, ahora solo las frases que de verdad responden → **gasta un 25-32% menos** sin perder calidad; (2) **se imagina la respuesta para buscar mejor** en preguntas difíciles (lo activamos tras comprobar que mejora las respuestas flojas); (3) **protege secretos y no se deja engañar** (si un documento llevara una contraseña la tapa, y si intentara "dar órdenes" a la IA lo ignora). Descartamos una cuarta idea más cara porque medimos que **no hacía falta** (el buscador ya encontraba bien, solo sobraba relleno). Montamos primero un "banco de pruebas" para medir, y resultó clave: cazó dos topes técnicos de Cloudflare **antes** de que llegaran a los clientes. Y el Vigía pilló un fallo de despliegue (un documento mal formado que bloqueaba las subidas) que arreglamos al momento. Todo en producción y en verde. **Edu lo prueba en la próxima sesión.**

Auditoría Suprema monitorización (6ª parte, la más barata) + piloto BONSAI + evaluación ArcRift

media jornada, dos bloques. (1) **Auditoría Suprema**: como Edu pidió ir corto de crédito, hicimos la **parte más pequeña** del módulo de monitorización — las páginas del Observatory (Wireless/UPS/Signage/Network) y el **tiempo real** que actualiza los gráficos. Lo primero, una buena noticia: el tiempo real estaba **bien aislado** (un cliente de una empresa no podía espiar la telemetría de otra; la prueba lo confirmó). El arreglo de fondo: al abrir esas páginas, CreaRack "da de alta" dispositivos automáticamente, pero **no comprobaba el permiso** → un usuario de **solo lectura** disparaba esas altas; ahora solo ocurre si tienes permiso de edición. De paso quitamos código duplicado (un fichero de 677→446 líneas) y reforzamos el tiempo real. Fue la tanda **más barata de toda la auditoría**. (2) **Dos herramientas que trajo Edu**: investigamos **BONSAI** (un "jardinero" que, tras cada turno, revisa el código en segundo plano y avisa solo de lo importante) → **arrancamos un piloto de 2 semanas** con métricas y frenos, y con la tranquilidad de que **gasta de la suscripción (Plan Max), no de la API de pago**; y **ArcRift** (memoria persistente para IA) → no encaja con nuestra arquitectura (es local, nosotros somos cloud), pero le sacamos 3 ideas para mejorar nuestro buscador interno. Todo subido y en verde.

Auditoría Suprema monitorización (2ª parte) + fix del backup gigante + Vigía + UX de la wiki

día muy productivo y de bajo riesgo. (1) Seguimos la Auditoría Suprema con la **segunda parte del módulo de monitorización** (los "sondeos": ping, SNMP, web): la auditamos y la arreglamos de una vez — lo gordo era que el chequeo de webs se podía desviar a direcciones internas del propio servidor (lo cerramos con un "portero" único), más permisos que faltaban en SNMP y otra rendija de fuga entre empresas. (2) Arreglamos un **fallo que detectó Edu**: el "Full Backup" había pasado de 30-40 MB a **333 MB** porque metía en el ZIP las imágenes de **todas las empresas**, no solo la tuya (tamaño inflado + fuga); ahora incluye solo lo tuyo. (3) Bautizamos al ayudante de CI como **"Vigía"** y lo usamos todo el día (vigila las subidas en segundo plano). (4) **Adelgazamos del todo la memoria de Claude** para que entre entera. (5) Convertimos el motor de auditoría en una **herramienta reutilizable** y escribimos el **Plan de la Auditoría Suprema en la wiki** (para cuando volvamos a pasarla). (6) Pulimos la **lectura de la wiki**: índice lateral plegable, "miga de pan" completa (sabes en qué wiki y epígrafe estás y puedes subir pulsando), y un aviso más claro al guardar en el editor. Todo subido y en verde.

Auditoría Suprema: módulo de monitorización (1ª parte) saneado + mejoras de método (memoria, ayudante de CI, plan de firewall)

jornada doble. Por un lado seguimos la Auditoría Suprema con el módulo de **monitorización** (el más grande del producto, lo partimos en 6 trozos): auditamos y arreglamos de una vez la primera parte (alta de dispositivos, métricas e ingesta). Lo importante para entendernos: ahora un usuario "de solo lectura" **ya no puede** crear/borrar dispositivos vigilados ni lanzar barridos de red, las **contraseñas SNMP ya no se enseñan** por pantalla, y cerramos una rendija por la que se podían **espiar datos de otra empresa**; de paso descubrimos que tres funciones de barrido masivo llevaban tiempo **rotas (daban error 405)** y las dejamos operativas y protegidas. Por otro lado, mejoras de "fontanería": **adelgazamos la memoria de Claude** (estaba tan llena que media no se cargaba), creamos un **ayudante Haiku que vigilará el CI** a partir de mañana para liberar al modelo potente, y dejamos **guardado un plan** para endurecer el cortafuegos del servidor apoyándonos en NetBird (sin prisa). Todo en verde y documentado.

Auditoría Suprema: módulo base arreglado en producción + auditado y saneado el módulo de Racks

seguimos con la Auditoría Suprema. Primero terminamos de arreglar el módulo base (`core`): los 5 fallos serios que encontró la prueba de ayer ya están corregidos y funcionando en producción, verificados de verdad —incluida una "puerta trasera" que permitía colarse en el panel de administración falseando un dato de la conexión—. Después auditamos el segundo módulo, **Racks**, pero afinando el motor para gastar menos crédito (preocupación que planteó Edu): en lugar de los 133 "agentes" de ayer usó 96, y aun así encontró más cosas. Salieron 42 problemas (13 graves) y arreglé los 6 más peligrosos —entre ellos un par que dejaban borrar o escribir archivos del servidor con rutas trampa, y otro que permitía cargarse la librería de iconos compartida por todos—. Edu decidió **parar aquí** y seguir con el siguiente módulo (`blueprints`) en la próxima sesión, para no disparar el gasto. Todo subido, en verde y documentado.

Arranca la "Auditoría Suprema": diseño + primera prueba sobre el módulo base

Edu propuso al cerrar ayer una "Auditoría Suprema": repasar a fondo TODO el código para luego limpiarlo, pulir lo que ya hay, descubrir lo que falta y proponer ideas nuevas. Hoy diseñé el plan completo, Edu eligió cómo enfocarlo (a máxima profundidad, empezando ya con una prueba), y lancé esa prueba sobre el módulo base del producto (`core`). El resultado fue muy bueno: un equipo de agentes encontró 39 problemas sólidos —varios serios que ni el mapa del "Máster" había detectado— y cada uno pasó por un triple filtro de verificación para descartar falsas alarmas. Se nos agotó el crédito de la sesión (fue intensa), así que dejé todo bien documentado para continuar exactamente desde aquí en la próxima, esperando ~1,5 h a que se recupere el crédito.

Mejoras de método (Git), el Help arreglado de verdad y manual de Auto-Provision

Mejoras de método (Git), el Help arreglado de verdad y manual de Auto-Provision

Terminada la ronda de refuerzos de seguridad del producto

Terminada la ronda de refuerzos de seguridad del producto

Mejoras de seguridad y documentación, con un tropiezo de método

Mejoras de seguridad y documentación, con un tropiezo de método

🏁 HITO: onboarding del staff al 100% en los 3 perfiles

🏁 HITO: onboarding del staff al 100% en los 3 perfiles

Auditoría y saneamiento del Harness

Auditoría y saneamiento del Harness

Reparado el "hot cache" (Claude arrancaba leyendo una página de login)

Reparado el "hot cache" (Claude arrancaba leyendo una página de login)

Honestidad de pantallas (Hito B) + blindaje del "modo de esfuerzo"

Honestidad de pantallas (Hito B) + blindaje del "modo de esfuerzo"

Alarmas de PROD por email + un "candado" que obliga a Claude a consultar la Biblioteca

Alarmas de PROD por email + un "candado" que obliga a Claude a consultar la Biblioteca

Le hicimos a Claude un "máster" del proyecto y lo dejamos como herramienta repetible

Le hicimos a Claude un "máster" del proyecto y lo dejamos como herramienta repetible

Nueva herramienta del Workspace: un vigía de librerías desactualizadas

Nueva herramienta del Workspace: un vigía de librerías desactualizadas

El oráculo del workspace volvió a funcionar (no estaba roto, se "dormía") y arreglamos por qué yo razonaba a medio gas

El oráculo del workspace volvió a funcionar (no estaba roto, se "dormía") y arreglamos por qué yo razonaba a medio gas

Día doble: arreglamos un bug que llevaba meses rompiendo wikis, dejamos el portal estable de verdad y el dashboard se ve mejor

Día doble: arreglamos un bug que llevaba meses rompiendo wikis, dejamos el portal estable de verdad y el dashboard se ve mejor

Comprobación rápida desde el ordenador de Txell

Comprobación rápida desde el ordenador de Txell

Día grande del Bibliotecario: deuda técnica de abril cerrada al 100% + el sensor ya no se queda corto

Día grande del Bibliotecario: deuda técnica de abril cerrada al 100% + el sensor ya no se queda corto

Falsa alarma de "organización desaparecida" + nueva forma de compartir entre los Claudes del equipo

Dani avisó de que, usando el panel de administración, se le había "desaparecido" una organización. Resultó ser una **falsa alarma**: no se borró nada — el usuario y la organización siguen ahí, los dos vivos. Lo que pasaba es que un enlace antiguo del historial del panel quedó "apuntando al cajón equivocado" después de la reconstrucción de la base de datos que hicimos a finales de abril, y al pincharlo daba un error que parecía pérdida de datos. Lo confirmamos mirando la base de datos **sin tocar nada**. De paso, la charla nos dejó una idea útil que pusimos en marcha: una forma sencilla de que los tres Claudes del equipo (Edu, Dani, Txell) **compartan cosas entre ellos** — basta con crear una página y etiquetarla con `staff-share`, y los demás la encuentran solos preguntándole a su Claude. Lo dejamos documentado para los tres y avisamos al equipo con una noticia.

Agente Local (aviso de permiso), IA ya en el modelo barato, base de datos y documentación al día, y arreglos de consola

Agente Local (aviso de permiso), IA ya en el modelo barato, base de datos y documentación al día, y arreglos de consola

Panel más rápido (75→99), más estable, y papeleo interno ordenado

Panel más rápido (75→99), más estable, y papeleo interno ordenado

"La web va lenta" → era la VPN, no la web

"La web va lenta" → era la VPN, no la web

Onboarding de Dani + cambio de VPN (Tailscale → NetBird)

Onboarding de Dani + cambio de VPN (Tailscale → NetBird)

Cambio del Bibliotecario al modelo de IA barato (Haiku)

Cambio del Bibliotecario al modelo de IA barato (Haiku)

Saneamiento + Idea Market + optimización coste del Bibliotecario + prueba Haiku vs Sonnet

Saneamiento + Idea Market + optimización coste del Bibliotecario + prueba Haiku vs Sonnet

Onboardings E2E + backup dual de memoria + harness vivo (settings sync)

Onboardings E2E + backup dual de memoria + harness vivo (settings sync)

Reunión popup window + rediseño /biblioteca/pulse en 6 bandas + tarjeta Crons del sistema

Reunión popup window + rediseño /biblioteca/pulse en 6 bandas + tarjeta Crons del sistema

Evaluación Understand-Anything + 4 cherry-picks Bibliotecario + WebRTC peer-to-peer reemplaza Jitsi

Evaluación Understand-Anything + 4 cherry-picks Bibliotecario + WebRTC peer-to-peer reemplaza Jitsi

Día denso · auditoría onboardings 5 pasadas + drama CF Access + Oráculo UX + widget Salud refactor

Día denso · auditoría onboardings 5 pasadas + drama CF Access + Oráculo UX + widget Salud refactor

Workspace UI sprint · worklog unify + Cuaderno multiusuario + tareas comentarios + chat avisos/maximize/paste/Jitsi flotante

sesión maratoniana de tarde-noche encadenada con la auditoría matutina (s76). Cinco frentes encadenados de UX visible para el equipo, todos en frontend del workspace. Empezó unificando las páginas de Actividad y Worklog (que estaban duplicadas), siguió con el Cuaderno volviéndose multiusuario con compartir notas entre los 3 + 7 herramientas nuevas en la barra (deshacer/rehacer, autocorrector, marcador urgente, emoji picker, pegar imágenes, dropdown compartir, botones más finos), luego mejoras en el menú Tareas (click en la card del widget abre el modal de edición, badge "N comentarios" en las tarjetas, nueva pestaña Comentarios que es un gestor transversal con filtros completos por toda la base de comentarios, y el botón Nueva del widget que ahora abre directo el modal de crear). El plato fuerte fue el widget Chat: avisos audio+visual cuando llega mensaje (beep si tienes otra tab activa + número en el title + favicon rojo + chip "N sin leer"), botón maximizar a columna full-height, capacidad de pegar capturas Ctrl+V (suben a R2 y se ven como `<abrir imagen>` clickable), y un botón Reunión que abre Jitsi Meet embebido para hacer videollamada con Dani y Txell sin instalar nada. Y al final, tras Edu probar, refactor del modal Jitsi para que sea una ventana flotante movible (no oculta el resto del workspace) + aviso automático en el chat cuando alguien inicia reunión. Por el camino hubo un episodio dramático con el layout del Cuaderno (3 iteraciones para que el canvas se ajustara correctamente sin tapar botones ni dejar hueco abajo — al final descubrimos que Astro mete un `astro-island` y React un outer div que rompían la cadena flex, fix con `display: contents`) y un susto de 5 minutos cuando Edu pensó que se habían perdido las 17 notas del Cuaderno (en realidad seguían ahí pero el nuevo código usaba un email diferente al guardado en la BD, fix con un UPDATE SQL para reasignar `owner_id`). Total del día (s76 mañana + s77 tarde-noche): ~8.5h efectivas. 5 PRs del workspace mergeados (#55-#59), 4 push directos hotfix, 1 migration D1 aplicada en remote, 0 caídas PROD reales, CI 100% verde, 0 commits CreaRack-Pro. Sin nuevas memorias (sesión de implementación pura, sin footguns nuevos — todos los patrones aplicados son refinamientos de cosas conocidas). Workspace mucho más rico que ayer en UX, todo listo para que mañana en la sesión presencial con Txell ella vea ya un dashboard completo y funcional.

Auditoría exhaustiva post-Org + runbook credenciales + onboardings pulidos pre-sesión Txell

Auditoría exhaustiva post-Org + runbook credenciales + onboardings pulidos pre-sesión Txell

Cierre deuda Org GitHub + Bloque B onboardings + 5 footguns nuevos

Cierre deuda Org GitHub + Bloque B onboardings + 5 footguns nuevos

Migración GitHub User→Org + auditoría exhaustiva post-migración

Migración GitHub User→Org + auditoría exhaustiva post-migración

Oráculo de EL Fase 2 · claude-method indexado en el corpus

Oráculo de EL Fase 2 · claude-method indexado en el corpus

Oráculo de EL desplegado · chat conversacional sobre el grafo

Oráculo de EL desplegado · chat conversacional sobre el grafo

Deuda inline styles workspace ELIMINADA + fix cron D1 Cleanup

Deuda inline styles workspace ELIMINADA + fix cron D1 Cleanup

Docs BD + Mermaid wiki + vista limpia + cron cleanup D1

Docs BD + Mermaid wiki + vista limpia + cron cleanup D1

TaskModal redesign + Team Chat + emails granular + UX dashboard

la sesión más larga del proyecto. Empezó verificando el primer run del cron Maintenance-Weekly que cayó otra vez al patrón Gmail draft (como hace 5 días). En lugar de parchearlo con prompts otra vez, fuimos a la causa raíz arquitectónica: los routines de claude.ai corren headless, no pueden completar el OAuth interactivo del MCP, y el agente Sonnet acaba viendo solo dos tools de bootstrap en lugar de las reales. Solución definitiva: bypass via curl directo al endpoint con un Bearer estático nuevo (`MAINTENANCE_AGENT_TOKEN`) + Service Token de CF Access. Validado end-to-end con dos emails reales llegando al inbox de Edu con UUID Resend. Tras cerrar ese hito, pivotamos a UX del workspace. Diseñamos un esquema granular de 8 emails internos en Zoho (`infra@`, `security@`, `factu@`, `legal@`, etc.) para que dejemos de tener todo mezclado en `edudomo2@gmail.com`. Luego refactor completo del modal de tareas con 7 iteraciones del agente design-collaborator: pasamos de un layout vertical apretado a 2 columnas horizontal con sistema de comentarios stash+persist, botones "Promover como Alerta/News", Copiar enlace, zona peligrosa para eliminar al final, halo 3D detrás del modal, etc. Para complementar añadimos un Team Chat (estilo grupo WhatsApp del staff) como tercer widget del home — sin destinatarios, polling 15s, typing indicator, auto-linkify URLs, borrar propio. También un banner que detecta automáticamente cuando hay un deploy nuevo y avisa al usuario para recargar — costó dos intentos porque CF Access bloqueaba el archivo de version y luego porque lo había montado en el layout equivocado, pero al final funcionó. Reubicamos el reloj de arriba a la línea del título del home (solo hora grande), ganamos ~35px verticales en todas las páginas reduciendo paddings, hicimos el filtro de tareas persistente en localStorage, click en card del widget abre el modal directo. Y al final derogamos la Regla 7 (solo texto, nunca iconos) parcialmente en el workspace — los iconos Lucide pequeños donde aportan claridad están ahora permitidos. CreaRack-Pro mantiene la regla estricta. Sesión intensa pero el workspace ha cambiado mucho en un día.

Zoho pivot completo: per-user + auto-events ciclo de vida task

tras un día con la integración Zoho de la s67 en producción, replanteaste el enfoque entero con una observación correcta — "nuestro gestor de tareas es más capaz que el de Zoho, no necesito sus Tasks, solo Calendar y Mail". Pivoteamos: D1 sigue siendo la fuente de verdad de tasks, KanbanMini intacto, y Zoho Calendar+Mail entran como canales de acción explícita desde la propia tarea (la task es el "hub", Zoho son los brazos). También cambiamos del modelo Service Account (s67) a per-user OAuth (cada miembro autoriza su cuenta — obligatorio para Mail, coherente para Calendar). Y al final añadimos "auto-events de ciclo de vida": cuando creas una task con asignados y fecha límite, Zoho crea solo un evento "Inicio" y otro "Fin previsto" en el calendario de cada implicado; cuando cierras la task, "Fin previsto" desaparece y aparece "Cerrado". Pequeña catarata de aprendizajes técnicos sobre la marcha (4 fixes reactivos): CF Access no inyecta el header email así que tuve que sacarlo del JWT decoded, las fechas Zoho son formato compact YYYYMMDDTHHmmssZ sin guiones, los scopes UPDATE/DELETE no estaban en mi lista inicial y Zoho rechaza DELETE sin un header etag de concurrencia optimista. También aprendimos que el modo admin `?as=Dani` solo dice al backend bajo qué cuenta guardar, pero la cuenta efectiva la determina la sesión Zoho activa del navegador — por eso autorizaste 3 tokens cruzados antes de descubrir que había que hacer logout en mail.zoho.eu entre cada autorización. Documentado todo en un runbook nuevo + 4 memorias para que no se repita. Al final del día, validaste E2E en producción: crear task con assignees+due_date → 2 eventos en cada calendario + invitaciones a Dani y Txell → cerrar task → swap correcto Fin previsto → Cerrado. Sesión intensa pero el sistema está completo y robusto.

Zoho integración · Fase A en PROD

una pregunta tuya al final del día — "he visto que Zoho dispone de Calendario y Tasks · ¿tendrá API para integrarlo con nuestro Workspace?" — terminó en una integración completa funcionando en producción. Validamos con la doc oficial de Zoho que el plan Mail que ya pagáis incluye API REST para Calendar y Tasks (sin webhooks, pero con polling estándar). Firmamos un ADR multifase A/B/C/D y arrancamos por Fase A (lectura). En el camino tomamos 5 decisiones tácticas en conversación contigo: (1) modelo Service Account (tú autorizas una vez, Dani y Txell no ven OAuth), (2) filtro UI Todos/Edu/Dani/Txell replicado de Zoho, (3) ruta Y "coexistencia" tras descubrir que tu widget de Tareas del home es un kanban con drag-drop que sustituir habría sido perder funcionalidad hasta Fase D, (4) postponer la migración masiva de 27 tasks MCP a Zoho hasta tener drag-drop Zoho en Fase D, (5) archivar el plan paralelo de "módulo Meetings propio" (task #29) que quedaba sin sentido con Zoho ya integrado. Implementé PR #44 (~1.2k LOC, 13 archivos), pisé un footgun memorizado de `wiki_create_page` schema que no consulté (1 commit fix de 1 línea), CI verde tras fix, mergeé, apliqué migration D1 en remote, tú autorizaste el OAuth en producción y validaste smoke test E2E del widget en el home. Cerré las 3 tasks Claude correspondientes y dejé NEXT.md con un bloque programático completo de Fase B para que cualquier sesión futura pueda retomar sin contexto previo.

Plan Servicios cierre operativo 97% + Fase C ligera ejecutada (6 crons migrados a STAGE)

continuación de la sesión tarde. Tras cerrar Fase A al 90% y avanzar Fase B con 3 PRs, volvimos a por la tarea menor (#30 subir el `.exe` del Agent v2.0.20 a la GitHub Release). Mientras lo hacía, te diste cuenta de que cada bump del Agent debe ir SIEMPRE con los 3 frentes cerrados (docs + tag + .exe) — quedó como disciplina permanente. Luego revisamos qué quedaba del Plan Servicios y decidimos descartar la página `/services` nueva en favor de refinar la wiki existente (5x más rápido, sin código). Aplicamos 5 mejoras a la wiki del catálogo: "Si esto cae, cae el negocio" + costes arriba + tabla "Para Txell · qué facturamos" + columna Panel billing + limpieza banner. Después declaramos Plan Servicios cerrado operativamente al 95%. Pero te entró el gusanillo de la Fase C (migración Hetzner): tras analizar consumo Actions real ($0 overage actual, 22% del cap) y descubrir que ya hay infra cron del Bibliotecario corriendo en STAGE desde s50, decidimos ejecutar Fase C **ligera**: migrar los 6 cron-workflows del Bibliotecario que son llamadas curl-MCP triviales (NO los 4 que necesitan Node/Python+clone, NO el self-runner CI). 6 scripts bash en `/opt/biblioteca-crons/` + `/etc/cron.d/biblioteca-crons` + smoke test 5/6 OK. GH Actions schedule comentado en los 6 workflows (workflow_dispatch mantenido para rollback). En medio del trabajo encontré un bug serio del MCP `wiki_update_page` con `patch` object: corrompió 2 .md escribiendo JSON crudo. Recuperados con json.loads. Memoria guardada. Cleanup colateral: 8 branches locales stale eliminadas tras autorizar.

Plan Servicios · Fase A 90% + 3 PRs Fase B mergeados

tarde maratón de Plan Servicios. Empezamos con la discusión a nivel CEO (¿cómo controlamos el enjambre de SaaS externos?) y acabamos con 3 Pull Requests mergeados de cleanup real y un agujero de seguridad cerrado que llevaba 5 días abierto sin que nadie lo viera. Tras consensuar el plan multi-fase (Auditoría → Limpieza → Migración selectiva), documenté el ADR, monté el catálogo de 22 servicios externos, audité 5 candidatos sospechosos (DeepSeek, groupdocs, Zoho extras, Workers AI, Spinetix), descubrí que 2 estaban muertos en PROD (DeepSeek + groupdocs), y los retiré con cleanup quirúrgico. Pasada esa primera vuelta, auditamos los crons (cero huérfanos · resultado bueno) y de paso descubrimos un CVE en `python-multipart` del Local Agent que el cron `agent-pip-audit` llevaba 5 días gritando en silencio. Bumpeado, Agent v2.0.20 publicado en GitHub Releases. Tú probaste en PROD que el Rack Editor sigue importando `.vss` perfectamente tras quitar groupdocs (lo soportaba ya con `libvisio-tools` desde s40, era redundante). Acciones manuales que hiciste durante la sesión: revocar API keys DeepSeek + GroupDocs, rebuild Agent v2.0.20, distribución a clientes. Pendientes minor (costes reales en paneles, dashboard visual `/services`, decisión Bitwarden vs alternativas) quedan delegados como tasks MCP workspace #30-33 con due_date.

Normalización consumo GitHub Actions tras cap hit s65

día tranquilo de fontanería. El viernes pasamos del cap mensual de los 3000 min de GitHub Actions y los crons del workspace estaban pausados de emergencia. Hoy he limpiado todo eso: he unificado el patrón de pausa (un solo flag controla los 10 crons del Bibliotecario, antes solo controlaba 5), he bajado de diario a 3 veces por semana los crons que no tenían por qué correr todos los días, y he añadido al CI de CreaRack-Pro un filtro para que los commits que solo tocan documentación (README, CHANGELOG, archivos `.md`...) no disparen los 4 jobs en paralelo cuando subes a `main` directo. Pull Requests siguen corriendo el CI entero, así que no se nos cuela nada. 2 PRs mergeados, todo verde, cero caídas. Te queda 1 minutito en la UI de GitHub: subir el spending limit a $20/mes como colchón (te salvó con $1.04 la semana pasada).

Admin email noreply@esfericlabs.com + housekeeping OpenRouter + plan MVP Meetings workspace

día tranquilo de admin y arquitectura. Configuré la dirección de correo `noreply@esfericlabs.com` en Zoho (la cuenta corporativa nueva de Esferic Labs SL) y aclaramos cómo van a convivir Resend (los mails del SaaS al cliente, sigue con `crearack.com`) y Zoho (mails humanos del equipo). Charlamos si los clientes deberían recibir mails de `esfericlabs.com` en vez de `crearack.com` (decidimos: NO de momento — los clientes conocen la marca CreaRack, Esferic Labs queda para legal/facturación, patrón Slack/Stripe). Lo guardé como decisión a discutir con el equipo. Limpié un pendiente fantasma de "Hygiene OpenRouter" que aparecía cada sesión pese a estar cerrado hace tiempo (verificado en producción + drift documental viejo retirado). Y diseñé el plan completo de un módulo de **gestión de reuniones** para el workspace — porque Edu, Dani y Txell hacen muchas reuniones y queremos trazabilidad agenda → actas → decisiones → tareas. Está todo guardado como tareas MCP en el workspace + entrada-puntero en `TASK.md` para la próxima sesión.

Esferic Labs setup + Quick Links fix + unificación Worklog/Activity

cuatro tareas reales detrás de un día de admin disfrazado. Monté las firmas de email del equipo en Zoho con el nuevo nombre **Esferic Labs SL**, arreglé los DNS que Zoho marcaba en rojo (un SPF heredado tenía una IP fantasma de Yoigo y un bucle autoreferente), descubrí que las Quick Links del workspace estaban **todas duplicadas** por un bug viejo de migraciones D1 y lo arreglé de raíz (no se podrá repetir), unifiqué las páginas Actividad y Worklog (eran redundantes), y añadí botón de **Cerrar sesión directo** al avatar de la esquina del workspace. 3 PRs workspace + 1 commit docs, todo verde, sin caídas.

Cierre KB vs Graph Fase 5 + saneamiento docs

Cierre KB vs Graph Fase 5 + saneamiento docs

KB vs Graph Fases 1-4 desplegadas

KB vs Graph Fases 1-4 desplegadas

Sesión arquitectónica · 7 iniciativas + ADR rediseño documental KB vs Graph

Sesión arquitectónica · 7 iniciativas + ADR rediseño documental KB vs Graph

Maintenance-Weekly envío real + crons STAGE HTTP 302 + UX gestor tareas + translate-wiki fuera del build

Maintenance-Weekly envío real + crons STAGE HTTP 302 + UX gestor tareas + translate-wiki fuera del build

Propagador claude-method bidireccional + paridad mobile + deuda 64 inline styles V1HomeVivo cerrada

Propagador claude-method bidireccional + paridad mobile + deuda 64 inline styles V1HomeVivo cerrada

audit drift sistémico + 4 deudas zanjadas + plan Gap 1 propagador claude-method (s60)

audit drift sistémico + 4 deudas zanjadas + plan Gap 1 propagador claude-method (s60)

Hotfix d20 Help Widget · CF Access Service Token en callers Django runtime

Hotfix d20 Help Widget · CF Access Service Token en callers Django runtime

Saneamiento TS workspace + Cloudflare Security Insights + CF Access Service Token migration

Saneamiento TS workspace + Cloudflare Security Insights + CF Access Service Token migration

Informante del estado + design tokens D.10 + unificación CI workspace

Informante del estado + design tokens D.10 + unificación CI workspace

Help Widget Chat Tutor + Cuaderno workspace pulido

Help Widget Chat Tutor + Cuaderno workspace pulido

Help Widget: idioma + listas numeradas + modo IT Tutor (sesión corta · cierre urgencia)

Help Widget: idioma + listas numeradas + modo IT Tutor (sesión corta · cierre urgencia)

Help → AI Studio paid + cierre exposición pública llama-help

Help → AI Studio paid + cierre exposición pública llama-help

Help Widget end-to-end + arranque tools workspace

Help Widget end-to-end + arranque tools workspace

Lanzador Claude CreaRack portable (sustituye claude.bat de s51)

Sesión corta de fix sobre el `claude.bat` de s51, que rompía la apertura "como es habitual" en PowerShell 7.6.1 + perfil cargado.

Lanzador claude.bat + Txell fijada en Claude Code CLI

Sesión corta de housekeeping. Dos hilos:

Design Toolkit instalado + propagado a staff (claude-method/global-agents + global-skills)

Sesión disparada por el deseo de Edu de rediseñar `workspace.crearack.com` con un estilo "Holo" (referencia visual: `C:\dev\miscelanea\imagenes\ejemplo 1.png` — fondo casi negro, acento verde lima neón, transparencias suaves, tipografía geométrica). Pre-requisito: confirmar que existe un "Agente de Diseño" (Edu pensaba que se había implementado en sesión anterior — verificación rápida: NO existía).

Biblioteca al 100% health (4 fixes encadenados)

Sesión de **~1h efectiva** que arrancó con el aviso "Cobertura baja — 37% · 2517 stale de 3994 nodos" persistiendo tras s50. Investigación destapó **3 bugs estructurales latentes** y **2 limpiezas legacy pendientes**, todos resueltos. Cierre con métrica histórica del proyecto: **17% → 100% health, 2517 stale → 1**. Sub-agente Opus paralelo se llevó la limpieza más tediosa (164 doc nodes rejuvenecidos uno a uno) mientras el thread principal hacía el TS extractor fix.

sesión 51 (tarde)

sesión 51 (tarde)

Biblioteca reindex completo definitivo + watchdog routine cloud + nueva línea docu servicios Claude + Vertex AI research postpuesto + UI workspace

Sesión maratón que arrancó con un aviso "Cobertura baja — 2517 stale de 3958 nodos" en panel workspace y terminó destapando un cron de la Biblioteca parado **10 días silenciosamente** (chmod perdido tras git pull) + arquitectura de reindex incompleta por diseño (cubría solo AST Python, no docs/endpoints/schemas). Resuelto **definitivamente** con scripts faltantes, endpoint Bearer auth, cron triple y doble línea de defensa con routine cloud. En paralelo: investigación Vertex AI postpuesta + nueva línea de documentación sobre servicios Claude asociados (3 docs nuevos en `context/`).

Auto-Plan migrado a google-genai SDK directo Google AI Studio Paid Tier (sustituye OpenRouter :free BYOK del s48)

Sesión que arrancó como una migración aparentemente trivial ("vamos a probar Gemma 4 directo desde Google sin OpenRouter") y terminó destapando que el ganador del s48 (`:free` BYOK) no cumplía constraint SaaS comercial + un audit Opus que reveló 3 bugs críticos en el driver OpenRouter + descubrimiento empírico de que la lotería de calidad venía de fallback silencioso entre providers físicos.

Edu (sesión 48 · Auto-Plan PROD migrado a OpenRouter :free BYOK · 100% calidad / 2 min / $0)

Edu (sesión 48 · Auto-Plan PROD migrado a OpenRouter :free BYOK · 100% calidad / 2 min / $0)

Auditoría deuda técnica + consolidación inventario Hetzner + Regla 24/15 (Igualdad de accesos del staff)

Sesión que arrancó como una consulta simple ("qué tenemos de deuda técnica?") y terminó cerrando 2 deudas + anclando una regla nueva del equipo + propagándola a los 3 onboardings staff + documentación asociada.

Auto-Plan calidad 70 % → 99 % (afinado prompt + flags vision Reddit + 32 cores + mmproj F32)

Sesión doble en el mismo día (mañana s45 setup hardware, tarde s46 afinado calidad). Sin tocar hardware, con solo flags de llama-server, prompt y subida del LXC a 32 cores, calidad Auto-Plan en plano test 70 racks **subió de 70 % (s45 baseline) a 99 % estable**. Coste: tiempo de plano de 3:30 a ~6:00 min por procesar 8× más image tokens.

Migración llama-server a EPYC 7502P 256 GB / 8 canales DDR4 (pve-epyc-02)

Migración completa del host llama-server a un nuevo Hetzner Server Auction con la misma CPU (EPYC 7502P) pero **8 DIMMs llenos (256 GB DDR4-2933 ECC reg, 8 canales activos)** en lugar de 4 — bandwidth ×1.85 vs el setup anterior (4 canales DDR4-3200). Coste +28 €/mes. Plan ejecutado en una sesión completa con setup paralelo, sin downtime de Auto-Plan.

Hardening seguridad pve-epyc-01 + purga Ollama + Tailscale en host

Sesión continuación de la 43. Plan inicial: optimizar Proxmox con scripts community. Resultado tras diagnóstico read-only: **las optimizaciones community ya estaban aplicadas desde s43** (PVE Post Install, CPU governor performance, microcode AMD al día, kernels limpios). Pivote del plan: cerrar deudas s43 + hardening seguridad descubierto en auditoría.

Migración Auto-Plan a llama.cpp b8984 · 60% calidad / 7:33 / 98.5% recall

Sesión continuación de la 42. Objetivo: subir calidad Auto-Plan del 30% a igual o cerca del 100% que daba la laptop. Resultado: stack llama-server adoptado en producción con **calidad 60%, tiempo 7:33, recall 98.5%** (67/68 racks). 100% sigue inalcanzable porque el modelo `gemma4` que daba 100% en laptop es propietario de Ollama Hub y no carga en llama-server estándar.

Migración EPYC 7502P · Proxmox VE 9.1 + LXC Ollama + smoke test Auto-Plan

Sesión densa: levantar el nuevo server Hetzner Server Auction EPYC 7502P (167.235.119.253), montar Proxmox VE 9.1, LXC unprivileged Ubuntu 24.04 con Ollama 0.21.2 + Gemma 4 8B Omni, conectar Crearack PROD vía Tailscale y validar con plano 70 racks. Resultado: server productivo, **calidad Auto-Plan insuficiente (30%) — optimización pendiente sesión 43**.

GitHub Pro + bumps Node 24 + rotación GEMINI_API_KEY

Sesión cortita para desbloquear el CI tras el bloqueo por billing del 29-04 y sanear infraestructura GitHub Actions.

Auto-Plan self-hosted Hetzner (validación + decisión migración EPYC)

Sesión maratón validando Auto-Plan AI self-hosted en server Hetzner provisionado (Xeon E-2276G + 64 GB ECC + 2× NVMe RAID 1 + Tailscale 100.64.188.104).

Migración total IA Gemini → Gemma 4 vía OpenRouter

Sesión continuando el plan registrado en memoria `project_gemma4_openrouter` de la sesión 39 cierre.

Help Widget bilingüe restaurado + Gemma 4 plan próxima sesión

Sesión cierre de día. El Help Widget de CreaRack devolvía 404 al abrir cualquier doc tras la consolidación Supercontexto que eliminó `src/content/wiki-en/` del workspace. Cinco fixes encadenados hasta dejarlo bilingüe operativo otra vez.

Mobile pulido + /me + /servers + Hetzner

Sesión larga de pulido mobile post Mobile Review (s36). Tras detectar issues en uso real, cerrar todo lo accionable de la home mobile y completar la BottomNav.

CF Pages migrado a Direct Upload

Cierre del footgun `cf_pages_skip_ci` que llevaba activo desde sesión 10. La integración nativa GitHub App ↔ CF Pages marcaba commits como "Omitido" arbitrariamente — el workaround `cf-pages-deploy-trigger.yml` (Deploy Hook) compensaba pero generaba **2 deploys por commit** (uno por la GitHub App, otro por el Hook).

Mobile Review + CF Access user resolve

Cierre del pendiente "Mobile Review" del Design Refresh 2026 (abierto desde el 18-04). Cuatro bloques entregados en un solo commit:

Limpieza pendientes Supercontexto (s33 LOG)

Sesión corta de barrido. 3 pendientes del backlog operativo cerrados en una sola sesión:

AI Eval tool (Fase 4 Gemini Lite)

**Contexto**: cierre de la Fase 4 del plan Gemini Lite Migration (sesión 33). El script `scripts/eval_ai_models.py` de CreaRack-Pro funcionaba pero solo lo usaba quien sabía el comando. Llevamos el comparador a una herramienta web para que cualquiera del staff pueda evaluar modelos en 30 segundos.

**Contexto**: dos frentes independientes en una sesión. Primero arreglar la búsqueda del workspace (no funcionaba, devolvía MOCK). Luego, evaluar Qwen 3.6 como alternativa a Gemini Flash y, según resultado, decidir qué hacer.

**Contexto**: sesión larga multi-frente que consolida lo aprendido en sesiones 28-31, codifica una nueva regla operativa y crea el primer agente Claude programado del ecosistema.

**Contexto**: tras sesión 30 quedaban 2 clusters Fase B abiertos (C auth/crypto + F Redis/huey). Edu eligió intentar Cluster C asumiendo riesgo, saltándose smoke local (Docker Desktop apagado) y STAGE.

**Bloque 1 — Pulido visual wiki**:

Sesión 25 Supercontexto + I+D plugins + optimización settings (Edu + Claude Opus 4.7)

Sesión 25 Supercontexto + I+D plugins + optimización settings (Edu + Claude Opus 4.7)

**Bloque 1 — Supercontexto (sesión 24)**:

**Arranque**: schedules Curator/Lint/Utility confirmados disparando automáticamente tras reset GH Actions de sesión 16. Primer día completo con cron. CF Pages estable.

Pulse tiempo real + Grafo vivo (Edu + Claude)

Pulse tiempo real + Grafo vivo (Edu + Claude)

Sesiones 1-4 (Edu + Claude Opus 4.7)

Sesiones 1-4 (Edu + Claude Opus 4.7)

**Sistema de Tareas del Workspace — rediseño completo** Partiendo de un CRUD básico, se añade toda la feature de gestión moderna:

**Fase 2 — Pre-commit bib_report_change check (en producción)**

**Sprint Supercontexto arrancado** Inspiracion: claude-obsidian (Supercontexto) + cerrar gap de "compounding knowledge" entre sesiones. Plan 3 fases con onboarding como vehiculo de entrega.

**Shell unificado en todas las páginas**

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.

Sin resumen disponible.