Auditoria completa y plan de implementacion TZZR

- ARCHITECTURE.md: Estado real de 23 repos
- IMPLEMENTATION_PLAN.md: 7 fases de implementacion
- PHASES/: Scripts detallados para cada fase

Resultado de auditoria:
- 5 repos implementados
- 4 repos parciales
- 14 repos solo documentacion
This commit is contained in:
ARCHITECT
2025-12-24 08:59:14 +00:00
parent 1638a8cf85
commit 73ae91d337
7 changed files with 2089 additions and 2 deletions

260
ARCHITECTURE.md Normal file
View File

@@ -0,0 +1,260 @@
# TZZR - Estado Real del Ecosistema
**Fecha de auditoría:** 2025-12-24
**Auditor:** Orchestrator (Architect Agent)
---
## 1. INVENTARIO DE REPOS (23 repos)
### Estado por Categoría
| Estado | Cantidad | Repos |
|--------|----------|-------|
| **IMPLEMENTADO** | 5 | clara, hst, packet, orchestrator, context |
| **PARCIAL** | 4 | grace, penny, the-factory, deck |
| **SOLO DOCS** | 14 | alfred, architect, contratos-comunes, corp, credentials, feldman, jared, locker, margaret, mason, mind-link, sentinel, system, vision-builder |
---
## 2. ESTADO DETALLADO POR REPO
### IMPLEMENTADOS (código funcional)
| Repo | Lenguaje | Descripción Real | Desplegado |
|------|----------|------------------|------------|
| **clara** | Python/Flask | API de ingesta para DECK. Recibe contenedores de PACKET, sube a R2, registra en PostgreSQL | NO |
| **hst** | Python/Flask | Image server para tags semánticos. Sirve imágenes por subdominios .tzrtech.org | SÍ (72.62.2.84) |
| **packet** | Flutter/Dart | App móvil completa. Captura multimedia, etiqueta con HST, envía a backends | NO (código listo) |
| **orchestrator** | Python | Framework multi-agente LLM. Soporta Claude, GPT-4, Gemini | Local only |
| **context** | SQL/Docs | Sistema de bloques de contexto para agentes. 35 bloques en PostgreSQL | SÍ (architect DB) |
### PARCIALMENTE IMPLEMENTADOS
| Repo | Contenido Real | Falta |
|------|----------------|-------|
| **grace** | Handler RunPod con 6 módulos (ASR, OCR, TTS, Face, Embeddings, Avatar) | Desplegar en RunPod |
| **penny** | Estructura RunPod para generación de texto (config, engine, server) | Completar engine, desplegar |
| **the-factory** | Handler RunPod para generación iterativa | Implementar Director/Evaluator |
| **deck** | Configuración de servidor (docker, scripts, nginx) | Integrar clara, alfred |
### SOLO DOCUMENTACIÓN (conceptuales)
| Repo | Propósito Documentado | Estado Real |
|------|----------------------|-------------|
| **alfred** | Flujos predefinidos DECK | Solo README con diagrama |
| **jared** | Flujos predefinidos CORP | Solo README con diagrama |
| **margaret** | Log de entrada CORP | Solo README (clon de clara) |
| **mason** | Espacio de enriquecimiento | Solo README |
| **feldman** | Consolidación en bloques | Solo README |
| **sentinel** | Auditoría del sistema | Solo README |
| **vision-builder** | Diseño de visiones | Solo README |
| **locker** | Gateway almacenamiento | Solo README + credenciales R2 |
| **mind-link** | Interfaz de conexión | Carpeta src/ vacía |
| **corp** | Servidor empresarial | Solo STATUS.md |
| **architect** | Coordinación | Docs + carpetas de setup obsoletas |
| **contratos-comunes** | Especificaciones | Docs extensivos, sin código |
| **credentials** | Gestión de credenciales | Docs + inventarios |
| **system** | Documentación central | Solo markdown |
---
## 3. MAPA DE DEPENDENCIAS
### Flujo de Datos Principal
```
┌─────────────────┐
│ PACKET │
│ (App móvil) │
└────────┬────────┘
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ CLARA │ │ MARGARET │ │ALFRED/JARED │
│ (DECK log) │ │ (CORP log) │ │ (flujos) │
│ IMPLEMENTADO│ │ SOLO DOC │ │ SOLO DOC │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────────────────┼────────────────────┘
┌─────────────┐
│ MASON │
│ SOLO DOC │
└──────┬──────┘
┌─────────────┐
│ FELDMAN │
│ SOLO DOC │
└─────────────┘
```
### Servicios GPU
```
┌─────────────┐
│ GRACE │
│ 6 módulos │ ←── RunPod template listo
│ PARCIAL │
└──────┬──────┘
┌───────────┼───────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌──────────┐
│ PENNY │ │FACTORY │ │ (otros) │
│PARCIAL │ │PARCIAL │ │ │
└────────┘ └────────┘ └──────────┘
```
### Matriz de Dependencias
| Componente | Depende de | Es dependido por |
|------------|------------|------------------|
| PACKET | HST (tags), CLARA/MARGARET (backend) | Ninguno |
| CLARA | PostgreSQL, R2, HST (tags) | MASON, FELDMAN |
| MARGARET | PostgreSQL, R2, HST (tags) | MASON, FELDMAN |
| MASON | CLARA/MARGARET | FELDMAN |
| FELDMAN | MASON | SENTINEL |
| HST | PostgreSQL | PACKET, CLARA, MARGARET |
| GRACE | RunPod GPU | PENNY, FACTORY, cualquier servicio |
| LOCKER | Cloudflare R2 | CLARA, MARGARET, FACTORY |
---
## 4. INFRAESTRUCTURA ACTUAL
### Servidores
| Servidor | IP | Servicios Activos | Servicios Documentados pero NO activos |
|----------|-----|-------------------|---------------------------------------|
| ARCHITECT | 69.62.126.110 | Gitea, Directus, PostgreSQL, Infisical | Windmill (puerto 8100) |
| DECK | 72.62.1.113 | Directus, PostgreSQL, Mailcow, FileBrowser | CLARA, ALFRED, Vision Builder |
| CORP | 92.112.181.188 | Directus, Nextcloud, Odoo, Vaultwarden | MARGARET, JARED |
| HST | 72.62.2.84 | Nginx (imágenes), Directus, PostgreSQL | - |
### Bases de Datos
| Servidor | DB | Tablas Principales |
|----------|-----|-------------------|
| ARCHITECT | architect | context_blocks, agent_context_index, creds_*, s_contract_* |
| ARCHITECT | gitea | (gitea interno) |
| ARCHITECT | infisical | (infisical interno) |
| DECK | tzzr | (sin tablas de flujo reales) |
| HST | hst_images | 5 tablas de tags (973 registros) |
### Cloudflare R2
| Bucket | Estado | Contenido |
|--------|--------|-----------|
| architect | Vacío | - |
| deck | 1 objeto | test.txt (5 bytes) |
| corp | Vacío | - |
| hst | Vacío | - |
| locker | Vacío | - |
---
## 5. INCONSISTENCIAS DETECTADAS
### Críticas
| ID | Descripción | Impacto |
|----|-------------|---------|
| I01 | **CLARA documentada pero no desplegada en DECK** | Flujo de ingesta no funciona |
| I02 | **MARGARET/JARED/MASON/FELDMAN solo documentados** | Pipeline completo no existe |
| I03 | **PostgreSQL sin tablas de flujo** | clara_log, feldman_bloques no existen |
| I04 | **GRACE no desplegado en RunPod** | Procesamiento IA no disponible |
| I05 | **R2 buckets vacíos** | Almacenamiento configurado pero no usado |
### Moderadas
| ID | Descripción | Impacto |
|----|-------------|---------|
| I06 | **Windmill documentado pero no activo** | Alternativa a n8n no disponible |
| I07 | **HSU API en CORP documentada pero no verificada** | Biblioteca de usuario sin confirmar |
| I08 | **orchestrator solo funciona localmente** | No hay orquestación remota |
| I09 | **PACKET código completo pero no compilado/publicado** | App móvil no disponible para usuarios |
| I10 | **architect repo tiene carpetas obsoletas** | app-v2, orchestrator-v3 confusos |
### Menores
| ID | Descripción | Impacto |
|----|-------------|---------|
| I11 | **mind-link tiene src/ vacío** | Repo inútil actualmente |
| I12 | **NocoDB referenciado pero migrado a Directus** | Documentación desactualizada |
| I13 | **contratos-comunes muy extenso sin tests** | Especificaciones sin validación |
| I14 | **Credenciales dispersas entre repos** | Difícil gestión centralizada |
---
## 6. SERVICIOS REALES vs DOCUMENTADOS
### DECK (72.62.1.113)
| Servicio | Documentado | Real |
|----------|-------------|------|
| PostgreSQL | SÍ | SÍ |
| Directus | SÍ | SÍ |
| Mailcow | SÍ | SÍ |
| FileBrowser | SÍ | SÍ |
| CLARA | SÍ | NO |
| ALFRED | SÍ | NO |
| Vision Builder | SÍ | NO |
| Windmill | SÍ | NO |
### CORP (92.112.181.188)
| Servicio | Documentado | Real |
|----------|-------------|------|
| Directus | SÍ | SÍ |
| Nextcloud | SÍ | SÍ |
| Odoo | SÍ | SÍ |
| MARGARET | SÍ | NO |
| JARED | SÍ | NO |
| HSU API | SÍ | ? (no verificado) |
### HST (72.62.2.84)
| Servicio | Documentado | Real |
|----------|-------------|------|
| Nginx (imágenes) | SÍ | SÍ |
| Directus | SÍ | SÍ |
| PostgreSQL | SÍ | SÍ |
| API /biblioteca | SÍ | SÍ |
---
## 7. RESUMEN EJECUTIVO
### Lo que FUNCIONA
1. **HST** - Sistema de tags semánticos operativo
2. **Gitea** - Control de versiones funcional
3. **Directus** - CMS en todos los servidores
4. **PostgreSQL** - Bases de datos operativas
5. **R2** - Buckets configurados (vacíos)
6. **context** - Sistema de contexto para agentes
### Lo que está LISTO pero NO DESPLEGADO
1. **CLARA** - Código Python completo
2. **PACKET** - App Flutter completa
3. **GRACE** - Handler RunPod con 6 módulos
### Lo que es SOLO DOCUMENTACIÓN
1. **Todo el pipeline de flujo** (ALFRED → MASON → FELDMAN)
2. **MARGARET** (versión CORP de CLARA)
3. **JARED** (versión CORP de ALFRED)
4. **SENTINEL** (auditoría)
5. **VISION BUILDER** (diseño de visiones)
6. **MIND LINK** (conexión de ideas)
### Porcentaje de Implementación Real
- **Infraestructura base**: 80% (servidores, DBs, R2)
- **Servicios de soporte**: 60% (Directus, Gitea, etc.)
- **Pipeline de datos**: 10% (solo HST funciona end-to-end)
- **Procesamiento IA**: 0% (GRACE no desplegado)
- **Apps de usuario**: 0% (PACKET no publicada)
---
*Documento generado automáticamente por auditoría del ecosistema TZZR*

