41 Commits

Author SHA1 Message Date
ARCHITECT
1a94cd87e7 260122: Marcar archivos DECK como obsoletos, usar PABLO/MODELO CERO 2026-01-22 19:40:18 +00:00
ARCHITECT
3bca96ffd7 260122: Renombrado DECK → MODELO CERO y DECK PABLO → PABLO
- Actualizado 04_INFRAESTRUCTURA/overview.md con nueva nomenclatura
- Creado 01_ARQUITECTURA/entidades/modelo-cero.md (plantilla base)
- Creado 01_ARQUITECTURA/entidades/pablo.md (instancia producción)
- MODELO CERO (72.62.1.113): desarrollo y plantilla
- PABLO (72.62.115.124): producción del usuario
2026-01-22 16:55:49 +00:00
ARCHITECT
787babf6c2 260121: Documentación Captain Claude API v3 2026-01-21 19:37:35 +00:00
ARCHITECT
1f26cd78c4 Add: 260119_r2_proxy_multibucket.md - Configuración multi-bucket R2 2026-01-19 19:37:42 +00:00
ARCHITECT
25eee88c15 Add: 260118 auditorías servidores y sesión monitorización 2026-01-18 21:45:05 +00:00
ARCHITECT
573b3daabf Add: 260118_sesion_fk_completas.md - FK completas TZZR 2026-01-18 02:57:06 +00:00
ARCHITECT
ec9405def7 Add: 260118_sesion_hashtags_mapeado.md 2026-01-18 01:24:56 +00:00
ARCHITECT
b961cd6fe1 Add: 260118_agente_curador_hashtags.md - diseño inicial 2026-01-18 01:11:39 +00:00
ARCHITECT
f25df09834 Update: 260118_tareas_tablas.md - hashtags como proceso largo 2026-01-18 01:09:52 +00:00
ARCHITECT
608236e5a5 Add tareas: 260118_tareas_tablas.md - Análisis hashtags 2026-01-18 01:03:05 +00:00
ARCHITECT
d2ea1d28b1 Add session 260118: database keys and endpoints 2026-01-18 00:40:24 +00:00
ARCHITECT
f059266630 Add Nextcloud and ATC sync documentation
- NEXTCLOUD.md: Configuration for all 3 instances (ARCHITECT, DECK, HST)
- SYNC_ATC_R2.md: Architecture for R2 → Windmill → Nextcloud sync system

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-18 00:25:11 +00:00
ARCHITECT
d469589b81 Add database structure documentation 2026-01-17 2026-01-17 20:11:14 +00:00
ARCHITECT
38435fe820 Add ANEXO_5: Historial completo sesiones Claude Code 6 enero 2026
Documenta todas las sesiones de trabajo del 6 de enero:
- Sesion 1: Verificacion servidores y Windmill
- Sesion 2: Actualizacion Gitea con GPU Services
- Sesion 3: Analisis Skynet v10
- Sesion 4: Investigacion pendientes sistema
- Sesion 5: Investigacion RunPod y GPU services
- Sesion 6: Upgrade sistema

Incluye informacion clave recuperada:
- Endpoints RunPod (GRACE, PENNY)
- URLs Windmill
- Estado de componentes
- Trabajo pendiente identificado
2026-01-06 18:09:34 +00:00
ARCHITECT
a205cddac0 Add missing files from R2 skynet v10
- 00_VISION/MARCO_TEMPORAL.md - Marco conceptual temporal
- 01_ARQUITECTURA/aplicaciones/09_APLICACIONES.md - Aplicaciones TZZR
- 03_MODELO_DATOS/hst_standards_all.json - Tags HST JSON
- 03_MODELO_DATOS/procesos_productivos.md - Procesos productivos
- 05_INTEGRACIONES/README_MCP.md - MCP Server README
- 05_INTEGRACIONES/SPEC_MCP.md - MCP Especificación técnica
- 99_ANEXOS/ANEXO_1_REFERENCIA_TECNICA.md - Referencia técnica
2026-01-06 04:59:03 +00:00
ARCHITECT
386eef4d4b Add HST standards and infrastructure overview (encoding fixed)
- 04_INFRAESTRUCTURA/overview.md: Infrastructure overview with correct UTF-8
- 03_MODELO_DATOS/hst_standards_all.md: 963 HST tags with standards (756 KB)
- 03_MODELO_DATOS/listado_hst_flg.md: HST/FLG listing (132 KB)

Synced from R2 skynet v10 with encoding corrections

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-06 04:52:57 +00:00
ARCHITECT
1917054170 Add Oracle component and DATABASE_SPEC
- Add oracle.md: Complete specification for Oracle (prospectiva)
  - Puerto 5055, Capa 2 análisis prospectivo
  - 7 secciones del análisis, 10 reglas O-*
  - Integración con Grace, métricas calibración
- Add DATABASE_SPEC.md: Schema v2.1 with Oracle tables
  - oracle_analisis, oracle_escenario
  - Total: 28 tables

Synced from R2 skynet v10.1

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-06 04:15:14 +00:00
ARCHITECT
e020e2c518 Actualizar estado de mapeo Airtable - IDs poblados 2026-01-04 02:55:52 +00:00
ARCHITECT
6597d87053 Add Airtable mapping documentation
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-04 01:09:52 +00:00
ARCHITECT
3d80f9a56f Add HST master index v2.0 with complete status 2026-01-01 22:21:21 +00:00
ARCHITECT
579031f564 Add QFM quality form standard with ISO/IATF/AS standards 2026-01-01 22:13:35 +00:00
ARCHITECT
22c43d5d64 Update HST execution schemas: add tre and gnt definitions with industrial standards 2026-01-01 21:52:26 +00:00
ARCHITECT
5e34a16ba3 Add HST execution schemas documentation (pss, sqc, ctl) 2026-01-01 21:39:25 +00:00
ARCHITECT
c1c35ed357 Update README with HST schemas summary 2026-01-01 19:53:10 +00:00
ARCHITECT
e2c308eb6f Add HST schemas index with 13 document types 2026-01-01 19:52:43 +00:00
5dd2110b74 Update README with HST Contract (CCT) standard reference 2026-01-01 18:56:01 +00:00
e24de4102c Add HST Contract (CCT) standard documentation 2026-01-01 18:55:29 +00:00
ARCHITECT
0011b9c88a Add: Estudio de debilidades y mejoras del sistema 2026-01-01 13:06:45 +00:00
ARCHITECT
7fc4bdd04a Add: Informe de mejoras 2026-01-01 2026-01-01 13:00:43 +00:00
ARCHITECT
e260782dcd Add: Auditoría sistema 2026-01-01 pre-mejoras 2026-01-01 12:48:51 +00:00
ARCHITECT
b507f316f2 Update Context Manager v8.1 - new log schema with TZZR components integration 2026-01-01 12:22:39 +00:00
ARCHITECT
9f3a4214d3 Sync from R2 skynet v8: manuales, operación, glosario v3
Añadido:
- MANUAL_USUARIO_ARCHITECT.md
- MANUAL_USUARIO_CORP.md
- MANUAL_USUARIO_DECK.md
- MANUAL_USUARIO_HST.md
- 07_OPERACION/ (monitoring, runbooks, incident_response)
- glosario_she_enterprise_v3.md

Eliminado:
- glosario_she_enterprise_v2.md (reemplazado por v3)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-01 10:53:57 +00:00
ARCHITECT
36f87ca9b7 Add 07_INTERFACES - Documentación de interfaces desplegadas
Incluye:
- Interfaces web (MindLink, Flow-UI, Directus)
- APIs microservicios TZZR (Clara, Alfred, Mason, Feldman)
- HST API
- Tablas PostgreSQL por servidor
- Resumen de puertos y repositorios
- Comandos de gestión

Basado en auditoría real del 2025-12-31

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-31 19:28:36 +00:00
ARCHITECT
3960067337 Add user units and sync tables (10_user_units.sql, 11_sync.sql) 2025-12-30 23:40:36 +00:00
ARCHITECT
5d78535472 docs: Add HST server documentation
- Service overview and ports
- Docker containers
- PostgreSQL databases
- SSL domains
- Maintenance commands

🤖 Generated with Claude Code
2025-12-30 00:04:57 +00:00
ARCHITECT
3006ff9a76 docs: Añadir estructura navegable con READMEs por sección
- README.md principal con índice completo y tablas navegables
- README por cada sección (00-06 y 99_ANEXOS)
- Enlaces relativos para navegación interna
- Diagramas ASCII para arquitectura y flujos
- Tablas de referencia rápida

Basado en estructura skynet v7

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:08:07 +00:00
ARCHITECT
6ea70bd34f Update to Skynet v7 - Complete documentation restructure
- Nueva estructura de carpetas según Skynet v7
- Añadidos schemas SQL completos
- Documentación de entidades, componentes e integraciones
- Modelo de seguridad actualizado
- Infraestructura y operaciones reorganizadas
2025-12-29 18:23:41 +00:00
ARCHITECT
ac481fe266 docs: Add RunPod Serverless configuration and troubleshooting
- Document working REST API configuration (vs broken GraphQL)
- Add endpoint IDs for GRACE, PENNY, FACTORY
- Include troubleshooting for workers not starting
- Document Docker image rebuild process
2025-12-28 00:24:35 +00:00
admin
cad5512a59 Merge pull request 'fix(naming): Generic + proper name convention' (#3) from system-v5 into main 2025-12-25 11:26:05 +00:00
admin
767d98cfe0 Merge pull request 'fix: Enforce instance autonomy principle' (#2) from system-v5 into main 2025-12-25 11:17:35 +00:00
admin
4f92b6e369 Merge pull request 'docs(v5): Complete TZZR System Documentation' (#1) from system-v5 into main 2025-12-25 09:30:10 +00:00
133 changed files with 90566 additions and 4141 deletions

152
00_VISION/MARCO_TEMPORAL.md Normal file
View File

@@ -0,0 +1,152 @@
# Marco Conceptual Integrado para Gestion de Proyectos y Produccion
**Version:** 10.0
**Fecha:** 6 Enero 2026
**Sistema:** TZZR
---
## Introduccion
Este documento consolida un sistema de marcos conceptuales interrelacionados para comprender la gestion de proyectos, procesos productivos y la maduracion de productos.
> **Principio fundamental:** La realidad es un flujo energetico continuo donde las divisiones categoricas son simplificaciones utiles (modelos mentales), no verdades absolutas.
---
## 1. El Paradigma Temporal: La Linea T-N a T+N
### 1.1 Definicion de los puntos temporales
| Punto | Significado | Caracteristicas |
|-------|-------------|-----------------|
| **T-N** | Origen difuso | Zona de exploracion, ideas no consolidadas |
| **T-1** | Punto de referencia previo | Momento desde el cual se puede planificar hacia T0 |
| **T0** | Inicio de ejecucion | Arranque formal del proceso |
| **T+1** | Final de la accion | Hito de cierre operativo |
| **T+N** | Consolidacion del resultado | Momento en que el resultado se materializa en el mundo |
### 1.2 La distincion entre accion, hito y resultado
- **La accion fisica** termina cuando se agota la energia (no cuando aparece el hito).
- **El hito burocratico (T+1)** es un registro formal (ejemplo: la photo finish).
- **El resultado consolidado** emerge cuando el mundo interpreta la burocracia.
---
## 2. Tipologia de Acciones
### 2.1 Los tres tipos fundamentales
| Tipo | Metafora deportiva | Caracteristica | Equivalente |
|------|-------------------|----------------|-------------|
| **Puntos** | Baloncesto | Acumulacion de pequenas unidades | Cuantificacion |
| **Secuencias** | Patinaje artistico | Productividad en las transiciones | Metodo |
| **Esfuerzo maximo** | 1RM en gimnasio | Pico unico + recuperacion | Medidas de referencia |
---
## 3. El Eje Energetico: Mundo Real vs Burocracia
### 3.1 Principio fundamental
> La realidad se analiza mejor en terminos de flujo energetico que de categorias discretas.
### 3.2 Componentes del mundo real
| Componente | Descripcion | Relacion |
|------------|-------------|----------|
| **Energia** | Esfuerzo humano, energia electrica, trabajo aplicado | Recurso que se consume |
| **Recursos** | Capital, materias primas, activos | Elementos que se transforman |
| **Herramientas** | Equipos, tecnologia, sistemas | Multiplicadores de energia |
---
## 4. La Santisima Trinidad de los Proyectos (Project Cannon)
### 4.1 Los tres documentos fundamentales
| Documento | Pregunta que responde | Contenido |
|-----------|----------------------|-----------|
| **Listado de costes** | Que? | Materiales + Procesos (BOM ampliado) |
| **Arbol de procesos** | Como? | Secuencia y dependencias de transformaciones |
| **Grafica de Gantt** | Cuando? | Distribucion temporal de actividades |
---
## 5. Madurez del Producto: De la Idea al Mercado
| Fase temporal | Estado del producto | Entorno | Documento asociado |
|---------------|--------------------|---------|--------------------|
| **T-N** | Manualidades/Pruebas parciales | Artesano | Bocetos |
| **T-1** | Prototipo | Taller | Diseno tecnico |
| **T0** | Modelo cero | Industrial (transicion) | Lista de costes + Arbol + Gantt |
| **T+1** | Producto de produccion | Industrial | Control de calidad |
| **T+N** | Producto de mercado | Comercial | Documentacion de calidad |
---
## 6. Entornos Profesionales
| Entorno | Caracteristica principal | Herramientas |
|---------|-------------------------|--------------|
| **Artesano** | Habilidad individual, baja escala | Manuales, flexibles |
| **Taller** | Iteracion, prueba y error | Prototipos, maquinas simples |
| **Industrial** | Repetibilidad, alta escala | Lineas de produccion, estandares |
| **Comercial** | Atencion al cliente, feedback | CRM, post-venta |
---
## 7. Paradigma Guerrero vs Atleta
| Paradigma | T0 | Preparacion | Ejemplos |
|-----------|-----|-------------|----------|
| **Guerrero** | Impredecible | Permanente, nivel sostenido excepcional | Bomberos, urgencias medicas |
| **Atleta** | Definido | Orientada a pico maximo en fecha especifica | Competiciones, lanzamientos |
---
## 8. Reversibilidad
### 8.1 Concepto
El grado en que una accion o proceso permite correccion posterior sin coste prohibitivo.
| Nivel | Caracteristica | Ejemplo |
|-------|---------------|---------|
| **Alta** | Facil deshacer | Edicion de documento |
| **Media** | Deshacer con coste | Refactorizacion de codigo |
| **Baja** | Muy dificil deshacer | Produccion masiva lanzada |
| **Nula** | Irreversible | Comunicacion publica |
---
## 9. Eje de Escala / Volumen
| Escala | Caracteristicas | Documentacion necesaria |
|--------|-----------------|------------------------|
| **Unitario (1)** | Todo en la cabeza de una persona | Minima |
| **Pequena serie (2-20)** | Equipo pequeno, comunicacion directa | Listas basicas |
| **Serie media (20-500)** | Procesos deben ser ensenables | Procedimientos escritos |
| **Serie grande (500+)** | Sistemas, no personas | Sistemas de calidad |
| **Masivo (miles+)** | Estadistica, no casos individuales | Automatizacion |
---
## 10. Glosario de Terminos Clave
| Termino | Definicion |
|---------|------------|
| **T0** | Momento de inicio de ejecucion; punto de referencia temporal |
| **Modelo cero** | Producto identico al de serie, obtenido mediante preserie |
| **Preserie** | Produccion limitada para validar el modelo cero |
| **Diseno tecnico** | Documento que define que es algo y como se abordara tecnicamente |
| **Santisima Trinidad** | Conjunto de: listado de costes, arbol de procesos, Gantt |
| **Paradigma energetico** | Enfoque que analiza la realidad en terminos de flujo de energia |
| **Biblioteca de secuencias** | Coleccion de patrones de procesos normalizados |
| **Reversibilidad** | Grado en que una accion permite correccion posterior |
| **Punto de no retorno** | Momento donde la reversibilidad cae drasticamente |
---
*Marco Conceptual Integrado v10 - 6 Enero 2026*

29
00_VISION/README.md Normal file
View File

@@ -0,0 +1,29 @@
# 00 - Visión
> Principios fundamentales, paradigmas y terminología del sistema TZZR
## Contenido
| Documento | Descripción |
|-----------|-------------|
| [filosofia.md](filosofia.md) | Paradigmas del sistema, acuerdo bilateral usuario-sistema, principios de diseño |
| [glosario.md](glosario.md) | Términos técnicos, entidades del sistema, prefijos de hash |
## Principios Clave
1. **Soberanía de datos**: El usuario es dueño absoluto de su información
2. **Inmutabilidad**: Los registros históricos no se modifican
3. **Trazabilidad**: Cada cambio tiene origen y destino rastreable
4. **Interoperabilidad**: Los sistemas personal y empresarial se comunican
## Entidades Principales
- **HST**: Hash Semantic Tagging - Sistema de etiquetado semántico
- **ITM**: Items - Elementos del plano ideal
- **PLY**: Players - Identidades
- **LOC**: Locations - Ubicaciones
- **FLG**: Flags - Marcos jurídicos
---
[← Volver al índice](../README.md)

View File

@@ -1,118 +1,185 @@
# Filosofía del Sistema TZZR
# Filosofía Fundacional
**Versión:** 5.0
**Fecha:** 2024-12-24
**Versión:** 1.0
**Estado:** Definición
---
## 10 Principios Fundacionales
### 1. Constructores, no gestores
ARCHITECT (con Claude) es un **constructor de arquitecturas**, no un gestor permanente.
- ARCHITECT diseña y construye la arquitectura de cada servidor
- Cuando la arquitectura esté madura, el servidor será **clonable e independiente**
- DECK y CORP funcionan sin conexión a ARCHITECT ni a Claude
- Son sistemas diseñados para **usar** servicios de IA (APIs externas, RunPod), no para contenerla
### 2. Descentralización operativa
## 1. Principio Fundamental
```
Architect App (centralizado) → Diseña moldes
Instancias reales (descentralizadas)
Cada una con su CORP, su DECK, sus agentes
┌─────────────────────────────────────────────────────────────────┐
"La realidad es un flujo energético continuo. │
Las categorías son modelos mentales útiles,
│ no verdades absolutas. │
│ Ante la duda, analizar el flujo de energía │
│ clarifica la situación." │
│ │
└─────────────────────────────────────────────────────────────────┘
```
### 3. Referencias ligeras mediante hashes
Este principio guía todas las decisiones arquitectónicas del sistema. Cuando existe ambigüedad sobre cómo clasificar algo, la pregunta correcta es: **¿dónde se consume la energía?**
---
## 2. Paradigma de Resultados
```
DEFINICIÓN ORIGINAL → SHA-256 → HASH UNÍVOCO (64 chars)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ "El sistema no registra incidencias. Registra resultados." │
│ │
└─────────────────────────────────────────────────────────────────┘
```
El hash es una referencia ligera que arrastra toda la información del original sin duplicarla.
| Paradigma Burocrático | Paradigma de Resultados |
|----------------------|------------------------|
| ¿Por qué no cumpliste? | ¿Cumpliste? |
| Documenta la desviación | Documenta el resultado |
| Justifica el proceso | Evidencia el producto |
| El error es información | El error es ruido |
### 4. Separación de planos
### Implicación Técnica
| Plano | Nombre | Función |
|-------|--------|---------|
| **T-N → T0** | ITM (Ítems) | Lo ideal, la partitura |
| **Burocrático** | MST (Milestones) | Documentos, hitos, estados |
| **Físico** | BCK (Bloques) | Acciones, evidencias, trabajo real |
Cuando un Bloque de trabajo se completa, el sistema registra:
- Qué se hizo
- Evidencia de que se hizo
- Quién lo hizo
- Cuándo quedó completo
### 5. Período flotante antes de inmutabilidad
El sistema **NO registra**:
- Cuánto tardó internamente
- Qué interrupciones hubo
- Por qué se desvió del proceso ideal
- Cuántos intentos fueron necesarios
Los datos pasan por un período flotante que permite mejora antes del sellado definitivo.
---
## 3. Paradigma Temporal
### Línea Temporal Fundamental
```
Dato nuevo → Período flotante (24h) → Verificación SENTINEL → Sellado FELDMAN → Inmutable
T-N ────→ T-1 ────→ T0 ────→ T+1 ────→ T+N
│ │ │ │ │
Origen Pre- Inicio Cierre Futuro/
Difuso consoli- Real Eviden- Histórico
dación cia
```
### 6. Renombrabilidad de agentes
### Definición de Puntos Temporales
Los componentes marcados como renombrables pueden personalizarse:
| Punto | Significado | Características |
|-------|-------------|-----------------|
| **TN** | Origen difuso | Exploración, ideas no consolidadas |
| **T1** | Referencia previa | Punto desde el cual planificar hacia T0 |
| **T0** | Inicio ejecución | Arranque formal, recursos comprometidos |
| **T+1** | Hito burocrático | Registro formal de cierre operativo |
| **T+N** | Resultado consolidado | Materialización real en el mundo |
### Naturaleza Temporal de Entidades
| Entidad | Intervalo | Naturaleza |
|---------|-----------|------------|
| **Ítem** | T-N → T-1 → T0 | Definición ideal, proceso, producto conceptual |
| **Milestone** | T0 → T+1 | Estado contable/legal en vigor |
| **Bloque** | T+1 | Evidencia física de la ejecución |
> **"Un Bloque es la fotografía energética del intervalo T0 → T+1"**
---
## 4. El Acuerdo Bilateral
El sistema implementa un **pacto implícito de descargo de responsabilidad**:
### La Empresa Ofrece
- Herramientas para que el trabajador demuestre su buen trabajo
- Ausencia de vigilancia de proceso
- Contexto automático (arrastre de datos conocidos)
- Granularidad que permite progreso incluso en días difíciles
### El Trabajador Ofrece
- Resultados evidenciados
- Bloques completados
- Narrativa verificable de su aportación
### El Límite del Acuerdo
> **Si los resultados no llegan, la trazabilidad revela el problema.**
Pero lo revela de forma **constructiva**, no punitiva.
---
## 5. Trazabilidad como Movilidad
La trazabilidad tradicional es un arma de control. En este sistema, es una **herramienta de movilidad**:
### Para el Trabajador
- Portfolio verificable de resultados
- Evidencia objetiva de capacidades
- Independencia de la opinión subjetiva del supervisor
- Portabilidad entre puestos y empresas
### Para la Empresa
- Visibilidad real de dónde se genera valor
- Identificación de cuellos de botella sin buscar culpables
- Datos para optimizar asignación de recursos
- Base objetiva para decisiones de personal
### Mecánica Técnica
Cada Bloque completado es un registro inmutable que demuestra:
```
CLARA → "Lucía"
ALFRED → "Pepe"
PENNY → "Asistente"
```
Esto permite que cada usuario sienta el sistema como propio.
### 7. GRACE nunca modifica
GRACE extrae y comprende, pero **nunca modifica** el contenido original.
> "Solo extrae y comprende, nunca modifica el contenido original."
### 8. Auditoría dual: confía pero verifica
SENTINEL opera en dos modos:
| Modo | Frecuencia | Alcance | Tecnología |
|------|------------|---------|------------|
| **LIGHT** | Cada 5 min | Todos los registros | Reglas automáticas |
| **DEEP** | Cada 1 hora | Muestreo | LLM análisis |
### 9. Zero-retention en interfaces móviles
PACKET no almacena datos localmente. Todo va directo al servidor.
### 10. Curación humana en Vision Builder
```
VALORES → OBJETIVOS → IMÁGENES IA → CURACIÓN HUMANA → LO QUE SOBREVIVE DEFINE QUIÉN ERES
[Trabajador X] completó [Tarea Y] con [Evidencia Z] en [Contexto W]
```
---
## Modelo de Instancias
## 6. Implicaciones para el Diseño
**DECK** y **CORP** son plantillas. En producción habrá múltiples instancias:
### Granularidad de Bloques
| Tipo | Ejemplos |
|------|----------|
| **DECK** | "Deck de Juan", "Deck de Victoria", "Deck de Pablo" |
| **CORP** | "Lacitos de Colores SL", "TZR Tech", "Acme Corp" |
Los Bloques deben ser suficientemente pequeños para que:
- Un día malo no impida completar ninguno
- El progreso sea visible incluso con interrupciones
- La evidencia sea simple (una foto, un tap, una confirmación)
Cada instancia:
- Tiene su propio bucket de almacenamiento
- Puede renombrar sus agentes
- **Opera de forma autónoma** (no depende de ARCHITECT en runtime)
- Tiene su propio gestor de secretos (Vaultwarden)
- Hace sus propios backups a R2
### Arrastre de Contexto
### Servicios Compartidos (Opcionales)
Cada nuevo Bloque debe heredar automáticamente:
- Identidad del trabajador (sesión)
- Datos del Milestone padre
- Información ya capturada en pasos anteriores
- Reglas aplicables (Bandera)
Las instancias **pueden** conectarse a servicios GPU compartidos:
El trabajador **solo aporta lo nuevo**. Nunca re-introduce datos existentes.
| Servicio | Función | Requerido |
|----------|---------|-----------|
| GRACE | Extracción IA | Opcional |
| THE FACTORY | Generación | Opcional |
| CIRCLE | Colaboración | Opcional |
### Evidencia Mínima Viable
> **Nota:** Si los servicios compartidos no están disponibles, la instancia sigue operando. Solo las funciones de IA estarán limitadas.
La evidencia requerida debe ser:
- La mínima necesaria para demostrar el resultado
- Capturable en segundos
- No interpretable (foto > descripción textual)
- Protección para el trabajador, no vigilancia
---
## Resumen
| Principio | Implementación |
|-----------|----------------|
| Resultados sobre justificaciones | Solo se registran Bloques completados |
| Ocultación legítima | Las incidencias se absorben si hay resultado |
| Acuerdo bilateral | Herramientas a cambio de resultados |
| Trazabilidad como movilidad | Portfolio verificable para ambas partes |
| Eliminación del burócrata | Arrastre automático, sin transcripción |
| Granularidad liberadora | Bloques pequeños = progreso posible |
| Evidencia mínima | Demostrar resultado, no documentar proceso |

View File

@@ -1,7 +1,7 @@
# Glosario TZZR
# Glosario
**Versión:** 5.0
**Fecha:** 2024-12-24
**Versión:** 1.0
**Estado:** Definición
---
@@ -10,7 +10,7 @@
| Término | Hash | Descripción | Estado |
|---------|------|-------------|--------|
| **HST** | h_maestro | Hash Semantic Tagging - Etiquetas semánticas visuales | Implementado |
| **ITM** | h_item | Ítems ideales - Definiciones del plano T0 | Planificado |
| **ITM** | h_item | Items - Definiciones del plano ideal (T0) | Planificado |
| **PLY** | h_player | Players - Identidad de actores | Planificado |
| **LOC** | h_loc | Locations - Ubicaciones geográficas | Planificado |
| **FLG** | h_flag | Flags - Marcos jurídicos y banderas | Planificado |
@@ -27,84 +27,70 @@
---
## Componentes (Microservicios)
## Componentes del Sistema
> **Nota:** Los componentes tienen nombres de persona pero son **microservicios backend**, no IA.
> Están diseñados para consumir servicios de IA externos (APIs, RunPod), no para contenerla.
### Registro Inmutable
### secretaria (ingesta)
| Componente | Servidor | Puerto | Descripción |
|------------|----------|--------|-------------|
| **secretaria (CLARA)** | DECK | 5051 | Recoge información personal, log inmutable |
| **secretaria (MARGARET)** | CORP | 5051 | Recoge información corporativa, log inmutable |
| Componente | Nombre Personal | Nombre Corporativo | Descripción |
|------------|-----------------|-------------------|-------------|
| Secretaría | Clara | Margaret | Ingesta, log inmutable |
| Administración | Mason | Mason | Enriquecimiento, ventana flotante 24h |
| Contable | Feldman | Feldman | Consolidación final, inmutable |
| Producción | Alfred | Jared | Flujos predefinidos, orquestación |
| Auditoría | Sentinel | Sentinel | LIGHT (5min) + DEEP (1h) |
### administrativo (enriquecimiento)
| Componente | Servidor | Puerto | Descripción |
|------------|----------|--------|-------------|
| **administrativo (MASON)** | DECK | 5053 | Enriquecimiento, ventana flotante 24h |
| **administrativo (MASON)** | CORP | 5053 | Enriquecimiento, ventana flotante 24h |
### Servicios IA
### contable (consolidación)
| Componente | Servidor | Puerto | Descripción |
|------------|----------|--------|-------------|
| **contable (FELDMAN)** | DECK | 5054 | Consolidación final, blockchain, inmutable |
| **contable (FELDMAN)** | CORP | 5054 | Consolidación final, blockchain, inmutable |
| Componente | Descripción |
|------------|-------------|
| Grace | Capa cognitiva, 18 módulos IA |
| Penny | Asistente de voz conversacional |
| The Factory | Generación iterativa |
### producción (orquestación)
| Componente | Servidor | Puerto | Descripción |
|------------|----------|--------|-------------|
| **producción (ALFRED)** | DECK | 5052 | Flujos predefinidos, orden de ejecución |
| **producción (JARED)** | CORP | 5052 | Flujos predefinidos, orden de ejecución |
### Orquestación
### auditoría (planificado)
| Componente | Servidor | Puerto | Descripción |
|------------|----------|--------|-------------|
| **SENTINEL** | - | - | Auditoría LIGHT (5min) + DEEP (1h) |
---
## Servicios GPU (RunPod)
| Servicio | Endpoint | Descripción | Estado |
|----------|----------|-------------|--------|
| **GRACE** | r00x4g3rrwkbyh | IA cognitiva, extracción (18 módulos) | Bloqueado |
| **PENNY** | 0mxhaokgsmgee3 | Asistente personal, generación texto | Planificado |
| **FACTORY** | ddnuk6y35zi56a | Generación iterativa | Planificado |
| Componente | Descripción |
|------------|-------------|
| Orchestrator | Orquestación multi-agente LLM |
| Circle | Consejo de perspectivas |
| Cloudville | Laboratorio de zumbados |
---
## Servidores
| Servidor | IP | Rol |
|----------|-----|-----|
| **ARCHITECT** | 69.62.126.110 | Coordinador central, Gitea, PostgreSQL |
| **DECK** | 72.62.1.113 | Servidor personal |
| **CORP** | 92.112.181.188 | Servidor empresarial |
| **HST** | 72.62.2.84 | API tags semánticos |
| **LOCKER** | Cloudflare R2 | Almacenamiento (5 buckets) |
| Servidor | Descripción |
|----------|-------------|
| **ARCHITECT** | Coordinador central, Gitea, PostgreSQL |
| **DECK** | Servidor personal |
| **CORP** | Servidor empresarial |
| **HST** | API tags semánticos |
---
## Hashes y Identificadores
## Hashes e Identificadores
| Prefijo | Tipo | Ejemplo | Descripción |
|---------|------|---------|-------------|
| **h_maestro** | SHA-256 | `a1b2c3...` | Hash de tag HST |
| **h_instancia** | SHA-256 | `d4e5f6...` | Identidad servidor/contexto |
| **h_entrada** | SHA-256 | `g7h8i9...` | Hash contenedor ingesta |
| **h_bloque** | SHA-256 | `j0k1l2...` | Hash de bloque BCK |
| **h_milestone** | SHA-256 | `m3n4o5...` | Hash de milestone MST |
| **H_proyecto** | Prefijo | `H_tzzr_genesis` | Identificador proyecto legible |
| Prefijo | Tipo | Descripción |
|---------|------|-------------|
| **h_maestro** | SHA-256 | Hash de tag HST |
| **h_instancia** | SHA-256 | Identidad servidor/contexto |
| **h_entrada** | SHA-256 | Hash contenedor ingesta |
| **h_bloque** | SHA-256 | Hash de bloque BCK |
| **h_milestone** | SHA-256 | Hash de milestone MST |
| **h_item** | SHA-256 | Hash de ítem T0 |
| **h_player** | SHA-256 | Hash de identidad PLY |
| **h_loc** | SHA-256 | Hash de ubicación LOC |
| **h_flag** | SHA-256 | Hash de bandera FLG |
---
## Interfaces
## Aplicaciones
| Interfaz | Tipo | Descripción |
|----------|------|-------------|
| **PACKET** | App móvil | Captura multimedia, zero-retention |
| Aplicación | Tipo | Descripción |
|------------|------|-------------|
| **Packet** | App móvil | Captura multimedia, zero-retention |
| **Vision Builder** | Web | Diseño de vida mediante curación visual |
| **Mind Link** | Web | Compartición de información |
| **Mind Link** | Web | Interfaz unificada de acceso |
---
@@ -112,7 +98,7 @@
| Protocolo | Versión | Descripción |
|-----------|---------|-------------|
| **S-CONTRACT** | v2.1 | Comunicación con IAs (context, deployment, envelope, payload) |
| **S-CONTRACT** | v2.1 | Comunicación con servicios IA |
| **locker://** | - | Referencias almacenamiento R2 |
---
@@ -134,9 +120,9 @@
| Estado | Etapa | Descripción |
|--------|-------|-------------|
| **recibido** | CLARA/MARGARET | Contenedor ingresado, inmutable |
| **en_edicion** | MASON | Usuario enriqueciendo datos |
| **listo** | MASON | Listo para consolidar |
| **pendiente** | FELDMAN | En cola de consolidación |
| **consolidado** | FELDMAN | Registrado en milestone/bloque |
| **sellado** | NOTARIO | Blockchain confirmado |
| **recibido** | Secretaría | Contenedor ingresado, inmutable |
| **en_edicion** | Administración | Usuario enriqueciendo datos |
| **listo** | Administración | Listo para consolidar |
| **pendiente** | Contable | En cola de consolidación |
| **consolidado** | Contable | Registrado en milestone/bloque |
| **sellado** | Notario | Blockchain confirmado |

61
01_ARQUITECTURA/README.md Normal file
View File

@@ -0,0 +1,61 @@
# 01 - Arquitectura
> Visión general del sistema, entidades y aplicaciones
## Contenido Principal
| Documento | Descripción |
|-----------|-------------|
| [overview.md](overview.md) | Diagrama general y componentes principales del sistema |
| [almacenamiento.md](almacenamiento.md) | Cloudflare R2, buckets, protocolo `locker://` |
## Entidades
Define las estructuras fundamentales del sistema.
| Entidad | Archivo | Descripción |
|---------|---------|-------------|
| DECK | [deck.md](entidades/deck.md) | Servidor personal - instancia individual del usuario |
| CORP | [corp.md](entidades/corp.md) | Servidor empresarial - instancia organizacional |
| HST | [hst.md](entidades/hst.md) | Hash Semantic Tagging - sistema de categorización |
| ITM | [itm.md](entidades/itm.md) | Items - elementos del plano ideal T0 |
| PLY | [ply.md](entidades/ply.md) | Players - identidades y roles |
| LOC | [loc.md](entidades/loc.md) | Locations - ubicaciones físicas y virtuales |
| FLG | [flg.md](entidades/flg.md) | Flags - marcos jurídicos y regulatorios |
## Aplicaciones
Interfaces de usuario para interactuar con el sistema.
| App | Archivo | Descripción |
|-----|---------|-------------|
| Packet | [packet.md](aplicaciones/packet.md) | App móvil para captura multimedia y entrada rápida |
| Vision Builder | [vision-builder.md](aplicaciones/vision-builder.md) | Herramienta para Visiones → Milestones → Acciones |
| Mind-Link | [mind-link.md](aplicaciones/mind-link.md) | Interfaz unificada de acceso al sistema |
## Diagrama de Alto Nivel
```
┌─────────────────────────────────────────────────────────────┐
│ APLICACIONES │
│ ┌─────────┐ ┌───────────────┐ ┌─────────────┐ │
│ │ Packet │ │ Vision Builder │ │ Mind-Link │ │
│ └────┬────┘ └───────┬───────┘ └──────┬──────┘ │
│ └─────────────────┼───────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ DECK / CORP │ │
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │
│ │ │ HST │ │ ITM │ │ PLY │ │ LOC │ │ FLG │ │ ... │ │ │
│ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ ALMACENAMIENTO R2 │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
---
[← Volver al índice](../README.md)

View File

@@ -0,0 +1,128 @@
# Almacenamiento
**Versión:** 1.0
**Estado:** Definición
---
## Visión General
El sistema utiliza Cloudflare R2 como almacenamiento de objetos. Cada instancia tiene su propio bucket independiente.
---
## Buckets R2
| Bucket | Uso | Acceso |
|--------|-----|--------|
| **architect** | Coordinador central | Privado |
| **deck** | Servidor personal | Privado |
| **corp** | Servidor empresarial | Privado |
| **hst** | Tags semánticos (imágenes) | Público |
| **locker** | Almacenamiento general | Privado |
---
## Protocolo locker://
Referencia interna para archivos almacenados en R2.
### Formato
```
locker://{bucket}/{h_entrada}/{filename}
```
### Ejemplos
```
locker://deck/a1b2c3d4.../documento.pdf
locker://corp/f5e6d7c8.../factura.png
locker://hst/abc123.../imagen.png
```
---
## Estructura de Almacenamiento
### Por contenedor (ingesta)
```
{bucket}/
└── {h_entrada}/
├── archivo1.pdf
├── archivo2.jpg
└── metadata.json
```
### HST (tags)
```
hst/
└── {mrf}.png # mrf = SHA-256 del archivo de imagen
```
---
## Configuración R2
### Variables de Entorno
```bash
R2_ENDPOINT=https://{account_id}.r2.cloudflarestorage.com
R2_ACCESS_KEY=****
R2_SECRET_KEY=****
R2_BUCKET={bucket_name}
```
### Cliente Python
```python
import boto3
s3 = boto3.client(
's3',
endpoint_url=R2_ENDPOINT,
aws_access_key_id=R2_ACCESS_KEY,
aws_secret_access_key=R2_SECRET_KEY
)
# Subir archivo
s3.put_object(
Bucket=R2_BUCKET,
Key=f"{h_entrada}/{filename}",
Body=file_bytes
)
# Obtener archivo
response = s3.get_object(
Bucket=R2_BUCKET,
Key=f"{h_entrada}/{filename}"
)
content = response['Body'].read()
```
---
## Política de Retención
| Tipo de datos | Retención | Backup |
|---------------|-----------|--------|
| Archivos de ingesta | Permanente | Sí |
| Imágenes HST | Permanente | Sí |
| Temporales | 7 días | No |
---
## Integridad
Cada archivo se identifica por su hash SHA-256:
```python
import hashlib
def calcular_hash(contenido_bytes):
return hashlib.sha256(contenido_bytes).hexdigest()
```
La referencia `locker://` incluye el hash del contenedor, permitiendo verificación de integridad.

View File

@@ -0,0 +1,468 @@
# 09_APLICACIONES
**Versión:** 10.0
**Fecha:** 6 Enero 2026
**Sistema:** TZZR
---
# Visión General
Las aplicaciones son **interfaces especializadas** para interactuar con el sistema TZZR. Cada una resuelve un problema específico y puede integrarse con otras partes del sistema.
| App | Propósito | Destino |
|-----|-----------|---------|
| **Packet** | Captura de evidencia | Secretaría (Clara) |
| **Mind Map** | Árboles de milestones y bloques | Feldman (estructuras) |
| **Mind Flow** | Flujos de trabajo con HST | Producción (Alfred/Jared) |
| **Mind Link** | Menú de acceso / visualizador | Salida (Usuario) |
---
# Packet
**Tipo:** App Móvil (Flutter)
**Estado:** APK funcional
**Destino:** Secretaría (Clara/Margaret)
## Propósito
Captura de evidencia multimedia con política zero-retention. Todo lo capturado se envía inmediatamente a la Secretaría sin dejar rastro en el dispositivo.
## Características
| Característica | Descripción |
|----------------|-------------|
| Zero-retention | Archivos en RAM, nunca en disco |
| Hash-first | SHA-256 único por contenedor |
| Offline-capable | Cola de 20 reintentos en 72h |
| Multi-destino | DECK, CORP u otros servidores |
## Flujo
```
Captura → Etiquetas HST → Enviar → Clara → BCK
```
## Pantallas
| Pantalla | Función |
|----------|---------|
| Captura | Foto, audio, video, texto, GPS |
| Etiquetas | Selección de tags HST |
| Packs | Conjuntos predefinidos |
| Pendientes | Cola de fallos |
| Config | Destinos y bibliotecas |
## API
```http
POST /ingest
X-Auth-Key: {h_instancia}
{
"hash": "sha256 del contenedor",
"titulo": "opcional",
"etiquetas": ["mrf1", "mrf2"],
"archivos": [{"nombre", "tipo", "contenido"}]
}
```
---
# Mind Map
**Tipo:** App Web / iPad
**Estado:** Especificado
**Destino:** Feldman (estructuras de referencia)
## Propósito
Crear **árboles de milestones** y **árboles de bloques**, enlazarlos entre ellos. Cada nodo genera un hash único. Las estructuras resultantes sirven como documentación interna para que Feldman reconozca entradas y proponga integraciones.
## Problema que Resuelve
| Problema | Solución |
|----------|----------|
| Vendor lock-in | Formato abierto, exportable |
| Duplicación de elementos | Elementos únicos por hash |
| Pérdida de datos | Estructuras separadas de elementos |
## Modelo Conceptual
```
┌─────────────────────────────────────────────────────────────────┐
│ ELEMENTOS │
│ (entidades únicas, cada una con su hash) │
│ │
│ [E1: hash-a1b2] [E2: hash-c3d4] [E3: hash-e5f6] │
└─────────────────────────────────────────────────────────────────┘
│ RELACIONES
┌─────────────────────────────────────────────────────────────────┐
│ ESTRUCTURAS │
│ │
│ Árbol A: E1 ──► E2 ──► E3 │
│ Árbol B: E4 ──► E5 ──► E3 (mismo E3, no duplicado) │
└─────────────────────────────────────────────────────────────────┘
```
## Identificación por Hash
Cada elemento tiene un **content hash** (SHA-256) calculado sobre su contenido:
```python
def calculate_hash(elemento):
content = {
'nombre': elemento['nombre'].strip().lower(),
'tipo': elemento.get('tipo', 'nodo'),
}
content_string = json.dumps(content, sort_keys=True)
return hashlib.sha256(content_string.encode()).hexdigest()
```
## Estados
| Estado | Descripción |
|--------|-------------|
| **Borrador** | Editable, puede ser solo local |
| **Consolidado** | Inmutable, sincronizado |
## Tipos de Árbol
### Árbol de Milestones (MST)
```
Proyecto Alpha (mrf: a1b2c3...)
├── Fase 1 (mrf: d4e5f6...)
│ ├── Diseño (mrf: g7h8i9...)
│ └── Desarrollo (mrf: j0k1l2...)
└── Fase 2 (mrf: m3n4o5...)
└── Testing (mrf: p6q7r8...)
```
### Árbol de Bloques (BCK)
```
Documentación Proyecto (mrf: x1y2z3...)
├── Especificación técnica (mrf: a9b8c7...)
├── Manual de usuario (mrf: d6e5f4...)
└── Guía de despliegue (mrf: g3h2i1...)
```
### Enlaces entre Árboles
```
MST: Fase 1 > Desarrollo
└── enlaza → BCK: Especificación técnica
```
## Interfaz
```
┌─────────────────────────────────────────────────────────────────┐
│ Mind Map 🔄 Sync ⚙ │
├─────────────────────────────────────────────────────────────────┤
│ ┌───────────────┐ ┌─────────────────────────────────────────┐ │
│ │ MAPAS │ │ Proyecto Alpha │ │
│ │ │ ├─────────────────────────────────────────┤ │
│ │ ▼ Trabajo │ │ │ │
│ │ • Proyecto │ │ ▼ 🔒 Proyecto Alpha │ │
│ │ Alpha │ │ ▼ 🔒 Fase 1 │ │
│ │ • Backlog │ │ • Diseño │ │
│ │ │ │ • Desarrollo [2] │ │
│ │ ▼ Personal │ │ ▶ 🔒 Fase 2 (3 items) │ │
│ │ • Ideas │ │ │ │
│ │ │ │ │ │
│ │ + Nuevo mapa │ │ + Añadir elemento... │ │
│ └───────────────┘ └─────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ 🔒 = consolidado [2] = aparece en 2 mapas │
└─────────────────────────────────────────────────────────────────┘
```
## Atajos de Teclado
| Atajo | Acción |
|-------|--------|
| `Enter` | Crear hermano debajo |
| `Tab` | Convertir en hijo |
| `Shift+Tab` | Subir nivel |
| `Ctrl+Enter` | Crear hijo |
| `Space` | Colapsar/expandir |
| `Ctrl+Shift+C` | Consolidar elemento |
| `Ctrl+L` | Vincular elemento existente |
## Exportación
| Formato | Uso |
|---------|-----|
| JSON | Estructura completa con hashes |
| OPML | Compatibilidad con otras apps |
| Markdown | Lectura humana |
---
# Mind Flow
**Tipo:** App Web / iPad
**Estado:** Especificado
**Destino:** Producción (Alfred/Jared)
## Propósito
Crear **flujos de trabajo** enlazando piezas de la **biblioteca HST**. Interfaz minimalista para bocetado rápido de procesos. Los flujos definidos se usan como plantillas en Producción.
## Diferencia con Mind Map
| Mind Map | Mind Flow |
|----------|-----------|
| Árboles jerárquicos | Grafos direccionales |
| Estructura estática | Flujo con dirección |
| Milestones y bloques | Procesos HST enlazados |
## Principios de Diseño
| Principio | Descripción |
|-----------|-------------|
| Minimalismo | Elementos esenciales |
| Naturalidad | Físicas orgánicas |
| Portabilidad | Exportable |
## Elementos Visuales
Cuadrados con esquinas redondeadas (estilo Apple), tamaño 1×1.
| Elemento | Marco | Descripción |
|----------|-------|-------------|
| Proceso | Amarillo | Paso individual (tag HST) |
| Flujo | Azul | 2+ procesos conectados |
## Biblioteca HST en UI
```
┌─────────────────────────────────────────────────────────────────┐
│ [inv] [cli] [prv] [pgo] [ctr] [doc] [tsk] ... 🔍 Buscar │
├─────────────────────────────────────────────────────────────────┤
│ [⭐ frecuentes del usuario] │
├─────────────────────────────────────────────────────────────────┤
│ │
│ LIENZO DE TRABAJO │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ cli │────────▶│ inv │────────▶│ pgo │ │
│ └─────┘ └─────┘ └─────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
## Sistema de Físicas
### Gravedad Central
Elementos atraídos hacia el centro del lienzo (estilo Apple Watch).
### Separación Vertical
- Procesos (amarillo): tendencia arriba
- Flujos (azul): tendencia abajo
## Conexiones
### Crear
1. Arrastrar proceso sobre otro
2. Colisión genera rebote
3. Se crea línea de conexión
4. Ambos pasan a flujo (azul)
### Direccionalidad
| Acción | Resultado |
|--------|-----------|
| Deslizar sobre línea | Flecha en dirección del gesto |
| Doble tap | Cicla: sin flecha → → → ← |
### Elasticidad
- Límite: 2 celdas
- Superar y soltar en vacío: ruptura
- Superar y soltar sobre otro: unión
## Nodo Fantasma
Al crear flujo aparece nodo vacío para:
- Conexiones adicionales
- Flujos circulares
## Exportación a Producción
```json
{
"mrf": "hash-del-flujo",
"nombre": "Proceso de facturación",
"pasos": [
{"ref": "cli", "mrf": "hash-cliente"},
{"ref": "inv", "mrf": "hash-factura"},
{"ref": "pgo", "mrf": "hash-pago"}
],
"conexiones": [
{"from": 0, "to": 1},
{"from": 1, "to": 2}
]
}
```
---
# Mind Link
**Tipo:** Componente Web embebible
**Estado:** Planificado
**Destino:** Salida al usuario
## Propósito
**Visualizador y menú de acceso** integrable en cualquier parte del sistema:
1. **Menú** - Agrupar herramientas o funcionalidades
2. **Visualizador** - Enlace de salida de documentos
3. **Share** - Página pública tipo linktree
## Integración con ADI
Se integra con ADI para aplicación de acceso a documentos.
## Característica Clave
**Embebible en cualquier parte del sistema** como componente reutilizable.
## Modo Menú
```
┌─────────────────────────────────────────┐
│ 🏠 TZZR │
├─────────────────────────────────────────┤
│ ┌─────────┐ ┌─────────┐ │
│ │ 📷 │ │ 🗺️ │ │
│ │ Packet │ │ Mind Map│ │
│ └─────────┘ └─────────┘ │
│ ┌─────────┐ ┌─────────┐ │
│ │ ⚡ │ │ 📊 │ │
│ │ Flow │ │ Reports │ │
│ └─────────┘ └─────────┘ │
└─────────────────────────────────────────┘
```
## Modo Visualizador
```
┌─────────────────────────────────────────┐
│ Documentación Proyecto │
├─────────────────────────────────────────┤
│ [Proyecto] │
│ │ │
│ ┌─────────┼─────────┐ │
│ │ │ │ │
│ [Spec] [Manual] [API] │
└─────────────────────────────────────────┘
```
## Modo Share
```
┌─────────────────────────────────────┐
│ 🖼️ Avatar │
│ Nombre │
│ Bio corta │
├─────────────────────────────────────┤
│ [🔗 Portfolio] │
│ [📧 Contacto] │
│ [📄 CV] │
└─────────────────────────────────────┘
```
## Tipos de Nodo
| Tipo | Acción |
|------|--------|
| Link externo | Abre URL |
| Documento | Abre visualizador |
| App | Lanza aplicación |
| Submenú | Expande hijos |
| Acción | Ejecuta función |
## Configuración
```json
{
"modo": "menu",
"titulo": "Panel Principal",
"nodos": [
{
"icono": "📷",
"nombre": "Packet",
"tipo": "app",
"destino": "/packet"
}
]
}
```
---
# Matriz de Aplicaciones
## Por Destino
| App | Secretaría | Producción | Feldman | Salida |
|-----|------------|------------|---------|--------|
| Packet | ✅ | - | - | - |
| Mind Map | - | - | ✅ | - |
| Mind Flow | - | ✅ | - | - |
| Mind Link | - | - | - | ✅ |
## Por Estado
| App | Estado | Próximo paso |
|-----|--------|--------------|
| Packet | APK funcional | Enlazar con Clara |
| Mind Map | Especificado | Prototipo |
| Mind Flow | Especificado | Prototipo |
| Mind Link | Planificado | Especificar integración ADI |
## Por Plataforma
| App | Web | iPad | Móvil |
|-----|-----|------|-------|
| Packet | ❌ | ❌ | ✅ |
| Mind Map | ✅ | ✅ | ❌ |
| Mind Flow | ✅ | ✅ | ❌ |
| Mind Link | ✅ | ✅ | ✅ |
---
# Principios Comunes
## Hash como Identificador
```python
mrf = hashlib.sha256(contenido.encode()).hexdigest()
```
## Inmutabilidad
Datos consolidados no se modifican. Cambios crean nuevas versiones.
## Portabilidad
Formatos abiertos, exportables, sin vendor lock-in.
## Offline-first
Funcionalidad básica sin conexión.
---
*SKYNET v10 - 09_APLICACIONES - 6 Enero 2026*

View File

@@ -0,0 +1,142 @@
# Mind Link
**Tipo:** Aplicación Web
**Versión:** v11
**Estado:** En desarrollo
---
## Descripción
Interfaz de comunicación visual tipo mindmap/linktree. Presenta nodos principales (categorías) con subnodos desplegables (documentos) conectados por líneas animadas.
---
## Arquitectura Visual
```
┌─────────────────────────────────────────────────────────────────┐
│ MIND LINK │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────────────────┐ │
│ │ NODO │──────────────│ SUBNODO 1 │ │
│ │ 120x120 │ │ 180x101 │ │
│ │ │──────────────│ SUBNODO 2 │ │
│ └─────────┘ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Especificaciones Técnicas
### Dimensiones
| Elemento | Valor | Notas |
|----------|-------|-------|
| Nodo principal | 120×120 px | Cuadrado |
| Subnodo | 180×101 px | Ratio 16:9 |
| Radio esquinas nodo | 20px | |
| Radio esquinas subnodo | 15px | |
| Grosor líneas/bordes | 3px | |
| Gap entre subnodos | 20px | Vertical |
| Gap entre grupos | 50px | Vertical |
| Gap nodo a subnodo | 70px | Horizontal |
### Tipografía
| Elemento | Tamaño | Peso | Color |
|----------|--------|------|-------|
| Título página | 32px | 600 | #1a1a1a |
| Título nodo | 18px | 500 | Color del nodo |
| Título subnodo | 16px | 500 | Color del nodo |
### Colores por Defecto
```
#FF6B35 - Naranja (nodo 1)
#E5A000 - Amarillo (nodo 2)
#06D6A0 - Verde (nodo 3)
#0891B2 - Cyan (nodo 4)
#3B82F6 - Azul (nodo 5)
#8B5CF6 - Violeta (nodo 6)
#EC4899 - Rosa (nodo 7)
```
---
## Iconos de Acción
Posicionados en las 4 esquinas del subnodo:
```
┌─────────────────────┐
│ 🕐 👁 │ 🕐 = historial
│ │ 👁 = preview
│ │
│ ⬇ 🔗 │ ⬇ = descarga
└─────────────────────┘ 🔗 = enlace
```
| Icono | Campo | Función |
|-------|-------|---------|
| 👁 | tiene_preview | Abrir modal con documento |
| ⬇ | tiene_descarga | Descargar archivo |
| 🔗 | tiene_enlace | Copiar URL |
| 🕐 | tiene_historial | Mostrar versiones |
---
## Animaciones
| Elemento | Duración | Función | Delay |
|----------|----------|---------|-------|
| Movimiento vertical nodo | 400ms | ease-out | - |
| Revelado de líneas | 450ms | linear | 80ms |
| Aparición subnodos | instantánea | - | 30ms |
---
## Estructura de Datos
### Configuración
| Campo | Tipo | Descripción |
|-------|------|-------------|
| titulo | String | Título principal |
| mostrar_titulo | Boolean | Mostrar/ocultar |
| colores | String | Hex separados por comas |
| fuente | String | Nombre de fuente |
### Nodos
| Campo | Tipo | Descripción |
|-------|------|-------------|
| id | String | Identificador único |
| titulo | String | Nombre categoría |
| imagen | URL | Imagen 120×120 |
| subnodos | Array | Lista documentos |
### Subnodos
| Campo | Tipo | Descripción |
|-------|------|-------------|
| id | String | Identificador único |
| titulo | String | Nombre documento |
| imagen | URL | Miniatura 16:9 |
| tiene_preview | Boolean | Icono ojo |
| tiene_descarga | Boolean | Icono descarga |
| tiene_enlace | Boolean | Icono enlace |
| tiene_historial | Boolean | Icono reloj |
---
## Pendiente
- [ ] Conexión real con API
- [ ] Sistema de autenticación con PIN
- [ ] Funcionalidad real de iconos
- [ ] Responsive móvil
- [ ] Integración en aplicación empresarial

View File

@@ -0,0 +1,74 @@
# Packet
**Tipo:** App Móvil
**Estado:** En desarrollo
---
## Descripción
App móvil de captura multimedia con política **zero-retention**. No almacena datos localmente; todo va directo al servidor.
---
## Principio
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ PACKET no almacena datos localmente. │
│ Todo va directo al servidor. │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Flujo
```
Captura (foto/audio/texto)
Upload inmediato
Clara/Margaret (secretaría)
Confirmación al usuario
Borrado local
```
---
## Tipos de Captura
| Tipo | Formato | Uso |
|------|---------|-----|
| **Foto** | JPEG/PNG | Evidencia visual |
| **Audio** | MP3/WAV | Notas de voz |
| **Texto** | String | Notas rápidas |
| **Ubicación** | Coords | Geolocalización |
---
## Características
| Característica | Valor |
|----------------|-------|
| Almacenamiento local | NO |
| Funciona offline | NO (requiere conexión) |
| Autenticación | Token de sesión |
| Destino | Secretaría (Clara/Margaret) |
---
## Integración
```
PACKET ──► Clara (secretaría) ──► Mason (si no encaja) ──► Feldman
└──► Feldman (si encaja)
```

View File

@@ -0,0 +1,67 @@
# Vision Builder
**Tipo:** Aplicación Web
**Estado:** En desarrollo
---
## Descripción
Sistema de construcción de visiones que se convierten en acciones medibles.
---
## Flujo Principal
```
VISIÓN → MST (Milestones) → ACCIONES + HÁBITOS → BCK (Evidencias)
```
---
## Tipos de Visión
| Tipo | Descripción | Ejemplo |
|------|-------------|---------|
| **fitness** | Transformación física | Perder 10kg en 12 semanas |
| **career** | Desarrollo profesional | Conseguir ascenso |
| **project** | Proyecto específico | Lanzar MVP |
| **habit** | Crear hábito | Meditar diario |
| **learning** | Aprendizaje | Dominar Python |
| **finance** | Finanzas | Ahorrar €10k |
---
## Acciones vs Hábitos
| Concepto | Descripción | Ejemplo |
|----------|-------------|---------|
| **Acción** | Tarea única | Comprar báscula |
| **Hábito** | Comportamiento recurrente | Entrenar 5x/semana |
---
## Tablas
```sql
deck_visiones -- Visiones del usuario
deck_milestones -- MST: objetivos con fecha
deck_acciones -- Tareas únicas
deck_habitos -- Comportamientos recurrentes
deck_habito_registros -- Tracking diario de hábitos
deck_bck -- Bloques de evidencia
```
---
## Integración con HST
Cada visión puede etiquetarse con tags HST:
```json
{
"vision": "Transformación física",
"tags": ["fitness", "health", "body"],
"h_maestro": ["abc...", "def...", "ghi..."]
}
```

View File

@@ -0,0 +1,89 @@
# CORP
**Tipo:** Servidor Empresarial
**IP:** 92.112.181.188
**Dominio:** tzzrcorp.me
**Estado:** Operativo
---
## Descripción
CORP es el **servidor empresarial** del ecosistema. Gestiona múltiples usuarios y mayor complejidad que DECK.
---
## Arquitectura
```
┌──────────────────────────────────────────────────────────────────┐
│ CORP │
│ (Servidor Empresarial) │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ DIRECTUS │ │ NEXTCLOUD │ │ ODOO │ │
│ │ (admin) │ │ (archivos) │ │ (ERP) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Componentes Internos │ │
│ │ Margaret (secretaría) │ Jared (producción) │ │
│ │ Mason (administración) │ Feldman (contable) │ │
│ │ Sentinel (auditoría) │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────┐ │
│ │ PostgreSQL + Redis │ │
│ └───────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────┘
```
---
## Componentes Internos
| Componente | Puerto | Función |
|------------|--------|---------|
| Margaret (secretaría) | 5051 | Ingesta inmutable, múltiples usuarios |
| Jared (producción) | 5052 | Flujos predefinidos, mayor complejidad |
| Mason (administración) | 5053 | Enriquecimiento |
| Feldman (contable) | 5054 | Consolidación |
| Sentinel (auditoría) | - | Verificación LIGHT/DEEP |
---
## Servicios Docker
| Servicio | Puerto | Estado |
|----------|--------|--------|
| Directus | 8055 | OK |
| Nextcloud | 8080 | OK |
| Vaultwarden | 8081 | OK |
| Shlink | 8082 | OK |
| Odoo | 8069 | OK |
| ntfy | 8880 | OK |
| HSU API | 5002 | OK |
| Redis | 6379 | OK |
| PostgreSQL | 5432 | OK |
| Caddy | 80/443 | OK |
---
## Almacenamiento
- **Bucket R2:** corp
- **Protocolo:** locker://corp/...
---
## Diferencias con DECK
| Aspecto | DECK | CORP |
|---------|------|------|
| Dominio | tzzrdeck.me | tzzrcorp.me |
| Usuarios | Uno | Múltiples |
| Secretaría | Clara | Margaret |
| Producción | Alfred | Jared |
| Complejidad | Menor | Mayor |

View File

@@ -0,0 +1,265 @@
# DECK - DOCUMENTO OBSOLETO
> ⚠️ **OBSOLETO desde 2026-01-22**
>
> Este documento ha sido reemplazado por:
> - [MODELO CERO](modelo-cero.md) - Plantilla base (72.62.1.113)
> - [PABLO](pablo.md) - Instancia de producción (72.62.115.124)
>
> Mantienido solo para referencia histórica.
---
# DECK
**Tipo:** Servidor Personal
**IP:** 72.62.1.113
**Dominio:** tzzrdeck.me
---
## Rol en el Ecosistema
DECK es el **servidor central** y **punto de iniciación** de todas las conexiones hacia los servicios de IA.
```
┌─────────────────────────────────────────────────────────────────┐
│ PRINCIPIO DECK │
│ │
│ "DECK inicia TODAS las conexiones. Los servicios son │
│ stateless. Cada request lleva su contexto completo." │
└─────────────────────────────────────────────────────────────────┘
```
---
## Funciones
| Función | Descripción |
|---------|-------------|
| **Iniciador** | Todas las llamadas a GRACE, PENNY, FACTORY se originan aquí |
| **Gestor contexto** | Envía información de contexto con cada request |
| **Router despliegue** | Decide si usar self-hosted o externos |
| **Almacén credenciales** | Gestiona API keys vía Key Vault |
---
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ DECK │
│ (Servidor Central) │
├─────────────────────────────────────────────────────────────────┤
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PostgreSQL │ │ Directus │ │ FileBrowser │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Vaultwarden │ │ Shlink │ │ Addy.io │ │
│ │ (Key Vault) │ │ │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ DEPLOYMENT ROUTER │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ GRACE │ │ PENNY │ │ FACTORY │ │ │
│ │ │ Connector │ │ Connector │ │ Connector │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │
│ └─────────┼────────────────┼────────────────┼───────────────┘ │
└────────────┼────────────────┼────────────────┼──────────────────┘
│ │ │
▼ ▼ ▼
┌────────────────────────────────────────────────────┐
│ SERVICIOS DE IA │
├────────────────────────────────────────────────────┤
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ SELF-HOSTED │ │ EXTERNAL │ │
│ │ (RunPod/GPU) │ │ (APIs) │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Faster Whisper │ │ Groq API │ │
│ │ Local LLM │ │ OpenRouter │ │
│ │ Tesseract │ │ OpenAI │ │
│ │ Embeddings │ │ Anthropic │ │
│ └─────────────────┘ └─────────────────┘ │
└────────────────────────────────────────────────────┘
```
---
## Componentes Internos
| Componente | Puerto | Función |
|------------|--------|---------|
| Clara (secretaría) | 5051 | Ingesta inmutable |
| Alfred (producción) | 5052 | Flujos predefinidos |
| Mason (administración) | 5053 | Enriquecimiento |
| Feldman (contable) | 5054 | Consolidación |
---
## Modos de Despliegue
### EXTERNAL
```yaml
grace:
mode: EXTERNAL
external:
providers_allowed: [groq, openrouter, openai, anthropic]
```
- Todas las llamadas a proveedores externos
- Sin infraestructura propia
- Ideal para: inicio rápido, bajo volumen
### SELF_HOSTED
```yaml
grace:
mode: SELF_HOSTED
self_hosted:
endpoint: "https://your-runpod-endpoint.runpod.net"
timeout_ms: 30000
```
- Todas las llamadas a infraestructura propia
- Requiere RunPod/GPU configurado
- Ideal para: privacidad total, alto volumen
### SEMI (Recomendado)
```yaml
grace:
mode: SEMI
tier_preference:
- SELF_HOSTED
- EXTERNAL
self_hosted:
endpoint: "..."
retry_on_failure: true
external:
providers_allowed: [groq, openrouter]
```
- Intenta self-hosted primero
- Fallback automático a external
- Balance privacidad/disponibilidad
---
## Flujo de Request
```
┌──────────┐ ┌──────────┐ ┌───────────────┐ ┌──────────────┐
│ Cliente │────▶│ DECK │────▶│ Deployment │────▶│ Servicio │
│ │ │ │ │ Router │ │ (IA) │
└──────────┘ └────┬─────┘ └───────┬───────┘ └──────────────┘
│ │
│ 1. Recibe request │
│ 2. Lee config/deployment.yaml
│ 3. Obtiene credenciales de Vaultwarden
│ 4. Construye S-CONTRACT request
│ │
│ ┌────────▼────────┐
│ │ mode: SEMI │
│ ├─────────────────┤
│ │ 1. Try SELF_HOSTED
│ │ 2. If fail → EXTERNAL
│ └─────────────────┘
```
---
## Servicios Docker
| Servicio | Puerto | Descripción |
|----------|--------|-------------|
| PostgreSQL | 5432 | Base de datos principal |
| Directus | 8055 | Interface datos |
| FileBrowser | 8081 | Gestión archivos |
| Vaultwarden | 8082 | Key Vault |
| Shlink | 8083 | Acortador URLs |
| Addy.io | 8084 | Alias correo |
| Redis | 6379 | Cache y colas |
---
## Conectores de IA
### GRACE Connector
- Procesa requests de módulos GRACE
- Soporta todos los M-CONTRACTs
- Maneja fallback chain según M-CONTRACT
### PENNY Connector
- Conexión WebSocket para real-time voice
- Sesiones de voz bidireccionales
- Integración con ASR/TTS
### FACTORY Connector
- Jobs de generación iterativa
- Gestión de iteraciones y convergencia
- Tracking de costos
---
## Gestión de Credenciales
Las credenciales se referencian con URIs `kv://`:
| URI | Contenido |
|-----|-----------|
| `kv://deck/credentials/groq` | API key Groq |
| `kv://deck/credentials/openrouter` | API key OpenRouter |
| `kv://deck/credentials/runpod` | API key RunPod |
| `kv://deck/credentials/grace` | Credenciales consolidadas GRACE |
| `kv://deck/credentials/penny` | Credenciales PENNY |
| `kv://deck/credentials/factory` | Credenciales FACTORY |
---
## Integración S-CONTRACT
DECK construye requests siguiendo S-CONTRACT v2.1:
```json
{
"contract_version": "2.1",
"profile": "FULL",
"envelope": {
"trace_id": "uuid-generado-por-deck",
"idempotency_key": "sha256-del-contenido"
},
"routing": {
"module": "ASR_ENGINE"
},
"deployment": {
"mode": "SEMI",
"tier_preference": ["SELF_HOSTED", "EXTERNAL"],
"credentials_ref": "kv://deck/credentials/grace"
},
"payload": {
"type": "audio",
"encoding": "url",
"content": "https://storage.tzzrdeck.me/audio/file.mp3"
}
}
```
---
## Estructura de Directorios
```
deck/
├── config/
│ └── deployment.yaml # Modos de despliegue
├── docker-compose.yml # Servicios
├── docs/
│ ├── ARQUITECTURA.md
│ └── ESPECIFICACION_SERVIDOR.md
├── .env # Variables entorno
└── README.md
```

View File

@@ -0,0 +1,58 @@
# FLG - Flags
**Tipo:** Marcos Jurídicos
**Estado:** Planificado
---
## Descripción
Los FLG representan **marcos jurídicos**, normativas y países. Determinan las reglas aplicables a cada operación.
---
## Uso
| Contexto | Ejemplo |
|----------|---------|
| País | España, México, Argentina |
| Normativa | RGPD, SOX, ISO 27001 |
| Jurisdicción | UE, LATAM, USA |
---
## Grupos HST Relacionados
Actualmente existe un grupo `flg` en HST con 65 tags de países, pero no como entidad independiente con schema propio.
---
## Schema Propuesto
```sql
CREATE TABLE flags (
id BIGSERIAL PRIMARY KEY,
h_flag VARCHAR(64) UNIQUE NOT NULL,
tipo VARCHAR(50) NOT NULL,
codigo VARCHAR(10),
nombre VARCHAR(255) NOT NULL,
normativas JSONB,
metadata JSONB,
activo BOOLEAN DEFAULT true,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
---
## Aplicación en Bloques
Cada bloque puede tener un FLG asociado:
```json
{
"h_bloque": "abc123...",
"h_flag": "esp...",
"implicacion": "RGPD aplica, retención 5 años"
}
```

View File

@@ -0,0 +1,95 @@
# HST - Hash Semantic Tagging
**Tipo:** Sistema de Etiquetado
**Estado:** Implementado
---
## Descripción
Sistema de etiquetas semánticas visuales de 3 caracteres. Cada tag tiene un hash SHA-256 único (h_maestro) y una imagen asociada.
---
## Fórmula
```
h_maestro = SHA-256(grupo:ref)
```
---
## Grupos
| Grupo | Cantidad | Descripción |
|-------|----------|-------------|
| **hst** | 639 | Tags del sistema base |
| **spe** | 145 | Tags específicos |
| **vsn** | 84 | Visiones |
| **flg** | 65 | Banderas/países |
| **vue** | 21 | Vistas |
**Total:** 954 tags maestros
---
## Schema
```sql
CREATE TABLE hst_tags (
id SERIAL PRIMARY KEY,
ref VARCHAR(100) UNIQUE NOT NULL,
h_maestro VARCHAR(64) UNIQUE NOT NULL,
grupo VARCHAR(50) NOT NULL,
nombre_es VARCHAR(255),
nombre_en VARCHAR(255),
descripcion TEXT,
imagen_url TEXT,
activo BOOLEAN DEFAULT true,
version INTEGER DEFAULT 1,
created_at TIMESTAMP DEFAULT NOW()
);
```
---
## Ejemplo
```json
{
"ref": "person",
"h_maestro": "a1b2c3d4e5f6...",
"grupo": "hst",
"nombre_es": "Persona",
"nombre_en": "Person",
"imagen_url": "https://tzrtech.org/a1b2c3d4e5f6...png"
}
```
---
## Extensiones de Usuario
Los usuarios pueden crear sus propios tags:
| Tabla | Descripción |
|-------|-------------|
| **hsu** | HST Usuario |
| **spu** | SPE Usuario |
| **vsu** | VSN Usuario |
| **vuu** | VUE Usuario |
| **pju** | Proyectos Usuario |
| **flu** | FLG Usuario |
---
## API
**Base URL:** https://tzrtech.org/api
| Endpoint | Método | Descripción |
|----------|--------|-------------|
| /tags | GET | Lista todos los tags |
| /tags/{ref} | GET | Obtiene tag por ref |
| /tags/search | GET | Busca tags |
| /biblioteca | GET | Tags de usuario |

View File

@@ -0,0 +1,84 @@
# ITM - Items
**Tipo:** Entidad de Plano Ideal
**Estado:** Planificado
---
## Descripción
Los ITM representan el **plano ideal** (T0). Son la "partitura" que guía las acciones. Definiciones perfectas de lo que debería existir o lograrse.
---
## Concepto
| Aspecto | Descripción |
|---------|-------------|
| **Naturaleza** | Ideal, abstracta |
| **Temporalidad** | T-N → T-1 → T0 |
| **Energía** | No consume (es definición) |
| **Mutabilidad** | Versionable |
---
## Tipos de Items
| Tipo | Descripción |
|------|-------------|
| **accion_ideal** | Acción que debería ejecutarse |
| **objetivo** | Meta a alcanzar |
| **requerimiento** | Requisito a cumplir |
---
## Schema Propuesto
```sql
CREATE TABLE items (
id BIGSERIAL PRIMARY KEY,
h_item VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64),
tipo_item VARCHAR(50) NOT NULL,
titulo VARCHAR(255) NOT NULL,
descripcion TEXT,
criterios_aceptacion JSONB,
metadata JSONB,
proyecto_tag VARCHAR(64),
etiquetas JSONB,
estado VARCHAR(20) DEFAULT 'draft',
created_at TIMESTAMPTZ DEFAULT NOW(),
created_by VARCHAR(64),
UNIQUE (h_instancia, secuencia)
);
```
---
## Fórmula Hash
```
h_item = SHA-256(h_instancia:secuencia:tipo:contenido)
```
---
## Relación con Otros Planos
```
ITM (ideal)
├──► h_maestro (HST tags)
├──► h_player (PLY responsable)
├──► h_loc (LOC ubicación)
└──► h_flag (FLG normativa)
▼ materializa
MST (milestone)
▼ genera
BCK (bloque)
```

View File

@@ -0,0 +1,67 @@
# LOC - Locations
**Tipo:** Ubicaciones Geográficas
**Estado:** Planificado
---
## Descripción
Los LOC representan **ubicaciones geográficas** con precisión variable.
---
## Tipos
| Tipo | Descripción |
|------|-------------|
| **punto** | Coordenadas exactas |
| **area** | Zona delimitada |
| **ruta** | Trayecto entre puntos |
---
## Schema Propuesto
```sql
CREATE TABLE locations (
id BIGSERIAL PRIMARY KEY,
h_loc VARCHAR(64) UNIQUE NOT NULL,
nombre VARCHAR(255),
lat DECIMAL(10, 8),
lon DECIMAL(11, 8),
precision_metros INTEGER,
tipo VARCHAR(50),
metadata JSONB,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
---
## Fórmula Hash
```
h_loc = SHA-256(lat:lon:precision)
```
---
## Uso en el Sistema
Cada bloque puede tener una ubicación asociada:
```json
{
"h_bloque": "abc123...",
"h_loc": "geo456...",
"lat": 41.6488,
"lon": -0.8891,
"precision_metros": 10
}
```
Esto permite:
- Geolocalización de evidencias
- Verificación de ubicación
- Análisis espacial de operaciones

View File

@@ -0,0 +1,256 @@
# MODELO CERO
**Tipo:** Plantilla Base / Desarrollo
**IP:** 72.62.1.113
**Dominio:** tzzrdeck.me
---
## Rol en el Ecosistema
MODELO CERO es la **plantilla base replicable** del sistema. Sirve como entorno de **desarrollo y experimentación** antes de replicar cambios a instancias de producción (como PABLO).
Es el **servidor central** y **punto de iniciación** de todas las conexiones hacia los servicios de IA en cualquier instancia del sistema.
```
┌─────────────────────────────────────────────────────────────────┐
│ PRINCIPIO MODELO CERO │
│ │
│ "MODELO CERO inicia TODAS las conexiones. Los servicios son │
│ stateless. Cada request lleva su contexto completo." │
└─────────────────────────────────────────────────────────────────┘
```
---
## Funciones
| Función | Descripción |
|---------|-------------|
| **Iniciador** | Todas las llamadas a GRACE, PENNY, FACTORY se originan aquí |
| **Gestor contexto** | Envía información de contexto con cada request |
| **Router despliegue** | Decide si usar self-hosted o externos |
| **Almacén credenciales** | Gestiona API keys vía Key Vault |
---
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ MODELO CERO │
│ (Servidor Central) │
├─────────────────────────────────────────────────────────────────┤
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PostgreSQL │ │ Directus │ │ FileBrowser │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Vaultwarden │ │ Shlink │ │ Addy.io │ │
│ │ (Key Vault) │ │ │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ DEPLOYMENT ROUTER │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ GRACE │ │ PENNY │ │ FACTORY │ │ │
│ │ │ Connector │ │ Connector │ │ Connector │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │
│ └─────────┼────────────────┼────────────────┼───────────────┘ │
└────────────┼────────────────┼────────────────┼──────────────────┘
│ │ │
▼ ▼ ▼
┌────────────────────────────────────────────────────┐
│ SERVICIOS DE IA │
├────────────────────────────────────────────────────┤
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ SELF-HOSTED │ │ EXTERNAL │ │
│ │ (RunPod/GPU) │ │ (APIs) │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Faster Whisper │ │ Groq API │ │
│ │ Local LLM │ │ OpenRouter │ │
│ │ Tesseract │ │ OpenAI │ │
│ │ Embeddings │ │ Anthropic │ │
│ └─────────────────┘ └─────────────────┘ │
└────────────────────────────────────────────────────┘
```
---
## Componentes Internos
| Componente | Puerto | Función |
|------------|--------|---------|
| Clara (secretaría) | 5051 | Ingesta inmutable |
| Alfred (producción) | 5052 | Flujos predefinidos |
| Mason (administración) | 5053 | Enriquecimiento |
| Feldman (contable) | 5054 | Consolidación |
---
## Modos de Despliegue
### EXTERNAL
```yaml
grace:
mode: EXTERNAL
external:
providers_allowed: [groq, openrouter, openai, anthropic]
```
- Todas las llamadas a proveedores externos
- Sin infraestructura propia
- Ideal para: inicio rápido, bajo volumen
### SELF_HOSTED
```yaml
grace:
mode: SELF_HOSTED
self_hosted:
endpoint: "https://your-runpod-endpoint.runpod.net"
timeout_ms: 30000
```
- Todas las llamadas a infraestructura propia
- Requiere RunPod/GPU configurado
- Ideal para: privacidad total, alto volumen
### SEMI (Recomendado)
```yaml
grace:
mode: SEMI
tier_preference:
- SELF_HOSTED
- EXTERNAL
self_hosted:
endpoint: "..."
retry_on_failure: true
external:
providers_allowed: [groq, openrouter]
```
- Intenta self-hosted primero
- Fallback automático a external
- Balance privacidad/disponibilidad
---
## Flujo de Request
```
┌──────────┐ ┌──────────┐ ┌───────────────┐ ┌──────────────┐
│ Cliente │────▶│ MODELO CERO │────▶│ Deployment │────▶│ Servicio │
│ │ │ │ │ Router │ │ (IA) │
└──────────┘ └────┬─────┘ └───────┬───────┘ └──────────────┘
│ │
│ 1. Recibe request │
│ 2. Lee config/deployment.yaml
│ 3. Obtiene credenciales de Vaultwarden
│ 4. Construye S-CONTRACT request
│ │
│ ┌────────▼────────┐
│ │ mode: SEMI │
│ ├─────────────────┤
│ │ 1. Try SELF_HOSTED
│ │ 2. If fail → EXTERNAL
│ └─────────────────┘
```
---
## Servicios Docker
| Servicio | Puerto | Descripción |
|----------|--------|-------------|
| PostgreSQL | 5432 | Base de datos principal |
| Directus | 8055 | Interface datos |
| FileBrowser | 8081 | Gestión archivos |
| Vaultwarden | 8082 | Key Vault |
| Shlink | 8083 | Acortador URLs |
| Addy.io | 8084 | Alias correo |
| Redis | 6379 | Cache y colas |
---
## Conectores de IA
### GRACE Connector
- Procesa requests de módulos GRACE
- Soporta todos los M-CONTRACTs
- Maneja fallback chain según M-CONTRACT
### PENNY Connector
- Conexión WebSocket para real-time voice
- Sesiones de voz bidireccionales
- Integración con ASR/TTS
### FACTORY Connector
- Jobs de generación iterativa
- Gestión de iteraciones y convergencia
- Tracking de costos
---
## Gestión de Credenciales
Las credenciales se referencian con URIs `kv://`:
| URI | Contenido |
|-----|-----------|
| `kv://deck/credentials/groq` | API key Groq |
| `kv://deck/credentials/openrouter` | API key OpenRouter |
| `kv://deck/credentials/runpod` | API key RunPod |
| `kv://deck/credentials/grace` | Credenciales consolidadas GRACE |
| `kv://deck/credentials/penny` | Credenciales PENNY |
| `kv://deck/credentials/factory` | Credenciales FACTORY |
---
## Integración S-CONTRACT
MODELO CERO construye requests siguiendo S-CONTRACT v2.1:
```json
{
"contract_version": "2.1",
"profile": "FULL",
"envelope": {
"trace_id": "uuid-generado-por-deck",
"idempotency_key": "sha256-del-contenido"
},
"routing": {
"module": "ASR_ENGINE"
},
"deployment": {
"mode": "SEMI",
"tier_preference": ["SELF_HOSTED", "EXTERNAL"],
"credentials_ref": "kv://deck/credentials/grace"
},
"payload": {
"type": "audio",
"encoding": "url",
"content": "https://storage.tzzrdeck.me/audio/file.mp3"
}
}
```
---
## Estructura de Directorios
```
deck/
├── config/
│ └── deployment.yaml # Modos de despliegue
├── docker-compose.yml # Servicios
├── docs/
│ ├── ARQUITECTURA.md
│ └── ESPECIFICACION_SERVIDOR.md
├── .env # Variables entorno
└── README.md
```

View File

@@ -0,0 +1,128 @@
# PABLO
**Tipo:** Instancia de Producción del Usuario
**IP:** 72.62.115.124
**Dominio:** tzzr.me
---
## Rol en el Ecosistema
PABLO es la **instancia de producción** del sistema TZZR. Es una réplica operativa de MODELO CERO que sirve como herramienta de trabajo diario del usuario.
Todas las características y arquitectura documentadas en MODELO CERO aplican a PABLO, con la diferencia de que esta instancia está optimizada para uso en producción con todos los servicios activos y estables.
---
## Relación con MODELO CERO
```
┌──────────────────┐ ┌──────────────────┐
│ MODELO CERO │ │ PABLO │
│ (Desarrollo) │ ──────► │ (Producción) │
│ 72.62.1.113 │ replica │ 72.62.115.124 │
│ tzzrdeck.me │ │ tzzr.me │
└──────────────────┘ └──────────────────┘
Experimentación Uso diario
Nuevas features Estable
Pruebas Operativo
```
Cuando una característica o configuración es validada en MODELO CERO, se replica a PABLO para uso en producción.
---
## Servicios Activos
| Servicio | Puerto | Estado | Descripción |
|----------|--------|--------|-------------|
| Caddy | 443 | ✓ | Reverse proxy y SSL |
| PostgreSQL | 5432 | ✓ | Base de datos principal |
| PostgREST | 3000 | ✓ | API REST auto-generada |
| Directus | 8055 | ✓ | CMS headless |
| Nextcloud | 8084 | ✓ | Almacenamiento cloud |
| Vaultwarden | 8085 | ✓ | Gestor de contraseñas |
| Shlink | 8083 | ✓ | Acortador de URLs |
| Ntfy | 8080 | ✓ | Notificaciones push |
| Windmill | 8100 | ✓ | Orquestación de flujos |
| HST Web | 5002 | ✓ | Interfaz etiquetas |
---
## Servicios TZZR Internos
| Componente | Puerto | Estado | Función |
|------------|--------|--------|---------|
| Clara (secretaría) | 5051 | ✓ | Ingesta inmutable |
| Alfred (producción) | 5052 | ✓ | Flujos predefinidos |
| Mason (administración) | 5053 | ✓ | Enriquecimiento |
| Feldman (contable) | 5054 | ✓ | Consolidación |
---
## Sistema de Correo
PABLO incluye un sistema completo de correo electrónico:
| Componente | Puerto | Función |
|------------|--------|---------|
| Haraka | 25, 587 | SMTP server |
| Dovecot | 143, 993 | IMAP server |
| mail-ui | 3080 | Interfaz web |
| Stalwart | 8899 | Admin panel |
| Snappymail | 8280 | Webmail |
Datos almacenados en: `tzzr_communications.mail`
---
## Base de Datos
### DB Principal: `tzzr`
Base de datos PostgreSQL con esquema completo del sistema TZZR.
### DB Usuario: `pablo`
Base de datos PostgreSQL dedicada para gestión personal:
```bash
ssh pablo "docker exec tzzr-postgres psql -U pablo -d pablo"
```
#### Tablas Provisionales
| Tabla | Campos | Propósito |
|-------|--------|-----------|
| **notas** | id, nota, created, fecha_inicio, fecha_finalizacion | Agenda personal |
---
## Conectividad
```bash
# SSH
ssh pablo
# Acceso web
https://tzzr.me
```
---
## Arquitectura
PABLO implementa la misma arquitectura documentada en MODELO CERO:
- Router de deployment (SEMI mode por defecto)
- Gestión de credenciales via Vaultwarden
- Integración S-CONTRACT v2.1
- Conectores para GRACE, PENNY, FACTORY
- Context Manager para gestión de contexto IA
Consultar [MODELO CERO](modelo-cero.md) para detalles arquitectónicos completos.
---
**Actualizado:** 22 Enero 2026

View File

@@ -0,0 +1,64 @@
# PLY - Players
**Tipo:** Entidad de Identidad
**Estado:** Planificado
---
## Descripción
Los PLY representan la **identidad de actores** en el sistema: personas, empresas, agentes.
---
## Tipos
| Tipo | Descripción |
|------|-------------|
| **persona** | Usuario individual |
| **empresa** | Organización |
| **agente** | Sistema automatizado |
---
## Schema Propuesto
```sql
CREATE TABLE players (
id BIGSERIAL PRIMARY KEY,
h_player VARCHAR(64) UNIQUE NOT NULL,
tipo VARCHAR(50) NOT NULL,
nombre VARCHAR(255) NOT NULL,
email VARCHAR(255),
metadata JSONB,
activo BOOLEAN DEFAULT true,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
---
## Fórmula Hash
```
h_player = SHA-256(tipo:identificador_unico)
```
---
## Uso en el Sistema
Cada acción registrada incluye referencia al player:
```json
{
"h_bloque": "abc123...",
"h_player": "def456...",
"accion": "completó tarea X"
}
```
Esto permite:
- Trazabilidad de quién hizo qué
- Portfolio verificable por persona
- Auditoría sin ambigüedad

View File

@@ -1,167 +1,221 @@
# Arquitectura Overview
# Overview
**Versión:** 5.0
**Fecha:** 2024-12-24
**Versión:** 1.1
**Estado:** Definición
---
## Principio Fundamental
## Visión General
> **ARCHITECT es el constructor. DECK y CORP son instancias autónomas.**
- **ARCHITECT**: Construye, despliega, coordina. NO es dependencia runtime.
- **DECK/CORP**: Operan independientemente. Funcionan si ARCHITECT está caído.
Sistema de arquitecturas personales y empresariales. ARCHITECT (con Claude) construye y despliega servidores autónomos (DECK, CORP) que operan independientemente. Los componentes internos son microservicios backend, no IA. Las instancias están diseñadas para **consumir** servicios de IA externos (APIs, RunPod), no para contenerla.
---
## Diagrama General
## Arquitectura General
```
┌─────────────────────────────────────────────────────────────────────────
CAPA DE CONSTRUCCIÓN (solo deploy/dev)
│ ┌─────────────────────────────────────────────────────────────────┐ │
ARCHITECT (69.62.126.110)
┌──────────┐ ┌──────────┐ ┌────────────┐ ┌───────────────┐
│ │ │PostgreSQL│ │ Gitea │ │Orchestrator│ │ Infisical │ │ │
│ contexto │ │ 25 repos │ │ v5 │ │ (master)
│ └──────────┘ └──────────┘ └────────────┘ └───────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Rol: Construcción, deployment, gestión central de secretos
NO es dependencia runtime de las instancias
└─────────────────────────────────────────────────────────────────────────┘
deploy │ │ │ deploy
▼ ▼
┌─────────────────────────────────────────────────────────────────────────
CAPA DE INSTANCIAS (autónomas)
│ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │
│ │ DECK │ │ CORP │ │ HST │ │
│ │ 72.62.1.113 │ │ 92.112.181.188 │ │ 72.62.2.84 │ │
│ │ │ │ │ │ │ │
│ │ secretaria :5051 │ │ secretaria :5051 │ │ 973 tags │ │
│ │ producción :5052 │ │ producción :5052 │ │ API pública │ │
│ │ admin.vo :5053 │ │ admin.vo :5053 │ │ Directus :8055 │ │
│ │ contable :5054 │ │ contable :5054 │ │ │ │
│ │ │ │ │ │ │ │
│ │ Vaultwarden │ │ Odoo │ │ │ │
│ └───────────────────┘ │ Nextcloud │ └───────────────────┘ │
│ │ └───────────────────┘ │ │
│ │ │ │ │
│ └─────────────────────────┼──────────────────────┘ │
│ │ │
└───────────────────────────────────┼─────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────┐
│ CAPA DE ALMACENAMIENTO │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Cloudflare R2 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │
│ │ │architect │ │ deck │ │ corp │ │ hst │ │ locker │ │ │
│ │ │ backups │ │ archivos │ │ archivos │ │ imágenes │ │ general│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────┐
│ CAPA GPU (RunPod) │
│ Estado: BLOQUEADO - Workers no inician │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ GRACE │ │ PENNY │ │ FACTORY │ │
│ │ 18 módulos│ │ texto │ │generación│ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
ARCHITECT
PostgreSQL central │ Gitea │ Orchestrator │ Infisical
─────────────────────────────────────────────────────────────
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
DECK │ │ CORP │ │ HST
│ │ │ │
secretaría │ │ secretaría │ │ 973 tags
administración │ administración │ API pública
contable │ │ contable │ │
producción │ │ producción
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │
└────────┬───────────┘
┌─────────────────────────────────────────────────────────────┐
Cloudflare R2 (buckets)
architect │ deck │ corp │ hst │ locker
─────────────────────────────────────────────────────────────┘
```
---
## Flujo de Datos
## Flujo de Datos Principal
El sistema tiene dos flujos según el origen y completitud de la información:
### Diagrama General
```
PACKET (App móvil)
│ POST /ingest
Content-Type: multipart/form-data
X-Auth-Key: {h_instancia}
┌─────────────────────────────────────────┐
secretaria (CLARA / MARGARET)
1. Validar h_instancia
2. Calcular h_entrada (SHA-256)
3. Subir archivos a R2
4. Insertar en log
│ 5. Estado: 'recibido' (inmutable) │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
producción (ALFRED / JARED)
│ │
1. Definir orden de ejecución
2. Aplicar flujos predefinidos
3. Enviar a administrativo
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
administrativo (MASON)
1. Recibir de producción
2. Ventana flotante 24h
3. Usuario enriquece datos │
│ 4. [Futuro] GRACE extrae información
│ 5. Enviar a contable cuando listo
─────────────────────────────────────────
┌─────────────────────────────────────────┐
│ contable (FELDMAN)
1. Recibir en cola │
2. Validar reglas (M-001, M-002, M-003)
3. Crear milestone o bloque
│ 4. Calcular hash_contenido │
5. Encadenar (hash_previo)
6. [Futuro] Merkle tree, blockchain
─────────────────────────────────────────
┌─────────────────────────────────────────┐
│ auditoría (SENTINEL) [planificado] │
│ │
│ LIGHT: Cada 5 min, reglas automáticas │
│ DEEP: Cada 1 hora, muestreo con LLM │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ ORÍGENES
├─────────────────────────────────────────────────────────────┤
┌─────────────────┐ ┌─────────────────────────┐ │
│ │ PRODUCCIÓN │ │ ENTRADA MANUAL │
│ │ Alfred/Jared │ │ (Packet, API, manual) │ │
│ │ │ │ │ │
│ Flujos │ │ Datos incompletos
│ predefinidos │ o ad-hoc
└────────┬────────┘ └────────────┬────────────┘
│ │
│ (datos completos)
└───────────┼─────────────────────────────────┼──────────────┘
│ │
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ SECRETARÍA │
Clara / Margaret
├─────────────────────────────────────────────────────────────┤
• Punto de entrada ÚNICO
• Log inmutable
• Todo se registra exactamente como llega
└─────────────────────────────────────────────────────────────
┌────────────────┐
encaja no encaja
│ ┌─────────────────────────────────────────────────────┐
│ │ ADMINISTRACIÓN
│ │ Mason
│ ├─────────────────────────────────────────────────────
│ │ • Ventana de enriquecimiento (24h configurable)
│ │ • Usuario completa/corrige datos │
│ │ • Auto-envío si expira el tiempo │
└──────────────────────────┬──────────────────────────┘
└───────────────┬───────────────┘
┌─────────────────────────────────────────────────────────────┐
CONTABLE
Feldman
├─────────────────────────────────────────────────────────────
│ • Cola de validación (24h configurable)
• Consolidación en bloques inmutables │
│ • Encadenamiento hash (blockchain-style) │
└─────────────────────────────────────────────────────────────┘
```
### Regla de Decisión
| Condición | Ruta | Descripción |
|-----------|------|-------------|
| **Encaja** | Secretaría → Feldman | Datos completos de flujo predefinido |
| **No encaja** | Secretaría → Mason → Feldman | Entrada manual o incompleta |
### Flujo de Producción (encaja)
Cuando la información viene de un proceso predefinido y está completa:
```
Producción (Alfred/Jared)
│ flujo predefinido completo
Secretaría (Clara/Margaret) ← Registro inmutable
│ directo (salta Mason)
Contable (Feldman) ← Consolidación
```
### Flujo Estándar (no encaja)
Cuando la información es manual, ad-hoc o incompleta:
```
Entrada manual (Packet, API, etc.)
Secretaría (Clara/Margaret) ← Registro inmutable
Administración (Mason) ← Enriquecimiento (24h)
Contable (Feldman) ← Consolidación
```
---
## Comunicación Entre Servidores
## Auditoría (Sentinel)
| Origen | Destino | Protocolo | Puerto | Propósito |
|--------|---------|-----------|--------|-----------|
| DECK | ARCHITECT | SSH/Git | 2222 | Push repos |
| DECK | R2 | HTTPS | 443 | Almacenamiento |
| CORP | ARCHITECT | SSH/Git | 2222 | Push repos |
| CORP | R2 | HTTPS | 443 | Almacenamiento |
| HST | ARCHITECT | SSH | 22 | Administración |
| ARCHITECT | DECK | SSH | 22 | Deploy |
| ARCHITECT | CORP | SSH | 22 | Deploy |
Sentinel es un **componente independiente** que opera de forma transversal sobre el sistema:
```
┌─────────────────────────────────────────────────────────────┐
│ SENTINEL │
│ (Auditoría) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Monitoriza y verifica integridad en múltiples puntos: │
│ │
│ • Secretaría ←── verifica inmutabilidad del log │
│ • Mason ←── verifica ventanas temporales │
│ • Feldman ←── verifica encadenamiento de bloques │
│ │
│ Modos de operación: │
│ • LIGHT: verificación rápida (cada 5 min) │
│ • DEEP: auditoría completa (cada 1h) │
│ │
└─────────────────────────────────────────────────────────────┘
```
---
## Bases de Datos
## Principio de Diseño
| Servidor | Database | Tablas Principales |
|----------|----------|--------------------|
| ARCHITECT | architect | context_blocks, agents, creds_* |
| DECK | tzzr | clara_log, alfred_executions |
| CORP | corp | margaret_log, mason_workspace, feldman_* |
| HST | hst_images | hst_tags, hst_trees |
### Constructores, no gestores
ARCHITECT (con Claude) es un **constructor de arquitecturas**, no un gestor permanente.
- ARCHITECT diseña y construye la arquitectura de cada servidor
- Cuando la arquitectura esté madura, el servidor será **clonable e independiente**
- DECK y CORP funcionan sin conexión a ARCHITECT ni a Claude
- Son sistemas diseñados para **usar** servicios de IA (APIs externas, RunPod), no para contenerla
### Descentralización operativa
```
Architect App (centralizado) → Diseña moldes
Instancias reales (descentralizadas)
Cada una con su CORP, su DECK, sus agentes
```
---
## Modelo de Instancias
**DECK** y **CORP** son plantillas. En producción habrá múltiples instancias:
| Tipo | Ejemplos |
|------|----------|
| **DECK** | "Deck de Juan", "Deck de Victoria" |
| **CORP** | "Empresa A SL", "Empresa B Corp" |
Cada instancia:
- Tiene su propio bucket de almacenamiento
- Puede renombrar sus agentes
- **Opera de forma autónoma** (no depende de ARCHITECT en runtime)
- Tiene su propio gestor de secretos
- Hace sus propios backups a R2
---
## Servicios Compartidos (Opcionales)
Las instancias **pueden** conectarse a servicios GPU compartidos:
| Servicio | Función | Requerido |
|----------|---------|-----------|
| Grace | Extracción IA | Opcional |
| The Factory | Generación | Opcional |
| Circle | Colaboración | Opcional |
> **Nota:** Si los servicios compartidos no están disponibles, la instancia sigue operando. Solo las funciones de IA estarán limitadas.

View File

@@ -1,230 +0,0 @@
# Servidores TZZR
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## ARCHITECT (69.62.126.110)
**Rol:** Coordinador central del sistema
### Servicios
| Servicio | Puerto | Estado |
|----------|--------|--------|
| PostgreSQL | 5432 | Operativo |
| Gitea | 3000 (HTTP), 2222 (SSH) | Operativo |
| Orchestrator App | 5050 | Operativo |
| Infisical | 8082 | Operativo |
### PostgreSQL (database: architect)
| Tabla | Descripción |
|-------|-------------|
| context_blocks | 30 bloques de contexto atómicos |
| agent_context_index | Asignaciones agente-bloque |
| agents | 6 agentes definidos |
| creds_* | 6 tablas de credenciales |
| s_contract_contexts | Contextos IA |
| s_contract_datasets | Datasets IA |
### Acceso
```bash
# SSH
ssh orchestrator@69.62.126.110
# PostgreSQL
sudo -u postgres psql -d architect
# Gitea
http://localhost:3000
```
---
## DECK (72.62.1.113)
**Rol:** Servidor personal
### Servicios
| Servicio | Puerto | Estado |
|----------|--------|--------|
| CLARA | 5051 | Operativo |
| ALFRED | 5052 | Operativo |
| Mailcow (15 containers) | SMTP, IMAP | Operativo |
| Directus | 8055 | Operativo |
| FileBrowser | 8082 | Operativo |
| Shlink | 8083 | Operativo |
| Vaultwarden | 8085 | Operativo |
| ntfy | 8080 | Operativo |
### PostgreSQL (database: tzzr)
| Tabla | Descripción |
|-------|-------------|
| clara_log | Log inmutable de ingesta |
| deck_visiones | Visiones personales |
| deck_milestones | Milestones personales |
| deck_acciones | Acciones |
| deck_habitos | Hábitos |
| deck_bck | Bloques |
### Docker Containers
```
mailcowdockerized-acme-mailcow-1
mailcowdockerized-clamd-mailcow-1
mailcowdockerized-dovecot-mailcow-1
mailcowdockerized-mysql-mailcow-1
mailcowdockerized-netfilter-mailcow-1
mailcowdockerized-nginx-mailcow-1
mailcowdockerized-olefy-mailcow-1
mailcowdockerized-php-fpm-mailcow-1
mailcowdockerized-postfix-mailcow-1
mailcowdockerized-redis-mailcow-1
mailcowdockerized-rspamd-mailcow-1
mailcowdockerized-sogo-mailcow-1
mailcowdockerized-solr-mailcow-1
mailcowdockerized-unbound-mailcow-1
mailcowdockerized-watchdog-mailcow-1
clara-clara
alfred-alfred
directus
filebrowser
shlink
vaultwarden
ntfy
```
### Acceso
```bash
ssh -i ~/.ssh/tzzr root@72.62.1.113
```
---
## CORP (92.112.181.188)
**Rol:** Servidor empresarial
### Servicios
| Servicio | Puerto | Estado |
|----------|--------|--------|
| MARGARET | 5051 | Operativo |
| JARED | 5052 | Operativo |
| MASON | 5053 | Operativo |
| FELDMAN | 5054 | Operativo |
| PostgreSQL | 5432 | Operativo |
| Directus | 8055 | Operativo |
| Nextcloud | 8080 | Operativo |
| Vaultwarden | 8081 | Operativo |
| Odoo | 8069 | Operativo |
| Caddy | 80/443 | Operativo |
### PostgreSQL (database: corp)
| Tabla | Descripción |
|-------|-------------|
| margaret_log | Log inmutable de ingesta |
| mason_workspace | Espacio de enriquecimiento |
| feldman_cola | Cola de consolidación |
| feldman_bloques | Bloques inmutables |
| feldman_validaciones | Auditoría validaciones |
| milestones | Plano MST |
| bloques | Plano BCK |
| hst_mirror | Mirror de tags HST |
### Acceso
```bash
ssh -i ~/.ssh/tzzr root@92.112.181.188
```
---
## HST (72.62.2.84)
**Rol:** API de tags semánticos
### Servicios
| Servicio | Puerto | Estado |
|----------|--------|--------|
| Nginx | 80/443 | Operativo |
| Directus | 8055 | Operativo |
| PostgreSQL | 5432 | Operativo |
### Estadísticas HST
| Grupo | Cantidad |
|-------|----------|
| hst | 639 |
| spe | 145 |
| vsn | 84 |
| flg | 65 |
| vue | 21 |
| **Total** | **973** |
### API
```
https://tzrtech.org/{h_maestro}.png # Imagen de tag
```
### Acceso
```bash
ssh -i ~/.ssh/tzzr root@72.62.2.84
```
---
## LOCKER (Cloudflare R2)
**Rol:** Almacenamiento distribuido
### Endpoint
```
https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
```
### Buckets
| Bucket | Uso |
|--------|-----|
| architect | Backups Gitea, configs, GPU services |
| deck | Archivos personales (CLARA) |
| corp | Archivos empresariales (MARGARET) |
| hst | Imágenes de tags |
| locker | Almacenamiento general/temporal |
### Estructura GPU Services
```
s3://architect/gpu-services/
├── base/
│ └── bootstrap.sh
├── grace/
│ └── code/handler.py
├── penny/
│ └── code/handler.py
└── factory/
└── code/handler.py
```
---
## Resumen de IPs
| Servidor | IP Pública | IP Interna |
|----------|------------|------------|
| ARCHITECT | 69.62.126.110 | localhost |
| DECK | 72.62.1.113 | - |
| CORP | 92.112.181.188 | - |
| HST | 72.62.2.84 | - |

58
02_COMPONENTES/README.md Normal file
View File

@@ -0,0 +1,58 @@
# 02 - Componentes
> Servicios y agentes del sistema TZZR
## Estructura
Los componentes se dividen en dos categorías:
- **Internos**: Servicios core que operan dentro del sistema
- **Servicios Externos**: Integraciones y servicios que operan fuera del núcleo
## Componentes Internos
Servicios fundamentales que gestionan el flujo de datos.
| Componente | Archivo | Agente | Rol |
|------------|---------|--------|-----|
| Context System | [context-system.md](internos/context-system.md) | - | Log inmutable, gestor de contexto, dataset, grafo |
| Secretaría | [secretaria.md](internos/secretaria.md) | Clara / Margaret | Gestión de comunicaciones y agenda |
| Administración | [administracion.md](internos/administracion.md) | Mason | Edición temporal de registros |
| Contable | [contable.md](internos/contable.md) | Feldman | Consolidación financiera, inmutabilidad |
| Producción | [produccion.md](internos/produccion.md) | Alfred / Jared | Ejecución de tareas y workflows |
| Auditoría | [auditoria.md](internos/auditoria.md) | Sentinel | Verificación LIGHT y DEEP |
| Utilidades | [utilidades.md](internos/utilidades.md) | - | Funciones auxiliares del sistema |
### Agentes por Contexto
| Contexto | Secretaría | Producción |
|----------|------------|------------|
| Personal | Clara | Alfred |
| Corporativo | Margaret | Jared |
## Servicios Externos
Servicios que extienden las capacidades del sistema.
| Servicio | Archivo | Descripción |
|----------|---------|-------------|
| Asistente | [asistente.md](servicios%20externos/asistente.md) | Penny - interfaz de voz conversacional |
| Gestoría | [gestoria.md](servicios%20externos/gestoria.md) | Gestión administrativa y fiscal externa |
| Gen. Iterativa | [generacion-iterativa.md](servicios%20externos/generacion-iterativa.md) | The Factory - generación de contenido |
| Orchestrator | [orchestratorv6.md](servicios%20externos/orchestratorv6.md) | Orquestación multi-agente LLM |
| Circle | [circle.md](servicios%20externos/circle.md) | Consejo de perspectivas múltiples |
| Cloudville | [cloudville.md](servicios%20externos/cloudville.md) | Laboratorio experimental |
## Flujo de Datos
```
Usuario → [Secretaría] → [Context System] → [Producción]
[Contable]
[Auditoría]
```
---
[← Volver al índice](../README.md)

View File

@@ -0,0 +1,106 @@
# Administración
**Nombre:** Mason
**Estado:** Implementado
---
## Descripción
Tabla de trabajo temporal donde se enriquece, procesa y consolida la información antes de su registro definitivo.
---
## Características
| Característica | Valor |
|----------------|-------|
| Mutabilidad | Editable |
| Persistencia | **Temporal** |
| Eliminación | Siempre se elimina tras consolidar |
---
## Función
```
Secretaría (entrada)
┌─────────────────┐
│ Administración │
│ Mason │
├─────────────────┤
│ • Enriquecer │
│ • Validar │
│ • Completar │
│ • Corregir │
└────────┬────────┘
Contable (Feldman)
```
---
## Ventana Flotante
| Parámetro | Valor |
|-----------|-------|
| Duración | 24 horas |
| Durante | Modificable |
| Después | Pasa a Feldman automáticamente |
---
## Operaciones Permitidas
| Operación | Permitido |
|-----------|-----------|
| Editar campos | ✓ |
| Añadir datos | ✓ |
| Corregir errores | ✓ |
| Eliminar registro | ✗ (solo consolidar) |
| Modificar h_entrada | ✗ |
---
## Referencia a Origen
Mason siempre mantiene referencia al registro original en Secretaría:
```json
{
"id": 123,
"h_entrada_origen": "abc123...",
"datos_enriquecidos": { ... },
"estado": "en_edicion"
}
```
---
## Estados
| Estado | Descripción |
|--------|-------------|
| **en_edicion** | Usuario trabajando |
| **listo** | Preparado para consolidar |
| **consolidado** | Ya pasó a Feldman |
---
## Schema
```sql
CREATE TABLE mason_temporal (
id BIGSERIAL PRIMARY KEY,
h_entrada_origen VARCHAR(64) NOT NULL,
datos JSONB NOT NULL,
estado VARCHAR(20) DEFAULT 'en_edicion',
created_at TIMESTAMPTZ DEFAULT NOW(),
expires_at TIMESTAMPTZ,
modified_at TIMESTAMPTZ,
modified_by VARCHAR(64)
);
```

View File

@@ -0,0 +1,204 @@
# Auditoría
**Nombre:** Sentinel
**Estado:** Planificado
---
## Descripción
Sistema de auditoría automatizada con estrategia dual: LIGHT (rápido, exhaustivo) y DEEP (selectivo, profundo).
```
┌─────────────────────────────────────────────────────────────────┐
│ PRINCIPIO SENTINEL │
│ │
│ "Confía, pero verifica. Verifica todo, siempre, sin excepción" │
└─────────────────────────────────────────────────────────────────┘
```
---
## Filosofía Dual
| Aspecto | SENTINEL-LIGHT | SENTINEL-DEEP |
|---------|----------------|---------------|
| Analogía | Guardia de seguridad | Detective investigador |
| Enfoque | Exhaustivo, superficial | Selectivo, profundo |
| Motor | Reglas + ML ligero | LLM pesado |
| Frecuencia | Cada 5 min | Cada hora |
| Costo | Mínimo | Variable |
---
## SENTINEL-LIGHT
### Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ SENTINEL-LIGHT │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ RULES │ │ STATS │ │ ALERTS │ │
│ │ ENGINE │───▶│ COLLECTOR │───▶│ DISPATCHER │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────┤
│ │ SYS_LOG (Source) │
│ └─────────────────────────────────────────────────────────────┤
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┤
│ │ AUDIT_RESULTS (Sink) │
│ └─────────────────────────────────────────────────────────────┤
│ │
└─────────────────────────────────────────────────────────────────┘
```
### Ciclo de Ejecución (cada 5 min)
```
1. QUERY
SELECT * FROM SYS_LOG
WHERE audit_status = 'PENDING'
AND timestamp_created > NOW() - INTERVAL '10 minutes'
LIMIT 1000
2. APPLY RULES
Para cada registro:
- Ejecutar reglas de integridad
- Ejecutar reglas de conformidad
- Ejecutar reglas de rendimiento
3. CLASSIFY
- PASS: Todas las reglas OK
- WARN: Reglas MEDIUM fallaron
- FAIL: Reglas HIGH/CRITICAL fallaron
4. UPDATE & ESCALATE
- UPDATE SYS_LOG SET audit_status
- INSERT AUDIT_RESULTS
- Si FAIL → marcar para DEEP
- Si CRITICAL → alerta inmediata
```
---
## Reglas de Integridad (I-*)
| Regla | Nombre | Severidad | Condición |
|-------|--------|-----------|-----------|
| I-001 | Hash entrada coincide | CRITICAL | input_hash == SHA256(archivo) |
| I-002 | Hash salida coincide | CRITICAL | output_hash == SHA256(archivo) |
| I-003 | Cadena trazas válida | HIGH | parent_trace_id existe o es null |
| I-004 | Referencias no huérfanas | HIGH | input_ref y output_ref existen |
| I-005 | Idempotency key única | MEDIUM | No duplicados con distinto resultado |
---
## Reglas de Conformidad (C-*)
| Regla | Nombre | Severidad | Condición |
|-------|--------|-----------|-----------|
| C-001 | Campos obligatorios | HIGH | Todos los campos requeridos presentes |
| C-002 | Status code válido | HIGH | status_code en lista permitida |
| C-003 | Step type válido | HIGH | step_type en lista permitida |
| C-004 | Confidence en rango | MEDIUM | 0 <= confidence <= 1 |
| C-005 | Timestamps coherentes | MEDIUM | completed >= started >= created |
---
## Reglas de Rendimiento (P-*)
| Regla | Nombre | Severidad | Condición |
|-------|--------|-----------|-----------|
| P-001 | Latencia aceptable | MEDIUM | duration_ms <= expected * 2 |
| P-002 | Costo razonable | MEDIUM | cost_units <= max_expected |
| P-003 | Sin reintentos excesivos | LOW | retries <= 3 |
---
## SENTINEL-DEEP
### Cuándo se Activa
- Regla CRITICAL falló en LIGHT
- Muestreo aleatorio (5% de registros PASS)
- Petición manual de auditoría
### Qué Hace
```
┌─────────────────────────────────────────────────────────────────┐
│ SENTINEL-DEEP │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Obtener contexto completo del registro │
│ 2. Recuperar archivos de input_ref y output_ref │
│ 3. Analizar con LLM: │
│ - ¿El output es coherente con el input? │
│ - ¿Hay anomalías semánticas? │
│ - ¿La confianza reportada es realista? │
│ 4. Generar informe detallado │
│ 5. Si anomalía → alerta + bloqueo │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Niveles de Severidad
| Nivel | Acción | Alerta |
|-------|--------|--------|
| **CRITICAL** | Escalado inmediato + DEEP | Inmediata |
| **HIGH** | Log error + revisar | Batch (cada hora) |
| **MEDIUM** | Log warning | Batch (diario) |
| **LOW** | Log info | Ninguna |
---
## Schema SQL
```sql
CREATE TABLE audit_results (
id BIGSERIAL PRIMARY KEY,
batch_id UUID NOT NULL,
audit_type VARCHAR(10) NOT NULL, -- 'LIGHT' o 'DEEP'
records_checked INTEGER NOT NULL,
records_pass INTEGER NOT NULL,
records_warn INTEGER NOT NULL,
records_fail INTEGER NOT NULL,
rules_triggered JSONB,
started_at TIMESTAMPTZ NOT NULL,
completed_at TIMESTAMPTZ,
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Índice para búsqueda por fecha
CREATE INDEX idx_audit_results_created ON audit_results(created_at);
```
---
## Métricas
| Métrica | Descripción | Umbral |
|---------|-------------|--------|
| pass_rate | % registros que pasan | > 99% |
| avg_latency_ms | Latencia promedio | < 100ms |
| escalation_rate | % escalados a DEEP | < 1% |
| alert_rate | Alertas por hora | < 5 |
---
## Pendiente
- [ ] Implementación scheduler LIGHT (cada 5 min)
- [ ] Implementación scheduler DEEP (cada hora)
- [ ] Dashboard de estado
- [ ] Sistema de alertas (ntfy)
- [ ] Integración con Feldman para verificar cadena de bloques

View File

@@ -0,0 +1,230 @@
# Captain Claude API v3
API para interactuar con Claude Code desde aplicaciones móviles/web.
## Información General
| Campo | Valor |
|-------|-------|
| **Servidor** | ARCHITECT (69.62.126.110) |
| **Puerto** | 3030 |
| **Protocolo** | HTTP + WebSocket |
| **Dominio externo** | captain.tzzrarchitect.me |
| **Ubicación código** | `/home/architect/captain-claude/apps/captain-mobile-v2/backend/captain_api_v3.py` |
## Autenticación
JWT Bearer Token. Obtener via `/auth/login`.
```bash
curl -X POST https://captain.tzzrarchitect.me/auth/login \
-H "Content-Type: application/json" \
-d '{"username":"admin","password":"***"}'
```
Respuesta:
```json
{
"token": "eyJ...",
"username": "admin"
}
```
## Endpoints REST
### GET /health
Estado del servicio.
```json
{"status": "ok", "version": "3.0.0"}
```
### POST /auth/login
Autenticación.
**Request:**
```json
{
"username": "string",
"password": "string"
}
```
**Response:**
```json
{
"token": "string",
"username": "string"
}
```
### GET /sessions
Lista sesiones activas. Requiere Bearer token.
**Response:**
```json
[
{
"session_id": "abc123...",
"name": "Mi sesión"
}
]
```
### POST /sessions
Crear nueva sesión. Requiere Bearer token.
**Request:**
```json
{
"name": "Nombre de la sesión"
}
```
**Response:**
```json
{
"session_id": "abc123...",
"name": "Nombre de la sesión"
}
```
## WebSocket
### Endpoint
```
wss://captain.tzzrarchitect.me/ws/chat
```
### Flujo de conexión
1. Conectar al WebSocket
2. Enviar autenticación:
```json
{"type": "auth", "token": "eyJ..."}
```
3. Recibir confirmación con sesiones existentes:
```json
{
"type": "init",
"sessions": [{"session_id": "...", "name": "..."}]
}
```
### Mensajes Cliente → Servidor
#### Crear sesión
```json
{
"type": "create_session",
"name": "Nombre de la sesión"
}
```
#### Conectar a sesión existente
```json
{
"type": "connect_session",
"session_id": "abc123..."
}
```
#### Enviar mensaje a Claude
```json
{
"type": "message",
"content": "Hola Claude"
}
```
### Mensajes Servidor → Cliente
#### Sesión creada
```json
{
"type": "session_created",
"session_id": "abc123...",
"name": "Nombre"
}
```
#### Conectado a sesión
```json
{
"type": "session_connected",
"session_id": "abc123...",
"name": "Nombre"
}
```
#### Output de Claude (streaming)
```json
{
"type": "output",
"content": "Texto de respuesta..."
}
```
#### Respuesta completada
```json
{
"type": "done",
"session_id": "uuid-de-claude"
}
```
#### Error
```json
{
"type": "error",
"message": "Descripción del error"
}
```
## Arquitectura
```
┌─────────────┐ HTTPS/WSS ┌─────────────┐
│ App Móvil │ ◄────────────────► │ Caddy │
│ (Flutter) │ │ (reverse │
└─────────────┘ │ proxy) │
└──────┬──────┘
│ :3030
┌──────▼──────┐
│ Captain API │
│ v3 (uvicorn)│
└──────┬──────┘
│ subprocess
┌──────▼──────┐
│ Claude Code │
│ (claude -p) │
└─────────────┘
```
## Notas
- **Sin screen**: v3 usa `claude -p` directamente como subprocess, no sesiones screen
- **Session ID**: El `session_id` inicial es temporal. Después del primer mensaje, se actualiza con el UUID real de Claude para poder hacer `--resume`
- **Streaming**: Las respuestas se envían en tiempo real vía WebSocket
- **Concurrencia**: Una sesión solo procesa un mensaje a la vez
## Servicio systemd
```ini
[Unit]
Description=Captain Claude API v3
After=network.target
[Service]
Type=simple
User=architect
WorkingDirectory=/home/architect/captain-claude/apps/captain-mobile-v2/backend
ExecStart=/home/architect/captain-claude/apps/captain-mobile-v2/backend/venv/bin/uvicorn captain_api_v3:app --host 0.0.0.0 --port 3030
Restart=always
[Install]
WantedBy=multi-user.target
```
---
*Última actualización: 2026-01-21*

View File

@@ -0,0 +1,122 @@
# Contable
**Nombre:** Feldman
**Estado:** Implementado
---
## Descripción
Registro final definitivo e inmutable. Representa el estado válido y oficial de cada operación. Aplica principios contables de inmutabilidad.
---
## Características
| Característica | Valor |
|----------------|-------|
| Mutabilidad | **Inmutable** |
| Persistencia | Permanente |
| Eliminación | Prohibida bajo ningún concepto |
---
## Estructura Interna
Feldman es una **unidad conceptual** que contiene dos tablas:
```
┌─────────────────────────────────────────────────────────────────┐
│ FELDMAN │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Cola de Validación │ → │ Registro Final │ │
│ │ (espera bloques) │ │ (inmutable) │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
**Aclaración:** La división es **técnica** (tiempo entre validaciones), no conceptual.
---
## Validación por Bloques
| Aspecto | Valor |
|---------|-------|
| Frecuencia | Periódica |
| Tipo | Por bloques, no transacción a transacción |
| Reglas | M-001, M-002, M-003 |
### Reglas de Validación
| Regla | Nombre | Descripción |
|-------|--------|-------------|
| M-001 | Hash único | h_bloque/h_milestone no existe previamente |
| M-002 | Encadenamiento | hash_previo apunta a bloque existente |
| M-003 | Integridad | hash_contenido = SHA-256(contenido) |
---
## Encadenamiento
```
Bloque N-1 Bloque N
┌──────────────────┐ ┌──────────────────┐
│ h_bloque: abc123 │ ──────► │ hash_previo: │
│ hash_contenido: │ │ abc123 │
│ def456 │ │ h_bloque: ghi789 │
│ secuencia: 1 │ │ secuencia: 2 │
└──────────────────┘ └──────────────────┘
```
---
## Schema Cola
```sql
CREATE TABLE feldman_cola (
id BIGSERIAL PRIMARY KEY,
tipo VARCHAR(50) NOT NULL,
h_entrada VARCHAR(64) NOT NULL,
contenido JSONB NOT NULL,
prioridad INTEGER DEFAULT 0,
estado VARCHAR(20) DEFAULT 'pendiente',
created_at TIMESTAMPTZ DEFAULT NOW(),
processed_at TIMESTAMPTZ
);
```
---
## Schema Registro Final
```sql
CREATE TABLE bloques (
id BIGSERIAL PRIMARY KEY,
h_bloque VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64) NOT NULL,
tipo_bloque VARCHAR(50) NOT NULL,
contenido JSONB NOT NULL,
metadata JSONB,
estado VARCHAR(20) DEFAULT 'consolidado',
created_at TIMESTAMPTZ DEFAULT NOW(),
validated_at TIMESTAMPTZ,
UNIQUE (h_instancia, secuencia)
);
```
---
## Trazabilidad
Cualquier registro en Feldman puede rastrearse hasta Secretaría:
```
Bloque (Feldman) → h_entrada → Secretaría (Clara/Margaret)
```

View File

@@ -0,0 +1,150 @@
# Context System
**Versión:** 0.1
**Estado:** Especificación inicial
---
## Descripción
Herramienta local para gestionar el contexto de trabajo con modelos de IA. Funciona de forma idéntica en cualquier servidor. No depende de servicios externos.
---
## Principios
1. **Local first** - Todo funciona sin conexión a servicios externos
2. **Inmutabilidad del log** - El historial nunca se modifica
3. **Control del usuario** - El usuario decide qué contexto envía
4. **Independencia** - Cada componente funciona por separado
5. **Portabilidad** - La misma herramienta en cualquier servidor
---
## Componentes
### 1. Log Inmutable
Registro de TODOS los mensajes de conversaciones con IA.
| Característica | Valor |
|----------------|-------|
| Editable | NO |
| Borrable | NO |
| Ubicación | Local (PostgreSQL) |
**Contenido:**
- Cada mensaje enviado a la IA
- Cada respuesta recibida
- Timestamp
- Identificador de sesión
### 2. Gestor de Contexto
| Característica | Valor |
|----------------|-------|
| Editable | Sí |
| Borrable | Sí |
| Ubicación | Local |
**Contenido:**
- Bloques de contexto reutilizables
- Configuración de qué se incluye en cada sesión
- Prioridades y orden
### 3. Dataset del Usuario
| Característica | Valor |
|----------------|-------|
| Editable | Sí |
| Borrable | Sí |
| Ubicación | Local |
**Contenido:**
- Referencias a archivos, documentos, datos
- Metadatos para búsqueda y acceso
- Estructura del espacio de trabajo
### 4. Buzón de Entrada
| Característica | Valor |
|----------------|-------|
| Editable | Según implementación |
| Ubicación | Local |
**Contenido:**
- Resultados que el usuario quiere persistir
- Datos que entran al sistema
- Conexión con almacenamiento externo
---
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ SERVIDOR (local) │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 1. LOG │ │ 2. GESTOR │ │
│ │ INMUTABLE │ │ DE CONTEXTO │ │
│ │ [NO editable] │ │ [Editable] │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 3. DATASET │ │ 4. BUZÓN │ │
│ │ DEL USUARIO │ │ DE ENTRADA │ │
│ │ [Editable] │ │ [E/S datos] │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────┐
│ IA EXTERNA │
│ (no en local) │
└─────────────────┘
```
---
## Módulo Grafo (Kuzu)
Capa de selección dinámica de contexto. El grafo no almacena datos primarios — es una proyección reconstruible del log.
```
LOG (inmutable) → GRAFO (derivado) → Contexto seleccionado
fuente de verdad caché relaciones input para LLM
```
### Tecnología: Kuzu
| Criterio | Kuzu |
|----------|------|
| Instalación | `pip install kuzu` |
| Dependencias | Ninguna |
| Servidor | No requiere |
| Persistencia | Carpeta local |
| Licencia | MIT |
### Uso Básico
```python
import kuzu
db = kuzu.Database("./grafo_contexto")
conn = kuzu.Connection(db)
# Crear esquema
conn.execute("CREATE NODE TABLE Mensaje(id INT64, hash STRING, PRIMARY KEY(id))")
conn.execute("CREATE NODE TABLE Concepto(nombre STRING, PRIMARY KEY(nombre))")
conn.execute("CREATE REL TABLE Menciona(FROM Mensaje TO Concepto)")
```
### Mantenimiento
| Tarea | Comando |
|-------|---------|
| Backup | `cp -r ./grafo_contexto ./backup` |
| Borrar | `rm -rf ./grafo_contexto` |
| Regenerar | Script desde log |

View File

@@ -0,0 +1,253 @@
# Oracle (Prospectiva)
**Estado:** Especificación completa - Implementación pendiente
**Puerto propuesto:** 5055
## Descripción
Módulo de análisis prospectivo del Sistema de Registro Inmutable. Permite explorar escenarios futuros mediante la manipulación de supuestos inciertos, manteniendo inmutables los datos históricos y el modelo de cálculo.
```
┌─────────────────────────────────────────────────────────────────┐
│ PRINCIPIO ORACLE │
│ │
│ "No predecimos el futuro. Documentamos qué pasaría │
│ SI ciertos supuestos se cumplen. │
│ La honestidad está en los supuestos, no en el resultado." │
│ │
└─────────────────────────────────────────────────────────────────┘
```
## Ficha Técnica
| Atributo | Valor |
|----------|-------|
| Nombre | Oracle |
| Descriptor | prospectiva |
| Versión personal | Oracle (DECK) |
| Versión corporativa | Oracle (CORP) |
| Puerto | 5055 |
| Mutabilidad | Inmutable post-emisión |
| Persistencia | Permanente |
| Eliminación | Prohibida |
## Posición en el Sistema
Oracle implementa la **Capa 2: Análisis Prospectivo** del marco de Contabilidad Bifurcada:
```
┌─────────────────────────────────────────────────────────────────┐
│ CAPA 1: REGISTRO HISTÓRICO (implementada) │
│ Clara/Margaret → Mason → Feldman → [NOTARIO] │
│ Hechos consumados, inmutables, verificables │
└─────────────────────────────────────────────────────────────────┘
│ alimenta (solo lectura)
┌─────────────────────────────────────────────────────────────────┐
│ CAPA 2: ANÁLISIS PROSPECTIVO (Oracle) │
│ Supuestos explícitos + Escenarios + Sensibilidad │
│ Proyecciones documentadas, auditables, no vinculantes │
└─────────────────────────────────────────────────────────────────┘
```
## Flujo de Datos
```
Feldman (libros contables)
│ consulta (solo lectura)
Oracle (prospectiva)
├── Genera análisis con hash (mrf)
├── Usuario explora escenarios
├── Guarda escenarios (inmutables)
[Almacenamiento propio de Oracle]
│ [cuando el horizonte temporal se cumple]
Contraste con realidad (datos nuevos de Feldman)
└── Métricas de calibración
```
## Relación con Componentes
| Componente | Relación | Descripción |
|------------|----------|-------------|
| **Feldman** | Entrada (solo lectura) | Única fuente de datos. Oracle nunca escribe en Feldman |
| **Grace** | Colaboración | Ejecuta modelos vía S-CONTRACT, sugiere supuestos |
| **Sentinel** | Verificación | Valida integridad de análisis y escenarios |
| **ITM** | Informativo | Oracle puede evaluar viabilidad de items/objetivos |
| **MST** | Informativo | Oracle puede evaluar probabilidad de cumplimiento |
| **BCK** | Calibración | Bloques consolidados permiten contrastar predicción vs realidad |
## Arquitectura del Análisis
Cada análisis Oracle es una unidad atómica con 7 secciones:
### 1. Datos Base
| Campo | Tipo | Descripción |
|-------|------|-------------|
| h_bloques_feldman | Array[mrf] | Referencias a bloques de Feldman |
| periodo_inicio | Date | Inicio del período histórico |
| periodo_fin | Date | Fin del período histórico |
| h_dataset | mrf | Hash de integridad del conjunto |
### 2. Supuestos
Lista exhaustiva de afirmaciones no verificables:
| Campo | Tipo | Descripción |
|-------|------|-------------|
| id | String | Identificador (ej: SUP_001) |
| name_es | String | Nombre en español |
| txt | Text | Descripción |
| tipo | Enum | porcentaje, moneda, cantidad, booleano |
| valor_defecto | Numeric | Valor por defecto |
| rango_min | Numeric | Mínimo plausible |
| rango_max | Numeric | Máximo plausible |
| fuente_tipo | Enum | histórico, estimación_externa, juicio_experto |
| confianza | Enum | alta, media, baja |
### 3. Modelo
| Campo | Tipo | Descripción |
|-------|------|-------------|
| name_es | String | Nombre del modelo |
| version | String | Versión del modelo |
| metodologia | Text | Descripción de la metodología |
| formulas | JSONB | Fórmulas de cálculo |
| limitaciones | Text | Condiciones de no aplicabilidad |
### 4. Escenarios (Obligatorios)
| Escenario | Descripción |
|-----------|-------------|
| **Base** | Supuestos en valores por defecto |
| **Optimista** | Supuestos ajustados favorablemente |
| **Pesimista** | Supuestos ajustados desfavorablemente |
| **Estrés** | Límites del modelo - qué tendría que pasar para resultado inaceptable |
### 5. Sensibilidad
| Campo | Tipo | Descripción |
|-------|------|-------------|
| contribucion | JSONB | % de cada supuesto en varianza total |
| supuestos_criticos | Array | Top 3 supuestos más influyentes |
### 6. Resultado
Nunca cifra única:
| Campo | Tipo | Descripción |
|-------|------|-------------|
| rango_min | Numeric | Límite inferior |
| rango_max | Numeric | Límite superior |
| punto_medio | Numeric | Valor central |
| horizonte | String | Período de proyección |
| unidad | String | Unidad de medida |
### 7. Metadata
| Campo | Tipo | Descripción |
|-------|------|-------------|
| mrf | VARCHAR(64) | Hash público del análisis |
| private_mrf | VARCHAR(64) | Hash privado (prueba de propiedad) |
| date | Date | Fecha de emisión |
| fecha_caducidad | Date | Cuándo expira el análisis |
| condiciones_invalidacion | Text | Qué haría el análisis inaplicable |
## Interfaz de Escenarios
```
┌─────────────────────────────────────────────────────────────────┐
│ PRINCIPIO DE SEPARACIÓN │
│ │
│ INMUTABLE (no se toca) VARIABLE (el usuario mueve) │
│ ---------------------- -------------------------- │
│ - Datos históricos - Supuestos macro │
│ - Fórmulas del modelo - Tasas estimadas │
│ - Reglas de cálculo - Probabilidades asignadas │
│ - Metodología aplicada - Horizontes temporales │
│ │
│ "Cambias lo incierto, no lo calculado" │
│ │
└─────────────────────────────────────────────────────────────────┘
```
Cada supuesto se presenta como slider con:
- Nombre descriptivo
- Valor actual (posición del slider)
- Rango Min-Max
- Fuente del valor por defecto
- Indicador de confianza (alta/media/baja)
Cada movimiento dispara recálculo en tiempo real.
## Reglas de Validación (O-*)
| Código | Nombre | Descripción | Severidad |
|--------|--------|-------------|-----------|
| O-001 | Trazabilidad total | Todo dato debe tener mrf de Feldman | CRITICAL |
| O-002 | Supuesto explícito | Ningún supuesto implícito permitido | CRITICAL |
| O-003 | Sin cifra única | Resultados siempre como rango | HIGH |
| O-004 | Modelo nombrado | No metodologías ad-hoc | HIGH |
| O-005 | Caducidad obligatoria | fecha_caducidad requerido | HIGH |
| O-006 | Condición invalidación | condiciones_invalidacion requerido | HIGH |
| O-007 | Conservación permanente | Eliminación prohibida | CRITICAL |
| O-008 | Escenarios obligatorios | Los 4 escenarios requeridos | HIGH |
| O-009 | Sensibilidad visible | Campo sensibilidad requerido | MEDIUM |
| O-010 | Inmutabilidad post-emisión | Solo INSERT, nunca UPDATE | CRITICAL |
## Integración con Grace (S-CONTRACT)
| Módulo Grace | Uso en Oracle |
|--------------|---------------|
| PREDICTOR | Generar pronósticos base |
| CLUSTERER | Agrupar escenarios similares |
| SCORER | Evaluar calidad de supuestos |
| NARRATOR | Generar informe en lenguaje natural |
| AUDITOR | Detectar anomalías en proyecciones |
## Ciclo de Retroalimentación
Cuando el horizonte temporal se cumple:
1. Oracle recupera datos reales de Feldman
2. Compara supuestos usados vs valores reales
3. Compara resultado proyectado vs resultado observado
4. Calcula % error por supuesto incorrecto vs limitación modelo
## Métricas de Calibración
| Métrica | Descripción |
|---------|-------------|
| Sesgo de supuestos | "Tus estimaciones de crecimiento son 15% optimistas" |
| Precisión de rangos | "90% de veces el resultado cayó en tu rango" |
| Sensibilidad real vs estimada | "Dijiste inflación, pero fue tipo de cambio" |
## Lo que Oracle NO es
- No es sistema de alertas
- No toma decisiones
- No modifica datos de Feldman
- No genera "la respuesta correcta"
- No sustituye juicio humano
## Limitaciones Conocidas
| Limitación | Descripción |
|------------|-------------|
| No captura cisnes negros | Eventos radicalmente improbables no aparecen |
| Depende de calidad Feldman | Datos incorrectos = análisis heredan problemas |
| Modelos son simplificaciones | No capturan toda la realidad |
| Pasado no garantiza futuro | Cambios de régimen difíciles de anticipar |
---
*SKYNET v10.1 - Oracle - 6 Enero 2026*

View File

@@ -0,0 +1,106 @@
# Producción
**Nombres:** Alfred (personal), Jared (corporativo)
**Estado:** Implementado
---
## Descripción
Almacena flujos y secuencias de procesos predefinidos. Pueden ser complejos (árboles de procesos de producción) o simples (rutinas de entrenamiento).
---
## Características
| Característica | Valor |
|----------------|-------|
| Mutabilidad | Editable |
| Persistencia | Permanente |
| Eliminación | Permitida |
---
## Función
- Tiene su propia tabla para definiciones de flujos
- La información ya está disponible y ordenada
- Permite ejecución directa sin intervención manual
- Implementación: Windmill (orquestador de procesos)
---
## Alfred vs Jared
| Aspecto | Alfred | Jared |
|---------|--------|-------|
| Contexto | Personal (DECK) | Corporativo (CORP) |
| Complejidad | Menor | Mayor (múltiples usuarios) |
| Flujos | Simples | Complejos |
---
## Flujo de Producción
Cuando la información **encaja** (viene de un proceso predefinido):
```
Alfred/Jared (producción)
Clara/Margaret (secretaría) ← Registro inmutable
Feldman (contable) ← Consolidación directa
```
**Nota:** Este flujo salta Administración porque no hay nada que enriquecer.
---
## Decisión de Flujo
```
┌─────────────────┐
│ ¿Encaja? │
└────────┬────────┘
┌────┴────┐
│ │
SÍ NO
│ │
▼ ▼
Feldman Mason
(directo) (enriquecer)
```
---
## Relación con Grace
```
Alfred/Jared (decide) ──► Grace (transforma)
```
- **Producción** decide el flujo
- **Grace** transforma los datos
---
## Mapeo de Intenciones
```javascript
// Ejemplo de decisiones de Alfred
"resumir" GRACE.SUMMARIZER
"transcribir" GRACE.ASR_ENGINE
"generar plan" PENNY
"crear imagen" FACTORY
```
---
## Pendiente
- [ ] Estructura de la tabla de flujos
- [ ] Formato de definición de flujos
- [ ] Mecanismo de hashes para "encaja/no encaja"

View File

@@ -0,0 +1,105 @@
# Secretaría
**Nombres:** Clara (personal), Margaret (corporativo)
**Estado:** Implementado
---
## Descripción
Punto de entrada inmutable del sistema. Todo dato que ingresa queda registrado exactamente como llegó.
---
## Principio
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Todo lo que entra se registra. │
│ Nada se modifica. Nada se elimina. │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Características
| Característica | Valor |
|----------------|-------|
| Mutabilidad | **Inmutable** |
| Persistencia | Permanente |
| Eliminación | Prohibida |
---
## Registra
- Fecha y hora
- Origen
- Usuario
- Contenido
- Hash SHA-256 de archivos
---
## Clara vs Margaret
| Aspecto | Clara | Margaret |
|---------|-------|----------|
| Contexto | Personal (DECK) | Corporativo (CORP) |
| Usuarios | Uno | Múltiples |
| Tabla recepción | Menor | Mayor |
| Funcionalidad | Equivalente | Equivalente |
---
## Flujo de Entrada
```
PACKET / API / Manual
┌─────────────────┐
│ Secretaría │
│ Clara/Margaret │
├─────────────────┤
│ • Registrar │
│ • Hashear │
│ • Almacenar │
│ • Confirmar │
└────────┬────────┘
├──► Producción (si encaja)
└──► Administración (si no encaja)
```
---
## Schema
```sql
CREATE TABLE secretaria_log (
id BIGSERIAL PRIMARY KEY,
h_entrada VARCHAR(64) UNIQUE NOT NULL,
ts TIMESTAMPTZ DEFAULT NOW(),
origen VARCHAR(100),
usuario_id INTEGER,
tipo_contenido VARCHAR(50),
contenido JSONB,
archivos_hashes JSONB,
metadata JSONB
);
```
---
## API
| Endpoint | Método | Descripción |
|----------|--------|-------------|
| /ingesta | POST | Nueva entrada |
| /ingesta/{h_entrada} | GET | Consultar entrada |
| /ingesta/verificar | POST | Verificar hash |

View File

@@ -0,0 +1,90 @@
# Utilidades
**Estado:** Operativo
---
## Descripción
Pack de servicios auxiliares disponibles en cada instancia del sistema.
---
## Servicios
| Servicio | Función | Base |
|----------|---------|------|
| **Mail** | Correo electrónico | Cowmail |
| **Alias** | Gestión de alias de correo | Addy.io |
| **Credenciales** | Gestión de credenciales | Vaultwarden |
| **Acortador** | Redirección de URLs | Shlink |
---
## Puertos por Servidor
| Servicio | DECK | CORP |
|----------|------|------|
| Mail | 8084 | 8084 |
| Alias | 8085 | 8085 |
| Credenciales | 8082 | 8081 |
| Acortador | 8083 | 8082 |
---
## Mail
Gestión de correo electrónico.
| Aspecto | Valor |
|---------|-------|
| Base | Cowmail |
| Protocolo | SMTP/IMAP |
---
## Alias
Gestión de alias de correo para privacidad y organización.
| Aspecto | Valor |
|---------|-------|
| Base | Addy.io |
| Función | Crear alias temporales o permanentes |
---
## Credenciales
Almacén seguro de credenciales y secretos.
| Aspecto | Valor |
|---------|-------|
| Base | Vaultwarden |
| Protocolo | API compatible Bitwarden |
| Referencia | `kv://` URIs |
---
## Acortador
Acortador y redirector de URLs con tracking.
| Aspecto | Valor |
|---------|-------|
| Base | Shlink |
| Función | URLs cortas, estadísticas de clics |
---
## Bases de Datos de Usuario
Extensiones de bibliotecas para contenido personalizado:
| Tabla | Descripción | Extiende |
|-------|-------------|----------|
| **hsu** | Tags de usuario | HST |
| **spu** | Especialidades de usuario | SPE |
| **pju** | Proyectos de usuario | PJT |
Estas tablas permiten que cada usuario cree sus propias etiquetas, especialidades y proyectos sin modificar las bibliotecas base del sistema.

View File

@@ -0,0 +1,224 @@
# Asistente de Voz
**Nombre:** Penny
**Versión:** 1.0
**Estado:** Especificación
---
## Descripción
PENNY es el asistente personal de voz del sistema DECK. Proporciona interfaz conversacional hablada 100% natural.
```
┌─────────────────────────────────────────────────────────────────┐
│ PENNY │
│ │
│ • ES la voz del DECK │
│ • ES la interfaz hablada con el usuario │
│ • ES quien llama a GRACE cuando necesita datos │
│ • HABLA con el usuario (GRACE no puede) │
│ • REGISTRA todo en el log (planos de información) │
│ • MANTIENE contexto durante la sesión │
│ │
│ "PENNY habla, GRACE procesa, el Log recuerda." │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Principios
| Principio | Descripción |
|-----------|-------------|
| **Privacidad radical** | Audio procesado 100% local |
| **Conversación natural** | Turnos fluidos, latencia <2s |
| **Log como verdad** | Todo está en el log |
| **Planos separados** | Contextos cargables independientemente |
| **GRACE como backend** | PENNY pregunta, GRACE extrae |
---
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ PENNY VOICE ENGINE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐│
│ │ Silero │ │ Faster │ │ PENNY │ │ XTTS-v2 ││
│ │ VAD │─▶│ Whisper │─▶│ CORE │─▶│ /Kokoro ││
│ │ │ │ │ │ │ │ ││
│ │ Detecta │ │ Transcribe │ │ Orquesta │ │ Sintetiza ││
│ │ voz │ │ audio │ │ todo │ │ respuesta ││
│ └────────────┘ └────────────┘ └─────┬──────┘ └────────────┘│
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ PLANOS │ │ GRACE │ │
│ │ (Log) │ │ (S-CONTRACT)│ │
│ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
│ SOLO texto (nunca audio)
┌─────────────────────────────┐
│ Claude API │
└─────────────────────────────┘
```
---
## Flujo Voz → Voz
```
1. VAD DETECTA (Silero)
└── Usuario empieza a hablar
└── Usuario termina (silencio 700ms)
2. ASR TRANSCRIBE (Faster-Whisper)
└── Audio → Texto
└── ~200-400ms con GPU
3. PENNY CORE PROCESA
├── Cargar planos relevantes
├── ¿Necesita GRACE? → Llamar con S-CONTRACT
├── Construir prompt con contexto
└── Enviar a Claude API (solo texto)
4. LLM RESPONDE (Claude)
└── Streaming de tokens
└── ~1-2s primera palabra
5. TTS SINTETIZA (XTTS-v2/Kokoro)
└── Texto → Audio
└── Streaming mientras llegan tokens
6. LOG REGISTRA
└── Todo el intercambio → plano CONVERSACION
LATENCIA TOTAL OBJETIVO: <2 segundos voice-to-voice
```
---
## Planos de Información
El Log está organizado en planos que se cargan independientemente:
| Plano | Nombre | Descripción | Comportamiento |
|-------|--------|-------------|----------------|
| 0 | SISTEMA | Instrucciones base | INMUTABLE durante sesión |
| 1 | PERSONALIDAD | Tono, estilo, nombre, voz | CONFIGURABLE por usuario |
| 2 | CONTEXTO PERSONAL | Info usuario, preferencias | PERSISTENTE entre sesiones |
| 3 | CONTEXTO AMBIENTAL | Fecha, hora, estado sistema | DINÁMICO cada sesión |
| 4 | DATASET | Datos específicos de tarea | OPCIONAL bajo demanda |
| 5 | CONVERSACIÓN | Historial de sesión | TEMPORAL durante sesión |
---
## Modelos Autoalojados
| Componente | Modelo | Descripción |
|------------|--------|-------------|
| VAD | Silero VAD v5 | Detección de actividad vocal |
| ASR | Faster-Whisper Large-v3 | Transcripción |
| TTS | XTTS-v2 / Kokoro | Síntesis de voz |
| LLM | Claude API | Solo texto, streaming |
---
## Configuración
```yaml
penny:
version: "1.0"
server:
host: "0.0.0.0"
port: 8765
websocket_path: "/ws/voice"
models:
vad:
type: "silero"
path: "models/silero/vad_v5.onnx"
asr:
type: "faster-whisper"
model: "large-v3"
device: "cuda"
compute_type: "float16"
tts:
type: "xtts-v2"
speaker_wav: "voces/penny_base.wav"
language: "es"
llm:
provider: "anthropic"
model: "claude-sonnet-4-20250514"
max_tokens: 150
temperature: 0.7
streaming: true
grace:
endpoint: "http://localhost:8080/api/v1"
timeout_ms: 10000
log:
database_url: "postgresql://..."
retain_audio_days: 7
retain_text_days: 365
```
---
## Rol en el Sistema
```
┌─────────────────────────────────────────────────────────────────┐
│ DECK (Servidor Personal) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Usuario ◄────────────────────────────────────► PENNY │
│ (voz natural) │ (habla) │
│ │ │
│ ┌──────────────┼──────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ GRACE │ │ LOG │ │ DECK │ │
│ │ (datos) │ │(planos) │ │(acciones│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Características Conversacionales
| Característica | Descripción |
|----------------|-------------|
| **Barge-in** | Usuario puede interrumpir |
| **Turn detection** | Detecta fin de turno por silencio |
| **Contexto** | Mantiene contexto durante sesión |
| **Streaming** | Respuesta progresiva mientras genera |
---
## Pendiente
- [ ] Configurar servidor con GPU
- [ ] Instalar modelos (Whisper, XTTS-v2, Silero)
- [ ] Crear tablas de log
- [ ] Definir planos específicos
- [ ] Grabar voz base para clonación TTS
- [ ] Implementar pipeline con Pipecat
- [ ] Ajustar turn detection

View File

@@ -0,0 +1,84 @@
# Circle
**Nombre:** The Circle - Consejo de Perspectivas
**Estado:** Implementado
---
## Descripción
Sistema que convoca múltiples perspectivas (agentes con roles distintos) para analizar un problema desde diferentes ángulos.
---
## Concepto
```
┌─────────────────────────────────────────────────────────────────┐
│ THE CIRCLE │
│ (Consejo de Perspectivas) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Crítico │ │Optimista│ │
│ └────┬────┘ └────┬────┘ │
│ │ │ │
│ │ ┌─────────────┐ │ │
│ └─────►│ PROBLEMA │◄─────────┘ │
│ └──────┬──────┘ │
│ ┌─────────────┼─────────────┐ │
│ │ │ │ │
│ ┌────┴────┐ ┌─────┴─────┐ ┌────┴────┐ │
│ │Pragmático│ │ Creativo │ │Analítico│ │
│ └─────────┘ └───────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Presets
| Preset | Perspectivas | Uso |
|--------|--------------|-----|
| **decision** | Crítico, Optimista, Pragmático | Toma de decisiones |
| **creative** | Creativo, Crítico, Explorador | Brainstorming |
| **analysis** | Analítico, Escéptico, Sintético | Análisis profundo |
---
## Uso
```javascript
const circle = new Circle('decision');
const result = await circle.deliberate({
problem: "¿Deberíamos lanzar el producto ahora?",
context: "..."
});
```
---
## Output
```json
{
"perspectives": [
{ "role": "critico", "opinion": "..." },
{ "role": "optimista", "opinion": "..." },
{ "role": "pragmatico", "opinion": "..." }
],
"synthesis": "...",
"recommendation": "..."
}
```
---
## Diferencia con Orchestrator
| Aspecto | Orchestrator | Circle |
|---------|--------------|--------|
| Enfoque | Ejecución de tareas | Deliberación |
| Agentes | Colaborativos | Contrapuestos |
| Output | Resultado | Perspectivas + síntesis |

View File

@@ -0,0 +1,87 @@
# Cloudville
**Nombre:** Cloudville - Laboratorio de Zumbados
**Estado:** Implementado
---
## Descripción
Laboratorio experimental donde agentes con personalidades extremas o poco convencionales exploran ideas sin restricciones.
---
## Concepto
```
┌─────────────────────────────────────────────────────────────────┐
│ CLOUDVILLE │
│ (Laboratorio de Zumbados) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ "Donde las ideas locas tienen permiso para existir" │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Visionario│ │ Caótico │ │Contrarian│ │ Loco │ │
│ │ │ │ │ │ │ │ Genio │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Propósito
| Aspecto | Valor |
|---------|-------|
| Restricciones | Mínimas |
| Filtro | Ninguno |
| Output | Ideas sin censura |
| Uso | Exploración, brainstorming extremo |
---
## Diferencia con Circle
| Aspecto | Circle | Cloudville |
|---------|--------|------------|
| Tono | Profesional | Experimental |
| Filtro | Moderado | Ninguno |
| Propósito | Decisión | Exploración |
| Personalidades | Equilibradas | Extremas |
---
## Uso
```javascript
const cloudville = new Cloudville();
const ideas = await cloudville.explore({
challenge: "¿Cómo podríamos...?",
constraints: "ninguna"
});
```
---
## Output
```json
{
"ideas": [
{ "agent": "visionario", "idea": "..." },
{ "agent": "caotico", "idea": "..." },
{ "agent": "contrarian", "idea": "..." },
{ "agent": "loco_genio", "idea": "..." }
],
"wildest": "...",
"hidden_gems": ["...", "..."]
}
```
---
## Advertencia
> **Nota:** Las ideas de Cloudville no están filtradas. Requieren evaluación posterior antes de implementación.

View File

@@ -0,0 +1,96 @@
# Generación Iterativa
**Nombre:** The Factory
**Estado:** Implementado (RunPod)
---
## Descripción
Sistema de generación iterativa. Produce contenido mediante ciclos de refinamiento sucesivos.
---
## Concepto
```
Input inicial
┌─────────────────┐
│ THE FACTORY │
├─────────────────┤
│ │
│ Iteración 1 ───┼──► Resultado parcial
│ │ │
│ ▼ │
│ Iteración 2 ───┼──► Resultado mejorado
│ │ │
│ ▼ │
│ Iteración N ───┼──► Resultado final
│ │
└─────────────────┘
```
---
## Endpoint
| Parámetro | Valor |
|-----------|-------|
| Ubicación | RunPod |
| GPU | NVIDIA L4 |
| Modo | Serverless |
---
## Casos de Uso
| Caso | Descripción |
|------|-------------|
| Generación de imágenes | Refinamiento progresivo |
| Generación de texto | Mejora iterativa |
| Producción de contenido | Ciclos de calidad |
---
## Request
```json
{
"input": {
"prompt": "...",
"iterations": 3,
"quality_threshold": 0.8,
"output_format": "..."
}
}
```
---
## Response
```json
{
"status": "completed",
"iterations_used": 3,
"outputs": [
{ "iteration": 1, "result": "...", "score": 0.6 },
{ "iteration": 2, "result": "...", "score": 0.75 },
{ "iteration": 3, "result": "...", "score": 0.85 }
],
"final_result": "...",
"trace_id": "..."
}
```
---
## Diferencia con Grace
| Aspecto | Grace | The Factory |
|---------|-------|-------------|
| Modo | Single-shot | Iterativo |
| Enfoque | Transformación | Generación |
| Ciclos | 1 | N |

View File

@@ -0,0 +1,203 @@
# Gestoría
**Nombre:** Grace
**Versión:** 2.0
**Estado:** Enterprise Standard
---
## Descripción
GRACE no es un chatbot. Es un **conjunto de 18 microservicios cognitivos desacoplados**.
```
┌─────────────────────────────────────────────────────────────────┐
│ PRINCIPIO GRACE │
│ │
│ "GRACE transforma, Producción (Alfred/Jared) decide" │
└─────────────────────────────────────────────────────────────────┘
```
---
## Características
| Propiedad | Valor |
|-----------|-------|
| Stateless | No guarda estado |
| Determinista | Misma entrada → misma salida |
| Intercambiable | Modelos sustituibles |
| Trazable | Todo via trace_id |
**GRACE no:**
- Toma decisiones
- Altera estados
- Escribe en base de datos
---
## Infraestructura
| Aspecto | Valor |
|---------|-------|
| **Plataforma** | RunPod Serverless |
| **GPU** | NVIDIA L4 (24GB) |
| **Endpoint** | https://api.runpod.ai/v2/{id} |
| **Modos** | runsync, run, status |
---
## Catálogo de 18 Módulos
### FAMILIA A - VISIÓN (Procesado Documental)
| # | Módulo | Función |
|---|--------|---------|
| 1 | **IMG_PREPROCESS** | Normalización: crop, denoise, upscale, grayscale |
| 2 | **PDF_SCANNER** | Limpieza escaneados: deskew, binarización, bordes |
| 3 | **OCR_CORE** | Extracción texto: layout analysis, HOCR |
### FAMILIA B - VOZ (Reuniones)
| # | Módulo | Función |
|---|--------|---------|
| 4 | **ASR_ENGINE** | Reconocimiento habla: Whisper Large v3, diarización |
| 5 | **TTS_ENGINE** | Síntesis voz neutral para notificaciones |
### FAMILIA C - IDENTIDAD (Biometría)
| # | Módulo | Función |
|---|--------|---------|
| 6 | **FACE_VECTOR** | Vector biométrico facial (Float32 L2) |
| 7 | **ID_CONSOLIDATION** | Fusión identidades: mediana geométrica |
| 8 | **AVATAR_GEN** | Avatar neutral 512x512 desde vector |
### FAMILIA D - SEMÁNTICA (NLP)
| # | Módulo | Función |
|---|--------|---------|
| 9 | **EMBEDDINGS** | Vectorización semántica para búsquedas |
| 10 | **SUMMARIZER** | Resumen estructurado: objetivos, acuerdos, riesgos |
| 11 | **TASK_EXTRACTOR** | Minería de acciones, responsables, fechas |
| 12 | **CLASSIFIER** | Asigna tags HST basado en contenido |
| 13 | **SIMILARITY** | Comparador vectorial (Cosine Similarity) |
### FAMILIA E - UTILIDADES
| # | Módulo | Función |
|---|--------|---------|
| 14 | **FIELD_EXTRACTOR** | Lectura estructurada: CIF, fechas, importes |
| 15 | **HASHER** | Generador SHA256 y UUID v4 |
| 16 | **INPUT_NORMALIZER** | Traducción formatos y enumeraciones |
| 17 | **OUTPUT_ADAPTER** | Adaptación a formatos legacy |
| 18 | **LANG_DETECT** | Identificación idioma ISO 639-1 |
---
## Cadenas de Fallback
Cada módulo define degradación vía `fallback_chain` en S-CONTRACT:
### Ejemplo OCR
```json
"routing": {
"module": "OCR_CORE",
"fallback_chain": ["OCR_LOCAL", "OCR_GROQ", "OCR_OPENAI"]
}
```
### Ejemplo ASR
```json
"routing": {
"module": "ASR_ENGINE",
"fallback_chain": ["ASR_WHISPER_LOCAL", "ASR_FASTER_WHISPER", "ASR_GROQ"]
}
```
---
## Integración con S-CONTRACT
Todos los módulos GRACE cumplen S-CONTRACT sin excepciones. No hay contratos específicos por módulo.
### Request (LITE)
```json
{
"contract_version": "2.1",
"profile": "LITE",
"envelope": {
"trace_id": "uuid-v4",
"idempotency_key": "sha256-input"
},
"routing": {
"module": "CLASSIFIER"
},
"context": {
"lang": "es",
"mode": "strict"
},
"payload": {
"type": "text",
"encoding": "utf-8",
"content": "Texto a procesar"
}
}
```
### Response
```json
{
"contract_version": "2.1",
"profile": "LITE",
"status": {
"code": "SUCCESS",
"provider_used": "groq"
},
"result": {
"data": {
"category": "FINANZAS",
"confidence": 0.98
}
},
"quality": {
"confidence": 0.98,
"tokens_input": 150,
"tokens_output": 45
},
"metadata": {
"model_id": "llama-3.1-70b-versatile",
"processing_ms": 340
}
}
```
---
## Relación con Otros Componentes
GRACE es un servicio de transformación. Cuando termina de procesar, envía el resultado a Secretaría (Clara/Margaret) como cualquier otro origen:
```
┌─────────────────────────────────────────────────────────────────┐
│ PUNTO DE ENTRADA ÚNICO │
├─────────────────────────────────────────────────────────────────┤
│ │
│ GRACE ──────┐ │
│ Penny ──────┼──► Secretaría (Clara/Margaret) │
│ Packet ─────┤ │
│ Manual ─────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
GRACE no es un paso del flujo de datos. Es un servicio que cualquier componente puede invocar vía S-CONTRACT para obtener transformaciones cognitivas (OCR, transcripción, clasificación, etc.).
---
## Compatibilidad Universal
El sistema está diseñado para que cuando aparezcan módulos mejores, encajen sin trabajo añadido. S-CONTRACT es el marco de compatibilidad universal — cualquier módulo que lo cumpla es interoperable.

File diff suppressed because it is too large Load Diff

View File

@@ -1,237 +0,0 @@
# Entidades Base TZZR
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Visión General
Las entidades base son los bloques fundamentales del sistema. Cada una tiene un hash único SHA-256 que la identifica de forma unívoca.
```
DEFINICIÓN ORIGINAL → SHA-256 → h_{tipo} (64 chars)
```
---
## HST (Hash Semantic Tagging)
**Estado:** Implementado
**Servidor:** HST (72.62.2.84)
**Hash:** h_maestro
### Fórmula
```
h_maestro = SHA-256(grupo:ref)
```
### Grupos
| Grupo | Cantidad | Descripción |
|-------|----------|-------------|
| hst | 639 | Tags del sistema base |
| spe | 145 | Tags específicos |
| vsn | 84 | Visiones |
| flg | 65 | Banderas/países |
| vue | 21 | Vistas |
### Schema
```sql
CREATE TABLE hst_tags (
id SERIAL PRIMARY KEY,
ref VARCHAR(100) UNIQUE NOT NULL,
h_maestro VARCHAR(64) UNIQUE NOT NULL,
grupo VARCHAR(50) NOT NULL,
nombre_es VARCHAR(255),
nombre_en VARCHAR(255),
descripcion TEXT,
imagen_url TEXT,
activo BOOLEAN DEFAULT true,
version INTEGER DEFAULT 1,
created_at TIMESTAMP DEFAULT NOW()
);
```
### Ejemplo
```json
{
"ref": "person",
"h_maestro": "a1b2c3d4e5f6...",
"grupo": "hst",
"nombre_es": "Persona",
"nombre_en": "Person",
"imagen_url": "https://tzrtech.org/a1b2c3d4e5f6...png"
}
```
---
## ITM (Items - Plano Ideal)
**Estado:** Planificado
**Servidor:** Por definir
**Hash:** h_item
### Concepto
Los ITM representan el estado ideal futuro. Son la "partitura" que guía las acciones.
### Schema Propuesto
```sql
CREATE TABLE items (
id BIGSERIAL PRIMARY KEY,
h_item VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64),
tipo_item VARCHAR(50) NOT NULL, -- accion_ideal, objetivo, requerimiento
titulo VARCHAR(255) NOT NULL,
descripcion TEXT,
criterios_aceptacion JSONB,
metadata JSONB,
proyecto_tag VARCHAR(64),
etiquetas JSONB,
estado VARCHAR(20) DEFAULT 'draft', -- draft, vigente, obsoleto
created_at TIMESTAMPTZ DEFAULT NOW(),
created_by VARCHAR(64),
UNIQUE (h_instancia, secuencia)
);
```
---
## PLY (Players - Identidad)
**Estado:** Planificado
**Servidor:** Por definir
**Hash:** h_player
### Concepto
Los PLY representan la identidad de actores en el sistema (personas, empresas, agentes).
### Schema Propuesto
```sql
CREATE TABLE players (
id BIGSERIAL PRIMARY KEY,
h_player VARCHAR(64) UNIQUE NOT NULL,
tipo VARCHAR(50) NOT NULL, -- persona, empresa, agente
nombre VARCHAR(255) NOT NULL,
email VARCHAR(255),
metadata JSONB,
activo BOOLEAN DEFAULT true,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
---
## LOC (Locations - Ubicaciones)
**Estado:** Planificado
**Servidor:** Por definir
**Hash:** h_loc
### Concepto
Los LOC representan ubicaciones geográficas con precisión variable.
### Schema Propuesto
```sql
CREATE TABLE locations (
id BIGSERIAL PRIMARY KEY,
h_loc VARCHAR(64) UNIQUE NOT NULL,
nombre VARCHAR(255),
lat DECIMAL(10, 8),
lon DECIMAL(11, 8),
precision_metros INTEGER,
tipo VARCHAR(50), -- punto, area, ruta
metadata JSONB,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
### Fórmula Hash
```
h_loc = SHA-256(lat:lon:precision)
```
---
## FLG (Flags - Marcos Jurídicos)
**Estado:** Planificado
**Servidor:** Por definir
**Hash:** h_flag
### Concepto
Los FLG representan marcos jurídicos, normativas, países.
### Notas
Actualmente existe un grupo `flg` en HST con 65 tags de países, pero no como entidad independiente.
---
## Tags de Usuario (Extensiones)
Los usuarios pueden crear sus propios tags como extensiones de HST.
| Tabla | Descripción |
|-------|-------------|
| hsu | HST Usuario |
| spu | SPE Usuario |
| vsu | VSN Usuario |
| vuu | VUE Usuario |
| pju | Proyectos Usuario |
| flu | FLG Usuario |
### Schema
```sql
CREATE TABLE hsu (
id SERIAL PRIMARY KEY,
ref VARCHAR(10) NOT NULL,
h_usuario VARCHAR(64) NOT NULL,
nombre VARCHAR(255) NOT NULL,
user_id INTEGER REFERENCES users(id),
metadata JSONB,
activo BOOLEAN DEFAULT true,
created_at TIMESTAMP DEFAULT NOW(),
UNIQUE (user_id, ref)
);
```
---
## Relaciones Entre Entidades
```
ITM (ideal)
├──► h_maestro (HST tags)
├──► h_player (PLY responsable)
├──► h_loc (LOC ubicación)
└──► h_flag (FLG normativa)
MST (milestone)
├──► item_asociado (ITM)
└──► h_maestro (HST tags)
BCK (bloque)
├──► item_asociado (ITM)
├──► milestone_asociado (MST)
└──► h_maestro (HST tags)
```

View File

@@ -1,309 +0,0 @@
# Planos de Datos TZZR
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Visión General
El sistema TZZR utiliza tres planos conceptuales para organizar la información:
```
┌─────────────────────────────────────────────────────────────────┐
│ T0 - PLANO IDEAL │
│ ITM (Items): Objetivos, acciones ideales, requerimientos │
│ Estado: PLANIFICADO - Sin implementación actual │
└─────────────────────────────────────────────────────────────────┘
▼ materializa
┌─────────────────────────────────────────────────────────────────┐
│ MST - MILESTONES │
│ Compromisos futuros con fecha de vencimiento │
│ Estado: IMPLEMENTADO en CORP (tabla milestones) │
└─────────────────────────────────────────────────────────────────┘
▼ cumple/genera
┌─────────────────────────────────────────────────────────────────┐
│ BCK - BLOQUES │
│ Hechos inmutables del pasado (blockchain-ready) │
│ Estado: IMPLEMENTADO en CORP (tabla bloques) │
└─────────────────────────────────────────────────────────────────┘
```
---
## T0 - Plano Ideal (ITM)
### Concepto
El plano T0 contiene los Items (ITM) que representan el estado ideal futuro. Son la "partitura" que guía las acciones.
### Tipos de Items
| Tipo | Descripción |
|------|-------------|
| accion_ideal | Acción que debería ejecutarse |
| objetivo | Meta a alcanzar |
| requerimiento | Requisito a cumplir |
### Estado de Implementación
**PLANIFICADO** - Schema definido pero sin tablas creadas.
### Schema Propuesto
```sql
CREATE TABLE items (
id BIGSERIAL PRIMARY KEY,
h_item VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64),
tipo_item VARCHAR(50) NOT NULL,
titulo VARCHAR(255) NOT NULL,
descripcion TEXT,
criterios_aceptacion JSONB,
metadata JSONB,
proyecto_tag VARCHAR(64),
etiquetas JSONB,
estado VARCHAR(20) DEFAULT 'draft',
created_at TIMESTAMPTZ DEFAULT NOW(),
created_by VARCHAR(64),
UNIQUE (h_instancia, secuencia)
);
```
---
## MST - Milestones
### Concepto
Los milestones representan compromisos con fecha futura. Tienen un período flotante de 24 horas antes de consolidarse.
### Estado de Implementación
**IMPLEMENTADO** en CORP (database: corp).
### Schema Actual
```sql
-- Tabla: milestones (CORP)
CREATE TABLE milestones (
id BIGSERIAL PRIMARY KEY,
h_milestone VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64),
tipo_milestone VARCHAR(50) NOT NULL,
fecha_vencimiento DATE NOT NULL,
descripcion TEXT,
metadata JSONB,
proyecto_tag VARCHAR(64),
etiquetas JSONB,
estado VARCHAR(20) DEFAULT 'draft',
created_at TIMESTAMPTZ DEFAULT NOW(),
modified_at TIMESTAMPTZ,
created_by VARCHAR(64),
UNIQUE (h_instancia, secuencia)
);
```
### Tipos de Milestones
| Tipo | Descripción |
|------|-------------|
| compromiso | Compromiso de entrega |
| deadline | Fecha límite |
| evento | Evento programado |
| recordatorio | Recordatorio futuro |
### Fórmula Hash
```
h_milestone = SHA-256(h_instancia:secuencia:tipo:contenido)
```
### Período Flotante
- **Duración:** 24 horas desde creación
- **Durante período:** Modificable vía MASON
- **Después:** Inmutable, solo lectura
**Nota:** Actualmente no hay scheduler que procese la expiración automáticamente.
---
## BCK - Bloques
### Concepto
Los bloques son registros inmutables de hechos pasados. Cada bloque está encadenado al anterior mediante hash, preparando la infraestructura para blockchain.
### Estado de Implementación
**IMPLEMENTADO** en CORP (database: corp).
### Schema Actual
```sql
-- Tabla: bloques (CORP)
CREATE TABLE bloques (
id BIGSERIAL PRIMARY KEY,
h_bloque VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64) NOT NULL,
tipo_bloque VARCHAR(50) NOT NULL,
contenido JSONB NOT NULL,
metadata JSONB,
item_asociado VARCHAR(64),
milestone_asociado VARCHAR(64),
h_maestro JSONB,
h_player VARCHAR(64),
h_loc VARCHAR(64),
h_flag VARCHAR(64),
estado VARCHAR(20) DEFAULT 'consolidado',
created_at TIMESTAMPTZ DEFAULT NOW(),
validated_at TIMESTAMPTZ,
validated_by VARCHAR(64),
UNIQUE (h_instancia, secuencia)
);
```
### Tipos de Bloques
| Tipo | Descripción |
|------|-------------|
| transaccion | Transacción económica |
| documento | Documento consolidado |
| evento | Evento registrado |
| milestone_cumplido | Milestone que se cumplió |
### Fórmula Hash
```
h_bloque = SHA-256(h_instancia:secuencia:hash_previo:hash_contenido)
hash_contenido = SHA-256(contenido_serializado)
```
### Encadenamiento
```
Bloque N-1 Bloque N
┌──────────────────┐ ┌──────────────────┐
│ h_bloque: abc123 │ ──────► │ hash_previo: │
│ hash_contenido: │ │ abc123 │
│ def456 │ │ h_bloque: ghi789 │
│ secuencia: 1 │ │ secuencia: 2 │
└──────────────────┘ └──────────────────┘
```
---
## Flujo Entre Planos
```
Usuario crea ITM
ITM (T0) "Objetivo: Completar proyecto X"
│ materializa
MST "Milestone: Entrega módulo 1 - 2024-01-15"
│ [período flotante 24h]
MASON (enriquecimiento)
FELDMAN (validación)
│ cumple/genera
BCK "Bloque: Módulo 1 entregado - 2024-01-14"
Inmutable ✓
```
---
## Tablas de Procesamiento
### FELDMAN Cola
```sql
-- feldman_cola: Elementos pendientes de validación
CREATE TABLE feldman_cola (
id BIGSERIAL PRIMARY KEY,
tipo VARCHAR(50) NOT NULL, -- 'milestone' o 'bloque'
h_entrada VARCHAR(64) NOT NULL,
contenido JSONB NOT NULL,
prioridad INTEGER DEFAULT 0,
estado VARCHAR(20) DEFAULT 'pendiente',
created_at TIMESTAMPTZ DEFAULT NOW(),
processed_at TIMESTAMPTZ
);
```
### FELDMAN Validaciones
```sql
-- feldman_validaciones: Auditoría de validaciones
CREATE TABLE feldman_validaciones (
id BIGSERIAL PRIMARY KEY,
h_entrada VARCHAR(64) NOT NULL,
regla VARCHAR(50) NOT NULL, -- M-001, M-002, M-003
resultado BOOLEAN NOT NULL,
mensaje TEXT,
validated_at TIMESTAMPTZ DEFAULT NOW()
);
```
---
## Reglas de Validación FELDMAN
| Regla | Nombre | Descripción |
|-------|--------|-------------|
| M-001 | Hash único | h_bloque/h_milestone no existe previamente |
| M-002 | Encadenamiento | hash_previo apunta a bloque existente |
| M-003 | Integridad | hash_contenido = SHA-256(contenido) |
---
## Decisiones de Diseño
### D-004: Eliminar columnas duplicadas
**Problema:** Milestones tienen columnas + JSONB duplicados.
**Decisión:** Mantener metadatos solo en JSONB `metadata`.
### D-007: Timestamps UTC
**Problema:** Inconsistencia en zonas horarias.
**Decisión:** Usar `TIMESTAMPTZ` y almacenar en UTC.
---
## Roadmap
### Implementado
- [x] Tabla milestones en CORP
- [x] Tabla bloques en CORP
- [x] Fórmulas hash definidas
### Pendiente
- [ ] Tabla items (T0)
- [ ] Scheduler para período flotante
- [ ] Merkle tree para verificación
- [ ] Smart contract blockchain (futuro)

View File

@@ -1,314 +0,0 @@
# secretaria (CLARA / MARGARET)
**Componente:** Ingesta
**Versión:** 5.0
**Fecha:** 2024-12-24
> **Nota:** Este es un microservicio backend, no IA.
---
## Resumen
| Aspecto | secretaria (CLARA) | secretaria (MARGARET) |
|---------|-------|----------|
| Servidor | DECK (72.62.1.113) | CORP (92.112.181.188) |
| Puerto | 5051 | 5051 |
| Dominio | Personal | Empresarial |
| Base de datos | tzzr | corp |
| Tabla log | secretaria_log | secretaria_log |
| Bucket R2 | deck | corp |
| Estado | Operativo | Operativo |
---
## Arquitectura
```
PACKET (App móvil)
│ POST /ingest
│ Content-Type: multipart/form-data
│ X-Auth-Key: {h_instancia}
┌─────────────────────────────────────────┐
│ secretaria (CLARA / MARGARET) │
│ │
│ 1. Validar h_instancia │
│ 2. Calcular h_entrada (SHA-256) │
│ 3. Subir archivos a R2 │
│ 4. Insertar en log (inmutable) │
│ 5. Estado: 'recibido' │
│ 6. Responder con h_entrada │
└─────────────────────────────────────────┘
producción (ALFRED / JARED)
```
---
## Endpoint de Ingesta
### Request
```http
POST /ingest HTTP/1.1
Host: deck.example.com:5051
Content-Type: multipart/form-data
X-Auth-Key: {h_instancia}
--boundary
Content-Disposition: form-data; name="tipo"
documento
--boundary
Content-Disposition: form-data; name="archivo"; filename="doc.pdf"
Content-Type: application/pdf
{binary data}
--boundary--
```
### Response
```json
{
"success": true,
"h_entrada": "a1b2c3d4e5f6...",
"estado": "recibido",
"timestamp": "2024-12-24T12:00:00Z"
}
```
---
## Cálculo de h_entrada
```python
import hashlib
import json
def calcular_h_entrada(h_instancia, tipo, contenido_bytes, timestamp):
"""
Calcula el hash único de entrada.
h_entrada = SHA-256(h_instancia:tipo:sha256(contenido):timestamp)
"""
hash_contenido = hashlib.sha256(contenido_bytes).hexdigest()
data = f"{h_instancia}:{tipo}:{hash_contenido}:{timestamp}"
return hashlib.sha256(data.encode()).hexdigest()
```
---
## Schema: clara_log / margaret_log
```sql
CREATE TABLE clara_log (
id BIGSERIAL PRIMARY KEY,
h_entrada VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
tipo VARCHAR(50) NOT NULL,
contenido_url TEXT, -- locker://deck/{h_entrada}/archivo
contenido_hash VARCHAR(64), -- SHA-256 del contenido
metadata JSONB,
estado VARCHAR(20) DEFAULT 'recibido',
created_at TIMESTAMPTZ DEFAULT NOW(),
processed_at TIMESTAMPTZ,
processed_by VARCHAR(50) -- 'alfred' o 'manual'
);
-- margaret_log tiene schema idéntico
CREATE TABLE margaret_log (
id BIGSERIAL PRIMARY KEY,
h_entrada VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
tipo VARCHAR(50) NOT NULL,
contenido_url TEXT,
contenido_hash VARCHAR(64),
metadata JSONB,
estado VARCHAR(20) DEFAULT 'recibido',
created_at TIMESTAMPTZ DEFAULT NOW(),
processed_at TIMESTAMPTZ,
processed_by VARCHAR(50)
);
```
---
## Estados del Log
| Estado | Descripción |
|--------|-------------|
| recibido | Ingesta completada, pendiente procesamiento |
| procesando | ALFRED/JARED está procesando |
| enviado_mason | Enviado a MASON para enriquecimiento |
| consolidado | Procesado por FELDMAN |
| error | Error en procesamiento |
---
## Almacenamiento en R2
### Estructura de URLs
```
locker://deck/{h_entrada}/archivo.ext
locker://corp/{h_entrada}/archivo.ext
```
### Implementación
```python
import boto3
def subir_a_r2(bucket, h_entrada, archivo_bytes, filename):
"""Sube archivo a Cloudflare R2."""
s3 = boto3.client(
's3',
endpoint_url='https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com',
aws_access_key_id=R2_ACCESS_KEY,
aws_secret_access_key=R2_SECRET_KEY
)
key = f"{h_entrada}/{filename}"
s3.put_object(
Bucket=bucket,
Key=key,
Body=archivo_bytes
)
return f"locker://{bucket}/{key}"
```
---
## Validación de h_instancia
```python
def validar_instancia(h_instancia):
"""
Valida que h_instancia exista y esté activa.
TODO: Implementar tabla de instancias activas.
Actualmente: Validación básica de formato.
"""
if not h_instancia:
return False
if len(h_instancia) != 64:
return False
# TODO: Consultar tabla de instancias
return True
```
---
## Tipos de Ingesta Soportados
| Tipo | Descripción | Extensiones |
|------|-------------|-------------|
| documento | Documentos | pdf, doc, docx |
| imagen | Imágenes | jpg, png, gif |
| audio | Audio | mp3, wav, m4a |
| video | Video | mp4, mov |
| texto | Texto plano | txt, md |
| json | Datos estructurados | json |
---
## Configuración
### Variables de Entorno
```bash
# CLARA (.env en /opt/clara/)
DB_HOST=localhost
DB_PORT=5432
DB_NAME=tzzr
DB_USER=clara
DB_PASSWORD=****
R2_ENDPOINT=https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
R2_ACCESS_KEY=****
R2_SECRET_KEY=****
R2_BUCKET=deck
# MARGARET (.env en /opt/margaret/)
DB_HOST=localhost
DB_PORT=5432
DB_NAME=corp
DB_USER=margaret
DB_PASSWORD=****
R2_BUCKET=corp
```
### Docker Compose
```yaml
# CLARA
version: '3.8'
services:
clara:
container_name: clara-clara
image: tzzr/clara:latest
ports:
- "5051:5051"
env_file:
- .env
restart: unless-stopped
```
---
## Diferencias CLARA vs MARGARET
| Aspecto | CLARA | MARGARET |
|---------|-------|----------|
| Uso | Personal | Empresarial |
| Volumen | Bajo | Alto |
| Privacidad | Máxima | Compartida (empresa) |
| Integración | ALFRED | JARED → MASON → FELDMAN |
| Backup | deck bucket | corp bucket |
---
## Seguridad
### Actual
- Autenticación por h_instancia
- Comunicación HTTP (sin TLS interno)
- .env con permisos 644 (**CRÍTICO: cambiar a 600**)
### Recomendado
- TLS interno con certificados
- Rate limiting
- Validación de tipos MIME
- Escaneo antivirus (ClamAV)
---
## Monitoreo
### Logs
```bash
# CLARA
docker logs clara-clara -f
# MARGARET
docker logs margaret-margaret -f
```
### Métricas Sugeridas
- Ingestas por minuto
- Tamaño promedio de archivos
- Tiempo de procesamiento
- Errores por tipo

View File

@@ -1,393 +0,0 @@
# contable (FELDMAN)
**Componente:** Consolidación
**Versión:** 5.0
**Fecha:** 2024-12-24
> **Nota:** Este es un microservicio backend, no IA.
---
## Resumen
| Aspecto | Valor |
|---------|-------|
| Servidor | DECK y CORP |
| Puerto | 5054 |
| Base de datos | tzzr / corp |
| Tablas | contable_cola, contable_bloques, contable_validaciones |
| Estado | Operativo |
---
## Rol en el Sistema
contable (FELDMAN) es el "notario" del sistema: valida y consolida datos en bloques inmutables.
```
administrativo (MASON)
┌─────────────────────────────────────────┐
│ contable (FELDMAN) │
│ │
│ 1. Recibir en cola │
│ 2. Validar reglas (M-001, M-002, M-003)│
│ 3. Calcular hash_contenido │
│ 4. Encadenar (hash_previo) │
│ 5. Crear milestone o bloque │
│ 6. Marcar como consolidado │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ milestones / bloques (inmutables) │
└─────────────────────────────────────────┘
auditoría (SENTINEL) [planificado]
```
---
## Reglas de Validación
| Regla | Nombre | Descripción | Acción si falla |
|-------|--------|-------------|-----------------|
| M-001 | Hash único | h_bloque/h_milestone no existe previamente | Rechazar |
| M-002 | Encadenamiento | hash_previo apunta a bloque existente | Rechazar |
| M-003 | Integridad | hash_contenido = SHA-256(contenido) | Rechazar |
### Implementación
```python
def validar_m001(h_bloque):
"""M-001: Hash debe ser único."""
existe = db.execute(
"SELECT 1 FROM bloques WHERE h_bloque = %s",
[h_bloque]
).fetchone()
return existe is None
def validar_m002(hash_previo, h_instancia):
"""M-002: hash_previo debe existir (excepto génesis)."""
if hash_previo is None:
# Primer bloque de la instancia (génesis)
existe = db.execute(
"SELECT 1 FROM bloques WHERE h_instancia = %s",
[h_instancia]
).fetchone()
return existe is None # OK si no hay bloques previos
existe = db.execute(
"SELECT 1 FROM bloques WHERE h_bloque = %s",
[hash_previo]
).fetchone()
return existe is not None
def validar_m003(hash_contenido, contenido):
"""M-003: Hash debe coincidir con contenido."""
import hashlib
import json
contenido_serializado = json.dumps(contenido, sort_keys=True)
hash_calculado = hashlib.sha256(contenido_serializado.encode()).hexdigest()
return hash_contenido == hash_calculado
```
---
## Schema de Tablas
### feldman_cola
```sql
CREATE TABLE feldman_cola (
id BIGSERIAL PRIMARY KEY,
tipo VARCHAR(50) NOT NULL, -- 'milestone' o 'bloque'
h_entrada VARCHAR(64) NOT NULL, -- Referencia a origen
h_instancia VARCHAR(64) NOT NULL,
contenido JSONB NOT NULL,
prioridad INTEGER DEFAULT 0,
estado VARCHAR(20) DEFAULT 'pendiente',
intentos INTEGER DEFAULT 0,
ultimo_error TEXT,
created_at TIMESTAMPTZ DEFAULT NOW(),
processed_at TIMESTAMPTZ
);
CREATE INDEX idx_feldman_cola_estado ON feldman_cola(estado);
CREATE INDEX idx_feldman_cola_prioridad ON feldman_cola(prioridad DESC);
```
### feldman_bloques (alias de bloques)
```sql
-- Ver 02_MODELO_DATOS/planos.md para schema completo
CREATE TABLE bloques (
id BIGSERIAL PRIMARY KEY,
h_bloque VARCHAR(64) UNIQUE NOT NULL,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64) NOT NULL,
tipo_bloque VARCHAR(50) NOT NULL,
contenido JSONB NOT NULL,
-- ... campos adicionales
UNIQUE (h_instancia, secuencia)
);
```
### feldman_validaciones
```sql
CREATE TABLE feldman_validaciones (
id BIGSERIAL PRIMARY KEY,
h_entrada VARCHAR(64) NOT NULL,
tipo_destino VARCHAR(50) NOT NULL, -- 'milestone' o 'bloque'
h_destino VARCHAR(64), -- h_milestone o h_bloque
regla VARCHAR(50) NOT NULL, -- M-001, M-002, M-003
resultado BOOLEAN NOT NULL,
mensaje TEXT,
validated_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_feldman_val_entrada ON feldman_validaciones(h_entrada);
```
---
## Flujo de Consolidación
```
1. Entrada en feldman_cola
2. FELDMAN procesa (poll cada N segundos)
├─► Validar M-001 (hash único)
│ ├─ PASS → continuar
│ └─ FAIL → registrar error, marcar 'rechazado'
├─► Validar M-002 (encadenamiento)
│ ├─ PASS → continuar
│ └─ FAIL → registrar error, marcar 'rechazado'
├─► Validar M-003 (integridad)
│ ├─ PASS → continuar
│ └─ FAIL → registrar error, marcar 'rechazado'
3. Todas las validaciones PASS
4. Obtener última secuencia de h_instancia
5. Calcular h_bloque/h_milestone
6. INSERT en bloques/milestones
7. Actualizar feldman_cola → 'consolidado'
8. Registrar en feldman_validaciones
```
---
## Cálculo de Hashes
### h_bloque
```python
def calcular_h_bloque(h_instancia, secuencia, hash_previo, hash_contenido):
"""
Calcula el hash del bloque.
h_bloque = SHA-256(h_instancia:secuencia:hash_previo:hash_contenido)
"""
import hashlib
# hash_previo puede ser None para bloque génesis
previo = hash_previo or "genesis"
data = f"{h_instancia}:{secuencia}:{previo}:{hash_contenido}"
return hashlib.sha256(data.encode()).hexdigest()
```
### hash_contenido
```python
def calcular_hash_contenido(contenido):
"""
Calcula el hash del contenido.
hash_contenido = SHA-256(contenido_serializado)
"""
import hashlib
import json
# Serialización determinista
contenido_str = json.dumps(contenido, sort_keys=True, ensure_ascii=False)
return hashlib.sha256(contenido_str.encode()).hexdigest()
```
---
## API Endpoints
### POST /consolidar
```http
POST /consolidar HTTP/1.1
Host: corp.example.com:5054
Content-Type: application/json
```
### Response (éxito)
```json
{
"success": true,
"h_bloque": "ghi789...",
"secuencia": 42,
"hash_contenido": "jkl012...",
"validaciones": {
"M-001": true,
"M-002": true,
"M-003": true
}
}
```
### Response (error)
```json
{
"success": false,
"error": "Validación fallida",
"validaciones": {
"M-001": true,
"M-002": false,
"M-003": true
},
"mensaje": "M-002: hash_previo no existe en cadena"
}
```
---
## Configuración
### Variables de Entorno
```bash
# /opt/feldman/.env
DB_HOST=localhost
DB_PORT=5432
DB_NAME=corp
DB_USER=feldman
DB_PASSWORD=****
POLL_INTERVAL=5 # Segundos entre polls
MAX_BATCH=10 # Elementos por lote
MAX_RETRIES=3 # Reintentos antes de rechazar
```
---
## Estados de la Cola
| Estado | Descripción |
|--------|-------------|
| pendiente | En espera de procesamiento |
| procesando | FELDMAN está validando |
| consolidado | Validado y creado bloque/milestone |
| rechazado | Falló validación, no se reintentará |
| error | Error técnico, puede reintentarse |
---
## Auditoría
Cada validación se registra en `feldman_validaciones`:
```sql
-- Consultar historial de validaciones
SELECT
h_entrada,
regla,
resultado,
mensaje,
validated_at
FROM feldman_validaciones
WHERE h_entrada = 'abc123...'
ORDER BY validated_at;
```
---
## Futuro: Blockchain
FELDMAN está diseñado para evolucionar hacia blockchain:
1. **Actual:** Encadenamiento por hash_previo en PostgreSQL
2. **Fase 2:** Merkle tree para verificación eficiente
3. **Fase 3:** Smart contract en blockchain (Ethereum/Polygon)
```
Merkle Root
┌───────────┴───────────┐
│ │
Hash(AB) Hash(CD)
│ │
┌─────┴─────┐ ┌─────┴─────┐
│ │ │ │
Hash(A) Hash(B) Hash(C) Hash(D)
│ │ │ │
Bloque A Bloque B Bloque C Bloque D
```
---
## Monitoreo
### Logs
```bash
docker logs feldman-feldman -f
```
### Consultas de Estado
```sql
-- Elementos pendientes
SELECT COUNT(*) FROM feldman_cola WHERE estado = 'pendiente';
-- Últimas validaciones fallidas
SELECT * FROM feldman_validaciones
WHERE resultado = false
ORDER BY validated_at DESC
LIMIT 10;
-- Bloques creados hoy
SELECT COUNT(*) FROM bloques
WHERE created_at >= CURRENT_DATE;
```
-- Últimas validaciones fallidas
SELECT * FROM feldman_validaciones
WHERE resultado = false
ORDER BY validated_at DESC
LIMIT 10;
-- Bloques creados hoy
SELECT COUNT(*) FROM bloques
WHERE created_at >= CURRENT_DATE;
```

View File

@@ -1,403 +0,0 @@
# GRACE - Servicio de IA Cognitiva
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Estado Actual
**BLOQUEADO:** RunPod no inicia workers.
| Aspecto | Valor |
|---------|-------|
| Plataforma | RunPod Serverless |
| Endpoint ID | r00x4g3rrwkbyh |
| Balance | ~$72 USD |
| Workers activos | 0 |
| Estado | Inoperativo |
---
## Descripción
GRACE es el servicio de extracción de información mediante IA. Procesa contenido multimedia para extraer datos estructurados.
```
Contenido Raw
(audio, imagen, video, documento)
┌─────────────────────────────────────────┐
│ GRACE (GPU) │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ ASR │ │ OCR │ │ TTS │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Face │ │Embeddings│ │ Avatar │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ + 12 módulos pendientes │
└─────────────────────────────────────────┘
Datos Estructurados
(JSON, vectores, metadatos)
```
---
## Módulos Implementados (6 de 18)
### ASR - Automatic Speech Recognition
| Campo | Valor |
|-------|-------|
| Modelo | Whisper Large v3 |
| Input | Audio (mp3, wav, m4a) |
| Output | Texto + timestamps |
| GPU | A10G recomendado |
```python
@grace.module("asr")
def process_asr(audio_bytes: bytes) -> dict:
"""Transcribe audio a texto."""
model = whisper.load_model("large-v3")
result = model.transcribe(audio_bytes)
return {
"text": result["text"],
"segments": result["segments"],
"language": result["language"]
}
```
### OCR - Optical Character Recognition
| Campo | Valor |
|-------|-------|
| Modelo | EasyOCR + Tesseract |
| Input | Imagen (jpg, png) |
| Output | Texto + bounding boxes |
| GPU | A10G recomendado |
```python
@grace.module("ocr")
def process_ocr(image_bytes: bytes) -> dict:
"""Extrae texto de imagen."""
reader = easyocr.Reader(['es', 'en'])
result = reader.readtext(image_bytes)
return {
"text": " ".join([r[1] for r in result]),
"boxes": [{"text": r[1], "bbox": r[0], "confidence": r[2]} for r in result]
}
```
### TTS - Text to Speech
| Campo | Valor |
|-------|-------|
| Modelo | Coqui TTS |
| Input | Texto |
| Output | Audio (wav) |
| GPU | A10G recomendado |
### Face - Reconocimiento Facial
| Campo | Valor |
|-------|-------|
| Modelo | InsightFace |
| Input | Imagen |
| Output | Embeddings faciales |
| GPU | A10G recomendado |
### Embeddings - Vectores Semánticos
| Campo | Valor |
|-------|-------|
| Modelo | Sentence Transformers |
| Input | Texto |
| Output | Vector 384/768 dims |
| GPU | A10G recomendado |
### Avatar - Generación de Avatares
| Campo | Valor |
|-------|-------|
| Modelo | StyleGAN |
| Input | Imagen facial |
| Output | Avatar estilizado |
| GPU | A10G recomendado |
---
## Módulos Pendientes (12)
| Módulo | Descripción | Prioridad |
|--------|-------------|-----------|
| Document parsing | Extracción de PDFs | Alta |
| Image classification | Clasificación de imágenes | Media |
| Object detection | Detección de objetos | Media |
| Sentiment analysis | Análisis de sentimiento | Media |
| Named entity recognition | Extracción de entidades | Alta |
| Translation | Traducción de texto | Media |
| Summarization | Resumen de texto | Media |
| Question answering | Respuestas a preguntas | Baja |
| Code generation | Generación de código | Baja |
| Audio classification | Clasificación de audio | Baja |
| Video analysis | Análisis de video | Baja |
| Multimodal fusion | Fusión multimodal | Baja |
---
## Código en R2
El código está listo y disponible:
```
s3://architect/gpu-services/
├── base/
│ └── bootstrap.sh # Script de inicialización
├── grace/
│ └── code/
│ └── handler.py # Handler principal
├── penny/
│ └── code/
│ └── handler.py
└── factory/
└── code/
└── handler.py
```
### Descargar Código
```bash
source /home/orchestrator/orchestrator/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
aws s3 sync s3://architect/gpu-services/grace/ ./grace/ \
--endpoint-url https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
```
---
## Handler RunPod
```python
import runpod
def handler(event):
"""
Handler principal de GRACE para RunPod Serverless.
Input:
{
"input": {
"module": "asr|ocr|tts|face|embeddings|avatar",
"data": "base64 encoded content",
"options": {}
}
}
Output:
{
"output": { ... resultado del módulo ... },
"error": null
}
"""
try:
module = event["input"]["module"]
data = base64.b64decode(event["input"]["data"])
options = event["input"].get("options", {})
if module == "asr":
result = process_asr(data, **options)
elif module == "ocr":
result = process_ocr(data, **options)
elif module == "tts":
result = process_tts(data, **options)
elif module == "face":
result = process_face(data, **options)
elif module == "embeddings":
result = process_embeddings(data, **options)
elif module == "avatar":
result = process_avatar(data, **options)
else:
return {"error": f"Módulo desconocido: {module}"}
return {"output": result, "error": None}
except Exception as e:
return {"error": str(e)}
runpod.serverless.start({"handler": handler})
```
---
## Uso desde MASON
```python
import runpod
import base64
runpod.api_key = "..." # Desde Infisical
def call_grace(module: str, content: bytes, options: dict = None) -> dict:
"""Llama a GRACE para procesar contenido."""
job = runpod.run(
endpoint_id="r00x4g3rrwkbyh",
input={
"module": module,
"data": base64.b64encode(content).decode(),
"options": options or {}
}
)
# Polling hasta completar
while True:
status = runpod.status(job["id"])
if status["status"] == "COMPLETED":
return status["output"]
elif status["status"] == "FAILED":
raise Exception(status.get("error", "Job failed"))
time.sleep(1)
```
---
## Problema Actual: Workers No Inician
### Incidente 2024-12-24
- **Síntoma:** 0 workers activos a pesar de jobs en cola
- **Balance:** $72+ (suficiente)
- **Configuración:** Correcta
- **Causa probable:** Problema de capacidad RunPod
### Intentos de Diagnóstico
1. Verificado endpoint activo en dashboard
2. Verificado balance suficiente
3. Verificado configuración de scaling
4. Jobs quedan en estado "IN_QUEUE" indefinidamente
### Log de Errores
```
No hay logs disponibles - workers nunca inician
```
---
## Alternativas Evaluadas
### 1. Modal (Recomendado)
```python
import modal
stub = modal.Stub("grace")
image = modal.Image.debian_slim().pip_install("whisper", "easyocr")
@stub.function(gpu="A10G", image=image)
def process_asr(audio_bytes: bytes) -> dict:
import whisper
model = whisper.load_model("large-v3")
result = model.transcribe(audio_bytes)
return {"text": result["text"]}
```
**Pros:**
- Serverless real
- Buen DX (developer experience)
- Python-native
- Cold start rápido
**Contras:**
- Menos GPUs disponibles que RunPod
- Pricing puede ser mayor
### 2. Replicate
```python
import replicate
output = replicate.run(
"openai/whisper:large-v3",
input={"audio": audio_url}
)
```
**Pros:**
- Modelos pre-entrenados
- API simple
- Sin gestión de infraestructura
**Contras:**
- Menos control
- Más caro a escala
- Dependencia de modelos de terceros
### 3. Lambda Labs
**Pros:**
- Hardware dedicado
- GPUs disponibles
**Contras:**
- Menos flexible
- Reserva manual
- No serverless
### 4. Self-Hosted
**Pros:**
- Control total
- Sin dependencias externas
- Costo fijo a largo plazo
**Contras:**
- CapEx alto
- Mantenimiento
- Requiere expertise
---
## Plan de Migración
### Fase 1: Evaluación
- [ ] Crear cuenta Modal
- [ ] Portar módulo ASR a Modal
- [ ] Comparar latencia con RunPod (cuando funcione)
- [ ] Comparar costos
### Fase 2: Migración
- [ ] Portar 6 handlers a Modal
- [ ] Actualizar endpoints en MASON
- [ ] Actualizar documentación
- [ ] Testing end-to-end
### Fase 3: Producción
- [ ] Desplegar en Modal
- [ ] Monitorear costos y performance
- [ ] Deprecar RunPod endpoints
- [ ] Cancelar cuenta RunPod
---
## Principio Fundamental
**GRACE nunca modifica datos.**
GRACE es read-only: extrae información pero no puede modificar el contenido original ni los datos del sistema. Las extracciones se almacenan como metadatos asociados al contenido original.
```
Contenido Original ────► GRACE ────► Metadatos Extraídos
(inmutable) (nuevos datos)
```

View File

@@ -0,0 +1,450 @@
# TZZR - Especificación de Base de Datos
**Versión:** 2.1
**Fecha:** 6 Enero 2026
**Estado:** Actualizado
---
## 1. Estructura de Tablas Principales
### 1.1 Esquema Completo
| hst | flg | ply | itm | loc | mst | bck | mth |
|-----|-----|-----|-----|-----|-----|-----|-----|
| num | num | num | num | num | num | num | num |
| alias | alias | alias | alias | alias | alias | alias | alias |
| ref | ref | ref | ref | ref | ref | ref | ref |
| mrf | mrf | mrf | mrf | mrf | mrf | mrf | mrf |
| private_mrf | private_mrf | private_mrf | private_mrf | private_mrf | private_mrf | private_mrf | private_mrf |
| name_es | name_es | name_es | name_es | name_es | name_es | name_es | name_es |
| name_en | name_en | name_en | name_en | name_en | name_en | name_en | name_en |
| name_ch | name_ch | name_ch | name_ch | name_ch | name_ch | name_ch | name_ch |
| group | group | group | - | - | - | - | - |
| - | - | - | set_hst | set_hst | set_hst | set_hst | set_hst |
| - | - | - | - | - | link_mst | link_mst | - |
| - | - | - | - | - | link_bck | link_bck | - |
| txt | txt | txt | txt | txt | txt | txt | txt |
| - | - | hashtags | hashtags | hashtags | hashtags | hashtags | hashtags |
| standard_md | standard_md | - | - | - | - | - | - |
| - | - | standard_data | standard_data | standard_data | standard_data | standard_data | standard_data |
| jsonb_standard | jsonb_standard | - | - | - | - | - | - |
| - | - | jsonb_data | jsonb_data | jsonb_data | jsonb_data | jsonb_data | jsonb_data |
| version | version | version | version | version | version | version | version |
| rootref | rootref | rootref | rootref | rootref | rootref | rootref | rootref |
| roothash | roothash | roothash | roothash | roothash | roothash | roothash | roothash |
| img_url | img_url | img_url | img_url | img_url | img_url | img_url | img_url |
| img_thumb_url | img_thumb_url | img_thumb_url | img_thumb_url | img_thumb_url | img_thumb_url | img_thumb_url | img_thumb_url |
| owner | owner | owner | owner | owner | owner | owner | owner |
| - | - | set_flg | set_flg | set_flg | set_flg | set_flg | set_flg |
| url | url | url | url | url | - | - | - |
| - | - | - | url_atc | - | url_atc | url_atc | url_atc |
| url_json | url_json | url_json | url_json | url_json | url_json | url_json | url_json |
| date | date | date | date | date | date | date | date |
| created_at | created_at | created_at | created_at | created_at | created_at | created_at | created_at |
| - | - | - | - | - | mth_mrf | mth_mrf | - |
---
## 2. Clasificación de Tablas
| Tipo | Tablas | Descripción |
|------|--------|-------------|
| Etiquetado semántico | hst, flg | Vocabulario controlado, trazabilidad |
| Entidades de negocio | ply, itm, loc | Actores, productos, ubicaciones |
| Gestión de procesos | mst, bck, mth | Burocracia, evidencia real, métodos |
### 2.1 Detalle MST/BCK/MTH
| Tabla | Nombre | Descripción |
|-------|--------|-------------|
| mst | Master | Burocracia, documentos formales, registros administrativos |
| bck | Back | Evidencia del mundo real, trabajo efectivo, hechos |
| mth | Method | Métodos, procesos productivos predefinidos |
---
## 3. Descripción de Campos
| Campo | Tipo | Descripción |
|-------|------|-------------|
| num | INTEGER | Identificador numérico autoincremental |
| alias | VARCHAR | Nombre corto del registro |
| ref | VARCHAR | Código único (típicamente 3 letras) |
| mrf | VARCHAR(64) | Hash público SHA-256 (identidad del registro) |
| private_mrf | VARCHAR(64) | Hash original SHA-256 (prueba de propiedad) |
| name_es | VARCHAR | Nombre en español |
| name_en | VARCHAR | Nombre en inglés |
| name_ch | VARCHAR | Nombre en chino |
| group | VARCHAR | Subgrupo dentro de hst/flg/ply (enum cerrado) |
| set_hst | VARCHAR(64) | mrf del hashtag que define el tipo (abierto) |
| link_mst | VARCHAR/JSONB | Enlace a un mst (único o múltiple según tabla) |
| link_bck | JSONB/VARCHAR | Enlace a bck (único o múltiple según tabla) |
| txt | TEXT | Texto libre / descripción |
| hashtags | JSONB | Array de mrfs de hst |
| standard_md | TEXT | Descripción técnica en Markdown (define formato) |
| standard_data | TEXT | Formato heredado del group |
| jsonb_standard | JSONB | Schema JSON con versiones (define estructura) |
| jsonb_data | JSONB | Datos reales según schema |
| version | VARCHAR | Versión del formato usado |
| rootref | VARCHAR | Concatenación de refs (jerarquía) |
| roothash | JSONB | Array de mrfs (jerarquía) |
| img_url | VARCHAR | URL de imagen original |
| img_thumb_url | VARCHAR | URL de thumbnail |
| owner | JSONB | Propietario(s) |
| set_flg | JSONB | Array de mrfs de flg |
| url | VARCHAR | URL externa |
| url_atc | JSONB | Array de URLs de adjuntos |
| url_json | VARCHAR/JSONB | URL(s) de archivos JSON para IA |
| date | DATE | Fecha manual significativa |
| created_at | TIMESTAMP | Fecha de creación automática |
| mth_mrf | VARCHAR(64) | Referencia al proceso productivo |
---
## 4. Tablas Relacionales
### 4.1 Árbol y Grafos
| tree_hst | tree_flg | graph_hst | graph_flg | library_hst | library_flg |
|----------|----------|-----------|-----------|-------------|-------------|
| mrf_parent | mrf_parent | mrf_a | mrf_a | mrf_library | mrf_library |
| mrf_child | mrf_child | mrf_b | mrf_b | mrf_hst | mrf_flg |
| - | - | weight | weight | - | - |
| - | - | edge_type | edge_type | - | - |
### 4.2 Relaciones Entidades-Tags
| ply_hst | ply_flg | itm_hst | itm_flg | loc_hst | loc_flg |
|---------|---------|---------|---------|---------|---------|
| mrf_ply | mrf_ply | mrf_itm | mrf_itm | mrf_loc | mrf_loc |
| mrf_hst | mrf_flg | mrf_hst | mrf_flg | mrf_hst | mrf_flg |
| mst_hst | mst_flg | bck_hst | bck_flg | mth_hst | mth_flg |
|---------|---------|---------|---------|---------|---------|
| mrf_mst | mrf_mst | mrf_bck | mrf_bck | mrf_mth | mrf_mth |
| mrf_hst | mrf_flg | mrf_hst | mrf_flg | mrf_hst | mrf_flg |
---
## 5. Grupos (group)
### 5.1 HST - Etiquetado Semántico
| group | Nombre | Regla de ref |
|-------|--------|--------------|
| hst | hashtags base | Cada registro tiene ref única |
| spe | especificaciones | Todos tienen ref = "spe" |
| vsn | visiones | Todos tienen ref = "vsn" |
| vue | valores | Todos tienen ref = "vue" |
| msn | misiones | ref = "msn", "pjt", "tgt" o "ctg" |
### 5.2 PLY - Players
| ref | group | Descripción |
|-----|-------|-------------|
| ppl | persona | Individuo humano |
| inc | empresa | Entidad jurídica |
| tem | equipo | Grupo de personas |
| ain | inteligencia artificial | Agente artificial |
---
## 6. Edge Types (graph)
| edge_type | Descripción |
|-----------|-------------|
| relation | Genérica |
| specialization | Es-un-tipo-de |
| mirror | Equivalencia/reflejo |
| dependency | Depende-de |
| composition | Parte-de |
| sequence | Sigue-a |
| association | Asociado-con |
| contextual | En-contexto-de |
| alternative | Alternativa-a |
---
## 7. Estructura de Carpetas (Servidor)
```
/hst/
├── bases/ # Backups SQL
├── images/
│ ├── hst/thumb/
│ ├── flg/thumb/
│ ├── ply/thumb/
│ ├── itm/thumb/
│ ├── loc/thumb/
│ ├── mst/thumb/
│ ├── bck/thumb/
│ └── mth/thumb/
└── map/
```
---
## 8. Infraestructura
| Servidor | IP | Propósito |
|----------|-----|-----------|
| ARCHITECT | 69.62.126.110 | Desarrollo |
| HST | 72.62.2.84 | API tags semánticos |
| DECK | 72.62.1.113 | Usuario |
| CORP | 92.112.181.188 | Corporativo |
| Parámetro | Valor |
|-----------|-------|
| Container | postgres_hst |
| Usuario | directus |
| DB | hst_images |
| R2 Endpoint | https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com |
---
## 9. Tablas Oracle (Prospectiva)
### oracle_analisis
| Campo | Tipo | Descripción |
|-------|------|-------------|
| num | SERIAL | Identificador |
| mrf | VARCHAR(64) | Hash público (PK) |
| private_mrf | VARCHAR(64) | Hash privado |
| name_es | VARCHAR(255) | Nombre en español |
| name_en | VARCHAR(255) | Nombre en inglés |
| txt | TEXT | Descripción |
| h_bloques_feldman | JSONB | Array de mrfs de Feldman |
| periodo_inicio | DATE | Inicio período histórico |
| periodo_fin | DATE | Fin período histórico |
| h_dataset | VARCHAR(64) | Hash integridad del conjunto |
| modelo_name | VARCHAR(255) | Nombre del modelo |
| modelo_version | VARCHAR(50) | Versión del modelo |
| modelo_metodologia | TEXT | Descripción metodología |
| modelo_formulas | JSONB | Fórmulas de cálculo |
| modelo_parametros | JSONB | Parámetros fijos |
| modelo_limitaciones | TEXT | Limitaciones |
| supuestos | JSONB | Array de supuestos |
| escenario_base | JSONB | Escenario base |
| escenario_optimista | JSONB | Escenario optimista |
| escenario_pesimista | JSONB | Escenario pesimista |
| escenario_estres | JSONB | Escenario estrés |
| sensibilidad | JSONB | Análisis sensibilidad |
| estado | VARCHAR(20) | activo, caducado, invalidado |
| fecha_caducidad | DATE | Fecha expiración |
| condiciones_invalidacion | TEXT | Qué invalida el análisis |
| autor | VARCHAR(255) | Usuario o módulo Grace |
| owner | JSONB | Propietario(s) |
| version | VARCHAR(50) | Versión |
| date | DATE | Fecha emisión |
| created_at | TIMESTAMP | Fecha creación |
### oracle_escenario
| Campo | Tipo | Descripción |
|-------|------|-------------|
| num | SERIAL | Identificador |
| mrf | VARCHAR(64) | Hash público (PK) |
| private_mrf | VARCHAR(64) | Hash privado |
| analisis_mrf | VARCHAR(64) | FK a oracle_analisis |
| name_es | VARCHAR(255) | Nombre en español |
| name_en | VARCHAR(255) | Nombre en inglés |
| txt | TEXT | Descripción |
| valores_supuestos | JSONB | id_supuesto → valor |
| resultado_min | NUMERIC | Límite inferior |
| resultado_max | NUMERIC | Límite superior |
| resultado_medio | NUMERIC | Valor central |
| horizonte | VARCHAR(50) | Período proyección |
| comparado_con | JSONB | Array mrfs otros escenarios |
| autor | VARCHAR(255) | Usuario |
| owner | JSONB | Propietario(s) |
| date | DATE | Fecha |
| created_at | TIMESTAMP | Fecha creación |
---
## 10. Resumen
| Tipo | Cantidad |
|------|----------|
| Tablas principales | 8 |
| Tablas Oracle | 2 |
| Tablas árbol/grafos | 6 |
| Tablas relacionales | 12 |
| **Total** | **28** |
---
## 11. Changelog
### v2.1 (4 Enero 2026)
- Añadido `img_thumb_url` en todas las tablas
### v2.0 (4 Enero 2026)
| Antes | Después |
|-------|---------|
| nombre_es/en/ch | name_es/en/ch |
| estandar_md | standard_md |
| estandar_data | standard_data |
| grupo | group |
| mrf_padre | mrf_parent |
| mrf_hijo | mrf_child |
| mrf_biblioteca | mrf_library |
---
# Anexo: Cuestiones Pendientes
## A.1 Subgrupos por Definir
### FLG - Flags
| Categoría | Códigos | Ejemplos | Estado |
|-----------|---------|----------|--------|
| Países | ??? | España, USA, China | Pendiente |
| Jurisdicciones | ??? | UE, LATAM, NAFTA | Pendiente |
| Normativas | ??? | RGPD, SOX, HIPAA | Pendiente |
| Estándares | ??? | ISO 27001, Bluetooth, WiFi | Pendiente |
### ITM - Items
| Categoría | Códigos | Ejemplos | Estado |
|-----------|---------|----------|--------|
| ??? | ??? | Productos, componentes, materiales | Pendiente |
**Referencia:** Marco temporal T-N → T+N ya definido (crf, mku, zmd, prd, itm).
### LOC - Locations
| Categoría | Códigos | Ejemplos | Estado |
|-----------|---------|----------|--------|
| Punto | ??? | Coordenadas exactas | Pendiente |
| Área | ??? | Zona delimitada | Pendiente |
| Ruta | ??? | Trayecto entre puntos | Pendiente |
---
## A.2 Estructura jsonb_standard (Capas)
| Capa | Nombre | Contenido |
|------|--------|-----------|
| L1 | core | Identificación básica |
| L2 | {dominio} | Datos específicos del tipo |
| L3 | relations | Referencias a otras entidades |
| L4 | extended | Datos opcionales |
| L5 | metadata | Auditoría, versiones |
| L6+ | custom | Extensiones específicas |
**Estado:** Propuesto, no validado.
---
## A.3 Campos jsonb_data por Tabla
| Tabla | Campos esperados en jsonb_data | Estado |
|-------|--------------------------------|--------|
| ply (ppl) | fecha_nacimiento, genero, ... | Pendiente |
| ply (inc) | nombre_fiscal, codigo_fiscal, telefono, email, direccion, numero_cuenta | Parcial |
| ply (tem) | miembros, ... | Pendiente |
| ply (ain) | modelo, proveedor, ... | Pendiente |
| itm | ref_supplier, moq, lote, embalaje, unidad, coste, iva, delivery_time, specs | Parcial |
| loc | lat, lon, precision, tipo_zona, ... | Pendiente |
| mst | positivo, negativo, time, count, days, fecha_objetivo, ... | Parcial |
| bck | fecha_inicio, fecha_final, prioridad, ... | Parcial |
| mth | pasos, secuencia, validaciones, ... | Pendiente |
---
## A.4 Formatos de owner
| Caso | Formato | Estado |
|------|---------|--------|
| Propietario único | `"mrf123..."` | Definido |
| Múltiples propietarios | `[{"mrf": "...", "participacion": 51}, ...]` | Definido |
| Empresa con socios | Schema en hst ref="owner" | Pendiente |
---
## A.5 Bibliotecas
### Visibilidad Pública/Privada
| Aspecto | Decisión | Implementación |
|---------|----------|----------------|
| Diferencia en datos | No hay | - |
| Discriminación | En endpoint | Pendiente |
### Niveles de Biblioteca
| Nivel | Descripción | Estado |
|-------|-------------|--------|
| Sistema (pública) | Disponibles para todos | Existente |
| Sistema (privada) | Backup completo, solo admin | Existente |
| Usuario | Creadas por el usuario | Por implementar |
---
## A.6 Sincronización de Tablas Redundantes
| Opción | Descripción | Estado |
|--------|-------------|--------|
| Triggers | Actualización automática en INSERT/UPDATE | Por evaluar |
| Batch | Sincronización periódica | Por evaluar |
| Aplicación | Lógica en el código | Por evaluar |
**Pregunta:** ¿Cómo se sincronizan las tablas redundantes (ply_hst, itm_flg, etc.) con los campos JSONB (hashtags, set_flg)?
---
## A.7 API y Endpoints Pendientes
| Endpoint | Función | Estado |
|----------|---------|--------|
| /biblioteca/import | Importar biblioteca | Pendiente |
| /biblioteca/export | Exportar biblioteca | Pendiente |
| /sync/redundant | Sincronizar tablas redundantes | Pendiente |
---
## A.8 Validaciones
### Foreign Keys
| Decisión | Estado |
|----------|--------|
| Usar FK con DEFERRABLE INITIALLY DEFERRED | Propuesto |
| Permitir importación masiva sin validación inmediata | Propuesto |
### Constraints de Unicidad
| Campo | Tabla | Constraint | Estado |
|-------|-------|------------|--------|
| mrf | todas | UNIQUE | Por verificar |
| ref | hst (dentro de grupo) | UNIQUE | Por verificar |
| mrf_child | tree_* | UNIQUE | Existente |
---
## A.9 Prioridades
### Alta (Bloquea desarrollo)
1. Definir subgrupos FLG
### Media (Mejora funcionalidad)
2. Definir jsonb_data por tabla
3. Mecanismo de sincronización tablas redundantes
4. Endpoints de importación/exportación
### Baja (Optimización)
5. Subgrupos ITM, LOC, MST, BCK, MTH
6. Documentación de estándares
7. Migración a Gitea
---
*TZZR Database Schema v2.1 - 6 Enero 2026*

81
03_MODELO_DATOS/README.md Normal file
View File

@@ -0,0 +1,81 @@
# 03 - Modelo de Datos
> Estructuras de datos, schemas SQL y flujos de informacion
## Documentacion Conceptual
| Documento | Descripcion |
|-----------|-------------|
| [entidades.md](entidades.md) | Definicion de HST, ITM, PLY, LOC, FLG |
| [planos.md](planos.md) | T0 (ideal), MST (milestones), BCK (bloques) |
| [hashes.md](hashes.md) | h_maestro, h_entrada, h_instancia, h_bloque |
| [flujos.md](flujos.md) | Flujos estandar, produccion e incidencia |
| [contenedor-schema.md](contenedor-schema.md) | Schema del contenedor principal |
| [context-tables.md](context-tables.md) | Tablas del sistema de contexto |
## Estandares HST (HashTag Semantico)
| Documento | Descripcion |
|-----------|-------------|
| **[hst-schemas-index.md](hst-schemas-index.md)** | **Indice de 13 schemas HST** |
| [hst-contract-cct.md](hst-contract-cct.md) | Detalle del estandar Contract (CCT) |
### Resumen de Schemas
| Tag | Nombre | Campos | Tipo |
|-----|--------|--------|------|
| `inv` | Factura | 250 | Ventas |
| `siv` | Factura Proveedor | 250 | Compras |
| `ord` | Pedido | 200 | Ventas |
| `sod` | Pedido Proveedor | 200 | Compras |
| `off` | Oferta | 180 | Ventas |
| `qtt` | Cotizacion | 180 | Compras |
| `dpa` | Aviso de Despacho | 180 | Logistica |
| `dnt` | Albaran | 160 | Logistica |
| `cct` | Contrato | 280 | Legal |
| `bgt` | Presupuesto | 120 | Comercial |
| `gtc` | Condiciones Generales | 90 | Legal |
| `evt` | Evento | 80 | Gestion |
| `tsk` | Tarea | 70 | Gestion |
## Schemas SQL
Definiciones de base de datos en PostgreSQL.
| Schema | Archivo | Proposito |
|--------|---------|-----------|
| Types | [00_types.sql](schemas/00_types.sql) | Tipos ENUM y estructuras base |
| HST Tags | [01_hst_tags.sql](schemas/01_hst_tags.sql) | Sistema de etiquetado semantico |
| Task Manager | [02_task_manager.sql](schemas/02_task_manager.sql) | Gestion de tareas y workflows |
| Work Log | [03_work_log.sql](schemas/03_work_log.sql) | Registro inmutable de trabajo |
| AI Context | [04_ai_context.sql](schemas/04_ai_context.sql) | Contexto para modelos de IA |
| AI Requests | [05_ai_requests.sql](schemas/05_ai_requests.sql) | Solicitudes y respuestas de IA |
| Clara | [06_clara.sql](schemas/06_clara.sql) | Schema del agente Clara |
| Feldman | [07_feldman.sql](schemas/07_feldman.sql) | Schema del agente Feldman |
| Alfred | [08_alfred.sql](schemas/08_alfred.sql) | Schema del agente Alfred |
Ver [schemas/README.md](schemas/README.md) para detalles de implementacion.
## Jerarquia de Hashes
```
h_maestro (identidad unica del elemento)
|
+-- h_entrada (cada modificacion)
| |
| +-- h_instancia (version especifica)
|
+-- h_bloque (consolidacion periodica)
```
## Planos Temporales
| Plano | Codigo | Descripcion |
|-------|--------|-------------|
| Ideal | T0 | Estado objetivo, vision final |
| Milestone | MST | Puntos de control intermedios |
| Bloque | BCK | Consolidaciones inmutables |
---
[<- Volver al indice](../README.md)

View File

@@ -0,0 +1,347 @@
# Estructura CONTENEDOR
Esquema de datos completo para un registro en el sistema TZZR.
## Esquema JSON
```json
{
"id": "uuid-contenedor",
"h_instancia": "sha256-instancia",
"archivo_hash": "sha256-archivo",
"origen": {
"dispositivo": "uuid-dispositivo",
"app_version": "1.0.0",
"timestamp_captura": "2025-01-15T10:30:00Z",
"geolocalizacion": {
"lat": 41.3851,
"lon": 2.1734,
"precision_m": 10
}
},
"archivo": {
"tipo": "image/jpeg",
"categoria": "imagen",
"size_bytes": 2048576,
"nombre_original": "IMG_2024.jpg",
"dimensiones": {
"ancho": 1920,
"alto": 1080
},
"duracion_seg": null
},
"tags": [
{
"h_maestro": "sha256-tag",
"grupo": "hst",
"nombre": "Factura",
"confianza": 1.0
}
],
"extraccion": {
"servicio": "openai-vision",
"version": "gpt-4o",
"timestamp": "2025-01-15T10:30:05Z",
"coste_cents": 2,
"texto": "FACTURA N 2024-001...",
"resumen": "Factura de servicios por 1.500EUR",
"entidades": {
"fechas": ["2025-01-15"],
"importes": [{"valor": 1500.00, "moneda": "EUR"}],
"personas": [],
"organizaciones": ["Acme Corp"],
"ubicaciones": [],
"documentos": [{"tipo": "factura", "numero": "2024-001"}]
},
"clasificacion": {
"categoria": "finanzas",
"subcategoria": "factura_recibida",
"confianza": 0.95
},
"tags_sugeridos": [
{"h_maestro": "sha256", "nombre": "Factura", "confianza": 0.95}
],
"especifico": {}
},
"enriquecimiento": {
"notas": "Pendiente de pago",
"campos_personalizados": {
"proyecto": "Proyecto Alpha",
"responsable": "Juan Garcia"
},
"tags_confirmados": ["sha256-tag1", "sha256-tag2"],
"tags_rechazados": ["sha256-tag3"],
"correcciones": {
"texto": null,
"entidades": null
},
"editado_por": "usuario-id",
"editado_at": "2025-01-15T11:00:00Z"
},
"estado": {
"actual": "en_feldman_cola",
"historial": [
{"paso": "clara", "entrada": "...", "salida": "...", "procesado_por": "clara-service"},
{"paso": "mason", "entrada": "...", "salida": "...", "procesado_por": "usuario-id"},
{"paso": "feldman_cola", "entrada": "...", "procesado_por": "feldman-service"}
]
},
"bloque": {
"id": "sha256-bloque",
"numero": 42,
"registro_hash": "sha256-este-registro",
"merkle_proof": ["sha256-1", "sha256-2", "sha256-3"]
}
}
```
---
## Secciones
### IDENTIFICACION
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `id` | UUID | Identificador unico del contenedor, generado por PACKET |
| `h_instancia` | SHA-256 | Identifica servidor DECK/CORP de origen |
| `archivo_hash` | SHA-256 | Hash del archivo, sirve como ruta en R2 |
**Ruta R2**: `{endpoint}/{archivo_hash}`
---
### ORIGEN
Informacion del momento de captura. Generada automaticamente por PACKET.
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `dispositivo` | UUID | ID del dispositivo que capturo |
| `app_version` | String | Version de PACKET |
| `timestamp_captura` | ISO 8601 | Momento exacto de captura |
| `geolocalizacion` | Object | Ubicacion GPS (opcional) |
| `geolocalizacion.lat` | Float | Latitud |
| `geolocalizacion.lon` | Float | Longitud |
| `geolocalizacion.precision_m` | Int | Precision en metros |
**Inmutable**: Esta seccion nunca se modifica despues de la captura.
---
### ARCHIVO
Metadata tecnica del archivo capturado.
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `tipo` | String | MIME type (image/jpeg, audio/mp3, etc.) |
| `categoria` | Enum | imagen, audio, video, documento |
| `size_bytes` | Int | Tamano en bytes |
| `nombre_original` | String | Nombre original del archivo (opcional) |
| `dimensiones.ancho` | Int | Ancho en pixels (imagen/video) |
| `dimensiones.alto` | Int | Alto en pixels (imagen/video) |
| `duracion_seg` | Float | Duracion en segundos (audio/video) |
**Inmutable**: Esta seccion nunca se modifica.
---
### TAGS
Etiquetas aplicadas por el usuario en PACKET al momento de captura.
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `h_maestro` | SHA-256 | Referencia a la biblioteca de tags |
| `grupo` | Enum | hst, emp, hsu, pjt, sys |
| `nombre` | String | Nombre visible del tag |
| `confianza` | Float | 1.0 = usuario, <1.0 = sugerido por IA |
**Grupos de tags**:
- `hst`: Biblioteca publica HST
- `emp`: Biblioteca de empresa
- `hsu`: Biblioteca personal de usuario
- `pjt`: Biblioteca de proyecto
- `sys`: Tags de sistema (automaticos)
**Mutable**: Se pueden anadir tags en MASON.
---
### EXTRACCION
Resultado del servicio de extraccion (OCR, transcripcion, analisis IA).
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `servicio` | String | Identificador del servicio usado |
| `version` | String | Version del modelo/servicio |
| `timestamp` | ISO 8601 | Momento de la extraccion |
| `coste_cents` | Int | Coste en centavos (obligatorio para auditoria) |
| `texto` | String | Contenido textual extraido |
| `resumen` | String | Resumen generado por IA |
| `entidades` | Object | Datos estructurados detectados |
| `clasificacion` | Object | Categoria sugerida automaticamente |
| `tags_sugeridos` | Array | Tags de biblioteca que podrian aplicar |
| `especifico` | Object | Campos segun tipo de archivo |
#### Entidades detectadas
```json
{
"fechas": ["2025-01-15"],
"importes": [{"valor": 1500.00, "moneda": "EUR"}],
"personas": ["Juan Garcia"],
"organizaciones": ["Acme Corp"],
"ubicaciones": ["Barcelona"],
"documentos": [{"tipo": "factura", "numero": "2024-001"}]
}
```
#### Campos especificos por tipo
**Imagen**:
```json
{
"descripcion_visual": "Documento escaneado...",
"objetos_detectados": ["documento", "texto", "logo"],
"texto_ocr_bruto": "..."
}
```
**Audio**:
```json
{
"transcripcion": "...",
"idioma_detectado": "es",
"hablantes": 2
}
```
**Video**:
```json
{
"transcripcion": "...",
"escenas": [...]
}
```
**Documento (PDF)**:
```json
{
"paginas": 3,
"texto_por_pagina": ["...", "...", "..."]
}
```
**Inmutable**: Esta seccion no se modifica una vez generada.
---
### ENRIQUECIMIENTO
Lo que el usuario anade o modifica en MASON.
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `notas` | String | Texto libre del usuario |
| `campos_personalizados` | Object | Campos key-value definidos por usuario |
| `tags_confirmados` | Array | h_maestro de tags sugeridos aceptados |
| `tags_rechazados` | Array | h_maestro de tags sugeridos descartados |
| `correcciones.texto` | String | Texto corregido si OCR fallo |
| `correcciones.entidades` | Object | Entidades corregidas |
| `editado_por` | String | ID del usuario que edito |
| `editado_at` | ISO 8601 | Ultima edicion |
**Mutable**: Hasta que se consolida en FELDMAN.
---
### ESTADO
Trazabilidad del registro a traves del sistema.
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `actual` | String | Ubicacion actual del registro |
| `historial` | Array | Pasos por los que ha pasado |
| `historial[].paso` | String | Nombre del paso (clara, mason, feldman_cola, feldman_bloque) |
| `historial[].entrada` | ISO 8601 | Cuando entro |
| `historial[].salida` | ISO 8601 | Cuando salio |
| `historial[].procesado_por` | String | Servicio o usuario que proceso |
**Estados posibles**:
- `en_clara` / `en_margaret`: Recien capturado
- `en_mason`: En enriquecimiento
- `en_feldman_cola`: Esperando consolidacion
- `en_feldman_bloque`: Consolidado (inmutable)
---
### BLOQUE
Solo se rellena cuando FELDMAN consolida el registro.
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| `id` | SHA-256 | Hash del bloque |
| `numero` | Int | Numero secuencial del bloque |
| `registro_hash` | SHA-256 | Hash de este registro |
| `merkle_proof` | Array | Prueba de inclusion en el arbol Merkle |
**Inmutable**: Una vez consolidado, nunca cambia.
---
## Mutabilidad por Seccion
| Seccion | Quien escribe | Inmutable |
|---------|---------------|-----------|
| identificacion | PACKET | Si |
| origen | PACKET | Si |
| archivo | PACKET | Si |
| tags | PACKET (usuario) | No (se puede anadir) |
| extraccion | Servicio externo | Si |
| enriquecimiento | Usuario en MASON | No (hasta consolidar) |
| estado | Sistema | Se acumula |
| bloque | FELDMAN | Si (al consolidar) |
---
## Flujo de datos
```
PACKET genera:
- identificacion
- origen
- archivo
- tags (iniciales)
CLARA/MARGARET registra:
- estado.historial += {paso: "clara/margaret"}
Servicio extraccion anade:
- extraccion (completa)
MASON permite editar:
- enriquecimiento
- tags (anadir)
- estado.historial += {paso: "mason"}
FELDMAN consolida:
- bloque (completo)
- estado.actual = "en_feldman_bloque"
- estado.historial += {paso: "feldman_bloque"}
```
---
*Actualizado: 2025-12-22*

View File

@@ -0,0 +1,262 @@
# Tablas de Contexto
**Estado:** Implementado
**Base de datos:** PostgreSQL (ARCHITECT)
---
## Descripción
Tablas que proporcionan contexto a las instancias Claude.
---
## Diagrama de Relaciones
```
instancias ──┬── memoria
└── conversaciones ──── mensajes_v2
└── memoria (conversacion_origen)
conocimiento (independiente, compartido)
contexto_ambiental (independiente, periódico)
```
---
## instancias
Identidad de cada instancia Claude.
```sql
CREATE TABLE instancias (
id VARCHAR(50) PRIMARY KEY,
nombre VARCHAR(100),
system_prompt TEXT NOT NULL,
personalidad JSONB DEFAULT '{
"tono": "profesional",
"idioma": "es",
"verbosidad": "conciso"
}',
permisos JSONB DEFAULT '{
"puede_ejecutar_bash": false,
"puede_acceder_red": false,
"puede_modificar_archivos": false,
"servidores_permitidos": []
}',
modelo VARCHAR(50) DEFAULT 'sonnet',
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
```
**Uso:** Define quién es cada Claude, su personalidad, y qué puede hacer.
### Instancias Activas
| ID | Nombre | Modelo | Servidor |
|----|--------|--------|----------|
| architect | Architect | sonnet | ARCHITECT |
| hst | HST | sonnet | HST |
| deck | Deck | sonnet | DECK |
| corp | Corp | sonnet | CORP |
| runpod | Runpod | sonnet | RunPod |
| locker | Locker | haiku | R2/Storage |
---
## memoria
Memoria a largo plazo por instancia.
```sql
CREATE TABLE memoria (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
instancia_id VARCHAR(50) REFERENCES instancias(id),
tipo VARCHAR(50) NOT NULL,
contenido TEXT NOT NULL,
importancia INT DEFAULT 5,
usos INT DEFAULT 0,
ultimo_uso TIMESTAMP,
conversacion_origen UUID REFERENCES conversaciones(id),
expira_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_memoria_instancia ON memoria(instancia_id, importancia DESC);
CREATE INDEX idx_memoria_tipo ON memoria(instancia_id, tipo);
```
### Tipos de Memoria
| Tipo | Descripción |
|------|-------------|
| preferencia | Preferencias del usuario |
| hecho | Hechos aprendidos |
| decision | Decisiones tomadas |
| aprendizaje | Lecciones aprendidas |
| procedimiento | Procedimientos aprendidos |
---
## conocimiento
Base de conocimiento compartida (RAG).
```sql
CREATE TABLE conocimiento (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
categoria VARCHAR(50) NOT NULL,
titulo VARCHAR(200),
contenido TEXT NOT NULL,
tags TEXT[],
instancias_permitidas VARCHAR(50)[],
prioridad INT DEFAULT 0,
fuente VARCHAR(200),
hash_contenido VARCHAR(64),
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_conocimiento_categoria ON conocimiento(categoria);
CREATE INDEX idx_conocimiento_prioridad ON conocimiento(prioridad DESC);
CREATE INDEX idx_conocimiento_tags ON conocimiento USING GIN(tags);
```
### Categorías
| Categoría | Descripción |
|-----------|-------------|
| infraestructura | Documentación de infra |
| proyecto | Información de proyectos |
| personal | Datos personales |
| procedimiento | Procedimientos operativos |
---
## conversaciones
Sesiones de chat.
```sql
CREATE TABLE conversaciones (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
instancia_id VARCHAR(50) REFERENCES instancias(id),
usuario VARCHAR(50) NOT NULL,
titulo VARCHAR(200),
activa BOOLEAN DEFAULT TRUE,
total_tokens INT DEFAULT 0,
total_mensajes INT DEFAULT 0,
resumen TEXT,
resumen_updated_at TIMESTAMP,
contexto_ambiental JSONB DEFAULT '{
"proyecto_activo": null,
"archivos_abiertos": [],
"ultimo_comando": null,
"hora_local": null
}',
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_conversaciones_instancia ON conversaciones(instancia_id, activa);
CREATE INDEX idx_conversaciones_usuario ON conversaciones(usuario, activa);
```
---
## mensajes_v2
Mensajes con soporte para compactación.
```sql
CREATE TABLE mensajes_v2 (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
conversacion_id UUID REFERENCES conversaciones(id),
role VARCHAR(20) NOT NULL CHECK (role IN ('user', 'assistant', 'system')),
contenido TEXT NOT NULL,
archivos JSONB DEFAULT '[]',
tokens_estimados INT,
compactado BOOLEAN DEFAULT FALSE,
resumen_compactado TEXT,
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_mensajes_v2_conversacion ON mensajes_v2(conversacion_id, created_at);
CREATE INDEX idx_mensajes_v2_no_compactados ON mensajes_v2(conversacion_id, compactado)
WHERE compactado = FALSE;
```
**Nota:** Los mensajes antiguos se compactan (resumen) para ahorrar tokens.
---
## contexto_ambiental
Estado actual del sistema (captura periódica).
```sql
CREATE TABLE contexto_ambiental (
id SERIAL PRIMARY KEY,
capturado_at TIMESTAMP DEFAULT NOW(),
servidores JSONB,
servicios JSONB,
tareas_pendientes JSONB,
alertas JSONB,
git_estado JSONB,
expira_at TIMESTAMP DEFAULT NOW() + INTERVAL '1 hour'
);
CREATE INDEX idx_contexto_ambiental_tiempo ON contexto_ambiental(capturado_at DESC);
```
### Estructura JSONB
```json
{
"servidores": {
"architect": {"status": "online", "uptime": "5d"},
"deck": {"status": "online", "uptime": "3d"}
},
"servicios": {
"gitea": "running",
"windmill": "running",
"directus": "running"
},
"tareas_pendientes": [
{"id": 1, "descripcion": "...", "prioridad": "alta"}
],
"alertas": [
{"tipo": "warning", "mensaje": "...", "severidad": "medium"}
],
"git_estado": {
"branch": "main",
"commits_ahead": 0,
"uncommitted_changes": false
}
}
```
---
## Flujo de Contexto
Cuando Claude recibe un mensaje:
```
1. System Prompt ← instancias.system_prompt
2. Personalidad ← instancias.personalidad
3. Memorias ← memoria WHERE instancia_id = X
ORDER BY importancia DESC LIMIT 20
4. Conocimiento ← conocimiento WHERE instancias_permitidas
IS NULL OR X = ANY(instancias_permitidas)
5. Contexto Ambiental ← contexto_ambiental
ORDER BY capturado_at DESC LIMIT 1
6. Historial ← mensajes_v2 WHERE compactado = FALSE
ORDER BY created_at
7. Resumen ← conversaciones.resumen (mensajes compactados)
```

View File

@@ -0,0 +1,346 @@
# Context Manager v8 - Sistema de Gestión de Contexto para IA
**Versión:** 8.1
**Fecha:** 2026-01-01
**Sistema:** CAPTAIN CLAUDE - TZZR
**Generador:** ARCHITECT
---
## Visión General
El **Context Manager v8** es un sistema completo para la gestión del contexto en sistemas de IA. Proporciona:
1. **Log inmutable** con integridad criptográfica (blockchain-style)
2. **Integración con Sistema de Componentes TZZR** (players, items, locations, hashtags, flags)
3. **Referencias relacionales** a contexto, libros contables y registros de secretaría
4. **Contexto ambiental** dinámico embebido en mensajes
5. **Soporte multiagente** con owner, players y master_player
---
## Arquitectura de Schemas
```
┌─────────────────────────────────────────────────────────────┐
│ CONTEXT MANAGER v8.1 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ SCHEMA: log (Inmutable) │ │
│ │ │ │
│ │ ├── log.messages (mensajes) │ │
│ │ └── log.message_refs (referencias a contexto) │ │
│ │ │ │
│ │ Características: │ │
│ │ ├─ Solo INSERT (UPDATE/DELETE bloqueados) │ │
│ │ ├─ Cadena SHA-256: prev_hash → hash │ │
│ │ └─ Integración con Sistema Componentes TZZR │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ SISTEMA DE COMPONENTES TZZR (Referencias externas) │ │
│ │ │ │
│ │ ├── ply (Players: usuarios, agentes, empresas) │ │
│ │ ├── hst (Hash Semantic Tagging: etiquetas) │ │
│ │ ├── flg (Flags: jurisdicciones, normativas) │ │
│ │ ├── itm (Items: productos, componentes) │ │
│ │ └── loc (Locations: ubicaciones físicas) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ FUENTES DE CONOCIMIENTO (via message_refs) │ │
│ │ │ │
│ │ ├── context → log.messages (historial) │ │
│ │ ├── accountant → libros contables │ │
│ │ └── secretary → registros de secretaría │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
```
---
## Schema LOG (2 tablas)
### 1. `log.messages` - Mensajes
Almacena todos los mensajes del sistema de forma inmutable.
**Características:**
- Solo permite INSERT (triggers previenen UPDATE/DELETE)
- Cadena de integridad: cada mensaje contiene hash del anterior
- Integración completa con Sistema de Componentes TZZR
- Soporte multiagente: owner (emisor), players (receptores), master_player (líder)
**Schema:**
```sql
CREATE TABLE log.messages (
id BIGSERIAL PRIMARY KEY,
hash CHAR(64) UNIQUE NOT NULL, -- SHA-256 del mensaje
session_hash CHAR(64) NOT NULL, -- Sesión
thread_hash CHAR(64), -- Hilo (nullable)
owner_id CHAR(64) NOT NULL, -- Emisor (→ ply)
players_id CHAR(64)[] DEFAULT '{}', -- Receptores (→ ply)
master_player CHAR(64), -- Líder/coordinador (→ ply)
role TEXT, -- Rol del emisor
content TEXT NOT NULL, -- Contenido del mensaje
attachments JSONB DEFAULT '{}', -- Adjuntos
prev_hash CHAR(64), -- Hash mensaje anterior
hashtags CHAR(64)[] DEFAULT '{}', -- Etiquetas (→ hst)
flag_id CHAR(64), -- Jurisdicción (→ flg)
master_item_id CHAR(64), -- Item principal (→ itm)
item_id CHAR(64)[] DEFAULT '{}', -- Items relacionados (→ itm)
loc_id CHAR(64), -- Ubicación (→ loc)
ambient JSONB, -- Contexto ambiental
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
**Índices:**
- `session_hash` - Mensajes de una sesión
- `thread_hash` - Mensajes de un hilo
- `owner_id` - Mensajes enviados por
- `master_player` - Mensajes con líder
- `prev_hash` - Cadena de integridad
- `created_at` - Orden cronológico
- `hashtags` (GIN) - Búsqueda por etiquetas
- `players_id` (GIN) - Búsqueda por receptores
- `item_id` (GIN) - Búsqueda por items
- `flag_id` - Filtrar por jurisdicción
- `loc_id` - Filtrar por ubicación
---
### 2. `log.message_refs` - Referencias
Relaciona cada mensaje con su contexto y fuentes de conocimiento.
**Características:**
- Tabla relacional para evitar arrays largos de hashes
- Tres tipos de referencias: context, accountant, secretary
- Posición para ordenar el contexto
- Inmutable como log.messages
**Schema:**
```sql
CREATE TABLE log.message_refs (
id BIGSERIAL PRIMARY KEY,
message_hash CHAR(64) NOT NULL, -- Mensaje que se envía
ref_hash CHAR(64) NOT NULL, -- Hash de la referencia
ref_type log.ref_type NOT NULL, -- context|accountant|secretary
position INT NOT NULL, -- Orden de la referencia
thread_hash CHAR(64), -- Hilo (nullable)
UNIQUE(message_hash, ref_hash)
);
```
**Tipos de referencia:**
| Tipo | Descripción |
|------|-------------|
| `context` | Mensajes anteriores incluidos como contexto |
| `accountant` | Registros de libros contables (conocimiento financiero) |
| `secretary` | Registros de secretaría (conocimiento general) |
---
## Integración con Sistema de Componentes TZZR
El Context Manager referencia las tablas del Sistema de Componentes:
| Campo log.messages | Tabla TZZR | Descripción |
|-------------------|------------|-------------|
| `owner_id` | ply | Emisor del mensaje (usuario o agente) |
| `players_id[]` | ply | Receptores del mensaje |
| `master_player` | ply | Coordinador en sistemas multiagente |
| `hashtags[]` | hst | Etiquetas semánticas del mensaje |
| `flag_id` | flg | Jurisdicción o normativa aplicable |
| `master_item_id` | itm | Item principal relacionado |
| `item_id[]` | itm | Items adicionales relacionados |
| `loc_id` | loc | Ubicación física del contexto |
### Tablas del Sistema de Componentes
```
PLY (Players)
├── ply - Sistema (empresas, entidades oficiales)
├── plu - Usuario (contactos personales)
└── plx - Compartidos
HST (Hash Semantic Tagging)
├── hst - Tags del sistema (658)
├── spe - Especificaciones técnicas (145)
├── vsn - Visiones/escenas (84)
├── vue - Valores humanos (21)
└── hsu - Tags de usuario
FLG (Flags/Jurisdicciones)
├── flg - Sistema (65 países/normativas)
└── flu - Usuario
ITM (Items)
├── itm - Sistema
├── itu - Usuario
└── itx - Compartidos
LOC (Locations)
├── loc - Sistema
├── lou - Usuario
└── lox - Compartidos
```
---
## Cadena de Integridad
Cada mensaje incluye el hash del anterior, formando una cadena verificable:
```
msg1.hash = SHA256(msg1_data)
msg2.prev_hash = msg1.hash
msg2.hash = SHA256(msg2_data)
msg3.prev_hash = msg2.hash
...
```
**Primer mensaje de sesión:** `prev_hash = NULL`
**Función de hash:**
```sql
CREATE FUNCTION log.sha256(data TEXT) RETURNS CHAR(64) AS $$
BEGIN
RETURN encode(digest(data, 'sha256'), 'hex');
END;
$$ LANGUAGE plpgsql IMMUTABLE;
```
---
## Protección de Inmutabilidad
Triggers que previenen modificación:
```sql
-- Bloquear UPDATE
CREATE TRIGGER protect_messages_update
BEFORE UPDATE ON log.messages
FOR EACH ROW EXECUTE FUNCTION log.prevent_update();
-- Bloquear DELETE
CREATE TRIGGER protect_messages_delete
BEFORE DELETE ON log.messages
FOR EACH ROW EXECUTE FUNCTION log.prevent_delete();
-- Igual para message_refs
```
---
## Contexto Ambiental (ambient)
Campo JSONB para capturar estado del sistema en el momento del mensaje:
```json
{
"timezone": "Europe/Madrid",
"locale": "es-ES",
"working_directory": "/home/architect/project",
"git_branch": "main",
"active_services": ["gitea", "postgresql"],
"server": "ARCHITECT",
"timestamp_utc": "2026-01-01T12:00:00Z"
}
```
Solo se incluye cuando es relevante (nullable en la mayoría de mensajes).
---
## Despliegue
**Servidores activos:**
| Servidor | IP | Base de Datos | Estado |
|----------|-----|---------------|--------|
| ARCHITECT | 69.62.126.110 | architect | ✅ Activo |
| DECK | 72.62.1.113 | tzzr | ✅ Activo |
| CORP | 92.112.181.188 | tzzr | ✅ Activo |
**Extensiones requeridas:**
- `pgcrypto` - Para función SHA-256
- `pgvector` - Para embeddings (opcional, instalado)
**Comando de aplicación:**
```bash
sudo -u postgres psql -d [database] -c "$(curl -s http://localhost:3000/admin/context-manager/raw/branch/main/schemas/04_log.sql)"
```
---
## Flujo de Trabajo
### 1. Insertar mensaje
```sql
INSERT INTO log.messages (
hash, session_hash, owner_id, players_id,
content, prev_hash, hashtags, created_at
) VALUES (
log.sha256(...), 'session_abc...', 'owner_hash...',
ARRAY['player1_hash...', 'player2_hash...'],
'Contenido del mensaje', 'prev_msg_hash...',
ARRAY['tag1_hash...'], NOW()
);
```
### 2. Añadir referencias de contexto
```sql
INSERT INTO log.message_refs (
message_hash, ref_hash, ref_type, position, thread_hash
) VALUES
('msg_hash...', 'context_msg_1...', 'context', 1, 'thread...'),
('msg_hash...', 'context_msg_2...', 'context', 2, 'thread...'),
('msg_hash...', 'accountant_record...', 'accountant', 3, 'thread...');
```
### 3. Consultar mensajes con contexto
```sql
SELECT
m.content,
m.owner_id,
array_agg(r.ref_hash ORDER BY r.position) as context_refs
FROM log.messages m
LEFT JOIN log.message_refs r ON m.hash = r.message_hash
WHERE m.session_hash = 'session_abc...'
GROUP BY m.id, m.content, m.owner_id
ORDER BY m.created_at;
```
---
## Ubicación de Documentación
| Ubicación | Ruta |
|-----------|------|
| Gitea | http://localhost:3000/admin/context-manager |
| R2 | s3://architect/system/context-manager/ |
| Skynet v8 | s3://architect/system/skynet v8/03_MODELO_DATOS/ |
---
## Historial de Cambios
| Versión | Fecha | Cambios |
|---------|-------|---------|
| 8.0 | 2025-12-30 | Versión inicial con 9 tablas |
| 8.1 | 2026-01-01 | Simplificación a 2 tablas (log.messages, log.message_refs). Integración con Sistema de Componentes TZZR. Nuevos campos: owner_id, players_id, master_player, flag_id, master_item_id, item_id, loc_id |
---
**Documento generado por:** ARCHITECT
**Timestamp:** 2026-01-01
**Versión:** Context Manager v8.1

View File

@@ -0,0 +1,139 @@
# Entidades
**Versión:** 1.0
**Estado:** Definición
---
## Visión General
Las entidades base son los bloques fundamentales del sistema. Cada una tiene un hash único SHA-256 que la identifica de forma unívoca.
```
DEFINICIÓN ORIGINAL → SHA-256 → h_{tipo} (64 chars)
```
---
## Entidades del Sistema
| Entidad | Hash | Descripción | Estado |
|---------|------|-------------|--------|
| **HST** | h_maestro | Tags semánticos | Implementado |
| **ITM** | h_item | Plano ideal | Planificado |
| **PLY** | h_player | Identidad | Planificado |
| **LOC** | h_loc | Ubicaciones | Planificado |
| **FLG** | h_flag | Marcos jurídicos | Planificado |
---
## HST (Hash Semantic Tagging)
Sistema de etiquetas semánticas visuales.
### Fórmula
```
h_maestro = SHA-256(grupo:ref)
```
### Grupos
| Grupo | Cantidad |
|-------|----------|
| hst | 639 |
| spe | 145 |
| vsn | 84 |
| flg | 65 |
| vue | 21 |
---
## ITM (Items)
Plano ideal - definiciones abstractas.
### Tipos
| Tipo | Descripción |
|------|-------------|
| accion_ideal | Acción que debería ejecutarse |
| objetivo | Meta a alcanzar |
| requerimiento | Requisito a cumplir |
---
## PLY (Players)
Identidad de actores en el sistema.
### Tipos
| Tipo | Descripción |
|------|-------------|
| persona | Usuario individual |
| empresa | Organización |
| agente | Sistema automatizado |
---
## LOC (Locations)
Ubicaciones geográficas.
### Tipos
| Tipo | Descripción |
|------|-------------|
| punto | Coordenadas exactas |
| area | Zona delimitada |
| ruta | Trayecto |
---
## FLG (Flags)
Marcos jurídicos y normativas.
### Uso
- Países
- Normativas (RGPD, SOX, ISO)
- Jurisdicciones
---
## Relaciones Entre Entidades
```
ITM (ideal)
├──► h_maestro (HST tags)
├──► h_player (PLY responsable)
├──► h_loc (LOC ubicación)
└──► h_flag (FLG normativa)
MST (milestone)
├──► item_asociado (ITM)
└──► h_maestro (HST tags)
BCK (bloque)
├──► item_asociado (ITM)
├──► milestone_asociado (MST)
└──► h_maestro (HST tags)
```
---
## Extensiones de Usuario
| Tabla | Descripción |
|-------|-------------|
| hsu | HST Usuario |
| spu | SPE Usuario |
| vsu | VSN Usuario |
| vuu | VUE Usuario |
| pju | Proyectos Usuario |
| flu | FLG Usuario |

188
03_MODELO_DATOS/flujos.md Normal file
View File

@@ -0,0 +1,188 @@
# Flujos
**Versión:** 1.0
**Estado:** Definición
---
## Visión General
El sistema tiene tres flujos principales según la naturaleza de la información entrante.
---
## Flujo Estándar (entrada manual)
**Condición:** La información no encaja (entrada manual, incidencia, improvisación). Requiere enriquecimiento o validación manual.
```
Secretaría (Clara/Margaret)
│ registro inmutable
Administración (Mason)
│ enriquecimiento (24h)
Contable (Feldman)
│ consolidación
Inmutable
```
---
## Flujo de Producción (procesos predefinidos)
**Condición:** La información encaja (viene de Producción, proceso predefinido completo). La información ya está completa y estructurada.
```
Producción (Alfred/Jared)
│ flujo predefinido
Secretaría (Clara/Margaret)
│ registro inmutable
Contable (Feldman)
│ consolidación directa
Inmutable
```
**Nota:** Este flujo salta Administración porque no hay nada que enriquecer.
---
## Flujo con Incidencia
**Condición:** Durante un flujo de producción, el usuario improvisa o se produce un cambio.
**Comportamiento:** La improvisación marca el punto de quiebre. Todo lo anterior registrado se mantiene, pero lo que viene después requiere el paso por Administración.
```
Producción (Alfred/Jared)
│ flujo predefinido
Secretaría (Clara/Margaret)
│ ⚠️ incidencia detectada
Administración (Mason)
│ enriquecimiento
Contable (Feldman)
```
---
## Regla de Decisión
| Condición | Flujo |
|-----------|-------|
| **Encaja** | Secretaría → Feldman |
| **No encaja** | Secretaría → Mason → Feldman |
---
## Diagrama de Decisión
```
┌─────────────────┐
│ Entrada │
└────────┬────────┘
┌────────▼────────┐
│ ¿Viene de │
│ Producción? │
└────────┬────────┘
┌────────┴────────┐
│ │
SÍ NO
│ │
┌────────▼────────┐ │
│ ¿Encaja │ │
│ completo? │ │
└────────┬────────┘ │
│ │
┌────────┴────────┐ │
│ │ │
SÍ NO │
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────────────┐
│ Directo │ │ Mason │
│ Feldman │ │ (enriquecer) │
└──────────┘ └──────────────────┘
```
---
## Mecanismo de "Encaja"
**Pendiente de definir:** Sistema de hashes que determina automáticamente si la información encaja con un flujo predefinido.
Concepto propuesto:
```python
def encaja(entrada, flujo_esperado):
# Comparar estructura de datos
# Verificar campos requeridos
# Validar tipos
return estructura_coincide and campos_completos
```
---
## Estados del Flujo
| Estado | Ubicación | Descripción |
|--------|-----------|-------------|
| **recibido** | Secretaría | Entrada registrada |
| **en_edicion** | Mason | Usuario enriqueciendo |
| **listo** | Mason | Preparado para Feldman |
| **pendiente** | Feldman cola | En espera de consolidación |
| **consolidado** | Feldman bloques | Registro final inmutable |
---
## Estructura de Feldman
Feldman tiene **dos tablas internas**:
```
┌─────────────────────────────────────────────────────────────────┐
│ FELDMAN │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ COLA (24h configurable) │ │
│ │ • Registros esperando consolidación │ │
│ │ • Usuario puede: DEVOLVER a Mason │ │
│ │ • Si expira → pasa a BLOQUE │ │
│ └─────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ BLOQUES INMUTABLES │ │
│ │ GÉNESIS ─▶ BLOQUE 1 ─▶ BLOQUE 2 ─▶ ... │ │
│ │ (hash anterior, merkle root, timestamp) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Ventanas Temporales
| Etapa | Default | Configurable | Descripción |
|-------|---------|--------------|-------------|
| Mason | 24h | ✓ | Tiempo para enriquecer antes de auto-envío |
| Feldman cola | 24h | ✓ | Tiempo en cola antes de cerrar en bloque |

134
03_MODELO_DATOS/hashes.md Normal file
View File

@@ -0,0 +1,134 @@
# Hashes e Identificadores
**Versión:** 1.0
**Estado:** Definición
---
## Visión General
El sistema usa SHA-256 para identificación única e inmutable de todos los elementos.
```
CONTENIDO → SHA-256 → 64 caracteres hexadecimales
```
---
## Tipos de Hash
| Prefijo | Tipo | Descripción |
|---------|------|-------------|
| **h_maestro** | Tag HST | Hash de etiqueta semántica |
| **h_instancia** | Contexto | Identidad del servidor/instancia |
| **h_entrada** | Contenedor | Hash de ingesta en secretaría |
| **h_bloque** | BCK | Hash de bloque consolidado |
| **h_milestone** | MST | Hash de milestone |
| **h_item** | ITM | Hash de ítem (plano ideal) |
| **h_player** | PLY | Hash de identidad |
| **h_loc** | LOC | Hash de ubicación |
| **h_flag** | FLG | Hash de marco jurídico |
---
## Fórmulas
### h_maestro (HST)
```
h_maestro = SHA-256(grupo:ref)
Ejemplo:
h_maestro = SHA-256("hst:person")
```
### h_entrada (Secretaría)
```
h_entrada = SHA-256(timestamp:origen:contenido)
```
### h_bloque (BCK)
```
h_bloque = SHA-256(h_instancia:secuencia:hash_previo:hash_contenido)
hash_contenido = SHA-256(contenido_serializado)
```
### h_milestone (MST)
```
h_milestone = SHA-256(h_instancia:secuencia:tipo:contenido)
```
### h_item (ITM)
```
h_item = SHA-256(h_instancia:secuencia:tipo:contenido)
```
### h_loc (LOC)
```
h_loc = SHA-256(lat:lon:precision)
```
---
## Encadenamiento
```
Bloque 1 Bloque 2 Bloque 3
┌────────────┐ ┌────────────┐ ┌────────────┐
│h_bloque: A │──────►│hash_prev: A│──────►│hash_prev: B│
│ │ │h_bloque: B │ │h_bloque: C │
└────────────┘ └────────────┘ └────────────┘
```
---
## Verificación
### Integridad de Contenido
```python
import hashlib
import json
def verificar_integridad(bloque):
contenido_serializado = json.dumps(bloque['contenido'], sort_keys=True)
hash_calculado = hashlib.sha256(contenido_serializado.encode()).hexdigest()
return hash_calculado == bloque['hash_contenido']
```
### Encadenamiento
```python
def verificar_cadena(bloque, bloque_previo):
return bloque['hash_previo'] == bloque_previo['h_bloque']
```
---
## Propiedades
| Propiedad | Descripción |
|-----------|-------------|
| **Determinista** | Mismo input → mismo hash |
| **Único** | Colisión prácticamente imposible |
| **Irreversible** | No se puede obtener contenido desde hash |
| **Fijo** | Siempre 64 caracteres |
---
## Uso en Trazabilidad
```
Bloque (Feldman)
└── h_entrada ──► Contenedor (Secretaría)
└── archivos_hashes ──► R2 Storage
```
Cualquier registro final puede rastrearse hasta su origen.

View File

@@ -0,0 +1,588 @@
# Estandar HST Contract (CCT)
**Version:** 1.0
**Estado:** Especificacion
**Fecha:** 2026-01-01
---
## Vision General
El estandar HST Contract (CCT) es un modelo de datos semantico para la gestion integral de contratos. Sigue la arquitectura de 6 capas (L1-L6) compatible con el estandar INV, proporcionando un marco completo para la gestion del ciclo de vida contractual.
### Caracteristicas Principales
- **~280 campos totales** distribuidos en 6 capas
- **18 tipos de contrato** para cubrir escenarios empresariales
- **22 roles de partes** para identificar participantes
- **14 estados de ciclo de vida** para trazabilidad completa
- **37 tipos de clausulas** estandarizadas
- **Compatibilidad eIDAS** para firmas electronicas europeas
- **Soporte Smart Contracts** para blockchain
- **Auditoria completa** con hash inmutables
---
## Arquitectura de 6 Capas (L1-L6)
### L1 - Identificacion Base
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| h_contract | VARCHAR(64) | Hash SHA-256 unico del contrato |
| contract_id | UUID | Identificador interno |
| external_ref | VARCHAR(100) | Referencia externa del cliente |
| contract_number | VARCHAR(50) | Numero de contrato |
| version | INTEGER | Version del contrato |
| parent_contract | UUID | Contrato padre (para enmiendas) |
| created_at | TIMESTAMPTZ | Fecha de creacion |
| created_by | UUID | Usuario creador |
### L2 - Clasificacion
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| contract_type | ENUM | Tipo de contrato (ver catalogo) |
| contract_subtype | VARCHAR(50) | Subtipo especifico |
| category | VARCHAR(50) | Categoria de negocio |
| department | VARCHAR(100) | Departamento responsable |
| cost_center | VARCHAR(50) | Centro de coste |
| business_unit | VARCHAR(100) | Unidad de negocio |
| project_code | VARCHAR(50) | Codigo de proyecto asociado |
| h_maestro_tags | JSONB | Tags HST asociados |
### L3 - Partes y Roles
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| parties | JSONB | Array de partes involucradas |
| party_id | UUID | Identificador de la parte |
| party_role | ENUM | Rol de la parte (ver catalogo) |
| party_type | ENUM | Tipo: person, company, government |
| legal_name | VARCHAR(255) | Nombre legal completo |
| tax_id | VARCHAR(50) | NIF/CIF/VAT |
| address | JSONB | Direccion estructurada |
| contact_person | VARCHAR(255) | Persona de contacto |
| contact_email | VARCHAR(255) | Email de contacto |
| signatory | BOOLEAN | Es firmante autorizado |
| signatory_power | TEXT | Poder de representacion |
### L4 - Terminos Contractuales
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| effective_date | DATE | Fecha de inicio de vigencia |
| expiration_date | DATE | Fecha de finalizacion |
| duration_months | INTEGER | Duracion en meses |
| auto_renewal | BOOLEAN | Renovacion automatica |
| renewal_period | INTERVAL | Periodo de renovacion |
| notice_period_days | INTEGER | Dias de preaviso |
| termination_terms | TEXT | Condiciones de terminacion |
| governing_law | VARCHAR(100) | Ley aplicable |
| jurisdiction | VARCHAR(100) | Jurisdiccion |
| dispute_resolution | ENUM | Metodo de resolucion |
| arbitration_rules | VARCHAR(100) | Reglas de arbitraje |
| language | VARCHAR(10) | Idioma del contrato |
| currency | VARCHAR(3) | Moneda principal |
### L5 - Condiciones Economicas
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| total_value | NUMERIC(18,4) | Valor total del contrato |
| annual_value | NUMERIC(18,4) | Valor anualizado |
| payment_terms | JSONB | Terminos de pago |
| payment_schedule | JSONB | Calendario de pagos |
| penalty_clauses | JSONB | Clausulas de penalizacion |
| price_adjustment | JSONB | Mecanismos de ajuste de precio |
| tax_treatment | JSONB | Tratamiento fiscal |
| billing_address | JSONB | Direccion de facturacion |
| bank_details | JSONB | Datos bancarios (encriptados) |
| insurance_requirements | JSONB | Requisitos de seguro |
| performance_bond | JSONB | Garantias de cumplimiento |
### L6 - Metadatos y Auditoria
| Campo | Tipo | Descripcion |
|-------|------|-------------|
| status | ENUM | Estado del ciclo de vida |
| workflow_stage | VARCHAR(50) | Etapa del workflow |
| approval_chain | JSONB | Cadena de aprobacion |
| signatures | JSONB | Firmas (eIDAS compatible) |
| documents | JSONB | Documentos adjuntos |
| amendments | JSONB | Historial de enmiendas |
| notes | JSONB | Notas internas |
| tags | JSONB | Etiquetas adicionales |
| metadata | JSONB | Metadatos extensibles |
| blockchain_ref | VARCHAR(100) | Referencia blockchain |
| smart_contract_address | VARCHAR(100) | Direccion smart contract |
| audit_log | JSONB | Log de auditoria |
| h_entrada | VARCHAR(64) | Hash de entrada |
| h_instancia | VARCHAR(64) | Hash de instancia |
| last_modified_at | TIMESTAMPTZ | Ultima modificacion |
| last_modified_by | UUID | Usuario que modifico |
---
## Catalogo de Tipos de Contrato (18)
| Codigo | Nombre | Descripcion |
|--------|--------|-------------|
| COM | Commercial | Contrato de compraventa comercial |
| SVC | Service | Prestacion de servicios |
| EMP | Employment | Contrato laboral |
| LIC | License | Licencia de software/IP |
| NDA | Non-Disclosure | Acuerdo de confidencialidad |
| JVA | Joint Venture | Empresa conjunta |
| LEA | Lease | Arrendamiento/alquiler |
| LOA | Loan | Prestamo |
| INS | Insurance | Seguro |
| CON | Consulting | Consultoria |
| AGY | Agency | Agencia/representacion |
| FRA | Franchise | Franquicia |
| SLA | Service Level | Acuerdo de nivel de servicio |
| MNT | Maintenance | Mantenimiento |
| SUB | Subscription | Suscripcion |
| PAR | Partnership | Sociedad/colaboracion |
| SET | Settlement | Acuerdo transaccional |
| AMD | Amendment | Enmienda/modificacion |
---
## Catalogo de Roles de Partes (22)
| Codigo | Rol | Descripcion |
|--------|-----|-------------|
| BUYER | Comprador | Parte que adquiere |
| SELLER | Vendedor | Parte que provee |
| LICENSOR | Licenciante | Otorga la licencia |
| LICENSEE | Licenciatario | Recibe la licencia |
| LESSOR | Arrendador | Propietario del bien |
| LESSEE | Arrendatario | Usuario del bien |
| EMPLOYER | Empleador | Contratante laboral |
| EMPLOYEE | Empleado | Trabajador |
| LENDER | Prestamista | Otorga el prestamo |
| BORROWER | Prestatario | Recibe el prestamo |
| INSURER | Asegurador | Compania de seguros |
| INSURED | Asegurado | Beneficiario del seguro |
| FRANCHISOR | Franquiciador | Dueno de la marca |
| FRANCHISEE | Franquiciado | Operador local |
| PRINCIPAL | Principal | Representado |
| AGENT | Agente | Representante |
| GUARANTOR | Garante | Proporciona garantia |
| BENEFICIARY | Beneficiario | Recibe el beneficio |
| CONSULTANT | Consultor | Proveedor de asesoria |
| CLIENT | Cliente | Receptor de asesoria |
| PARTNER | Socio | Miembro de sociedad |
| WITNESS | Testigo | Testigo de la firma |
---
## Estados del Ciclo de Vida (14)
| Codigo | Estado | Descripcion | Transiciones Validas |
|--------|--------|-------------|---------------------|
| DRAFT | Borrador | En redaccion | REVIEW, CANCELLED |
| REVIEW | En Revision | Pendiente de revision | DRAFT, NEGOTIATION, CANCELLED |
| NEGOTIATION | Negociacion | En proceso de negociacion | REVIEW, PENDING_APPROVAL, CANCELLED |
| PENDING_APPROVAL | Pendiente Aprobacion | Esperando aprobacion | NEGOTIATION, APPROVED, REJECTED |
| APPROVED | Aprobado | Aprobado internamente | PENDING_SIGNATURE |
| REJECTED | Rechazado | Rechazado (final) | DRAFT |
| PENDING_SIGNATURE | Pendiente Firma | Esperando firmas | APPROVED, SIGNED, CANCELLED |
| SIGNED | Firmado | Todas las firmas completadas | ACTIVE |
| ACTIVE | Activo | En vigor | SUSPENDED, TERMINATED, EXPIRED, RENEWED |
| SUSPENDED | Suspendido | Temporalmente inactivo | ACTIVE, TERMINATED |
| TERMINATED | Terminado | Terminacion anticipada | - |
| EXPIRED | Expirado | Vencido naturalmente | RENEWED |
| RENEWED | Renovado | Renovado (nuevo periodo) | ACTIVE |
| CANCELLED | Cancelado | Cancelado antes de firma | - |
---
## Catalogo de Clausulas (37)
### Clausulas Generales
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| DEF | Definiciones | Terminos y definiciones |
| OBJ | Objeto | Proposito del contrato |
| SCO | Alcance | Ambito de aplicacion |
| DUR | Duracion | Vigencia temporal |
| PRI | Precio | Condiciones economicas |
| PAY | Pago | Terminos de pago |
| DEL | Entrega | Condiciones de entrega |
| WAR | Garantia | Garantias ofrecidas |
### Clausulas de Responsabilidad
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| LIM | Limitacion Responsabilidad | Limites de responsabilidad |
| IND | Indemnizacion | Obligaciones de indemnizar |
| INS | Seguro | Requisitos de seguro |
| FOR | Fuerza Mayor | Eventos extraordinarios |
### Clausulas de Propiedad Intelectual
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| IPR | Propiedad Intelectual | Derechos de PI |
| LIC | Licencia | Terminos de licencia |
| CON | Confidencialidad | Obligaciones de secreto |
| NDA | No Divulgacion | Restricciones de divulgacion |
| NCA | No Competencia | Restricciones de competencia |
### Clausulas de Terminacion
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| TER | Terminacion | Causas de terminacion |
| NOT | Notificacion | Requisitos de preaviso |
| PEN | Penalizacion | Penalizaciones por incumplimiento |
| TRA | Transicion | Obligaciones de transicion |
### Clausulas de Cumplimiento
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| COM | Cumplimiento | Obligaciones de compliance |
| AUD | Auditoria | Derechos de auditoria |
| REP | Reportes | Obligaciones de informar |
| REC | Registros | Mantenimiento de registros |
### Clausulas de Datos
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| DPA | Procesamiento Datos | Acuerdo de procesamiento |
| GDP | RGPD | Cumplimiento RGPD |
| SEC | Seguridad | Medidas de seguridad |
| BRE | Brecha | Notificacion de brechas |
| RET | Retencion | Periodo de retencion |
| DEL | Eliminacion | Destruccion de datos |
### Clausulas de Resolucion
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| GOV | Ley Aplicable | Jurisdiccion legal |
| JUR | Jurisdiccion | Tribunales competentes |
| ARB | Arbitraje | Clausula arbitral |
| MED | Mediacion | Procedimiento de mediacion |
### Clausulas Especiales
| Codigo | Clausula | Descripcion |
|--------|----------|-------------|
| ASS | Cesion | Transferencia de derechos |
| SUB | Subcontratacion | Autorizacion de subcontratistas |
| ENT | Integracion | Acuerdo completo |
| MOD | Modificacion | Procedimiento de enmienda |
| WAI | Renuncia | No renuncia de derechos |
---
## Compatibilidad eIDAS
El estandar CCT es compatible con el Reglamento eIDAS (910/2014) para firmas electronicas.
### Niveles de Firma Soportados
| Nivel | Tipo | Valor Legal |
|-------|------|-------------|
| SES | Simple Electronic Signature | Basico |
| AES | Advanced Electronic Signature | Presuncion de validez |
| QES | Qualified Electronic Signature | Equivalente a firma manuscrita |
### Estructura de Firma eIDAS
```json
{
"signature_id": "uuid",
"signer_id": "uuid",
"signature_level": "QES",
"timestamp": "2026-01-01T12:00:00Z",
"certificate": {
"issuer": "Qualified Trust Service Provider",
"serial": "...",
"validity": {...}
},
"signature_value": "base64...",
"document_hash": "sha256:...",
"seal": {
"timestamp_authority": "...",
"timestamp_token": "..."
}
}
```
### Proveedores QES Soportados
- **Espana:** FNMT, Camerfirma, AC Firmaprofesional
- **Alemania:** D-Trust, Bundesdruckerei
- **Francia:** Certinomis, ChamberSign
- **Italia:** Aruba PEC, InfoCert
---
## Integracion Blockchain / Smart Contracts
### Casos de Uso
| Caso | Descripcion | Beneficio |
|------|-------------|----------|
| Notarizacion | Hash del contrato en blockchain | Prueba de existencia |
| Pagos automaticos | Smart contract para milestones | Automatizacion |
| Escrow | Fondos en custodia automatica | Seguridad |
| Vesting | Liberacion programada de activos | Transparencia |
| Multi-firma | Aprobacion descentralizada | Gobernanza |
### Estructura Smart Contract
```json
{
"blockchain_network": "ethereum|polygon|arbitrum",
"contract_address": "0x...",
"deployment_tx": "0x...",
"abi_hash": "sha256:...",
"state_hash": "sha256:...",
"last_update_block": 12345678,
"oracle_sources": [],
"events": []
}
```
### Redes Soportadas
| Red | Tipo | Uso Recomendado |
|-----|------|-----------------|
| Ethereum | Mainnet | Contratos de alto valor |
| Polygon | L2 | Operaciones frecuentes |
| Arbitrum | L2 | DeFi integrado |
| Hyperledger | Permissioned | Enterprise privado |
---
## Hashes e Inmutabilidad
### Cadena de Hashes
```
h_contract = SHA-256(contract_core_data)
|
+-- h_entrada = SHA-256(modification_data)
| |
| +-- h_instancia = SHA-256(snapshot_data)
|
+-- h_bloque = SHA-256(consolidated_block)
```
### Formula de Hash
```python
h_contract = sha256(
contract_type + "|" +
parties_hash + "|" +
effective_date + "|" +
total_value + "|" +
created_at
)
```
### Verificacion de Integridad
```sql
SELECT
contract_id,
h_contract,
sha256(
contract_type || \x27|\x27 ||
parties_hash || \x27|\x27 ||
effective_date || \x27|\x27 ||
total_value || \x27|\x27 ||
created_at
) as computed_hash,
CASE
WHEN h_contract = computed_hash THEN \x27VALID\x27
ELSE \x27TAMPERED\x27
END as integrity_status
FROM contracts;
```
---
## Relaciones con Otras Entidades
### Diagrama de Relaciones
```
CONTRACT (CCT)
|
+---> HST (h_maestro tags)
| - Etiquetas semanticas del contrato
| - Clasificacion automatica
|
+---> PLY (Players/Partes)
| - Identificacion de partes
| - Roles y capacidades
|
+---> LOC (Locations)
| - Lugar de ejecucion
| - Direcciones de las partes
|
+---> FLG (Flags/Normativas)
| - Ley aplicable
| - Jurisdiccion
| - Compliance requerido
|
+---> DOC (Documentos)
| - Anexos
| - Versiones
|
+---> WFL (Workflows)
- Proceso de aprobacion
- Notificaciones
```
### Integracion con Feldman
Los contratos CCT se consolidan en Feldman como parte del registro consolidado:
```json
{
"entity_type": "CONTRACT",
"entity_id": "h_contract",
"consolidated_data": {...},
"validation_status": "VERIFIED",
"blockchain_proof": "0x..."
}
```
---
## Ejemplos de Uso
### Ejemplo 1: Contrato de Servicios (SVC)
```json
{
"h_contract": "sha256:a1b2c3...",
"contract_type": "SVC",
"parties": [
{
"party_role": "CLIENT",
"legal_name": "Empresa ABC S.L.",
"tax_id": "B12345678"
},
{
"party_role": "SELLER",
"legal_name": "Consultora XYZ S.A.",
"tax_id": "A87654321"
}
],
"effective_date": "2026-01-15",
"expiration_date": "2027-01-14",
"total_value": 120000.00,
"currency": "EUR",
"status": "ACTIVE",
"clauses": ["DEF", "OBJ", "SCO", "PRI", "PAY", "CON", "TER", "GOV"]
}
```
### Ejemplo 2: NDA (NDA)
```json
{
"h_contract": "sha256:d4e5f6...",
"contract_type": "NDA",
"parties": [
{
"party_role": "PRINCIPAL",
"legal_name": "Tech Corp"
},
{
"party_role": "AGENT",
"legal_name": "Partner Inc"
}
],
"effective_date": "2026-01-01",
"duration_months": 24,
"clauses": ["DEF", "OBJ", "CON", "NDA", "TER", "PEN", "GOV", "ARB"]
}
```
---
## Validaciones y Reglas de Negocio
### Validaciones Obligatorias
| Regla | Descripcion |
|-------|-------------|
| V001 | contract_type debe ser uno de los 18 valores validos |
| V002 | Al menos 2 partes deben estar definidas |
| V003 | effective_date no puede ser futuro si status = ACTIVE |
| V004 | expiration_date > effective_date |
| V005 | total_value >= 0 |
| V006 | Todas las firmas requeridas antes de SIGNED |
| V007 | governing_law obligatorio para contratos internacionales |
### Reglas de Transicion de Estado
```
DRAFT -> [REVIEW, CANCELLED]
REVIEW -> [DRAFT, NEGOTIATION, CANCELLED]
NEGOTIATION -> [REVIEW, PENDING_APPROVAL, CANCELLED]
PENDING_APPROVAL -> [NEGOTIATION, APPROVED, REJECTED]
APPROVED -> [PENDING_SIGNATURE]
REJECTED -> [DRAFT]
PENDING_SIGNATURE -> [APPROVED, SIGNED, CANCELLED]
SIGNED -> [ACTIVE]
ACTIVE -> [SUSPENDED, TERMINATED, EXPIRED, RENEWED]
SUSPENDED -> [ACTIVE, TERMINATED]
EXPIRED -> [RENEWED]
RENEWED -> [ACTIVE]
```
---
## APIs Recomendadas
### Endpoints REST
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /contracts | Crear contrato |
| GET | /contracts/{id} | Obtener contrato |
| PUT | /contracts/{id} | Actualizar contrato |
| DELETE | /contracts/{id} | Eliminar borrador |
| POST | /contracts/{id}/sign | Firmar contrato |
| POST | /contracts/{id}/approve | Aprobar contrato |
| GET | /contracts/{id}/history | Historial de cambios |
| POST | /contracts/{id}/verify | Verificar integridad |
### Webhooks
| Evento | Descripcion |
|--------|-------------|
| contract.created | Nuevo contrato creado |
| contract.updated | Contrato modificado |
| contract.signed | Firma completada |
| contract.activated | Contrato en vigor |
| contract.expiring | Proximo a vencer (30 dias) |
| contract.expired | Contrato vencido |
| contract.terminated | Contrato terminado |
---
## Referencias
- [Entidades Base](entidades.md) - Definicion de HST, ITM, PLY, LOC, FLG
- [Hashes](hashes.md) - Sistema de hashes del sistema
- [Flujos](flujos.md) - Flujos de trabajo estandar
- [Reglamento eIDAS](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32014R0910) - Regulacion europea de firmas electronicas
---
*Documento generado como parte del sistema TZZR - HST Contract Standard*

View File

@@ -0,0 +1,112 @@
# Schemas de Ejecución HST
**Versión:** 1.1
**Fecha:** Enero 2026
## Pilares de Definición de Producto/Proyecto
| Pilar | Pregunta | Tag | Descripción |
|-------|----------|-----|-------------|
| QUÉ | ¿Qué necesito? | bom | Bill of Materials - Lista de materiales |
| CÓMO | ¿Cómo lo hago? | pss, sqc, tre | Proceso → Secuencia → Árbol |
| CUÁNDO | ¿Cuándo? | gnt | Gantt - Planificación temporal |
| COSTE | ¿Cuánto cuesta? | ctl | Lista de Costes (BOM + Procesos) |
| CONTROL | ¿Cumple? | qfm | Formulario de Calidad |
## Jerarquía de Procesos
```
pss (proceso) → Átomo: 1 operación con tiempos y recursos
sqc (secuencia) → Routing: lista ordenada de pss
tre (árbol) → Process Tree: jerarquía con dependencias
gnt (gantt) → Timeline: planificación temporal
```
## Tags Definidos
| Tag | Nombre | Campos | Estándares | Estado |
|-----|--------|--------|------------|--------|
| pss | Proceso | ~45 | - | ✅ Definido |
| sqc | Secuencia / Routing | ~55 | - | ✅ Definido |
| tre | Árbol de Procesos | ~70 | WBS, ISA-95, ISA-88 | ✅ Definido |
| gnt | Gantt | ~85 | CPM, PERT, PMBOK, EVM | ✅ Definido |
| ctl | Lista de Costes | ~65 | - | ✅ Definido |
| bom | Bill of Materials | ~85 | - | ✅ Definido |
| qfm | Formulario de Calidad | ~95 | ISO 9001, IATF 16949, AS9100, AS9102, ANSI Z1.4, SPC, MSA | ✅ Definido |
| mor | Orden Fabricación | - | - | ⏳ Pendiente |
## Árbol de Procesos (tre)
Basado en estándares industriales:
- **WBS (PMBOK)**: Regla del 100%, descomposición jerárquica
- **ISA-95**: Jerarquía de 5 niveles (Enterprise → Unit)
- **ISA-88**: Modelo procedural (Procedure → Phase)
**Tipos de nodo:**
- `phase` - Fase principal
- `subprocess` - Subproceso
- `routing_ref` - Referencia a sqc
- `process_ref` - Referencia a pss
- `milestone` - Hito
- `gate` - Punto de decisión
## Gantt (gnt)
Basado en estándares de planificación:
- **CPM**: Camino crítico, forward/backward pass
- **PERT**: Duración probabilística (O+4M+P)/6
- **PMBOK**: WBS, baselines, varianzas
- **ANSI/EIA-748**: Earned Value Management
**Métricas EVM:**
- PV (Planned Value), EV (Earned Value), AC (Actual Cost)
- SV (Schedule Variance), CV (Cost Variance)
- SPI (Schedule Performance Index), CPI (Cost Performance Index)
- EAC, ETC, VAC (Forecasts)
## Control de Calidad (qfm)
Basado en estándares de gestión de calidad:
- **ISO 9001**: Sistema de gestión de calidad
- **IATF 16949**: Requisitos automotriz
- **AS9100/AS9102**: Requisitos aeroespacial (FAI)
- **ANSI Z1.4**: Planes de muestreo por atributos
- **SPC**: Control estadístico de procesos
- **MSA**: Análisis del sistema de medición
**Niveles de clasificación:**
- `CC` - Critical Characteristic (Crítico)
- `SC` - Significant Characteristic (Mayor)
- `Minor` - Característica menor
**Índices de capacidad:**
- Cp, Cpk - Capacidad de proceso (corto plazo)
- Pp, Ppk - Performance de proceso (largo plazo)
**Muestreo:**
- AQL según ANSI Z1.4
- Niveles de inspección: I, II, III, S-1 a S-4
**Códigos de disposición:**
- `ACC` - Aceptado
- `REJ` - Rechazado
- `RWK` - Retrabajo
- `SCR` - Scrap
- `UAI` - Use As Is
- `RPR` - Reparar
## Documentación en R2
Ubicación: `s3://architect/system/skynet v8/03_MODELO_DATOS/sistema hst/`
| Archivo | Tag | Tamaño |
|---------|-----|--------|
| HST_Process_Standard_v1.0.md | pss | ~14KB |
| HST_Sequence_Routing_Standard_v1.0.md | sqc | ~17KB |
| HST_Process_Tree_Standard_v1.0.md | tre | ~30KB |
| HST_Gantt_Standard_v1.0.md | gnt | ~15KB |
| HST_Cost_List_Standard_v1.0.md | ctl | ~14KB |
| HST_BOM_Standard_v1.0.md | bom | ~18KB |

View File

@@ -0,0 +1,105 @@
# Índice Maestro HST
**Versión:** 2.0
**Fecha:** Enero 2026
## Estado General
### Documentos Transaccionales (con fecha, flujo, estados)
| Tag | Nombre | Schema BD | Doc R2 | Campos |
|-----|--------|-----------|--------|--------|
| inv | Factura | ✅ | ✅ | ~120 |
| siv | Factura Proveedor | ✅ | ✅ | ~120 |
| cct | Contrato | ✅ | ✅ | ~150 |
| dpa | Despatch Advice | ✅ | ✅ | ~100 |
| dnt | Delivery Note | ✅ | ✅ | ~90 |
| bgt | Presupuesto | ✅ | ✅ | ~120 |
| gtc | Condiciones Generales | ✅ | ✅ | ~90 |
| off | Oferta | ✅ | ✅ | ~130 |
| ord | Pedido | ✅ | ✅ | ~110 |
| sod | Pedido Proveedor | ✅ | ✅ | ~110 |
| qtt | Cotización | ✅ | ✅ | ~100 |
### Ejecución (Pilares QUÉ/CÓMO/CUÁNDO/COSTE/CONTROL)
| Tag | Nombre | Pilar | Schema BD | Doc R2 | Campos |
|-----|--------|-------|-----------|--------|--------|
| bom | Bill of Materials | QUÉ | ✅ | ✅ | ~85 |
| pss | Proceso | CÓMO | ✅ | ✅ | ~45 |
| sqc | Secuencia/Routing | CÓMO | ✅ | ✅ | ~55 |
| tre | Árbol de Procesos | CÓMO | ✅ | ✅ | ~70 |
| gnt | Gantt | CUÁNDO | ✅ | ✅ | ~85 |
| ctl | Lista de Costes | COSTE | ✅ | ✅ | ~65 |
| qfm | Formulario Calidad | CONTROL | ✅ | ✅ | ~95 |
| mor | Orden Fabricación | EJECUCIÓN | ⏳ | ⏳ | - |
### Entidades Maestras (datos de referencia)
| Tag | Nombre | Schema BD | Doc R2 | Notas |
|-----|--------|-----------|--------|-------|
| ppl | Persona | ⏳ | ✅ | Persona física |
| inc | Empresa/Organización | ⏳ | ✅ | Persona jurídica + anexo jurisdicciones |
| cli | Cliente | ⏳ | ✅ | Rol sobre ppl/inc |
| spl | Proveedor | ⏳ | ✅ | Rol sobre ppl/inc |
| ptn | Partner | ⏳ | ✅ | Compartir ingresos (crear tag) |
| shd | Shareholder | ⏳ | ✅ | Compartir patrimonio (crear tag, shr=showroom) |
### Documentos de Identidad
| Tag | Nombre | Schema BD | Doc R2 | Aplica a |
|-----|--------|-----------|--------|----------|
| nid | DNI/National ID | ⏳ | ✅ | ppl (crear tag) |
| pst | Pasaporte | ⏳ | ✅ | ppl |
| uid | Identificador Único | ⏳ | ⏳ | ppl, inc, animal, vehículo (crear) |
| fic | Código Fiscal | ⏳ | ⏳ | ppl, inc (existe tag) |
### Habilitaciones
| Tag | Nombre | Existente | Uso propuesto |
|-----|--------|-----------|---------------|
| opl | Operator License | No | Vehículos/maquinaria (crear) |
| pff | Profesional | Sí | Credenciales profesionales |
| lck | Control Acceso | Sí | Habilitaciones de acceso |
### Tareas y Eventos
| Tag | Nombre | Schema BD | Doc R2 | Notas |
|-----|--------|-----------|--------|-------|
| tsk | Tarea | ⏳ | ✅ | Con capas compatibilidad |
| evt | Evento | ⏳ | ✅ | Con capas compatibilidad |
## Flujos Documentales
### Ciclo Comercial
```
bgt → off (+gtc) → ord → dpa → dnt → inv
↓ ↓
qtt → sod → (dpa) → (dnt) → siv
```
### Ciclo Ejecución
```
pss → sqc → tre → gnt
bom ────────► ctl → mor → qfm
```
### Relaciones Económicas
```
ppl/inc ─┬─ cli (nos paga)
├─ spl (le pagamos)
├─ ptn (compartimos ingresos)
└─ shd (compartimos patrimonio)
```
## Pendientes Prioritarios
1. **mor** - Orden de Fabricación (cierra ciclo ejecución)
2. **uid** - Identificador Único (unifica DNI/CIF/chip/VIN)
3. **opl** - Operator License (licencias operador)
4. Actualizar schemas BD para entidades con doc R2 listo
## Ubicación Documentos
R2: `s3://architect/system/skynet v8/03_MODELO_DATOS/sistema hst/`

View File

@@ -0,0 +1,192 @@
# Índice de Schemas HST
**Versión:** 1.0
**Actualizado:** 2026-01-01
---
## Resumen
El sistema HST (HashTag Semántico) define 13 schemas de documentos comerciales siguiendo una arquitectura de 6 capas (L1-L6). Los schemas están almacenados en R2 y registrados en la base de datos HST.
---
## Documentos Comerciales
### Flujo de Ventas
| Tag | Nombre ES | Nombre EN | Campos | Descripción |
|-----|-----------|-----------|--------|-------------|
| `bgt` | Presupuesto | Budget/Estimate | 120 | Cálculo económico sin compromiso |
| `gtc` | Condiciones Generales | General Terms | 90 | Términos legales reutilizables |
| `off` | Oferta | Offer | 180 | Propuesta vinculante (bgt + gtc) |
| `ord` | Pedido | Order | 200 | Instrucción de compra |
| `dpa` | Aviso de Despacho | Despatch Advice | 180 | Notificación de envío |
| `dnt` | Albarán | Delivery Note | 160 | Documento de entrega |
| `inv` | Factura | Invoice | 250 | Documento fiscal |
| `cct` | Contrato | Contract | 280 | Acuerdo legal vinculante |
### Flujo de Compras (Perspectiva)
| Tag | Nombre ES | Base | Descripción |
|-----|-----------|------|-------------|
| `qtt` | Cotización | off | Oferta recibida de proveedor |
| `sod` | Pedido Proveedor | ord | Pedido emitido a proveedor |
| `siv` | Factura Proveedor | inv | Factura recibida de proveedor |
### Gestión
| Tag | Nombre ES | Nombre EN | Campos | Descripción |
|-----|-----------|-----------|--------|-------------|
| `evt` | Evento | Event | 80 | Registro de actividad |
| `tsk` | Tarea | Task | 70 | Unidad de trabajo |
---
## Flujo Documental
```
VENTAS:
bgt ──────────────────────────────────────────────────┐
│ │
└──▶ off (+gtc) ──▶ ord ──▶ dpa ──▶ dnt ──▶ inv │
│ │
└──▶ cct ────────────────────────────────┘
COMPRAS:
qtt ──▶ sod ──▶ (dpa) ──▶ (dnt) ──▶ siv
```
---
## Arquitectura de 6 Capas
| Capa | Nombre | Descripción |
|------|--------|-------------|
| **L1** | Core | Datos principales: header, partes, líneas, totales |
| **L2** | Tax/Legal | Información fiscal y legal |
| **L3** | Execution | Firmas, estados, seguimiento |
| **L4** | Regional | Requisitos por país (Peppol, CFDI, etc.) |
| **L5** | Links | Referencias a otros documentos |
| **L6** | Extended | Metadata, workflow, integraciones |
---
## Estándares Soportados
- **UBL 2.1** - Universal Business Language
- **Peppol BIS 3.0** - Pan-European Public Procurement Online
- **EN16931** - Norma europea de facturación electrónica
- **Factur-X / ZUGFeRD** - Factura híbrida PDF/XML
- **CFDI 4.0** - Comprobante Fiscal Digital (México)
- **FacturaE 3.2** - Factura electrónica (España)
- **INCOTERMS 2020** - Términos de comercio internacional
- **eIDAS** - Reglamento europeo de firma electrónica
---
## Ubicaciones
### Schemas Completos (R2)
```
s3://architect/system/skynet v8/03_MODELO_DATOS/sistema hst/
├── HST_Budget_Standard_v1.0.md
├── HST_Delivery_Note_Standard_v1.0.md
├── HST_Despatch_Advice_Standard_v1.0.md
├── HST_Event_Standard_v1.0.md
├── HST_General_Terms_Standard_v1.0.md
├── HST_Global_Contract_Standard_v1.0.md
├── HST_Global_Invoice_Standard_v1.0.md
├── HST_Offer_Standard_v1.0.md
├── HST_Order_Standard_v1.0.md
├── HST_Quotation_Standard_v1.0.md
├── HST_Supplier_Invoice_Standard_v1.0.md
├── HST_Supplier_Order_Standard_v1.0.md
└── HST_Task_Standard_v1.0.md
```
### Base de Datos (HST Server)
- **Servidor:** 72.62.2.84
- **Base de datos:** lumalia
- **Tabla:** hst
- **Campo:** descripcion_modelo (JSONB)
---
## Consultas Útiles
### Listar schemas disponibles
```sql
SELECT ref, nombre_es,
descripcion_modelo->>'name_en' as name_en,
descripcion_modelo->>'total_fields' as campos
FROM hst
WHERE descripcion_modelo IS NOT NULL
ORDER BY ref;
```
### Ver flujo documental de un tipo
```sql
SELECT ref,
descripcion_modelo->'document_flow'->>'input' as entrada,
descripcion_modelo->'document_flow'->>'output' as salida
FROM hst
WHERE ref = 'ord';
```
### Listar capas de un schema
```sql
SELECT ref,
jsonb_object_keys(descripcion_modelo->'layers') as capa
FROM hst
WHERE ref = 'inv';
```
---
## Tipos de Documento
### Tipos de Factura (inv/siv)
| Código | UNTDID 1001 | Descripción |
|--------|-------------|-------------|
| 380 | Commercial Invoice | Factura comercial |
| 381 | Credit Note | Nota de crédito |
| 383 | Debit Note | Nota de débito |
| 384 | Corrective Invoice | Factura rectificativa |
| 389 | Self-billed Invoice | Autofactura |
| 751 | Invoice Information | Factura informativa |
### Tipos de Pedido (ord/sod)
| Código | Descripción |
|--------|-------------|
| STD | Pedido estándar |
| BLK | Pedido abierto/marco |
| REL | Liberación de pedido abierto |
| SPT | Pedido puntual |
| RPT | Pedido repetitivo |
| RUS | Pedido urgente |
| SVC | Pedido de servicios |
### Tipos de Contrato (cct)
| Código | Descripción |
|--------|-------------|
| FRM | Contrato marco |
| SVC | Servicios |
| NDX | Anexo/Adenda |
| LIC | Licencia |
| EMP | Empleo |
| LEA | Arrendamiento |
| PUR | Compraventa |
---
## Changelog
| Fecha | Versión | Cambios |
|-------|---------|---------|
| 2026-01-01 | 1.0 | Versión inicial con 13 schemas |

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

141
03_MODELO_DATOS/planos.md Normal file
View File

@@ -0,0 +1,141 @@
# Planos de Datos
**Versión:** 1.0
**Estado:** Definición
---
## Visión General
El sistema utiliza tres planos conceptuales para organizar la información:
```
┌─────────────────────────────────────────────────────────────────┐
│ T0 - PLANO IDEAL │
│ ITM (Items): Objetivos, acciones ideales, requerimientos │
└─────────────────────────────────────────────────────────────────┘
▼ materializa
┌─────────────────────────────────────────────────────────────────┐
│ MST - MILESTONES │
│ Compromisos futuros con fecha de vencimiento │
└─────────────────────────────────────────────────────────────────┘
▼ cumple/genera
┌─────────────────────────────────────────────────────────────────┐
│ BCK - BLOQUES │
│ Hechos inmutables del pasado (blockchain-ready) │
└─────────────────────────────────────────────────────────────────┘
```
---
## T0 - Plano Ideal (ITM)
### Concepto
El plano T0 contiene los Items que representan el estado ideal futuro. Son la "partitura" que guía las acciones.
### Naturaleza
| Aspecto | Valor |
|---------|-------|
| Temporalidad | T-N → T-1 → T0 |
| Energía | No consume (es definición) |
| Mutabilidad | Versionable |
### Estado
**PLANIFICADO** - Schema definido pero sin tablas creadas.
---
## MST - Milestones
### Concepto
Compromisos con fecha futura. Tienen un período flotante de 24 horas antes de consolidarse.
### Tipos
| Tipo | Descripción |
|------|-------------|
| compromiso | Compromiso de entrega |
| deadline | Fecha límite |
| evento | Evento programado |
| recordatorio | Recordatorio futuro |
### Período Flotante
| Parámetro | Valor |
|-----------|-------|
| Duración | 24 horas |
| Durante | Modificable vía Mason |
| Después | Inmutable |
### Estado
**IMPLEMENTADO** en CORP.
---
## BCK - Bloques
### Concepto
Registros inmutables de hechos pasados. Cada bloque está encadenado al anterior mediante hash.
### Tipos
| Tipo | Descripción |
|------|-------------|
| transaccion | Transacción económica |
| documento | Documento consolidado |
| evento | Evento registrado |
| milestone_cumplido | Milestone que se cumplió |
### Encadenamiento
```
Bloque N-1 Bloque N
┌──────────────────┐ ┌──────────────────┐
│ h_bloque: abc123 │ ──────► │ hash_previo: │
│ hash_contenido: │ │ abc123 │
│ def456 │ │ h_bloque: ghi789 │
│ secuencia: 1 │ │ secuencia: 2 │
└──────────────────┘ └──────────────────┘
```
### Estado
**IMPLEMENTADO** en CORP.
---
## Flujo Entre Planos
```
Usuario crea ITM
ITM (T0) "Objetivo: Completar proyecto X"
│ materializa
MST "Milestone: Entrega módulo 1 - 2024-01-15"
│ [período flotante 24h]
MASON (enriquecimiento)
FELDMAN (validación)
│ cumple/genera
BCK "Bloque: Módulo 1 entregado - 2024-01-14"
Inmutable ✓
```

View File

@@ -0,0 +1,59 @@
# Listado de Procesos Productivos
## Procesos de Corte y Conformado
- Corte láser
- Grabado láser
- Mecanizado CNC
- Torneado
- Plegado de chapa
- Curvado de chapa
- Curvado de tubo
- Cizallado
- Troquelado
- Repulsado
- Estampación
- Embutición
- Rebordeado
## Procesos de Acabado Superficial
- Pintura
- Anodizado
- Arenado
- Lijado
- Calibrado
- Pulido
- Vinilado
- Ploteo (plotter)
## Procesos de Unión y Fijación
- Soldadura de aluminio
- Soldadura con estaño
- Remachado
- Remachado de roscas
- Adhesivado
## Procesos de Taladrado y Roscas
- Taladrado
- Roscado con machos
## Procesos de Plástico y Moldeo
- Inyección de plástico
- Termoconformado
- Termorretráctil
## Procesos Eléctricos y de Cableado
- Corte de cable
- Pelado
- Desforrado
- Estañado
- Embornado
- Insertado (insertadora)
## Procesos de Montaje y Finales
- Montaje
- Instalación
- Embalado
## Procesos Especiales
- Colada / Potting
- Vacío + Autoclave

View File

@@ -0,0 +1,101 @@
-- ============================================
-- TIPOS ENUMERADOS COMUNES
-- Sistema TZZR - contratos-comunes
-- ============================================
-- Aplicar primero antes de cualquier otro schema
-- Estados de tarea
DO $$ BEGIN
CREATE TYPE task_status AS ENUM (
'draft', -- Borrador, no iniciada
'pending', -- Pendiente de inicio
'in_progress', -- En progreso
'blocked', -- Bloqueada por dependencia
'review', -- En revisión
'completed', -- Completada
'cancelled' -- Cancelada
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
-- Prioridad de tarea
DO $$ BEGIN
CREATE TYPE task_priority AS ENUM (
'critical', -- Crítica, atención inmediata
'high', -- Alta prioridad
'medium', -- Media (default)
'low', -- Baja prioridad
'someday' -- Algún día / sin fecha
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
-- Dirección de archivo en work log
DO $$ BEGIN
CREATE TYPE file_direction AS ENUM (
'inbound', -- Archivo recibido
'outbound', -- Archivo enviado
'internal', -- Archivo interno/generado
'reference' -- Archivo de referencia
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
-- Servicios de IA del ecosistema
DO $$ BEGIN
CREATE TYPE ai_service AS ENUM (
'grace', -- GRACE - Capa de procesamiento
'penny', -- PENNY - Asistente de voz
'factory' -- THE FACTORY - Procesamiento documental
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
-- Grupos de etiquetas HST
DO $$ BEGIN
CREATE TYPE hst_grupo AS ENUM (
'hst', -- Sistema (sync tzrtech.org)
'emp', -- Empresa
'hsu', -- Usuario
'pjt' -- Proyecto
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
-- Modo de despliegue S-CONTRACT
DO $$ BEGIN
CREATE TYPE deployment_mode AS ENUM (
'EXTERNAL', -- Solo APIs externas
'SELF_HOSTED', -- Solo infraestructura propia
'SEMI' -- Híbrido con fallback
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
-- Tier de proveedor
DO $$ BEGIN
CREATE TYPE provider_tier AS ENUM (
'SELF_HOSTED', -- Infraestructura propia
'EXTERNAL' -- API externa
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
-- ============================================
-- FUNCIÓN: Actualizar updated_at automáticamente
-- ============================================
CREATE OR REPLACE FUNCTION update_updated_at_column()
RETURNS TRIGGER AS $$
BEGIN
NEW.updated_at = CURRENT_TIMESTAMP;
RETURN NEW;
END;
$$ language 'plpgsql';

View File

@@ -0,0 +1,227 @@
-- ============================================
-- TABLAS HST (Sistema de Etiquetas)
-- Sistema TZZR - contratos-comunes
-- ============================================
-- Requiere: 00_types.sql
--
-- SISTEMA DUAL DE HASHES:
-- ┌─────────────────────────────────────────────────────────────┐
-- │ h_maestro = SHA-256(grupo || ':' || ref) │
-- │ → Identidad SEMÁNTICA (determinista, para S-CONTRACT) │
-- │ → Ejemplo: SHA-256("hst:finanzas") = "a7b3c9..." │
-- │ │
-- │ mrf = SHA-256(bytes_imagen) │
-- │ → Identidad de ARCHIVO (para servir imágenes) │
-- │ → URL: https://tzrtech.org/{mrf}.png │
-- └─────────────────────────────────────────────────────────────┘
-- ============================================
-- TABLA BASE: hst_tags
-- Tabla unificada de etiquetas HST
-- ============================================
CREATE TABLE IF NOT EXISTS hst_tags (
id SERIAL PRIMARY KEY,
-- Identificadores duales
h_maestro VARCHAR(64) UNIQUE NOT NULL, -- SHA-256(grupo:ref), identidad semántica
ref VARCHAR(50) NOT NULL, -- Referencia corta (ej: "finanzas")
mrf VARCHAR(64), -- SHA-256(imagen_bytes), hash de imagen
-- Nombres
nombre VARCHAR(100) NOT NULL, -- Nombre legible en español
nombre_en VARCHAR(100), -- Nombre en inglés
descripcion TEXT,
-- Visual
imagen_url TEXT, -- URL completa (https://tzrtech.org/{mrf}.png)
color VARCHAR(7), -- Color hex (#RRGGBB)
icono VARCHAR(50), -- Nombre de icono (ej: lucide:tag)
-- Clasificación
grupo hst_grupo NOT NULL, -- hst, emp, hsu, pjt
categoria VARCHAR(100), -- Categoría dentro del grupo
-- Jerarquía
padre_h_maestro VARCHAR(64) REFERENCES hst_tags(h_maestro),
rootref VARCHAR(50), -- Ref del ancestro raíz
nivel INTEGER DEFAULT 0, -- Nivel de profundidad (0 = raíz)
path_h_maestros TEXT[], -- Array de ancestros para queries rápidas
-- Estado
activo BOOLEAN DEFAULT true,
visible BOOLEAN DEFAULT true, -- Visible en UI
-- Sync con tzrtech.org
source VARCHAR(50) DEFAULT 'local', -- local, tzrtech, empresa
source_id VARCHAR(100), -- ID en el sistema origen
synced_at TIMESTAMP, -- Última sincronización
-- Metadata
metadata JSONB DEFAULT '{}',
-- Timestamps
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
-- Constraints
CONSTRAINT unique_ref_grupo UNIQUE(ref, grupo)
);
-- Índices principales
CREATE INDEX IF NOT EXISTS idx_hst_tags_h_maestro ON hst_tags(h_maestro);
CREATE INDEX IF NOT EXISTS idx_hst_tags_ref ON hst_tags(ref);
CREATE INDEX IF NOT EXISTS idx_hst_tags_mrf ON hst_tags(mrf);
CREATE INDEX IF NOT EXISTS idx_hst_tags_grupo ON hst_tags(grupo);
CREATE INDEX IF NOT EXISTS idx_hst_tags_categoria ON hst_tags(categoria);
CREATE INDEX IF NOT EXISTS idx_hst_tags_padre ON hst_tags(padre_h_maestro);
CREATE INDEX IF NOT EXISTS idx_hst_tags_rootref ON hst_tags(rootref);
CREATE INDEX IF NOT EXISTS idx_hst_tags_activo ON hst_tags(activo);
CREATE INDEX IF NOT EXISTS idx_hst_tags_path ON hst_tags USING GIN(path_h_maestros);
-- Trigger para updated_at
DROP TRIGGER IF EXISTS update_hst_tags_updated_at ON hst_tags;
CREATE TRIGGER update_hst_tags_updated_at BEFORE UPDATE ON hst_tags
FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
-- ============================================
-- FUNCIÓN: Calcular path de ancestros
-- ============================================
CREATE OR REPLACE FUNCTION calculate_hst_path()
RETURNS TRIGGER AS $$
DECLARE
parent_path TEXT[];
BEGIN
IF NEW.padre_h_maestro IS NULL THEN
NEW.path_h_maestros := ARRAY[]::TEXT[];
NEW.nivel := 0;
ELSE
SELECT path_h_maestros, nivel + 1
INTO parent_path, NEW.nivel
FROM hst_tags
WHERE h_maestro = NEW.padre_h_maestro;
NEW.path_h_maestros := array_append(parent_path, NEW.padre_h_maestro);
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
DROP TRIGGER IF EXISTS trigger_calculate_hst_path ON hst_tags;
CREATE TRIGGER trigger_calculate_hst_path
BEFORE INSERT OR UPDATE OF padre_h_maestro ON hst_tags
FOR EACH ROW EXECUTE FUNCTION calculate_hst_path();
-- ============================================
-- VISTAS POR GRUPO (Compatibilidad con v2)
-- ============================================
-- Vista: Etiquetas del sistema (HST)
CREATE OR REPLACE VIEW hst_tags_sistema AS
SELECT * FROM hst_tags WHERE grupo = 'hst';
-- Vista: Etiquetas de empresa (EMP)
CREATE OR REPLACE VIEW hst_tags_empresa AS
SELECT * FROM hst_tags WHERE grupo = 'emp';
-- Vista: Etiquetas de usuario (HSU)
CREATE OR REPLACE VIEW hst_tags_usuario AS
SELECT * FROM hst_tags WHERE grupo = 'hsu';
-- Vista: Etiquetas de proyecto (PJT)
CREATE OR REPLACE VIEW hst_tags_proyecto AS
SELECT * FROM hst_tags WHERE grupo = 'pjt';
-- ============================================
-- TABLA: hst_tag_relations
-- Relaciones entre etiquetas (sinónimos, relacionados)
-- ============================================
CREATE TABLE IF NOT EXISTS hst_tag_relations (
id SERIAL PRIMARY KEY,
tag_a_h_maestro VARCHAR(64) NOT NULL REFERENCES hst_tags(h_maestro),
tag_b_h_maestro VARCHAR(64) NOT NULL REFERENCES hst_tags(h_maestro),
-- Tipo de relación
relation_type VARCHAR(50) NOT NULL, -- synonym, related, opposite, child_of
strength DECIMAL(3,2) DEFAULT 1.0, -- Fuerza de la relación (0-1)
bidirectional BOOLEAN DEFAULT true,
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT unique_tag_relation UNIQUE(tag_a_h_maestro, tag_b_h_maestro, relation_type),
CONSTRAINT chk_different_tags CHECK (tag_a_h_maestro != tag_b_h_maestro)
);
CREATE INDEX IF NOT EXISTS idx_tag_relations_a ON hst_tag_relations(tag_a_h_maestro);
CREATE INDEX IF NOT EXISTS idx_tag_relations_b ON hst_tag_relations(tag_b_h_maestro);
CREATE INDEX IF NOT EXISTS idx_tag_relations_type ON hst_tag_relations(relation_type);
-- ============================================
-- FUNCIÓN: Generar h_maestro (DETERMINISTA)
-- SHA-256(grupo || ':' || ref)
-- ============================================
CREATE OR REPLACE FUNCTION generate_h_maestro(p_grupo TEXT, p_ref TEXT)
RETURNS VARCHAR(64) AS $$
BEGIN
-- DETERMINISTA: mismo input = mismo output SIEMPRE
RETURN encode(sha256((p_grupo || ':' || p_ref)::bytea), 'hex');
END;
$$ LANGUAGE plpgsql IMMUTABLE;
-- ============================================
-- FUNCIÓN: Generar imagen_url desde mrf
-- ============================================
CREATE OR REPLACE FUNCTION generate_imagen_url(p_mrf VARCHAR(64))
RETURNS TEXT AS $$
BEGIN
IF p_mrf IS NULL THEN
RETURN NULL;
END IF;
RETURN 'https://tzrtech.org/' || p_mrf || '.png';
END;
$$ LANGUAGE plpgsql IMMUTABLE;
-- ============================================
-- DATOS INICIALES: Categorías base
-- Nota: Los datos reales vienen de tzrtech.org/api/index.json
-- ============================================
INSERT INTO hst_tags (h_maestro, ref, nombre, nombre_en, grupo, categoria, color) VALUES
(generate_h_maestro('hst', 'trabajo'), 'trabajo', 'Trabajo', 'Work', 'hst', 'actividad', '#3498db'),
(generate_h_maestro('hst', 'personal'), 'personal', 'Personal', 'Personal', 'hst', 'actividad', '#2ecc71'),
(generate_h_maestro('hst', 'urgente'), 'urgente', 'Urgente', 'Urgent', 'hst', 'prioridad', '#e74c3c'),
(generate_h_maestro('hst', 'proyecto'), 'proyecto', 'Proyecto', 'Project', 'hst', 'organizacion', '#9b59b6'),
(generate_h_maestro('hst', 'factura'), 'factura', 'Factura', 'Invoice', 'hst', 'documento', '#f39c12'),
(generate_h_maestro('hst', 'contrato'), 'contrato', 'Contrato', 'Contract', 'hst', 'documento', '#1abc9c'),
(generate_h_maestro('hst', 'email'), 'email', 'Email', 'Email', 'hst', 'comunicacion', '#34495e'),
(generate_h_maestro('hst', 'reunion'), 'reunion', 'Reunión', 'Meeting', 'hst', 'evento', '#e67e22')
ON CONFLICT (h_maestro) DO NOTHING;
-- ============================================
-- VISTA: API JSON compatible con tzrtech.org
-- ============================================
CREATE OR REPLACE VIEW hst_api_index AS
SELECT
ref,
h_maestro,
mrf,
nombre AS nombre_es,
nombre_en,
grupo,
categoria,
color,
imagen_url,
padre_h_maestro,
rootref,
nivel,
activo
FROM hst_tags
WHERE activo = true
ORDER BY grupo, nivel, nombre;

View File

@@ -0,0 +1,290 @@
-- ============================================
-- GESTOR DE TAREAS
-- Sistema TZZR - contratos-comunes
-- ============================================
-- Requiere: 00_types.sql, 01_hst_tags.sql
-- ============================================
-- TABLA: task_projects
-- Proyectos que agrupan tareas
-- ============================================
CREATE TABLE IF NOT EXISTS task_projects (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
codigo VARCHAR(50) UNIQUE NOT NULL, -- Código corto (ej: DECK-2024)
nombre VARCHAR(255) NOT NULL,
descripcion TEXT,
-- Estado
activo BOOLEAN DEFAULT true,
archivado BOOLEAN DEFAULT false,
fecha_inicio DATE,
fecha_fin_estimada DATE,
fecha_fin_real DATE,
-- Etiquetas (array de h_maestro)
tags JSONB DEFAULT '[]',
-- Configuración de contexto por defecto
default_context_id UUID, -- FK a task_contexts (añadido después)
-- Metadata
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX IF NOT EXISTS idx_task_projects_codigo ON task_projects(codigo);
CREATE INDEX IF NOT EXISTS idx_task_projects_activo ON task_projects(activo);
CREATE INDEX IF NOT EXISTS idx_task_projects_tags ON task_projects USING GIN(tags);
DROP TRIGGER IF EXISTS update_task_projects_updated_at ON task_projects;
CREATE TRIGGER update_task_projects_updated_at BEFORE UPDATE ON task_projects
FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
-- ============================================
-- TABLA: task_milestones
-- Hitos dentro de un proyecto
-- ============================================
CREATE TABLE IF NOT EXISTS task_milestones (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
project_id UUID REFERENCES task_projects(id) ON DELETE CASCADE,
codigo VARCHAR(50) NOT NULL, -- Código dentro del proyecto
nombre VARCHAR(255) NOT NULL,
descripcion TEXT,
-- Orden y jerarquía
orden INTEGER DEFAULT 0,
parent_milestone_id UUID REFERENCES task_milestones(id),
-- Fechas
fecha_objetivo DATE,
fecha_completado DATE,
-- Progreso (calculado automáticamente)
progreso_percent DECIMAL(5,2) DEFAULT 0,
-- Etiquetas
tags JSONB DEFAULT '[]',
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT unique_milestone_code UNIQUE(project_id, codigo)
);
CREATE INDEX IF NOT EXISTS idx_task_milestones_project ON task_milestones(project_id);
CREATE INDEX IF NOT EXISTS idx_task_milestones_parent ON task_milestones(parent_milestone_id);
CREATE INDEX IF NOT EXISTS idx_task_milestones_orden ON task_milestones(orden);
DROP TRIGGER IF EXISTS update_task_milestones_updated_at ON task_milestones;
CREATE TRIGGER update_task_milestones_updated_at BEFORE UPDATE ON task_milestones
FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
-- ============================================
-- TABLA: task_blocks
-- Bloques de trabajo dentro de milestones
-- ============================================
CREATE TABLE IF NOT EXISTS task_blocks (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
milestone_id UUID REFERENCES task_milestones(id) ON DELETE CASCADE,
codigo VARCHAR(50) NOT NULL,
nombre VARCHAR(255) NOT NULL,
descripcion TEXT,
-- Orden
orden INTEGER DEFAULT 0,
-- Estimación
horas_estimadas DECIMAL(6,2),
horas_reales DECIMAL(6,2),
-- Estado
status task_status DEFAULT 'pending',
-- Etiquetas
tags JSONB DEFAULT '[]',
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT unique_block_code UNIQUE(milestone_id, codigo)
);
CREATE INDEX IF NOT EXISTS idx_task_blocks_milestone ON task_blocks(milestone_id);
CREATE INDEX IF NOT EXISTS idx_task_blocks_status ON task_blocks(status);
DROP TRIGGER IF EXISTS update_task_blocks_updated_at ON task_blocks;
CREATE TRIGGER update_task_blocks_updated_at BEFORE UPDATE ON task_blocks
FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
-- ============================================
-- TABLA: task_manager
-- Tareas individuales
-- ============================================
CREATE TABLE IF NOT EXISTS task_manager (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-- Jerarquía
project_id UUID REFERENCES task_projects(id) ON DELETE SET NULL,
milestone_id UUID REFERENCES task_milestones(id) ON DELETE SET NULL,
block_id UUID REFERENCES task_blocks(id) ON DELETE SET NULL,
parent_task_id UUID REFERENCES task_manager(id) ON DELETE SET NULL,
-- Identificación
codigo VARCHAR(100), -- Código único generado
titulo VARCHAR(500) NOT NULL,
descripcion TEXT,
-- Estado y prioridad
status task_status DEFAULT 'pending',
priority task_priority DEFAULT 'medium',
-- Fechas
fecha_creacion TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
fecha_inicio DATE,
fecha_vencimiento DATE,
fecha_completado TIMESTAMP,
-- Estimación
horas_estimadas DECIMAL(6,2),
horas_reales DECIMAL(6,2),
-- Asignación
asignado_a VARCHAR(100), -- Usuario o servicio
creado_por VARCHAR(100) DEFAULT 'system',
-- Etiquetas HST (separadas por grupo para queries eficientes)
tags_hst JSONB DEFAULT '[]', -- h_maestros de grupo hst
tags_hsu JSONB DEFAULT '[]', -- h_maestros de grupo hsu
tags_emp JSONB DEFAULT '[]', -- h_maestros de grupo emp
tags_pjt JSONB DEFAULT '[]', -- h_maestros de grupo pjt
-- Contexto IA
context_id UUID, -- FK a task_contexts (añadido después)
-- Archivos relacionados (array de UUIDs de work_log)
archivos_ref JSONB DEFAULT '[]',
-- Trazabilidad S-CONTRACT
trace_id VARCHAR(64),
-- Metadata
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX IF NOT EXISTS idx_task_manager_project ON task_manager(project_id);
CREATE INDEX IF NOT EXISTS idx_task_manager_milestone ON task_manager(milestone_id);
CREATE INDEX IF NOT EXISTS idx_task_manager_block ON task_manager(block_id);
CREATE INDEX IF NOT EXISTS idx_task_manager_parent ON task_manager(parent_task_id);
CREATE INDEX IF NOT EXISTS idx_task_manager_status ON task_manager(status);
CREATE INDEX IF NOT EXISTS idx_task_manager_priority ON task_manager(priority);
CREATE INDEX IF NOT EXISTS idx_task_manager_fecha_venc ON task_manager(fecha_vencimiento);
CREATE INDEX IF NOT EXISTS idx_task_manager_asignado ON task_manager(asignado_a);
CREATE INDEX IF NOT EXISTS idx_task_manager_tags_hst ON task_manager USING GIN(tags_hst);
CREATE INDEX IF NOT EXISTS idx_task_manager_tags_hsu ON task_manager USING GIN(tags_hsu);
CREATE INDEX IF NOT EXISTS idx_task_manager_trace ON task_manager(trace_id);
DROP TRIGGER IF EXISTS update_task_manager_updated_at ON task_manager;
CREATE TRIGGER update_task_manager_updated_at BEFORE UPDATE ON task_manager
FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
-- ============================================
-- TABLA: task_dependencies
-- Dependencias entre tareas
-- ============================================
CREATE TABLE IF NOT EXISTS task_dependencies (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
task_id UUID NOT NULL REFERENCES task_manager(id) ON DELETE CASCADE,
depends_on_task_id UUID NOT NULL REFERENCES task_manager(id) ON DELETE CASCADE,
-- Tipo de dependencia
tipo VARCHAR(50) DEFAULT 'finish_to_start',
-- finish_to_start: B empieza cuando A termina
-- start_to_start: B empieza cuando A empieza
-- finish_to_finish: B termina cuando A termina
-- start_to_finish: B termina cuando A empieza
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT unique_dependency UNIQUE(task_id, depends_on_task_id),
CONSTRAINT chk_no_self_dep CHECK (task_id != depends_on_task_id)
);
CREATE INDEX IF NOT EXISTS idx_task_deps_task ON task_dependencies(task_id);
CREATE INDEX IF NOT EXISTS idx_task_deps_depends ON task_dependencies(depends_on_task_id);
-- ============================================
-- FUNCIÓN: Actualizar progreso de milestone
-- ============================================
CREATE OR REPLACE FUNCTION update_milestone_progress()
RETURNS TRIGGER AS $$
BEGIN
UPDATE task_milestones
SET progreso_percent = (
SELECT COALESCE(
(COUNT(*) FILTER (WHERE status = 'completed')::DECIMAL /
NULLIF(COUNT(*), 0) * 100),
0
)
FROM task_manager
WHERE milestone_id = COALESCE(NEW.milestone_id, OLD.milestone_id)
),
updated_at = CURRENT_TIMESTAMP
WHERE id = COALESCE(NEW.milestone_id, OLD.milestone_id);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
DROP TRIGGER IF EXISTS trigger_update_milestone_progress ON task_manager;
CREATE TRIGGER trigger_update_milestone_progress
AFTER INSERT OR UPDATE OF status OR DELETE ON task_manager
FOR EACH ROW EXECUTE FUNCTION update_milestone_progress();
-- ============================================
-- FUNCIÓN: Generar código de tarea
-- ============================================
CREATE OR REPLACE FUNCTION generate_task_codigo()
RETURNS TRIGGER AS $$
DECLARE
prefix VARCHAR(20);
seq INTEGER;
BEGIN
IF NEW.codigo IS NULL OR NEW.codigo = '' THEN
IF NEW.project_id IS NOT NULL THEN
SELECT codigo INTO prefix FROM task_projects WHERE id = NEW.project_id;
ELSE
prefix := 'TASK';
END IF;
SELECT COALESCE(MAX(
CAST(SUBSTRING(codigo FROM '[0-9]+$') AS INTEGER)
), 0) + 1
INTO seq
FROM task_manager
WHERE codigo LIKE prefix || '-%';
NEW.codigo := prefix || '-' || LPAD(seq::TEXT, 4, '0');
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
DROP TRIGGER IF EXISTS trigger_generate_task_codigo ON task_manager;
CREATE TRIGGER trigger_generate_task_codigo
BEFORE INSERT ON task_manager
FOR EACH ROW EXECUTE FUNCTION generate_task_codigo();

View File

@@ -0,0 +1,168 @@
-- ============================================
-- LOG DE TRABAJO (Work Log)
-- Sistema TZZR - contratos-comunes
-- ============================================
-- Requiere: 00_types.sql, 02_task_manager.sql
-- ============================================
-- TABLA: task_work_log
-- Registro de archivos entrantes/salientes
-- ============================================
CREATE TABLE IF NOT EXISTS task_work_log (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-- Relación con tarea (opcional)
task_id UUID REFERENCES task_manager(id) ON DELETE SET NULL,
project_id UUID REFERENCES task_projects(id) ON DELETE SET NULL,
-- Dirección
direction file_direction NOT NULL,
-- Información del archivo
filename VARCHAR(500) NOT NULL,
filepath TEXT, -- Ruta en FileBrowser o URL
file_hash VARCHAR(64), -- SHA-256 del contenido
file_size_bytes BIGINT,
mime_type VARCHAR(100),
file_extension VARCHAR(20),
-- Origen/Destino
source VARCHAR(255), -- email, upload, api, scrape, etc.
source_ref VARCHAR(500), -- Referencia específica (message_id, url, etc.)
destination VARCHAR(255), -- grace, penny, factory, export, storage
destination_ref VARCHAR(500),
-- Procesamiento IA
processed_by_ia BOOLEAN DEFAULT false,
ai_service ai_service,
ai_module VARCHAR(50), -- Módulo específico (ASR_ENGINE, OCR_CORE, etc.)
ai_trace_id VARCHAR(64), -- trace_id del S-CONTRACT
ai_status VARCHAR(20), -- SUCCESS, ERROR, PARTIAL
ai_result_summary JSONB, -- Resumen del resultado
-- Descripción
titulo VARCHAR(255),
descripcion TEXT,
-- Etiquetas (h_maestros)
tags JSONB DEFAULT '[]',
-- Metadata
metadata JSONB DEFAULT '{}',
-- Timestamps
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
processed_at TIMESTAMP
);
CREATE INDEX IF NOT EXISTS idx_work_log_task ON task_work_log(task_id);
CREATE INDEX IF NOT EXISTS idx_work_log_project ON task_work_log(project_id);
CREATE INDEX IF NOT EXISTS idx_work_log_direction ON task_work_log(direction);
CREATE INDEX IF NOT EXISTS idx_work_log_hash ON task_work_log(file_hash);
CREATE INDEX IF NOT EXISTS idx_work_log_source ON task_work_log(source);
CREATE INDEX IF NOT EXISTS idx_work_log_destination ON task_work_log(destination);
CREATE INDEX IF NOT EXISTS idx_work_log_ai_service ON task_work_log(ai_service);
CREATE INDEX IF NOT EXISTS idx_work_log_ai_trace ON task_work_log(ai_trace_id);
CREATE INDEX IF NOT EXISTS idx_work_log_fecha ON task_work_log(created_at);
CREATE INDEX IF NOT EXISTS idx_work_log_tags ON task_work_log USING GIN(tags);
CREATE INDEX IF NOT EXISTS idx_work_log_mime ON task_work_log(mime_type);
-- ============================================
-- TABLA: task_work_log_versions
-- Versiones de archivos (tracking de cambios)
-- ============================================
CREATE TABLE IF NOT EXISTS task_work_log_versions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
work_log_id UUID NOT NULL REFERENCES task_work_log(id) ON DELETE CASCADE,
version INTEGER NOT NULL,
filepath TEXT NOT NULL,
file_hash VARCHAR(64) NOT NULL,
file_size_bytes BIGINT,
-- Cambio
change_type VARCHAR(50), -- created, modified, processed, exported
change_description TEXT,
changed_by VARCHAR(100),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT unique_version UNIQUE(work_log_id, version)
);
CREATE INDEX IF NOT EXISTS idx_work_log_versions_log ON task_work_log_versions(work_log_id);
CREATE INDEX IF NOT EXISTS idx_work_log_versions_hash ON task_work_log_versions(file_hash);
-- ============================================
-- FUNCIÓN: Auto-incrementar versión
-- ============================================
CREATE OR REPLACE FUNCTION auto_version_work_log()
RETURNS TRIGGER AS $$
DECLARE
next_version INTEGER;
BEGIN
SELECT COALESCE(MAX(version), 0) + 1
INTO next_version
FROM task_work_log_versions
WHERE work_log_id = NEW.work_log_id;
NEW.version := next_version;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
DROP TRIGGER IF EXISTS trigger_auto_version_work_log ON task_work_log_versions;
CREATE TRIGGER trigger_auto_version_work_log
BEFORE INSERT ON task_work_log_versions
FOR EACH ROW EXECUTE FUNCTION auto_version_work_log();
-- ============================================
-- VISTA: Work log reciente
-- ============================================
CREATE OR REPLACE VIEW v_work_log_recent AS
SELECT
w.id,
w.filename,
w.direction,
w.source,
w.destination,
w.ai_service,
w.ai_module,
w.ai_status,
w.processed_by_ia,
t.titulo AS tarea,
t.codigo AS tarea_codigo,
p.nombre AS proyecto,
p.codigo AS proyecto_codigo,
w.file_size_bytes,
w.mime_type,
w.created_at,
w.processed_at
FROM task_work_log w
LEFT JOIN task_manager t ON w.task_id = t.id
LEFT JOIN task_projects p ON w.project_id = p.id
ORDER BY w.created_at DESC;
-- ============================================
-- VISTA: Archivos pendientes de procesar
-- ============================================
CREATE OR REPLACE VIEW v_work_log_pending AS
SELECT
w.id,
w.filename,
w.mime_type,
w.file_size_bytes,
w.source,
w.direction,
p.nombre AS proyecto,
w.created_at
FROM task_work_log w
LEFT JOIN task_projects p ON w.project_id = p.id
WHERE w.processed_by_ia = false
AND w.direction IN ('inbound', 'internal')
ORDER BY w.created_at ASC;

View File

@@ -0,0 +1,354 @@
-- ============================================
-- CONTEXTO PARA SERVICIOS IA
-- Sistema TZZR - contratos-comunes
-- ============================================
-- Requiere: 00_types.sql, 01_hst_tags.sql, 02_task_manager.sql
--
-- IMPORTANTE: Las estructuras aquí almacenadas corresponden
-- exactamente al bloque "context" del S-CONTRACT v2.1
-- (schemas/s-contract-request.json)
-- ============================================
-- TABLA: s_contract_contexts
-- Contextos reutilizables en formato S-CONTRACT
-- ============================================
CREATE TABLE IF NOT EXISTS s_contract_contexts (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-- Identificación
codigo VARCHAR(100) UNIQUE NOT NULL,
nombre VARCHAR(255) NOT NULL,
descripcion TEXT,
-- ============================================
-- BLOQUE context (S-CONTRACT v2.1)
-- Almacenado como JSONB para garantizar formato exacto
-- ============================================
context JSONB NOT NULL DEFAULT '{
"lang": "es",
"mode": "strict",
"pii_filter": false,
"bandera_id": null,
"player_id": null,
"method_hash": null,
"human_readable": null,
"system_instruction": null,
"datasets": [],
"tags": {"hst": [], "hsu": [], "emp": [], "pjt": []},
"ambiente": {"timezone": "Europe/Madrid", "locale": "es-ES"}
}'::jsonb,
-- ============================================
-- BLOQUE deployment (S-CONTRACT v2.1)
-- Configuración de despliegue asociada
-- ============================================
deployment JSONB DEFAULT '{
"mode": "SEMI",
"tier_preference": ["SELF_HOSTED", "EXTERNAL"]
}'::jsonb,
-- Alcance
scope VARCHAR(50) DEFAULT 'global', -- global, project, task
project_id UUID REFERENCES task_projects(id) ON DELETE SET NULL,
-- Estado
activo BOOLEAN DEFAULT true,
-- Metadata (campos no S-CONTRACT, solo para gestión interna)
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX IF NOT EXISTS idx_scontract_ctx_codigo ON s_contract_contexts(codigo);
CREATE INDEX IF NOT EXISTS idx_scontract_ctx_scope ON s_contract_contexts(scope);
CREATE INDEX IF NOT EXISTS idx_scontract_ctx_project ON s_contract_contexts(project_id);
CREATE INDEX IF NOT EXISTS idx_scontract_ctx_activo ON s_contract_contexts(activo);
CREATE INDEX IF NOT EXISTS idx_scontract_ctx_context ON s_contract_contexts USING GIN(context);
CREATE INDEX IF NOT EXISTS idx_scontract_ctx_deployment ON s_contract_contexts USING GIN(deployment);
DROP TRIGGER IF EXISTS update_scontract_ctx_updated_at ON s_contract_contexts;
CREATE TRIGGER update_scontract_ctx_updated_at BEFORE UPDATE ON s_contract_contexts
FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
-- ============================================
-- TABLA: s_contract_datasets
-- Datasets reutilizables (formato S-CONTRACT context.datasets[])
-- ============================================
CREATE TABLE IF NOT EXISTS s_contract_datasets (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-- Campos que mapean a context.datasets[] en S-CONTRACT
codigo VARCHAR(100) UNIQUE NOT NULL,
tipo VARCHAR(50) NOT NULL, -- knowledge, examples, rules, vocabulary, context, persona
contenido TEXT, -- Contenido inline
contenido_ref TEXT, -- URI a contenido externo
-- Campos adicionales de gestión (no van en S-CONTRACT)
nombre VARCHAR(255) NOT NULL,
descripcion TEXT,
version VARCHAR(20) DEFAULT '1.0',
scope VARCHAR(50) DEFAULT 'global',
project_id UUID REFERENCES task_projects(id) ON DELETE SET NULL,
activo BOOLEAN DEFAULT true,
metadata JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT chk_dataset_tipo CHECK (tipo IN ('knowledge', 'examples', 'rules', 'vocabulary', 'context', 'persona'))
);
CREATE INDEX IF NOT EXISTS idx_scontract_ds_codigo ON s_contract_datasets(codigo);
CREATE INDEX IF NOT EXISTS idx_scontract_ds_tipo ON s_contract_datasets(tipo);
CREATE INDEX IF NOT EXISTS idx_scontract_ds_activo ON s_contract_datasets(activo);
DROP TRIGGER IF EXISTS update_scontract_ds_updated_at ON s_contract_datasets;
CREATE TRIGGER update_scontract_ds_updated_at BEFORE UPDATE ON s_contract_datasets
FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
-- ============================================
-- FUNCIÓN: Convertir dataset a formato S-CONTRACT
-- ============================================
CREATE OR REPLACE FUNCTION dataset_to_scontract(p_dataset_id UUID)
RETURNS JSONB AS $$
SELECT jsonb_build_object(
'codigo', codigo,
'tipo', tipo,
'contenido', contenido,
'contenido_ref', contenido_ref
)
FROM s_contract_datasets
WHERE id = p_dataset_id AND activo = true;
$$ LANGUAGE SQL STABLE;
-- ============================================
-- FUNCIÓN: Obtener context block para S-CONTRACT
-- Devuelve EXACTAMENTE el formato de context en S-CONTRACT
-- ============================================
CREATE OR REPLACE FUNCTION get_scontract_context(p_context_codigo VARCHAR)
RETURNS JSONB AS $$
SELECT context
FROM s_contract_contexts
WHERE codigo = p_context_codigo AND activo = true;
$$ LANGUAGE SQL STABLE;
-- ============================================
-- FUNCIÓN: Obtener deployment block para S-CONTRACT
-- ============================================
CREATE OR REPLACE FUNCTION get_scontract_deployment(p_context_codigo VARCHAR)
RETURNS JSONB AS $$
SELECT deployment
FROM s_contract_contexts
WHERE codigo = p_context_codigo AND activo = true;
$$ LANGUAGE SQL STABLE;
-- ============================================
-- FUNCIÓN: Construir context con datasets expandidos
-- Útil cuando se quiere incluir datasets por código
-- ============================================
CREATE OR REPLACE FUNCTION build_scontract_context(
p_context_codigo VARCHAR,
p_dataset_codigos VARCHAR[] DEFAULT NULL
)
RETURNS JSONB AS $$
DECLARE
base_context JSONB;
datasets_array JSONB;
BEGIN
-- Obtener contexto base
SELECT context INTO base_context
FROM s_contract_contexts
WHERE codigo = p_context_codigo AND activo = true;
IF base_context IS NULL THEN
RETURN NULL;
END IF;
-- Si se especifican datasets, construir el array
IF p_dataset_codigos IS NOT NULL AND array_length(p_dataset_codigos, 1) > 0 THEN
SELECT jsonb_agg(
jsonb_build_object(
'codigo', d.codigo,
'tipo', d.tipo,
'contenido', d.contenido,
'contenido_ref', d.contenido_ref
)
)
INTO datasets_array
FROM s_contract_datasets d
WHERE d.codigo = ANY(p_dataset_codigos)
AND d.activo = true;
-- Reemplazar datasets en el contexto
base_context := jsonb_set(base_context, '{datasets}', COALESCE(datasets_array, '[]'::jsonb));
END IF;
RETURN base_context;
END;
$$ LANGUAGE plpgsql STABLE;
-- ============================================
-- FUNCIÓN: Actualizar campo específico del context
-- ============================================
CREATE OR REPLACE FUNCTION update_scontract_context_field(
p_context_codigo VARCHAR,
p_field_path TEXT[],
p_value JSONB
)
RETURNS BOOLEAN AS $$
BEGIN
UPDATE s_contract_contexts
SET context = jsonb_set(context, p_field_path, p_value),
updated_at = CURRENT_TIMESTAMP
WHERE codigo = p_context_codigo;
RETURN FOUND;
END;
$$ LANGUAGE plpgsql;
-- ============================================
-- Añadir FK en task_manager
-- ============================================
-- Eliminar columna antigua si existe
ALTER TABLE task_manager DROP COLUMN IF EXISTS context_id;
-- Añadir referencia al contexto S-CONTRACT
ALTER TABLE task_manager
ADD COLUMN IF NOT EXISTS scontract_context_codigo VARCHAR(100);
-- Añadir FK en task_projects
ALTER TABLE task_projects DROP COLUMN IF EXISTS default_context_id;
ALTER TABLE task_projects
ADD COLUMN IF NOT EXISTS default_scontract_context VARCHAR(100);
-- ============================================
-- DATOS INICIALES
-- ============================================
-- Contexto por defecto
INSERT INTO s_contract_contexts (codigo, nombre, descripcion, context, deployment) VALUES
(
'CTX_DEFAULT',
'Contexto por defecto',
'Contexto base para operaciones sin configuración específica',
'{
"lang": "es",
"mode": "strict",
"pii_filter": false,
"bandera_id": null,
"player_id": null,
"method_hash": null,
"human_readable": null,
"system_instruction": "Procesa la información recibida de forma precisa. Responde en español.",
"datasets": [],
"tags": {"hst": [], "hsu": [], "emp": [], "pjt": []},
"ambiente": {
"timezone": "Europe/Madrid",
"locale": "es-ES",
"currency": "EUR"
}
}'::jsonb,
'{
"mode": "SEMI",
"tier_preference": ["SELF_HOSTED", "EXTERNAL"]
}'::jsonb
),
(
'CTX_GRACE',
'Contexto para GRACE',
'Contexto optimizado para procesamiento GRACE',
'{
"lang": "es",
"mode": "strict",
"pii_filter": false,
"system_instruction": "Eres un asistente de procesamiento del sistema GRACE. Procesa los datos de forma estructurada y precisa. Si hay incertidumbre, indica el nivel de confianza.",
"datasets": [],
"tags": {"hst": [], "hsu": [], "emp": [], "pjt": []},
"ambiente": {
"timezone": "Europe/Madrid",
"locale": "es-ES"
}
}'::jsonb,
'{"mode": "SEMI", "tier_preference": ["SELF_HOSTED", "EXTERNAL"]}'::jsonb
),
(
'CTX_PENNY',
'Contexto para PENNY',
'Contexto optimizado para asistente de voz PENNY',
'{
"lang": "es",
"mode": "lenient",
"pii_filter": false,
"system_instruction": "Eres PENNY, un asistente de voz amable y eficiente. Responde de forma concisa (máximo 2-3 oraciones). Usa tono conversacional pero profesional.",
"datasets": [],
"tags": {"hst": [], "hsu": [], "emp": [], "pjt": []},
"ambiente": {
"timezone": "Europe/Madrid",
"locale": "es-ES",
"session_type": "interactive"
}
}'::jsonb,
'{"mode": "SEMI", "tier_preference": ["SELF_HOSTED", "EXTERNAL"]}'::jsonb
),
(
'CTX_FACTORY',
'Contexto para THE FACTORY',
'Contexto optimizado para procesamiento documental',
'{
"lang": "es",
"mode": "strict",
"pii_filter": true,
"system_instruction": "Eres un procesador de documentos de THE FACTORY. Extrae información de forma estructurada. Mantén fidelidad al documento original. Señala incertidumbres con [INCIERTO: razón].",
"datasets": [],
"tags": {"hst": [], "hsu": [], "emp": [], "pjt": []},
"ambiente": {
"timezone": "Europe/Madrid",
"locale": "es-ES",
"session_type": "batch"
}
}'::jsonb,
'{"mode": "SEMI", "tier_preference": ["EXTERNAL", "SELF_HOSTED"]}'::jsonb
)
ON CONFLICT (codigo) DO UPDATE SET
context = EXCLUDED.context,
deployment = EXCLUDED.deployment,
updated_at = CURRENT_TIMESTAMP;
-- Datasets base
INSERT INTO s_contract_datasets (codigo, nombre, tipo, contenido) VALUES
(
'DS_TZZR_ECOSYSTEM',
'Ecosistema TZZR',
'knowledge',
'TZZR es un ecosistema personal de productividad:
- DECK: Servidor central, iniciador de conexiones
- GRACE: Capa de procesamiento IA
- PENNY: Asistente de voz real-time
- THE FACTORY: Procesamiento documental
Sistema de etiquetas HST con h_maestro (SHA-256) como ID único.'
),
(
'DS_HST_INTRO',
'Introducción HST',
'vocabulary',
'Grupos de etiquetas HST:
- hst: Sistema (sync tzrtech.org)
- emp: Empresa
- hsu: Usuario
- pjt: Proyecto
Cada etiqueta tiene: codigo, nombre, descripcion, color, jerarquía.'
)
ON CONFLICT (codigo) DO UPDATE SET
contenido = EXCLUDED.contenido,
updated_at = CURRENT_TIMESTAMP;

View File

@@ -0,0 +1,277 @@
-- ============================================
-- LOG DE REQUESTS A SERVICIOS IA
-- Sistema TZZR - contratos-comunes
-- ============================================
-- Requiere: 00_types.sql, 02_task_manager.sql, 03_work_log.sql, 04_ai_context.sql
-- ============================================
-- TABLA: task_ai_requests
-- Registro de todas las requests a servicios IA
-- ============================================
CREATE TABLE IF NOT EXISTS task_ai_requests (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-- Trazabilidad S-CONTRACT
trace_id VARCHAR(64) NOT NULL, -- trace_id del S-CONTRACT
idempotency_key VARCHAR(64), -- Para deduplicación
step_id VARCHAR(64), -- ID del paso en cadena
step_index INTEGER, -- Posición en la cadena
-- Origen
task_id UUID REFERENCES task_manager(id) ON DELETE SET NULL,
work_log_id UUID REFERENCES task_work_log(id) ON DELETE SET NULL,
project_id UUID REFERENCES task_projects(id) ON DELETE SET NULL,
-- Destino
target_service ai_service NOT NULL,
target_module VARCHAR(50) NOT NULL, -- ASR_ENGINE, CLASSIFIER, OCR_CORE, etc.
-- Contexto usado
context_id UUID REFERENCES task_contexts(id) ON DELETE SET NULL,
context_snapshot JSONB, -- Snapshot del contexto en el momento
-- Deployment
deployment_mode deployment_mode,
tier_requested provider_tier,
tier_used provider_tier,
provider_used VARCHAR(50),
endpoint_used TEXT,
-- Request (sin contenido sensible)
request_summary JSONB, -- Resumen de la request
payload_type VARCHAR(50), -- text, audio, image, document
payload_size_bytes BIGINT,
payload_hash VARCHAR(64),
-- Response
status VARCHAR(20) NOT NULL, -- SUCCESS, PARTIAL, ERROR, TIMEOUT, FALLBACK
fallback_level INTEGER DEFAULT 0,
response_summary JSONB, -- Resumen de respuesta
output_schema VARCHAR(100),
output_hash VARCHAR(64),
-- Calidad
confidence DECIMAL(4,3),
coverage DECIMAL(4,3),
validation_passed BOOLEAN,
-- Métricas
latency_ms INTEGER,
queue_wait_ms INTEGER,
tokens_input INTEGER,
tokens_output INTEGER,
cost_usd DECIMAL(10,6),
-- Errores
error_code VARCHAR(50),
error_message TEXT,
retry_count INTEGER DEFAULT 0,
-- Timestamps
timestamp_init TIMESTAMP NOT NULL,
timestamp_end TIMESTAMP,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Índices principales
CREATE INDEX IF NOT EXISTS idx_ai_requests_trace ON task_ai_requests(trace_id);
CREATE INDEX IF NOT EXISTS idx_ai_requests_idempotency ON task_ai_requests(idempotency_key);
CREATE INDEX IF NOT EXISTS idx_ai_requests_task ON task_ai_requests(task_id);
CREATE INDEX IF NOT EXISTS idx_ai_requests_work_log ON task_ai_requests(work_log_id);
CREATE INDEX IF NOT EXISTS idx_ai_requests_project ON task_ai_requests(project_id);
CREATE INDEX IF NOT EXISTS idx_ai_requests_service ON task_ai_requests(target_service);
CREATE INDEX IF NOT EXISTS idx_ai_requests_module ON task_ai_requests(target_module);
CREATE INDEX IF NOT EXISTS idx_ai_requests_status ON task_ai_requests(status);
CREATE INDEX IF NOT EXISTS idx_ai_requests_fecha ON task_ai_requests(timestamp_init);
CREATE INDEX IF NOT EXISTS idx_ai_requests_tier ON task_ai_requests(tier_used);
CREATE INDEX IF NOT EXISTS idx_ai_requests_provider ON task_ai_requests(provider_used);
-- Índice para métricas temporales
CREATE INDEX IF NOT EXISTS idx_ai_requests_fecha_service ON task_ai_requests(timestamp_init, target_service);
-- ============================================
-- TABLA: task_ai_request_chain
-- Cadenas de requests relacionadas
-- ============================================
CREATE TABLE IF NOT EXISTS task_ai_request_chain (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-- Trace principal de la cadena
chain_trace_id VARCHAR(64) NOT NULL,
-- Request en la cadena
request_id UUID NOT NULL REFERENCES task_ai_requests(id) ON DELETE CASCADE,
-- Posición
chain_index INTEGER NOT NULL,
-- Dependencias (requests previas necesarias)
depends_on JSONB DEFAULT '[]', -- Array de request_ids
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT unique_chain_position UNIQUE(chain_trace_id, chain_index)
);
CREATE INDEX IF NOT EXISTS idx_request_chain_trace ON task_ai_request_chain(chain_trace_id);
CREATE INDEX IF NOT EXISTS idx_request_chain_request ON task_ai_request_chain(request_id);
-- ============================================
-- VISTAS DE MÉTRICAS
-- ============================================
-- Vista: Métricas por servicio (últimos 30 días)
CREATE OR REPLACE VIEW v_ai_metrics_by_service AS
SELECT
target_service,
target_module,
COUNT(*) AS total_requests,
COUNT(*) FILTER (WHERE status = 'SUCCESS') AS successful,
COUNT(*) FILTER (WHERE status = 'ERROR') AS errors,
COUNT(*) FILTER (WHERE status = 'FALLBACK') AS fallbacks,
ROUND(AVG(latency_ms)::numeric, 2) AS avg_latency_ms,
ROUND(PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency_ms)::numeric, 2) AS p95_latency_ms,
SUM(cost_usd) AS total_cost_usd,
SUM(tokens_input) AS total_tokens_in,
SUM(tokens_output) AS total_tokens_out,
ROUND(AVG(confidence)::numeric, 3) AS avg_confidence
FROM task_ai_requests
WHERE timestamp_init > CURRENT_DATE - INTERVAL '30 days'
GROUP BY target_service, target_module
ORDER BY total_requests DESC;
-- Vista: Métricas por tier
CREATE OR REPLACE VIEW v_ai_metrics_by_tier AS
SELECT
tier_used,
provider_used,
COUNT(*) AS total_requests,
COUNT(*) FILTER (WHERE status = 'SUCCESS') AS successful,
ROUND(AVG(latency_ms)::numeric, 2) AS avg_latency_ms,
SUM(cost_usd) AS total_cost_usd
FROM task_ai_requests
WHERE timestamp_init > CURRENT_DATE - INTERVAL '30 days'
AND tier_used IS NOT NULL
GROUP BY tier_used, provider_used
ORDER BY total_requests DESC;
-- Vista: Costos diarios
CREATE OR REPLACE VIEW v_ai_daily_costs AS
SELECT
DATE(timestamp_init) AS fecha,
target_service,
COUNT(*) AS requests,
SUM(cost_usd) AS cost_usd,
SUM(tokens_input) AS tokens_in,
SUM(tokens_output) AS tokens_out
FROM task_ai_requests
WHERE timestamp_init > CURRENT_DATE - INTERVAL '30 days'
GROUP BY DATE(timestamp_init), target_service
ORDER BY fecha DESC, cost_usd DESC;
-- Vista: Errores recientes
CREATE OR REPLACE VIEW v_ai_recent_errors AS
SELECT
id,
trace_id,
target_service,
target_module,
status,
error_code,
error_message,
provider_used,
tier_used,
timestamp_init
FROM task_ai_requests
WHERE status IN ('ERROR', 'TIMEOUT')
AND timestamp_init > CURRENT_DATE - INTERVAL '7 days'
ORDER BY timestamp_init DESC
LIMIT 100;
-- ============================================
-- FUNCIÓN: Registrar request de S-CONTRACT
-- ============================================
CREATE OR REPLACE FUNCTION log_ai_request(
p_trace_id VARCHAR(64),
p_service ai_service,
p_module VARCHAR(50),
p_context_id UUID DEFAULT NULL,
p_task_id UUID DEFAULT NULL,
p_work_log_id UUID DEFAULT NULL
)
RETURNS UUID AS $$
DECLARE
new_id UUID;
ctx_snapshot JSONB;
BEGIN
-- Obtener snapshot del contexto si existe
IF p_context_id IS NOT NULL THEN
ctx_snapshot := build_ai_context(p_context_id);
END IF;
INSERT INTO task_ai_requests (
trace_id,
target_service,
target_module,
context_id,
context_snapshot,
task_id,
work_log_id,
status,
timestamp_init
) VALUES (
p_trace_id,
p_service,
p_module,
p_context_id,
ctx_snapshot,
p_task_id,
p_work_log_id,
'pending',
CURRENT_TIMESTAMP
)
RETURNING id INTO new_id;
RETURN new_id;
END;
$$ LANGUAGE plpgsql;
-- ============================================
-- FUNCIÓN: Actualizar request completada
-- ============================================
CREATE OR REPLACE FUNCTION complete_ai_request(
p_request_id UUID,
p_status VARCHAR(20),
p_tier_used provider_tier,
p_provider VARCHAR(50),
p_latency_ms INTEGER,
p_tokens_in INTEGER DEFAULT NULL,
p_tokens_out INTEGER DEFAULT NULL,
p_cost_usd DECIMAL(10,6) DEFAULT NULL,
p_confidence DECIMAL(4,3) DEFAULT NULL,
p_error_code VARCHAR(50) DEFAULT NULL,
p_error_message TEXT DEFAULT NULL
)
RETURNS VOID AS $$
BEGIN
UPDATE task_ai_requests
SET
status = p_status,
tier_used = p_tier_used,
provider_used = p_provider,
latency_ms = p_latency_ms,
tokens_input = p_tokens_in,
tokens_output = p_tokens_out,
cost_usd = p_cost_usd,
confidence = p_confidence,
error_code = p_error_code,
error_message = p_error_message,
timestamp_end = CURRENT_TIMESTAMP
WHERE id = p_request_id;
END;
$$ LANGUAGE plpgsql;

View File

@@ -0,0 +1,50 @@
-- Inicialización de la base de datos para CLARA
-- Servicio inmutable de log de entrada
-- Tabla principal: clara_log
CREATE TABLE IF NOT EXISTS clara_log (
id BIGSERIAL PRIMARY KEY,
h_instancia VARCHAR(64) NOT NULL,
h_entrada VARCHAR(64) NOT NULL,
contenedor JSONB NOT NULL,
r2_paths JSONB,
created_at TIMESTAMP DEFAULT NOW()
);
-- Índices para búsqueda eficiente
CREATE INDEX IF NOT EXISTS idx_clara_instancia ON clara_log(h_instancia);
CREATE INDEX IF NOT EXISTS idx_clara_entrada ON clara_log(h_entrada);
CREATE INDEX IF NOT EXISTS idx_clara_created ON clara_log(created_at DESC);
-- Índice para buscar por estado del contenedor
CREATE INDEX IF NOT EXISTS idx_clara_estado ON clara_log((contenedor->'estado'->>'actual'));
-- Índice para buscar por timestamp de captura
CREATE INDEX IF NOT EXISTS idx_clara_timestamp ON clara_log((contenedor->'origen'->>'timestamp_captura'));
-- Índice compuesto para búsquedas frecuentes
CREATE INDEX IF NOT EXISTS idx_clara_inst_entrada ON clara_log(h_instancia, h_entrada);
-- Vista para consultas comunes
CREATE OR REPLACE VIEW clara_summary AS
SELECT
id,
h_instancia,
h_entrada,
contenedor->>'id' as contenedor_id,
contenedor->'origen'->>'timestamp_captura' as timestamp_captura,
contenedor->'archivo'->>'tipo' as tipo_archivo,
contenedor->'archivo'->>'categoria' as categoria,
contenedor->'estado'->>'actual' as estado_actual,
jsonb_array_length(COALESCE(contenedor->'tags', '[]'::jsonb)) as num_tags,
created_at
FROM clara_log
ORDER BY id DESC;
-- Comentarios para documentación
COMMENT ON TABLE clara_log IS 'Log inmutable de contenedores recibidos de PACKET';
COMMENT ON COLUMN clara_log.h_instancia IS 'Hash de identificación de la instancia DECK';
COMMENT ON COLUMN clara_log.h_entrada IS 'Hash del archivo (sha256)';
COMMENT ON COLUMN clara_log.contenedor IS 'Contenedor completo según esquema de contratos-comunes';
COMMENT ON COLUMN clara_log.r2_paths IS 'Rutas de los archivos en Cloudflare R2';
COMMENT ON COLUMN clara_log.created_at IS 'Timestamp de recepción (inmutable)';

View File

@@ -0,0 +1,123 @@
-- Los Libros Contables - FELDMAN v2.0
-- Tablas para milestones, bloques y validaciones
-- MILESTONES
CREATE TABLE IF NOT EXISTS milestones (
id BIGSERIAL PRIMARY KEY,
h_milestone VARCHAR(64) NOT NULL UNIQUE,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64) NOT NULL,
alias VARCHAR(200) NOT NULL,
tipo_item VARCHAR(50) NOT NULL,
descripcion TEXT,
datos JSONB DEFAULT '{}',
etiqueta_principal VARCHAR(64),
proyecto_tag VARCHAR(64),
id_padre_milestone BIGINT REFERENCES milestones(id),
id_bloque_asociado BIGINT,
blockchain_pending BOOLEAN DEFAULT TRUE,
blockchain_tx_ref VARCHAR(128),
notario_batch_id VARCHAR(64),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
created_by VARCHAR(64),
CONSTRAINT milestone_secuencia_unica UNIQUE (h_instancia, secuencia)
);
-- BLOQUES
CREATE TABLE IF NOT EXISTS bloques (
id BIGSERIAL PRIMARY KEY,
h_bloque VARCHAR(64) NOT NULL UNIQUE,
h_instancia VARCHAR(64) NOT NULL,
secuencia BIGINT NOT NULL,
hash_previo VARCHAR(64),
hash_contenido VARCHAR(64) NOT NULL,
alias VARCHAR(200) NOT NULL,
tipo_accion VARCHAR(50) NOT NULL,
descripcion TEXT,
datos JSONB DEFAULT '{}',
evidencia_hash VARCHAR(64) NOT NULL,
evidencia_url VARCHAR(500) NOT NULL,
evidencia_tipo VARCHAR(50) NOT NULL,
etiqueta_principal VARCHAR(64),
proyecto_tag VARCHAR(64),
id_padre_bloque BIGINT REFERENCES bloques(id),
id_milestone_asociado BIGINT REFERENCES milestones(id),
blockchain_pending BOOLEAN DEFAULT TRUE,
blockchain_tx_ref VARCHAR(128),
notario_batch_id VARCHAR(64),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
created_by VARCHAR(64),
CONSTRAINT bloque_secuencia_unica UNIQUE (h_instancia, secuencia)
);
-- COLA DE VALIDACION
CREATE TABLE IF NOT EXISTS feldman_cola (
id BIGSERIAL PRIMARY KEY,
h_entrada VARCHAR(64) NOT NULL UNIQUE,
h_instancia VARCHAR(64) NOT NULL,
origen VARCHAR(50) NOT NULL,
h_origen VARCHAR(64),
tipo_destino VARCHAR(20) NOT NULL,
datos JSONB NOT NULL,
estado VARCHAR(20) DEFAULT 'pendiente',
error_mensaje TEXT,
intentos INT DEFAULT 0,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
processed_at TIMESTAMP
);
-- VALIDACIONES
CREATE TABLE IF NOT EXISTS feldman_validaciones (
id BIGSERIAL PRIMARY KEY,
h_entrada VARCHAR(64) NOT NULL,
validacion_ok BOOLEAN NOT NULL,
reglas_aplicadas JSONB NOT NULL,
tipo_registro VARCHAR(20),
h_registro VARCHAR(64),
validated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- INDICES
CREATE INDEX IF NOT EXISTS idx_milestones_pending ON milestones(blockchain_pending) WHERE blockchain_pending = TRUE;
CREATE INDEX IF NOT EXISTS idx_bloques_pending ON bloques(blockchain_pending) WHERE blockchain_pending = TRUE;
CREATE INDEX IF NOT EXISTS idx_milestones_proyecto ON milestones(proyecto_tag);
CREATE INDEX IF NOT EXISTS idx_bloques_proyecto ON bloques(proyecto_tag);
CREATE INDEX IF NOT EXISTS idx_feldman_estado ON feldman_cola(estado);
CREATE INDEX IF NOT EXISTS idx_feldman_instancia ON feldman_cola(h_instancia);
-- FUNCIONES
CREATE OR REPLACE FUNCTION get_ultimo_hash_milestone(p_h_instancia VARCHAR)
RETURNS VARCHAR AS $$
DECLARE v_hash VARCHAR;
BEGIN
SELECT hash_contenido INTO v_hash FROM milestones
WHERE h_instancia = p_h_instancia ORDER BY secuencia DESC LIMIT 1;
RETURN COALESCE(v_hash, 'GENESIS');
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION get_ultimo_hash_bloque(p_h_instancia VARCHAR)
RETURNS VARCHAR AS $$
DECLARE v_hash VARCHAR;
BEGIN
SELECT hash_contenido INTO v_hash FROM bloques
WHERE h_instancia = p_h_instancia ORDER BY secuencia DESC LIMIT 1;
RETURN COALESCE(v_hash, 'GENESIS');
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION get_siguiente_secuencia_milestone(p_h_instancia VARCHAR)
RETURNS BIGINT AS $$
BEGIN
RETURN (SELECT COALESCE(MAX(secuencia), 0) + 1 FROM milestones WHERE h_instancia = p_h_instancia);
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION get_siguiente_secuencia_bloque(p_h_instancia VARCHAR)
RETURNS BIGINT AS $$
BEGIN
RETURN (SELECT COALESCE(MAX(secuencia), 0) + 1 FROM bloques WHERE h_instancia = p_h_instancia);
END;
$$ LANGUAGE plpgsql;

View File

@@ -0,0 +1,36 @@
-- ALFRED - Flujos Predefinidos
-- Deploy en DECK PostgreSQL
-- Flujos predefinidos
CREATE TABLE IF NOT EXISTS flujos_predefinidos (
id VARCHAR(64) PRIMARY KEY,
h_instancia VARCHAR(64) NOT NULL,
nombre VARCHAR(100) NOT NULL,
descripcion TEXT,
pasos JSONB NOT NULL,
campos_fijos JSONB DEFAULT '{}',
campos_variables JSONB DEFAULT '[]',
activo BOOLEAN DEFAULT true,
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
-- Ejecuciones de flujos
CREATE TABLE IF NOT EXISTS flujo_ejecuciones (
id BIGSERIAL PRIMARY KEY,
h_flujo VARCHAR(64) REFERENCES flujos_predefinidos(id),
h_instancia VARCHAR(64) NOT NULL,
h_ejecucion VARCHAR(64) NOT NULL UNIQUE,
datos JSONB NOT NULL,
estado VARCHAR(20) DEFAULT 'ok',
destino VARCHAR(20) DEFAULT 'feldman',
notas TEXT,
created_at TIMESTAMP DEFAULT NOW()
);
-- Indices
CREATE INDEX IF NOT EXISTS idx_flujos_h_instancia ON flujos_predefinidos(h_instancia);
CREATE INDEX IF NOT EXISTS idx_flujos_activo ON flujos_predefinidos(activo);
CREATE INDEX IF NOT EXISTS idx_ejecuciones_h_flujo ON flujo_ejecuciones(h_flujo);
CREATE INDEX IF NOT EXISTS idx_ejecuciones_estado ON flujo_ejecuciones(estado);
CREATE INDEX IF NOT EXISTS idx_ejecuciones_created ON flujo_ejecuciones(created_at DESC);

View File

@@ -0,0 +1,70 @@
-- 10_user_units.sql
-- Tablas de unidades de usuario por tipo
-- Version: 1.0
-- Fecha: 2025-12-30
-- HSU: Host Service Unit (usuarios de servicio host)
CREATE TABLE IF NOT EXISTS hsu (
id SERIAL PRIMARY KEY,
ref VARCHAR(10) NOT NULL UNIQUE,
h_usuario VARCHAR(64) NOT NULL UNIQUE,
nombre VARCHAR(255),
user_id INTEGER NOT NULL,
activo BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT NOW()
);
-- PJU: Project Unit (usuarios de proyecto)
CREATE TABLE IF NOT EXISTS pju (
id SERIAL PRIMARY KEY,
ref VARCHAR(10) NOT NULL UNIQUE,
h_usuario VARCHAR(64) NOT NULL UNIQUE,
nombre VARCHAR(255),
user_id INTEGER NOT NULL,
activo BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT NOW()
);
-- SPU: Service Process Unit (usuarios de proceso de servicio)
CREATE TABLE IF NOT EXISTS spu (
id SERIAL PRIMARY KEY,
ref VARCHAR(10) NOT NULL UNIQUE,
h_usuario VARCHAR(64) NOT NULL UNIQUE,
nombre VARCHAR(255),
user_id INTEGER NOT NULL,
activo BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT NOW()
);
-- VSU: Version Service Unit (usuarios de servicio de version)
CREATE TABLE IF NOT EXISTS vsu (
id SERIAL PRIMARY KEY,
ref VARCHAR(10) NOT NULL UNIQUE,
h_usuario VARCHAR(64) NOT NULL UNIQUE,
nombre VARCHAR(255),
user_id INTEGER NOT NULL,
activo BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT NOW()
);
-- VUU: Version Update Unit (usuarios de actualizacion de version)
CREATE TABLE IF NOT EXISTS vuu (
id SERIAL PRIMARY KEY,
ref VARCHAR(10) NOT NULL UNIQUE,
h_usuario VARCHAR(64) NOT NULL UNIQUE,
nombre VARCHAR(255),
user_id INTEGER NOT NULL,
activo BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT NOW()
);
-- FLU: Flow Unit (usuarios de flujo)
CREATE TABLE IF NOT EXISTS flu (
id SERIAL PRIMARY KEY,
ref VARCHAR(10) NOT NULL UNIQUE,
h_usuario VARCHAR(64) NOT NULL UNIQUE,
nombre VARCHAR(255),
user_id INTEGER NOT NULL,
activo BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT NOW()
);

View File

@@ -0,0 +1,40 @@
-- 11_sync.sql
-- Tablas de sincronizacion y notificaciones
-- Version: 1.0
-- Fecha: 2025-12-30
-- HST_MIRROR: Espejo de entidades HST para sincronizacion local
CREATE TABLE IF NOT EXISTS hst_mirror (
id SERIAL PRIMARY KEY,
ref VARCHAR(100) NOT NULL UNIQUE,
h_maestro VARCHAR(64) NOT NULL UNIQUE,
nombre_es VARCHAR(255),
nombre_en VARCHAR(255),
grupo VARCHAR(50),
hst_subdominio VARCHAR(255),
hst_ruta VARCHAR(255),
local_subdominio VARCHAR(255) DEFAULT NULL,
local_ruta VARCHAR(255) DEFAULT NULL,
activo BOOLEAN DEFAULT TRUE,
hst_activo BOOLEAN DEFAULT TRUE,
sincronizado_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX IF NOT EXISTS idx_hst_mirror_h_maestro ON hst_mirror(h_maestro);
CREATE INDEX IF NOT EXISTS idx_hst_mirror_ref ON hst_mirror(ref);
-- NOTIFICATION: Sistema de notificaciones
CREATE TABLE IF NOT EXISTS notification (
id VARCHAR(20) PRIMARY KEY,
type VARCHAR(40),
body TEXT,
is_read BOOLEAN DEFAULT FALSE,
is_deleted BOOLEAN DEFAULT FALSE,
fk_user_id VARCHAR(20),
created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX IF NOT EXISTS notification_created_at_index ON notification(created_at);
CREATE INDEX IF NOT EXISTS notification_fk_user_id_index ON notification(fk_user_id);

View File

@@ -0,0 +1,86 @@
# Schemas SQL
**Versión:** 1.0
**Estado:** Implementado
---
## Archivos
| Archivo | Descripción | Tablas |
|---------|-------------|--------|
| 00_types.sql | Tipos y enums | task_status, task_priority, file_direction, ai_service, hst_grupo, deployment_mode |
| 01_hst_tags.sql | Tags semánticos | hst_tags, hst_biblioteca |
| 02_task_manager.sql | Gestión de tareas | tasks, task_dependencies, task_comments |
| 03_work_log.sql | Log de trabajo | work_log, work_log_files |
| 04_ai_context.sql | Contexto IA | ai_context_blocks, ai_context_datasets |
| 05_ai_requests.sql | Peticiones IA | ai_requests, ai_responses |
| 06_clara.sql | Clara (secretaría) | clara_log, clara_summary (vista) |
| 07_feldman.sql | Feldman (contable) | milestones, bloques, feldman_cola, feldman_validaciones |
| 08_alfred.sql | Alfred (producción) | flujos_predefinidos, flujo_ejecuciones |
| 10_user_units.sql | Unidades de usuario | hsu, pju, spu, vsu, vuu, flu |
| 11_sync.sql | Sincronización | hst_mirror, notification |
---
## Orden de Aplicación
```bash
# Aplicar en este orden
psql -U tzzr -d tzzr -f 00_types.sql
psql -U tzzr -d tzzr -f 01_hst_tags.sql
psql -U tzzr -d tzzr -f 02_task_manager.sql
psql -U tzzr -d tzzr -f 03_work_log.sql
psql -U tzzr -d tzzr -f 04_ai_context.sql
psql -U tzzr -d tzzr -f 05_ai_requests.sql
psql -U tzzr -d tzzr -f 06_clara.sql
psql -U tzzr -d tzzr -f 07_feldman.sql
psql -U tzzr -d tzzr -f 08_alfred.sql
psql -U tzzr -d tzzr -f 10_user_units.sql
psql -U tzzr -d tzzr -f 11_sync.sql
```
---
## Tipos Enumerados (00_types.sql)
```sql
-- Estados de tarea
CREATE TYPE task_status AS ENUM (
'draft', 'pending', 'in_progress',
'blocked', 'review', 'completed', 'cancelled'
);
-- Prioridad de tarea
CREATE TYPE task_priority AS ENUM (
'critical', 'high', 'medium', 'low', 'someday'
);
-- Dirección de archivo
CREATE TYPE file_direction AS ENUM (
'inbound', 'outbound', 'internal', 'reference'
);
-- Servicios IA
CREATE TYPE ai_service AS ENUM (
'grace', 'penny', 'factory'
);
-- Grupos HST
CREATE TYPE hst_grupo AS ENUM (
'hst', 'emp', 'hsu', 'pjt'
);
-- Modo despliegue
CREATE TYPE deployment_mode AS ENUM (
'EXTERNAL', 'SELF_HOSTED', 'SEMI'
);
```
---
## Notas
- Todos los schemas usan `DO $$ BEGIN ... EXCEPTION ... END $$` para ser idempotentes
- Función `update_updated_at_column()` actualiza `updated_at` automáticamente
- Los SQL están en `/schemas/` junto a este README

View File

@@ -0,0 +1,77 @@
# R2 Proxy - Configuración Multi-Bucket
**Fecha:** 2026-01-19
**Servidor:** DECK (72.62.1.113)
**Servicio:** r2-proxy (systemd)
## Descripción
Proxy Flask que sirve archivos desde múltiples buckets de Cloudflare R2, cada uno con sus propias credenciales compartimentadas.
## Ubicación
```
/opt/r2-proxy/
├── app.py # Código del proxy
├── .env # Credenciales (no commitear)
└── venv/ # Entorno virtual Python
```
## Buckets Configurados
| Bucket | Credencial | Uso |
|--------|------------|-----|
| `deck` | DECK_ACCESS_KEY/SECRET | Archivos DECK (thumbs, PDFs, attachments) |
| `personaldeck` | PERSONALDECK_ACCESS_KEY/SECRET | Archivos personales |
## Endpoints
```
GET /health → Estado del servicio
GET /<path> → Archivo del bucket por defecto (deck)
GET /deck/<path> → Archivo explícito de bucket deck
GET /personaldeck/<path> → Archivo de bucket personaldeck
```
## Configuración Caddy
```
atc.tzzrdeck.me {
header {
Cache-Control "public, max-age=31536000, immutable"
Access-Control-Allow-Origin *
}
reverse_proxy localhost:8090
}
```
## Credenciales
Almacenadas en `/opt/r2-proxy/.env`:
```
DECK_ACCESS_KEY=xxx
DECK_SECRET_KEY=xxx
PERSONALDECK_ACCESS_KEY=xxx
PERSONALDECK_SECRET_KEY=xxx
```
**Fuente de verdad:** `tzzr_system.keys` (PostgreSQL en DECK)
## Comandos
```bash
# Reiniciar servicio
systemctl restart r2-proxy
# Ver logs
journalctl -u r2-proxy -f
# Test health
curl http://localhost:8090/health
```
## Notas
- Cada bucket tiene credenciales separadas (compartimentación)
- Bucket `architect` NO está configurado aquí (solo para backups RunPod)
- El bucket por defecto es `deck` para compatibilidad con URLs existentes

View File

@@ -0,0 +1,64 @@
# Nextcloud - Sistema de Almacenamiento
## Instancias
| Servidor | URL | Usuario | Symlink Local |
|----------|-----|---------|---------------|
| ARCHITECT | cloud.tzzrarchitect.me | architect | /nextc_architect → files/ |
| DECK | cloud.tzzrdeck.me | deck | /nextc_deck → bandeja de salida/ |
| HST | cloud.tzrtech.org | hst | /nextc_hst → files/ |
## Arquitectura
Cada instancia corre en Docker:
- `nextcloud:32` - Servidor Nextcloud
- `postgres:16-alpine` - Base de datos
- `redis:7-alpine` - Cache
Los datos se almacenan en volúmenes Docker:
```
/var/lib/docker/volumes/nextcloud_nextcloud-data/_data/data/{usuario}/files/
```
Los symlinks `/nextc_*` apuntan directamente a estas carpetas para acceso rápido desde scripts.
## Configuración Caddy
```caddyfile
# ARCHITECT
cloud.tzzrarchitect.me {
reverse_proxy localhost:8085
}
# DECK
cloud.tzzrdeck.me {
reverse_proxy localhost:8084
}
# HST
cloud.tzrtech.org {
reverse_proxy localhost:8084
}
```
## Comandos Útiles
```bash
# Escanear archivos de usuario
docker exec -u www-data nextcloud php occ files:scan {usuario}
# Listar usuarios
docker exec nextcloud php occ user:list
# Ver configuración
docker exec nextcloud php occ config:list
```
## Convenciones de Nombres
Todos los archivos siguen el formato: `yymmdd_nombre_archivo.ext`
- yy: año (2 dígitos)
- mm: mes
- dd: día
Caracteres especiales (acentos) se convierten a ASCII para compatibilidad.

View File

@@ -0,0 +1,59 @@
# 04 - Infraestructura
> Servidores, despliegue, backup y recuperación
## Contenido
| Documento | Descripción |
|-----------|-------------|
| [architect.md](architect.md) | Servidor central - Gitea, PostgreSQL, Infisical |
| [despliegue.md](despliegue.md) | Guías docker-compose, fases, checklists |
| [backup-recovery.md](backup-recovery.md) | Estrategia DR, scripts de backup |
| [status.md](status.md) | Estado actual de servicios |
## Servidores
| Nombre | IP | SSH | Rol |
|--------|----|----|-----|
| **Architect** | 69.62.126.110 | - | Central (Gitea, PostgreSQL, coordinación) |
| **Deck** | 72.62.1.113 | `root@72.62.1.113` | Servidor personal |
| **Corp** | 92.112.181.188 | `root@92.112.181.188` | Servidor empresarial |
| **HST** | 72.62.2.84 | `root@72.62.2.84` | Hash Semantic Tagging |
## Servicios por Servidor
### Architect (Central)
- Gitea (gestión de código)
- PostgreSQL (base de datos)
- Infisical (gestión de secretos)
- Coordinación de agentes
### Deck / Corp
- Agentes locales (Clara/Margaret, Alfred/Jared)
- Base de datos local
- Sincronización con central
## Almacenamiento R2
**Endpoint**: `https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com`
| Bucket | Uso |
|--------|-----|
| `documentos adjuntos/` | Documentos compartidos |
| `system/` | Configs y backups internos |
| `gpu-services/` | GRACE/PENNY/FACTORY |
| `backups/` | Backups Gitea y sistema |
| `auditorias/` | Logs de auditoría |
## Stack Tecnológico
- **Contenedores**: Docker + docker-compose
- **Base de datos**: PostgreSQL 16
- **Código**: Gitea
- **Secretos**: Infisical
- **Storage**: Cloudflare R2
- **GPU**: RunPod (para servicios IA)
---
[← Volver al índice](../README.md)

View File

@@ -0,0 +1,83 @@
# ARCHITECT
**Tipo:** Servidor Central
**Estado:** Operativo
---
## Descripción
Coordinador central del ecosistema. Contiene servicios compartidos y actúa como hub de desarrollo y despliegue.
---
## Servicios
| Servicio | Puerto | Función |
|----------|--------|---------|
| PostgreSQL | 5432 | Base de datos central |
| Gitea | 3000 | Repositorios Git |
| Infisical | 8082 | Gestión de secretos |
| Orchestrator | 5000 | Coordinación multi-agente |
---
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ ARCHITECT │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ PostgreSQL │ │ Gitea │ │ Infisical │ │
│ │ (datos) │ │ (repos) │ │ (secretos) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Orchestrator│ │ Backups │ │
│ │ (agentes) │ │ (R2) │ │
│ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Repositorios Gitea
| Categoría | Repos |
|-----------|-------|
| **tzzr/** | system-docs, architect, deck, corp, hst, etc. |
| **admin/** | architect-app, data-structures, credentials |
---
## Infisical
Gestor centralizado de secretos.
| Parámetro | Valor |
|-----------|-------|
| Proyectos | anthropic, servers, databases, r2 |
| Acceso | Machine Identities por cada instancia |
---
## Función
ARCHITECT es un **constructor de arquitecturas**, no un gestor permanente:
1. Diseña y construye la arquitectura de cada servidor
2. Despliega configuraciones
3. Mantiene repositorios
4. Las instancias (DECK, CORP) funcionan independientemente
---
## Backups
| Destino | Frecuencia | Contenido |
|---------|------------|-----------|
| R2 (architect) | Diario | PostgreSQL, Gitea |
| R2 (gitea) | Por commit | Repos bare |

View File

@@ -0,0 +1,131 @@
# Backup y Recovery
**Versión:** 1.0
**Estado:** Definición
---
## Estrategia
| Tipo | Frecuencia | Retención | Destino |
|------|------------|-----------|---------|
| **PostgreSQL** | Diario | 30 días | R2 |
| **Gitea repos** | Por commit | Indefinido | R2 |
| **Archivos** | Diario | 30 días | R2 |
| **Configuración** | Por cambio | Indefinido | Gitea |
---
## Backup PostgreSQL
### Script
```bash
#!/bin/bash
# backup-postgres.sh
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="postgres_backup_${DATE}.sql.gz"
# Dump
pg_dump -U $DB_USER -h $DB_HOST $DB_NAME | gzip > /tmp/$BACKUP_FILE
# Upload a R2
aws s3 cp /tmp/$BACKUP_FILE s3://$R2_BUCKET/backups/postgres/$BACKUP_FILE \
--endpoint-url $R2_ENDPOINT
# Limpiar local
rm /tmp/$BACKUP_FILE
# Limpiar antiguos (>30 días)
aws s3 ls s3://$R2_BUCKET/backups/postgres/ --endpoint-url $R2_ENDPOINT | \
while read -r line; do
createDate=$(echo $line | awk '{print $1}')
if [[ $(date -d "$createDate" +%s) -lt $(date -d "30 days ago" +%s) ]]; then
fileName=$(echo $line | awk '{print $4}')
aws s3 rm s3://$R2_BUCKET/backups/postgres/$fileName --endpoint-url $R2_ENDPOINT
fi
done
```
### Cron
```bash
0 3 * * * /opt/scripts/backup-postgres.sh
```
---
## Recovery PostgreSQL
```bash
# Descargar backup
aws s3 cp s3://$R2_BUCKET/backups/postgres/$BACKUP_FILE /tmp/ \
--endpoint-url $R2_ENDPOINT
# Restaurar
gunzip -c /tmp/$BACKUP_FILE | psql -U $DB_USER -h $DB_HOST $DB_NAME
```
---
## Backup Gitea
Los repositorios bare se sincronizan automáticamente a R2:
```bash
#!/bin/bash
# backup-gitea.sh
rsync -av /var/lib/gitea/git/repositories/ /tmp/gitea_repos/
tar -czf /tmp/gitea_backup_$(date +%Y%m%d).tar.gz -C /tmp gitea_repos/
aws s3 cp /tmp/gitea_backup_*.tar.gz s3://$R2_BUCKET/backups/gitea/ \
--endpoint-url $R2_ENDPOINT
```
---
## Disaster Recovery
### Escenario: Pérdida total del servidor
1. Aprovisionar nuevo servidor
2. Instalar Docker
3. Clonar repos de configuración desde R2/Gitea backup
4. Restaurar PostgreSQL desde R2
5. `docker-compose up -d`
6. Verificar servicios
7. Actualizar DNS
### RTO/RPO
| Métrica | Objetivo |
|---------|----------|
| **RPO** (Recovery Point Objective) | 24 horas |
| **RTO** (Recovery Time Objective) | 4 horas |
---
## Verificación de Backups
```bash
# Verificar integridad mensualmente
#!/bin/bash
# Descargar último backup
LATEST=$(aws s3 ls s3://$R2_BUCKET/backups/postgres/ --endpoint-url $R2_ENDPOINT | tail -1 | awk '{print $4}')
aws s3 cp s3://$R2_BUCKET/backups/postgres/$LATEST /tmp/ --endpoint-url $R2_ENDPOINT
# Restaurar en BD temporal
createdb -U $DB_USER test_restore
gunzip -c /tmp/$LATEST | psql -U $DB_USER test_restore
# Verificar tablas
psql -U $DB_USER test_restore -c "\dt"
# Limpiar
dropdb -U $DB_USER test_restore
```

View File

@@ -0,0 +1,126 @@
# Despliegue
**Versión:** 1.0
**Estado:** Definición
---
## Stack Tecnológico
| Componente | Tecnología |
|------------|------------|
| Contenedores | Docker + Docker Compose |
| Base de datos | PostgreSQL |
| Cache | Redis |
| Proxy | Caddy |
| Orquestación | Windmill |
---
## Docker Compose Base
```yaml
version: '3.8'
services:
postgres:
image: postgres:15
environment:
POSTGRES_USER: ${DB_USER}
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_DB: ${DB_NAME}
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${DB_USER}"]
interval: 10s
timeout: 5s
retries: 5
redis:
image: redis:7-alpine
volumes:
- redis_data:/data
caddy:
image: caddy:2-alpine
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy_data:/data
volumes:
postgres_data:
redis_data:
caddy_data:
```
---
## Checklist de Despliegue
### Pre-despliegue
- [ ] Servidor aprovisionado
- [ ] DNS configurado
- [ ] Secretos en Infisical
- [ ] Backup de datos existentes
### Despliegue
- [ ] Clonar repositorio
- [ ] Copiar .env desde Infisical
- [ ] `docker-compose up -d`
- [ ] Verificar healthchecks
- [ ] Aplicar schemas SQL
### Post-despliegue
- [ ] Verificar servicios
- [ ] Configurar backups
- [ ] Test de endpoints
- [ ] Documentar IPs y puertos
---
## Variables de Entorno
```bash
# Base de datos
DB_HOST=localhost
DB_PORT=5432
DB_USER=tzzr
DB_PASSWORD=****
DB_NAME=tzzr
# Redis
REDIS_URL=redis://localhost:6379
# R2 Storage
R2_ENDPOINT=https://{account}.r2.cloudflarestorage.com
R2_ACCESS_KEY=****
R2_SECRET_KEY=****
R2_BUCKET=****
# Servicios externos
ANTHROPIC_API_KEY=****
RUNPOD_API_KEY=****
```
---
## Rollback
```bash
# Parar servicios
docker-compose down
# Restaurar backup
pg_restore -U tzzr -d tzzr backup.dump
# Volver a versión anterior
git checkout {commit_anterior}
docker-compose up -d
```

View File

@@ -0,0 +1,153 @@
# 04_INFRAESTRUCTURA
**Versión:** 10.1
**Fecha:** 22 Enero 2026
**Sistema:** TZZR
---
# Servidores
## Resumen
| Servidor | IP | Propósito |
|----------|-----|-----------|
| **ARCHITECT** | 69.62.126.110 | Desarrollo |
| **PABLO** | 72.62.115.124 | Usuario - Producción |
| **MODELO CERO** | 72.62.1.113 | Plantilla - Desarrollo |
| **CORP** | 92.112.181.188 | Corporativo |
| **HST** | 72.62.2.84 | API tags semánticos |
---
## ARCHITECT
**IP:** 69.62.126.110
| Servicio | Puerto | Función |
|----------|--------|---------|
| PostgreSQL | 5432 | Base de datos central |
| Gitea | 3000 | Repositorios Git |
| Infisical | 8082 | Gestión de secretos |
| Context-Manager | 5500 | Gestión de contexto IA |
---
## PABLO
**IP:** 72.62.115.124
**Dominio:** tzzr.me
**Tipo:** Instancia de producción del usuario
| Servicio | Puerto | Estado |
|----------|--------|--------|
| Clara | 5051 | OK |
| Alfred | 5052 | OK |
| Mason | 5053 | OK |
| Feldman | 5054 | OK |
| Context-Manager | 5500 | OK |
---
## MODELO CERO
**IP:** 72.62.1.113
**Dominio:** tzzrdeck.me
**Tipo:** Plantilla base para replicar instancias
| Servicio | Puerto | Estado |
|----------|--------|--------|
| Clara | 5051 | OK |
| Alfred | 5052 | OK |
| Mason | 5053 | Pendiente |
| Feldman | 5054 | Pendiente |
| Context-Manager | 5500 | OK |
---
## CORP
**IP:** 92.112.181.188
**Dominio:** tzzrcorp.me
| Servicio | Puerto | Estado |
|----------|--------|--------|
| Margaret | 5051 | OK |
| Jared | 5052 | OK |
| Mason | 5053 | OK |
| Feldman | 5054 | OK |
| Directus 11 | 8055 | OK |
---
## HST
**IP:** 72.62.2.84
| Servicio | Puerto | Estado |
|----------|--------|--------|
| Directus HST | 8055 | OK |
| Directus PLY | 8056 | OK |
| Directus ITM | 8057 | OK |
| HST-API | 80 | OK |
---
# Servicios Cloud
## RunPod
| Servicio | Endpoint ID | Estado |
|----------|-------------|--------|
| GRACE | r00x4g3rrwkbyh | Pendiente |
| PENNY | 0mxhaokgsmgee3 | OK |
## Cloudflare R2
**Endpoint:** `https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com`
| Bucket | Acceso |
|--------|--------|
| architect | Privado |
| pablo | Privado |
| modelo-cero | Privado |
| corp | Privado |
| hst | Público |
| locker | Privado |
---
# Stack Tecnológico
| Componente | Tecnología |
|------------|------------|
| Contenedores | Docker + Docker Compose |
| Base de datos | PostgreSQL 15 |
| Cache | Redis 7 |
| Proxy | Caddy 2 |
| Secretos | Infisical |
---
# Backup
| Tipo | Frecuencia | Destino |
|------|------------|---------|
| PostgreSQL | Diario | R2 |
| Gitea | Semanal | R2 |
| Config | Diario | R2 |
---
# SSH
```bash
ssh pablo # PABLO (producción)
ssh modelo-cero # MODELO CERO (desarrollo)
ssh root@92.112.181.188 -i ~/.ssh/tzzr # CORP
ssh root@72.62.2.84 -i ~/.ssh/tzzr # HST
```
---
*SKYNET v10.1 - 04_INFRAESTRUCTURA - 22 Enero 2026*

View File

@@ -0,0 +1,114 @@
# Estado del Sistema
**Última actualización:** 2024-12-24 10:45 UTC
---
## Estado Rápido
```
Pipeline de Ingesta: [########--] 80%
Procesamiento IA: [#---------] 10% (GRACE pendiente)
Apps Usuario: [----------] 0%
Observabilidad: [----------] 0%
```
---
## Servicios Activos
### DECK (72.62.1.113) - tzzrdeck.me
| Servicio | Puerto | Función | Estado |
|----------|--------|---------|--------|
| Clara (secretaría) | 5051 | Ingesta de datos | ✓ OK |
| Alfred (producción) | 5052 | Flujos predefinidos | ✓ OK |
| Mason (administración) | 5053 | Enriquecimiento | ⚠ Pendiente |
| Feldman (contable) | 5054 | Consolidación | ⚠ Pendiente |
### CORP (92.112.181.188) - tzzrcorp.me
| Servicio | Puerto | Función | Estado |
|----------|--------|---------|--------|
| Margaret (secretaría) | 5051 | Ingesta de datos | ✓ OK |
| Jared (producción) | 5052 | Flujos predefinidos | ✓ OK |
| Mason (administración) | 5053 | Enriquecimiento | ✓ OK |
| Feldman (contable) | 5054 | Consolidación | ✓ OK |
### RunPod (Serverless)
| Servicio | Endpoint ID | Función | Estado |
|----------|-------------|---------|--------|
| GRACE | r00x4g3rrwkbyh | GPU Processing | ⚠ Pendiente Docker image |
| PENNY | 0mxhaokgsmgee3 | Asistente voz | ✓ OK |
| FACTORY | - | Generación | ⚠ Pendiente |
### Infraestructura
| Servicio | Servidor | Puerto | Estado |
|----------|----------|--------|--------|
| Gitea | ARCHITECT | 3000 | ✓ OK |
| Directus | Todos | 8055 | ✓ OK |
| HST | HST | 80 | ✓ OK |
| Infisical | ARCHITECT | 8082 | ✓ OK |
---
## Fases Completadas
| Fase | Descripción | Fecha |
|------|-------------|-------|
| 0 | Limpieza y consolidación | 2024-12-24 |
| 1 | Pipeline mínimo - Clara (secretaría) | 2024-12-24 |
| 3 | Flujo empresarial - Margaret (secretaría) | 2024-12-24 |
| 4 | Alfred/Jared (producción), Mason (administración), Feldman (contable) | 2024-12-24 |
---
## h_instancia (Auth Keys)
| Servidor | Hash |
|----------|------|
| DECK | `f25e44ac3c075f57b9a198c880cb1fc05cf3af56f6466828b405d8c062374179` |
| CORP | `ea9e99d5f95bcc23749d5f25b71a5b520ae7917438912fc6e29564534484a514` |
---
## Endpoints de Verificación
```bash
# DECK (tzzrdeck.me)
curl http://72.62.1.113:5051/health # Clara (secretaría)
curl http://72.62.1.113:5052/health # Alfred (producción)
curl http://72.62.1.113:5053/health # Mason (administración)
curl http://72.62.1.113:5054/health # Feldman (contable)
# CORP (tzzrcorp.me)
curl http://92.112.181.188:5051/health # Margaret (secretaría)
curl http://92.112.181.188:5052/health # Jared (producción)
curl http://92.112.181.188:5053/health # Mason (administración)
curl http://92.112.181.188:5054/health # Feldman (contable)
```
---
## Bloqueadores Actuales
| Componente | Bloqueador | Impacto |
|------------|------------|---------|
| GRACE | Docker image en RunPod | Procesamiento IA |
---
## Próximos Pasos
### Inmediato
1. **GRACE** - Construir Docker image y desplegar en RunPod
2. **PACKET** - Publicar APK
### Posterior
1. SENTINEL - Observabilidad
2. THE-FACTORY - Generación contenido
3. PENNY - Procesamiento voz

View File

@@ -1,177 +0,0 @@
# Modelo de Amenazas TZZR
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Resumen Ejecutivo
El sistema TZZR tiene una base de seguridad sólida (SSH keys, PostgreSQL SSL, tokens de autenticación) pero presenta exposiciones críticas que requieren atención inmediata.
---
## Hallazgos Críticos
### CRÍTICO-001: CORP/HST sin Firewall
**Descripción:** UFW inactivo en servidores CORP y HST.
**Impacto:** Todos los puertos expuestos a Internet.
**Evidencia:** `ufw status` devuelve "inactive".
**Mitigación:**
```bash
# CORP
ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
# HST
ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
```
### CRÍTICO-002: PostgreSQL 5432 Expuesto
**Descripción:** PostgreSQL en ARCHITECT escucha en 0.0.0.0:5432.
**Impacto:** Accesible desde cualquier IP (aunque requiere autenticación).
**Mitigación:**
```
# /etc/postgresql/16/main/postgresql.conf
listen_addresses = '127.0.0.1,172.17.0.1'
```
### CRÍTICO-003: Archivos .env Legibles
**Descripción:** Archivos .env con permisos 644 (legibles por todos).
**Impacto:** Credenciales accesibles a cualquier usuario del sistema.
**Mitigación:**
```bash
chmod 600 /opt/clara/.env
chmod 600 /opt/alfred/.env
chmod 600 /opt/margaret/.env
chmod 600 /opt/mason/.env
```
---
## Hallazgos Altos
### ALTO-001: fail2ban No Configurado
**Descripción:** fail2ban failed en DECK, inactive en CORP.
**Impacto:** SSH bruteforce sin mitigación automática.
**Evidencia:** Ataques activos desde 165.232.81.204, 188.166.115.48.
**Mitigación:**
```bash
apt install fail2ban
systemctl enable fail2ban
# jail: sshd, maxretry=3, bantime=1h
```
### ALTO-002: Triple Gestión de Secretos
**Descripción:** Credenciales en Infisical, tablas creds_*, y archivos .env.
**Impacto:** No hay fuente única de verdad, riesgo de desincronización.
**Mitigación:**
- Migrar todas las credenciales a Infisical
- Eliminar .env hardcodeados
- creds_* solo para referencia
### ALTO-003: Servicios sin TLS Interno
**Descripción:** CLARA, MARGARET, MASON, FELDMAN en HTTP plano.
**Impacto:** Tráfico interno sin cifrar.
**Mitigación:**
- Configurar mTLS entre servicios
- Usar Caddy como reverse proxy con TLS
---
## Hallazgos Medios
### MEDIO-001: No hay Backup PostgreSQL
**Descripción:** Solo Gitea tiene backup en R2, PostgreSQL sin backup.
**Impacto:** Pérdida de datos en caso de fallo.
**Mitigación:**
```bash
# Cron diario
pg_dump architect | gzip | aws s3 cp - s3://architect/backups/architect_$(date +%F).sql.gz
```
### MEDIO-002: SENTINEL No Desplegado
**Descripción:** Sistema de auditoría planificado pero no implementado.
**Impacto:** Sin visibilidad de anomalías.
**Mitigación:** Implementar SENTINEL LIGHT mode básico.
### MEDIO-003: No hay Rotación de Secretos
**Descripción:** Sin política de rotación de credenciales.
**Impacto:** Credenciales comprometidas persisten indefinidamente.
**Mitigación:**
- API keys: 90 días
- DB passwords: 180 días
- SSH keys: 365 días
---
## Controles Existentes
| Control | Estado | Notas |
|---------|--------|-------|
| SSH Keys | Activo | Permisos 600 correctos |
| PostgreSQL SSL | Activo | SCRAM-SHA-256 |
| H_INSTANCIA Auth | Activo | CLARA/MARGARET |
| Gitea Tokens | Activo | Lectura/Escritura separados |
| DECK UFW | Activo | Política deny incoming |
---
## Matriz de Riesgos
| ID | Riesgo | Probabilidad | Impacto | Prioridad |
|----|--------|--------------|---------|-----------|
| CRÍTICO-001 | Firewall desactivado | Alta | Alto | Semana 1 |
| CRÍTICO-002 | PostgreSQL expuesto | Media | Alto | Semana 1 |
| CRÍTICO-003 | .env legibles | Alta | Alto | Semana 1 |
| ALTO-001 | Sin fail2ban | Alta | Medio | Semana 1 |
| ALTO-002 | Secretos duplicados | Media | Medio | Mes 1 |
| ALTO-003 | Sin TLS interno | Baja | Medio | Mes 1 |
| MEDIO-001 | Sin backup PG | Baja | Alto | Mes 1 |
| MEDIO-002 | Sin SENTINEL | Baja | Medio | Mes 2 |
| MEDIO-003 | Sin rotación | Baja | Medio | Mes 2 |
---
## Plan de Remediación
### Semana 1 (Urgente)
- [ ] Activar UFW en CORP y HST
- [ ] chmod 600 en todos los .env
- [ ] Instalar fail2ban
- [ ] PostgreSQL bind 127.0.0.1
### Mes 1 (Alta)
- [ ] Migrar secretos a Infisical
- [ ] TLS interno
- [ ] Backup PostgreSQL automatizado
### Mes 2 (Media)
- [ ] SENTINEL LIGHT mode
- [ ] Política de rotación
- [ ] Monitoreo de certificados

View File

@@ -1,344 +0,0 @@
# Gestión de Secretos TZZR
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Arquitectura de Secretos
### Principio Fundamental
> **DECK y CORP son instancias autónomas. Deben operar independientemente de ARCHITECT.**
ARCHITECT es el constructor/coordinador. DECK y CORP son instancias diseñadas para trabajar solas.
### Modelo de Gestión
```
┌─────────────────────────────────────────────────────────────────┐
│ ARCHITECT │
│ (Constructor) │
│ │
│ ┌──────────────┐ │
│ │ Infisical │ ← Gestión centralizada │
│ │ :8082 │ Single source of truth │
│ └──────┬───────┘ │
│ │ │
└───────────────────────────┼─────────────────────────────────────┘
sync/push │ (en deploy o periódico)
┌────────────────┴────────────────┐
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ DECK │ │ CORP │
│ (Instancia) │ │ (Instancia) │
│ │ │ │
│ ┌──────────────┐ │ │ ┌──────────────┐ │
│ │ Vaultwarden │ │ │ │ Vaultwarden │ │
│ │ :8085 │ │ │ │ :8081 │ │
│ └──────┬───────┘ │ │ └──────┬───────┘ │
│ │ │ │ │ │
│ ▼ │ │ ▼ │
│ CLARA, ALFRED │ │ MARGARET, JARED │
│ leen de aquí │ │ MASON, FELDMAN │
│ │ │ leen de aquí │
└──────────────────────┘ └──────────────────────┘
```
### Gestores por Servidor
| Servidor | Gestor | Puerto | Rol |
|----------|--------|--------|-----|
| ARCHITECT | Infisical | 8082 | Gestión central, source of truth |
| DECK | Vaultwarden | 8085 | Operación autónoma DECK |
| CORP | Vaultwarden | 8081 | Operación autónoma CORP |
---
## Flujo de Secretos
### Administración (en ARCHITECT)
```
Administrador
┌─────────────┐
│ Infisical │ ← Crear/modificar/rotar secretos aquí
│ (central) │
└─────────────┘
```
### Sincronización (ARCHITECT → Instancias)
```
Infisical (ARCHITECT)
│ Script de sync / deploy
├────────────────┬────────────────┐
▼ ▼ ▼
Vaultwarden Vaultwarden (otras instancias
DECK CORP futuras)
```
### Operación (en cada instancia)
```
┌──────────────────────────────────────┐
│ DECK │
│ │
│ CLARA ──────► Vaultwarden ◄─────── ALFRED
│ :8085 │
│ │
│ ✅ No depende de ARCHITECT │
│ ✅ Opera si ARCHITECT está caído │
└──────────────────────────────────────┘
```
---
## Estado Actual: Problema
**Triple gestión sin sincronización:**
| Fuente | Ubicación | Estado |
|--------|-----------|--------|
| Infisical | ARCHITECT :8082 | Parcialmente usado |
| creds_* | PostgreSQL ARCHITECT | Activo |
| .env | /opt/*/.env en cada servidor | Activo, **permisos 644** |
**Problemas:**
- Secretos duplicados en múltiples lugares
- Sin sincronización entre fuentes
- .env legibles por todos (644)
- Vaultwarden de DECK/CORP no integrados
---
## Decisión D-001: Arquitectura de Secretos
### Objetivo
1. **Infisical** (ARCHITECT): Única fuente de verdad para administración
2. **Vaultwarden** (DECK/CORP): Gestores locales para operación autónoma
3. **Sync**: Mecanismo de propagación Infisical → Vaultwarden
### División de Responsabilidades
| Tipo de Secreto | Gestión en | Operación en |
|-----------------|------------|--------------|
| API keys externas (OpenAI, etc.) | Infisical | Vaultwarden local |
| R2 credentials | Infisical | Vaultwarden local |
| Gitea tokens | Infisical | Vaultwarden local |
| DB password DECK | Infisical | Vaultwarden DECK |
| DB password CORP | Infisical | Vaultwarden CORP |
| Tokens internos DECK | Infisical | Vaultwarden DECK |
| Tokens internos CORP | Infisical | Vaultwarden CORP |
### Flujo de Trabajo
```
1. Admin modifica secreto en Infisical (ARCHITECT)
2. Script de sync detecta cambio
3. Propaga a Vaultwarden de DECK y/o CORP
4. Servicios locales usan Vaultwarden local
5. ARCHITECT puede caer → DECK/CORP siguen operando
```
---
## Plan de Migración
### Fase 1: Inventario
```
├── Catalogar todos los secretos en creds_*
├── Catalogar todos los secretos en .env
├── Identificar duplicados/inconsistencias
└── Mapear qué secretos necesita cada instancia
```
### Fase 2: Centralización en Infisical
```
├── Migrar todos los secretos a Infisical
├── Organizar por instancia (DECK, CORP)
├── Establecer políticas de acceso
└── Documentar cada secreto
```
### Fase 3: Configurar Vaultwarden en Instancias
```
├── DECK: Configurar Vaultwarden :8085
│ ├── Crear organización "DECK"
│ ├── Importar secretos de DECK desde Infisical
│ └── Configurar acceso para servicios
└── CORP: Configurar Vaultwarden :8081
├── Crear organización "CORP"
├── Importar secretos de CORP desde Infisical
└── Configurar acceso para servicios
```
### Fase 4: Implementar Sync
```
├── Crear script de sincronización
│ └── infisical export → vaultwarden import
├── Configurar trigger (manual, cron, o webhook)
└── Probar sync en ambas direcciones
```
### Fase 5: Actualizar Servicios
```
├── CLARA: Leer de Vaultwarden DECK
├── ALFRED: Leer de Vaultwarden DECK
├── MARGARET: Leer de Vaultwarden CORP
├── JARED: Leer de Vaultwarden CORP
├── MASON: Leer de Vaultwarden CORP
└── FELDMAN: Leer de Vaultwarden CORP
```
### Fase 6: Deprecación
```
├── Eliminar archivos .env
├── Marcar creds_* como "solo referencia histórica"
└── Documentar proceso completo
```
---
## Implementación
### Lectura desde Vaultwarden (Python)
```python
import requests
VAULTWARDEN_URL = "http://localhost:8085" # DECK
# VAULTWARDEN_URL = "http://localhost:8081" # CORP
def get_secret(name: str) -> str:
"""Obtiene secreto de Vaultwarden local."""
# Implementar según API de Vaultwarden/Bitwarden
pass
```
### Script de Sync (Infisical → Vaultwarden)
```bash
#!/bin/bash
# /opt/scripts/sync_secrets.sh
# Exportar desde Infisical
infisical export --env=deck --format=json > /tmp/deck_secrets.json
infisical export --env=corp --format=json > /tmp/corp_secrets.json
# Importar a Vaultwarden DECK
ssh deck 'bw import --format json /tmp/deck_secrets.json'
# Importar a Vaultwarden CORP
ssh corp 'bw import --format json /tmp/corp_secrets.json'
# Cleanup
rm /tmp/*_secrets.json
```
---
## Mitigación Inmediata
### Paso 1: Permisos .env (URGENTE)
```bash
# DECK
ssh -i ~/.ssh/tzzr root@72.62.1.113 'chmod 600 /opt/clara/.env /opt/alfred/.env'
# CORP
ssh -i ~/.ssh/tzzr root@92.112.181.188 'chmod 600 /opt/margaret/.env /opt/mason/.env /opt/feldman/.env'
```
### Paso 2: Verificar Vaultwarden
```bash
# DECK
curl -s http://72.62.1.113:8085/api/health
# CORP
curl -s http://92.112.181.188:8081/api/health
```
---
## Rotación de Secretos
### Política
| Tipo | Frecuencia | Responsable |
|------|------------|-------------|
| API Keys externas | 90 días | Admin vía Infisical |
| Contraseñas DB | 180 días | Admin vía Infisical |
| SSH Keys | 365 días | Admin vía Infisical |
| Tokens Gitea | 180 días | Admin vía Infisical |
### Proceso
```
1. Rotar en Infisical (ARCHITECT)
2. Ejecutar sync a Vaultwarden (DECK/CORP)
3. Verificar servicios operando
4. Documentar rotación
```
---
## Verificación
### Checklist
- [ ] Infisical operativo en ARCHITECT
- [ ] Vaultwarden operativo en DECK (:8085)
- [ ] Vaultwarden operativo en CORP (:8081)
- [ ] Sync configurado y probado
- [ ] Servicios leen de Vaultwarden local
- [ ] .env eliminados o con permisos 600
- [ ] DECK opera si ARCHITECT cae
- [ ] CORP opera si ARCHITECT cae
### Test de Autonomía
```bash
# 1. Detener ARCHITECT (simulado)
# 2. Verificar DECK sigue operando
curl http://72.62.1.113:5051/health # CLARA
# 3. Verificar CORP sigue operando
curl http://92.112.181.188:5051/health # MARGARET
```
---
## Resumen
| Componente | Rol |
|------------|-----|
| **Infisical (ARCHITECT)** | Gestión centralizada, source of truth |
| **Vaultwarden (DECK)** | Operación autónoma instancia personal |
| **Vaultwarden (CORP)** | Operación autónoma instancia empresarial |
| **Sync** | Propagación de cambios |
**Principio clave:** Las instancias (DECK, CORP) nunca dependen de ARCHITECT en runtime.

View File

@@ -0,0 +1,68 @@
# 05 - Integraciones
> APIs, protocolos de comunicación y servicios GPU
## Contenido
| Documento | Descripción |
|-----------|-------------|
| [factory-protocol.md](factory-protocol.md) | Protocolo de comunicación con The Factory |
| [hst-api.md](hst-api.md) | API REST de Hash Semantic Tagging |
| [gpu-services.md](gpu-services.md) | Servicios en RunPod: Grace, Penny, Factory |
| [notario.md](notario.md) | Servicio de notarización y certificación |
## APIs Principales
### HST API
Gestión de tags semánticos y categorización.
```
GET /api/v1/tags
POST /api/v1/tags
GET /api/v1/tags/{hash}
PUT /api/v1/tags/{hash}
```
### Factory Protocol
Comunicación con servicios de generación.
```
POST /factory/generate
GET /factory/status/{job_id}
POST /factory/iterate
```
## Servicios GPU (RunPod)
| Servicio | Función | Modelo Base |
|----------|---------|-------------|
| **Grace** | 18 módulos de IA especializados | Varios |
| **Penny** | Asistente de voz conversacional | Whisper + TTS |
| **Factory** | Generación iterativa de contenido | Diversos |
## Protocolos de Comunicación
### S-Contract v2.1
Protocolo estándar de comunicación entre componentes:
```json
{
"version": "2.1",
"source": "component_id",
"target": "component_id",
"action": "action_type",
"payload": {},
"timestamp": "ISO8601",
"signature": "hash"
}
```
## Autenticación
- **Interna**: Tokens JWT firmados por Architect
- **Externa**: API Keys gestionadas en Infisical
- **GPU**: Tokens específicos de RunPod
---
[← Volver al índice](../README.md)

View File

@@ -0,0 +1,274 @@
# MCP Server TZZR
Servidor MCP (Model Context Protocol) que expone los servicios del sistema TZZR, traduciendo entre el protocolo MCP estándar y S-CONTRACT v2.1.
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ CLIENTE MCP │
│ (Claude Desktop, Cursor, otro cliente MCP) │
└─────────────────────────────────┬───────────────────────────────┘
│ MCP Protocol (stdio/SSE)
┌─────────────────────────────────────────────────────────────────┐
│ MCP SERVER TZZR │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ TOOLS │ │ RESOURCES │ │ PROMPTS │ │
│ │ │ │ │ │ │ │
│ │ clasificar │ │ hst://tags │ │ analizar_ │ │
│ │ resumir │ │ tzzr:// │ │ factura │ │
│ │ ocr │ │ grace:// │ │ clasificar_ │ │
│ │ transcribir │ │ │ │ documento │ │
│ │ ... │ │ │ │ ... │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │
│ ┌────────────┴────────────┐ │
│ │ S-CONTRACT BUILDER │ │
│ │ (v2.1) │ │
│ └────────────┬────────────┘ │
└───────────────────────────┼─────────────────────────────────────┘
│ S-CONTRACT JSON
┌─────────────┼─────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ GRACE │ │ HST │ │ Context │
│ (RunPod) │ │(Directus)│ │ Manager │
└──────────┘ └──────────┘ └──────────┘
```
## Instalación
### Opción 1: pip (recomendado)
```bash
pip install mcp-server-tzzr
```
### Opción 2: Desde código fuente
```bash
git clone https://gitea.tzzr.me/tzzr/mcp-server-tzzr.git
cd mcp-server-tzzr
pip install -e .
```
## Configuración
### Variables de entorno
Crea un archivo `.env` o configura las siguientes variables:
```bash
# RunPod API Key (para GRACE)
RUNPOD_API_KEY=rpa_XXXXXXXXXXXXXXXXXXXXXXXXXX
# Token de Directus HST
HST_TOKEN=your_directus_token
# (Opcional) Context Manager
CONTEXT_MANAGER_URL=https://captain-claude.tzrtech.org/api/v2
```
### Configuración en Claude Desktop
Añade al archivo `claude_desktop_config.json`:
```json
{
"mcpServers": {
"tzzr": {
"command": "python",
"args": ["-m", "mcp_server_tzzr"],
"env": {
"RUNPOD_API_KEY": "rpa_XXXXXXX",
"HST_TOKEN": "your_token"
}
}
}
}
```
Ubicación del archivo:
- **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json`
- **Windows**: `%APPDATA%\Claude\claude_desktop_config.json`
- **Linux**: `~/.config/Claude/claude_desktop_config.json`
## Herramientas Disponibles (Tools)
### GRACE - Procesamiento Cognitivo
| Tool | Descripción | Módulo S-CONTRACT |
|------|-------------|-------------------|
| `clasificar` | Clasifica texto y asigna tags HST | CLASSIFIER |
| `resumir` | Resume textos largos | SUMMARIZER |
| `ocr` | Extrae texto de imágenes | OCR_CORE |
| `transcribir` | Transcribe audio a texto | ASR_ENGINE |
| `traducir` | Traduce entre idiomas | TRANSLATOR |
| `extraer_campos` | Extrae CIF, fechas, importes | FIELD_EXTRACTOR |
| `embeddings` | Genera vectores semánticos | EMBEDDINGS |
| `detectar_idioma` | Detecta idioma de texto | LANG_DETECT |
| `generar_hash` | Genera SHA-256 o UUID | HASHER |
### HST - Sistema de Tags
| Tool | Descripción |
|------|-------------|
| `buscar_tags` | Busca tags por texto |
| `listar_tags` | Lista tags de un grupo (hst, spe, flg, vsn) |
### Sistema
| Tool | Descripción |
|------|-------------|
| `grace_health` | Verifica estado de GRACE en RunPod |
## Recursos Disponibles (Resources)
| URI | Descripción |
|-----|-------------|
| `tzzr://hst/tags/hst` | 639 tags del sistema base |
| `tzzr://hst/tags/spe` | 145 tags de iluminación técnica |
| `tzzr://hst/tags/flg` | 65 banderas/países |
| `tzzr://grace/modules` | Catálogo de 18 módulos GRACE |
| `tzzr://servers/status` | Estado de servidores TZZR |
| `tzzr://hst/tag/{ref}` | Tag individual por referencia |
## Prompts Disponibles
| Prompt | Descripción | Argumentos |
|--------|-------------|------------|
| `analizar_factura` | Extrae campos de factura | `texto_factura` |
| `clasificar_documento` | Clasifica y sugiere tags | `contenido`, `contexto` |
| `resumir_reunion` | Resume transcripción | `transcripcion` |
## Ejemplos de Uso
### Desde Claude Desktop
```
Usuario: Clasifica este documento: "Factura nº 2024-001 de Luminarias S.L..."
Claude: [Ejecuta tool: clasificar]
Resultado:
{
"categoria": "FINANZAS",
"confidence": 0.95,
"tags": ["hst:factura", "spe:luminaria", "hst:proveedor"]
}
```
### Desde código Python
```python
from mcp import ClientSession
from mcp.client.stdio import stdio_client
async with stdio_client(["python", "-m", "mcp_server_tzzr"]) as client:
async with ClientSession(*client) as session:
# Llamar a una herramienta
result = await session.call_tool(
"clasificar",
{"texto": "Contrato de servicios de iluminación LED..."}
)
print(result)
# Leer un recurso
tags = await session.read_resource("tzzr://hst/tags/spe")
print(tags)
```
## Traducción MCP → S-CONTRACT
El servidor traduce automáticamente las llamadas MCP a S-CONTRACT v2.1:
### Entrada MCP (Tool call)
```json
{
"name": "clasificar",
"arguments": {
"texto": "Documento de ejemplo...",
"idioma": "es"
}
}
```
### S-CONTRACT generado
```json
{
"contract_version": "2.1",
"profile": "LITE",
"envelope": {
"trace_id": "550e8400-e29b-41d4-a716-446655440000",
"idempotency_key": "a1b2c3d4e5f6...",
"timestamp": "2026-01-04T12:00:00Z"
},
"routing": {
"module": "CLASSIFIER",
"version": "1.0"
},
"context": {
"lang": "es",
"mode": "strict"
},
"payload": {
"type": "text",
"encoding": "utf-8",
"content": "Documento de ejemplo..."
}
}
```
## Desarrollo
### Ejecutar tests
```bash
pytest tests/ -v
```
### Ejecutar en modo desarrollo
```bash
python -m src.server
```
### Verificar con MCP Inspector
```bash
npx @modelcontextprotocol/inspector python -m src.server
```
## Estructura del Proyecto
```
mcp-server-tzzr/
├── src/
│ └── server.py # Servidor MCP principal
├── tests/
│ └── test_server.py # Tests
├── pyproject.toml # Configuración del proyecto
├── README.md # Este archivo
└── .env.example # Ejemplo de variables de entorno
```
## Servicios TZZR Integrados
| Servicio | Función | Endpoint |
|----------|---------|----------|
| **GRACE** | 18 módulos cognitivos | RunPod Serverless |
| **HST** | Sistema de tags semánticos | Directus API |
| **Context Manager** | Orquestación de contexto | API interna |
## Roadmap
- [ ] Soporte para FELDMAN (validación Merkle)
- [ ] Integración con NOTARIO (sellado blockchain)
- [ ] Streaming para respuestas largas
- [ ] Caché de resultados frecuentes
- [ ] Métricas y observabilidad
## Licencia
MIT License - TZZR Systems 2026

View File

@@ -0,0 +1,342 @@
# MCP Server TZZR - Especificación Técnica
**Versión:** 1.0.0
**Fecha:** 2026-01-04
**Estado:** Listo para implementación
---
## 1. Visión General
### 1.1 Propósito
El MCP Server TZZR actúa como **puente entre el ecosistema MCP** (clientes como Claude Desktop, Cursor, etc.) y los **servicios internos TZZR** que utilizan S-CONTRACT v2.1.
```
┌────────────────────┐
│ Clientes MCP │
│ (Claude Desktop) │
└─────────┬──────────┘
│ MCP Protocol
┌────────────────────┐
│ MCP Server TZZR │ ◄── Este componente
└─────────┬──────────┘
│ S-CONTRACT v2.1
┌────────────────────┐
│ Servicios TZZR │
│ (GRACE, HST, etc) │
└────────────────────┘
```
### 1.2 Beneficios
| Sin MCP Server | Con MCP Server |
|----------------|----------------|
| Acceso solo vía API REST | Acceso desde cualquier cliente MCP |
| Integración manual por servicio | Integración automática estandarizada |
| Solo desarrolladores | Usuarios finales vía Claude Desktop |
| Contexto manual | Recursos y prompts predefinidos |
---
## 2. Arquitectura
### 2.1 Componentes
```
mcp-server-tzzr/
├── src/
│ ├── __init__.py
│ └── server.py # Servidor principal
│ ├── SContractBuilder # Constructor S-CONTRACT
│ ├── GraceClient # Cliente RunPod/GRACE
│ ├── HSTClient # Cliente Directus/HST
│ ├── Tools # 12 herramientas MCP
│ ├── Resources # 5+ recursos estáticos
│ └── Prompts # 3 plantillas
├── tests/
├── pyproject.toml
└── README.md
```
### 2.2 Flujo de Datos
```
1. Cliente MCP llama tool "clasificar" con {texto: "..."}
2. MCP Server recibe la llamada
3. SContractBuilder genera S-CONTRACT v2.1:
{
"contract_version": "2.1",
"routing": {"module": "CLASSIFIER"},
"payload": {"content": "..."}
}
4. GraceClient envía a RunPod endpoint
5. GRACE procesa y devuelve resultado
6. MCP Server parsea respuesta y devuelve TextContent
7. Cliente MCP recibe resultado formateado
```
---
## 3. Mapeo MCP ↔ S-CONTRACT
### 3.1 Tools → Módulos GRACE
| Tool MCP | Módulo S-CONTRACT | Familia |
|----------|-------------------|---------|
| `clasificar` | CLASSIFIER | Semántica |
| `resumir` | SUMMARIZER | Semántica |
| `ocr` | OCR_CORE | Visión |
| `transcribir` | ASR_ENGINE | Voz |
| `traducir` | TRANSLATOR | Semántica |
| `extraer_campos` | FIELD_EXTRACTOR | Utilidades |
| `embeddings` | EMBEDDINGS | Semántica |
| `detectar_idioma` | LANG_DETECT | Utilidades |
| `generar_hash` | HASHER | Utilidades |
### 3.2 Traducción de Parámetros
**Ejemplo: Tool `clasificar`**
```
MCP Input:
{
"texto": "Factura de servicios...",
"idioma": "es"
}
S-CONTRACT Output:
{
"contract_version": "2.1",
"profile": "LITE",
"envelope": {
"trace_id": "uuid",
"idempotency_key": "sha256",
"timestamp": "ISO8601"
},
"routing": {
"module": "CLASSIFIER",
"version": "1.0"
},
"context": {
"lang": "es",
"mode": "strict"
},
"payload": {
"type": "text",
"encoding": "utf-8",
"content": "Factura de servicios..."
}
}
```
### 3.3 Cadenas de Fallback
Algunos módulos tienen fallback automático:
| Módulo | Fallback Chain |
|--------|----------------|
| OCR_CORE | OCR_LOCAL → OCR_GROQ → OCR_OPENAI |
| ASR_ENGINE | ASR_WHISPER_LOCAL → ASR_FASTER_WHISPER → ASR_GROQ |
---
## 4. Recursos MCP
### 4.1 Recursos Estáticos
| URI | Fuente | Descripción |
|-----|--------|-------------|
| `tzzr://hst/tags/hst` | Directus | 639 tags base |
| `tzzr://hst/tags/spe` | Directus | 145 tags iluminación |
| `tzzr://hst/tags/flg` | Directus | 65 países |
| `tzzr://grace/modules` | Hardcoded | Catálogo 18 módulos |
| `tzzr://servers/status` | Config | Estado servidores |
### 4.2 Templates Dinámicos
| Template | Parámetro | Uso |
|----------|-----------|-----|
| `tzzr://hst/tag/{ref}` | ref | Tag individual |
| `tzzr://context/{agent_id}` | agent_id | Contexto de agente |
---
## 5. Prompts MCP
### 5.1 analizar_factura
**Propósito:** Extracción estructurada de datos de factura
**Argumentos:**
- `texto_factura` (required): Texto de la factura
**Campos extraídos:**
- CIF/NIF emisor y receptor
- Número y fechas
- Base imponible, IVA, total
- IBAN
- Líneas de factura
### 5.2 clasificar_documento
**Propósito:** Clasificación y asignación de tags
**Argumentos:**
- `contenido` (required): Texto del documento
- `contexto` (optional): Contexto adicional
**Output:**
- Categoría principal
- Tags HST sugeridos
- Nivel de confidencialidad
- Resumen breve
### 5.3 resumir_reunion
**Propósito:** Extracción de información de reuniones
**Argumentos:**
- `transcripcion` (required): Transcripción de la reunión
**Output:**
- Participantes
- Temas tratados
- Decisiones
- Tareas asignadas
- Próximos pasos
---
## 6. Configuración
### 6.1 Variables de Entorno
| Variable | Requerida | Descripción |
|----------|-----------|-------------|
| `RUNPOD_API_KEY` | Sí | API key para GRACE |
| `HST_TOKEN` | Sí | Token Directus HST |
| `GRACE_ENDPOINT_ID` | No | Override endpoint GRACE |
| `LOG_LEVEL` | No | DEBUG/INFO/WARNING/ERROR |
### 6.2 Configuración Claude Desktop
```json
{
"mcpServers": {
"tzzr": {
"command": "python",
"args": ["-m", "src.server"],
"cwd": "/opt/mcp-server-tzzr",
"env": {
"RUNPOD_API_KEY": "...",
"HST_TOKEN": "..."
}
}
}
}
```
---
## 7. Despliegue
### 7.1 Opción A: Local (desarrollo)
```bash
cd /opt/mcp-server-tzzr
python -m src.server
```
### 7.2 Opción B: Como paquete pip
```bash
pip install mcp-server-tzzr
mcp-server-tzzr
```
### 7.3 Opción C: Docker
```dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY . .
RUN pip install -e .
CMD ["python", "-m", "src.server"]
```
---
## 8. Integración con Sistema TZZR
### 8.1 Posición en la Arquitectura
```
┌─────────────────┐
│ Claude Desktop │
│ (Usuario) │
└────────┬────────┘
│ MCP
┌────────▼────────┐
│ MCP Server │
│ TZZR │
└────────┬────────┘
│ S-CONTRACT
┌────────────────────┼────────────────────┐
│ │ │
┌───────▼───────┐ ┌────────▼────────┐ ┌──────▼──────┐
│ GRACE │ │ HST │ │ Context │
│ (RunPod) │ │ (Directus) │ │ Manager │
└───────────────┘ └─────────────────┘ └─────────────┘
```
### 8.2 Servicios Conectados
| Servicio | Protocolo | Puerto | Función |
|----------|-----------|--------|---------|
| GRACE | HTTPS/RunPod | - | Procesamiento cognitivo |
| HST Directus | HTTPS | 8055 | Tags semánticos |
| Context Manager | HTTPS | 5500 | Orquestación (futuro) |
---
## 9. Roadmap
### v1.0 (actual)
- [x] Tools GRACE básicos
- [x] Recursos HST
- [x] Prompts predefinidos
- [x] Traducción S-CONTRACT
### v1.1 (planificado)
- [ ] Integración FELDMAN (validación Merkle)
- [ ] Integración NOTARIO (sellado blockchain)
- [ ] Caché de respuestas frecuentes
### v1.2 (futuro)
- [ ] Streaming para respuestas largas
- [ ] Context Manager integration
- [ ] Métricas Prometheus
---
## 10. Referencias
- [MCP Specification](https://spec.modelcontextprotocol.io)
- [S-CONTRACT v2.1](gitea://tzzr/contratos-comunes)
- [GRACE Modules](gitea://tzzr/grace)
- [HST System](gitea://tzzr/hst)

View File

@@ -0,0 +1,75 @@
# Sincronización ATC ↔ R2 ↔ Nextcloud
## Objetivo
Sincronizar archivos seleccionados desde buckets R2 hacia Nextcloud DECK, permitiendo descarga selectiva en dispositivos locales (Mac).
## Arquitectura
```
┌─────────────┐ ┌──────────────┐ ┌─────────────┐ ┌─────────┐
│ R2/S3 │ │ Windmill │ │ Nextcloud │ │ Mac │
│ deck/ │────▶│ flow.tzzr │────▶│ /nextc_ │────▶│ Local │
│ personaldeck│ │ deck.me │ │ deck/sync │ │ Sync │
└─────────────┘ └──────────────┘ └─────────────┘ └─────────┘
┌──────────────┐
│ PostgreSQL │
│ atc_status │
└──────────────┘
```
## Tablas PostgreSQL
### tzzr_storage.buckets
Configuración de buckets R2.
| bucket_mrf | name | endpoint |
|------------|------|----------|
| d83032... | deck | R2 Cloudflare |
| c1b0e6... | personaldeck | R2 Cloudflare |
### tzzr_storage.atc
Catálogo de archivos con metadata.
| Campo | Descripción |
|-------|-------------|
| mrf | Hash único del archivo |
| private_mrf | Hash privado |
| bucket_mrf | FK a buckets |
| roothash | Ruta/estructura del archivo (pendiente) |
| ref | Tipo: img, doc, cad, etc. |
### tzzr_storage.atc_status
Lista blanca de archivos a sincronizar.
| Campo | Descripción |
|-------|-------------|
| mrf | FK a atc |
| status | enable / disable / deleted |
| bucket_mrf | FK a buckets |
## Flujo de Sincronización
1. Usuario marca archivo en `atc_status` con `status='enable'`
2. Windmill detecta cambio (trigger/schedule)
3. Script consulta archivos con `status='enable'`
4. Para cada archivo:
- Obtiene ruta de `roothash`
- Descarga de R2 a `/nextc_deck/sync/{ruta}/`
5. Nextcloud detecta archivos nuevos
6. Mac sincroniza via app Nextcloud
## Windmill
- URL: `flow.tzzrdeck.me`
- Puerto interno: 8100
- Propósito: Orquestación de workflows
## Pendiente
- [ ] Definir formato de `roothash`
- [ ] Crear workflow en Windmill
- [ ] Configurar trigger (webhook vs schedule)
- [ ] Implementar script de sync

View File

@@ -0,0 +1,194 @@
# Mapeo HST - Airtable
**Estado:** Implementado
**Última actualización:** 2026-01-04
---
## Descripción
Sistema de mapeo bidireccional entre los tags semánticos HST/FLG almacenados en PostgreSQL y las múltiples bases de Airtable utilizadas por el equipo.
---
## Bases Airtable
| Base | ID | Tablas | Columna en map |
|------|-----|--------|----------------|
| hst_flg | appxaEAneiaYtO8NC | hst, flg | airtable_hst_flg |
| hst_psn | appOyP8gZfm9Bdcgm | hst | airtable_hst_psn |
| lumalia | appZgRKY5sG6E9zJy | hst in | airtable_lumalia |
| lum | apps8bynpQRuMPEid | hst in | airtable_lum |
| tuzzaro | appDaK3LcfWFrlc5u | hst in | airtable_tuzzaro |
| psn | appWIVTR5cYd3aIDJ | hst in | airtable_psn |
| bck | apprqWlmqdj98YIUt | hst in | airtable_bck |
| pff | appAyCPZAtkPhkOAh | hst in | airtable_pff |
---
## Tabla de Mapeo
**Schema:** `map`
**Tabla:** `airtable_map`
**Ubicación:** PostgreSQL en servidor HST (72.62.2.84)
### Estructura
```sql
CREATE TABLE map.airtable_map (
id SERIAL PRIMARY KEY,
als VARCHAR(255), -- Alias del tag
mrf_hst VARCHAR(64), -- Hash MRF en HST
airtable_hst_flg VARCHAR(20),
airtable_hst_psn VARCHAR(20),
airtable_lumalia VARCHAR(20),
airtable_lum VARCHAR(20),
airtable_tuzzaro VARCHAR(20),
airtable_psn VARCHAR(20),
airtable_bck VARCHAR(20),
airtable_pff VARCHAR(20),
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_map_als ON map.airtable_map(als);
CREATE INDEX idx_map_mrf ON map.airtable_map(mrf_hst);
```
### Contenido
| Origen | Registros |
|--------|-----------|
| hst | 963 |
| flg | 65 |
| **Total** | **1028** |
### Estado de Mapeo
| Columna | Registros con ID |
|---------|------------------|
| airtable_hst_flg | 797 |
| airtable_hst_psn | 796 |
| airtable_lumalia | 746 |
| airtable_lum | 746 |
---
## Lógica de Matching
El mapeo se realiza por **alias normalizado**:
1. Lowercase
2. Eliminar espacios extra
3. Eliminar "/" en conectores (ej: "M12 / 6p" → "M12 6p")
4. Normalizar variantes:
- `prototipo` se omite
- `especificaciones``especificación`
### Formato de Alias
```
{ref} {nombre}
```
Ejemplos:
- `spe m12 6p female`
- `flg spain`
- `hst acero inoxidable`
- `rbc cable de cinta`
---
## Grupos HST
| Grupo | Descripción | Cantidad |
|-------|-------------|----------|
| hst | Tags principales | 717 |
| spe | Especificaciones técnicas | 142 |
| vsn | Visiones | 40 |
| vue | Vistas | 21 |
| msn | Misiones/Proyectos | (pendiente) |
---
## Conectores Añadidos
Conectores técnicos sincronizados con Airtable:
### JST
- jst jwpf 2p/3p/4p female/male
- jst sm 2p/3p/4p female/male
### Roscas M
- M8 4p female/male
- M12 2+2p/4p/6p/8p female/male
- M15 3p female/male
- M16 2p/2+4p female/male/screw
- M20 3p/4p screw
- M25 2+2p female/male
- M29 4p female/male
- mr30 female/male
### Otros
- xt30 female/male
- xt60 female/male
- ethernet
- utp, ftp, s/ftp, sf/utp
- rbc (ribbon cable / cable de cinta)
---
## Convenciones de Nombres
| Campo | Español | Inglés |
|-------|---------|--------|
| nombre_es | hembra/macho | - |
| nombre_en | - | female/male |
| Roscas | M8, M12, M16... (mayúsculas) | M8, M12, M16... |
| Resto | minúsculas | minúsculas |
---
## Archivos
| Ubicación | Archivo | Descripción |
|-----------|---------|-------------|
| HST Server | /hst/map/airtable_map.sql | Schema SQL |
| HST Server | /hst/map/airtable_map_data.sql | Datos (INSERT) |
| R2 | documentos adjuntos/architect/airtable_map.sql | Schema + datos completos |
| R2 | documentos adjuntos/architect/mapeo_simplificado_hst_flg_airtable.md | Tabla MD (4 bases) |
| R2 | documentos adjuntos/architect/mapeo_completo_hst_flg_airtable.md | Tabla MD (8 bases) |
| R2 | documentos adjuntos/architect/proyectos_msn.md | 108 proyectos pendientes |
---
## Pendientes
- [ ] Añadir 108 proyectos al grupo `msn`
- [ ] Sincronización automática bidireccional
- [ ] Webhook para cambios en Airtable
---
## Uso
### Consultar mapeo
```sql
SELECT * FROM map.airtable_map WHERE als LIKE '%spain%';
```
### Obtener ID de Airtable para un tag HST
```sql
SELECT als, airtable_hst_flg, airtable_lumalia
FROM map.airtable_map
WHERE mrf_hst = 'abc123...';
```
### Buscar por ID de Airtable
```sql
SELECT als, mrf_hst
FROM map.airtable_map
WHERE airtable_hst_flg = 'recXXXXXXXX';
```

View File

@@ -0,0 +1,205 @@
# Factory Protocol
**Versión:** 1.0
**Estado:** Especificación
---
## Descripción
THE FACTORY es el sistema de generación iterativa. Implementa un ciclo de mejora continua con Director, Executor, Evaluator y Auditor.
```
┌─────────────────────────────────────────────────────────────────┐
│ THE FACTORY │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ DIRECTOR │───▶│ EXECUTOR │───▶│ EVALUATOR│ │
│ │ (decide) │◀───│ (genera) │◀───│ (evalúa) │ │
│ └────┬─────┘ └──────────┘ └──────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ AUDITOR │ ──▶ SENTINEL │
│ │(registra)│ │
│ └──────────┘ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Componentes
### DIRECTOR
Cerebro de THE FACTORY:
- Recibe jobs de Alfred (DECK) o Clara (CORP)
- Selecciona modelos apropiados
- Decide convergencia
- Gestiona presupuesto e iteraciones
```javascript
// Convergencia si:
// - confidence >= 0.85
// - mejora < 0.02 con confidence > 0.7 (rendimientos decrecientes)
const decision = director.decideConvergence(job, evaluation);
```
### EXECUTOR
Genera artefactos según tipo:
| Función | Modelos |
|---------|---------|
| TEXT_GENERATION | claude-sonnet, claude-opus, gpt-4, llama-3 |
| IMAGE_GENERATION | flux-pro, flux-dev, sdxl, dalle-3 |
| CODE_GENERATION | claude-sonnet, claude-opus, gpt-4 |
| DOCUMENT_GENERATION | claude-opus, gpt-4 |
| AUDIO_GENERATION | elevenlabs, bark, xtts |
| VIDEO_GENERATION | runway, pika, stable-video |
### EVALUATOR
Analiza cada artefacto:
```json
{
"confidence": 0.82,
"strengths": ["Cumple estructura básica", "Lenguaje apropiado"],
"weaknesses": ["Falta detalle en sección X"],
"feedback": "Mejorar especificidad y añadir ejemplos."
}
```
### AUDITOR
Registra eventos para trazabilidad:
- `JOB_CREATED` - Inicio del job
- `JOB_STARTED` - Ejecución iniciada
- `ITERATION_COMPLETED` - Cada iteración
- `JOB_COMPLETED` - Finalización
---
## Ciclo de Iteración
```
1. DIRECTOR recibe job
2. DIRECTOR selecciona modelo para EXECUTOR
3. EXECUTOR genera artefacto
4. EVALUATOR evalúa resultado
5. DIRECTOR decide:
- Converge → Finalizar
- No converge → Volver a paso 3 con feedback
6. AUDITOR registra cada paso
```
---
## Request
```json
{
"contract_version": "2.1",
"profile": "FULL",
"routing": {
"module": "FACTORY",
"version": "1.0"
},
"factory": {
"function": "TEXT_GENERATION",
"objective": "Generar artículo sobre IA",
"constraints": {
"max_iterations": 5,
"min_confidence": 0.85,
"max_cost_units": 1.0
},
"context": {
"style": "profesional",
"length": "1500 palabras",
"audience": "técnico"
}
},
"payload": {
"type": "text",
"content": "Brief del artículo..."
}
}
```
---
## Response
```json
{
"result": {
"status": "SUCCESS",
"content": "Artículo generado...",
"content_hash": "sha256"
},
"factory": {
"iterations": 3,
"final_confidence": 0.89,
"model_used": "claude-opus",
"convergence_reason": "confidence_threshold"
},
"audit": {
"job_id": "uuid",
"events": [
{"type": "JOB_CREATED", "ts": "..."},
{"type": "ITERATION_COMPLETED", "iteration": 1, "confidence": 0.72},
{"type": "ITERATION_COMPLETED", "iteration": 2, "confidence": 0.81},
{"type": "ITERATION_COMPLETED", "iteration": 3, "confidence": 0.89},
{"type": "JOB_COMPLETED", "ts": "..."}
]
},
"performance": {
"total_ms": 45000,
"cost_units": 0.45
}
}
```
---
## Convergencia
| Condición | Acción |
|-----------|--------|
| confidence >= threshold | Converge |
| mejora < 0.02 && confidence > 0.7 | Converge (rendimientos decrecientes) |
| iteraciones >= max | Converge forzado |
| costo >= max | Converge forzado |
---
## Configuración
```yaml
factory:
default_max_iterations: 5
default_min_confidence: 0.85
default_max_cost: 1.0
convergence:
confidence_threshold: 0.85
diminishing_returns_threshold: 0.02
diminishing_returns_min_confidence: 0.7
models:
text:
primary: claude-opus
fallback: [claude-sonnet, gpt-4]
image:
primary: flux-pro
fallback: [flux-dev, sdxl]
```

View File

@@ -0,0 +1,125 @@
# GPU Services
**Plataforma:** RunPod
**Estado:** Operativo
---
## Servicios
| Servicio | Endpoint ID | GPU | Workers | Función |
|----------|-------------|-----|---------|---------|
| **Grace** | {grace_id} | NVIDIA L4 | 2 | Procesamiento IA |
| **Penny** | 0mxhaokgsmgee3 | NVIDIA L4 | 2 | Asistente voz |
| **The Factory** | {factory_id} | NVIDIA L4 | 2 | Generación iterativa |
---
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ RunPod │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ GRACE │ │ PENNY │ │ FACTORY │ │
│ │ │ │ │ │ │ │
│ │ 18 módulos │ │ ASR + TTS │ │ Iterativo │ │
│ │ NVIDIA L4 │ │ + Claude │ │ NVIDIA L4 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
▲ ▲ ▲
│ │ │
└──────────────────┼──────────────────┘
┌───────┴───────┐
│ S-CONTRACT │
│ v2.1 │
└───────────────┘
┌──────────────┴──────────────┐
│ │
┌────┴────┐ ┌────┴────┐
│ DECK │ │ CORP │
│ Alfred │ │ Jared │
└─────────┘ └─────────┘
```
---
## Llamada a Servicio
### URL Base
```
https://api.runpod.ai/v2/{endpoint_id}/runsync
```
### Headers
```
Authorization: Bearer {RUNPOD_API_KEY}
Content-Type: application/json
```
### Request
```json
{
"input": {
"contract": {
"contract_version": "2.1",
"source": { "system": "DECK" },
"target": { "service": "GRACE", "module": "SUMMARIZER" },
"input": { "type": "text", "data": "..." }
}
}
}
```
### Response
```json
{
"id": "job_id",
"status": "COMPLETED",
"output": {
"status": "completed",
"output": { "data": "..." },
"usage": { "cost_usd": 0.002 }
}
}
```
---
## Modos de Ejecución
| Modo | Endpoint | Uso |
|------|----------|-----|
| **runsync** | /runsync | Espera respuesta |
| **run** | /run | Asíncrono, devuelve job_id |
| **status** | /status/{job_id} | Consultar estado |
---
## Costes
| Recurso | Coste |
|---------|-------|
| NVIDIA L4 | ~$0.20/hora |
| Worker idle | $0 (serverless) |
| Por request | Variable según tokens |
---
## Monitoreo
```bash
# Estado de endpoints
curl -H "Authorization: Bearer $RUNPOD_API_KEY" \
https://api.runpod.ai/v2/{endpoint_id}/health
```

162
05_INTEGRACIONES/hst-api.md Normal file
View File

@@ -0,0 +1,162 @@
# HST API
**Base URL:** https://tzrtech.org/api
**Estado:** Implementado
---
## Endpoints
### Listar Tags
```
GET /tags
```
**Query params:**
| Param | Tipo | Descripción |
|-------|------|-------------|
| grupo | string | Filtrar por grupo (hst, spe, vsn, flg, vue) |
| activo | boolean | Solo activos |
| limit | integer | Límite de resultados |
**Response:**
```json
{
"tags": [
{
"ref": "person",
"h_maestro": "a1b2c3...",
"grupo": "hst",
"nombre_es": "Persona",
"nombre_en": "Person",
"imagen_url": "https://tzrtech.org/a1b2c3...png"
}
],
"total": 639
}
```
---
### Obtener Tag
```
GET /tags/{ref}
```
**Response:**
```json
{
"ref": "person",
"h_maestro": "a1b2c3...",
"grupo": "hst",
"nombre_es": "Persona",
"nombre_en": "Person",
"descripcion": "...",
"imagen_url": "https://tzrtech.org/a1b2c3...png",
"activo": true,
"version": 1
}
```
---
### Buscar Tags
```
GET /tags/search?q={query}
```
**Response:**
```json
{
"query": "person",
"results": [
{ "ref": "person", "score": 1.0 },
{ "ref": "people", "score": 0.8 }
]
}
```
---
### Biblioteca de Usuario
```
GET /biblioteca
```
**Headers:**
```
Authorization: Bearer {token}
```
**Response:**
```json
{
"user_id": 123,
"tags": [
{
"ref": "mi_tag",
"h_usuario": "def456...",
"nombre": "Mi Tag Personal"
}
]
}
```
---
### Crear Tag de Usuario
```
POST /biblioteca
```
**Body:**
```json
{
"ref": "mi_tag",
"nombre": "Mi Tag Personal",
"metadata": {}
}
```
**Response:**
```json
{
"ref": "mi_tag",
"h_usuario": "def456...",
"created": true
}
```
---
## Autenticación
| Endpoint | Auth |
|----------|------|
| GET /tags | Pública |
| GET /tags/{ref} | Pública |
| GET /tags/search | Pública |
| GET /biblioteca | Token requerido |
| POST /biblioteca | Token requerido |
---
## Rate Limits
| Tipo | Límite |
|------|--------|
| Público | 100 req/min |
| Autenticado | 1000 req/min |

250
05_INTEGRACIONES/notario.md Normal file
View File

@@ -0,0 +1,250 @@
# Notario
**Versión:** 2.0
**Estado:** Especificación
---
## Descripción
Sistema de sellado inmutable en blockchain. Última capa de confianza del ecosistema.
```
┌─────────────────────────────────────────────────────────────────┐
│ PRINCIPIO NOTARIO │
│ │
│ "Lo que NOTARIO sella, nadie lo altera" │
└─────────────────────────────────────────────────────────────────┘
```
---
## Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ NOTARIO │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Feldman (bloques consolidados) │
│ │ │
│ │ (auditados por SENTINEL) │
│ ▼ │
│ ┌─────────────────┐ │
│ │ BATCH COLLECTOR │ Agrupa por ventana temporal │
│ └─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ MERKLE BUILDER │ Construye árbol Merkle │
│ └─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ BLOCKCHAIN TX │ Publica hash raíz │
│ └─────────────────┘ │
│ │ │
│ ▼ │
│ Registro actualizado con blockchain_tx_ref │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Dos Franjas Temporales
### Franja Interna
Tiempo del sistema para:
- Procesar operaciones
- Ejecutar auditoría SENTINEL
- Consolidar en Feldman
**Duración:** Minutos a horas
### Franja Blockchain
Tiempo de NOTARIO para:
- Agrupar registros en batches
- Construir pruebas criptográficas
- Publicar en blockchain
- Confirmar transacciones
**Duración:** Horas a días
---
## Ciclo de Sellado
```
1. RECOLECTAR
SELECT FROM feldman_bloques
WHERE audit_status = 'DEEP_PASS'
AND blockchain_tx_ref IS NULL
2. AGRUPAR
Crear batch con ventana temporal (ej: 24h)
Asignar notario_batch_id
3. CONSTRUIR MERKLE
- Ordenar registros por h_bloque
- Calcular hash de cada registro
- Construir árbol binario
- Obtener merkle_root
4. FIRMAR
- Firmar merkle_root con llave NOTARIO
- Generar timestamp certificado
5. PUBLICAR
- Enviar transacción a blockchain
- Esperar confirmaciones
6. ACTUALIZAR
UPDATE feldman_bloques SET blockchain_tx_ref = tx_hash
```
---
## Schema SQL
```sql
CREATE TABLE notario_batches (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
batch_id UUID UNIQUE NOT NULL,
-- Ventana temporal
window_start TIMESTAMPTZ NOT NULL,
window_end TIMESTAMPTZ NOT NULL,
-- Contenido
records_count INTEGER NOT NULL,
bloque_hashes TEXT[] NOT NULL,
-- Merkle
merkle_root CHAR(64) NOT NULL,
merkle_tree JSONB,
-- Firma
signature TEXT NOT NULL,
signing_key_id VARCHAR(100),
signed_at TIMESTAMPTZ NOT NULL,
-- Blockchain
blockchain_network VARCHAR(50) DEFAULT 'ethereum',
blockchain_tx_ref VARCHAR(100),
blockchain_block BIGINT,
blockchain_timestamp TIMESTAMPTZ,
confirmations INTEGER DEFAULT 0,
-- Estado
status VARCHAR(20) DEFAULT 'PENDING',
created_at TIMESTAMPTZ DEFAULT NOW(),
CONSTRAINT valid_status CHECK (
status IN ('PENDING', 'SUBMITTED', 'CONFIRMED', 'FAILED')
)
);
CREATE INDEX idx_notario_status ON notario_batches(status);
CREATE INDEX idx_notario_window ON notario_batches(window_start, window_end);
```
---
## Verificación de Integridad
```python
def verify_record_integrity(h_bloque, notario_batch_id):
# 1. Obtener batch
batch = get_batch(notario_batch_id)
# 2. Verificar que h_bloque está en el batch
assert h_bloque in batch.bloque_hashes
# 3. Obtener registro de Feldman
record = get_feldman_record(h_bloque)
# 4. Calcular hash del registro
record_hash = sha256(serialize(record))
# 5. Verificar inclusión en merkle tree
proof = get_merkle_proof(batch.merkle_tree, h_bloque)
assert verify_merkle_proof(record_hash, proof, batch.merkle_root)
# 6. Verificar firma del batch
assert verify_signature(
batch.merkle_root,
batch.signature,
batch.signing_key_id
)
# 7. Verificar que merkle_root está en blockchain
tx = get_blockchain_tx(batch.blockchain_tx_ref)
assert tx.data == batch.merkle_root
return True
```
---
## Integración con S-CONTRACT
### Campos en Response (pre-sellado)
```json
"audit": {
"blockchain_pending": true,
"blockchain_tx_ref": null,
"notario_batch_id": "uuid-batch"
}
```
### Campos post-sellado
```json
"audit": {
"blockchain_pending": false,
"blockchain_tx_ref": "0x1234...abcd",
"notario_batch_id": "uuid-batch"
}
```
---
## Configuración
```yaml
notario:
enabled: true
# Ventana de agregación
batch_window_hours: 24
min_records_per_batch: 10
max_records_per_batch: 10000
# Blockchain
network: ethereum
contract_address: "0x..."
gas_limit: 100000
# Firma
signing_key: kv://production/signing/notario
# Reintentos
max_retries: 3
retry_delay_minutes: 60
```
---
## Pendiente
- [ ] Crear tabla notario_batches
- [ ] Implementar recolector de registros
- [ ] Implementar constructor Merkle tree
- [ ] Configurar llave de firma
- [ ] Integrar con proveedor blockchain
- [ ] Implementar verificador de integridad
- [ ] Crear workflow de sellado periódico

View File

@@ -1,422 +0,0 @@
# Backup y Recovery TZZR
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Principio Fundamental
> **Cada instancia es responsable de su propio backup.**
DECK y CORP son instancias autónomas. No dependen de ARCHITECT para hacer backups.
Cada servidor ejecuta su script de backup localmente y sube directamente a R2.
---
## Estado Actual
### Backups Existentes
| Sistema | Backup | Destino | Frecuencia | Estado |
|---------|--------|---------|------------|--------|
| Gitea | Sí | R2 | Manual | Operativo |
| PostgreSQL ARCHITECT | No | - | - | **CRÍTICO** |
| PostgreSQL DECK | No | - | - | **CRÍTICO** |
| PostgreSQL CORP | No | - | - | **CRÍTICO** |
| PostgreSQL HST | No | - | - | **CRÍTICO** |
| R2 buckets | Built-in | R2 | Automático | Operativo |
---
## Arquitectura de Backups
```
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ ARCHITECT │ │ DECK │ │ CORP │
│ │ │ │ │ │
│ backup.sh ───┼────►│ backup.sh ───┼────►│ backup.sh ───┼────► R2
│ (local) │ │ (local) │ │ (local) │
└──────────────┘ └──────────────┘ └──────────────┘
│ │
▼ ▼
Sin dependencia Sin dependencia
de ARCHITECT de ARCHITECT
```
---
## Backup por Servidor (LOCAL)
### ARCHITECT (69.62.126.110)
**Ubicación script:** `/opt/scripts/backup_postgres.sh`
```bash
#!/bin/bash
# Ejecutar EN ARCHITECT - backup local
set -e
DATE=$(date +%F)
# Credenciales R2 (desde Vaultwarden local o .env)
source /opt/architect/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
R2_ENDPOINT="https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com"
# Backup local
sudo -u postgres pg_dump architect | gzip > /tmp/architect_$DATE.sql.gz
# Subir a R2
aws s3 cp /tmp/architect_$DATE.sql.gz s3://architect/backups/postgres/ \
--endpoint-url $R2_ENDPOINT
rm /tmp/architect_$DATE.sql.gz
echo "ARCHITECT backup completado: $DATE"
```
### DECK (72.62.1.113)
**Ubicación script:** `/opt/scripts/backup_postgres.sh`
```bash
#!/bin/bash
# Ejecutar EN DECK - backup local (NO depende de ARCHITECT)
set -e
DATE=$(date +%F)
# Credenciales R2 (desde Vaultwarden DECK)
source /opt/deck/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
R2_ENDPOINT="https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com"
# Backup local
sudo -u postgres pg_dump tzzr | gzip > /tmp/deck_tzzr_$DATE.sql.gz
# Subir a R2 (bucket propio de DECK)
aws s3 cp /tmp/deck_tzzr_$DATE.sql.gz s3://deck/backups/postgres/ \
--endpoint-url $R2_ENDPOINT
rm /tmp/deck_tzzr_$DATE.sql.gz
echo "DECK backup completado: $DATE"
```
### CORP (92.112.181.188)
**Ubicación script:** `/opt/scripts/backup_postgres.sh`
```bash
#!/bin/bash
# Ejecutar EN CORP - backup local (NO depende de ARCHITECT)
set -e
DATE=$(date +%F)
# Credenciales R2 (desde Vaultwarden CORP)
source /opt/corp/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
R2_ENDPOINT="https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com"
# Backup local
sudo -u postgres pg_dump corp | gzip > /tmp/corp_$DATE.sql.gz
# Subir a R2 (bucket propio de CORP)
aws s3 cp /tmp/corp_$DATE.sql.gz s3://corp/backups/postgres/ \
--endpoint-url $R2_ENDPOINT
rm /tmp/corp_$DATE.sql.gz
echo "CORP backup completado: $DATE"
```
### HST (72.62.2.84)
**Ubicación script:** `/opt/scripts/backup_postgres.sh`
```bash
#!/bin/bash
# Ejecutar EN HST - backup local
set -e
DATE=$(date +%F)
source /opt/hst/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
R2_ENDPOINT="https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com"
sudo -u postgres pg_dump hst_images | gzip > /tmp/hst_$DATE.sql.gz
aws s3 cp /tmp/hst_$DATE.sql.gz s3://hst/backups/postgres/ \
--endpoint-url $R2_ENDPOINT
rm /tmp/hst_$DATE.sql.gz
echo "HST backup completado: $DATE"
```
---
## Cron en Cada Servidor
Cada instancia configura su propio cron:
```bash
# /etc/cron.d/tzzr-backup (en cada servidor)
# Backup diario a las 3:00 AM
0 3 * * * root /opt/scripts/backup_postgres.sh >> /var/log/backup.log 2>&1
```
---
## Gitea Backup
### Backup Manual
```bash
# En ARCHITECT
docker exec -t gitea bash -c 'gitea dump -c /data/gitea/conf/app.ini'
docker cp gitea:/app/gitea/gitea-dump-*.zip ./
# Subir a R2
aws s3 cp gitea-dump-*.zip s3://architect/backups/gitea/ \
--endpoint-url $R2_ENDPOINT
```
### Backup Automático
```bash
#!/bin/bash
# /opt/scripts/backup_gitea.sh
DATE=$(date +%F_%H%M)
# Crear dump
docker exec -t gitea bash -c "gitea dump -c /data/gitea/conf/app.ini -f /tmp/gitea-dump-$DATE.zip"
# Copiar fuera del container
docker cp gitea:/tmp/gitea-dump-$DATE.zip /tmp/
# Subir a R2
source /home/orchestrator/orchestrator/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
aws s3 cp /tmp/gitea-dump-$DATE.zip s3://architect/backups/gitea/ \
--endpoint-url https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
# Cleanup
rm /tmp/gitea-dump-$DATE.zip
docker exec gitea rm /tmp/gitea-dump-$DATE.zip
```
---
## Estructura de Backups en R2
Cada instancia usa su propio bucket:
```
s3://architect/backups/
├── postgres/
│ └── architect_2024-12-24.sql.gz
└── gitea/
└── gitea-dump-2024-12-24_0300.zip
s3://deck/backups/
└── postgres/
└── deck_tzzr_2024-12-24.sql.gz
s3://corp/backups/
└── postgres/
└── corp_2024-12-24.sql.gz
s3://hst/backups/
└── postgres/
└── hst_2024-12-24.sql.gz
```
> **Nota:** Cada instancia es dueña de sus backups. No hay dependencia cruzada.
---
## Retención de Backups
### Política Propuesta
| Tipo | Retención | Notas |
|------|-----------|-------|
| Diario | 7 días | Últimos 7 backups |
| Semanal | 4 semanas | Domingos |
| Mensual | 12 meses | Primer día del mes |
### Script de Limpieza
```bash
#!/bin/bash
# /opt/scripts/cleanup_backups.sh
source /home/orchestrator/orchestrator/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
R2_ENDPOINT="https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com"
# Eliminar backups más antiguos de 30 días
# (Implementar con lifecycle rules de R2 preferentemente)
aws s3 ls s3://architect/backups/postgres/ --endpoint-url $R2_ENDPOINT | \
while read -r line; do
createDate=$(echo $line | awk '{print $1}')
fileName=$(echo $line | awk '{print $4}')
# Comparar fechas y eliminar si > 30 días
# ...
done
```
---
## Recovery
### PostgreSQL - Restaurar Base de Datos
```bash
# Descargar backup
aws s3 cp s3://architect/backups/postgres/architect_2024-12-24.sql.gz . \
--endpoint-url $R2_ENDPOINT
# Descomprimir
gunzip architect_2024-12-24.sql.gz
# Restaurar (¡CUIDADO! Sobrescribe datos existentes)
sudo -u postgres psql -d architect < architect_2024-12-24.sql
```
### PostgreSQL - Restaurar a Nueva Base
```bash
# Crear nueva base de datos
sudo -u postgres createdb architect_restored
# Restaurar
gunzip -c architect_2024-12-24.sql.gz | sudo -u postgres psql -d architect_restored
```
### Gitea - Restaurar
```bash
# Descargar backup
aws s3 cp s3://architect/backups/gitea/gitea-dump-2024-12-24_0300.zip . \
--endpoint-url $R2_ENDPOINT
# Detener Gitea
docker stop gitea
# Copiar al container
docker cp gitea-dump-2024-12-24_0300.zip gitea:/tmp/
# Restaurar
docker exec gitea bash -c "cd /tmp && unzip gitea-dump-2024-12-24_0300.zip"
# Seguir instrucciones de Gitea para restore
# Iniciar Gitea
docker start gitea
```
---
## Disaster Recovery Plan
### Escenario 1: Pérdida de ARCHITECT
1. Provisionar nuevo VPS con misma IP (si posible)
2. Instalar Ubuntu 22.04
3. Configurar usuario orchestrator
4. Restaurar PostgreSQL desde R2
5. Restaurar Gitea desde R2
6. Reinstalar Docker y servicios
7. Verificar conectividad con DECK/CORP/HST
### Escenario 2: Pérdida de DECK
1. Provisionar nuevo VPS
2. Restaurar PostgreSQL (tzzr) desde backup
3. Reinstalar CLARA, ALFRED
4. Reinstalar Mailcow (requiere backup separado)
5. Actualizar DNS si IP cambió
### Escenario 3: Pérdida de CORP
1. Provisionar nuevo VPS
2. Restaurar PostgreSQL (corp) desde backup
3. Reinstalar MARGARET, JARED, MASON, FELDMAN
4. Reinstalar Odoo, Nextcloud
5. Activar UFW (nuevo servidor)
### Escenario 4: Pérdida de R2
**IMPROBABLE** - Cloudflare tiene redundancia multi-región.
Mitigación: Backup mensual a segundo proveedor (AWS S3 Glacier).
---
## Verificación de Backups
### Test Mensual
```bash
#!/bin/bash
# /opt/scripts/verify_backup.sh
# Descargar último backup
LATEST=$(aws s3 ls s3://architect/backups/postgres/ --endpoint-url $R2_ENDPOINT | \
sort | tail -1 | awk '{print $4}')
aws s3 cp s3://architect/backups/postgres/$LATEST /tmp/ \
--endpoint-url $R2_ENDPOINT
# Verificar integridad
gunzip -t /tmp/$LATEST
if [ $? -eq 0 ]; then
echo "Backup válido: $LATEST"
else
echo "ERROR: Backup corrupto: $LATEST"
# Enviar alerta
fi
rm /tmp/$LATEST
```
### Checklist de Verificación
- [ ] Backup PostgreSQL ARCHITECT existe (< 24h)
- [ ] Backup PostgreSQL DECK existe (< 24h)
- [ ] Backup PostgreSQL CORP existe (< 24h)
- [ ] Backup Gitea existe (< 7d)
- [ ] Integridad verificada (gunzip -t)
- [ ] Restore test exitoso (mensual)
---
## Alertas
### Configuración ntfy
```bash
# Notificar si backup falla
if [ $? -ne 0 ]; then
curl -d "Backup FALLIDO: $DATE" ntfy.sh/tzzr-alerts
fi
```
### Monitoreo
```bash
# Verificar último backup
aws s3 ls s3://architect/backups/postgres/ --endpoint-url $R2_ENDPOINT | \
sort | tail -5
```

View File

@@ -1,383 +0,0 @@
# Infraestructura TZZR
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Resumen de Servidores
| Servidor | IP Pública | Rol | Proveedor |
|----------|------------|-----|-----------|
| ARCHITECT | 69.62.126.110 | Coordinador central | VPS |
| DECK | 72.62.1.113 | Personal | VPS |
| CORP | 92.112.181.188 | Empresarial | VPS |
| HST | 72.62.2.84 | API Tags | VPS |
| LOCKER | R2 | Almacenamiento | Cloudflare |
---
## ARCHITECT (69.62.126.110)
### Especificaciones
- **OS:** Ubuntu 22.04 LTS
- **Usuario:** orchestrator
- **Servicios:** PostgreSQL, Gitea, Orchestrator, Infisical
### Puertos
| Puerto | Servicio | Estado |
|--------|----------|--------|
| 22 | SSH | Abierto |
| 2222 | Gitea SSH | Abierto |
| 3000 | Gitea HTTP | Abierto |
| 5050 | Orchestrator | Abierto |
| 5432 | PostgreSQL | **CRÍTICO: 0.0.0.0** |
| 8082 | Infisical | Abierto |
### Acceso
```bash
ssh orchestrator@69.62.126.110
```
### PostgreSQL
```bash
sudo -u postgres psql -d architect
```
### Gitea
```
URL: http://localhost:3000
Token lectura: 5ca10e5b71d41f9b22f12d0f96bfc2e6de5c2c7f
Token escritura: ac5a604b9aac5cee81192a656fc918f9efa3834b
```
---
## DECK (72.62.1.113)
### Especificaciones
- **OS:** Ubuntu 22.04 LTS
- **Usuario:** root
- **Servicios:** CLARA, ALFRED, Mailcow, Directus, etc.
### Puertos
| Puerto | Servicio | Estado |
|--------|----------|--------|
| 22 | SSH | Abierto |
| 25 | SMTP | Abierto |
| 143 | IMAP | Abierto |
| 465 | SMTPS | Abierto |
| 587 | Submission | Abierto |
| 993 | IMAPS | Abierto |
| 5051 | CLARA | Abierto |
| 5052 | ALFRED | Abierto |
| 8055 | Directus | Abierto |
| 8080 | ntfy | Abierto |
| 8082 | FileBrowser | Abierto |
| 8083 | Shlink | Abierto |
| 8085 | Vaultwarden | Abierto |
### Acceso
```bash
ssh -i ~/.ssh/tzzr root@72.62.1.113
```
### Docker Containers
```bash
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
```
---
## CORP (92.112.181.188)
### Especificaciones
- **OS:** Ubuntu 22.04 LTS
- **Usuario:** root
- **Servicios:** MARGARET, JARED, MASON, FELDMAN, Odoo, Nextcloud
### Puertos
| Puerto | Servicio | Estado |
|--------|----------|--------|
| 22 | SSH | Abierto |
| 80 | Caddy HTTP | Abierto |
| 443 | Caddy HTTPS | Abierto |
| 5051 | MARGARET | Abierto |
| 5052 | JARED | Abierto |
| 5053 | MASON | Abierto |
| 5054 | FELDMAN | Abierto |
| 5432 | PostgreSQL | Local |
| 8055 | Directus | Abierto |
| 8069 | Odoo | Abierto |
| 8080 | Nextcloud | Abierto |
| 8081 | Vaultwarden | Abierto |
### Acceso
```bash
ssh -i ~/.ssh/tzzr root@92.112.181.188
```
### Firewall
**ALERTA CRÍTICA: UFW INACTIVO**
```bash
# Verificar estado
ufw status
# Activar (cuando se autorice)
ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
```
---
## HST (72.62.2.84)
### Especificaciones
- **OS:** Ubuntu 22.04 LTS
- **Usuario:** root
- **Servicios:** Nginx, Directus, PostgreSQL
### Puertos
| Puerto | Servicio | Estado |
|--------|----------|--------|
| 22 | SSH | Abierto |
| 80 | Nginx HTTP | Abierto |
| 443 | Nginx HTTPS | Abierto |
| 5432 | PostgreSQL | Local |
| 8055 | Directus | Abierto |
### Acceso
```bash
ssh -i ~/.ssh/tzzr root@72.62.2.84
```
### API Pública
```
https://tzrtech.org/{h_maestro}.png
```
### Estadísticas HST
| Grupo | Cantidad |
|-------|----------|
| hst | 639 |
| spe | 145 |
| vsn | 84 |
| flg | 65 |
| vue | 21 |
| **Total** | **973** |
---
## LOCKER (Cloudflare R2)
### Endpoint
```
https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
```
### Buckets
| Bucket | Uso | Tamaño Aprox |
|--------|-----|--------------|
| architect | Backups, configs, GPU services | ~500 MB |
| deck | Archivos personales (CLARA) | Variable |
| corp | Archivos empresariales (MARGARET) | Variable |
| hst | Imágenes de tags | ~100 MB |
| locker | Almacenamiento general | Variable |
### Acceso
```bash
source /home/orchestrator/orchestrator/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
aws s3 ls s3://architect/ \
--endpoint-url https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
```
---
## SSH Keys
### Ubicación
```
/home/orchestrator/.ssh/tzzr # Private key
/home/orchestrator/.ssh/tzzr.pub # Public key
```
### Permisos
```bash
chmod 600 ~/.ssh/tzzr
chmod 644 ~/.ssh/tzzr.pub
```
### Configuración SSH
```bash
# ~/.ssh/config
Host deck
HostName 72.62.1.113
User root
IdentityFile ~/.ssh/tzzr
Host corp
HostName 92.112.181.188
User root
IdentityFile ~/.ssh/tzzr
Host hst
HostName 72.62.2.84
User root
IdentityFile ~/.ssh/tzzr
```
---
## Bases de Datos
### architect (ARCHITECT)
```
Host: localhost
Port: 5432
Database: architect
User: postgres
```
Tablas principales:
- context_blocks
- agents
- creds_*
### tzzr (DECK)
```
Host: localhost
Port: 5432
Database: tzzr
```
Tablas principales:
- clara_log
- deck_visiones
- deck_milestones
### corp (CORP)
```
Host: localhost
Port: 5432
Database: corp
```
Tablas principales:
- margaret_log
- mason_workspace
- feldman_cola
- milestones
- bloques
### hst_images (HST)
```
Host: localhost
Port: 5432
Database: hst_images
```
Tablas principales:
- hst_tags
- hst_trees
---
## Monitoreo
### Comandos de Estado
```bash
# Verificar servicios ARCHITECT
systemctl status postgresql
docker ps
# Verificar servicios DECK
ssh deck 'docker ps'
ssh deck 'systemctl status fail2ban'
# Verificar servicios CORP
ssh corp 'docker ps'
ssh corp 'ufw status'
# Verificar servicios HST
ssh hst 'systemctl status nginx'
ssh hst 'systemctl status postgresql'
```
### Logs Importantes
```bash
# PostgreSQL
journalctl -u postgresql -f
# Docker containers
docker logs <container> -f
# Nginx (HST)
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
# SSH auth
tail -f /var/log/auth.log
```
---
## Diagrama de Red
```
Internet
┌──────────────────────────┼──────────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ ARCHITECT │ │ DECK │ │ CORP │
│ 69.62.126.110 │◄────────│ 72.62.1.113 │────────►│92.112.181.188 │
└───────────────┘ SSH └───────────────┘ SSH └───────────────┘
│ │ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ HST │ │
└────────────────►│ 72.62.2.84 │◄──────────────────┘
SSH └───────────────┘
│ HTTPS
┌───────────────┐
│ Cloudflare │
│ R2 │
└───────────────┘
```

View File

@@ -1,179 +0,0 @@
# GPU Services - RunPod
**Versión:** 5.0
**Fecha:** 2024-12-24
---
## Estado Crítico
**ALERTA: RunPod NO es confiable para producción.**
### Incidente 2024-12-24
RunPod falló en provisionar workers a pesar de:
- Configuración correcta
- Balance suficiente ($72+)
- Jobs en cola
**Resultado:** 0 workers activos. Servicio GPU inoperativo.
---
## Endpoints Configurados
| Servicio | Endpoint ID | Estado |
|----------|-------------|--------|
| GRACE | r00x4g3rrwkbyh | Inactivo |
| PENNY | 0mxhaokgsmgee3 | Inactivo |
| FACTORY | ddnuk6y35zi56a | Inactivo |
---
## GRACE (Extracción IA)
### Módulos Implementados (6 de 18)
| Módulo | Descripción |
|--------|-------------|
| ASR | Speech-to-text |
| OCR | Reconocimiento texto |
| TTS | Text-to-speech |
| Face | Reconocimiento facial |
| Embeddings | Vectores semánticos |
| Avatar | Generación avatares |
### Módulos Pendientes (12)
- Document parsing
- Image classification
- Object detection
- Sentiment analysis
- Named entity recognition
- Translation
- Summarization
- Question answering
- Code generation
- Audio classification
- Video analysis
- Multimodal fusion
---
## Código Disponible en R2
Los handlers están listos y son portables:
```
s3://architect/gpu-services/
├── base/
│ └── bootstrap.sh
├── grace/
│ └── code/handler.py
├── penny/
│ └── code/handler.py
└── factory/
└── code/handler.py
```
### Descargar Código
```bash
source /home/orchestrator/orchestrator/.env
export AWS_ACCESS_KEY_ID="$R2_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="$R2_SECRET_KEY"
aws s3 sync s3://architect/gpu-services/ ./gpu-services/ \
--endpoint-url https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
```
---
## Alternativas a Evaluar
### 1. Modal (Recomendado)
- Pricing: Pay-per-use
- Pros: Serverless real, buen DX, Python-native
- Contras: Menos GPUs disponibles que RunPod
```python
import modal
stub = modal.Stub("grace")
@stub.function(gpu="A10G")
def process_asr(audio_bytes):
# Whisper inference
pass
```
### 2. Replicate
- Pricing: Per-inference
- Pros: Modelos pre-entrenados, API simple
- Contras: Menos control, más caro a escala
### 3. Lambda Labs
- Pricing: Hourly
- Pros: Hardware dedicado
- Contras: Menos flexible, reserva manual
### 4. Self-Hosted
- Pricing: Upfront + hosting
- Pros: Control total, sin dependencias
- Contras: CapEx alto, mantenimiento
---
## Migración Propuesta
### Fase 1: Evaluación (1 semana)
- [ ] Probar Modal con ASR handler
- [ ] Comparar latencia y costo
### Fase 2: Migración (2 semanas)
- [ ] Portar 6 handlers a Modal
- [ ] Actualizar endpoints en MASON
### Fase 3: Producción
- [ ] Desplegar en Modal
- [ ] Deprecar RunPod endpoints
---
## Configuración Actual RunPod
### API Key
```
Almacenada en: creds_runpod (PostgreSQL ARCHITECT)
Campo: api_key_runpod
```
### SDK
```python
import runpod
runpod.api_key = "..."
# Crear job
job = runpod.run(
endpoint_id="r00x4g3rrwkbyh",
input={"audio": "base64..."}
)
# Check status
status = runpod.status(job["id"])
```
---
## Recomendación
**NO confiar en RunPod para producción.**
Migrar a Modal como prioridad alta una vez resueltos los issues de seguridad críticos.

67
06_SEGURIDAD/README.md Normal file
View File

@@ -0,0 +1,67 @@
# 06 - Seguridad
> Cifrado, gestión de secretos, modelo de amenazas y respuesta a incidentes
## Contenido
| Documento | Descripción |
|-----------|-------------|
| [inmutabilidad.md](inmutabilidad.md) | Principios de inmutabilidad, cadena de hashes |
| [secretos.md](secretos.md) | Gestión con Infisical, categorías de credenciales |
| [cifrado.md](cifrado.md) | Envelope encryption, KEK, algoritmos |
| [rotacion.md](rotacion.md) | Políticas de rotación de claves |
| [modelo-amenazas.md](modelo-amenazas.md) | Análisis de riesgos y mitigaciones |
| [respuesta-incidentes.md](respuesta-incidentes.md) | Procedimientos ante incidentes |
## Principios de Seguridad
1. **Inmutabilidad**: Los registros consolidados no se modifican
2. **Cifrado en reposo**: Datos sensibles cifrados con AES-256-GCM
3. **Cifrado en tránsito**: TLS 1.3 para todas las comunicaciones
4. **Mínimo privilegio**: Acceso solo a lo necesario
5. **Trazabilidad**: Toda acción queda registrada
## Arquitectura de Cifrado
```
┌─────────────────────────────────────────┐
│ Master Key (HSM) │
└─────────────────┬───────────────────────┘
┌─────────▼─────────┐
│ KEK (Key Enc.) │
└─────────┬─────────┘
┌─────────────┼─────────────┐
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│ DEK 1 │ │ DEK 2 │ │ DEK N │
└───────┘ └───────┘ └───────┘
│ │ │
▼ ▼ ▼
Data Data Data
```
## Gestión de Secretos
**Herramienta**: Infisical
| Categoría | Ejemplos | Rotación |
|-----------|----------|----------|
| API Keys | OpenAI, Anthropic, RunPod | 90 días |
| DB Credentials | PostgreSQL users | 30 días |
| Storage | R2 access keys | 180 días |
| SSH Keys | Acceso a servidores | 365 días |
## Modelo de Amenazas
| Amenaza | Probabilidad | Impacto | Mitigación |
|---------|--------------|---------|------------|
| Acceso no autorizado | Media | Alto | MFA, logs, alertas |
| Pérdida de datos | Baja | Crítico | Backups 3-2-1 |
| Compromiso de keys | Baja | Alto | Rotación, Infisical |
| Denegación de servicio | Media | Medio | Rate limiting, CDN |
---
[← Volver al índice](../README.md)

170
06_SEGURIDAD/cifrado.md Normal file
View File

@@ -0,0 +1,170 @@
# Cifrado
**Estado:** Especificación
---
## Principio KEY VAULT
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ "Las llaves nunca viajan con los datos que protegen" │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Envelope Encryption
### Jerarquía de Llaves
```
MASTER KEY (MK)
(HSM / KMS externo)
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
KEK-DATA KEK-SECRETS KEK-SIGNING
(Cifra (Cifra API (Firma
datos) keys) tokens)
│ │ │
▼ ▼ ▼
DEK-1..n API Keys JWT Keys
(Efímeras) (Rotables) (Rotables)
```
---
## Niveles
### 1. MASTER KEY (MK)
| Aspecto | Valor |
|---------|-------|
| Almacenamiento | HSM/KMS externo |
| Exposición | Nunca se expone |
| Rotación | Anual |
| Uso | Deriva KEKs |
### 2. Key Encryption Keys (KEK)
| KEK | Función | Rotación |
|-----|---------|----------|
| KEK-DATA | Cifra datos | 365 días |
| KEK-SECRETS | Cifra API keys | 365 días |
| KEK-SIGNING | Firma tokens | 180 días |
### 3. Data Encryption Keys (DEK)
| Aspecto | Valor |
|---------|-------|
| Generación | Por operación |
| Cifrado | Con KEK correspondiente |
| Rotación | Por uso (efímeras) |
---
## Ventajas de Envelope Encryption
| Ventaja | Descripción |
|---------|-------------|
| **Rotación eficiente** | Rotar KEKs sin re-cifrar todos los datos |
| **Separación** | Diferentes KEKs para diferentes propósitos |
| **Trazabilidad** | Cada nivel tiene su propio ciclo de vida |
| **Seguridad en capas** | Compromiso de DEK no expone otras DEKs |
---
## Cifrado en Reposo
### Base de Datos
| Componente | Cifrado |
|------------|---------|
| PostgreSQL | Transparent Data Encryption (TDE) |
| Backups | AES-256-GCM con KEK-DATA |
| Logs sensibles | AES-256-GCM con KEK-DATA |
### Almacenamiento
| Componente | Cifrado |
|------------|---------|
| Cloudflare R2 | SSE con llaves gestionadas |
| Backups locales | AES-256-GCM |
| Archivos temporales | Cifrado en memoria |
---
## Cifrado en Tránsito
| Conexión | Protocolo |
|----------|-----------|
| HTTPS | TLS 1.3 |
| PostgreSQL | SSL required |
| Redis | TLS |
| SSH | Ed25519 |
---
## Gestión de Llaves
### Ubicación
| Llave | Ubicación |
|-------|-----------|
| MASTER KEY | HSM / KMS externo |
| KEKs | Infisical (cifradas) |
| DEKs | Generadas en runtime |
| API Keys | Infisical |
### Acceso
```
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Servicio │────▶│ Infisical │────▶│ KEK/DEK │
│ │ │ (API) │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
│ │
│ (nunca en mismo lugar) │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Datos │ │ Llaves │
│ Cifrados │ │ │
└─────────────┘ └─────────────┘
```
---
## Algoritmos
| Uso | Algoritmo |
|-----|-----------|
| Cifrado simétrico | AES-256-GCM |
| Hashing | SHA-256, SHA-512 |
| Firmas | Ed25519, ECDSA |
| KDF | Argon2id |
| TLS | TLS 1.3 |
---
## Rotación de Llaves
| Llave | Proceso |
|-------|---------|
| **MASTER KEY** | Re-derivar todas las KEKs, re-cifrar DEKs |
| **KEK** | Re-cifrar DEKs asociadas |
| **DEK** | Generar nueva, re-cifrar datos específicos |
---
## Auditoría
| Evento | Log |
|--------|-----|
| Acceso a KEK | SENTINEL-LIGHT |
| Uso de DEK | Trace en S-CONTRACT |
| Rotación | Alerta + registro |
| Compromiso | SENTINEL-DEEP + alerta crítica |

View File

@@ -0,0 +1,119 @@
# Inmutabilidad
**Versión:** 1.0
**Estado:** Definición
---
## Principio
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Los datos de entrada y salida nunca se modifican. │
│ La trazabilidad siempre es posible. │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Componentes Inmutables
| Componente | Mutabilidad | Eliminación |
|------------|-------------|-------------|
| Secretaría (Clara/Margaret) | **Inmutable** | Prohibida |
| Contable (Feldman) | **Inmutable** | Prohibida |
---
## Componentes Editables
| Componente | Mutabilidad | Eliminación |
|------------|-------------|-------------|
| Producción (Alfred/Jared) | Editable | Permitida |
| Administración (Mason) | Editable | Siempre (tras consolidar) |
---
## Cadena de Hashes
### Encadenamiento
```
Bloque 1 Bloque 2 Bloque 3
┌────────────┐ ┌────────────┐ ┌────────────┐
│h_bloque: A │──────►│hash_prev: A│──────►│hash_prev: B│
│content: X │ │h_bloque: B │ │h_bloque: C │
│ │ │content: Y │ │content: Z │
└────────────┘ └────────────┘ └────────────┘
```
### Verificación
```python
def verificar_cadena_completa():
bloques = obtener_todos_bloques_ordenados()
for i, bloque in enumerate(bloques):
# Verificar hash de contenido
if not verificar_integridad(bloque):
return False, f"Integridad fallida en bloque {i}"
# Verificar encadenamiento
if i > 0:
if bloque.hash_previo != bloques[i-1].h_bloque:
return False, f"Encadenamiento roto en bloque {i}"
return True, "Cadena válida"
```
---
## Reglas de Validación
| Regla | Nombre | Descripción |
|-------|--------|-------------|
| M-001 | Hash único | h_bloque no existe previamente |
| M-002 | Encadenamiento | hash_previo apunta a bloque existente |
| M-003 | Integridad | hash_contenido = SHA-256(contenido) |
---
## Trazabilidad
Cualquier registro en Feldman puede rastrearse hasta Secretaría:
```
Bloque (Feldman)
└── h_entrada ──► Contenedor (Secretaría)
├── timestamp
├── origen
├── usuario
└── archivos_hashes ──► R2
```
---
## Auditoría
Sentinel verifica periódicamente:
| Modo | Frecuencia | Verificación |
|------|------------|--------------|
| LIGHT | 5 min | Últimos bloques |
| DEEP | 1 hora | Cadena completa |
---
## Blockchain Ready
La estructura de bloques encadenados está preparada para:
- Publicación en blockchain (Polygon)
- Merkle tree para verificación
- Smart contracts para sellado
**Estado:** Preparado pero no implementado.

View File

@@ -0,0 +1,135 @@
# Modelo de Amenazas
**Versión:** 1.0
**Estado:** Definición
---
## Activos Críticos
| Activo | Criticidad | Descripción |
|--------|------------|-------------|
| Bloques consolidados | Alta | Datos inmutables de Feldman |
| Cadena de hashes | Alta | Integridad del sistema |
| Credenciales | Alta | Acceso a servicios |
| Datos de usuario | Media | Información personal/empresarial |
| Configuración | Media | Parámetros del sistema |
---
## Amenazas Identificadas
### T1: Manipulación de Datos
| Aspecto | Valor |
|---------|-------|
| Descripción | Alteración de bloques consolidados |
| Impacto | Crítico |
| Probabilidad | Baja |
| Mitigación | Inmutabilidad, cadena de hashes, auditoría |
### T2: Acceso No Autorizado
| Aspecto | Valor |
|---------|-------|
| Descripción | Acceso a datos sin permiso |
| Impacto | Alto |
| Probabilidad | Media |
| Mitigación | Autenticación, autorización, cifrado |
### T3: Pérdida de Datos
| Aspecto | Valor |
|---------|-------|
| Descripción | Pérdida de información por fallo |
| Impacto | Alto |
| Probabilidad | Media |
| Mitigación | Backups, replicación, DR |
### T4: Compromiso de Credenciales
| Aspecto | Valor |
|---------|-------|
| Descripción | Robo de API keys o contraseñas |
| Impacto | Alto |
| Probabilidad | Media |
| Mitigación | Infisical, rotación, least privilege |
### T5: Denegación de Servicio
| Aspecto | Valor |
|---------|-------|
| Descripción | Indisponibilidad del sistema |
| Impacto | Medio |
| Probabilidad | Baja |
| Mitigación | Rate limiting, CDN, redundancia |
---
## Matriz de Riesgos
```
IMPACTO
Bajo Medio Alto Crítico
┌────────┬────────┬────────┬────────┐
Alta │ │ │ T2 │ │
├────────┼────────┼────────┼────────┤
P Media │ │ T5 │ T3,T4 │ │
R ├────────┼────────┼────────┼────────┤
O Baja │ │ │ │ T1 │
B ├────────┼────────┼────────┼────────┤
Muy │ │ │ │ │
Baja │ │ │ │ │
└────────┴────────┴────────┴────────┘
```
---
## Controles
### Preventivos
| Control | Amenazas |
|---------|----------|
| Cifrado en reposo | T1, T2 |
| Cifrado en tránsito | T2 |
| Autenticación MFA | T2, T4 |
| Rotación de secretos | T4 |
| Principio least privilege | T2, T4 |
### Detectivos
| Control | Amenazas |
|---------|----------|
| Sentinel LIGHT | T1 |
| Sentinel DEEP | T1 |
| Logs de acceso | T2 |
| Alertas de anomalías | T2, T5 |
### Correctivos
| Control | Amenazas |
|---------|----------|
| Backups | T3 |
| DR plan | T3, T5 |
| Revocación de credenciales | T4 |
---
## Respuesta a Incidentes
### Proceso
1. **Detectar** - Sentinel, logs, alertas
2. **Contener** - Aislar sistema afectado
3. **Erradicar** - Eliminar amenaza
4. **Recuperar** - Restaurar servicio
5. **Documentar** - Lecciones aprendidas
### Contactos
| Rol | Responsabilidad |
|-----|-----------------|
| Administrador | Primera respuesta |
| Propietario | Decisiones de negocio |
| Backup | Restauración de datos |

View File

@@ -0,0 +1,101 @@
# Respuesta a Incidentes
**Estado:** Activo
---
## Respuesta a Compromiso de Credencial
| Tiempo | Acción |
|--------|--------|
| **INMEDIATO** | Revocar credencial comprometida en el servicio origen |
| **T+5min** | Generar y desplegar nueva credencial |
| **T+15min** | Auditar logs de acceso para evaluar impacto |
| **T+1h** | Documentar incidente y actualizar procedimientos |
---
## Niveles de Severidad
| Severidad | Descripción | Tiempo Respuesta |
|-----------|-------------|------------------|
| **CRITICAL** | Master Key, KEK comprometida | Inmediato |
| **HIGH** | API Key producción, DB credential | < 5 min |
| **MEDIUM** | Service token, webhook | < 30 min |
| **LOW** | Token de desarrollo | < 24h |
---
## Acciones por Tipo de Incidente
### Compromiso de API Key
```
1. Revocar en el servicio (Anthropic, OpenRouter, etc.)
2. Generar nueva key
3. Actualizar en Infisical
4. Verificar servicios
5. Revisar logs
```
### Compromiso de DB Credential
```
1. Cambiar contraseña en PostgreSQL
2. Actualizar en Infisical
3. Reiniciar servicios dependientes
4. Revisar accesos anómalos
```
### Compromiso de SSH Key
```
1. Revocar en authorized_keys
2. Generar nuevo par de llaves
3. Actualizar en todos los servidores
4. Revisar logs de acceso SSH
```
### Compromiso de KEK/Master Key
```
1. ALERTA CRÍTICA inmediata
2. Rotar TODAS las credenciales derivadas
3. Re-cifrar datos con nueva KEK
4. Auditoría completa de accesos
5. Análisis forense
```
---
## Post-Incidente
| Paso | Descripción |
|------|-------------|
| 1 | Documentar timeline completo |
| 2 | Identificar causa raíz |
| 3 | Actualizar procedimientos |
| 4 | Comunicar a stakeholders si aplica |
| 5 | Implementar medidas preventivas |
---
## Contactos de Emergencia
| Rol | Canal |
|-----|-------|
| Admin principal | Slack #alerts |
| Backup admin | ntfy + Email |
| Escalación | PagerDuty |
---
## Checklist de Incidente
- [ ] Credencial revocada
- [ ] Nueva credencial generada
- [ ] Servicios verificados
- [ ] Logs revisados
- [ ] Impacto evaluado
- [ ] Incidente documentado
- [ ] Stakeholders notificados (si aplica)

62
06_SEGURIDAD/rotacion.md Normal file
View File

@@ -0,0 +1,62 @@
# Política de Rotación
**Estado:** Activo
---
## Matriz por Tipo de Credencial
| Tipo | Rotación | Ejemplos | Responsable |
|------|----------|----------|-------------|
| `API_KEY` | 90 días | OpenRouter, Groq, Cloudflare | Automatizado + Revisión |
| `DB_CREDENTIAL` | 30 días | PostgreSQL, Redis | Automatizado |
| `SERVICE_TOKEN` | 7 días | n8n, Nextcloud, Slack webhooks | Automatizado |
| `CERTIFICATE` | 90 días | SSL/TLS (Let's Encrypt) | Traefik auto-renovación |
| `SIGNING_KEY` | 180 días | JWT, KEK-SIGNING | Manual + Notificación |
| `ENCRYPTION_KEY` | 365 días | AES-256, KEK-DATA | Manual + Auditoría |
| `SSH_CREDENTIAL` | 180 días | Llaves SSH servidores | Manual + Backup |
---
## Procedimiento de Rotación
```
1. SENTINEL genera alerta 7 días antes de expiración
2. Generar nueva credencial en el servicio
3. Actualizar en Infisical (versión anterior se mantiene 24h para rollback)
4. Verificar funcionamiento de servicios dependientes
5. Revocar credencial anterior en el servicio origen
```
---
## Alertas de Rotación
| Tiempo restante | Severidad | Acción |
|-----------------|-----------|--------|
| 7 días | MEDIUM | Email a admin |
| 24 horas | HIGH | Email + Slack |
| Expirada | CRITICAL | Email + Slack + PagerDuty |
---
## Calendario de Rotación
| Frecuencia | Credenciales |
|------------|--------------|
| **Semanal** | SERVICE_TOKEN (webhooks, tokens temporales) |
| **Mensual** | DB_CREDENTIAL (PostgreSQL, Redis) |
| **Trimestral** | API_KEY, CERTIFICATE |
| **Semestral** | SIGNING_KEY, SSH_CREDENTIAL |
| **Anual** | ENCRYPTION_KEY, MASTER_KEY |
---
## Automatización
| Tarea | Herramienta |
|-------|-------------|
| Alertas expiración | SENTINEL |
| Renovación certificados | Traefik + Let's Encrypt |
| Rotación DB credentials | Script + Infisical API |
| Notificaciones | ntfy + Slack |

115
06_SEGURIDAD/secretos.md Normal file
View File

@@ -0,0 +1,115 @@
# Gestión de Secretos
**Gestor:** Infisical
**Estado:** Operativo
---
## Principio
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Las llaves nunca viajan con los datos que protegen. │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Infisical
| Parámetro | Valor |
|-----------|-------|
| URL | http://{ip}:8082 |
| Proyectos | anthropic, servers, databases, r2 |
| Acceso | Machine Identities |
---
## Proyectos
| Proyecto | Contenido |
|----------|-----------|
| **anthropic** | API keys de IA |
| **servers** | SSH, accesos servidores |
| **databases** | Credenciales PostgreSQL, Redis |
| **r2** | Keys de Cloudflare R2 |
---
## Categorías de Secretos
| Categoría | Ejemplos |
|-----------|----------|
| APIs IA | OpenRouter, Groq, Anthropic, OpenAI |
| Bases de datos | PostgreSQL, Redis |
| Almacenamiento | Storj, R2, Arweave |
| Infraestructura | n8n, Nextcloud, Windmill |
| Blockchain | Polygon, NOTARIO |
| Comunicaciones | Resend, Slack, ntfy |
| DNS/CDN | Cloudflare, Let's Encrypt |
| GPU | RunPod |
| Servidores | SSH credentials |
| Cifrado | Master Key, KEKs |
---
## Matriz de Rotación
| Tipo | Rotación | Ejemplos |
|------|----------|----------|
| API_KEY | 90 días | OpenRouter, Groq, Cloudflare |
| DB_CREDENTIAL | 30 días | PostgreSQL, Redis |
| SERVICE_TOKEN | 7 días | n8n, Nextcloud, Slack |
| CERTIFICATE | 90 días | SSL/TLS (auto) |
| SIGNING_KEY | 180 días | JWT, KEK-SIGNING |
| ENCRYPTION_KEY | 365 días | AES-256, KEK-DATA |
| SSH_CREDENTIAL | 180 días | Llaves SSH |
---
## Acceso por Instancia
Cada instancia tiene su propia Machine Identity:
```
ARCHITECT → Machine Identity: architect_prod
DECK → Machine Identity: deck_prod
CORP → Machine Identity: corp_prod
HST → Machine Identity: hst_prod
```
---
## Uso en Código
```python
from infisical import InfisicalClient
client = InfisicalClient(
client_id=os.environ["INFISICAL_CLIENT_ID"],
client_secret=os.environ["INFISICAL_CLIENT_SECRET"]
)
# Obtener secreto
api_key = client.get_secret(
project_id="anthropic",
environment="production",
secret_name="ANTHROPIC_API_KEY"
)
```
---
## Nunca en Código
Los siguientes NUNCA deben estar en repositorios:
- API keys
- Contraseñas de BD
- Tokens de acceso
- Llaves privadas
- Certificados
Siempre usar Infisical o variables de entorno.

Some files were not shown because too many files have changed in this diff Show More