45 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
ARCHITECT
4ec99f63c9 fix(naming): Apply generic + proper name convention
Components now use format: genérico (NOMBRE_PROPIO)

- secretaria (CLARA/MARGARET) - ingesta
- administrativo (MASON) - enriquecimiento
- contable (FELDMAN) - consolidación
- producción (ALFRED/JARED) - orquestación
- auditoría (SENTINEL) - planificado

Clarifies that components are microservices, not AI.
DECK/CORP are designed to USE AI services, not contain them.

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

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-25 11:25:41 +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
ARCHITECT
0ee01d07a3 fix(arch): Enforce instance autonomy principle across docs
Updates to ensure DECK/CORP are documented as autonomous instances:

- overview.md: Clarify ARCHITECT is for build/deploy only, not runtime
- filosofia.md: Mark shared services (GRACE, etc.) as optional
- backup-recovery.md: Each instance does its own local backup to its own R2 bucket

Key principle: Instances never depend on ARCHITECT at runtime.

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

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-25 10:40:19 +00:00
ARCHITECT
582e425832 fix(security): Correct secrets architecture for autonomous instances
ARCHITECT is the constructor, DECK/CORP are autonomous instances.
Each instance must operate independently at runtime.

Architecture:
- Infisical (ARCHITECT): Central management, source of truth
- Vaultwarden (DECK :8085): Local secrets for autonomous operation
- Vaultwarden (CORP :8081): Local secrets for autonomous operation
- Sync: Infisical → Vaultwarden propagation

Key principle: Instances never depend on ARCHITECT at runtime.

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

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-25 09:42:57 +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
ARCHITECT
6d15abcb1a docs(v5): Complete system documentation
Comprehensive documentation for TZZR system v5 including:

- 00_VISION: Glossary and foundational philosophy
- 01_ARQUITECTURA: System overview and server specs
- 02_MODELO_DATOS: Entity definitions and data planes (T0, MST, BCK)
- 03_COMPONENTES: Agent docs (CLARA, MARGARET, FELDMAN, GRACE)
- 04_SEGURIDAD: Threat model and secrets management
- 05_OPERACIONES: Infrastructure and backup/recovery
- 06_INTEGRACIONES: GPU services (RunPod status: blocked)
- 99_ANEXOS: Repository inventory (24 repos)

Key findings documented:
- CRITICAL: UFW inactive on CORP/HST
- CRITICAL: PostgreSQL 5432 exposed
- CRITICAL: .env files with 644 permissions
- RunPod workers not starting (code ready in R2)
- Infisical designated as single source of secrets (D-001)

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

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-24 17:58:03 +00:00
122 changed files with 90751 additions and 2 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)

185
00_VISION/filosofia.md Normal file
View File

@@ -0,0 +1,185 @@
# Filosofía Fundacional
**Versión:** 1.0
**Estado:** Definición
---
## 1. Principio Fundamental
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ "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." │
│ │
└─────────────────────────────────────────────────────────────────┘
```
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
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ "El sistema no registra incidencias. Registra resultados." │
│ │
└─────────────────────────────────────────────────────────────────┘
```
| 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 |
### Implicación Técnica
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
El sistema **NO registra**:
- Cuánto tardó internamente
- Qué interrupciones hubo
- Por qué se desvió del proceso ideal
- Cuántos intentos fueron necesarios
---
## 3. Paradigma Temporal
### Línea Temporal Fundamental
```
T-N ────→ T-1 ────→ T0 ────→ T+1 ────→ T+N
│ │ │ │ │
Origen Pre- Inicio Cierre Futuro/
Difuso consoli- Real Eviden- Histórico
dación cia
```
### Definición de Puntos Temporales
| 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:
```
[Trabajador X] completó [Tarea Y] con [Evidencia Z] en [Contexto W]
```
---
## 6. Implicaciones para el Diseño
### Granularidad de Bloques
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)
### Arrastre de Contexto
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)
El trabajador **solo aporta lo nuevo**. Nunca re-introduce datos existentes.
### Evidencia Mínima Viable
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 |

128
00_VISION/glosario.md Normal file
View File

@@ -0,0 +1,128 @@
# Glosario
**Versión:** 1.0
**Estado:** Definición
---
## Entidades Base
| Término | Hash | Descripción | Estado |
|---------|------|-------------|--------|
| **HST** | h_maestro | Hash Semantic Tagging - Etiquetas semánticas visuales | Implementado |
| **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 |
---
## Planos de Datos
| Plano | Tabla | Descripción |
|-------|-------|-------------|
| **T0** | items | Lo ideal, la partitura, estado futuro deseado |
| **MST** | milestones | Plano burocrático - documentos, hitos, estados |
| **BCK** | bloques | Plano físico - acciones, evidencias, trabajo real |
---
## Componentes del Sistema
### Registro 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) |
### Servicios IA
| Componente | Descripción |
|------------|-------------|
| Grace | Capa cognitiva, 18 módulos IA |
| Penny | Asistente de voz conversacional |
| The Factory | Generación iterativa |
### Orquestación
| Componente | Descripción |
|------------|-------------|
| Orchestrator | Orquestación multi-agente LLM |
| Circle | Consejo de perspectivas |
| Cloudville | Laboratorio de zumbados |
---
## Servidores
| Servidor | Descripción |
|----------|-------------|
| **ARCHITECT** | Coordinador central, Gitea, PostgreSQL |
| **DECK** | Servidor personal |
| **CORP** | Servidor empresarial |
| **HST** | API tags semánticos |
---
## Hashes e Identificadores
| 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 |
---
## Aplicaciones
| 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 | Interfaz unificada de acceso |
---
## Protocolos
| Protocolo | Versión | Descripción |
|-----------|---------|-------------|
| **S-CONTRACT** | v2.1 | Comunicación con servicios IA |
| **locker://** | - | Referencias almacenamiento R2 |
---
## Grupos HST
| 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 |
| **hsu** | - | Tags usuario (extensión) |
---
## Estados de Pipeline
| Estado | Etapa | Descripción |
|--------|-------|-------------|
| **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

221
01_ARQUITECTURA/overview.md Normal file
View File

@@ -0,0 +1,221 @@
# Overview
**Versión:** 1.1
**Estado:** Definición
---
## Visión General
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.
---
## Arquitectura General
```
┌─────────────────────────────────────────────────────────────┐
│ 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 Principal
El sistema tiene dos flujos según el origen y completitud de la información:
### Diagrama General
```
┌─────────────────────────────────────────────────────────────┐
│ 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
```
---
## Auditoría (Sentinel)
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) │
│ │
└─────────────────────────────────────────────────────────────┘
```
---
## Principio de Diseño
### 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.

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

@@ -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

@@ -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

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.

View File

@@ -0,0 +1,775 @@
# 07_INTERFACES
**Versión:** 1.0
**Estado:** Documentación basada en despliegue real
**Fecha:** 2025-12-31
---
## Resumen
Este documento describe las interfaces desplegadas y operativas en el ecosistema TZZR.
| Tipo | Cantidad | Servidores |
|------|----------|------------|
| Interfaces Web | 6 | DECK, CORP, HST, ARCHITECT |
| APIs Microservicios TZZR | 8 | DECK (4), CORP (4) |
| APIs Externas | 1 | HST |
---
# §1. INTERFACES WEB
## 1.1 MindLink - Portal Unificado
Portal visual que centraliza acceso a todos los servicios TZZR con estado en tiempo real.
### Instancias Desplegadas
| Instancia | URL | Servidor | Puerto |
|-----------|-----|----------|--------|
| CENTRAL | https://link.tzzrarchitect.me | DECK (72.62.1.113) | 5090 |
| CORP | https://link.tzzrcorp.me | CORP (92.112.181.188) | 5090 |
| DECK | https://link.tzzrdeck.me | DECK (72.62.1.113) | 5090 |
### Stack Técnico
| Componente | Tecnología |
|------------|------------|
| Backend | Python + Flask |
| Frontend | Jinja2 + Vanilla JS |
| Proceso | systemd |
| Ubicación | `/opt/mindlink/` |
### API Endpoints
```
GET / # Frontend
GET /api/health # Health check
GET /api/services # Lista servicios por categoría
GET /api/services/status # Estado de todos los servicios
GET /api/service/<id>/status # Estado de un servicio
# URL Shortener integrado
POST /api/shorten # Acortar URL
GET /api/urls # Listar URLs
GET /s/<code> # Redirección
GET /api/url/<code>/stats # Estadísticas
```
### Gestión
```bash
# Estado
systemctl status mindlink
# Reiniciar
systemctl restart mindlink
# Logs
journalctl -u mindlink -f
```
---
## 1.2 Flow-UI - Gestión de Flujos
Interfaz web para gestionar el flujo de datos del sistema TZZR.
```
ENTRADA (Clara/Margaret) → MASON (Enriquecimiento) → FELDMAN (Registro + Merkle)
```
### Instancias Desplegadas
| Instancia | URL | Servidor | Puerto |
|-----------|-----|----------|--------|
| DECK | https://flows.tzzrdeck.me | DECK (72.62.1.113) | 5080 |
| CORP | https://flows.tzzrcorp.me | CORP (92.112.181.188) | 5080 |
### Stack Técnico
| Componente | Tecnología |
|------------|------------|
| Backend | Python + Flask |
| Frontend | Jinja2 + Vanilla JS |
| Proceso | systemd |
| Ubicación | `/opt/flow-ui/` |
### Secciones del Frontend
| Sección | Función |
|---------|---------|
| **Entrada** | Formulario de ingesta y lista de entradas |
| **Mason** | Editor de items pendientes de enriquecimiento |
| **Feldman** | Milestones, bloques y verificación de hashes |
| **Flujos** | Gestión de flujos automatizados (Alfred/Jared) |
| **HSU** | Tags y grupos HSU |
| **Dashboard** | Vista general y estadísticas |
| **Admin** | Logs y restart de servicios |
### API Endpoints
```
# Core
POST /api/ingest # Enviar datos a Clara/Margaret
GET /api/entradas # Listar entradas
GET /api/stats # Estadísticas
# Mason
GET /api/mason/pending # Items pendientes
GET /api/mason/item/<id> # Detalle item
PUT /api/mason/item/<id> # Actualizar item
POST /api/mason/item/<id>/resolve # Resolver → Feldman
POST /api/mason/item/<id>/descartar # Descartar
# Feldman
GET /api/feldman/milestones # Listar milestones
GET /api/feldman/blocks # Listar bloques
GET /api/feldman/verify/<hash> # Verificar hash
# Flujos
GET /api/flujos # Listar flujos
POST /api/flujos # Crear flujo
POST /api/flujos/<id>/ejecutar # Ejecutar flujo
GET /api/ejecuciones # Historial
# Admin
GET /api/admin/servicios # Estado servicios
GET /api/admin/logs/<svc> # Logs
POST /api/admin/restart/<svc> # Reiniciar
```
### Gestión
```bash
systemctl status flow-ui
systemctl restart flow-ui
journalctl -u flow-ui -f
```
---
## 1.3 Directus - CMS Headless
Interfaz de administración de datos y API REST/GraphQL automática.
### Instancias Desplegadas
| Instancia | URL | Servidor | Puerto | Base de Datos |
|-----------|-----|----------|--------|---------------|
| DECK | https://directus.tzzrdeck.me | DECK | 8055 | deck |
| CORP | https://directus.tzzrcorp.me | CORP | 8055 | corp |
| HST | https://hst.tzrtech.org | HST | 8055 | hst_images |
| Lumalia | - | HST | 8056 | lumalia |
| Personal | - | HST | 8057 | personal |
| ARCHITECT | https://directus.tzzrarchitect.me | ARCHITECT | 8055 | tzzr |
### Proceso
Todas las instancias corren como contenedores Docker.
---
## 1.4 Servicios Auxiliares
### DECK (72.62.1.113)
| Servicio | Puerto | URL | Descripción |
|----------|--------|-----|-------------|
| Nextcloud | 8084 | nextcloud.tzzrdeck.me | Almacenamiento |
| Vaultwarden | 8085 | vault.tzzrdeck.me | Contraseñas |
| Shlink | 8083 | - | URLs cortas |
| NTFY | 8080 | - | Notificaciones |
| Odoo | 8069 | - | ERP |
| Windmill | 8100 | - | Workflows |
| Mailcow | 8443 | - | Email |
| FileBrowser | 8082 | - | Archivos |
### CORP (92.112.181.188)
| Servicio | Puerto | URL | Descripción |
|----------|--------|-----|-------------|
| Nextcloud | 8080 | nextcloud.tzzrcorp.me | Almacenamiento |
| Vaultwarden | 8081 | vault.tzzrcorp.me | Contraseñas |
| Shlink | 8082 | shlink.tzzrcorp.me | URLs cortas |
| Addy | 8083 | addy.tzzrcorp.me | Email aliases |
| NTFY | 8880 | ntfy.tzzrcorp.me | Notificaciones |
| Odoo | 8069 | erp.tzzrcorp.me | ERP |
| Windmill | 8000 | localhost:8000 | Workflows |
### HST (72.62.2.84)
| Servicio | Puerto | Descripción |
|----------|--------|-------------|
| FileBrowser | 8081 | Administrador archivos |
| HST-Images | 80/443 | Nginx imágenes estáticas |
### ARCHITECT (69.62.126.110)
| Servicio | Puerto | URL | Descripción |
|----------|--------|-----|-------------|
| Gitea | 3000 | git.tzzrarchitect.me | Repositorios |
| Windmill | 8100 | - | Workflows |
| Infisical | 8082 | - | Secretos |
---
# §2. APIs MICROSERVICIOS TZZR
## 2.1 Arquitectura
```
┌─────────────────────────────────────────────────────────────────┐
│ DECK │
│ (72.62.1.113) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Clara │ → │ Mason │ → │ Feldman │ │ Alfred │ │
│ │ :5051 │ │ :5053 │ │ :5054 │ │ :5052 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ CORP │
│ (92.112.181.188) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Margaret │ → │ Mason │ → │ Feldman │ │ Jared │ │
│ │ :5051 │ │ :5053 │ │ :5054 │ │ :5052 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## 2.2 Clara (DECK) / Margaret (CORP)
**Función:** Secretaría - Punto de entrada inmutable del sistema.
| Aspecto | Valor |
|---------|-------|
| Puerto | 5051 |
| Versión | 1.0.0 |
| Contenedor | clara-service / margaret-service |
### Endpoints
```
GET /health # Health check
POST /api/v1/ingest # Registrar entrada
GET /api/v1/entries # Listar entradas
GET /api/v1/entry/<id> # Detalle entrada
```
### Request de Ingesta
```json
POST /api/v1/ingest
{
"contenido": "texto o datos",
"origen": "manual|api|flujo",
"metadata": {
"usuario": "id",
"timestamp": "ISO8601"
}
}
```
### Response
```json
{
"id": "uuid",
"hash": "sha256",
"timestamp": "ISO8601",
"status": "registrado"
}
```
---
## 2.3 Alfred (DECK) / Jared (CORP)
**Función:** Producción - Flujos predefinidos y automatización.
| Aspecto | Valor |
|---------|-------|
| Puerto | 5052 |
| Versión | 1.0.0 |
| Contenedor | alfred-service / jared-service |
### Endpoints
```
GET /health # Health check
GET /api/v1/flujos # Listar flujos definidos
POST /api/v1/flujos # Crear flujo
GET /api/v1/flujo/<id> # Detalle flujo
POST /api/v1/flujo/<id>/ejecutar # Ejecutar flujo
GET /api/v1/ejecuciones # Historial ejecuciones
```
### Estructura de Flujo
```json
{
"id": "uuid",
"nombre": "Proceso mensual",
"pasos": [
{"orden": 1, "accion": "ingest", "config": {}},
{"orden": 2, "accion": "enrich", "config": {}},
{"orden": 3, "accion": "validate", "config": {}}
],
"trigger": "manual|cron|evento",
"activo": true
}
```
---
## 2.4 Mason
**Función:** Administración - Enriquecimiento de datos.
| Aspecto | Valor |
|---------|-------|
| Puerto | 5053 |
| Versión | 1.0.0 |
| Contenedor | mason-service |
| Igual en | DECK y CORP |
### Endpoints
```
GET /health # Health check
GET /api/v1/pending # Items pendientes
GET /api/v1/item/<id> # Detalle item
PUT /api/v1/item/<id> # Actualizar item
POST /api/v1/item/<id>/resolve # Enviar a Feldman
POST /api/v1/item/<id>/discard # Descartar
GET /api/v1/stats # Estadísticas
```
### Estados de un Item
| Estado | Descripción |
|--------|-------------|
| `pending` | Esperando enriquecimiento |
| `in_progress` | Siendo editado |
| `resolved` | Enviado a Feldman |
| `discarded` | Descartado |
---
## 2.5 Feldman
**Función:** Contabilidad - Registro final inmutable con verificación Merkle.
| Aspecto | Valor |
|---------|-------|
| Puerto | 5054 |
| Versión | 3.0-unified |
| Contenedor | feldman-service |
| Igual en | DECK y CORP |
### Endpoints
```
GET /health # Health check
GET /api/v1/milestones # Listar milestones
GET /api/v1/blocks # Listar bloques
GET /api/v1/block/<id> # Detalle bloque
POST /api/v1/consolidate # Consolidar cola → bloque
GET /api/v1/verify/<hash> # Verificar integridad
GET /api/v1/merkle/<batch_id> # Obtener prueba Merkle
GET /api/v1/stats # Estadísticas
```
### Estructura de Bloque
```json
{
"id": "uuid",
"numero": 42,
"hash": "sha256",
"registros": ["hash1", "hash2", "hash3"],
"merkle_root": "sha256",
"timestamp": "ISO8601",
"anterior": "hash_bloque_41"
}
```
### Verificación de Integridad
```
GET /api/v1/verify/abc123def456...
Response:
{
"hash": "abc123def456...",
"existe": true,
"bloque": 42,
"merkle_proof": ["hash1", "hash2"],
"verificado": true
}
```
---
# §3. HST API
**Base URL:** https://tzrtech.org/api
**Puerto:** 5001
**Servidor:** HST (72.62.2.84)
---
## 3.1 Descripción
API REST para acceder al sistema de tags semánticos (Hash Semantic Tagging).
---
## 3.2 Endpoints Públicos
### 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 }
]
}
```
---
## 3.3 Endpoints Autenticados
### Biblioteca de Usuario
```
GET /biblioteca
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
Authorization: Bearer {token}
Content-Type: application/json
{
"ref": "mi_tag",
"nombre": "Mi Tag Personal",
"metadata": {}
}
```
---
## 3.4 Grupos de Tags
| Grupo | Cantidad | Descripción |
|-------|----------|-------------|
| hst | 639 | Tags del sistema |
| spe | 145 | Especializaciones |
| vsn | 84 | Visiones |
| flg | 65 | Flags/Marcos jurídicos |
| vue | 21 | Vistas |
---
## 3.5 Rate Limits
| Tipo | Límite |
|------|--------|
| Público | 100 req/min |
| Autenticado | 1000 req/min |
---
# §4. TABLAS POSTGRESQL
## 4.1 Resumen por Servidor
| Servidor | Bases de Datos | Total Tablas |
|----------|----------------|--------------|
| DECK | tzzr, deck | 30 |
| CORP | tzzr, corp | 89 |
| HST | directus, hst_images, lumalia, personal | 143 |
| ARCHITECT | tzzr, windmill | 122 |
---
## 4.2 Tablas Core TZZR
### Secretaría (Clara/Margaret)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| immutable_log | DECK, CORP | Log inmutable principal |
| clara_log | DECK | Log específico Clara |
| clara_registros | DECK | Registros Clara |
| margaret_log | CORP | Log específico Margaret |
| margaret_registros | CORP | Registros Margaret |
### Administración (Mason)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| incidencias | DECK, CORP | Items pendientes de resolver |
### Contabilidad (Feldman)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| feldman_cola | DECK, CORP | Cola de validación |
| feldman_validaciones | CORP | Registro de validaciones |
| bloques | DECK, CORP | Bloques consolidados |
| completados | DECK, CORP | Registros finalizados |
| milestones | DECK, CORP | Hitos del sistema |
| merkle_batches | DECK, CORP | Lotes Merkle |
### Producción (Alfred/Jared)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| flujos_predefinidos | DECK, CORP | Definiciones de flujos |
| flujo_ejecuciones | DECK, CORP | Historial de ejecuciones |
### Extensiones Usuario (HSU)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| hsu | DECK, CORP | Tags de usuario |
| pju | DECK, CORP | Proyectos usuario |
| spu | DECK, CORP | Especializaciones usuario |
| vsu | DECK, CORP | Visiones usuario |
| vuu | DECK, CORP | Vistas usuario |
| flu | DECK, CORP | Flags usuario |
### Sincronización
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| hst_mirror | DECK, CORP | Espejo de tags HST |
---
## 4.3 Tablas HST
| Tabla | Base de Datos | Descripción |
|-------|---------------|-------------|
| hst | hst_images, lumalia, personal | Tags principales |
| flg | hst_images, lumalia, personal | Flags/marcos jurídicos |
| spe | hst_images | Especializaciones |
| vsn | hst_images | Visiones |
| vue | hst_images | Vistas |
| graph_edges | hst_images | Relaciones entre tags |
| tag_categorias | hst_images | Categorías |
| itm | lumalia, personal | Items (plano ideal) |
| loc | lumalia, personal | Ubicaciones |
| ply | lumalia, personal | Players (actores) |
---
# §5. RESUMEN DE PUERTOS
| Puerto | Servicio | DECK | CORP | HST | ARCHITECT |
|--------|----------|------|------|-----|-----------|
| 80/443 | Reverse Proxy | Caddy | Caddy | Docker | Nginx |
| 3000 | Gitea | - | - | - | ✓ |
| 5001 | HST-API | - | - | ✓ | - |
| 5051 | Clara/Margaret | ✓ | ✓ | - | - |
| 5052 | Alfred/Jared | ✓ | ✓ | - | - |
| 5053 | Mason | ✓ | ✓ | - | - |
| 5054 | Feldman | ✓ | ✓ | - | - |
| 5080 | Flow-UI | ✓ | ✓ | - | - |
| 5090 | MindLink | ✓ | ✓ | - | - |
| 8055 | Directus | ✓ | ✓ | ✓ | ✓ |
| 8080/8880 | NTFY/Nextcloud | NTFY | NC | - | - |
| 8100 | Windmill | ✓ | - | - | ✓ |
---
# §6. REPOSITORIOS
**Gitea:** https://git.tzzrarchitect.me
## Organización `tzzr` (29 repos)
### Microservicios
| Repo | Descripción | Lenguaje |
|------|-------------|----------|
| clara | Entrada DECK | Python |
| margaret | Entrada CORP | Python |
| alfred | Asistente DECK | Python |
| jared | Flujos CORP | Python |
| mason | Enriquecimiento | Python |
| feldman | Validador + Merkle | Python |
| sentinel | Auditoría | Python |
### Interfaces
| Repo | Descripción |
|------|-------------|
| flow-ui | Interfaz de flujos |
| mindlink | Portal unificado |
| packet | App móvil (Dart) |
### Sistema
| Repo | Descripción |
|------|-------------|
| captain-claude | Sistema multiagente |
| orchestrator | Orquestación v5 |
| system-docs | Documentación |
| system-plan | Plan de implementación |
| contratos-comunes | Contratos compartidos |
### GPU Services (No desplegados)
| Repo | Descripción | Estado |
|------|-------------|--------|
| grace | Módulos IA | Repo existe, no desplegado |
| penny | Asistente voz | Repo existe, no desplegado |
| the-factory | Generación iterativa | Repo existe, no desplegado |
---
# Apéndice: Comandos de Gestión
## Servicios systemd
```bash
# MindLink
systemctl status|start|stop|restart mindlink
journalctl -u mindlink -f
# Flow-UI
systemctl status|start|stop|restart flow-ui
journalctl -u flow-ui -f
```
## Contenedores Docker
```bash
# Ver estado
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
# Logs de microservicio
docker logs -f clara-service
docker logs -f feldman-service
# Reiniciar
docker restart jared-service mason-service feldman-service
# Health check manual
curl http://localhost:5051/health
curl http://localhost:5052/health
curl http://localhost:5053/health
curl http://localhost:5054/health
```
## PostgreSQL
```bash
# Listar bases de datos
sudo -u postgres psql -c "\l"
# Ver tablas
sudo -u postgres psql -d tzzr -c "\dt"
# Query específica
sudo -u postgres psql -d tzzr -c "SELECT count(*) FROM immutable_log;"
```
---
*Documento generado a partir del estado real de despliegue*
*Fecha: 2025-12-31*

