systems/totebox-os.es

os-totebox es la capa de archivo de la familia PointSav: una bóveda aislada a nivel de núcleo por entidad. Almacena los registros, ejecuta los servicios que los procesan y no expone nada más. Una entidad es cualquier cosa que necesita su propio conjunto de libros — una persona, una corporación, una propiedad inmobiliaria, un proyecto, un hogar. Cada entidad tiene su propio os-totebox. Los Toteboxes no comparten archivos, no comparten usuarios y no pueden verse entre sí. Se comunican únicamente a través del Diodo, y solo bajo comando de os-console u os-orchestration. Este artículo cubre los servicios internos, la disciplina WORM, la evolución de la forma del host, los niveles de cómputo y el diseño libremente transferible.

[edit]Qué vive dentro

Cada os-totebox aloja un conjunto fijo de servicios:

Servicio	Función
service-email	Ingesta SMTP/IMAP; Maildir WORM; saneamiento de HTML y píxeles de rastreo
service-people	Libro mayor de identidades; la superficie F2; reclamaciones de entidad y el grafo Sovereign-ID
service-content	Lee cargas útiles, aplica el pipeline de síntesis editorial, genera resultados
service-extraction	Extracción de masa de entidades a través del archivo
service-slm	Modelo de lenguaje pequeño local; opera detrás del límite de auditoría Doorman
service-minutebook	Archivo de registros profundos — PDFs inmutables, DOCX, XLSX, con sumas de verificación criptográficas
service-bookkeeper	Libro mayor financiero
service-fs (previsto)	Servicio de sistema de archivos unikernel — el único servicio que toca el disco sin procesar
service-audit (previsto)	Libro mayor de solo adición a nivel de micronúcleo
service-resolution (previsto)	Empaquetador de resolución de activos — el paracaídas auto-ejecutable ante fallo del proveedor

[edit]La disciplina WORM

os-totebox escribe cargas útiles sin procesar directamente en almacenamiento de bloque de solo adición. No existe operación de borrado en el flujo de código. [^1] Un servicio comprometido no puede sobrescribir el historial porque el verbo no existe en la interfaz de almacenamiento. Esta es la capa de aplicación arquitectónica para la integridad de procesamiento y la disciplina WORM.

Cada registro institucional vive como un archivo plano inerte — Markdown, YAML o CSV — que no requiere ningún tiempo de ejecución propietario para leer décadas después. Un libro mayor .yaml o registro .csv puede ser leído por cualquier editor de texto, en cualquier hardware, en cualquier década. El costo de migración de datos tiende a cero: el operador siempre tiene la fuente en un formato que ningún software propietario puede bloquear. La arquitectura de almacenamiento WORM y la arquitectura del ledger describen la implementación técnica.

[edit]La forma del host

os-totebox está diseñado para evolucionar a través de cuatro fases a medida que el sustrato seL4 madura:

Fase	Forma	Caso de uso
1	Jaula LXC / FreeBSD	Desarrollo activo; itera rápidamente
2	Instancia FreeBSD reforzada	Primeros despliegues para clientes (previsto)
3	Monolito seL4 + Rust	Endurecimiento para producción (previsto)
4	Unikernel — binario único, ~15 MB, arranque <50 ms	Estado final (previsto)

El objetivo unikernel es la meta de diseño. [^2] El estado final no tiene SSH, ni shell, ni Bash, ni intérprete Python — solo un binario compilado fusionado a los controladores de hardware. Un operador recompila el código fuente del proveedor en el monorepo y reinicia el nodo en la nube con la nueva imagen; no hay shell al que conectarse.

[edit]Niveles de cómputo

os-totebox ajusta su comportamiento según el hardware disponible:

Nivel	Perfil	Capacidad
Bóveda de Cero Cómputo	Nodo en la nube ~$7/mes, ≤1 GB RAM	Solo libro mayor WORM y enrutador criptográfico; delega el procesamiento pesado al Relé Yo-Yo
Relé Yo-Yo	Nodo en la nube elástico aprovisionado por el operador	Puente con estado hacia un nodo de cómputo temporal; ejecuta [[service-extraction
Hierro Soberano	Estación de trabajo con ≥16 GB RAM o servidor bare-metal	Carga el [[service-slm

[edit]Libremente transferible

Cada instancia de os-totebox está prevista para distribuirse como una única imagen de disco (.img o .vmdk). El operador la toma y la mueve entre proveedores de nube, un servidor privado o hardware propio en sus instalaciones. No hay sistema operativo anfitrión subyacente que posea las claves. Esta es la intención del Addendum Soberano en forma física: la instancia en ejecución permanece como propiedad del operador en cualquier entorno.

[edit]Véase también

• os-family-overview — dónde encaja os-totebox en la familia de ocho SO
• console-os — el Libro Mayor de Comandos que se conecta a os-totebox y presenta su estado
• os-orchestration — el agregador de flota que consulta muchos Toteboxes a la vez
• diode-standard — el protocolo unidireccional a través del cual se comunica el Totebox
• sel4-microkernel-substrate — el núcleo que sustenta las garantías de aislamiento de os-totebox
• machine-based-auth — cómo el emparejamiento rige el acceso a un Totebox
• worm-ledger-design — la disciplina de almacenamiento de solo adición aplicada por os-totebox