Patrones de despliegue

Los patrones de despliegue describen las seis configuraciones canónicas en las que se despliega el sustrato PointSav en diferentes contextos institucionales, cada una construida sobre la arquitectura de tres anillos. Cada configuración se basa en los mismos cinco primitivos — Personas, Comunicaciones, Borradores, Registros, Dinero — y la misma superficie de Libro Mayor de Comandos; lo que cambia por configuración es el Plan de Cuentas y la superficie de cumplimiento. El sustrato no se bifurca entre segmentos; se adapta. Al finalizar este artículo, el lector comprenderá el posicionamiento de Compañero, las seis configuraciones canónicas y el modelo de aislamiento de cartuchos en tiempo de compilación que hace práctica la versión independiente en los seis.

Por qué importa: una corrección o función construida para una configuración se traslada automáticamente a las seis — no existe una base de código separada por segmento que mantener sincronizada.

Cinco primitivos que abarcan todos los contextos institucionales ¹

Cada contexto en el que operan los usuarios institucionales se asigna a las mismas cinco categorías primitivas de registros. Un profesional regulado que gestiona archivos de pacientes, un abogado litigante que gestiona la divulgación de casos y un hogar que gestiona declaraciones de impuestos mantienen documentos que caen exactamente en estas categorías:

Primitivo	Qué cubre
Personas	Contactos, registros de personal, relaciones de identidad
Comunicaciones	Correo electrónico, correspondencia, registros de reuniones
Borradores	Trabajo en progreso — documentos bajo autoría activa
Registros	Documentos firmados, sellados o ejecutados
Dinero	Registros financieros, facturas, entradas del libro mayor

El Libro Mayor de Comandos expone cada primitivo como una superficie de tecla F dedicada. El operador presiona una tecla; el chasis carga el plugin relevante; el plugin muestra los registros de ese primitivo dentro del contexto Totebox actual.

Por qué importa: un operador que ya aprendió la disposición de cinco teclas en una firma inmobiliaria ya la conoce en un bufete de abogados o en un hogar — la superficie nunca hay que reaprenderla cuando cambia el negocio subyacente.

Cómo la plataforma opera junto a las herramientas incumbentes

La plataforma se posiciona como un motor complementario, no como un reemplazo de las herramientas operativas existentes. Los clientes continúan usando las aplicaciones profesionales y de productividad que ya operan; el sustrato funciona en paralelo, enrutando los registros de esas aplicaciones hacia archivos Totebox soberanos.

Categoría de herramienta incumbente	Lo que agrega el sustrato
Clientes de correo electrónico profesional	service-email ingiere cada mensaje en un Maildir WORM; la copia en la nube puede rotar mientras la copia soberana permanece sellada
Aplicaciones de hojas de cálculo	La superficie de hoja de cálculo soberana prevista almacena modelos financieros ejecutados en el libro mayor WORM
Aplicaciones de procesamiento de texto	La superficie de procesamiento de texto soberana prevista usa Typst para salida con fidelidad de impresión
Plataformas de redes profesionales	Se prevé que service-people — el servicio de libro de identidades recopile datos de contacto verificados en el libro mayor de identidad del Totebox
Repositorios de documentos corporativos	Se prevé que service-minutebook selle criptográficamente los registros firmados contra el sustrato WORM

El cliente no necesita abandonar ninguna herramienta funcional. El sustrato opera en segundo plano; el Libro Mayor de Comandos proporciona una vista soberana sobre los registros que producen las herramientas incumbentes.

Por qué importa: el cliente nunca enfrenta una migración forzada fuera de las herramientas que su personal ya conoce — el sustrato añade un registro soberano por debajo, no reemplaza la interfaz que ya funciona.

Seis configuraciones de despliegue canónicas

Las seis configuraciones representan familias de GUIDEs distintas en el catálogo de despliegue de flota. Cada una es una configuración, no un producto separado; el os-totebox — La bóveda soberana y host de servicios, el os-console y los servicios subyacentes son idénticos en las seis.

Configuración	Registros principales	Adaptación del Plan de Cuentas
Gestor de activos inmobiliarios	Documentos de arrendamiento, modelos BIM, comunicaciones con inquilinos, permisos	Anclajes en Bienes Raíces / Arrendamiento / Inquilinos / Municipios
Emisor de información pública	Comunicados de prensa, presentaciones regulatorias, actas de la junta	Anclajes en Relaciones con Inversores / Finanzas / Medios
Práctica médica o quirúrgica	Registros de pacientes, archivos de diagnóstico, facturación clínica	Anclajes en Cumplimiento y Administración Local
Bufete de abogados	Expedientes de casos, materiales de divulgación, escritos judiciales firmados	Ancla en Cumplimiento / Asesoría
Family office	Registros fiscales, documentos de sucesión, contratos del hogar	Anclajes adaptados en Personal y Administración Local
Hogar	Recibos, garantías, correspondencia familiar	Plan simplificado de un solo Perfil

