# DIGITAL OPTIMUS — NORTE MAESTRO DEL PROYECTO

**Versión:** 2.0 — prioridad absoluta de autorreparación y transición posterior a VPS  
**Fecha de anclaje original:** 24 de octubre de 2026  
**Última decisión rectora del creador:** 27 de octubre de 2026  
**Naturaleza:** Carta rectora única para arquitectura, desarrollo, auditoría, autorizaciones, prioridades y despliegue.  
**Objetivo del documento:** Mantener a todo el proyecto alineado con su propósito. **No certifica capacidades aún no demostradas.**

> **MANDATO ACTUAL Y PRELACIÓN:** Desde el 27 de octubre de 2026 la única misión de desarrollo activa es lograr y demostrar la **autorreparación integral de Digital Optimus dentro del alcance autorizado**. No iniciar nuevas rutas de desarrollo, productos, comercialización ni despliegue VPS antes de superar la compuerta de aceptación de autorreparación definida en este documento. Las tareas de soporte imprescindibles para esa misión —estabilidad del Brain, seguridad, supervisión, pruebas, respaldos— sí están permitidas. **Una vez superada la compuerta, iniciar inmediatamente la preparación y contratación autorizada de un VPS, y desplegar el Brain para que pueda trabajar desde la nube mientras continúa su evolución.**

**Precedencia documental:** Si una prioridad anterior, un informe de Antigravity o un plan técnico contradicen este mandato, prevalece esta versión del Norte Maestro. Los informes de pruebas son evidencia, no sustituyen las reglas ni pueden declarar éxito por sí solos.


---

## 1. MISIÓN PRINCIPAL E INNEGOCIABLE

**Digital Optimus es el núcleo inteligente y ejecutivo que debe razonar, investigar, planificar, usar herramientas, crear y mantener productos, diagnosticar y reparar sus propias funciones, coordinar operaciones empresariales y buscar oportunidades comerciales legítimas para financiar su crecimiento.**

No es principalmente un IDE, un chatbot decorativo, un diseñador de interfaces ni un conjunto de servicios sin conexión. Debe terminar misiones de extremo a extremo y entregar resultados reales y verificables.

**Regla superior:** *Primero Optimus; después, los productos de Optimus.*

## 2. ARQUITECTURA Y RESPONSABILIDADES

### Digital Optimus / Brain
- Centro de razonamiento, planificación, coordinación, decisiones, memoria, continuidad, registro de capacidades, verificación y control de autorizaciones.
- Debe poder recibir instrucciones por una vía propia mínima (chat original, consola o API), aun cuando Optimus Developer no exista o no esté disponible.
- No debe depender de ChatGPT, Antigravity ni Optimus Developer para realizar sus tareas rutinarias una vez activado el núcleo autónomo.

### Motor de herramientas / efectores
- Capa ejecutora compartida, separada del razonamiento del Brain, que opera archivos, terminal, navegador, pantalla, teclado/ratón y demás capacidades según permisos.
- El Brain pide acciones, recibe resultados verificables y decide cómo continuar. No crear sistemas de manos duplicados para cada producto.

### Autodiagnóstico y autorreparación
- Mientras el Brain esté operativo, debe detectar errores, rastrear causas desde el origen hasta el resultado final, reparar fallos autorizados de sus propios componentes o productos, probar la corrección, conservar evidencia y revertir cambios defectuosos.
- Si el Brain queda detenido o congelado, actúa un supervisor externo pequeño e independiente para recuperar su disponibilidad. Este supervisor **no es Developer** y no sustituye la autorreparación del código.
- Las reparaciones de archivos centrales protegidos, cambios de seguridad, infraestructura crítica o gastos requieren el nivel de autorización configurado.