345
IMPLEMENTATION_PLAN.md Normal file
View File

@@ -0,0 +1,345 @@
# TZZR - Plan de Implementación
**Fecha:** 2025-12-24
**Objetivo:** Llevar el ecosistema de 10% a 80% de funcionalidad
---
## RESUMEN DE FASES
| Fase | Objetivo | Complejidad | Repos Afectados |
|------|----------|-------------|-----------------|
| 0 | Limpieza y consolidación | Simple | architect, system |
| 1 | Pipeline mínimo viable | Media | clara, deck, contratos-comunes |
| 2 | Procesamiento IA | Compleja | grace, penny, the-factory |
| 3 | Flujo empresarial | Media | margaret, corp |
| 4 | Pipeline completo | Compleja | mason, feldman, alfred, jared |
| 5 | Apps de usuario | Media | packet, vision-builder |
| 6 | Observabilidad | Simple | sentinel |
---
## FASE 0: LIMPIEZA Y CONSOLIDACIÓN
**Objetivo:** Eliminar confusión, actualizar documentación obsoleta
### Acciones
| # | Acción | Repo | Comando/Detalle |
|---|--------|------|-----------------|
| 0.1 | Eliminar carpetas obsoletas de architect | architect | Borrar app-v2, orchestrator-setup, orchestrator-v3 |
| 0.2 | Actualizar referencias a NocoDB | todos | Buscar y reemplazar por Directus |
| 0.3 | Consolidar documentación de servicios | system | Actualizar 04-servicios.md con estado real |
| 0.4 | Limpiar mind-link | mind-link | Decidir: eliminar repo o implementar |
| 0.5 | Sincronizar READMEs con realidad | todos | Marcar como "PLANIFICADO" lo no implementado |
### Script de Ejecución
```bash
# 0.1 - Limpiar architect
cd /tmp && git clone git@localhost:2222/tzzr/architect.git
cd architect
rm -rf app-v2 orchestrator-setup orchestrator-v3
git add -A && git commit -m "Limpieza: eliminar carpetas obsoletas"
GIT_SSH_COMMAND="ssh -i /home/orchestrator/.ssh/tzzr -p 2222" git push origin main
# 0.2 - Actualizar referencias NocoDB (ejemplo)
grep -r "NocoDB" . --include="*.md" | while read line; do
file=$(echo $line | cut -d: -f1)
sed -i 's/NocoDB/Directus/g' "$file"
done
```
### Verificación
- [ ] No existen carpetas app-v2, orchestrator-* en architect
- [ ] No hay referencias a NocoDB en documentación activa
- [ ] Todos los READMEs indican estado real
---
## FASE 1: PIPELINE MÍNIMO VIABLE
**Objetivo:** PACKET → CLARA → PostgreSQL → R2 funcionando
### Prerequisitos
- PostgreSQL en DECK accesible
- R2 bucket 'deck' configurado
- HST funcionando (ya OK)
### Acciones
| # | Acción | Servidor | Detalle |
|---|--------|----------|---------|
| 1.1 | Crear tablas de CLARA en DECK | DECK | Ejecutar SQL de init.sql |
| 1.2 | Desplegar CLARA como Docker | DECK | docker-compose up |
| 1.3 | Configurar Caddy para /ingest | DECK | Añadir ruta en Caddyfile |
| 1.4 | Probar ingesta desde curl | DECK | POST /ingest con contenedor test |
| 1.5 | Verificar archivo en R2 | R2 | Listar bucket deck |
### SQL para DECK
```sql
-- Ejecutar en DECK PostgreSQL (72.62.1.113)
CREATE TABLE IF NOT EXISTS clara_log (
id BIGSERIAL PRIMARY KEY,
h_instancia VARCHAR(64) NOT NULL,
h_entrada VARCHAR(64) NOT NULL UNIQUE,
contenedor JSONB NOT NULL,
r2_paths JSONB DEFAULT '{}',
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_clara_h_instancia ON clara_log(h_instancia);
CREATE INDEX idx_clara_created ON clara_log(created_at DESC);
```
### Docker Compose (clara)
```yaml
# /opt/clara/docker-compose.yml
version: '3.8'
services:
clara:
build: .
ports:
- "5051:5051"
environment:
- H_INSTANCIA=${H_INSTANCIA}
- DB_HOST=host.docker.internal
- DB_PORT=5432
- DB_NAME=tzzr
- DB_USER=deck
- DB_PASSWORD=${DB_PASSWORD}
- R2_ENDPOINT=https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
- R2_ACCESS_KEY=${R2_ACCESS_KEY}
- R2_SECRET_KEY=${R2_SECRET_KEY}
- R2_BUCKET=deck
restart: unless-stopped
```
### Verificación
- [ ] `curl -X POST http://72.62.1.113:5051/ingest` responde 401 (sin auth)
- [ ] Con auth válida, responde 200 o 409
- [ ] Registro aparece en clara_log
- [ ] Archivo aparece en R2 bucket deck
---
## FASE 2: PROCESAMIENTO IA
**Objetivo:** GRACE desplegado en RunPod, llamable desde DECK
### Acciones
| # | Acción | Plataforma | Detalle |
|---|--------|------------|---------|
| 2.1 | Crear template en RunPod | RunPod | Subir Dockerfile de grace/runpod |
| 2.2 | Configurar endpoint serverless | RunPod | GPU: RTX 4090, RAM: 24GB |
| 2.3 | Probar módulo ASR_ENGINE | RunPod | Enviar audio test |
| 2.4 | Probar módulo OCR_CORE | RunPod | Enviar imagen test |
| 2.5 | Documentar endpoint ID | credentials | Actualizar runpod.md |
### Dockerfile GRACE
```dockerfile
FROM runpod/pytorch:2.1.0-py3.10-cuda11.8.0-devel
WORKDIR /app
# Dependencias del sistema
RUN apt-get update && apt-get install -y ffmpeg libsm6 libxext6
# Dependencias Python
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Precargar modelos (opcional, reduce cold start)
RUN python -c "from faster_whisper import WhisperModel; WhisperModel('large-v3', device='cpu')"
COPY handler.py .
CMD ["python", "-u", "handler.py"]
```
### Test ASR
```bash
# Desde DECK
curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
-H "Authorization: Bearer ${RUNPOD_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"input": {
"contract_version": "2.1",
"routing": {"module": "ASR_ENGINE"},
"payload": {
"type": "audio",
"encoding": "base64",
"content": "'$(base64 -w0 test.wav)'"
},
"context": {"lang": "es"}
}
}'
```
### Verificación
- [ ] Template visible en RunPod dashboard
- [ ] Endpoint responde a health check
- [ ] ASR transcribe audio español
- [ ] OCR extrae texto de imagen
- [ ] Tiempo de respuesta < 30s (warm) / < 120s (cold)
---
## FASE 3: FLUJO EMPRESARIAL
**Objetivo:** MARGARET funcionando en CORP (clon de CLARA)
### Acciones
| # | Acción | Servidor | Detalle |
|---|--------|----------|---------|
| 3.1 | Crear repo margaret con código | Gitea | Fork de clara con ajustes |
| 3.2 | Crear tablas en CORP PostgreSQL | CORP | margaret_log |
| 3.3 | Desplegar MARGARET | CORP | Docker |
| 3.4 | Configurar Caddy | CORP | Ruta /ingest |
| 3.5 | Probar ingesta | CORP | curl test |
### Diferencias CLARA vs MARGARET
| Aspecto | CLARA | MARGARET |
|---------|-------|----------|
| Servidor | DECK | CORP |
| Bucket R2 | deck | corp |
| h_instancia | SHA256(seed_deck) | SHA256(seed_corp) |
| Tabla | clara_log | margaret_log |
| Extras | - | + campos empresa |
### Verificación
- [ ] MARGARET responde en CORP:5052
- [ ] Registros en margaret_log
- [ ] Archivos en R2/corp
---
## FASE 4: PIPELINE COMPLETO
**Objetivo:** MASON y FELDMAN implementados
### MASON (Enriquecimiento)
| # | Acción | Detalle |
|---|--------|---------|
| 4.1 | Crear schema SQL | mason_entries con campos de enriquecimiento |
| 4.2 | Implementar API Flask | GET/PUT /enrich/{h_entrada} |
| 4.3 | Integrar con CLARA | Trigger o worker que mueve a MASON |
| 4.4 | Implementar timeout 24h | Job que auto-envía a FELDMAN |
### FELDMAN (Consolidación)
| # | Acción | Detalle |
|---|--------|---------|
| 4.5 | Crear schema SQL | feldman_cola, feldman_bloques |
| 4.6 | Implementar API Flask | POST /consolidate, GET /bloque/{id} |
| 4.7 | Implementar lógica de bloques | Cada 24h o manual |
| 4.8 | Generar Merkle tree | Para verificación |
### ALFRED (Flujos Predefinidos)
| # | Acción | Detalle |
|---|--------|---------|
| 4.9 | Crear schema SQL | flujos_predefinidos, flujo_ejecuciones |
| 4.10 | Implementar API Flask | CRUD flujos, POST /execute |
| 4.11 | Integrar decisión | OK → FELDMAN, Incidencia → MASON |
### Verificación
- [ ] Flujo completo: CLARA → MASON → FELDMAN funciona
- [ ] Bloques se generan cada 24h
- [ ] ALFRED ejecuta flujos predefinidos
---
## FASE 5: APPS DE USUARIO
**Objetivo:** PACKET publicada, VISION BUILDER operativo
### PACKET
| # | Acción | Detalle |
|---|--------|---------|
| 5.1 | Configurar firma Android | Keystore + secrets |
| 5.2 | Build APK release | flutter build apk --release |
| 5.3 | Publicar en Gitea releases | O bucket R2 público |
| 5.4 | Documentar instalación | Wiki o README |
### VISION BUILDER
| # | Acción | Detalle |
|---|--------|---------|
| 5.5 | Implementar schema SQL | visiones, milestones, acciones, habitos |
| 5.6 | Crear API Flask | CRUD completo |
| 5.7 | Integrar con THE FACTORY | Refinamiento iterativo |
| 5.8 | Crear UI básica | React o directamente en Directus |
### Verificación
- [ ] APK descargable e instalable
- [ ] PACKET envía a CLARA exitosamente
- [ ] Visión se puede crear y genera milestones
---
## FASE 6: OBSERVABILIDAD
**Objetivo:** SENTINEL monitoreando todo
### Acciones
| # | Acción | Detalle |
|---|--------|---------|
| 6.1 | Crear schema SQL | sentinel_events, sentinel_alerts |
| 6.2 | Implementar hooks en cada servicio | Enviar eventos a SENTINEL |
| 6.3 | Crear dashboard | Grafana o Directus |
| 6.4 | Configurar alertas | ntfy para críticos |
### Verificación
- [ ] Eventos de todos los servicios llegan a SENTINEL
- [ ] Alertas se envían por ntfy
- [ ] Dashboard muestra estado del sistema
---
## CRONOGRAMA SUGERIDO
| Fase | Duración Estimada | Prioridad |
|------|-------------------|-----------|
| 0 | 1 día | ALTA |
| 1 | 2-3 días | CRÍTICA |
| 2 | 3-5 días | ALTA |
| 3 | 1-2 días | MEDIA |
| 4 | 5-7 días | MEDIA |
| 5 | 3-5 días | MEDIA |
| 6 | 2-3 días | BAJA |
**Total estimado:** 17-26 días de trabajo
---
## DECISIONES PENDIENTES
### Preguntas para el Usuario
1. **mind-link**: ¿Eliminar repo o implementar?
2. **Windmill vs n8n**: ¿Cuál usar para orquestación?
3. **THE FACTORY**: ¿Priorizar sobre PENNY?
4. **PACKET**: ¿Publicar en Play Store o solo APK directo?
5. **HSU API en CORP**: ¿Verificar o reimplementar?
---
## SCRIPTS DE IMPLEMENTACIÓN
Ver carpeta `/PHASES/` para scripts detallados de cada fase.
---
*Plan generado automáticamente - Revisar antes de ejecutar*

