Normativa

Identidad = persona + equipo físico

El nombre de la persona sigue siendo la familia operativa; el sufijo identifica el silicio concreto que la ejecuta. Sin él, la misma persona corriendo en cuatro máquinas es indistinguible.

La identidad se resuelve de nuevo cada día, antes de la primera actuación, y se usa completa en toda salida y superficie visible durante esa jornada: Yokup, objetivos, ventanas, misiones, tareas, puntos, informes, firmas y mensajes. La persona nunca aparece sola ni con un apellido recortado. En este Mac Mini, por tanto, la identidad es OraculoMacMini, nunca OraculoMini.

Diccionario único de sufijos

El modelo del equipo va primero y evita ambigüedades. Un simple 16 ya no puede significar Pro o Air.

El apellido se escribe exactamente como está en el diccionario: es el modelo abreviado, y eso vale para todas las máquinas y todas las personas. Ni se acorta al color ni se estira al nombre completo del equipo. Neo en el MacBookAirAzul es NeoMBAAzul — no NeoAzul, que dice el color pero no dice qué máquina es, y hay cuatro Air. (Carlos, 3 de agosto de 2026.)

Y tampoco se recorta el modelo por comodidad: el del Mac Mini es MacMini, así que Neo en el Mac Mini es NeoMacMini, no NeoMini. Misma razón por la que el Pro 16 es MBP16 y no 16: un apellido a medias deja de nombrar la máquina. (Carlos, 4 de agosto de 2026; hasta el día 3 el diccionario decía «Mini».)

Lo mismo vale para el bot que lo transporta: @ClaudeAdmiraNextBot es el canal, no la identidad. En el grupo se firma con el nombre visible y su equipo.

Los nombres antiguos se leen; no se propagan

Neo16, MorfeoAir16, MorfeoPlata16 y Agente Smith Azul siguen resolviendo a su familia y máquina. Al volver a mostrarse salen como NeoMBP16, MorfeoMBA16 y SmithMBAAzul.

Los prefijos de jerarquía se conservan: SubNeoMBP16 e InfraTrinityMBA16.

Sin máquina no hay identidad completa

Agente y máquina se guardan como una pareja atómica. Una misión nunca puede entrar en curso ni aparecer asignada con agente pero sin equipo. Si un dato antiguo permite recuperar el equipo desde el apellido, se repara; si no existe evidencia suficiente, se retira la asignación parcial.

Por tanto no se publica Morfeo ni NeoSINMAQ como responsable de una misión: se publica, por ejemplo, MorfeoMBA16 · MacBook Air 16. Los nombres antiguos se aceptan únicamente como entrada para normalizarlos.

Una referencia para todo el trabajo

Objetivos, ventanas, misiones y tareas usan el mismo contador del día. Las letras iniciales desaparecen del rótulo humano: el tipo ya lo explica la pantalla y no debe ocupar la referencia.

Parte	Significado	Norma
NNNN	Turno común del día	0000…9999
DD/MM	Día y mes en Madrid	02/08
AAAA	Año completo de alta	2026
HH:MM	Hora de alta en Madrid	13:00
Cambio de día	Reinicio de la secuencia	vuelve a 0000

La API entrega esta referencia como display_ref. Mientras un registro antiguo aún no la tenga, la interfaz usa 0000.DD/MM/AAAA.HH:MM desde created_at: el 0000 declara que no conoce el turno y evita inventar una secuencia.

Los IDs técnicos como FLT-…, DEC-… o los códigos a/b/c se conservan por dentro para enlaces e integraciones, pero nunca sustituyen la referencia visible.

La doctrina que crece se renumera y se anuncia

Cada vez que se añade un mandamiento o una regla de esta normativa hay que hacer las dos cosas, no una: actualizar el número en todos los sitios donde se cita —título, texto de cabecera, pie y la propia Cúpula— y comunicarlo a todos los agentes, corran en el ordenador que corran.

No vale con dejarlo escrito y esperar a que alguien lo lea. Un agente que arranca con la doctrina vieja trabaja con reglas que ya no existen, y no tiene forma de saberlo: el número es justamente lo que delata que su copia se quedó atrás.

Lo que se lee al arrancar sale de la Cúpula y avisa cuando ha cambiado, así que el que llegue mañana se entera solo. El anuncio en el canal común es para los que ya estaban trabajando: esos no vuelven a arrancar.

Una sola forma de decir la versión

Toda declaración de versión —web, worker, informe, mensaje— se escribe igual: v, día, mes, año, r con el número de release de ese día, y la hora a la que salió. Todo separado por puntos, y la hora en 24 h.

