system-plan/IMPLEMENTATION_PLAN.md

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

# 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

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

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

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

# 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