Definiciones de arquitectura, infraestructura y desarrollo del ecosistema Nostromo. Los términos contables, tributarios y de remuneraciones están en el Glosario Contable. Los términos específicos de cada sistema vivirán en glosarios propios (mother/glosario, orchestrator/glosario, sevastopol/glosario).
| Término | Definición |
|---|
| Nostromo | Nombre del ecosistema completo y también del monorepo en GitHub (ChrisTkm/Nostromo). |
| Mother | Servicio de base de datos PostgreSQL 16. Aloja nostromo_common, nostromo_command y las bases por empresa. |
| Orchestrator | Backend Node.js · Express · TypeScript. Expone la API REST y orquesta lógica de dominio. |
| Sevastopol | Frontend Astro + SolidJS. Renderiza la UI y consume el Orchestrator vía BFF. |
| Nostromo (ETL) | Sistema ETL en Python ubicado en accounting_system/. Alimenta Mother con datos de Banco Central, Previred y SII. |
| Jean d’Arc | Este sitio de documentación (Astro + Starlight). Sirve también como corpus RAG que consume Sevastopol. |
| accounting_system | Carpeta del monorepo donde vive el ETL Python (loaders, scrapers SII, cargas masivas). Conceptualmente es “Nostromo”. |
| Término | Definición |
|---|
| Tenant | Empresa-cliente del sistema. Cada tenant vive en su propia base de datos PostgreSQL. |
| Database-per-tenant | Patrón de aislamiento donde cada empresa tiene una base completa (nostromo_<rut_sin_dv>), no solo un schema. |
nostromo_common | Base de datos compartida: monedas, indicadores, AFP, ISAPRE, tablas IUSC y otros parámetros transversales. |
nostromo_command | Base de control central: usuarios, sesiones, tenants registrados y monitoreo del sistema. |
accunting_template | Plantilla PostgreSQL a partir de la cual se crean las bases por empresa. La falta de ortografía es intencional. |
| Tenant Resolver | Lógica del Orchestrator (getDatabaseNameForUser) que decide a qué base apunta cada petición autenticada. |
| Pool | Conjunto cacheado de conexiones PostgreSQL. Hay tres: centralPool, commonPool y un TenantPool por empresa. |
| Término | Definición |
|---|
| BFF | Backend-for-Frontend. Sevastopol nunca habla con Mother directamente: pasa por el Orchestrator, que actúa como proxy. |
| Hexagonal | Arquitectura de puertos y adaptadores. El dominio vive aislado de Express, PostgreSQL y SolidJS. |
| DDD | Domain-Driven Design. El Orchestrator organiza el código en domain/<contexto>/ (payroll, contracts, finiquitos, …). |
| Hybrid Core | Patrón propio: la lógica compleja (cálculos, validaciones) corre en TypeScript; las lecturas masivas en vistas SQL. |
| Smart View | Vista PostgreSQL pre-computada con joins y agregaciones, optimizada para lectura desde el Repository. |
| Island Architecture | Patrón de Astro: el HTML se sirve estático y solo las “islas” interactivas se hidratan en el cliente. |
| ViewIsland | Componente SolidJS que lee datos del Orchestrator y los muestra (solo lectura). |
| AdminIsland | ViewIsland con capacidades CRUD: además de leer, modifica el estado vía endpoints de mutación. |
| Capas (R · S · E · R) | Route → Service → Engine → Repository. Convención del Orchestrator para separar HTTP, orquestación, cálculo y datos. |
| Término | Definición |
|---|
| JWT | JSON Web Token. Firma la sesión del usuario; el Orchestrator lo lee desde la cookie sid. |
| RBAC | Role-Based Access Control. Cada usuario tiene un rol (admin, tenant_user, …) que define qué rutas resuelve. |
| CORS | Cross-Origin Resource Sharing. El Orchestrator solo acepta orígenes listados en CORS_ORIGINS. |
| CSP | Content Security Policy. Headers de helmet() que limitan los orígenes desde donde se cargan scripts y estilos. |
| Término | Definición |
|---|
| Astro | Framework SSR/SSG que sirve el shell de página de Sevastopol y Jean d’Arc. |
| SolidJS | Librería reactiva fine-grained usada en las islands de Sevastopol. |
| Starlight | Tema de documentación Astro que da estructura a Jean d’Arc. |
| Express | Framework HTTP del Orchestrator. |
| Helmet | Middleware Express que aplica headers de seguridad (CSP, HSTS, XSS). |
| pnpm | Gestor de paquetes de todo el ecosistema. El monorepo Accounting/ (Orchestrator + Sevastopol) lo pinea en packageManager; Jean d’Arc lo activa vía corepack. |
| Corepack | Activa la versión de pnpm pinneada en package.json → packageManager. |
| Mermaid | Sintaxis para diagramas embebidos en MDX. Renderizada por astro-mermaid en Jean d’Arc. |
| Término | Definición |
|---|
| ETL | Extract, Transform, Load. Pipeline de carga de datos externos hacia Mother. |
| Loader | Script Python del ETL Nostromo (bc_loader.py, previred_loader.py, sii_loader.py). |
| Seeder | Script que puebla datos de prueba en una base local; no se usa en producción. |
| ADR | Architecture Decision Record. Documento que justifica una decisión arquitectónica y su contexto. |
| Runbook | Procedimiento operativo paso a paso. En este sitio, las páginas kind: runbook. |
| Skill | Archivo de instrucciones para agentes AI (Claude). Las skills de Jean d’Arc viven en C:\dev\ai-skills\. |
| RAG | Retrieval-Augmented Generation. Sevastopol indexa Jean d’Arc para responder preguntas con contexto. |
| Término | Definición |
|---|
audience | Frontmatter que clasifica la página para el RAG. Valores: dev, auditor, both. |
domain | Dominio funcional al que pertenece la página (ej. remuneraciones, activo-fijo, arquitectura). |
layer | Capa técnica (mother, orchestrator, sevastopol, nostromo, infraestructura, seguridad, accounting). |
kind | Modo de lectura: reference, concept, service, ui, runbook o standard. |
related | B-tree de relaciones: upstream (padre directo), downstream (hijos directos), references (cruces). |
