Gobernanza · La cola del dueño (S5)
Hay decisiones y credenciales que sólo el dueño puede mover: logins, tokens de APIs, precios, apetito de riesgo de marca, sí/no a un producto nuevo. Si viven en tu cabeza o en un chat, frenan todo sin que nadie vea el freno.
La forma
Un archivo, una tabla, una fila por pendiente:
| campo | qué es |
|---|---|
| qué | el pendiente, en una línea |
| desde | fecha/hora en que se abrió (el reloj) |
| qué destraba | qué se libera cuando se resuelve — medido o [no testeado] |
| criterio de cierre | observable: cómo se sabe que quedó resuelto (un comando, no una sensación) |
Reglas: un pendiente que no está en la cola no existe; lo cerrado se anota con fecha, no se borra (el historial de latencias es dato).
Lo que la latencia medida enseñó
La fila más cara del caso real estuvo 16 horas abierta mientras la operación producía a máxima velocidad — 6 productos y 54 URLs creados que no podían salir a ningún canal. El desbalance no era de trabajo, era de S5: el sistema entero orbitaba una credencial.
El default que falta casi siempre
Cada fila debería llevar "si no decido en 24h, se hace X" — sin default, la cola registra la presión pero no la libera. Es el gap más barato de cerrar y el que menos sistemas cierran.
En el caso real ninguna de las 14 filas lo tiene [testeado: grep de "24h" y "default" sobre COLA_JOSE.md → 0 coincidencias]. La versión anterior de esta página decía además que el default estaba "prometido"; eso no se pudo sostener: la única fuente era Fase 4 · Gobernanza, que a su vez apunta acá. Dos páginas del mismo wiki citándose entre sí no son dos fuentes — es la misma afirmación dos veces, que es exactamente el modo de falla que Probe over report nombra para los reportes ajenos. La recomendación se mantiene (el default sigue siendo el gap más barato); lo que se cae es el "estaba prometido".
El criterio de cierre también puede estar mal
Este es el modo de falla que una cola bien llevada no ve venir, y el caso real lo tiene documentado: la fila del token de Cloudflare se abrió con el criterio "wrangler whoami deja de dar error 9109". Se resolvió midiendo otra cosa — wrangler pages deploy funcionaba, y se deployaron dos proyectos verificados contra lo servido. whoami seguía fallando porque pega a /accounts, el único endpoint con restricción de IP: el criterio original medía el endpoint equivocado y habría mantenido la fila abierta sobre un bloqueo inexistente [testeado: COLA_JOSE.md fila 13, cerrada con criterio corregido].
La lección no es "escribí mejores criterios" — eso es una prohibición y no produce nada. Es esta: cuando una fila lleva mucho tiempo abierta, sospechá del criterio antes que del dueño. Y cuando se corrige, se escribe criterio corregido con el motivo al lado, no se cierra en silencio: una fila que cambia de criterio sin dejar rastro convierte la cola en un registro que no se puede auditar hacia atrás.
Una cola federa, no copia
La fila más larga del caso real no contiene decisiones: contiene un puntero a otro registro canónico que vive fuera del repo, con la lista de sus filas y el comando que las mide. Esa forma es deliberada y conviene copiarla, porque el alternativo —resumir el registro ajeno dentro de la cola— deriva: al auditar esa fila contra su registro canónico aparecieron numeraciones distintas para la misma decisión y filas nuevas que el espejo no tenía [testeado: diff entre la fila-espejo y el registro canónico, 2026-08-30].
Regla que sale de ahí: una fila puede apuntar a un registro externo, nunca resumirlo. El puntero envejece bien; el resumen envejece mal y nadie lo nota, porque leer el resumen se siente como leer el registro.
La disciplina de cierre
Cuando el dueño reporta "listo": se verifica con un probe propio antes de marcar ✅ sin reservas (Probe over report) — "Jose reporta X activo" y "verificado con comando" son dos estados distintos y la tabla los distingue.