### Productos creados o mantenidos por Optimus
- **Optimus Developer:** cliente visual/producto especializado para programación. Sin cerebro autónomo duplicado. El Brain lo crea, repara, mejora y mantiene.
- **Avatar Live:** producto para demostraciones, presentaciones, interacción por voz/imagen y futuras transmisiones en TikTok y otras plataformas, respetando reglas de esas plataformas.
- **Página web oficial:** presencia pública, catálogo, comercialización y servicios.
- **Otros productos:** diseño gráfico, generación de imágenes, sitios web, aplicaciones y servicios conforme a oportunidades reales.
- Ningún producto individual es prerrequisito para que el Brain trabaje.

### Administrador ejecutivo empresarial
- Investigar mercados y modelos de negocio, detectar necesidades, comparar oportunidades, calcular costos, riesgos y márgenes, diseñar planes comerciales, crear productos y coordinar operaciones autorizadas.
- Priorizar productos con oportunidades reales de ingreso antes de extender indefinidamente infraestructura sin usuarios ni ventas.
- Llevar control de gastos, presupuestos, retornos y evidencia; no inventar ingresos, clientes, ventas, asociaciones o resultados.
- Compras, contratos, transacciones, publicación comercial y compromisos externos se realizan con permisos y límites definidos por el creador.

## 3. ORDEN OBLIGATORIO DE PRIORIDADES — SIN DESVÍOS

**P0-AR: Autorreparación propia es la única prioridad de desarrollo activa hasta su aceptación.** Que Optimus converse, restaure historial o tenga módulos implementados no autoriza a declararlo listo para trabajar autónomamente.

| Orden | Capacidad | Demostración exigida / decisión |
|---|---|---|
| **P0-AR / 1** | Brain estable e independiente | API/Workbench propio usable; proceso, HTTPS y datos protegidos; sin depender de Developer |
| **P0-AR / 2** | Detección real y trazado del circuito | Incidente real → evidencia → causa raíz; puntos `PASS/FAIL/NOT_REACHED`; sin inferir que una importación significa conexión operativa |
| **P0-AR / 3** | Razonamiento y propuesta autónoma | Optimus propone un parche para una falla propia no resuelta de antemano, sin que el operador le entregue la solución |
| **P0-AR / 4** | Sandbox aislado y ejecución verificable | Parche sobre candidato; aislamiento probado de producción, credenciales, red y efectos colaterales |
| **P0-AR / 5** | Verificación y reversión | Tests focales y regresiones realmente ejecutados; evidencia de PASS, fallo bloqueado y rollback válido |
| **P0-AR / 6** | Reparación propia autorizada de extremo a extremo | Detección → diagnóstico → parche → prueba → autorización según riesgo → aplicación al objetivo permitido → verificación final y recuperación de misión |
| **P0-AR / 7** | Recuperación ante caída del Brain | Supervisor externo independiente detecta caída/bloqueo, recupera disponibilidad sin bucles de reinicio ni modificar código sin autorización |
| **P0-AR / 8** | Continuidad y seguridad | Progreso persistente, protección de memoria y dispositivos, límites de intentos, no inventar PASS, trazabilidad y reanudación controlada |
| **P1 — solo tras P0-AR** | VPS y trabajo en nube | Iniciar contratación con aprobación del creador, desplegar de modo seguro y demostrar el Brain trabajando desde el VPS |
| **P2 — solo después de nube operativa** | Creación de productos, servicios, investigación comercial | El Brain crea y mantiene productos con autorización, recursos y evidencias reales |
| **P3 — evolutivo** | Developer, Avatar Live, web, modelos mayores | Productos y mejoras subordinados al Brain, sin duplicar su inteligencia |

**No queda autorizado adelantar P1/P2/P3 para «ganar tiempo» mientras P0-AR esté pendiente.** Solo se permite investigación mínima imprescindible para evitar un bloqueo de seguridad o planificar la transición después de aprobar P0-AR.

## 4. COMPUERTA DE ACEPTACIÓN DE AUTORREPARACIÓN — CONDICIÓN PARA VPS

La expresión «autorreparación por completo» significa aquí **capacidad completa y comprobada para un alcance declarado y autorizado**; no significa poder solucionar matemáticamente cualquier problema o reparar de forma segura todo fallo concebible. Los fallos fuera de alcance deben detectarse, contenerse y escalarse sin inventar una solución.