View File

@@ -0,0 +1,242 @@
# Auditoría Sistema TZZR - 2026-01-01
## Resumen Ejecutivo
Auditoría completa del sistema TZZR realizada antes de implementar mejoras de la Fase 1-7.
### Estado General
| Servidor | Microservicios | Web Apps | PostgreSQL | Estado |
|----------|---------------|----------|------------|--------|
| DECK | 4/4 OK | 2/2 OK | 93 tablas | ✅ Operativo |
| CORP | 4/4 OK | 2/2 OK | 32 tablas | ✅ Operativo |
---
## 1. DECK (72.62.1.113)
### 1.1 Microservicios Docker
| Servicio | Puerto | Estado | Health Check |
|----------|--------|--------|--------------|
| clara-service | 5051 | Up 6 days (healthy) | `{"status":"ok"}` |
| alfred-service | 5052 | Up 6 days (healthy) | `{"status":"healthy"}` |
| mason-service | 5053 | Up 6 days | `{"status":"healthy"}` |
| feldman-service | 5054 | Up 6 days | `{"status":"healthy"}` |
### 1.2 Aplicaciones Web (systemd)
| App | Puerto | Estado | Health Endpoint |
|-----|--------|--------|-----------------|
| MindLink | 5090 | active (running) | `/api/health` → OK |
| Flow-UI | 5080 | active (running) | `/api/health` → OK |
**Nota**: Los endpoints de health son `/api/health`, no `/health`
### 1.3 Base de Datos PostgreSQL
- **Ubicación**: Docker container `postgres`
- **DB Principal**: `tzzr`
- **Usuario**: `tzzr`
- **Total tablas**: 93
#### Tablas principales:
- `immutable_log` - Log inmutable
- `clara_log` - Log de Clara
- `feldman_cola`, `feldman_validaciones` - Cola Feldman
- `merkle_batches` - Batches Merkle
- `deck_*` - Tablas específicas DECK (emails, files, projects, etc.)
- `hst_*` - Hash Semantic Tagging
- `task_*` - Gestión de tareas
- `ia_*` - Contexto IA
- `circle_*` - Sistema de mensajería
### 1.4 Otros Contenedores Docker
| Contenedor | Estado | Puerto |
|------------|--------|--------|
| windmill-server | Up 37h | 8100 |
| nextcloud | Up 6 days | 8084 |
| directus | Up 6 days | 8055 |
| mailcow (múltiples) | Up 6 days | 25,465,587,993,995 |
| vaultwarden | Up 6 days (healthy) | 8085 |
| shlink | Up 6 days | 8083 |
| ntfy | Up 6 days | 8080 |
| deck-odoo | Up 6 days | 8069 |
| filebrowser | Up 6 days (healthy) | 8082 |
| redis | Up 6 days | 6379 |
---
## 2. CORP (92.112.181.188)
### 2.1 Microservicios Docker
| Servicio | Puerto | Estado | Health Check |
|----------|--------|--------|--------------|
| margaret-service | 5051 | Up 6 days (healthy) | `{"status":"ok"}` |
| jared-service | 5052 | Up 20h (healthy) | `{"status":"healthy"}` |
| mason-service | 5053 | Up 20h | `{"status":"healthy"}` |
| feldman-service | 5054 | Up 20h | `{"status":"healthy"}` |
### 2.2 Aplicaciones Web (systemd)
| App | Puerto | Estado | Health Endpoint |
|-----|--------|--------|-----------------|
| MindLink | 5090 | active (running) | `/api/health` → OK |
| Flow-UI | 5080 | active (running) | `/api/health` → OK |
### 2.3 Base de Datos PostgreSQL
- **Ubicación**: Host (no Docker)
- **DB Principal**: `tzzr`
- **Total tablas**: 32
#### Tablas principales:
- `immutable_log` - Log inmutable
- `ai_*` - Contexto IA (contexts, conversations, memory, etc.)
- `context_*` - Algoritmos de contexto
- `sesiones_ia`, `tareas_ia`, `mensajes_ia`
- `knowledge_base`, `memory`
### 2.4 Otros Contenedores Docker
| Contenedor | Estado | Puerto |
|------------|--------|--------|
| windmill-server | Up 2 days | 8000 (local) |
| nextcloud | Up 6 days | 8080 |
| directus | Up 43h | 8055 |
| odoo | Up 6 days | 8069 |
| shlink | Up 43h | 8082 |
| vaultwarden | Up 6 days (healthy) | 8081 |
| ntfy | Up 6 days | 8880 |
| addy | Up 8 min | 8083 |
| redis | Up 6 days | 6379 |
---
## 3. Código Fuente
### 3.1 MindLink
**Ubicación**: `/opt/mindlink/`
**Endpoints disponibles**:
- `GET /` - Portal principal
- `GET /api/health` - Health check
- `GET /api/services` - Lista servicios
- `GET /api/services/status` - Estado de servicios
- `GET /api/service/<id>/status` - Estado de un servicio
- `POST /api/shorten` - Acortar URL
- `GET /api/urls` - Listar URLs
- `GET /s/<code>` - Redirección corta
- `GET /api/url/<code>/stats` - Estadísticas URL
**Archivos**:
- `app.py` (15.3 KB)
- `requirements.txt`
- `templates/`
- `.env` (INSTANCE_TYPE)
### 3.2 Flow-UI
**Ubicación**: `/opt/flow-ui/`
**Endpoints disponibles**:
- `GET /` - Portal principal
- `GET /api/health` - Health check
- `POST /api/ingest` - Ingestar entrada
- `GET /api/entradas` - Listar entradas
- `GET /api/log` - Ver log
- `GET /api/mason/pending` - Items pendientes Mason
- `GET/PUT /api/mason/item/<id>` - Gestión items
- `POST /api/mason/item/<id>/resolve` - Resolver item
- `POST /api/mason/item/<id>/descartar` - Descartar item
- `GET /api/feldman/milestones` - Milestones
- `GET /api/feldman/blocks` - Bloques
- `GET /api/feldman/verify/<hash>` - Verificar hash
- `GET/POST /api/flujos` - Gestión flujos
- `POST /api/flujos/<id>/ejecutar` - Ejecutar flujo
- `GET /api/ejecuciones` - Listar ejecuciones
- `GET /api/hsu/*` - Biblioteca, tags, grupos
- `GET /api/status` - Estado general
**Archivos**:
- `app.py` (22.7 KB)
- `requirements.txt`
- `templates/`
- `.env` (SERVER, DB config)
---
## 4. Documentación R2
### 4.1 Estructura skynet v8 en R2
```
s3://architect/system/skynet v8/
├── 00_VISION/
│ ├── filosofia.md
│ └── glosario.md
├── 01_ARQUITECTURA/
│ ├── almacenamiento.md
│ ├── overview.md
│ ├── aplicaciones/ (mind-link, packet, vision-builder)
│ └── entidades/ (architect, corp, deck, flg, hst, itm, loc, ply)
├── 02_COMPONENTES/
│ ├── internos/ (administracion, auditoria, contable, context-system, etc.)
│ └── servicios externos/ (asistente, circle, cloudville, etc.)
├── 02_INFRAESTRUCTURA/ (duplicado, revisar)
├── 03_MODELO_DATOS/
│ └── schemas/
├── 04_INFRAESTRUCTURA/
├── 05_INTEGRACIONES/
└── 06_SEGURIDAD/
```
**Total documentos**: 68 archivos .md
---
## 5. Repositorios Gitea
| Repositorio | Última actualización |
|-------------|---------------------|
| system-docs | 2026-01-01 |
| captain-claude | 2025-12-29 |
| system-plan | 2025-12-30 |
| packet | 2025-12-24 |
| mason | 2025-12-24 |
| feldman | 2025-12-24 |
| margaret | 2025-12-24 |
| jared | 2025-12-24 |
| sentinel | 2025-12-24 |
| orchestrator | 2025-12-24 |
---
## 6. Problemas Detectados
### 6.1 Críticos
- Ninguno
### 6.2 Moderados
1. **Estructura duplicada en R2**: `02_COMPONENTES/` y `02_INFRAESTRUCTURA/` en mismo nivel - posible error de organización
2. **Diferencia de tablas DECK vs CORP**: DECK tiene 93 tablas, CORP solo 32 - puede ser intencional pero verificar sincronización
### 6.3 Menores
1. **Health endpoint inconsistente**: MindLink/Flow-UI usan `/api/health` mientras que microservicios usan `/health`
2. **Repos desactualizados**: Varios repos sin commits desde 2025-12-24 (1 semana)
---
## 7. Recomendaciones
1. **Estandarizar health endpoints**: Agregar `/health` como alias a `/api/health` en MindLink y Flow-UI
2. **Revisar estructura R2**: Corregir duplicación de carpetas 02_*
3. **Sincronizar esquemas**: Verificar si CORP necesita las mismas tablas que DECK
4. **Actualizar repos Gitea**: Sincronizar código de servidores con repositorios
---
*Generado: 2026-01-01 12:45 UTC*
*Sistema: CAPTAIN CLAUDE*