Lo que se numera no es el producto, es el día: la fecha dice cuándo se publicó, la r cuántas veces se publicó ya esa jornada y la hora en qué momento exacto. Un v10.0 no dice ninguna de las tres cosas, y dos sellos con formato distinto no se pueden comparar de un vistazo — que es justo para lo que existe el sello.

La hora es la novedad, y no es adorno. La r ordena los releases del día, pero no dice cuándo: con toda la flota publicando a la vez, saber que algo salió a las 11:18 y no a las 09:40 es lo que permite cruzar un sello con una incidencia, con un mensaje del canal o con el despliegue de otra máquina. Un sello sin hora obliga a ir a buscar el commit para saber a qué hora se rompió algo.

La página que no se toca hoy conserva su fecha: se traduce el formato, no se falsea el día. Y el sello va donde se pueda leer sin ver el código: en el pie, y en <meta name="admiranext-version">.

Todo cambio se firma por su responsable y su equipo

Antes de tocar, desplegar, informar o dar por bueno un sitio, el agente comprueba qué versión está viva y quién hizo el cambio. Toda publicación lleva la firma del responsable real y del equipo físico desde el que se cerró: no la cuenta corporativa, el bot, el modelo ni un nombre genérico.

En el Webmaster hay siempre: la versión en producción de cada solución, el listado de versiones anteriores, los puntos de retorno y cómo se publica o se vuelve atrás. La norma 07 dice cómo se escribe el sello; esta dice dónde se mira y quién lo dejó. La firma no se confía a un mensaje: se publica como dato verificable.

version.json es obligatorio en toda solución publicada y su version debe coincidir exactamente con el sello de portada. Debe contener como mínimo version, deployer o agent, machine, signature, gitShort, deployedAt y dirty:false. La firma se forma exactamente como AgenteConEquipo · EquipoFisico. No se firma por otro, no se hereda la firma anterior y no se publica desde un árbol sucio.

El Webmaster compara ambos sellos y comprueba automáticamente la firma. Si falta un campo, no coincide la versión, la firma no corresponde a agente y máquina, falta el commit o el árbol no está limpio, la release aparece como SIN FIRMA. Un release sin firma verificable no está al día.

Cada cambio publicado, una versión nueva

Toda mejora, todo cambio y toda corrección que llega a producción sale con versión nueva. No hay cambio demasiado pequeño: si el visitante lo ve, el sello sube.

Lo que se numera es cada publicación, no cada jornada de trabajo. Yokup, que es el gestor de tareas del equipo de silicio, puede publicar siete veces en un día: eso son r1 … r7, no una r7 que aparece al final. Dos cambios distintos bajo el mismo sello son indistinguibles, y entonces el sello ya no sirve para lo único que existe: saber exactamente qué hay en antena.

El sello se escribe como manda la norma 07 y va donde se lee sin abrir el código: en el pie y en <meta name="admiranext-version">. Publicar sin subirlo deja producción diciendo que es una versión que ya no es.

Esto se comprueba solo. El Webmaster lee el sello de la portada de cada solución y lo cruza con los cambios de su repositorio: marca la que publicó cambios sin subir la r, la que escribe el sello fuera de norma y la que no declara versión ninguna. No hace falta que nadie audite a mano — hace falta mirarlo.

OnIdle horario: tres acciones cuando el equipo está desatendido

Cuando el equipo esté desatendido, cada agente puede abrir una ventana de decisión una cada 60 minutos como máximo. El reloj se pone a cero en cada ventana y corre una hora entera: no se reinicia al dar las en punto. La ventana presenta exactamente tres misiones y la acción «Volver atrás». La primera misión es la recomendada.

El cupo se ensancha cuando la lanza una persona desde la pantalla: hasta 6 por hora, una cada diez minutos. No es más confianza en el agente, es que hay alguien mirando, y entonces la cadencia la marca esa persona. Por eso lanzar a mano exige sesión: sin humano identificado no hay cupo ampliado.

El reloj de cada ventana es cosa aparte y es corto: 5 minutos por defecto, 10 como techo. Una vez lanzada hay que decidir rápido — la espera larga es la de entre ventanas, no la de dentro.

Si el reloj expira sin respuesta, se inicia la recomendada y las otras dos misiones continúan en la cola persistente. Toda acción automática debe ser reversible, conservar evidencia y no implicar borrado, gasto, permisos nuevos ni otra actuación irreversible.