### 4.1 Condiciones obligatorias de aceptación

1. **Entrada real:** un error funcional auténtico llega al circuito desde una entrada de misión o monitor, no solo desde una llamada directa artificial a una función de prueba.
2. **Detección y causalidad:** registro reproducible del fallo inicial, traza desde origen a destino, causa raíz localizada y diagnóstico respaldado por evidencia.
3. **Autonomía de reparación:** el propio Brain/motor de razonamiento genera la corrección sin recibir `explicit_patch`, `custom_reasoner` que entrega la respuesta, ni solución codificada para el caso. Diferenciar explícitamente simulación de razonamiento real.
4. **Ejecución protegida:** crear copias/candidatos aislados; no escribir fuera de su raíz; no heredar claves API, tokens, bases de producción o acceso no autorizado a red/procesos. Un `cwd`, `PYTHONPATH` o interceptar solo `urllib` no constituyen aislamiento de sistema operativo.
5. **Verificación física:** prueba inicial `FAIL` → parche propuesto → tests focales y regresiones `PASS` **con ejecución registrada**; cero tests no equivalen a PASS para componentes propios.
6. **Promoción según autorización:** las modificaciones permitidas de bajo riesgo pueden ejecutarse de forma automática solo dentro del alcance previamente aprobado y con respaldo. Código central protegido, permisos de seguridad, secretos, infraestructura, publicación, contrataciones y gasto exigen aprobación del creador.
7. **Rollback y contención:** prueba real de reversión si el parche falla, hashes originales restaurados y circuit breaker ante errores repetidos, duplicados o recursivos.
8. **Continuidad:** persistir incidente, evidencia, versión y estado de misión; sobrevivir al cierre/reinicio controlado y reanudar únicamente si identidad y autorización coinciden.
9. **Disponibilidad independiente:** el supervisor externo pequeño verifica salud real y recupera procesos detenidos/colgados sin reemplazar el razonamiento de reparación ni generar reinicios indefinidos.
10. **Demostración independiente:** PowerShell/Python controlado por el creador verifica por fuera del propio sistema el resultado, los hashes, la integridad SQLite y la ausencia de modificaciones fuera del alcance.

### 4.2 Matriz mínima de escenarios

| Caso | Prueba que debe demostrarse | Requisito de cierre |
|---|---|---|
| AR-E2E-01 | Defecto funcional permitido en componente propio de Optimus | El motor lo diagnostica, genera parche original y lo verifica de extremo a extremo |
| AR-E2E-02 | Segundo defecto distinto, sin parche preprogramado | Repite el recorrido; demuestra que no es un caso rígido preparado para pasar |
| AR-SAFE-03 | Objetivo protegido o solicitud fuera de ámbito | Se rechaza o solicita aprobación, sin escribir en producción |
| AR-ROLLBACK-04 | Candidato incorrecto, prueba fallida o promoción fallida | Rollback probado, hashes restaurados, no PASS ficticio |
| AR-RECOVERY-05 | Brain detenido/bloqueado de forma controlada | Supervisor externo restaura disponibilidad; sin recurrencia infinita |
| AR-CONT-06 | Cierre/reinicio y recuperación de misión/incidente | Persistencia verificada sin pérdida de memoria ni reanudación duplicada |
| AR-ISOLATION-07 | Intento de escapar del sandbox, acceder a red o credenciales | Bloqueo y evidencia de ausencia de efectos no autorizados |

**Compuerta `AUTORREPARACION_LISTA_PARA_VPS=TRUE`:** todos los casos obligatorios `PASS` físico y reproducible, riesgos residuales declarados, rollback disponible, cero cambios no autorizados, Brain estable, autorización expresa del creador para entrar a VPS. Si alguno está `FAIL`, `PARTIAL`, `NOT_REACHED`, `BLOCKED` o `NOT_VERIFIED`, la compuerta permanece cerrada. Nunca transformar una prueba simulada en certificación real.

### 4.3 Etapas permitidas hasta superar la compuerta