316
PHASES/FASE_0_LIMPIEZA.md Normal file
View File

@@ -0,0 +1,316 @@
# FASE 0: LIMPIEZA Y CONSOLIDACIÓN
**Complejidad:** Simple
**Duración estimada:** 1 día
---
## OBJETIVO
Eliminar confusión, actualizar documentación obsoleta, sincronizar estado real con documentación.
---
## PREREQUISITOS
- Acceso SSH a ARCHITECT
- Token de escritura Gitea: `ac5a604b9aac5cee81192a656fc918f9efa3834b`
---
## PASO 0.1: Limpiar repo architect
### Acción
Eliminar carpetas obsoletas que causan confusión.
### Script
```bash
#!/bin/bash
# 0.1-limpiar-architect.sh
set -e
WORK_DIR="/tmp/cleanup-architect"
SSH_KEY="/home/orchestrator/.ssh/tzzr"
echo "=== Limpiando repo architect ==="
# Clonar
rm -rf $WORK_DIR
mkdir -p $WORK_DIR
cd $WORK_DIR
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222 -o StrictHostKeyChecking=no" \
git clone ssh://git@localhost:2222/tzzr/architect.git
cd architect
# Eliminar carpetas obsoletas
rm -rf app-v2 orchestrator-setup orchestrator-v3 local
# Commit
git add -A
git commit -m "Limpieza: eliminar carpetas obsoletas (app-v2, orchestrator-*, local)"
# Push
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222" git push origin main
echo "=== Completado ==="
```
### Verificación
```bash
curl -s "http://localhost:3000/api/v1/repos/tzzr/architect/contents" \
-H "Authorization: token 5ca10e5b71d41f9b22f12d0f96bfc2e6de5c2c7f" | jq -r '.[].name'
# No debe aparecer: app-v2, orchestrator-setup, orchestrator-v3, local
```
### Rollback
```bash
# Git revert del último commit
cd $WORK_DIR/architect
git revert HEAD --no-edit
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222" git push origin main
```
---
## PASO 0.2: Actualizar referencias NocoDB
### Acción
Buscar y reemplazar referencias a NocoDB por Directus en todos los repos.
### Script
```bash
#!/bin/bash
# 0.2-actualizar-nocodb.sh
set -e
WORK_DIR="/tmp/cleanup-nocodb"
SSH_KEY="/home/orchestrator/.ssh/tzzr"
TOKEN="5ca10e5b71d41f9b22f12d0f96bfc2e6de5c2c7f"
# Repos a revisar
REPOS="deck corp hst system contratos-comunes"
rm -rf $WORK_DIR
mkdir -p $WORK_DIR
cd $WORK_DIR
for repo in $REPOS; do
echo "=== Procesando $repo ==="
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222 -o StrictHostKeyChecking=no" \
git clone ssh://git@localhost:2222/tzzr/$repo.git
cd $repo
# Buscar y reemplazar
find . -name "*.md" -type f -exec grep -l "NocoDB" {} \; | while read file; do
echo " Actualizando: $file"
sed -i 's/NocoDB/Directus/g' "$file"
sed -i 's/nocodb/directus/g' "$file"
done
# Si hay cambios, commit
if [[ -n $(git status --porcelain) ]]; then
git add -A
git commit -m "Actualizar referencias: NocoDB -> Directus (migración completada)"
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222" git push origin main
echo " Cambios pusheados"
else
echo " Sin cambios"
fi
cd ..
done
echo "=== Completado ==="
```
### Verificación
```bash
# No debe encontrar NocoDB en ningún README actual
for repo in deck corp hst system contratos-comunes; do
result=$(curl -s "http://localhost:3000/api/v1/repos/tzzr/$repo/raw/README.md" \
-H "Authorization: token 5ca10e5b71d41f9b22f12d0f96bfc2e6de5c2c7f" | grep -i nocodb || echo "")
if [[ -n "$result" ]]; then
echo "WARN: NocoDB encontrado en $repo"
else
echo "OK: $repo limpio"
fi
done
```
---
## PASO 0.3: Sincronizar READMEs con realidad
### Acción
Añadir badges de estado a cada repo indicando si está IMPLEMENTADO, PARCIAL, o PLANIFICADO.
### Ejemplo de Badge
```markdown
<!-- Al inicio de cada README -->
![Estado](https://img.shields.io/badge/Estado-PLANIFICADO-yellow)
```
### Script
```bash
#!/bin/bash
# 0.3-sincronizar-estados.sh
# Definición de estados
declare -A ESTADOS
ESTADOS[clara]="IMPLEMENTADO"
ESTADOS[hst]="IMPLEMENTADO"
ESTADOS[packet]="IMPLEMENTADO"
ESTADOS[orchestrator]="IMPLEMENTADO"
ESTADOS[context]="IMPLEMENTADO"
ESTADOS[grace]="PARCIAL"
ESTADOS[penny]="PARCIAL"
ESTADOS[the-factory]="PARCIAL"
ESTADOS[deck]="PARCIAL"
ESTADOS[alfred]="PLANIFICADO"
ESTADOS[jared]="PLANIFICADO"
ESTADOS[margaret]="PLANIFICADO"
ESTADOS[mason]="PLANIFICADO"
ESTADOS[feldman]="PLANIFICADO"
ESTADOS[sentinel]="PLANIFICADO"
ESTADOS[vision-builder]="PLANIFICADO"
ESTADOS[locker]="PLANIFICADO"
ESTADOS[mind-link]="PLANIFICADO"
# Colores de badge
declare -A COLORES
COLORES[IMPLEMENTADO]="green"
COLORES[PARCIAL]="orange"
COLORES[PLANIFICADO]="yellow"
SSH_KEY="/home/orchestrator/.ssh/tzzr"
WORK_DIR="/tmp/sync-estados"
rm -rf $WORK_DIR
mkdir -p $WORK_DIR
cd $WORK_DIR
for repo in "${!ESTADOS[@]}"; do
estado="${ESTADOS[$repo]}"
color="${COLORES[$estado]}"
badge="![Estado](https://img.shields.io/badge/Estado-${estado}-${color})"
echo "=== $repo: $estado ==="
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222 -o StrictHostKeyChecking=no" \
git clone ssh://git@localhost:2222/tzzr/$repo.git 2>/dev/null
cd $repo
# Verificar si README tiene badge
if grep -q "img.shields.io/badge/Estado" README.md 2>/dev/null; then
# Actualizar badge existente
sed -i "s|!\[Estado\](https://img.shields.io/badge/Estado-[^)]*)|${badge}|g" README.md
else
# Añadir badge al inicio
if [[ -f README.md ]]; then
echo -e "${badge}\n\n$(cat README.md)" > README.md
fi
fi
if [[ -n $(git status --porcelain) ]]; then
git add README.md
git commit -m "Añadir badge de estado: $estado"
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222" git push origin main
fi
cd ..
done
```
---
## PASO 0.4: Decidir sobre mind-link
### Opciones
1. **Eliminar repo** - Si no se va a implementar
2. **Marcar como ABANDONADO** - Si puede implementarse en el futuro
3. **Implementar básico** - Si es prioritario
### Recomendación
Marcar como ABANDONADO por ahora, implementar después de FASE 4.
### Script (opción 2)
```bash
#!/bin/bash
# 0.4-archivar-mind-link.sh
SSH_KEY="/home/orchestrator/.ssh/tzzr"
WORK_DIR="/tmp/mind-link-archive"
rm -rf $WORK_DIR
mkdir -p $WORK_DIR
cd $WORK_DIR
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222 -o StrictHostKeyChecking=no" \
git clone ssh://git@localhost:2222/tzzr/mind-link.git
cd mind-link
# Actualizar README
cat > README.md << 'EOF'
![Estado](https://img.shields.io/badge/Estado-ABANDONADO-red)
# MIND LINK
> **NOTA:** Este repo está temporalmente archivado. Se implementará después de completar el pipeline principal (FASE 4).
## Concepto Original
Interfaz para conectar ideas y conceptos. Visualización de relaciones entre elementos.
## Funciones Planificadas
- Conexión de conceptos
- Grafos de conocimiento
- Navegación visual
- Búsqueda semántica
---
*Archivado: 2025-12-24*
EOF
# Eliminar carpetas vacías
rm -rf src docs
git add -A
git commit -m "Archivar temporalmente: implementar post-FASE 4"
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222" git push origin main
```
---
## CHECKLIST FINAL FASE 0
- [ ] 0.1 - Carpetas obsoletas eliminadas de architect
- [ ] 0.2 - Referencias a NocoDB actualizadas
- [ ] 0.3 - Badges de estado en todos los READMEs
- [ ] 0.4 - mind-link archivado
- [ ] Todos los cambios pusheados a Gitea
- [ ] Sin errores en los repos
---
## SIGUIENTE FASE
Continuar con [FASE_1_PIPELINE_MINIMO.md](FASE_1_PIPELINE_MINIMO.md)