View File

@@ -0,0 +1,396 @@
# Estudio de Debilidades y Mejoras - Sistema TZZR
**Fecha**: 2026-01-01
**Alcance**: DECK (72.62.1.113), CORP (92.112.181.188), ARCHITECT (69.62.126.110)
---
## Resumen Ejecutivo
Se identificaron **12 debilidades críticas/moderadas** y se proponen **18 mejoras** organizadas por prioridad. Las áreas más afectadas son **seguridad de red**, **monitoreo** y **mantenibilidad**.
### Matriz de Riesgo
| Categoría | Crítico | Alto | Medio | Bajo |
|-----------|---------|------|-------|------|
| Seguridad | 1 | 2 | 2 | 1 |
| Rendimiento | 0 | 1 | 2 | 1 |
| Mantenibilidad | 0 | 1 | 3 | 2 |
| Disponibilidad | 0 | 1 | 1 | 0 |
---
## 1. DEBILIDADES DE SEGURIDAD
### 1.1 [CRÍTICO] Microservicios Expuestos a Internet
**Problema**: Los puertos 5051-5054 están accesibles desde cualquier IP externa.
```
Port 5051 (Clara): ACCESIBLE desde internet
Port 5052 (Alfred): ACCESIBLE desde internet
Port 5053 (Mason): ACCESIBLE desde internet
Port 5054 (Feldman): ACCESIBLE desde internet
```
**Mitigación**: Aunque existe autenticación via `X-Auth-Key`, un atacante podría:
- Realizar ataques de fuerza bruta al header
- Explotar vulnerabilidades en el código
- Causar DoS
**Recomendación**:
```bash
# Restringir acceso solo a IPs del sistema
ufw delete allow 5051:5054/tcp
ufw allow from 69.62.126.110 to any port 5051:5054 proto tcp
ufw allow from 92.112.181.188 to any port 5051:5054 proto tcp
ufw allow from 72.62.2.84 to any port 5051:5054 proto tcp
```
---
### 1.2 [ALTO] Sin Rate Limiting
**Problema**: Las APIs no tienen límite de requests por segundo.
**Evidencia**:
```
5 requests consecutivos: 200 200 200 200 200 (sin throttling)
```
**Impacto**: Vulnerable a:
- Ataques de fuerza bruta
- DDoS a nivel de aplicación
- Abuso de recursos
**Recomendación**: Implementar rate limiting con Flask-Limiter:
```python
from flask_limiter import Limiter
limiter = Limiter(app, default_limits=["100 per minute", "10 per second"])
```
---
### 1.3 [ALTO] Clave SSH Compartida
**Problema**: La misma clave `~/.ssh/tzzr` se usa para acceso a todos los servidores.
**Impacto**: Si se compromete un servidor, todos están comprometidos.
**Recomendación**:
- Usar claves únicas por servidor
- Implementar rotación de claves cada 90 días
- Considerar HashiCorp Vault para gestión de secretos
---
### 1.4 [MEDIO] Sin Certificados Let's Encrypt
**Problema**: Los certificados SSL son de `/home/user-data/ssl/` (probablemente auto-generados o de mailcow).
**Recomendación**:
```bash
apt install certbot python3-certbot-nginx
certbot --nginx -d link.tzzrdeck.me -d flows.tzzrdeck.me
```
---
### 1.5 [MEDIO] Headers de Seguridad Ausentes
**Problema**: Las APIs no implementan headers de seguridad HTTP.
**Recomendación**: Agregar en nginx o Flask:
```python
@app.after_request
def add_security_headers(response):
response.headers['X-Content-Type-Options'] = 'nosniff'
response.headers['X-Frame-Options'] = 'DENY'
response.headers['X-XSS-Protection'] = '1; mode=block'
return response
```
---
### 1.6 [BAJO] Logs de Autenticación No Centralizados
**Problema**: Los intentos fallidos de autenticación no se registran de forma centralizada.
**Recomendación**: Implementar logging estructurado con envío a un SIEM o ELK stack.
---
## 2. DEBILIDADES DE RENDIMIENTO
### 2.1 [ALTO] Uso Excesivo de Swap (DECK)
**Problema**:
```
Swap: 1.5Gi usado de 2.0Gi (75%)
```
**Impacto**:
- Degradación de rendimiento
- Posibles timeouts en operaciones de DB
**Causa probable**:
- Demasiados contenedores Docker
- Memoria insuficiente (7.8Gi para 34 contenedores)
**Recomendación**:
1. Aumentar RAM a 16GB
2. Optimizar límites de memoria por contenedor
3. Reducir workers de gunicorn
---
### 2.2 [MEDIO] Docker Images Sin Limpiar
**Problema**:
```
Images: 32.67GB (99% reclamable)
```
**Recomendación**:
```bash
docker image prune -a --filter "until=720h" # Eliminar imágenes > 30 días
docker system prune -f --volumes
```
---
### 2.3 [MEDIO] Conexiones DB Sin Pool
**Problema**: Cada request crea una nueva conexión a PostgreSQL.
```python
def get_db_connection():
return psycopg2.connect(...) # Nueva conexión cada vez
```
**Impacto**: Overhead de conexión, posibles errores "too many connections".
**Recomendación**: Usar connection pool:
```python
from psycopg2 import pool
db_pool = pool.ThreadedConnectionPool(5, 20, ...)
def get_db_connection():
return db_pool.getconn()
```
---
### 2.4 [BAJO] Gunicorn con Workers Sync
**Problema**: Los workers son síncronos, bloqueantes durante I/O.
**Recomendación**:
```bash
gunicorn --workers 4 --worker-class gevent app:app
```
---
## 3. DEBILIDADES DE MANTENIBILIDAD
### 3.1 [ALTO] Sin CI/CD
**Problema**: Los deploys son manuales via SSH.
**Impacto**:
- Propenso a errores humanos
- Tiempo de deploy alto
- Sin rollback automático
**Recomendación**: Implementar pipeline en Gitea Actions:
```yaml
# .gitea/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Deploy to DECK
run: ssh root@72.62.1.113 'cd /opt/clara && git pull && docker-compose up -d --build'
```
---
### 3.2 [MEDIO] Código Duplicado DECK/CORP
**Problema**: MindLink y Flow-UI tienen código casi idéntico en DECK y CORP.
**Recomendación**:
- Usar variables de entorno para configuración específica de instancia
- Un solo repositorio con configuración por ambiente
---
### 3.3 [MEDIO] Sin Tests Automatizados
**Problema**: No hay tests unitarios ni de integración.
**Recomendación**:
```python
# tests/test_clara.py
def test_health_endpoint(client):
response = client.get('/health')
assert response.status_code == 200
assert response.json['status'] == 'ok'
```
---
### 3.4 [MEDIO] Dependencias Desactualizadas
**Problema**:
```
Flask==3.0.0 (actual: 3.1.0)
psycopg2-binary==2.9.9 (actual: 2.9.10)
```
**Recomendación**: Actualizar regularmente y usar Dependabot.
---
### 3.5 [BAJO] Documentación de API Ausente
**Problema**: No hay documentación OpenAPI/Swagger.
**Recomendación**: Implementar Flask-RESTx o FastAPI.
---
### 3.6 [BAJO] Sin Versionado de API
**Problema**: Las rutas no incluyen versión (`/ingest` en vez de `/v1/ingest`).
---
## 4. DEBILIDADES DE DISPONIBILIDAD
### 4.1 [ALTO] Sin Monitoreo
**Problema**: No hay Prometheus, Grafana ni alertas.
**Impacto**:
- No hay visibilidad de métricas
- Problemas se detectan tarde
- Sin historial de rendimiento
**Recomendación**:
```yaml
# docker-compose.monitoring.yml
services:
prometheus:
image: prom/prometheus
ports: ["9090:9090"]
grafana:
image: grafana/grafana
ports: ["3001:3000"]
alertmanager:
image: prom/alertmanager
```
---
### 4.2 [MEDIO] Healthchecks Incompletos
**Problema**: Solo Clara y Alfred tienen healthcheck en Docker.
```
clara-service: Healthcheck configurado ✓
feldman-service: Sin healthcheck ✗
mason-service: Sin healthcheck ✗
```
**Recomendación**: Agregar a docker-compose.yml:
```yaml
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5054/health"]
interval: 30s
timeout: 10s
retries: 3
```
---
## 5. PLAN DE MEJORAS PRIORIZADO
### Fase 1: Seguridad Inmediata (1-2 días)
| # | Mejora | Esfuerzo | Impacto |
|---|--------|----------|---------|
| 1 | Restringir puertos 5051-5054 en UFW | 1h | Crítico |
| 2 | Implementar rate limiting | 2h | Alto |
| 3 | Agregar headers de seguridad | 1h | Medio |
### Fase 2: Estabilidad (3-5 días)
| # | Mejora | Esfuerzo | Impacto |
|---|--------|----------|---------|
| 4 | Implementar connection pool DB | 4h | Alto |
| 5 | Limpiar Docker images | 1h | Medio |
| 6 | Agregar healthchecks faltantes | 2h | Medio |
| 7 | Configurar Let's Encrypt | 2h | Medio |
### Fase 3: Monitoreo (1 semana)
| # | Mejora | Esfuerzo | Impacto |
|---|--------|----------|---------|
| 8 | Desplegar Prometheus + Grafana | 8h | Alto |
| 9 | Configurar alertas básicas | 4h | Alto |
| 10 | Implementar logging estructurado | 4h | Medio |
### Fase 4: Mantenibilidad (2 semanas)
| # | Mejora | Esfuerzo | Impacto |
|---|--------|----------|---------|
| 11 | Implementar CI/CD básico | 8h | Alto |
| 12 | Escribir tests unitarios core | 16h | Alto |
| 13 | Documentar APIs con OpenAPI | 8h | Medio |
| 14 | Unificar código DECK/CORP | 8h | Medio |
### Fase 5: Optimización (continuo)
| # | Mejora | Esfuerzo | Impacto |
|---|--------|----------|---------|
| 15 | Aumentar RAM DECK a 16GB | - | Alto |
| 16 | Migrar a workers async | 4h | Medio |
| 17 | Implementar caché Redis | 8h | Medio |
| 18 | Rotación automática de claves SSH | 4h | Bajo |
---
## 6. MÉTRICAS DE ÉXITO
| Métrica | Actual | Objetivo |
|---------|--------|----------|
| Puertos expuestos públicamente | 4 | 0 |
| Cobertura de tests | 0% | 70% |
| Uptime monitorizado | No | Sí |
| Tiempo de deploy | ~30min | <5min |
| Uso de swap DECK | 75% | <20% |
| Alertas configuradas | 0 | 10+ |
---
## 7. CONCLUSIONES
El sistema TZZR está funcionalmente operativo pero presenta debilidades significativas en seguridad de red y observabilidad. Las mejoras más urgentes son:
1. **Restringir acceso a puertos de microservicios** (riesgo crítico)
2. **Implementar rate limiting** (prevención de abuso)
3. **Desplegar monitoreo** (visibilidad operacional)
Con la implementación de las 18 mejoras propuestas, el sistema alcanzaría un nivel de madurez adecuado para producción empresarial.
---
*Generado por CAPTAIN CLAUDE*
*Sistema TZZR - 2026-01-01*

97
07_OPERACION/INDEX.md Normal file
View File

@@ -0,0 +1,97 @@
# Skynet v8 - Sección 07: OPERACIÓN
## Documentos de Operación
### 1. Runbooks (runbooks.md)
Procedimientos estandarizados para operaciones comunes:
- **Reinicio de servicios**: Procedimiento seguro para reiniciar servicios sin downtime
- **Failover de base de datos**: Cambio automático a réplica en caso de fallo
- **Restauración de backups**: Opciones de restauración (completa, PITR, tabla)
- **Escalado de recursos**: CPU, RAM, almacenamiento
**Ubicación**: `/system/skynet v8/07_OPERACION/runbooks.md`
### 2. Respuesta ante Incidentes (incident_response.md)
Procedimientos de respuesta para situaciones de crisis:
- **Caída de servidor**: Detección, escalación, mitigación, recovery
- **Ataque DDoS**: Identificación, rate limiting, activación de servicios de protección
- **Breach de seguridad**: Aislamiento, investigación forense, recovery, notificación
Incluye:
- Fases de respuesta (detección, confirmación, escalación, investigación, mitigación, resolución)
- Escaleras de escalación por severidad (P1-P4)
- Contactos de emergencia
- Tiempos de respuesta objetivo (SLA)
**Ubicación**: `/system/skynet v8/07_OPERACION/incident_response.md`
### 3. Monitoreo y Observabilidad (monitoring.md)
Arquitectura y configuración de monitoreo:
- **Métricas a monitorear**: Aplicación, BD, sistema, seguridad
- **Alertas configuradas**: P1 (críticas), P2 (altas), P3 (medias)
- **Dashboards**: Sistema, aplicación, BD, infraestructura, seguridad
- **Logs**: Ubicaciones, análisis, comandos útiles
- **Exporters**: Prometheus, custom, PostgreSQL
**Ubicación**: `/system/skynet v8/07_OPERACION/monitoring.md`
---
## Estructura de Carpetas R2
```
s3://architect/system/skynet v8/07_OPERACION/
├── runbooks.md (6.6 KB)
├── incident_response.md (10.9 KB)
├── monitoring.md (17.0 KB)
└── INDEX_07_OPERACION.md (este archivo)
```
---
## Acceso Rápido
### Para operadores
1. Problema con servicio → Consultar `runbooks.md`
2. Incidente crítico → Consultar `incident_response.md`
3. Verificar estado del sistema → Consultar `monitoring.md`
### Para automatización
- Scripts de backup: Referir a `runbooks.md` - Restauración de backups
- Alertas automáticas: Referir a `monitoring.md` - Alertas Configuradas
- Escalación automática: Referir a `incident_response.md` - Escaleras de escalación
---
## Integración con otras secciones
| Sección | Relación |
|---------|----------|
| 01_ARCHITECTURE | Define componentes monitorear |
| 02_SECURITY | Colabora en incident response |
| 03_INFRASTRUCTURE | Detalles técnicos para runbooks |
| 04_DEPLOYMENT | Coordina con reinicio de servicios |
| 05_TESTING | Valida runbooks en staging |
| 06_TROUBLESHOOTING | Diagnostico previo a incidentes |
---
## Mejoras Futuras
1. Automatización adicional:
- Scripts Python para ejecutar runbooks
- Integración con orchestration tools (Kubernetes, etc.)
2. Aprendizaje automático:
- Análisis predictivo de fallos
- Detección anomalías avanzada
3. Documentación mejorada:
- Videos de procedimientos críticos
- Simulacros periódicos
---
**Última actualización**: 2025-12-30
**Versión**: Skynet v8.0
**Estado**: Operacional

View File