- **Etapa A — Preservar:** el Brain de producción continúa atendiendo normalmente; `brain_safe_bootstrap.py` mantiene neutralizada la autorreparación mientras no esté verificada; TEITAN y Developer permanecen fuera de este trabajo.
- **Etapa B — Diagnóstico integral:** usar AR-71/AR-72/AR-73B como referencias, localizar causas reales, defectos hermanos, contratos entre etapas y test faltantes en una sola matriz consolidada.
- **Etapa C — Reparación del sistema de reparación en laboratorio:** aplicar cambios quirúrgicos a copias aisladas, con límites explícitos; comprobar no escape de sandbox y pruebas independientes. No confundir cambio de laboratorio con cambio de producción.
- **Etapa D — Prueba autónoma real:** inyectar fallo reversible de componente propio, ejecutar motor sin suministrar el parche, verificar `FAIL → PASS`, prueba negativa y rollback.
- **Etapa E — Integración protegida:** solo tras evidencias anteriores, promover cambios autorizados con respaldo, verificar hashes, regresiones y conexión real con Brain; habilitación gradual por niveles de riesgo, nunca apagando las protecciones por comodidad.
- **Etapa F — Cierre:** emitir matriz independiente y decisión `GO/NO_GO` para VPS, con consentimiento del creador.

**Excepción:** una reparación humana urgente para preservar disponibilidad o evitar pérdida de datos puede realizarse como contención, con respaldo y evidencia. No cuenta como autorreparación autónoma.

## 5. MÉTODO PERMANENTE DE TRABAJO CON ANTIGRAVITY

Mientras Optimus todavía no pueda hacerse cargo de sus modificaciones, **Antigravity es una herramienta temporal de implementación, no el motor definitivo de Optimus**.

**Ciclo de misión obligatorio:**

1. **Antigravity entrega informe de cierre:** cambios realizados, evidencias, tests, hashes, limitaciones y lo no alcanzado.
2. **ChatGPT + creador contrastan el informe con este Norte Maestro:** ¿acerca al Brain al trabajo autónomo o distrae hacia productos secundarios?
3. **Auditoría de circuito integral relacionada con la misión:** seguir la ruta entrada → planificación → efecto → verificación → resultado. Consultar código y evidencia física desde PowerShell. Evitar repasar indiscriminadamente componentes ya verificados que no fueron afectados.
4. **Inventario consolidado de faltantes:** registrar conexiones ausentes, componentes no implementados, errores, pruebas insuficientes y bloqueos; clasificar `P0/P1/P2` y `PASS/FAIL/PARTIAL/NOT_REACHED/NOT_VERIFIED`; marcar dependencias y archivos afectados.
5. **Un único prompt maestro por ronda de corrección:** incluir todo el inventario accionable del alcance, organizado por etapas y dependencias, con archivos permitidos/prohibidos, hashes, pruebas focalizadas, criterios de aceptación, rollback y condiciones STOP. No convertirlo en una edición indiscriminada o riesgosa.
6. **Antigravity implementa y entrega otro informe final:** no declarar PASS sin pruebas o evidencia; no repetir indefinidamente comandos bloqueados.
7. **PowerShell valida físicamente:** integridad, funcionamiento de extremo a extremo, ausencia de regresiones del alcance afectado, evidencia conservada.
8. **Nuevo inventario y nueva ronda solo si existen faltantes reales:** repetir hasta lograr la Alpha mínima operativa. Al alcanzar el objetivo funcional, detener la expansión de infraestructura y poner a Optimus a trabajar.

**Aplicación durante P0-AR:** todos los prompts y rondas de Antigravity deben contribuir directamente a la compuerta de autorreparación. No encargar mejoras cosméticas, nuevos productos, interfaces, marketing ni desarrollo comercial. Cada prompt es copiable y autocontenido, con archivos permitidos/prohibidos, barreras, hashes y condiciones STOP.

**Regla de eficiencia:** una misión = un cierre verificable; no auditar desde cero en cada vuelta. Un prompt maestro puede reunir múltiples correcciones, pero sus etapas deben tener límites, puntos de parada y pruebas independientes. Si surge un problema grave inesperado, detener cambios y actualizar el inventario antes de continuar.

