# 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*