@@ -0,0 +1,152 @@
# Informe de Mejoras Sistema TZZR - 2026-01-01
## Resumen Ejecutivo
Se completó la auditoría y mejoras del sistema TZZR en servidores DECK y CORP.
### Resultado Final
| Servidor | Microservicios | Web Apps | PostgreSQL | Estado |
|----------|---------------|----------|------------|--------|
| DECK | 4/4 ✅ | 2/2 ✅ | 106 tablas | **OPERATIVO** |
| CORP | 4/4 ✅ | 2/2 ✅ | 37 tablas | **OPERATIVO** |
---
## Cambios Realizados
### 1. Endpoints Health Estandarizados
**Problema**: MindLink y Flow-UI solo tenían `/api/health`, inconsistente con microservicios que usan `/health`.
**Solución**: Agregado endpoint `/health` como alias en ambas aplicaciones.
**Archivos modificados**:
- `/opt/mindlink/app.py` (línea 338)
- `/opt/flow-ui/app.py` (línea 536)
**Commit**: `Add /health endpoint alias for consistency with microservices`
---
### 2. Claves SSH Configuradas
**Problema**: Flow-UI usa SSH para conectar a microservicios pero faltaba la clave `~/.ssh/tzzr` en DECK y CORP.
**Solución**: Copiada clave SSH desde ARCHITECT a ambos servidores.
**Archivos**:
- `/root/.ssh/tzzr` (DECK)
- `/root/.ssh/tzzr` (CORP)
---
### 3. Endpoint Feldman Corregido
**Problema**: Flow-UI llamaba a `/blocks` pero Feldman usa `/bloques`.
**Solución**: Actualizado endpoint en Flow-UI.
**Cambio**:
```python
# Antes
result = ssh_request(server, port, "GET", f"/blocks?limit={limit}")
# Después
result = ssh_request(server, port, "GET", f"/bloques?limit={limit}")
```
**Commit**: `Fix: Feldman endpoint /blocks -> /bloques for consistency with backend`
---
### 4. URL Flow-UI en MindLink Corregida
**Problema**: MindLink usaba `https://flows.tzzrdeck.me` que no está configurado en nginx.
**Solución**: Actualizado a IP directa `http://72.62.1.113:5080`.
**Commit**: `Fix: Update flowui URL to use direct IP instead of unconfigured domain`
---
### 5. Estructura R2 Consolidada
**Problema**: Carpeta duplicada `02_INFRAESTRUCTURA` junto a `04_INFRAESTRUCTURA`.
**Solución**:
- Movidos documentos de `02_INFRAESTRUCTURA/` a `04_INFRAESTRUCTURA/`
- Eliminada carpeta duplicada
**Archivos movidos**:
- `01_overview.md`
- `03_servicios_architect.md`
- `04_servicios_deck.md`
- `05_servicios_corp.md`
- `06_servicios_hst.md`
---
## Repositorios Actualizados en Gitea
| Repositorio | Commits | Descripción |
|-------------|---------|-------------|
| tzzr/mindlink | 2 | Health endpoint + URL fix |
| tzzr/flow-ui | 2 | Health endpoint + Feldman endpoint fix |
| tzzr/system-docs | 1 | Auditoría pre-mejoras |
---
## Verificación de Servicios
### DECK (72.62.1.113)
| Servicio | Puerto | Estado | Health |
|----------|--------|--------|--------|
| Clara | 5051 | ✅ Up | `ok` |
| Alfred | 5052 | ✅ Up | `healthy` |
| Mason | 5053 | ✅ Up | `healthy` |
| Feldman | 5054 | ✅ Up | `healthy` |
| MindLink | 5090 | ✅ Up | `ok` |
| Flow-UI | 5080 | ✅ Up | `ok` |
### CORP (92.112.181.188)
| Servicio | Puerto | Estado | Health |
|----------|--------|--------|--------|
| Margaret | 5051 | ✅ Up | `ok` |
| Jared | 5052 | ✅ Up | `healthy` |
| Mason | 5053 | ✅ Up | `healthy` |
| Feldman | 5054 | ✅ Up | `healthy` |
| MindLink | 5090 | ✅ Up | `ok` |
| Flow-UI | 5080 | ✅ Up | `ok` |
---
## Documentación Actualizada
### R2 (s3://architect/system/)
- `skynet v8/04_INFRAESTRUCTURA/` - Consolidada con docs de 02_INFRAESTRUCTURA
- `skynet v8/07_OPERACION/AUDITORIA_SISTEMA_2026-01-01.md` - Auditoría inicial
### Gitea (tzzr/system-docs)
- `07_OPERACION/AUDITORIA_SISTEMA_2026-01-01.md`
- `07_OPERACION/INFORME_MEJORAS_2026-01-01.md` (este documento)
---
## Próximos Pasos Recomendados
1. **Configurar nginx para dominios externos**:
- `flows.tzzrdeck.me``localhost:5080`
- `link.tzzrdeck.me``localhost:5090`
2. **Sincronizar schemas PostgreSQL**: DECK tiene 106 tablas, CORP solo 37
3. **Implementar CI/CD**: Automatizar deploys desde Gitea a servidores
4. **Monitoreo centralizado**: Agregar Prometheus/Grafana para métricas
---
*Generado: 2026-01-01 13:15 UTC*
*Sistema: CAPTAIN CLAUDE*

View File

@@ -0,0 +1,424 @@
# Procedimientos de Respuesta ante Incidentes - Skynet v8
## Procedimiento General ante Incidentes
### Fases de respuesta
1. **Detección**: Sistema de alertas detecta anomalía
2. **Confirmación**: Validar que es incidente real
3. **Escalación**: Notificar al equipo
4. **Investigación**: Determinar causa
5. **Mitigación**: Aplicar solución temporal
6. **Resolución**: Fix permanente
7. **Post-mortem**: Análisis y mejora
---
## Incidente: Caída de Servidor
### Severidad
**CRÍTICA** - Impacto: 100% del servicio indisponible
### Detección
- Sistema de monitoreo no recibe heartbeat
- Usuarios reportan servicio inaccesible
- Alertas en Grafana: `node_up == 0`
### Confirmación (2 minutos máximo)
```bash
# Verificar conectividad básica
ping 69.62.126.110
# Intentar conexión SSH
ssh -i ~/.ssh/tzzr architect@69.62.126.110
# Si SSH no responde, es caída real
```
### Escalación INMEDIATA
1. **Notificar a**:
- On-call engineer (5 min de respuesta)
- Engineering lead
- Operations manager
2. **Crear incident**
- Abrir INC ticket
- Timestamp inicio
- Severidad: P1-CRITICAL
3. **Canales de comunicación**
- Slack #incidents-critical
- Email a escalation-list@skynet.tzzr
- SMS a on-call (si disponible)
### Investigación inicial (5 minutos)
```bash
# Desde backup server
ssh -i ~/.ssh/tzzr root@72.62.1.113 # deck
# Verificar recursos
ping -c 3 69.62.126.110
ssh -o ConnectTimeout=5 root@69.62.126.110 "uptime"
# Verificar logs en firewall/router
ssh monitoring "tail -f /var/log/firewall.log | grep 69.62.126.110"
# Contactar proveedor datacenter
# Verificar alertas de potencia/red
```
### Mitigación Temporal (Si fallo de hardware)
#### Opción 1: Reinicio remoto
```bash
# Si acceso IPMI disponible
ipmitool -I lanplus -H ipmi.datacenter.com -U admin -P pass power reset
# Esperar 3 minutos
sleep 180
# Verificar si responde
ping -c 3 69.62.126.110
```
#### Opción 2: Failover a servidor backup
```bash
# Redirigir tráfico a deck (72.62.1.113)
# Actualizar DNS
# change A record: skynet.ttzr 300 IN A 72.62.1.113
# Sincronizar estado si posible
rsync -avz --delete /var/lib/postgresql/ deck:/var/lib/postgresql/
# Iniciar servicios en backup
ssh deck "systemctl start skynet-database skynet-api skynet-core"
```
### Resolución
- **Si hardware**: Contactar con datacenter para reemplazo
- **Si red**: Contactar ISP para restaurar conectividad
- **Si aplicación**: Debugging post-restauración
### Post-mortem (24 horas)
- Documentar timeline
- Identificar root cause
- Implementar prevención
- Actualizar runbooks
---
## Incidente: Ataque DDoS
### Severidad
**ALTA** - Impacto: Servicio degradado o inaccesible
### Detección
- Spike repentino de tráfico (>10x normal)
- Alertas: `request_rate > 50k/sec`
- Origen: Múltiples IPs no reconocidas
- Network utilization > 80% inbound
### Confirmación (1 minuto)
```bash
# Verificar tráfico
iftop -n -s 10
# Análisis de IPs origen
tcpdump -i eth0 -nnn 'tcp.port == 80 or tcp.port == 443' | \
awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20
# Patrones de ataque
# - SYN flood: conexiones incompletas
ss -antp | grep SYN_RECV | wc -l
# - HTTP flood: requests normales pero masivos
# - DNS amplification: puerto 53
# Verificar logs de aplicación
tail -f /var/log/skynet/access.log | head -100
```
### Escalación INMEDIATA
1. **Notificar**:
- Security team
- Network operations
- Incident commander
2. **Crear incident**
- INC ticket con "DDoS" en título
- Severidad: P2-HIGH (puede ser P1 si impacto crítico)
3. **Activar plan DDoS**
```bash
# Alertas automáticas envían:
# - Notificación a CDN provider
# - Activación de rate limiting
# - Análisis automático de patrones
```
### Mitigación Temporal (Primeros 5-10 minutos)
#### Paso 1: Rate limiting automático
```bash
# Activar rate limiting por IP
iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
# Alternativa: WAF rules
# modsecurity rule: SecAction phase:1,nolog,pass,setvar:ip.suspicious=1
```
#### Paso 2: Blacklist de IPs ofensoras
```bash
# Script para extraer top atacantes
tcpdump -i eth0 -nnn -c 10000 'tcp.port == 80 or tcp.port == 443' | \
awk '{print $3}' | cut -d. -f1-4 | \
sort | uniq -c | sort -rn | head -100 | \
awk '{print "iptables -A INPUT -s " $3 " -j DROP"}'
# O usar geo-blocking
geoiplookup <IP> | grep -E "CN|RU|KP" && echo "DROP"
```
#### Paso 3: Activar protección DNS
```bash
# Cambiar nameservers a proveedor con DDoS mitigation
# (e.g., CloudFlare, Akamai)
# Actualizar DNS:
# skynet.ttzr NS dns1.cloudflare.com
# skynet.ttzr NS dns2.cloudflare.com
# O activar Cloudflare proxy:
# change A record a IP de Cloudflare
# Cloudflare mitiga el ataque antes de llegar a nuestro servidor
```
### Escalación a DDoS Mitigation Service
```bash
# Si ataque persiste > 30 minutos
# Activar contrato con DDoS mitigation provider
# Ejemplo: Cloudflare
# 1. Cambiar nameservers
# 2. Enable "I'm under attack mode"
# 3. Cloudflare absorbe el tráfico malicioso
# Ejemplo: AWS Shield Advanced
# 1. Redirigir tráfico a AWS CloudFront
# 2. AWS absorbe y filtra ataque
# 3. Tráfico legítimo llega a servidor
```
### Investigación paralela
```bash
# Mientras se mitiga:
# 1. Analizar patrones de ataque
# 2. Identificar botnet o atacante
# 3. Reportar a ISP del atacante
# 4. Notificar law enforcement si necesario
# Comando: detectar patrón de User-Agent
tail -f /var/log/skynet/access.log | grep -o 'User-Agent: [^"]*' | sort | uniq -c | sort -rn | head -5
```
### Resolución
- Dejar mitigación activa mientras persista ataque
- Bloqueo permanente de IPs confirmadas maliciosas
- Mantener WAF rules
- Monitoreo intensivo por 24 horas
### Post-mortem
- Análisis de logs del ataque
- Identificación de patrones para prevención futura
- Actualización de WAF rules
- Prueba de carga para validar capacidad
---
## Incidente: Breach de Seguridad
### Severidad
**CRÍTICA** - Impacto: Acceso no autorizado a datos sensibles
### Detección
- Alertas de IDS/IPS
- Comportamiento anómalo de usuario
- Cambios no autorizados en archivos críticos
- Alertas de WAF: SQLi, RFI, etc.
### Confirmación (Inmediato)
```bash
# Verificar logs de seguridad
grep "ALERT\|ERROR\|FAILED" /var/log/auth.log | tail -50
# Revisar cambios recientes
find /var/www /etc /root -mtime -1 -ls
# Búsqueda de shells web
find / -name "*.php" -o -name "*.jsp" -o -name "*.asp" | \
xargs grep -l "exec\|system\|shell_exec" 2>/dev/null
# Revisar procesos anómalos
ps auxf | grep -E "bash|nc|perl|python" | grep -v grep
```
### Escalación CRÍTICA + Aislamiento (1 minuto)
1. **AISLAR SERVIDOR INMEDIATAMENTE**
- Desconectar del firewall si es posible
- O bloquear tráfico no autorizado
```bash
# Bloquear acceso excepto admin
iptables -F INPUT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s <ADMIN_IP> -j ACCEPT
iptables -A INPUT -j DROP
```
2. **Notificar a**:
- CTO / Security lead (inmediato)
- Incident commander
- Legal team
- HR (si credenciales de empleado usadas)
3. **Crear incident**
- INC ticket: "SECURITY BREACH"
- Severidad: P1-CRITICAL
- Activar crisis management
4. **Notificar stakeholders**
- CEO
- Directores de área afectada
- Equipo legal
### Investigación (En paralelo con aislamiento)
```bash
# NO modificar nada en el servidor comprometido aún
# Preservar evidencia
# 1. Identificar punto de entrada
grep "FAILED\|UNAUTHORIZED" /var/log/auth.log | tail -100
# 2. Buscar malware/backdoors
find /tmp /home /var/tmp -mtime -1 -type f | xargs file
strings /var/log/syslog | grep -E "curl|wget|chmod" | tail -20
# 3. Revisar cambios en usuarios/permisos
grep "sudo\|usermod\|chmod 777" /var/log/auth.log
# 4. Revisar conexiones de red
netstat -pantu | grep ESTABLISHED | head -20
lsof -i -P -n | grep -v LISTEN
# 5. Examinar sistema de archivos en disco
# (hacer copia forense primero)
ddrescue /dev/sda /mnt/forensic/sda.img
mount -o ro /mnt/forensic/sda.img /mnt/forensic_mount
# 6. Buscar cambios en archivos críticos
find /etc /root /var/www -mtime -3 ! -path "*/.*" -type f -ls
```
### Contención
```bash
# 1. Si credenciales comprometidas
# - Resetear contraseñas de todos los usuarios
# - Cambiar API keys
# - Revocar OAuth tokens
# 2. Si datos expuestos
# - Inventariar datos expuestos
# - Notificar a usuarios afectados (según GDPR/CCPA)
# - Contactar a asegurador
# 3. Parches de seguridad
# Aplicar patches a vulnerabilidad explotada
# Actualizar software vulnerable
```
### Recovery
```bash
# Opción 1: Restore desde backup limpio pre-breach
systemctl stop skynet-*
pg_restore -d postgres /backups/skynet_2025-12-25.sql # Anterior al breach
systemctl start skynet-*
# Opción 2: Rebuild desde source control
git clone https://gitea.ttzr/skynet/core.git
cd core && git checkout commit_seguro
./install.sh
```
### Post-mortem (CRÍTICO)
- Análisis forense completo
- Publicar breach disclosure si requerido por ley
- Auditoría de seguridad completa
- Implementar controles preventivos
- Revisión de políticas de seguridad
---
## Contactos de Emergencia
### Equipo de On-Call
| Rol | Nombre | Teléfono | Email | Backup |
|-----|--------|----------|-------|--------|
| Principal | [ON-CALL] | +X XXXXXXXXX | oncall@skynet.ttzr | [BACKUP] |
| Security | CISO | +X XXXXXXXXX | ciso@skynet.ttzr | Security Lead |
| Operations | Ops Manager | +X XXXXXXXXX | ops@skynet.ttzr | DevOps Lead |
| Database | DBA Lead | +X XXXXXXXXX | dba@skynet.ttzr | DBA Senior |
### Escalación Automática
```
Incidente detectado
Alertas a Slack #incidents
Si no confirmado en 5 min → Email a on-call
Si no responde en 10 min → SMS + teléfono
Si no responde en 15 min → Escalar a manager
Si Severidad P1 → Activar crisis team
```
### Proveedores Externos
#### Datacenter
- **Proveedor**: [DATACENTER_NAME]
- **Contacto NOC**: +X XXXXXXXXX
- **Tickets**: https://support.datacenter.com
- **Emergencia 24/7**: [NÚMERO]
#### ISP
- **Proveedor**: [ISP_NAME]
- **Contacto**: +X XXXXXXXXX
- **Status page**: https://status.isp.com
- **Emergencia**: [NÚMERO]
#### Banco de datos
- **Proveedor**: [DB_PROVIDER]
- **Support**: [EMAIL/TELÉFONO]
- **Documentation**: [URL]
### Escaleras de escalación según severidad
#### P1-CRITICAL (Todos afectados)
1. On-call engineer (inmediato)
2. Tech lead (1 min)
3. Engineering manager (2 min)
4. CTO (3 min)
5. CEO (5 min si no resolviendo)
#### P2-HIGH (Servicio degradado)
1. On-call engineer
2. Tech lead (si no resolviendo en 10 min)
3. Engineering manager (si no resolviendo en 30 min)
#### P3-MEDIUM (Funcionalidad limitada)
1. On-call engineer
2. Tech lead (próximo turno si no urgente)
#### P4-LOW (Feature requests, problemas menores)
1. Queue para próximo sprint
2. No escalación urgente