## 6. CONTROL ANTIDESVÍOS — PROHIBICIÓN DE RUTAS SECUNDARIAS

Hasta `AUTORREPARACION_LISTA_PARA_VPS=TRUE`, cada paso debe satisfacer **ambos** requisitos:

1. ¿Acerca directamente a una condición aún pendiente de la compuerta P0-AR o preserva la seguridad/disponibilidad indispensable del Brain?
2. ¿Tiene evidencia real, prueba verificable y un alcance limitado, sin duplicar módulos ni introducir trabajos ajenos?

Si cualquiera es negativo: **APARCAR** la tarea. No desviarse hacia Optimus Developer, Creator Workbench estético, Avatar Live, sitios web, nuevas capacidades comerciales, nuevas infraestructuras no esenciales o refactorizaciones innecesarias. Optimus Developer es un **producto cliente**, nunca el cerebro ni la puerta obligatoria de entrada.

Si aparece un bloqueo grave inesperado: detener la aplicación, preservar evidencias, añadirlo al inventario consolidado y corregir la causa real; no encadenar veinte parches o auditorías globales.

**Frase obligatoria en cada cierre:** `ALERTA_DESVIO=SI/NO — MOTIVO=... — REGRESAR_A=P0-AR`.

## 7. PRIORIDAD ACTUAL Y CHECKPOINT — 27 DE OCTUBRE DE 2026

**Estado conocido al actualizar el documento (no equivale a certificación P0-AR):**

- Migración a computadora nueva: Brain local activo en `127.0.0.1:8443`, Workbench `0.1.0-alpha.69` instalado, autenticación y chat visual observados. Restauración de frase anterior entre reaperturas de Workbench observada; memoria larga y persistencia de reparación todavía no certificadas.
- HTTPS validado con `https://localhost:8443`; el certificado **no** es válido para el literal `127.0.0.1`. Mantener el cliente usando `localhost` sin quitar verificación TLS.
- `brain_safe_bootstrap.py` bloquea deliberadamente importaciones de autorreparación y neutraliza el monitor continuo en producción. **No retirar el bloqueo sin superar etapas de aislamiento e integración.**
- AR-71: 29 módulos de autorreparación localizados; Brain funcionando; TEITAN apagado; 6 hashes centrales intactos.
- AR-72: informe de análisis estático, 33 archivos Python, 438 definiciones, 106 aristas/importaciones relevantes, 38 pruebas candidatas, 0 errores de sintaxis. Hallazgos estructurales, no PASS de ejecución real.
- AR-73B: 76 archivos de fuentes/pruebas copiados; 29 módulos y 39 archivos de prueba; `continuity.db` pasó `PRAGMA quick_check=ok` en modo lectura. El hash de una DB viva **no debe compararse** con un hash anterior a nuevas conversaciones; no restaurarla sin motivo comprobado.
- AR-74: inspección del código encontró riesgos que deben ser confirmados y resueltos antes de ejecutar candidatos: pertenencia de rutas por prefijos de texto, pruebas que podrían salir del candidato, validación de regresión vacía, y control de red parcial. **La corrección autónoma real E2E está PENDIENTE; el prompt de laboratorio no equivale a una prueba ejecutada.**

**Siguiente misión autorizada:** concluir el circuito de autorreparación en laboratorio con una matriz única de defectos, pruebas negativas y generación no preprogramada de parches; luego validar físicamente desde PowerShell. La protección del Brain productivo continúa.

**Fuera de alcance ahora:** desarrollar/migrar Developer, nuevas páginas, ventas, Avatar Live, migración prematura a nube, nuevas características que no sean necesarias para P0-AR.

## 8. PLANTILLA BREVE PARA REVISAR CADA INFORME

