Candados: conexión de Supabase, tool sql y archivo de turnos

[ErickUser1]

Qué pasaba

Cosas que no pueden pasar dos veces al mismo tiempo, y pasaban.

1. Conexión de Supabase. La vuelta de autorizar, la preparación y la renovación del token guardaban la fila completa (INSERT OR REPLACE) desde una copia leída antes.
   • Segunda autorización con la base ya lista (dos pestañas o doble clic): se perdía la contraseña. Si venía de otra cuenta, la sala se cambiaba a un proyecto nuevo y vacío en esa cuenta.
   • La renovación del token podía regresar el proyecto a null si la preparación lo guardaba mientras tanto.
2. Tool sql. No tenía candado: dos agentes podían cambiar la base al mismo tiempo y el orden quedaba al azar. Tampoco quedaba registro de lo que hacía, así que los demás agentes no se enteraban.
3. Resumen de otros agentes, bug que ya existía. Filtraba solo por id de agente, y los ids se repiten en cada sala (agente-1). Por eso llegaban archivos de otras salas, con rutas absolutas.
4. Archivo de turnos, bug que ya existía y es grave. Dos agentes que empezaban turno a la vez compartían el nombre del archivo temporal. El segundo rename tronaba con ENOENT, nadie lo atrapaba, y se caía el server con todas las salas. Cuando no tronaba, un turno borraba al otro.

Cambios

• actualizarConexionSupabase: un UPDATE que cambia solo los campos que llegan. Lo usan la preparación, la renovación y la re-autorización. sqlite.ts y types.ts conservan sus saltos de línea CRLF.
• Callback:
  • Guarda en la misma fila que la preparación de la sala.
  • Si ya hay proyecto, solo renueva los tokens cuando esa cuenta puede ver el proyecto. Si no puede, no toca nada y el panel muestra el error, porque el GET ahora devuelve error.
  • Antes de volver a la sala espera a que quede guardado, con un tope de 3 segundos.
• Renovación del token: una a la vez por sala, releyendo la conexión adentro.
• sql: corre y escribe su migración bajo fileMutation.conCandado, el mismo candado de los archivos. La sala ve "esperando a agente-1 (migraciones)". Dos migraciones en el mismo segundo ya no se pisan.
• Resumen: los cambios a la base salen como cambió la base: crea-tabla-tareas, junto con la indicación de revisar con ver_base. Se filtra por la carpeta de la sala y las rutas salen relativas.
• Turnos: las lecturas y escrituras van en fila por sala, el temporal tiene nombre único, y no se escribe si nada cambió.
• demo:candados (18 casos) entra al CI.

Cómo se probó

• npm run typecheck, npm run build y las demos (providers, back, politicas, actividad, modo-de-sala, ver-base, candados, agentes-se-ven).
• Server real con Supabase simulado (dos cuentas, tokens que rotan), primero en main y luego en la rama:

Escenario	main	rama
2ª autorización, misma cuenta, base lista	contraseña perdida	se conserva
2ª autorización de otra cuenta	sala pasa a un proyecto nuevo en la cuenta B	sin cambios, y el panel explica
Dos agentes empiezan turno a la vez	el server se cae (ENOENT)	los dos contestan
5 startTurn a la vez (demo)	error, quedan 1 de 5	sin error, quedan 5

• No reproducido: dos renovaciones de token chocando. Con el simulador, la primera terminaba antes de que empezara la segunda, también en main. El candado de la renovación queda como protección y no está probado de punta a punta.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HJ5oT2Xm3VZMvbPAcgKbz4

---

Generated by Claude Code