Tipo: DEFINICIÓN DE ROL · Especificación: §3.5, §8.9 · Revisión 1.0 · 2026-09-06 Edición en inglés: OPERATOR-ROLE.md · Publicado: sí
Dónde encaja esto.
civilization-backup-build-spec-v1.7.md§3.5 define la restricción; este documento define el rol que la satisface. Los procedimientos que el Operador sigue en la práctica están enOPERATOR-MANUAL-ES.md. El simulacro que pone a prueba esos procedimientos está enDRILL-01.md.
Un sistema que solo su constructor puede operar no es un respaldo. Es un pasatiempo con un único punto de falla, y ese punto de falla es una persona.
Esa frase es fácil de aceptar y difícil de aplicar, porque el constructor siempre puede operar el sistema, así que nada falla nunca de forma visible. El defecto permanece invisible hasta el día en que importa, que es exactamente la forma de todos los demás defectos que ha producido esta construcción: una verificación que reporta éxito, una tabla que se lee como una tabla, una respuesta segura y equivocada.
El Operador existe para hacer visible ese defecto de forma programada, en un simulacro, mientras el constructor todavía está disponible para corregirlo.
Una persona adulta capaz de seguir instrucciones paso a paso en Windows o en Ubuntu.
Ese es todo el nivel exigido, y es deliberadamente bajo. Todo lo que se escribe para el Operador se escribe a esa medida:
No se supone que el Operador sea técnico. No se supone que sepa qué es una suma de verificación, qué es un embedding, ni por qué hay dos copias de algo. Donde ese conocimiento haga falta para actuar con seguridad, el manual lo entrega en el punto de uso y no lo da por sabido.
Idioma. El inglés y el español son igualmente de primera clase. Los procedimientos existen en ambos, como dos documentos separados y no como uno mezclado. Una página bilingüe no le sirve bien a ninguno de los dos lectores bajo presión; el sitio público de este proyecto lo midió y separó sus idiomas por esa misma razón.
| cuándo | ||
|---|---|---|
| 1 | Encender el nodo y llegar a una búsqueda que funcione | cuando se necesite |
| 2 | Responder una pregunta desde el archivo, y leer el pasaje original antes de actuar sobre cualquier cifra | cuando se necesite |
| 3 | Conectar los discos fríos, ejecutar la verificación y rotarlos | cada tres meses |
| 4 | Ejecutar el simulacro de recuperación con las páginas impresas | cada año |
| 5 | Anotar cada paso del simulacro que no se pudo completar | durante el simulacro |
| 6 | Reconstruir el archivo en hardware nuevo desde el disco frío | después de una falla |
El punto 5 es el que la gente omite y es la razón de ser del simulacro. El resultado de un simulacro es una lista de defectos de la documentación. Un simulacro que no produce ninguno en su primera corrida es más probable que signifique que el constructor estaba parado demasiado cerca, y no que el documento sea perfecto.
Esta lista importa más que la anterior, porque un rol sin límites es un rol que nadie acepta y nadie ejerce.
El rol es genérico; una instalación no lo es. Cada instalación de este sistema registra a una persona frente al rol antes de su primer simulacro, en sus propios registros y no en este documento.
El entrenamiento es una pasada supervisada por el manual, en este orden, sobre un sistema que funciona, con el constructor presente y sin responder nada:
NOT IN ARCHIVE.Todo lo que el Operador no pueda hacer únicamente con las páginas se anota. El constructor responde preguntas solo después de que el paso se haya registrado como defecto, porque una pregunta respondida de viva voz es una página que nunca se escribe.
Un rol que sostiene una sola persona sin sucesor es el problema original con un paso adicional. Cada instalación nombra un sucesor al momento de designar. El sucesor no necesita entrenamiento hasta que suceda: el manual es el entrenamiento.