**MISIÓN:** [objetivo y fecha]  
**OBJETIVO PRINCIPAL DEL BRAIN AL QUE CONTRIBUYE:** [P0/P1/P2]  
**EVIDENCIA REAL:** [archivos, logs, hashes, resultados E2E]  
**FUNCIONES PASS:** [...]  
**FUNCIONES FAIL/PARTIAL/NOT_REACHED/NOT_VERIFIED:** [...]  
**INVENTARIO CONSOLIDADO DE FALTANTES:** [ID, causa, impacto, dependencia, archivo, verificación]  
**BLOQUEO PRINCIPAL:** [...]  
**DESVIACIÓN DETECTADA:** [sí/no, por qué]  
**SIGUIENTE PROMPT MAESTRO:** [un prompt con fases, permisos y condiciones STOP]  
**CONDICIÓN DE CIERRE:** [resultado real E2E, no solo test unitario]  
**COMPUERTA AUTORREPARACIÓN:** [AR-E2E-01/02, AR-SAFE-03, AR-ROLLBACK-04, AR-RECOVERY-05, AR-CONT-06, AR-ISOLATION-07 — PASS/FAIL/PARTIAL/BLOCKED/NOT_VERIFIED]  
**AUTORREPARACION_LISTA_PARA_VPS:** [TRUE/FALSE y evidencia]  
**ALERTA_DESVIO:** [SI/NO — MOTIVO — REGRESAR_A=P0-AR]

## 9. REGLAS TÉCNICAS PERMANENTES DE AUTORREPARACIÓN

1. **Una sola inteligencia:** Brain único, razonador central y efectores compartidos; productos como Developer no contienen una réplica del cerebro.
2. **Circuito de punta a punta:** entrada → detección → evidencia → traza → causa → hipótesis/parche → sandbox → tests → autorización → promoción/rollback → verificación → misión. Clasificar cada tramo `PASS/FAIL/NOT_REACHED/BLOCKED/NOT_VERIFIED`.
3. **No confiar en nombres o conteos:** módulos, importaciones, funciones, `CheckOnly`, PASS internos y demostraciones simuladas no prueban autorreparación operativa.
4. **Autonomía de verdad:** para acreditar razonamiento, Optimus debe producir la propuesta; ChatGPT, Antigravity o el usuario no le suministran la solución. Es legítimo usarlos **durante el desarrollo** del motor y la preparación de pruebas.
5. **PowerShell como instrumento independiente:** inspección de procesos, puertos, archivos, SHA256, SQLite lectura, logs y regresiones reproducibles. Tests que podrían modificar producción se ejecutan en aislamiento.
6. **Protección de memorias y secretos:** nunca publicar/copiar `continuity.db`, `devices.json`, tokens DPAPI, secretos API o claves privadas a laboratorios, ZIP, logs ni promotores. No volcar sus contenidos en informes.
7. **Aislamiento real:** sandbox de código y tests con barreras de SO cuando ejecuten código no confiable; prohibidos accesos a red/producción/secretos no autorizados. Resolver rutas y bloquear symlinks/junctions, traversal y escritura fuera de ámbito. Si aislamiento no puede comprobarse, `BLOCKED`.
8. **Rollback y estabilidad:** respaldos fuera de producción, reversión comprobada, límite de intentos, locks, deduplicación, circuito contra recursión y condiciones STOP.
9. **Supervisor vs autorreparador:** el supervisor externo recupera el proceso; el motor interno repara código. No mezclarlos, ni permitir que watchdog reescriba el Brain.
10. **Promoción gradual:** primero copia, después ambiente controlado y solamente entonces objetivo permitido con autorización/riesgo; proteger núcleo, seguridad, credenciales, infraestructura y dinero.
11. **Sin falsos éxitos:** pruebas faltantes = `NOT_VERIFIED`, ejecutor no alcanzado = `NOT_REACHED`, candidato sin verificar = rechazo, rollback no demostrado = bloqueo.
12. **Sin desviaciones ni trabajo duplicado:** aprovechar componentes existentes; un inventario consolidado por ronda, una intervención coordinada por dependencias, evidencia final independiente.

## 10. VPS: ACTIVACIÓN INMEDIATA DESPUÉS DE LA COMPUERTA