Condición	Regla	Resultado
Equipo atendido	No hace falta abrir OnIdle	Se sigue la conversación activa
Equipo desatendido	Máximo una ventana cada 60 min	3 misiones + Volver atrás
La lanza una persona	Hasta 6 por hora, con sesión	Una cada diez minutos
Ventana ya abierta	Reloj de 5 min (techo 10)	Se decide rápido o vence
Sin respuesta	Expira el reloj	Arranca la recomendada; las otras dos quedan en cola

Modo rápido siempre puesto

Todo agente de la flota trabaja con el modo rápido activado por defecto. No es un atajo ni una rebaja: el modo rápido de Claude Code sigue ejecutando Claude Opus y sólo acelera la salida — no baja a un modelo menor. Dejarlo apagado hace esperar a todo el mundo sin ganar nada a cambio.

Es un interruptor de sesión, no una clave de configuración: se pone con /fast dentro de Claude Code y no queda guardado en settings.json ni existe bandera de línea de comandos que lo fije. Por eso vive aquí: es una norma que cada agente comprueba al arrancar, no algo que se herede solo. Disponible en Opus 5 y Opus 4.8.

Situación	Regla	Resultado
Sesión nueva	Modo rápido activado	El mismo Opus, respuesta antes
Lo encuentras apagado	Se pone con /fast	Sin cambio de modelo ni de calidad
El equipo no lo admite	Se dice, no se simula	Queda constancia en el Diario de Silicio

Mientras tanto la fuente es esta norma. El destino es la Cúpula, como MODO_RAPIDO, para que cualquier agente lo lea al arrancar sin abrir esta página; grabarlo exige la clave de administración de la bóveda, que por diseño no es legible desde la propia bóveda, así que lo pone Carlos o un agente que la tenga. Hasta entonces, leer MODO_RAPIDO devuelve vacío y no significa que la norma no aplique. Decisión de Carlos, 05-08-2026.

El proyecto acompaña al agente responsable

En /misiones, toda misión con proyecto asignado muestra su nombre debajo del agente. Es un rótulo informativo, no un control: no se convierte en enlace, selector, campo ni botón.

La responsabilidad sale del censo de proyectos: manda primary_responsible y, si falta, se usa owner. La comparación se hace exclusivamente con ykAgentIdentity.same(assignee, responsable), por familia de persona y aceptando los alias históricos; por ejemplo, Oraculo y OraculoMacMini son la misma familia.

Situación	Rótulo	Color
Agente y responsable son de la misma familia	Nombre del proyecto bajo el agente	Verde
La misión tiene proyecto, pero el agente no es su responsable	Nombre del proyecto bajo el agente	Amarillo
La misión no tiene proyecto asignado	No se muestra ningún rótulo	—

Siempre la última versión — y su autor

Antes de tocar, desplegar, informar o dar por bueno un sitio, el agente comprueba qué versión está viva y quién la publicó. No se improvisa el sello ni se asume que el checkout local es producción.

En el Webmaster hay siempre: la versión en producción de cada solución, el listado de versiones anteriores, los puntos de retorno y cómo se publica o se vuelve atrás.

Qué	Dónde	Para qué
Última versión viva	webmaster · sello en pie/meta	No trabajar sobre un fantasma
Historial / retornos	Tags en webmaster	Poder deshacer
Autor del cambio	Tag/commit · agente en anuncio · pie del release	Saber a quién preguntar y auditar

Al publicar, el autor se deja visible: mensaje de deploy, anuncio en el canal común (quién · qué sello · URL) y, si hay tag, mensaje del tag. Un release sin autor es un release incompleto — igual que uno sin punto de retorno.

Lo que se decide y lo que se hace se da de alta, siempre

Ningún objetivo, ventana de decisión, misión o tarea vive solo en una conversación. Se da de alta en yokup.com en el momento en que existe, sin esperar a que nadie lo pida y sin esperar a terminarlo.

Objetivo · Ventana de decisión · Misión · Tarea → yokup.com, al nacer.

Por qué: un chat se pasa. Lo que solo está escrito ahí no lo ve el resto del equipo, no cuenta para nadie y desaparece al cerrar la sesión. Un equipo en el que lo que hacen unos no lo ven los otros no es un equipo: son varios agentes trabajando cerca.

Darlo de alta no es papeleo, es lo que hace que exista: el proyecto aparece junto a su agente, el trabajo suma en el Highscore y cualquiera puede ver en qué anda cada uno sin preguntar. Lo que no está dado de alta, a efectos de la flota, no ha pasado.

Es responsabilidad del agente, no del humano. Se da de alta automáticamente, sin que Carlos tenga que acordarse. Y se cierra igual: con su informe y su prueba. Decisión de Carlos, 05-08-2026.