View File

@@ -0,0 +1,419 @@
# FASE 1: PIPELINE MÍNIMO VIABLE
**Complejidad:** Media
**Duración estimada:** 2-3 días
**Prioridad:** CRÍTICA
---
## OBJETIVO
Establecer el flujo: PACKET → CLARA → PostgreSQL + R2
Esto permite que la app móvil envíe contenido y se almacene correctamente.
---
## PREREQUISITOS
- [x] FASE 0 completada
- [x] SSH acceso a DECK (72.62.1.113)
- [x] R2 bucket 'deck' accesible
- [x] PostgreSQL en DECK funcionando
- [x] HST funcionando (tags)
---
## PASO 1.1: Crear tablas de CLARA en DECK
### Conectar a DECK
```bash
ssh -i /home/orchestrator/.ssh/tzzr root@72.62.1.113
```
### Ejecutar SQL
```bash
sudo -u postgres psql -d tzzr << 'EOF'
-- Tabla principal de 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 DEFAULT '{}',
estado VARCHAR(20) DEFAULT 'recibido',
procesado_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW(),
CONSTRAINT clara_log_h_entrada_unique UNIQUE (h_entrada)
);
-- Índices para búsqueda eficiente
CREATE INDEX IF NOT EXISTS idx_clara_h_instancia ON clara_log(h_instancia);
CREATE INDEX IF NOT EXISTS idx_clara_estado ON clara_log(estado);
CREATE INDEX IF NOT EXISTS idx_clara_created ON clara_log(created_at DESC);
CREATE INDEX IF NOT EXISTS idx_clara_contenedor ON clara_log USING gin(contenedor);
-- Comentarios
COMMENT ON TABLE clara_log IS 'Log inmutable de entrada - recibe contenedores de PACKET';
COMMENT ON COLUMN clara_log.h_instancia IS 'Hash SHA-256 que identifica la instancia DECK';
COMMENT ON COLUMN clara_log.h_entrada IS 'Hash SHA-256 único del contenedor';
COMMENT ON COLUMN clara_log.contenedor IS 'Contenedor completo en formato JSON (S-CONTRACT)';
COMMENT ON COLUMN clara_log.r2_paths IS 'Rutas de archivos subidos a R2';
COMMENT ON COLUMN clara_log.estado IS 'Estado: recibido, en_mason, en_feldman, consolidado';
-- Verificar
SELECT 'Tabla clara_log creada correctamente' AS resultado;
\dt clara_log
\d clara_log
EOF
```
### Verificación
```bash
sudo -u postgres psql -d tzzr -c "SELECT COUNT(*) FROM clara_log;"
# Debe retornar 0 (tabla vacía)
```
### Rollback
```sql
DROP TABLE IF EXISTS clara_log CASCADE;
```
---
## PASO 1.2: Generar h_instancia para DECK
### Concepto
h_instancia es un hash SHA-256 único que identifica esta instancia de DECK.
### Generar
```bash
# En DECK
SEED="deck-personal-$(hostname)-$(date +%s)"
H_INSTANCIA=$(echo -n "$SEED" | sha256sum | cut -d' ' -f1)
echo "H_INSTANCIA=$H_INSTANCIA"
# Guardar en archivo de configuración
echo "H_INSTANCIA=$H_INSTANCIA" >> /opt/clara/.env
```
### Verificación
El hash debe tener 64 caracteres hexadecimales.
---
## PASO 1.3: Desplegar CLARA como Docker
### Crear estructura en DECK
```bash
ssh -i /home/orchestrator/.ssh/tzzr root@72.62.1.113 << 'REMOTE'
mkdir -p /opt/clara
cd /opt/clara
# Clonar repo
git clone http://localhost:3000/tzzr/clara.git .
# Crear .env
cat > .env << 'EOF'
# Generado automáticamente
H_INSTANCIA=<PEGAR_HASH_GENERADO>
# PostgreSQL
DB_HOST=172.17.0.1
DB_PORT=5432
DB_NAME=tzzr
DB_USER=deck
DB_PASSWORD=<PASSWORD_DECK>
# Cloudflare R2
R2_ENDPOINT=https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
R2_ACCESS_KEY=ecddc771824c3cb3417d9451780db3d2
R2_SECRET_KEY=c8138e2597100ffb7dd1477ad722c0214f86097cd968752aea3cfcea5d54dbac
R2_BUCKET=deck
# Puerto
PORT=5051
EOF
# Construir y levantar
docker-compose up -d --build
# Verificar
docker-compose logs --tail=20
REMOTE
```
### docker-compose.yml actualizado
```yaml
version: '3.8'
services:
clara:
build: .
container_name: clara
ports:
- "5051:5051"
env_file:
- .env
restart: unless-stopped
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5051/health"]
interval: 30s
timeout: 10s
retries: 3
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
networks:
default:
external:
name: deck_network
```
### Dockerfile
```dockerfile
FROM python:3.11-slim
WORKDIR /app
# Dependencias del sistema
RUN apt-get update && apt-get install -y --no-install-recommends \
curl \
&& rm -rf /var/lib/apt/lists/*
# Dependencias Python
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Código
COPY app.py .
# Puerto
EXPOSE 5051
# Ejecutar
CMD ["python", "app.py"]
```
### Verificación
```bash
# Desde DECK
curl http://localhost:5051/health
# Debe retornar: {"service": "clara", "status": "ok", ...}
# Desde ARCHITECT
curl http://72.62.1.113:5051/health
```
---
## PASO 1.4: Configurar Caddy para /ingest
### Editar Caddyfile en DECK
```bash
ssh -i /home/orchestrator/.ssh/tzzr root@72.62.1.113 << 'REMOTE'
# Añadir a Caddyfile existente
cat >> /etc/caddy/Caddyfile << 'EOF'
# CLARA - API de ingesta
clara.tzzrdeck.me {
reverse_proxy localhost:5051
}
# También en el dominio principal
tzzrdeck.me {
handle /ingest* {
reverse_proxy localhost:5051
}
# ... resto de configuración
}
EOF
# Recargar Caddy
systemctl reload caddy
REMOTE
```
### Verificación
```bash
# HTTPS (si DNS configurado)
curl https://clara.tzzrdeck.me/health
# O directamente
curl http://72.62.1.113:5051/health
```
---
## PASO 1.5: Probar ingesta completa
### Test desde curl
```bash
# Definir variables
H_INSTANCIA="<hash_de_paso_1.2>"
TEST_HASH=$(echo -n "test-$(date +%s)" | sha256sum | cut -d' ' -f1)
# Enviar contenedor de prueba
curl -X POST http://72.62.1.113:5051/ingest \
-H "Content-Type: application/json" \
-H "X-Auth-Key: $H_INSTANCIA" \
-d '{
"id": "'$TEST_HASH'",
"archivo_hash": "'$TEST_HASH'",
"origen": {
"app": "curl-test",
"version": "1.0",
"timestamp_captura": "'$(date -Iseconds)'"
},
"contenido": {
"titulo": "Test de ingesta",
"descripcion": "Contenedor de prueba desde curl"
},
"etiquetas": []
}'
```
### Respuestas esperadas
```json
// Éxito
{"ok": true, "id": 1, "h_entrada": "abc123..."}
// Duplicado
{"error": "hash_exists"}
// Sin auth
{"error": "unauthorized"}
```
### Verificar en PostgreSQL
```bash
ssh -i /home/orchestrator/.ssh/tzzr root@72.62.1.113 \
"sudo -u postgres psql -d tzzr -c 'SELECT id, h_entrada, estado, created_at FROM clara_log ORDER BY id DESC LIMIT 5;'"
```
---
## PASO 1.6: Probar subida a R2
### Test con archivo
```bash
# Crear archivo de prueba
echo "Contenido de prueba" > /tmp/test.txt
TEST_DATA=$(base64 /tmp/test.txt)
TEST_HASH=$(echo -n "test-file-$(date +%s)" | sha256sum | cut -d' ' -f1)
curl -X POST http://72.62.1.113:5051/ingest \
-H "Content-Type: application/json" \
-H "X-Auth-Key: $H_INSTANCIA" \
-d '{
"id": "'$TEST_HASH'",
"archivo_hash": "'$TEST_HASH'",
"origen": {
"app": "curl-test",
"version": "1.0"
},
"archivos": [{
"nombre": "test.txt",
"tipo": "text/plain",
"data": "'$TEST_DATA'"
}]
}'
```
### Verificar en R2
```bash
# Usando AWS CLI configurado para R2
aws s3 ls s3://deck/ --endpoint-url https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
```
---
## CHECKLIST FINAL FASE 1
- [ ] 1.1 - Tabla clara_log creada en DECK PostgreSQL
- [ ] 1.2 - h_instancia generado y guardado
- [ ] 1.3 - CLARA corriendo en Docker
- [ ] 1.4 - Caddy configurado (opcional)
- [ ] 1.5 - Test de ingesta exitoso
- [ ] 1.6 - Archivo subido a R2
- [ ] Health check responde correctamente
- [ ] Logs sin errores
---
## MÉTRICAS DE ÉXITO
| Métrica | Valor Esperado |
|---------|----------------|
| /health responde | < 100ms |
| /ingest (sin archivo) | < 500ms |
| /ingest (con archivo) | < 2s |
| Registros en clara_log | > 0 |
| Archivos en R2/deck | > 0 |
---
## TROUBLESHOOTING
### CLARA no arranca
```bash
docker logs clara
# Verificar variables de entorno
docker exec clara env | grep -E "DB_|R2_"
```
### No conecta a PostgreSQL
```bash
# Verificar red
docker exec clara ping -c1 172.17.0.1
# Verificar puerto
docker exec clara nc -zv 172.17.0.1 5432
```
### Error R2
```bash
# Verificar credenciales
docker exec clara python -c "
import boto3
s3 = boto3.client('s3',
endpoint_url='https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com',
aws_access_key_id='ecddc771824c3cb3417d9451780db3d2',
aws_secret_access_key='c8138e2597100ffb7dd1477ad722c0214f86097cd968752aea3cfcea5d54dbac'
)
print(s3.list_buckets())
"
```
---
## SIGUIENTE FASE
Continuar con [FASE_2_PROCESAMIENTO_IA.md](FASE_2_PROCESAMIENTO_IA.md)