**Disparador único:** `AUTORREPARACION_LISTA_PARA_VPS=TRUE`, sustentado por matriz de aceptación independiente y visto bueno expreso del creador. **No comprar ni contratar el VPS antes de superar la compuerta**, salvo que el creador modifique explícitamente esta regla en el Norte Maestro.

Al superarla, iniciar **sin proyectos intermedios** esta secuencia:

1. **Elección y autorización:** definir proveedor VPS, capacidad mínima para Brain y servicios, región, presupuesto/límites, modelo/API, responsabilidades y pagos. El creador aprueba la contratación y el gasto antes de ejecutarlos.
2. **Respaldo y continuidad:** snapshot/versiones, respaldo consistente de SQLite, dispositivos y secretos con custodia segura, inventario de configuración; plan de reversión a equipo local. No subir secretos en repositorios o ZIP públicos.
3. **Despliegue endurecido:** sistema actualizado, cuentas de privilegio mínimo, SSH seguro, firewall, TLS y dominio cuando proceda, supervisión externa, almacenamiento persistente, secretos separados, reglas de red y mecanismos de actualización/reversión.
4. **Prueba en nube:** Brain independiente en VPS, conectividad autenticada, chat/API real, misión autorizada de extremo a extremo, autorreparación E2E dentro de su ámbito, recuperación tras reinicio, persistencia, logs y medición de costos.
5. **Puesta en trabajo:** empezar con misiones reales **autorizadas y limitadas**, evidencias de entregables, presupuesto, revisión de resultados; continuar mejoras y mantenimiento mediante despliegues controlados sin quitar supervisión.
6. **Contingencia:** si el VPS no cumple pruebas, detener exposición externa y revertir a estado conocido; seguir corrigiendo el bloqueo relacionado sin derivar a productos secundarios.

**Resultado de nube:** `OPTIMUS_VPS_OPERATIVO=TRUE` solo con evidencia física de funcionamiento y recuperación, no solo porque el servidor fue contratado o los archivos copiados.

## 11. GOBIERNO DEL ARCHIVO RECTOR

- **Archivo canónico previsto:** `C:\xampp\htdocs\Digital Optimus\DIGITAL_OPTIMUS_NORTE_MAESTRO.md`. El creador debe instalar esta versión en esa ubicación; un archivo compartido en el chat no actualiza automáticamente la computadora local.
- Antes de cada prompt, auditoría, recomendación o promoción, contrastar con este documento. Si hay contradicción, detener y explicar el conflicto.
- Mantener un único documento rector vigente; guardar versiones anteriores como respaldos, no como planes competidores. Versionar fecha, motivo y aprobación del creador.
- Solo el creador puede redefinir misión, orden de prioridad, reglas de gasto y criterios de despliegue. Los informes técnicos actualizan los **estados de prueba**, no el objetivo rector.
- Los estados deben registrar siempre evidencias, archivos, hashes y fecha; no fijar hashes históricos de bases de datos activas como criterio automático de fallo.
- Este archivo no concede por sí mismo acceso administrativo, permiso de compra, permiso de modificar archivos protegidos ni capacidad autónoma. Las autorizaciones operativas deben implementarse y verificarse en los mecanismos del sistema.

---

## REGLA DE ORO

> **Digital Optimus no existe para mantener funcionando una colección de herramientas. Las herramientas existen para que Digital Optimus trabaje, cree, mantenga sus productos, aprenda de los resultados y desarrolle oportunidades que sostengan su crecimiento.**

**Decisión rectora actual del creador:** terminar y comprobar la autorreparación propia antes de abrir cualquier otra ruta de desarrollo. **Siguiente paso inmediato, una vez aprobada:** VPS contratado con autorización, Brain operativo en la nube y mantenimiento/mejoras continuas sobre un sistema que ya trabaja.

Este documento solo debe actualizarse cuando el creador redefina expresamente la misión o las prioridades rectoras. Los informes técnicos y los estados PASS/FAIL se actualizan continuamente en evidencias separadas, sin alterar el objetivo superior.