557
07_OPERACION/monitoring.md Normal file
View File

@@ -0,0 +1,557 @@
# Monitoreo y Observabilidad - Skynet v8
## Arquitectura de Monitoreo
```
┌─────────────────────────────────────────────────────────────┐
│ Skynet v8 Services │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ skynet-core │ │ skynet-api │ │ skynet-db │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ └──────────────────┼───────────────────┘ │
│ │ │
│ ┌──────────────────┴──────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Exporters / Collectors │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │ │
│ │ │ Prometheus │ │ Node Expt │ │ Filebeat │ │ │
│ │ │ Exporter │ │ (system) │ │ (logs) │ │ │
│ │ └──────────────┘ └──────────────┘ └────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
└──────────────────────┬──────────────────────────────────────┘
┌──────────────┼──────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────────┐
│ Grafana │ │ ELK │ │ Alert Mgr │
│ (Viz) │ │ (Logs) │ │ (Alerts) │
└─────────┘ └──────────┘ └──────────────┘
│ │ │
└──────────────┼───────────────┘
┌─────────────────┐
│ Notification │
│ Channels │
│ (Slack/Email) │
└─────────────────┘
```
---
## Métricas a Monitorear
### 1. Métricas de Aplicación (skynet-core)
#### Procesamiento y Throughput
```
Métrica | Umbral Normal | Alerta Warn | Alerta Critical
---------------------------|---------------|-------------|----------------
requests_per_second | 100-500 | > 750 | > 1000
response_time_p50 | < 100ms | > 200ms | > 500ms
response_time_p95 | < 500ms | > 1000ms | > 2000ms
response_time_p99 | < 1000ms | > 2000ms | > 5000ms
error_rate | < 0.1% | > 0.5% | > 1%
success_rate | > 99.9% | < 99.5% | < 99%
```
#### Ejemplos Prometheus
```
# Request rate (requests/sec)
rate(http_requests_total[5m])
# Response time percentiles
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# Error rate
rate(http_requests_total{status=~"5.."}[5m]) /
rate(http_requests_total[5m])
# Active connections
skynet_active_connections
```
### 2. Métricas de Base de Datos (skynet-database)
#### Performance
```
Métrica | Umbral Normal | Alerta | Critical
-----------------------------|---------------|---------|----------
query_execution_time_p95 | < 100ms | > 500ms | > 2000ms
transactions_per_second | 100-1000 | > 2000 | > 5000
active_connections | 10-50 | > 100 | > 150
connection_utilization_pct | < 50% | > 80% | > 95%
replication_lag_bytes | < 1MB | > 100MB | > 1GB
```
#### Ejemplo Prometheus
```
# Query latency
histogram_quantile(0.95, rate(pg_slow_queries_duration_seconds_bucket[5m]))
# Transactions/sec
rate(pg_transactions_total[1m])
# Active connections
pg_stat_activity_count{state="active"}
# Replication lag
pg_replication_lag_bytes / 1024 / 1024 # MB
# Connection ratio
pg_stat_activity_count / pg_settings_max_connections * 100
```
### 3. Métricas de Sistema (Node Exporter)
#### CPU y Memoria
```
Métrica | Umbral Normal | Alerta Warn | Critical
---------------------------|---------------|-------------|----------
cpu_usage_percent | < 70% | > 80% | > 95%
load_average_1min | < cores | > cores*1.5 | > cores*2
memory_usage_percent | < 80% | > 85% | > 95%
swap_usage_percent | < 10% | > 30% | > 50%
```
#### Disco e I/O
```
Métrica | Umbral Normal | Alerta Warn | Critical
---------------------------|---------------|-------------|----------
disk_usage_percent | < 70% | > 80% | > 95%
disk_io_read_mb_sec | variable | > 500MB/s | > 1GB/s
disk_io_write_mb_sec | variable | > 500MB/s | > 1GB/s
inode_usage_percent | < 70% | > 80% | > 95%
```
#### Red
```
Métrica | Umbral Normal | Alerta Warn | Critical
---------------------------|---------------|-------------|----------
network_in_mbps | variable | > 900Mbps | > 980Mbps
network_out_mbps | variable | > 900Mbps | > 980Mbps
packet_loss_percent | < 0.1% | > 0.5% | > 1%
tcp_connections | < 10000 | > 20000 | > 30000
tcp_time_wait | < 5000 | > 10000 | > 20000
```
#### Ejemplos Prometheus
```
# CPU usage
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# Memory usage
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
# Disk usage
(node_filesystem_size_bytes{fstype!="tmpfs"} - node_filesystem_avail_bytes) /
node_filesystem_size_bytes * 100
# Network throughput
rate(node_network_transmit_bytes_total{device="eth0"}[5m]) / 1024 / 1024 # MB/s
```
### 4. Métricas de Seguridad
#### Acceso y Autenticación
```
Métrica | Umbral Normal | Alerta
-----------------------------|---------------|--------
failed_login_attempts_per_min | < 5 | > 20
ssh_login_failures | < 3/10min | > 10/10min
sudo_usage_anomaly | histórico | +50% desviación
unauthorized_api_calls | < 1/min | > 10/min
```
#### Integridad de datos
```
Métrica | Acción
-----------------------------|------
database_checksum_errors | Alerta + Investigar inmediatamente
file_integrity_changes | Log + Review semanal
unauthorized_user_creation | Alerta crítica
privilege_escalation_attempt | Alerta crítica + Log forense
```
#### Ejemplo: Detección de anomalías
```bash
# Buscar cambios no autorizados en archivos críticos
aide --check --config=/etc/aide/aide.conf
# Auditar cambios de permisos
auditctl -l
ausearch -k privileged | tail -100
# Monitorear login attempts
faillog -a # Summary de todos los usuarios
lastb # Últimas 10 sesiones fallidas
```
---
## Alertas Configuradas
### Sistema de Alertas
Archivo: `/etc/prometheus/alert_rules.yml`
#### Alertas P1 (CRÍTICAS - 1 minuto)
```yaml
- alert: ServiceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "{{ $labels.instance }} DOWN"
action: "Verificar immediately, ejecutar runbook de reinicio"
- alert: DiskFull
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "Disco al 95% en {{ $labels.instance }}"
action: "Ejecutar escalado de almacenamiento"
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "Error rate > 5% en {{ $labels.job }}"
action: "Investigar logs, posible DDoS o fallo de aplicación"
- alert: DatabaseDown
expr: pg_up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "PostgreSQL DOWN en {{ $labels.instance }}"
action: "Ejecutar runbook de failover o reinicio"
- alert: ReplicationLagCritical
expr: (pg_replication_lag_bytes / 1024 / 1024) > 1000 # 1GB
for: 5m
labels:
severity: critical
annotations:
summary: "Replication lag {{ $value }}MB"
action: "Verificar red, aumentar bandwidth, o promover replica"
```
#### Alertas P2 (ALTAS - 5 minutos)
```yaml
- alert: HighCPU
expr: (100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80
for: 5m
labels:
severity: high
annotations:
summary: "CPU > 80% en {{ $labels.instance }}"
action: "Investigar procesos, considerar escalado"
- alert: HighMemory
expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.85
for: 5m
labels:
severity: high
annotations:
summary: "Memoria > 85% en {{ $labels.instance }}"
action: "Investigar memory leaks, escalar RAM"
- alert: SlowQueries
expr: histogram_quantile(0.95, rate(pg_slow_queries_duration_seconds_bucket[5m])) > 1
for: 5m
labels:
severity: high
annotations:
summary: "Queries lentas p95 {{ $value }}s"
action: "Analizar EXPLAIN PLAN, optimizar índices"
- alert: HighConnectionCount
expr: (pg_stat_activity_count / pg_settings_max_connections) > 0.8
for: 10m
labels:
severity: high
annotations:
summary: "Conexiones DB {{ $value }}%"
action: "Investigar connection leaks, escalar max_connections"
- alert: DDoSDetected
expr: rate(http_requests_total[5m]) > 10000
for: 2m
labels:
severity: high
annotations:
summary: "Posible DDoS: {{ $value }} req/sec"
action: "Activar rate limiting, contactar ISP"
```
#### Alertas P3 (MEDIAS - 15 minutos)
```yaml
- alert: DiskSpaceLow
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.15
for: 15m
labels:
severity: medium
annotations:
summary: "Disco < 15% en {{ $labels.instance }}"
action: "Agendar escalado de almacenamiento"
- alert: BackupFailed
expr: time() - backup_last_successful_timestamp > 86400 # 24h
for: 1h
labels:
severity: medium
annotations:
summary: "Backup no completado en > 24h"
action: "Verificar proceso de backup, logs"
- alert: CertificateExpiring
expr: (ssl_cert_expire_timestamp - time()) / 86400 < 30
labels:
severity: medium
annotations:
summary: "SSL cert vence en {{ $value }} días"
action: "Renovar certificado"
```
---
## Dashboards Disponibles
### Dashboard 1: Visión General (System Overview)
**URL**: `http://grafana.skynet.ttzr/d/overview`
**Paneles**:
- Estado de servicios (verde/rojo)
- Request rate (últimas 24h)
- Error rate (trending)
- CPU/Memoria (gauges)
- Disk space (stacked)
- Network I/O (dual axis)
- Database connections
- Top errors (tabla)
### Dashboard 2: Rendimiento de Aplicación (Application Performance)
**URL**: `http://grafana.skynet.ttzr/d/app-performance`
**Paneles**:
- Response time p50/p95/p99
- Throughput (requests/sec)
- Error rate by endpoint
- Hot endpoints (top 10)
- Request distribution (by method)
- Slowest endpoints
- Error distribution by type
- Request size distribution
### Dashboard 3: Rendimiento de Base de Datos (Database Performance)
**URL**: `http://grafana.skynet.ttzr/d/db-performance`
**Paneles**:
- Transactions/sec
- Query execution time percentiles
- Slow queries (top 10)
- Table sizes
- Index usage
- Cache hit ratio
- Replication lag
- Active connections
- Lock contention
- Autovacuum status
### Dashboard 4: Infraestructura y Hardware (Infrastructure)
**URL**: `http://grafana.skynet.ttzr/d/infrastructure`
**Paneles**:
- CPU utilization (por core)
- Memory breakdown (used/buffers/cache)
- Load average
- Disk I/O (read/write MB/s)
- Disk space by mount point
- Network throughput (in/out)
- Network errors/dropped packets
- TCP connection states
- Inode usage
### Dashboard 5: Seguridad y Logs (Security)
**URL**: `http://grafana.skynet.ttzr/d/security`
**Paneles**:
- Failed login attempts
- SSH connection attempts
- Firewall blocks (top IPs)
- Privilege escalation attempts
- API calls unauthorized
- File integrity changes
- Process anomalies
- Network connections unusual
---
## Logs Importantes
### Ubicaciones de logs
```
/var/log/skynet/
├── core.log # Logs de aplicación principal
├── api.log # Logs de API server
├── database.log # Logs de conexiones DB
└── error.log # Errores consolidados
/var/log/
├── auth.log # Logins, sudo
├── syslog # Mensajes del kernel
├── fail2ban.log # Intentos de acceso fallidos
└── postgresql/
└── postgresql.log # Logs de PostgreSQL
/var/lib/postgresql/
└── pg_log/ # Logs detallados de DB
```
### Log Analysis Queries
#### ELK / Kibana
```json
# Top 10 endpoints por error
{
"aggs": {
"endpoints": {
"terms": {
"field": "endpoint.keyword",
"size": 10,
"order": {"errors": "desc"}
},
"aggs": {
"errors": {
"filter": {"range": {"status": {"gte": 500}}}
}
}
}
}
}
# Response time trend
{
"aggs": {
"time_trend": {
"date_histogram": {
"field": "@timestamp",
"interval": "1m"
},
"aggs": {
"p95_latency": {
"percentiles": {
"field": "response_time_ms",
"percents": [95]
}
}
}
}
}
}
# Failed logins por IP
{
"query": {
"term": {"event": "failed_login"}
},
"aggs": {
"by_ip": {
"terms": {"field": "source_ip", "size": 20}
}
}
}
```
### Comandos útiles de análisis
```bash
# Top errores en última hora
grep ERROR /var/log/skynet/error.log | grep -o "ERROR [^:]]*" | \
sort | uniq -c | sort -rn | head -10
# Endpoints lentos
grep "response_time" /var/log/skynet/api.log | \
awk '{print $5, $1}' | sort -n | tail -10
# Intentos de acceso fallidos
grep "Failed" /var/log/auth.log | \
grep -o "from [0-9.]*" | sort | uniq -c | sort -rn
# Errors por hora
grep ERROR /var/log/skynet/error.log | \
cut -d' ' -f1 | cut -d: -f1-2 | uniq -c
```
---
## Instrumentación y Exporters
### Prometheus Node Exporter
```bash
# Verificar que está corriendo
systemctl status prometheus-node-exporter
# Metrics disponibles
curl http://localhost:9100/metrics | head -50
# Configuración
cat /etc/prometheus/node_exporter_args
# Típicamente: --collector.textfile.directory=/var/lib/node_exporter/textfile_collector
```
### Custom Exporter (skynet-exporter)
```bash
# Métricas customizadas de Skynet
curl http://localhost:9200/metrics | grep skynet_
# Ejemplos:
# skynet_requests_total{endpoint="/api/v1/data"}
# skynet_response_time_seconds_bucket{endpoint="/api/v1/data", le="0.1"}
# skynet_database_connections{state="active"}
# skynet_cache_hit_ratio
```
### PostgreSQL Exporter
```bash
# Verificar exporter de PostgreSQL
curl http://localhost:9187/metrics | grep pg_
# Métricas principales:
# pg_stat_database_tup_fetched
# pg_stat_database_tup_inserted
# pg_stat_database_tup_updated
# pg_stat_database_tup_deleted
# pg_up (1 si DB está up, 0 si down)
```
---
## Checklist de Monitoreo Diario
- [ ] Revisar estado de todos los dashboards
- [ ] Verificar que no hay alertas P1 sin resolver
- [ ] Analizar tendencias de performance (¿empeorando?)
- [ ] Verificar backup completó exitosamente
- [ ] Revisar log de acceso para anomalías
- [ ] Confirmar que replicación está al día
- [ ] Verificar espacio en disco (< 85%)
- [ ] Revisar certificados SSL (> 30 días para expirar)
- [ ] Documentar incident report si hubo P1/P2

294
07_OPERACION/runbooks.md Normal file
View File