View File

@@ -0,0 +1,430 @@
# FASE 2: PROCESAMIENTO IA
**Complejidad:** Compleja
**Duración estimada:** 3-5 días
**Prioridad:** ALTA
---
## OBJETIVO
Desplegar GRACE en RunPod para procesamiento de:
- ASR (Speech-to-Text)
- OCR (Imágenes a texto)
- TTS (Text-to-Speech)
- Embeddings (Vectorización semántica)
- Face Detection
- Avatar Generation
---
## PREREQUISITOS
- [x] FASE 1 completada
- [ ] Cuenta RunPod con créditos
- [ ] API Key de RunPod
- [ ] Docker Hub o registro privado para imágenes
---
## PASO 2.1: Preparar imagen Docker para RunPod
### Estructura del handler
El archivo `grace/runpod/handler.py` ya está implementado y soporta:
| Módulo | Modelo | VRAM |
|--------|--------|------|
| ASR_ENGINE | Faster Whisper Large V3 | ~4GB |
| OCR_CORE | GOT-OCR 2.0 | ~8GB |
| TTS | XTTS-v2 | ~4GB |
| FACE_VECTOR | InsightFace Buffalo L | ~2GB |
| EMBEDDINGS | BGE-Large | ~2GB |
| AVATAR_GEN | SDXL Base 1.0 | ~8GB |
### Dockerfile optimizado
```dockerfile
# grace/runpod/Dockerfile
FROM runpod/pytorch:2.1.0-py3.10-cuda11.8.0-devel-ubuntu22.04
WORKDIR /app
# Variables de entorno
ENV PYTHONUNBUFFERED=1
ENV TRANSFORMERS_CACHE=/app/models
ENV HF_HOME=/app/models
# Dependencias del sistema
RUN apt-get update && apt-get install -y \
ffmpeg \
libsm6 \
libxext6 \
libgl1-mesa-glx \
&& rm -rf /var/lib/apt/lists/*
# Dependencias Python base
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Precargar modelos para reducir cold start
RUN python -c "from faster_whisper import WhisperModel; WhisperModel('large-v3', device='cpu', compute_type='int8')"
RUN python -c "from sentence_transformers import SentenceTransformer; SentenceTransformer('BAAI/bge-large-en-v1.5')"
# Código del handler
COPY handler.py .
# Iniciar handler de RunPod
CMD ["python", "-u", "handler.py"]
```
### requirements.txt
```
runpod>=1.3.0
torch>=2.1.0
transformers>=4.36.0
faster-whisper>=0.10.0
TTS>=0.22.0
sentence-transformers>=2.2.2
insightface>=0.7.3
onnxruntime-gpu>=1.16.0
diffusers>=0.24.0
accelerate>=0.25.0
safetensors>=0.4.0
Pillow>=10.0.0
opencv-python-headless>=4.8.0
numpy>=1.24.0
boto3>=1.34.0
```
---
## PASO 2.2: Construir y subir imagen
### Opción A: Docker Hub
```bash
# En máquina con Docker
cd grace/runpod
# Construir
docker build -t tzzr/grace-gpu:v1.0 .
# Login a Docker Hub
docker login
# Subir
docker push tzzr/grace-gpu:v1.0
```
### Opción B: RunPod Registry
```bash
# Usar la CLI de RunPod
runpodctl build --name grace-gpu --tag v1.0 .
```
---
## PASO 2.3: Crear template en RunPod
### Via Dashboard
1. Ir a RunPod → Templates → Create Template
2. Configurar:
- **Name**: GRACE-GPU
- **Container Image**: tzzr/grace-gpu:v1.0
- **Container Disk**: 50GB
- **Volume Disk**: 100GB (para modelos)
- **Volume Mount Path**: /app/models
- **Expose HTTP Ports**: 8000
- **Expose TCP Ports**: (vacío)
### Via API
```bash
RUNPOD_API_KEY="<tu_api_key>"
curl -X POST "https://api.runpod.io/graphql" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $RUNPOD_API_KEY" \
-d '{
"query": "mutation { saveTemplate(input: { name: \"GRACE-GPU\", imageName: \"tzzr/grace-gpu:v1.0\", dockerArgs: \"\", containerDiskInGb: 50, volumeInGb: 100, volumeMountPath: \"/app/models\", ports: \"8000/http\", isServerless: true }) { id name } }"
}'
```
---
## PASO 2.4: Crear endpoint serverless
### Via Dashboard
1. Ir a Serverless → Create Endpoint
2. Configurar:
- **Name**: GRACE-Endpoint
- **Template**: GRACE-GPU
- **GPU Type**: RTX 4090 (24GB VRAM)
- **Min Workers**: 0
- **Max Workers**: 3
- **Idle Timeout**: 5 segundos
- **Flash Boot**: Enabled
### Configuración recomendada por módulo
| Módulo | GPU Mínima | GPU Recomendada |
|--------|------------|-----------------|
| ASR_ENGINE | RTX 3080 (10GB) | RTX 4090 (24GB) |
| OCR_CORE | RTX 3090 (24GB) | RTX 4090 (24GB) |
| TTS | RTX 3080 (10GB) | RTX 4090 (24GB) |
| FACE_VECTOR | RTX 3060 (8GB) | RTX 4090 (24GB) |
| EMBEDDINGS | RTX 3060 (8GB) | RTX 4090 (24GB) |
| AVATAR_GEN | RTX 3090 (24GB) | RTX 4090 (24GB) |
---
## PASO 2.5: Probar endpoint
### Test ASR_ENGINE
```bash
ENDPOINT_ID="<tu_endpoint_id>"
RUNPOD_API_KEY="<tu_api_key>"
# Crear audio de prueba (o usar uno existente)
# ffmpeg -f lavfi -i "sine=frequency=440:duration=3" -ar 16000 test.wav
# Codificar en base64
AUDIO_B64=$(base64 -w0 test.wav)
# Enviar request
curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $RUNPOD_API_KEY" \
-d '{
"input": {
"contract_version": "2.1",
"profile": "LITE",
"envelope": {
"trace_id": "test-asr-001"
},
"routing": {
"module": "ASR_ENGINE"
},
"payload": {
"type": "audio",
"encoding": "base64",
"content": "'$AUDIO_B64'"
},
"context": {
"lang": "es"
}
}
}'
```
### Respuesta esperada
```json
{
"id": "...",
"status": "COMPLETED",
"output": {
"contract_version": "2.1",
"status": {"code": "SUCCESS"},
"result": {
"schema": "asr_output_v1",
"data": {
"text": "...",
"language_detected": "es",
"duration_seconds": 3.0,
"segments": [...]
}
},
"quality": {
"confidence": 0.95
}
}
}
```
### Test OCR_CORE
```bash
# Imagen de prueba
IMAGE_B64=$(base64 -w0 test_image.png)
curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $RUNPOD_API_KEY" \
-d '{
"input": {
"contract_version": "2.1",
"routing": {"module": "OCR_CORE"},
"payload": {
"type": "image",
"encoding": "base64",
"content": "'$IMAGE_B64'"
}
}
}'
```
---
## PASO 2.6: Documentar endpoint
### Guardar en credentials
```bash
# En ARCHITECT, actualizar repo credentials
cd /tmp && rm -rf credentials
GIT_SSH_COMMAND="ssh -i /home/orchestrator/.ssh/tzzr -p 2222" \
git clone ssh://git@localhost:2222/tzzr/credentials.git
cd credentials
cat >> inventario/08-gpu-runpod.md << 'EOF'
## GRACE Endpoint (Actualizado 2025-12-24)
| Parámetro | Valor |
|-----------|-------|
| Endpoint ID | <endpoint_id> |
| Template | GRACE-GPU v1.0 |
| GPU | RTX 4090 |
| Max Workers | 3 |
| Idle Timeout | 5s |
### Módulos disponibles
- ASR_ENGINE (Whisper Large V3)
- OCR_CORE (GOT-OCR 2.0)
- TTS (XTTS-v2)
- FACE_VECTOR (InsightFace)
- EMBEDDINGS (BGE-Large)
- AVATAR_GEN (SDXL)
### Ejemplo de uso
```bash
curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
-H "Authorization: Bearer ${RUNPOD_API_KEY}" \
-d '{"input": {...}}'
```
EOF
git add -A
git commit -m "Documentar GRACE endpoint RunPod"
GIT_SSH_COMMAND="ssh -i /home/orchestrator/.ssh/tzzr -p 2222" git push origin main
```
---
## PASO 2.7: Integrar con DECK
### Crear cliente GRACE en DECK
```python
# /opt/deck/grace_client.py
import os
import base64
import requests
from typing import Dict, Any, Optional
class GraceClient:
def __init__(self):
self.endpoint_id = os.getenv("GRACE_ENDPOINT_ID")
self.api_key = os.getenv("RUNPOD_API_KEY")
self.base_url = f"https://api.runpod.ai/v2/{self.endpoint_id}"
def call(self, module: str, content: bytes, context: Dict = None) -> Dict[str, Any]:
"""Llamar a módulo GRACE"""
payload = {
"input": {
"contract_version": "2.1",
"routing": {"module": module},
"payload": {
"type": self._get_type(module),
"encoding": "base64",
"content": base64.b64encode(content).decode()
},
"context": context or {}
}
}
response = requests.post(
f"{self.base_url}/runsync",
headers={"Authorization": f"Bearer {self.api_key}"},
json=payload,
timeout=120
)
return response.json()
def _get_type(self, module: str) -> str:
types = {
"ASR_ENGINE": "audio",
"OCR_CORE": "image",
"TTS": "text",
"FACE_VECTOR": "image",
"EMBEDDINGS": "text",
"AVATAR_GEN": "text"
}
return types.get(module, "binary")
def transcribe(self, audio_bytes: bytes, lang: str = "es") -> str:
"""Convenience method para ASR"""
result = self.call("ASR_ENGINE", audio_bytes, {"lang": lang})
return result.get("output", {}).get("result", {}).get("data", {}).get("text", "")
def ocr(self, image_bytes: bytes) -> str:
"""Convenience method para OCR"""
result = self.call("OCR_CORE", image_bytes)
return result.get("output", {}).get("result", {}).get("data", {}).get("text", "")
def embed(self, text: str) -> list:
"""Convenience method para embeddings"""
result = self.call("EMBEDDINGS", text.encode(), {})
return result.get("output", {}).get("result", {}).get("data", {}).get("vector", [])
```
---
## CHECKLIST FINAL FASE 2
- [ ] 2.1 - Dockerfile preparado
- [ ] 2.2 - Imagen subida a registro
- [ ] 2.3 - Template creado en RunPod
- [ ] 2.4 - Endpoint serverless configurado
- [ ] 2.5 - Tests exitosos (ASR, OCR, etc.)
- [ ] 2.6 - Credenciales documentadas
- [ ] 2.7 - Cliente integrado en DECK
---
## MÉTRICAS DE ÉXITO
| Métrica | Valor Esperado |
|---------|----------------|
| Cold start | < 60s |
| Warm ASR (30s audio) | < 10s |
| Warm OCR (imagen) | < 5s |
| Disponibilidad | > 99% |
---
## COSTOS ESTIMADOS
| Uso | GPU | Costo/hora | Estimado mensual |
|-----|-----|------------|------------------|
| Bajo (10 req/día) | RTX 4090 | $0.69 | ~$5-10 |
| Medio (100 req/día) | RTX 4090 | $0.69 | ~$30-50 |
| Alto (1000 req/día) | RTX 4090 | $0.69 | ~$100-200 |
---
## SIGUIENTE FASE
Continuar con [FASE_3_FLUJO_EMPRESARIAL.md](FASE_3_FLUJO_EMPRESARIAL.md)

