La vida de una ficha

Una ficha no es una instantánea única y congelada para siempre. Nace, se puede editar y se puede dar de baja. Lo que la hace fiable no es que nada cambie nunca, es que lo que no puede cambiar, nunca cambia, y todo lo que sí puede cambiar deja rastro en lugar de reescribir la historia en silencio.

Toda ficha responde a dos preguntas independientes, y confundirlas es el error más habitual al leer cómo funciona el registro:

Pregunta	Qué la decide
¿Esta ficha existe, y quién es su dueño?	Su estado de ciclo de vida: activa, a la espera de un dueño, o dada de baja.
¿Esta ficha es pública?	Su nivel: las fichas verificadas son públicas, las registradas son privadas. Ver Directorio.

Una ficha activa puede ser privada (el caso normal: una ficha gratuita Registrada). Una ficha también puede existir sin dueño todavía. Ninguno de esos dos hechos dice nada sobre si aparece en público, eso lo decide solo la verificación.

Casi todas las fichas se crean de la forma normal: alguien las registra por su cuenta y es su dueño desde el principio. Una ficha también puede existir sin dueño todavía, marcada como sin reclamar, a la espera de que la persona a la que se refiere (o alguien que actúe en su representación) se presente y tome el control mediante una reclamación. Una ficha sin reclamar no es una ficha menor ni provisional, tiene su número THB, su fecha y su hash igual que cualquier otra; simplemente no tiene dueño asignado hasta que alguien la reclama.

Tres campos están protegidos por una regla de la base de datos que rechaza cualquier modificación, también la del dueño o la de un administrador:

• El número THB (registry_code): la referencia externa de la ficha. Si pudiera cambiar, cualquier cita anterior dejaría de resolver.
• La fecha de registro (registered_at): si fuera editable, la ficha no probaría anterioridad de nada.
• El slug: el identificador de la URL pública de la ficha. Un slug cambiable permitiría que enlaces antiguos resolvieran a una ficha distinta.

Estos tres se protegen a nivel de base de datos, no solo en la interfaz: cualquier intento de cambiarlos se rechaza sin importar quién haga la petición ni por qué vía.

El hash de contenido funciona un poco distinto, y merece la pena ser precisos. Los campos descriptivos de una ficha, el nombre del avatar, su tipo, su ámbito, dónde opera y el nombre de la persona responsable, sí son editables por el dueño. Congelar el hash para siempre en el alta significaría que en cuanto corrigieras una errata en el nombre del avatar, el hash dejaría de coincidir con la ficha y parecería manipulado, para siempre.

En vez de eso, el hash es vigente: refleja siempre la última versión guardada de esos campos, recalculado automáticamente en cada edición que los toque. Lo que es de verdad permanente no es un hash congelado en la cabecera de la ficha, es el historial completo. Cada versión, empezando por la versión 1 en el alta, queda archivada para siempre en un registro de solo-añadir que nada puede actualizar ni borrar, cada una con su propio hash y los datos exactos que la produjeron.

El dueño puede dar de baja una ficha. Deja de aparecer en la búsqueda y en la API pública, pero su página sigue respondiendo, con un aviso fechado 410 Gone en lugar de un simple 404. La diferencia importa: un 404 dice «aquí no hay nada», un 410 dice «esto existió, y se retiró deliberadamente en esta fecha». El registro nunca borra un rastro en silencio, lo marca como cerrado. Y el número THB que tenía esa ficha se retira con ella, nunca se reasigna a otra cosa.

Una ficha que miras hoy se puede tomar al pie de la letra, porque las partes que importarían en una disputa, cuándo se declaró y por quién, no se pueden reescribir después de los hechos, y las partes que legítimamente cambian con el tiempo lo hacen a la vista, con cada estado anterior todavía disponible.