@@ -0,0 +1,294 @@
# Runbooks - Operación Skynet v8
## Runbook: Reinicio de servicios
### Objetivo
Reiniciar servicios del sistema sin afectar operaciones críticas.
### Procedimiento
1. **Verificar estado actual**
```bash
systemctl status skynet-core
systemctl status skynet-database
systemctl status skynet-api
```
2. **Notificar a usuarios (si aplica)**
- Enviar notificación de mantenimiento planeado
- Esperar confirmación de ventana de mantenimiento
3. **Reiniciar servicios en orden**
```bash
# Primero servicios auxiliares
systemctl restart skynet-cache
systemctl restart skynet-broker
# Luego servicios principales
systemctl restart skynet-database
sleep 30
systemctl restart skynet-api
sleep 20
systemctl restart skynet-core
```
4. **Verificar estado post-reinicio**
```bash
systemctl status skynet-core
systemctl status skynet-database
systemctl status skynet-api
# Verificar conectividad
curl -s http://localhost:8080/health
curl -s http://localhost:5432/ping
```
5. **Validar operación normal**
- Verificar logs sin errores críticos
- Ejecutar health checks
- Monitorear métricas durante 5 minutos
### Rollback
Si hay fallos:
```bash
systemctl stop skynet-core
systemctl stop skynet-api
systemctl stop skynet-database
# Restaurar desde último snapshot conocido
pg_restore -d skynet /backups/skynet_latest.sql
systemctl start skynet-database
systemctl start skynet-api
systemctl start skynet-core
```
### Tiempo estimado
20-30 minutos con validación
---
## Runbook: Failover de base de datos
### Objetivo
Cambiar a base de datos secundaria en caso de fallo de primaria.
### Prerrequisitos
- Replicación configurada y activa
- Sistema de monitoreo detectó fallo de primaria
- Base de datos secundaria disponible
### Procedimiento
1. **Confirmar fallo de primaria**
```bash
# Intentar conectarse a primaria
psql -h skynet-primary -U postgres -d skynet -c "SELECT 1"
# Verificar lag de replicación
psql -h skynet-primary -U postgres -c "SELECT slot_name, restart_lsn FROM pg_replication_slots"
```
2. **Promover secundaria**
```bash
# En servidor secundario
pg_ctl promote -D /var/lib/postgresql/14/main
# Esperar 30 segundos para que complete
sleep 30
# Verificar estado
psql -U postgres -c "SELECT pg_is_wal_replay_paused()"
```
3. **Redirigir aplicaciones**
```bash
# Actualizar DNS o connection string
# En skynet-api.conf:
# database_host = skynet-secondary
systemctl restart skynet-api
```
4. **Verificar operación normal**
```bash
# Validar escrituras en nueva primaria
psql -h skynet-secondary -U postgres -d skynet -c "INSERT INTO test VALUES (NOW())"
# Monitorear performance
watch -n 2 'psql -h skynet-secondary -U postgres -c "SELECT count(*) FROM skynet_logs"'
```
5. **Informar del failover**
- Registrar en incident log
- Notificar al equipo
- Agendar recuperación de primaria
### Recovery de primaria
```bash
# Una vez primaria se recupere:
pg_basebackup -h skynet-primary -D /var/lib/postgresql/14/main -U replication
systemctl start postgresql
```
### Tiempo estimado
5-10 minutos
---
## Runbook: Restauración de backups
### Objetivo
Restaurar datos desde backups en caso de corrupción o pérdida de datos.
### Tipos de restauración
#### 1. Restauración completa
```bash
# Detener servicios
systemctl stop skynet-core
systemctl stop skynet-api
systemctl stop skynet-database
# Restaurar backup completo
pg_restore -C -d postgres /backups/skynet_full_2025-12-30.sql
# Reiniciar servicios
systemctl start skynet-database
sleep 30
systemctl start skynet-api
systemctl start skynet-core
```
#### 2. Restauración point-in-time (PITR)
```bash
# Restaurar hasta timestamp específico
psql -U postgres -d skynet -c "
SELECT pg_wal_replay_pause();
SELECT pg_xact_xmin(xid) FROM pg_xact;
"
# Restaurar WAL archive hasta timestamp
pg_restore -U postgres -d skynet \
-e -t tabla_critica /backups/skynet_full.sql
# Aplicar WAL hasta punto
pg_wal_replay_start()
```
#### 3. Restauración de tabla específica
```bash
# Restaurar solo tabla corrupta
pg_restore -d skynet -t tabla_corrupta /backups/skynet_full.sql
# Validar integridad
ANALYZE tabla_corrupta;
```
### Validación post-restauración
```bash
# Verificar integridad
psql -U postgres -d skynet -c "SELECT COUNT(*) FROM pg_stat_user_tables"
# Comparar checksums
pg_basebackup --wal-method=fetch -l "restore_$(date +%s)"
# Validar índices
REINDEX DATABASE skynet;
```
### Tiempo estimado
- Completa: 30-60 minutos (depende tamaño)
- PITR: 15-45 minutos
- Tabla: 5-15 minutos
---
## Runbook: Escalado de recursos
### Objetivo
Aumentar capacidad de computo o almacenamiento sin downtime.
### Escalado de CPU/RAM
1. **Evaluar necesidad**
```bash
# Monitorear uso actual
top -n 1 | head -20
free -h
# Proyectar crecimiento
# Si uso > 80%, escalar inmediatamente
# Si proyectado > 80% en 7 días, escalar
```
2. **Escalar infraestructura**
```bash
# En cloud provider o hypervisor
# Aumentar CPU cores
# Aumentar memoria RAM
# Aplicar cambios sin reinicio (si soportado)
```
3. **Verificar en SO**
```bash
lscpu
free -h
```
4. **Rebalancear servicios**
```bash
# Aumentar workers/threads en config
systemctl restart skynet-api
# Aumentar shared_buffers en PostgreSQL
# postgresql.conf: shared_buffers = 16GB (en lugar de 8GB)
systemctl restart skynet-database
```
### Escalado de almacenamiento
1. **Monitorear uso**
```bash
df -h /var/lib/postgresql
du -sh /backups
# Alerta si > 80% utilizado
```
2. **Agregar espacio**
```bash
# Opción 1: Aumentar volumen existente
lvextend -l +50G /dev/vg0/lv_data
resize2fs /dev/vg0/lv_data
# Opción 2: Agregar nuevo volumen
# Montar en /data2
# Configurar replicación a nuevo volumen
```
3. **Validar cambios**
```bash
df -h /var/lib/postgresql
# Debe mostrar nuevo tamaño
```
4. **Monitorear performance**
- Velocidad I/O
- Latencia de queries
- Crecimiento de espacios
### Tiempo estimado
- CPU/RAM: 30 minutos - 2 horas (depende downtime)
- Almacenamiento: 1-4 horas (sin downtime posible)
---
## Escalabilidad Matriz
| Recurso | Umbral Acción | Aumento | Tiempo |
|---------|---|---|---|
| CPU | >85% x 5min | +2 cores | 30min-2h |
| RAM | >80% x 10min | +8GB | 30min-2h |
| Disco | >85% utilizado | +50% capacidad | 1-4h |
| Conexiones DB | >80% max_connections | +50 conexiones | 15min |
| Replication lag | >10GB | Increase bandwidth | Immediate |

View File

@@ -0,0 +1,469 @@
# ANEXO 1 - REFERENCIA TÉCNICA
**Versión:** 10.0
**Fecha:** 6 Enero 2026
**Sistema:** TZZR
---
# §1. INTERFACES WEB DESPLEGADAS
## 1.1 MindLink - Portal Unificado
Portal visual que centraliza acceso a todos los servicios TZZR.
| Instancia | URL | Servidor | Puerto |
|-----------|-----|----------|--------|
| CENTRAL | https://link.tzzrarchitect.me | DECK | 5090 |
| CORP | https://link.tzzrcorp.me | CORP | 5090 |
| DECK | https://link.tzzrdeck.me | DECK | 5090 |
**Stack:** Python + Flask + Jinja2
**Ubicación:** `/opt/mindlink/`
**Proceso:** systemd
### Endpoints
```
GET / # Frontend
GET /api/health # Health check
GET /api/services # Lista servicios
GET /api/services/status # Estado servicios
POST /api/shorten # Acortar URL
GET /s/<code> # Redirección
```
---
## 1.2 Flow-UI - Gestión de Flujos
Interfaz web para gestionar el flujo de datos TZZR.
| Instancia | URL | Servidor | Puerto |
|-----------|-----|----------|--------|
| DECK | https://flows.tzzrdeck.me | DECK | 5080 |
| CORP | https://flows.tzzrcorp.me | CORP | 5080 |
**Stack:** Python + Flask + Jinja2
**Ubicación:** `/opt/flow-ui/`
**Proceso:** systemd
### Secciones
| Sección | Función |
|---------|---------|
| Entrada | Formulario ingesta, lista entradas |
| Mason | Editor items pendientes |
| Feldman | Milestones, bloques, verificación |
| Flujos | Gestión flujos (Alfred/Jared) |
| HST | Tags y grupos |
| Dashboard | Vista general |
| Admin | Logs y restart |
### Endpoints
```
POST /api/ingest # Enviar a Clara/Margaret
GET /api/entradas # Listar entradas
GET /api/mason/pending # Items pendientes
PUT /api/mason/item/<id> # Actualizar item
POST /api/mason/item/<id>/resolve # Resolver → Feldman
GET /api/feldman/milestones # Listar milestones
GET /api/feldman/verify/<hash> # Verificar hash
GET /api/flujos # Listar flujos
POST /api/flujos/<id>/ejecutar # Ejecutar flujo
```
---
## 1.3 Directus - CMS Headless
| Instancia | URL | Servidor | Puerto | Base de Datos |
|-----------|-----|----------|--------|---------------|
| DECK | https://directus.tzzrdeck.me | DECK | 8055 | deck |
| CORP | https://directus.tzzrcorp.me | CORP | 8055 | corp |
| HST | https://hst.tzrtech.org | HST | 8055 | hst_images |
| Lumalia | - | HST | 8056 | lumalia |
| Personal | - | HST | 8057 | personal |
| ARCHITECT | https://directus.tzzrarchitect.me | ARCHITECT | 8055 | tzzr |
---
# §2. SERVICIOS AUXILIARES
## 2.1 DECK (72.62.1.113)
| Servicio | Puerto | URL | Descripción |
|----------|--------|-----|-------------|
| Nextcloud | 8084 | nextcloud.tzzrdeck.me | Almacenamiento |
| Vaultwarden | 8085 | vault.tzzrdeck.me | Contraseñas |
| Shlink | 8083 | - | URLs cortas |
| NTFY | 8080 | - | Notificaciones |
| Windmill | 8100 | - | Workflows |
| Mailcow | 8443 | - | Email |
| FileBrowser | 8082 | - | Archivos |
## 2.2 CORP (92.112.181.188)
| Servicio | Puerto | URL | Descripción |
|----------|--------|-----|-------------|
| Nextcloud | 8080 | nextcloud.tzzrcorp.me | Almacenamiento |
| Vaultwarden | 8081 | vault.tzzrcorp.me | Contraseñas |
| Shlink | 8082 | shlink.tzzrcorp.me | URLs cortas |
| Addy | 8083 | addy.tzzrcorp.me | Email aliases |
| NTFY | 8880 | ntfy.tzzrcorp.me | Notificaciones |
| Windmill | 8000 | localhost:8000 | Workflows |
## 2.3 HST (72.62.2.84)
| Servicio | Puerto | Descripción |
|----------|--------|-------------|
| FileBrowser | 8081 | Administrador archivos |
| HST-Images | 80/443 | Nginx imágenes estáticas |
## 2.4 ARCHITECT (69.62.126.110)
| Servicio | Puerto | URL | Descripción |
|----------|--------|-----|-------------|
| Gitea | 3000 | git.tzzrarchitect.me | Repositorios |
| Windmill | 8100 | - | Workflows |
| Infisical | 8082 | - | Secretos |
---
# §3. RESUMEN DE PUERTOS
| Puerto | Servicio | DECK | CORP | HST | ARCHITECT |
|--------|----------|------|------|-----|-----------|
| 80/443 | Reverse Proxy | Caddy | Caddy | Docker | Nginx |
| 3000 | Gitea | - | - | - | ✓ |
| 5000 | HST-API | - | - | ✓ | - |
| 5051 | Clara/Margaret | ✓ | ✓ | - | - |
| 5052 | Alfred/Jared | ✓ | ✓ | - | - |
| 5053 | Mason | ✓ | ✓ | - | - |
| 5054 | Feldman | ✓ | ✓ | - | - |
| 5055 | Oracle (futuro) | ✓ | ✓ | - | - |
| 5080 | Flow-UI | ✓ | ✓ | - | - |
| 5090 | MindLink | ✓ | ✓ | - | - |
| 8055 | Directus | ✓ | ✓ | ✓ | ✓ |
| 8080/8880 | NTFY/Nextcloud | NTFY | NC | - | - |
| 8100 | Windmill | ✓ | - | - | ✓ |
---
# §4. SERVIDOR HST
## 4.1 Estructura Filesystem
```
/opt/hst/
├── api/ # Flask API (app.py, Dockerfile)
├── images/ # Imágenes PNG (926 archivos)
│ └── thumb/ # Thumbnails
├── directus/
│ ├── extensions/
│ └── uploads/
├── nginx/
│ └── default.conf
├── scripts/
│ └── refresh_views.sh
├── filebrowser/
├── backups/
└── docker-compose.yml
```
## 4.2 Contenedores Docker HST
| Contenedor | Puerto | Función |
|------------|--------|---------|
| hst-api | 5000 | API Flask principal |
| hst-images | 80, 443 | Nginx servidor imágenes |
| directus_hst | 8055 | CMS Directus |
| directus_lumalia | 8056 | CMS Lumalia |
| directus_personal | 8057 | CMS Personal |
| postgres_hst | 5432 | PostgreSQL |
| filebrowser | 8081 | Gestión archivos |
## 4.3 Dominios HST
| Dominio | Destino |
|---------|---------|
| tzrtech.org | Imágenes estáticas + /api/ |
| hst.tzrtech.org | Directus CMS |
| graph.tzrtech.org | API directa |
| lumalia.tzrtech.org | Directus Lumalia |
| pablo.tzrtech.org | Directus Personal |
## 4.4 API HST
Base: `https://tzrtech.org/api/`
| Endpoint | Método | Descripción |
|----------|--------|-------------|
| /api/index.json | GET | Índice general |
| /api/tags | GET | Buscar tags |
| /api/tags/{mrf} | GET | Obtener tag por hash |
| /api/tags/{mrf}/children | GET | Hijos de un tag |
| /api/tags/{mrf}/related | GET | Tags relacionados |
| /api/tree | GET | Árbol jerárquico |
| /api/graph | GET | Grafo de relaciones |
| /api/library | GET | Lista de bibliotecas |
| /api/grupos | GET | Lista de grupos |
---
# §5. TABLAS POSTGRESQL POR SERVIDOR
## 5.1 Resumen
| Servidor | Bases de Datos | Total Tablas |
|----------|----------------|--------------|
| DECK | tzzr, deck | 30 |
| CORP | tzzr, corp | 89 |
| HST | directus, hst_images, lumalia, personal | 143 |
| ARCHITECT | tzzr, windmill | 122 |
## 5.2 Tablas Core TZZR
### Secretaría (Clara/Margaret)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| immutable_log | DECK, CORP | Log inmutable principal |
| clara_log | DECK | Log específico Clara |
| clara_registros | DECK | Registros Clara |
| margaret_log | CORP | Log específico Margaret |
| margaret_registros | CORP | Registros Margaret |
### Administración (Mason)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| incidencias | DECK, CORP | Items pendientes |
### Contabilidad (Feldman)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| feldman_cola | DECK, CORP | Cola de validación |
| feldman_validaciones | CORP | Registro validaciones |
| bloques | DECK, CORP | Bloques consolidados |
| completados | DECK, CORP | Registros finalizados |
| milestones | DECK, CORP | Hitos del sistema |
| merkle_batches | DECK, CORP | Lotes Merkle |
### Producción (Alfred/Jared)
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| flujos_predefinidos | DECK, CORP | Definiciones de flujos |
| flujo_ejecuciones | DECK, CORP | Historial ejecuciones |
### Extensiones Usuario
| Tabla | Servidor | Descripción |
|-------|----------|-------------|
| hsu | DECK, CORP | Tags de usuario |
| pju | DECK, CORP | Proyectos usuario |
| spu | DECK, CORP | Especializaciones usuario |
| vsu | DECK, CORP | Visiones usuario |
| vuu | DECK, CORP | Vistas usuario |
| flu | DECK, CORP | Flags usuario |
| hst_mirror | DECK, CORP | Espejo de tags HST |
## 5.3 Tablas HST
| Tabla | Base de Datos | Descripción |
|-------|---------------|-------------|
| hst | hst_images, lumalia, personal | Tags principales |
| flg | hst_images, lumalia, personal | Flags |
| spe | hst_images | Especificaciones |
| vsn | hst_images | Visiones |
| vue | hst_images | Vistas |
| graph_edges | hst_images | Relaciones entre tags |
| tag_categorias | hst_images | Categorías |
| itm | lumalia, personal | Items |
| loc | lumalia, personal | Ubicaciones |
| ply | lumalia, personal | Players |
---
# §6. REPOSITORIOS GITEA
**URL:** https://git.tzzrarchitect.me
**Organización:** tzzr (29 repos)
## 6.1 Microservicios
| Repo | Descripción | Lenguaje |
|------|-------------|----------|
| clara | Entrada DECK | Python |
| margaret | Entrada CORP | Python |
| alfred | Asistente DECK | Python |
| jared | Flujos CORP | Python |
| mason | Enriquecimiento | Python |
| feldman | Validador + Merkle | Python |
| sentinel | Auditoría | Python |
## 6.2 Interfaces
| Repo | Descripción |
|------|-------------|
| flow-ui | Interfaz de flujos |
| mindlink | Portal unificado |
| packet | App móvil (Dart) |
## 6.3 Sistema
| Repo | Descripción |
|------|-------------|
| captain-claude | Sistema multiagente |
| orchestrator | Orquestación v5 |
| system-docs | Documentación |
| system-plan | Plan de implementación |
| contratos-comunes | Contratos compartidos |
## 6.4 GPU Services (No desplegados)
| Repo | Descripción | Estado |
|------|-------------|--------|
| grace | Módulos IA | Repo existe |
| penny | Asistente voz | Repo existe |
| the-factory | Generación iterativa | Repo existe |
---
# §7. COMANDOS DE GESTIÓN
## 7.1 Servicios systemd
```bash
# MindLink
systemctl status mindlink
systemctl restart mindlink
journalctl -u mindlink -f
# Flow-UI
systemctl status flow-ui
systemctl restart flow-ui
journalctl -u flow-ui -f
```
## 7.2 Contenedores Docker
```bash
# Ver estado
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
# Logs
docker logs -f clara-service
docker logs -f feldman-service
# Reiniciar
docker restart jared-service mason-service feldman-service
# Health check
curl http://localhost:5051/health
curl http://localhost:5052/health
curl http://localhost:5053/health
curl http://localhost:5054/health
```
## 7.3 PostgreSQL
```bash
# Listar bases de datos
sudo -u postgres psql -c "\l"
# Ver tablas
sudo -u postgres psql -d tzzr -c "\dt"
# Query
sudo -u postgres psql -d tzzr -c "SELECT count(*) FROM immutable_log;"
```
## 7.4 HST Específico
```bash
# SSH
ssh -i ~/.ssh/tzzr root@72.62.2.84
# PostgreSQL HST
docker exec -it postgres_hst psql -U directus -d hst_images
# Regenerar vistas materializadas
/opt/hst/scripts/refresh_views.sh
# Docker Compose HST
cd /opt/hst
docker compose up -d
docker compose down
docker compose logs -f
```
---
# §8. OPENAPI SPEC (Resumen)
## 8.1 Servidores
| Servicio | URL DECK | URL CORP |
|----------|----------|----------|
| Clara/Margaret | http://72.62.1.113:5051 | http://92.112.181.188:5051 |
| Alfred/Jared | http://72.62.1.113:5052 | http://92.112.181.188:5052 |
| Mason | http://72.62.1.113:5053 | http://92.112.181.188:5053 |
| Feldman | http://72.62.1.113:5054 | http://92.112.181.188:5054 |
## 8.2 Autenticación
Header: `X-Auth-Key: {h_instancia}`
## 8.3 Endpoints Principales
| Path | Método | Servicio | Descripción |
|------|--------|----------|-------------|
| /health | GET | Todos | Health check |
| /ingest | POST | Clara/Margaret | Registrar entrada |
| /list | GET | Clara/Margaret | Listar entradas |
| /flujos | GET/POST | Alfred/Jared | Gestionar flujos |
| /pendientes | GET | Mason | Items pendientes |
| /item/{id} | GET/PUT | Mason | Gestionar item |
| /milestones | GET | Feldman | Listar milestones |
| /bloques | GET | Feldman | Listar bloques |
| /verify/{hash} | GET | Feldman | Verificar integridad |
| /consolidar | POST | Feldman | Consolidar entradas |
## 8.4 Schemas Principales
### HealthResponse
```json
{
"service": "clara",
"status": "ok",
"rol": "secretaria",
"timestamp": "ISO8601",
"version": "1.0.0"
}
```
### IngestResponse
```json
{
"success": true,
"h_entrada": "sha256...",
"timestamp": "ISO8601"
}
```
### VerifyResponse
```json
{
"valid": true,
"hash": "sha256...",
"found_in": "milestone|block|entry"
}
```
---
*SKYNET v10 - ANEXO 1 REFERENCIA TÉCNICA - 6 Enero 2026*