View File

@@ -0,0 +1,259 @@
# FASE 3: FLUJO EMPRESARIAL
**Complejidad:** Media
**Duración estimada:** 1-2 días
**Prioridad:** MEDIA
---
## OBJETIVO
Desplegar MARGARET en CORP (clon de CLARA para servidor empresarial).
---
## PREREQUISITOS
- [x] FASE 1 completada (CLARA funcionando)
- [ ] SSH acceso a CORP (92.112.181.188)
- [ ] PostgreSQL en CORP accesible
- [ ] R2 bucket 'corp' accesible
---
## PASO 3.1: Crear repo margaret con código
MARGARET es esencialmente CLARA con:
- Diferente h_instancia
- Bucket R2 'corp' en lugar de 'deck'
- Tabla margaret_log en lugar de clara_log
- Campos adicionales para empresas (opcional)
### Script
```bash
#!/bin/bash
# Crear MARGARET como fork de CLARA
SSH_KEY="/home/orchestrator/.ssh/tzzr"
WORK_DIR="/tmp/create-margaret"
rm -rf $WORK_DIR
mkdir -p $WORK_DIR
cd $WORK_DIR
# Clonar CLARA
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222" \
git clone ssh://git@localhost:2222/tzzr/clara.git margaret
cd margaret
# Renombrar referencias
find . -type f -name "*.py" -exec sed -i 's/clara/margaret/g' {} \;
find . -type f -name "*.py" -exec sed -i 's/CLARA/MARGARET/g' {} \;
find . -type f -name "*.md" -exec sed -i 's/clara/margaret/g' {} \;
find . -type f -name "*.md" -exec sed -i 's/CLARA/MARGARET/g' {} \;
find . -type f -name "*.md" -exec sed -i 's/DECK/CORP/g' {} \;
# Actualizar docker-compose.yml
sed -i 's/5051/5052/g' docker-compose.yml
sed -i 's/deck/corp/g' docker-compose.yml
# Actualizar README
cat > README.md << 'EOF'
![Estado](https://img.shields.io/badge/Estado-IMPLEMENTADO-green)
# MARGARET
**Log de entrada CORP - Sistema TZZR**
Clon de CLARA para servidor empresarial. Recibe contenedores de PACKET y los almacena en PostgreSQL + R2.
## Diferencias con CLARA
| Aspecto | CLARA | MARGARET |
|---------|-------|----------|
| Servidor | DECK | CORP |
| Puerto | 5051 | 5052 |
| Bucket R2 | deck | corp |
| Tabla | clara_log | margaret_log |
## Despliegue
```bash
cd /opt/margaret
cp .env.example .env
# Editar .env con credenciales
docker-compose up -d
```
## API
Idéntica a CLARA:
- `POST /ingest` - Recibir contenedor
- `GET /query/{h_entrada}` - Consultar por hash
- `GET /list` - Listar entradas
- `GET /health` - Health check
EOF
# Cambiar origen remoto
git remote set-url origin ssh://git@localhost:2222/tzzr/margaret.git
# Crear nuevo historial
rm -rf .git
git init
git add -A
git commit -m "MARGARET: fork de CLARA para CORP"
# Push (asumiendo que el repo ya existe vacío)
GIT_SSH_COMMAND="ssh -i $SSH_KEY -p 2222" git push -u origin main --force
```
---
## PASO 3.2: Crear tablas en CORP PostgreSQL
### Conectar a CORP
```bash
ssh -i /home/orchestrator/.ssh/tzzr root@92.112.181.188
```
### Crear base de datos si no existe
```bash
sudo -u postgres psql << 'EOF'
CREATE DATABASE corp;
CREATE USER margaret WITH PASSWORD 'margaret_secure_2024';
GRANT ALL PRIVILEGES ON DATABASE corp TO margaret;
EOF
```
### Crear tabla
```bash
sudo -u postgres psql -d corp << 'EOF'
CREATE TABLE IF NOT EXISTS margaret_log (
id BIGSERIAL PRIMARY KEY,
h_instancia VARCHAR(64) NOT NULL,
h_entrada VARCHAR(64) NOT NULL,
contenedor JSONB NOT NULL,
r2_paths JSONB DEFAULT '{}',
estado VARCHAR(20) DEFAULT 'recibido',
-- Campos adicionales para empresas
empresa_id VARCHAR(64),
proyecto_id VARCHAR(64),
aprobado_por VARCHAR(100),
procesado_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW(),
CONSTRAINT margaret_log_h_entrada_unique UNIQUE (h_entrada)
);
CREATE INDEX idx_margaret_h_instancia ON margaret_log(h_instancia);
CREATE INDEX idx_margaret_empresa ON margaret_log(empresa_id);
CREATE INDEX idx_margaret_proyecto ON margaret_log(proyecto_id);
CREATE INDEX idx_margaret_created ON margaret_log(created_at DESC);
COMMENT ON TABLE margaret_log IS 'Log de entrada CORP - contenedores empresariales';
EOF
```
---
## PASO 3.3: Desplegar MARGARET
### En CORP
```bash
ssh -i /home/orchestrator/.ssh/tzzr root@92.112.181.188 << 'REMOTE'
mkdir -p /opt/margaret
cd /opt/margaret
# Clonar repo
git clone http://69.62.126.110:3000/tzzr/margaret.git .
# Generar h_instancia único para CORP
SEED="corp-enterprise-$(hostname)-$(date +%s)"
H_INSTANCIA=$(echo -n "$SEED" | sha256sum | cut -d' ' -f1)
# Crear .env
cat > .env << EOF
H_INSTANCIA=$H_INSTANCIA
# PostgreSQL
DB_HOST=localhost
DB_PORT=5432
DB_NAME=corp
DB_USER=margaret
DB_PASSWORD=margaret_secure_2024
# R2
R2_ENDPOINT=https://7dedae6030f5554d99d37e98a5232996.r2.cloudflarestorage.com
R2_ACCESS_KEY=ecddc771824c3cb3417d9451780db3d2
R2_SECRET_KEY=c8138e2597100ffb7dd1477ad722c0214f86097cd968752aea3cfcea5d54dbac
R2_BUCKET=corp
PORT=5052
EOF
# Construir y levantar
docker-compose up -d --build
REMOTE
```
---
## PASO 3.4: Configurar Caddy en CORP
```bash
ssh -i /home/orchestrator/.ssh/tzzr root@92.112.181.188 << 'REMOTE'
cat >> /etc/caddy/Caddyfile << 'EOF'
margaret.tzzrcorp.me {
reverse_proxy localhost:5052
}
EOF
systemctl reload caddy
REMOTE
```
---
## PASO 3.5: Probar ingesta
```bash
H_INSTANCIA="<hash_generado_en_corp>"
curl -X POST http://92.112.181.188:5052/ingest \
-H "Content-Type: application/json" \
-H "X-Auth-Key: $H_INSTANCIA" \
-d '{
"id": "test-corp-001",
"archivo_hash": "test-corp-hash-001",
"origen": {"app": "test"},
"empresa_id": "empresa-001",
"proyecto_id": "proyecto-alpha"
}'
```
---
## CHECKLIST FINAL FASE 3
- [ ] 3.1 - Repo margaret creado con código
- [ ] 3.2 - Tabla margaret_log creada
- [ ] 3.3 - MARGARET corriendo en Docker
- [ ] 3.4 - Caddy configurado
- [ ] 3.5 - Test de ingesta exitoso
---
## SIGUIENTE FASE
Continuar con [FASE_4_PIPELINE_COMPLETO.md](FASE_4_PIPELINE_COMPLETO.md)