Por qué importa: una nueva configuración para un segmento aún no listado aquí es un ejercicio de Plan de Cuentas, no un nuevo esfuerzo de ingeniería — el sustrato subyacente no necesita reconstruirse.

Aislamiento de cartuchos dentro del Libro Mayor de Comandos

El Libro Mayor de Comandos es una aplicación de terminal, no una superficie web — no tiene capa HTTP ni HTML, CSS o JavaScript en ninguna parte. Cada tecla de función carga un fragmento de código completamente separado y compilado de forma independiente, y ningún cartucho puede leer el estado de otro por accidente — esa separación la aplica el compilador, no una comprobación de permisos en tiempo de ejecución. El chasis es una capa vacía que registra un conjunto fijo de objetos Rust — uno por cartucho — al iniciar. Cuando el operador presiona F2, el chasis despacha al cartucho de Personas ya registrado; F3 despacha al de Correo.

Propiedad de aislamiento	Efecto
Aislamiento de estado en tiempo de compilación	El cartucho de Personas no puede leer el estado del cartucho de Correo; cada uno es un módulo Rust separado
Versión independiente	Actualizar el crate de un cartucho no requiere reconstruir los demás
Envío en binario único	Cada cartucho se envía dentro del mismo binario compilado que el chasis
Sin dependencia externa	Sin CDN, sin navegador, sin biblioteca de UI de terceros

Este modelo de aislamiento logra el mismo objetivo práctico que una arquitectura de micro-frontends² basada en navegador: módulos mutuamente aislados y versionados de forma independiente detrás de una capa compartida. El mecanismo difiere — el sistema de módulos y traits de Rust, aplicado en tiempo de compilación.

Por qué importa: un error en un cartucho no puede corromper ni leer los datos de otro cartucho ni siquiera en principio — la garantía se sostiene porque el compilador la aplica, no porque una verificación en tiempo de ejecución lo haya detectado esta vez.

Cómo las plantillas de despliegue se asignan al catálogo de flota

Plantilla	Función	Estado
vault-privategit-source	Plantilla de despliegue de control de fuentes interno. Por la regla de nomenclatura del catálogo (Patrón de catálogo en el nivel cliente), la entrada de catálogo lleva el nombre base de la plantilla — el espacio de trabajo en ejecución es la instancia numerada aprovisionada a partir de ella	Activo
Gestión de activos inmobiliarios	El despliegue operativo de referencia para una empresa inmobiliaria	Planeado
Emisor de información	Un par de OS Mediakit y os-totebox — La bóveda soberana y host de servicios para divulgación de empresa pública	Planeado

Las plantillas en la Capa de Exhibición corresponden a instancias numeradas en la Capa de Instancias — privadas para el operador, ignoradas por git en todos los repositorios públicos. Consulte Arquitectura de tres capas — Software, escaparate, instancias para el modelo de tres capas.

Por qué importa: un cliente puede examinar públicamente el catálogo completo de plantillas sin que ningún dato privado de instancia — precios, credenciales o identidad del cliente — quede expuesto junto a él.

La cadencia de despliegue visible-primero

Los patrones de despliegue se lanzan con una cadencia de visible-primero: la URL resuelve y una superficie reconocible responde antes de que comience cualquier trabajo de pulido o endurecimiento. Un patrón que aún no ha sido aprovisionado como un despliegue funcional se describe en términos de planificación, no como infraestructura activa.

Por qué importa: un lector que ve una configuración descrita como "desplegada" puede confiar en esa afirmación literalmente — una URL real resuelve a una superficie real y usable, no a una especificación pendiente de construir.

Véase también

• Arquitectura de tres anillos — la arquitectura de anillos que cada configuración despliega
• Arquitectura de tres capas — Software, escaparate, instancias — el modelo de tres capas Software / Exhibición / Instancias
• Arquetipos y plan de cuentas — la taxonomía del Plan de Cuentas que se adapta por configuración
• os-console — la superficie del Libro Mayor de Comandos común a las seis configuraciones
• os-totebox — La bóveda soberana y host de servicios — el sistema operativo Totebox que aloja los archivos de cada configuración
• Cómo autoalojar un despliegue — guía paso a paso: desplegar una configuración de este catálogo en infraestructura propia

1. The Open Group, Estándar TOGAF, 10.ª edición, 2022. Capítulo 20: Patrones de Arquitectura. Tratamiento canónico de configuraciones de despliegue reutilizables en arquitectura empresarial. https://www.opengroup.org/togaf ↩

2. Jackson, Cam. 'Micro Frontends.' martinfowler.com, 2019. El artículo técnico fundacional que describe el patrón arquitectónico de micro-frontends aplicado en la ingeniería web moderna. https://martinfowler.com/articles/micro-frontends.html ↩