View File

@@ -0,0 +1,600 @@
# ANEXO 5: Historial de Sesiones Claude Code - 6 Enero 2026
> Documento generado automaticamente con la extraccion completa de todas las sesiones de Claude Code activas el 6 de enero de 2026.
---
## Indice
1. [Resumen Ejecutivo](#resumen-ejecutivo)
2. [Sesion 1: Verificacion Servidores y Windmill](#sesion-1-verificacion-servidores-y-windmill)
3. [Sesion 2: Actualizacion Gitea con GPU Services](#sesion-2-actualizacion-gitea-con-gpu-services)
4. [Sesion 3: Analisis Skynet v10](#sesion-3-analisis-skynet-v10)
5. [Sesion 4: Investigacion Pendientes Sistema](#sesion-4-investigacion-pendientes-sistema)
6. [Sesion 5: Investigacion RunPod y GPU Services](#sesion-5-investigacion-runpod-y-gpu-services)
7. [Sesion 6: Upgrade Sistema](#sesion-6-upgrade-sistema)
8. [Estado Final de Screens](#estado-final-de-screens)
9. [Informacion Clave Recuperada](#informacion-clave-recuperada)
---
## Resumen Ejecutivo
| Sesion | ID | Hora Inicio | Hora Fin | Tarea Principal |
|--------|-------|-------------|----------|-----------------|
| 1 | ae74f372 | 00:29 | 02:35 | Verificacion servidores, eliminacion n8n, instalacion Windmill completa |
| 2 | 017a8ef1 | 08:22 | 08:29 | Actualizacion Gitea con repos GRACE, PENNY, FACTORY |
| 3 | agent-a79e2ce | 05:02 | 05:03 | Analisis completo de Skynet v10 |
| 4 | agent-a3b2558 | 05:02 | - | Investigacion de pendientes y roadmap |
| 5 | agent-aee2ef1 | 07:36 | - | Investigacion RunPod y GPU services |
| 6 | 760fee7d | 17:35 | 17:42 | Upgrade del sistema |
**Total de trabajo documentado:** ~17 horas de sesiones activas
---
## Sesion 1: Verificacion Servidores y Windmill
**ID:** `ae74f372-fd09-4e3d-b1e8-9d646e499714`
**Periodo:** 00:29 - 02:35
**Duracion:** ~2 horas
### Conversacion Completa
#### 1.1 Comprobacion de Servidores
**Usuario:** `comprueba todos los servidores`
**Resultado:**
| Servidor | Estado | Uptime | Load | Disco |
|----------|--------|--------|------|-------|
| ARCHITECT | OK | 11 dias | 1.28 | local |
| DECK | OK | 11 dias | 1.30 | 44% (55G libre) |
| CORP | OK | 11 dias | 0.95 | 39% (30G libre) |
| HST | OK | 11 dias | 0.30 | 21% (38G libre) |
#### 1.2 Eliminacion de n8n
**Usuario:** `verifica que se haya eliminado de todos los servidores n8n`
**Resultado:** n8n eliminado completamente de todos los servidores:
| Servidor | Procesos | Docker | Servicios | Directorios |
|----------|----------|--------|-----------|-------------|
| ARCHITECT | Limpio | Limpio | Limpio | Limpio |
| DECK | Limpio | Limpio | Limpio | Limpio |
| CORP | Limpio | Limpio | Limpio | Limpio |
| HST | Limpio | Limpio | Limpio | Limpio |
#### 1.3 Estado de Windmill
**Usuario:** `esta windmill en deck,corp y architect?`
**Estado inicial:**
| Servidor | Estado | Contenedores | Puerto |
|----------|--------|--------------|--------|
| ARCHITECT | Activo | 8 (completa) | 8100 |
| DECK | Activo | 3 (basica) | 8100 -> 8000 |
| CORP | Activo | 3 (basica) | 8000 (localhost) |
#### 1.4 Diferencia Instalacion Basica vs Completa
**Usuario:** `que diferencia hay entre instalacion basica y completa`
**Instalacion Completa (ARCHITECT):**
| Componente | Funcion |
|------------|---------|
| windmill_server | API y UI principal |
| windmill_worker (x3) | Ejecutan scripts/flows en paralelo |
| windmill_worker_native | Worker optimizado para scripts nativos |
| windmill-lsp | Autocompletado y validacion de codigo |
| caddy | Proxy reverso con TLS automatico |
| postgres:16 | Base de datos |
**Instalacion Basica (DECK/CORP):**
| Componente | Funcion |
|------------|---------|
| windmill-server | API y UI |
| windmill-worker (x1) | Un solo worker |
| postgres:15-alpine | Base de datos (version ligera) |
**Diferencias practicas:**
| Aspecto | Basica | Completa |
|---------|--------|----------|
| Workers paralelos | 1 | 4+ |
| Autocompletado codigo | No | Si (LSP) |
| Proxy/TLS | Manual | Caddy incluido |
| Capacidad concurrente | Baja | Alta |
| Recursos consumidos | ~500MB RAM | ~2GB RAM |
#### 1.5 Explicacion de Workers
**Usuario:** `que son los workers?`
Los **workers** son los procesos que ejecutan el codigo real en Windmill.
**Flujo simplificado:**
```
Usuario crea script -> Server lo encola -> Worker lo ejecuta -> Resultado guardado
```
**Analogia:** El server es el recepcionista que recibe pedidos, los workers son los empleados que hacen el trabajo.
**Por que importa la cantidad:**
| Workers | Comportamiento |
|---------|----------------|
| 1 | Scripts se ejecutan uno a uno (cola) |
| 3 | Hasta 3 scripts simultaneos |
| 4+ | Mayor paralelismo |
#### 1.6 Instalacion Completa
**Usuario:** `completa la instalacion`
**Acciones realizadas:**
1. Actualizo DECK con instalacion completa
2. Resolucion de conflicto con volumen de cache
3. Actualizo CORP (puerto 8200 por conflicto con Caddy del sistema)
4. Preservacion de datos en CORP (Postgres 15)
**Resultado Final:**
| Servidor | Componentes | Puerto | Estado |
|----------|-------------|--------|--------|
| ARCHITECT | 8 (server, 3 workers, native, lsp, caddy, db) | 8100 | OK |
| DECK | 8 (server, 3 workers, native, lsp, caddy, db) | 8100 | OK |
| CORP | 8 (server, 3 workers, native, lsp, caddy, db) | 8200 | OK |
**URLs de Acceso:**
- ARCHITECT: http://69.62.126.110:8100
- DECK: http://72.62.1.113:8100
- CORP: http://92.112.181.188:8200
#### 1.7 Independencia de Instancias
**Usuario:** `no quiero sincronizar nada, son independientes`
Las 3 instancias son completamente independientes:
| Instancia | Base de datos | Scripts | Usuarios |
|-----------|---------------|---------|----------|
| ARCHITECT | Local | Propios | Propios |
| DECK | Local | Propios | Propios |
| CORP | Local | Propios | Propios |
#### 1.8 Skynet v10
**Usuario:** `puedes ver skynet v10 en r2`
**Resultado:** En ese momento NO existia skynet v10 en R2. Las versiones disponibles eran v0 a v9.
---
## Sesion 2: Actualizacion Gitea con GPU Services
**ID:** `017a8ef1-4433-462d-8e29-2f502a4d7e7f`
**Periodo:** 08:22 - 08:29
**Duracion:** ~7 minutos
### Conversacion Completa
**Usuario:** `vale, actualiza gitea con todo lo encontrado`
### Resultado
**Repositorios creados en Gitea:**
| Repo | URL | Archivos |
|------|-----|----------|
| **tzzr/grace** | https://git.tzzrarchitect.me/tzzr/grace | `handler.py` (1122 lineas, 18 modulos), `Dockerfile`, `requirements.txt`, `code/handler.py` |
| **tzzr/penny** | https://git.tzzrarchitect.me/tzzr/penny | `handler.py`, `engine/pipeline.py`, `engine/config.py`, `engine/vad.py`, `engine/realtime.py`, `Dockerfile`, `requirements.txt` |
| **tzzr/factory** | https://git.tzzrarchitect.me/tzzr/factory | `handler.py`, `config.py`, `director.py`, `evaluator.py`, `executor.py`, `Dockerfile`, `requirements.txt` |
**Commits realizados:**
- `grace`: "Initial commit: GRACE 18 GPU modules for RunPod Serverless"
- `penny`: "Initial commit: PENNY Voice Assistant Pipeline"
- `factory`: "Initial commit: THE FACTORY - Iterative Image Generation"
---
## Sesion 3: Analisis Skynet v10
**ID:** `agent-a79e2ce`
**Periodo:** 05:02 - 05:03
**Tipo:** Agente de investigacion
### Tarea
Analizar la documentacion de Skynet v10 en R2 para identificar:
1. Componentes marcados como "futuro" o "planificado"
2. Gaps entre documentacion e implementacion
3. Puntos de integracion que necesitan trabajo
### Resultados Completos
#### 3.1 Componentes Marcados como "Futuro" o "Planificado"
**Componentes Principales:**
| Componente | Estado Documentado | Detalles |
|------------|-------------------|----------|
| **Oracle** | Especificacion completa - Implementacion pendiente | Puerto propuesto: 5055. Modulo de analisis prospectivo. Tiene especificacion detallada con tablas BD (oracle_analisis, oracle_escenario), reglas O-*, integracion con Grace |
| **Sentinel** | Planificado | Sistema de auditoria dual (LIGHT/DEEP). Reglas I-* definidas pero no implementado |
| **The Factory** | Planificado | Sistema de generacion iterativa. Solo mencion, sin especificacion |
| **Notario** | Mencionado | Sellado blockchain. Aparece en diagramas pero sin especificacion tecnica |
**Aplicaciones:**
| App | Estado | Descripcion |
|-----|--------|-------------|
| **Packet** | APK funcional | Proximo paso: Enlazar con Clara |
| **Mind Map** | Especificado | Pendiente prototipo |
| **Mind Flow** | Especificado | Pendiente prototipo |
| **Mind Link** | Planificado | Falta especificar integracion ADI |
**Servicios en Infraestructura:**
| Servicio | Servidor | Estado |
|----------|----------|--------|
| Mason (DECK) | 72.62.1.113:5053 | Pendiente |
| Feldman (DECK) | 72.62.1.113:5054 | Pendiente |
| GRACE (RunPod) | r00x4g3rrwkbyh | Pendiente |
**MCP Server Roadmap:**
| Version | Caracteristicas | Estado |
|---------|-----------------|--------|
| v1.0 | Tools GRACE, Recursos HST, Prompts, S-CONTRACT | Actual |
| v1.1 | Integracion FELDMAN (Merkle), NOTARIO (blockchain), Cache | Planificado |
| v1.2 | Streaming, Context Manager, Prometheus | Futuro |
#### 3.2 Gaps Entre Documentacion e Implementacion
**Gaps Criticos (Bloquean desarrollo):**
| Area | Documentado | Implementado | Gap |
|------|-------------|--------------|-----|
| **Subgrupos FLG** | Mencionados (paises, jurisdicciones, normativas) | 65 banderas/paises | Falta definir codigos para jurisdicciones (UE, LATAM), normativas (RGPD, SOX), estandares (ISO) |
| **Pipeline de Ingesta** | 80% | Parcial | Mason y Feldman en DECK pendientes |
| **Procesamiento IA** | 30% | GRACE parcial | GRACE en RunPod pendiente, The Factory sin spec |
**Gaps de Media Prioridad:**
| Area | Documentado | Implementado | Gap |
|------|-------------|--------------|-----|
| **jsonb_data por tabla** | Campos esperados definidos | Parcial | PLY(ppl/tem/ain), LOC, MTH sin implementar |
| **Sincronizacion tablas redundantes** | Pendiente definir | No implementado | ply_hst, itm_flg, etc. vs campos JSONB |
| **Endpoints bibliotecas** | /biblioteca/import, /export, /sync/redundant | No implementados | APIs pendientes |
| **Observabilidad** | 20% progreso | Basico | Sin metricas Prometheus ni alertas avanzadas |
**Estado General del Sistema:**
| Area | Progreso Documentado |
|------|---------------------|
| Pipeline de Ingesta | 80% |
| Procesamiento IA | 30% |
| Apps Usuario | 10% |
| Observabilidad | 20% |
#### 3.3 Puntos de Integracion que Necesitan Trabajo
**Integraciones Clara/Margaret -> Backend:**
| Integracion | Estado | Trabajo Pendiente |
|-------------|--------|-------------------|
| Clara -> Mason | DECK pendiente | Implementar servicio Mason en puerto 5053 |
| Clara -> Feldman | DECK pendiente | Implementar servicio Feldman en puerto 5054 |
| Margaret -> Mason -> Feldman | CORP OK | Funcional |
**Integraciones IA:**
| Integracion | Estado | Trabajo Pendiente |
|-------------|--------|-------------------|
| GRACE (RunPod) | Pendiente | Endpoint r00x4g3rrwkbyh no activo |
| PENNY (RunPod) | OK | Funcional |
| Grace -> Oracle | Especificado | Oracle no implementado |
| Sentinel -> Grace (DEEP) | Planificado | Ambos pendientes |
**Integraciones MCP Server:**
| Integracion | Estado | Trabajo Pendiente |
|-------------|--------|-------------------|
| MCP -> GRACE | v1.0 ready | Depende de activar GRACE |
| MCP -> HST Directus | v1.0 ready | Funcional |
| MCP -> FELDMAN | v1.1 | Validacion Merkle |
| MCP -> NOTARIO | v1.1 | Sellado blockchain |
| MCP -> Context Manager | v1.2 | Futuro |
**Integraciones Aplicaciones:**
| Integracion | Estado | Trabajo Pendiente |
|-------------|--------|-------------------|
| Packet -> Clara | Pendiente | Enlazar APK con servicio |
| Mind Map -> Feldman | Especificado | Falta prototipo |
| Mind Flow -> Alfred/Jared | Especificado | Falta prototipo |
| Mind Link -> ADI | Planificado | Especificar integracion |
#### 3.4 Resumen Ejecutivo
**Lo que funciona (CORP):**
- Margaret, Jared, Mason, Feldman - OK
- Directus 11, Odoo 17 - OK
- HST API con 963 tags - OK
- PENNY (voz) - OK
**Lo que esta parcial (DECK):**
- Clara, Alfred - OK
- Mason, Feldman - Pendientes
- Context Manager - OK
**Lo que falta implementar:**
1. **GRACE** - Endpoint RunPod no activo
2. **Oracle** - Especificado completamente, sin implementar
3. **Sentinel** - Solo concepto
4. **The Factory** - Solo mencion
5. **Notario** - Sin especificacion tecnica
6. **Apps (Mind Map, Mind Flow, Mind Link)** - Solo especificaciones
---
## Sesion 4: Investigacion Pendientes Sistema
**ID:** `agent-a3b2558`
**Periodo:** 05:02
**Tipo:** Agente de investigacion
### Tarea
Buscar en `/home/architect/workspace/system-docs/`:
1. Archivos pending.md, roadmap
2. Changelog.md
3. SPEC files con secciones "planificado" o "futuro"
### Resultados
#### 4.1 Pending Items (From `/99_ANEXOS/pendientes.md`)
**Por Definir (Alta/Media Prioridad):**
| Elemento | Prioridad | Dependencias | Status |
|----------|-----------|--------------|--------|
| Estructura tabla ITM (Items) | Alta | - | Por Definir |
| Estructura tabla PLY (Players) | Alta | - | Por Definir |
| Estructura tabla LOC (Locations) | Media | - | Por Definir |
| Estructura tabla FLG (Flags) | Media | HST | Por Definir |
| Mecanismo "encaja/no encaja" | Alta | Produccion | Por Definir |
| Formato flujos en Produccion | Alta | - | Por Definir |
| Lista modulos Grace completa | Media | - | Por Definir |
| Contratos E/S de Grace | Media | S-CONTRACT | Por Definir |
| Scheduler periodo flotante Mason | Alta | - | Por Definir |
| Merkle tree para verificacion | Media | Feldman | Por Definir |
| Smart contract blockchain | Baja | Merkle tree | Por Definir |
**Por Implementar:**
| Componente | Estado | Bloqueador |
|------------|--------|------------|
| Sentinel LIGHT | Planificado | - |
| Sentinel DEEP | Planificado | LIGHT |
| ITM (plano ideal) | Schema definido | - |
| PLY (identidad) | Schema definido | - |
| LOC (ubicaciones) | Schema definido | - |
| Mind Link | Planificado | API REST |
| Packet offline | En desarrollo | - |
**Por Documentar:**
| Documento | Ubicacion | Estado |
|-----------|-----------|--------|
| API Feldman | 05_INTEGRACIONES | Pendiente |
| API Mason | 05_INTEGRACIONES | Pendiente |
| API Clara/Margaret | 05_INTEGRACIONES | Pendiente |
| Guia despliegue DECK | 04_INFRAESTRUCTURA | Parcial |
| Guia despliegue CORP | 04_INFRAESTRUCTURA | Parcial |
**Decisiones Pendientes:**
| ID | Decision | Opciones | Estado |
|----|----------|----------|--------|
| D-008 | Motor de busqueda contexto | PostgreSQL FTS vs Elasticsearch | Abierta |
| D-009 | Formato flujos Produccion | JSON vs YAML vs DSL | Abierta |
| D-010 | Grafo de contexto | Kuzu vs Neo4j embedded | Kuzu elegido |
#### 4.2 Deuda Tecnica
| Item | Impacto | Esfuerzo | Status |
|------|---------|----------|--------|
| Migrar NocoDB -> Directus | - | - | Completado |
| Unificar schemas entre servidores | Medio | Alto | Pendiente |
| Tests automatizados | Alto | Alto | Pendiente |
| CI/CD pipeline | Medio | Medio | Pendiente |
#### 4.3 Plan de Mejoras Priorizado
**Fase 1: Seguridad Inmediata**
| # | Mejora | Esfuerzo | Impacto |
|---|--------|----------|---------|
| 1 | Restringir puertos 5051-5054 en UFW | 1h | Critico |
| 2 | Implementar rate limiting | 2h | Alto |
| 3 | Agregar headers de seguridad | 1h | Medio |
**Fase 2: Estabilidad**
| # | Mejora | Esfuerzo | Impacto |
|---|--------|----------|---------|
| 4 | Implementar connection pool DB | 4h | Alto |
| 5 | Limpiar Docker images | 1h | Medio |
| 6 | Agregar healthchecks faltantes | 2h | Medio |
| 7 | Configurar Let's Encrypt | 2h | Medio |
---
## Sesion 5: Investigacion RunPod y GPU Services
**ID:** `agent-aee2ef1`
**Periodo:** 07:36
**Tipo:** Agente de investigacion
### Tarea
Buscar en Gitea informacion sobre RunPod, Penny, Factory y GRACE:
1. Encontrar URL de Gitea
2. Buscar repositorios relacionados
3. Revisar archivos de configuracion
4. Encontrar endpoint IDs de RunPod
### Resultados
#### 5.1 URL Gitea
**https://git.tzzrarchitect.me**
#### 5.2 Ubicacion del Codigo
Los repositorios especificos de GPU-services (runpod, penny, factory, grace) **NO estaban en Gitea** inicialmente. El codigo fuente estaba en:
- **Local (ARCHITECT):** `/home/architect/workspace/docker-grace/`, `/home/architect/workspace/docker-penny/`, `/home/architect/workspace/docker-factory/`
- **R2 Storage:** `s3://architect/gpu-services/` (contiene codigo, configs e imagenes Docker tar.gz)
#### 5.3 Endpoint IDs de RunPod
| Servicio | Endpoint ID | Estado | Funcion |
|----------|-------------|--------|---------|
| **GRACE** | `r00x4g3rrwkbyh` | Pendiente Docker image | Procesamiento IA (18 modulos) |
| **PENNY** | `0mxhaokgsmgee3` | OK | Asistente de voz |
| **FACTORY** | No configurado | Pendiente | Generacion iterativa |
**URLs Completas de Endpoints:**
```
GRACE: https://api.runpod.ai/v2/r00x4g3rrwkbyh/runsync
PENNY: https://api.runpod.ai/v2/0mxhaokgsmgee3/runsync
```
#### 5.4 Servicios Desplegados
**GRACE** - Capa de procesamiento cognitivo con 18 modulos:
- **Familia A (Vision):** IMG_PREPROCESS, PDF_SCANNER, OCR_CORE
- **Familia B (Voz):** ASR_ENGINE (Faster Whisper Large V3), TTS_ENGINE
- **Familia C (Identidad):** FACE_VECTOR, ID_CONSOLIDATION, AVATAR_GEN
- **Familia D (Semantica):** EMBEDDINGS, SUMMARIZER, TASK_EXTRACTOR, CLASSIFIER, SIMILARITY
- **Familia E (Utilidades):** FIELD_EXTRACTOR, HASHER, INPUT_NORMALIZER, OUTPUT_ADAPTER, LANG_DETECT
- **GPU:** NVIDIA L4 (24GB)
- **Base:** RunPod pytorch:2.1.0-py3.10-cuda11.8.0
**PENNY** - Asistente de voz conversacional:
- Flujo: Audio -> GRACE/ASR -> Claude API -> GRACE/TTS -> Audio
- Depende de GRACE para transcripcion (ASR) y sintesis (TTS)
- Se conecta a CLARA en DECK (72.62.1.113:5051) para contexto
**FACTORY** - Generacion iterativa:
- Pendiente de configuracion
- Usa modelos: Claude Sonnet, Claude Haiku, GPT-4o, Flux Pro/Schnell
- Para generacion de texto, codigo, imagenes, documentos
#### 5.5 Archivos de Configuracion
| Archivo | Ubicacion |
|---------|-----------|
| Codigo GRACE | `/home/architect/workspace/docker-grace/handler.py` |
| Codigo PENNY | `/home/architect/workspace/docker-penny/handler.py` |
| Codigo FACTORY | `/home/architect/workspace/docker-factory/handler.py` |
| Config GRACE R2 | `s3://architect/gpu-services/grace/config/grace.json` |
| Imagenes Docker | `s3://architect/gpu-services/*/...image-20251228.tar.gz` |
| Documentacion | `/home/architect/workspace/system-docs/05_INTEGRACIONES/gpu-services.md` |
| Status infra | `/home/architect/workspace/system-docs/04_INFRAESTRUCTURA/status.md` |
#### 5.6 Variables de Entorno Requeridas
```bash
RUNPOD_API_KEY=rpa_XXXXXXXXXX
ANTHROPIC_API_KEY=sk-ant-XXXXXXXXXX
GRACE_ENDPOINT=https://api.runpod.ai/v2/r00x4g3rrwkbyh
H_INSTANCIA=<hash de autenticacion>
```
---
## Sesion 6: Upgrade Sistema
**ID:** `760fee7d-4983-4d56-a0ed-61b704449d21`
**Periodo:** 17:35 - 17:42
**Duracion:** ~7 minutos
### Conversacion
**Usuario:** `ayer hice un upgrade del sistema, comprueba como esta ahora el sistema`
**Usuario:** `que actualizaciones hay pendientes?`
**Usuario:** `si, aplicalas a todos los servidores`
*Nota: Esta sesion continuo con la tarea de revision de sesiones anteriores documentada en este anexo.*
---
## Estado Final de Screens
| Screen | PID | Iniciada | Estado | Contenido |
|--------|-----|----------|--------|-----------|
| 3335302.captain | 3335302 | 02:38 | Attached | Trabajo de Gitea completado, esperando RUNPOD_API_KEY |
| 3334168.captain | 3334168 | 02:36 | Detached | Pantalla bienvenida, usuario escribio "busca" sin completar |
| 3839259.captain | 3839259 | 17:34 | Attached | Sesion actual (esta documentacion) |
---
## Informacion Clave Recuperada
### Credenciales RunPod
```
RUNPOD_API_KEY=rpa_QDCHZ0OB1JEGHRNZWGUEM46WSC1EBQWZ8SZ0BO081x1v1q
```
### URLs de Servicios Windmill
| Servidor | URL |
|----------|-----|
| ARCHITECT | http://69.62.126.110:8100 |
| DECK | http://72.62.1.113:8100 |
| CORP | http://92.112.181.188:8200 |
### URLs Gitea
- Base: https://git.tzzrarchitect.me
- GRACE: https://git.tzzrarchitect.me/tzzr/grace
- PENNY: https://git.tzzrarchitect.me/tzzr/penny
- FACTORY: https://git.tzzrarchitect.me/tzzr/factory
### Endpoints RunPod
| Servicio | Endpoint |
|----------|----------|
| GRACE | https://api.runpod.ai/v2/r00x4g3rrwkbyh/runsync |
| PENNY | https://api.runpod.ai/v2/0mxhaokgsmgee3/runsync |
---
## Trabajo Pendiente Identificado
Basado en todas las sesiones analizadas, el trabajo pendiente prioritario es:
1. **GRACE RunPod** - Activar endpoint con Docker image
2. **Mason/Feldman en DECK** - Implementar servicios en puertos 5053/5054
3. **Oracle** - Implementar modulo de analisis prospectivo
4. **Sentinel** - Implementar sistema de auditoria LIGHT/DEEP
5. **The Factory** - Crear especificacion tecnica e implementar
6. **Packet -> Clara** - Enlazar aplicacion APK con servicio
7. **Tests automatizados** - Crear suite de pruebas
8. **CI/CD pipeline** - Implementar integracion continua
---
*Documento generado automaticamente el 6 de enero de 2026*
*Fuente: Sesiones Claude Code en ~/.claude/projects/-home-architect-captain-claude/*

50
99_ANEXOS/README.md Normal file
View File

@@ -0,0 +1,50 @@
# 99 - Anexos
> Inventarios, changelog y elementos pendientes
## Contenido
| Documento | Descripción |
|-----------|-------------|
| [inventario-repos.md](inventario-repos.md) | Lista completa de repositorios en Gitea |
| [inventario-credenciales.md](inventario-credenciales.md) | Credenciales organizadas por categoría |
| [pendientes.md](pendientes.md) | Elementos y decisiones por definir |
| [changelog.md](changelog.md) | Historial de cambios del sistema |
## Repositorios Principales
| Repositorio | Descripción |
|-------------|-------------|
| `tzzr/system-docs` | Esta documentación |
| `tzzr/orchestrator` | Orquestador multi-agente |
| `tzzr/sentinel` | Sistema de auditoría |
| `tzzr/feldman` | Consolidación contable |
| `tzzr/packet` | App móvil |
## Categorías de Credenciales
- **APIs IA**: OpenAI, Anthropic, RunPod
- **Bases de datos**: PostgreSQL, Redis
- **Storage**: Cloudflare R2
- **Servicios**: Gitea, Infisical
- **SSH**: Acceso a servidores
## Convenciones
### Versionado de Documentación
- **Mayor**: Cambios arquitecturales significativos
- **Menor**: Nuevos componentes o secciones
- **Parche**: Correcciones y actualizaciones menores
### Formato de Changelog
```markdown
## [X.Y.Z] - YYYY-MM-DD
### Added
### Changed
### Fixed
### Removed
```
---
[← Volver al índice](../README.md)

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