View File

@@ -1,3 +1,61 @@
# system-plan # TZZR System Plan
Plan de implementación y estado real del ecosistema TZZR **Estado real y plan de implementacion del ecosistema TZZR**
Generado: 2025-12-24
---
## Documentos
| Documento | Descripcion |
|-----------|-------------|
| [ARCHITECTURE.md](ARCHITECTURE.md) | Estado real del ecosistema, inventario de repos, inconsistencias |
| [IMPLEMENTATION_PLAN.md](IMPLEMENTATION_PLAN.md) | Plan de implementacion por fases |
| [PHASES/](PHASES/) | Scripts detallados para cada fase |
---
## Resumen Ejecutivo
### Estado Actual
| Categoria | Implementado | Parcial | Solo Docs |
|-----------|--------------|---------|-----------|
| **Repos** | 5 | 4 | 14 |
| **Pipeline datos** | 10% | - | 90% |
| **Procesamiento IA** | 0% | Template listo | - |
| **Apps usuario** | Codigo listo | - | - |
### Fases de Implementacion
| Fase | Objetivo | Complejidad |
|------|----------|-------------|
| 0 | Limpieza y consolidacion | Simple |
| 1 | Pipeline minimo (CLARA a R2) | Media |
| 2 | Procesamiento IA (GRACE RunPod) | Compleja |
| 3 | Flujo empresarial (MARGARET) | Media |
| 4 | Pipeline completo (MASON, FELDMAN) | Compleja |
| 5 | Apps de usuario (PACKET) | Media |
| 6 | Observabilidad (SENTINEL) | Simple |
---
## Inconsistencias Criticas
1. **CLARA documentada pero no desplegada** - Flujo de ingesta no funciona
2. **Pipeline completo solo en docs** - MASON, FELDMAN, ALFRED no existen
3. **GRACE no desplegado** - Procesamiento IA no disponible
4. **R2 buckets vacios** - Almacenamiento configurado pero no usado
---
## Proximos Pasos
1. Ejecutar FASE 0 (limpieza)
2. Desplegar CLARA en DECK (FASE 1)
3. Configurar GRACE en RunPod (FASE 2)
---
*Documento de trabajo - Revisar antes de ejecutar*