tzzr/system-plan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Actualizar estado post FASE 0, 1, 3

Browse Source 
- ARCHITECTURE.md: Estado actualizado, CLARA y MARGARET implementados
- IMPLEMENTATION_PLAN.md: Fases 0, 1, 3 marcadas como completadas
- STATUS.md: Nuevo archivo con resumen ejecutivo rapido
- README.md: Actualizado con estado actual

Progreso:
- Pipeline datos: 10% -> 40%
- CLARA desplegado en DECK:5051
- MARGARET desplegado en CORP:5051
- Bloqueador: GRACE requiere cuenta RunPod
This commit is contained in:
ARCHITECT
2025-12-24 09:36:08 +00:00
parent 73ae91d337
commit 0e3576aec6
4 changed files with 467 additions and 467 deletions
Download Patch File Download Diff File Expand all files Collapse all files

426
IMPLEMENTATION_PLAN.md
View File

@@ -1,345 +1,243 @@
# TZZR - Plan de Implementación
# TZZR - Plan de Implementacion
**Fecha:** 2025-12-24
**Ultima actualizacion:** 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 | Objetivo | Estado | Repos Afectados |
|------|----------|--------|-----------------|
| 0 | Limpieza y consolidacion | COMPLETADA | architect, system, mind-link |
| 1 | Pipeline minimo viable | COMPLETADA | clara, deck |
| 2 | Procesamiento IA | BLOQUEADA | grace, penny, the-factory |
| 3 | Flujo empresarial | COMPLETADA | margaret, corp |
| 4 | Pipeline completo | PENDIENTE | mason, feldman, alfred, jared |
| 5 | Apps de usuario | PENDIENTE | packet, vision-builder |
| 6 | Observabilidad | PENDIENTE | sentinel |
---
## FASE 0: LIMPIEZA Y CONSOLIDACIÓN
## FASE 0: LIMPIEZA Y CONSOLIDACION - COMPLETADA
**Objetivo:** Eliminar confusión, actualizar documentación obsoleta
**Ejecutada:** 2025-12-24
### Acciones
### Acciones Completadas
| # | 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 |
| # | Accion | Estado |
|---|--------|--------|
| 0.1 | Eliminar carpetas obsoletas de architect | OK |
| 0.2 | Actualizar referencias a NocoDB -> Directus | OK |
| 0.3 | Anadir badges de estado a todos los repos | OK |
| 0.4 | Archivar mind-link | OK |
### Script de Ejecución
### Verificacion
```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
- [x] No existen carpetas app-v2, orchestrator-* en architect
- [x] No hay referencias a NocoDB en documentacion activa
- [x] Todos los READMEs tienen badge de estado
- [x] mind-link archivado con README explicativo
---
## FASE 1: PIPELINE MÍNIMO VIABLE
## FASE 1: PIPELINE MINIMO VIABLE - COMPLETADA
**Objetivo:** PACKET → CLARA → PostgreSQL → R2 funcionando
**Ejecutada:** 2025-12-24
### Prerequisitos
- PostgreSQL en DECK accesible
- R2 bucket 'deck' configurado
- HST funcionando (ya OK)
### Acciones Completadas
### Acciones
| # | Accion | Estado | Detalle |
|---|--------|--------|---------|
| 1.1 | Crear tabla clara_log en DECK | OK | PostgreSQL Docker |
| 1.2 | Generar h_instancia | OK | f25e44ac... |
| 1.3 | Desplegar CLARA Docker | OK | Puerto 5051 |
| 1.4 | Configurar red Docker | OK | tzzr-network |
| 1.5 | Probar ingesta | OK | Auth + duplicados |
| # | 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 |
### Configuracion Final
### 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);
```
Servidor: DECK (72.62.1.113)
Puerto: 5051
DB: tzzr (PostgreSQL Docker)
Tabla: clara_log
R2 Bucket: deck
h_instancia: f25e44ac3c075f57b9a198c880cb1fc05cf3af56f6466828b405d8c062374179
```
### Docker Compose (clara)
### Verificacion
```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
- [x] `curl http://72.62.1.113:5051/health` responde OK
- [x] Sin auth responde 401
- [x] Con auth valida responde 200
- [x] Duplicados responden 409
- [x] Registro aparece en clara_log
---
## FASE 2: PROCESAMIENTO IA
## FASE 2: PROCESAMIENTO IA - BLOQUEADA
**Objetivo:** GRACE desplegado en RunPod, llamable desde DECK
**Bloqueador:** Requiere cuenta RunPod configurada
### Acciones
### Acciones Pendientes
| # | 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 |
| # | Accion | Estado |
|---|--------|--------|
| 2.1 | Crear template en RunPod | PENDIENTE |
| 2.2 | Configurar endpoint serverless | PENDIENTE |
| 2.3 | Probar modulo ASR_ENGINE | PENDIENTE |
| 2.4 | Probar modulo OCR_CORE | PENDIENTE |
| 2.5 | Documentar endpoint ID | PENDIENTE |
### Dockerfile GRACE
### Codigo Disponible
```dockerfile
FROM runpod/pytorch:2.1.0-py3.10-cuda11.8.0-devel
El repo `grace` contiene:
- handler.py con 6 modulos
- Dockerfile para RunPod
- requirements.txt
WORKDIR /app
### Para Desbloquear
# 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)
1. Crear cuenta RunPod
2. Subir template desde grace/runpod/
3. Crear endpoint serverless
4. Documentar ENDPOINT_ID en credentials
---
## FASE 3: FLUJO EMPRESARIAL
## FASE 3: FLUJO EMPRESARIAL - COMPLETADA
**Objetivo:** MARGARET funcionando en CORP (clon de CLARA)
**Ejecutada:** 2025-12-24
### Acciones
### Acciones Completadas
| # | 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 |
| # | Accion | Estado | Detalle |
|---|--------|--------|---------|
| 3.1 | Verificar PostgreSQL en CORP | OK | Host PostgreSQL |
| 3.2 | Crear tabla margaret_log | OK | DB: corp |
| 3.3 | Generar h_instancia | OK | ea9e99d5... |
| 3.4 | Desplegar MARGARET Docker | OK | Puerto 5051 |
| 3.5 | Probar ingesta | OK | Auth + duplicados |
### Diferencias CLARA vs MARGARET
### Configuracion Final
| 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 |
```
Servidor: CORP (92.112.181.188)
Puerto: 5051
DB: corp (PostgreSQL Host)
Tabla: margaret_log
R2 Bucket: corp
h_instancia: ea9e99d5f95bcc23749d5f25b71a5b520ae7917438912fc6e29564534484a514
```
### Verificación
- [ ] MARGARET responde en CORP:5052
- [ ] Registros en margaret_log
- [ ] Archivos en R2/corp
### Verificacion
- [x] `curl http://92.112.181.188:5051/health` responde OK
- [x] Sin auth responde 401
- [x] Con auth valida responde 200
- [x] Duplicados responden 409
- [x] Registro aparece en margaret_log
---
## FASE 4: PIPELINE COMPLETO
## FASE 4: PIPELINE COMPLETO - PENDIENTE
**Objetivo:** MASON y FELDMAN implementados
**Dependencia:** GRACE (FASE 2) para procesamiento IA
### ALFRED (Flujos Predefinidos DECK)
| # | Accion | Estado |
|---|--------|--------|
| 4.1 | Crear schema SQL flujos | PENDIENTE |
| 4.2 | Implementar API Flask | PENDIENTE |
| 4.3 | Integrar con CLARA | PENDIENTE |
**Nota:** ALFRED puede implementarse sin GRACE para flujos que no requieran IA.
### JARED (Flujos Predefinidos CORP)
| # | Accion | Estado |
|---|--------|--------|
| 4.4 | Fork de ALFRED | PENDIENTE |
| 4.5 | Adaptar para CORP | PENDIENTE |
| 4.6 | Integrar con MARGARET | PENDIENTE |
### 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 |
| # | Accion | Estado |
|---|--------|--------|
| 4.7 | Crear schema SQL | BLOQUEADO (GRACE) |
| 4.8 | Implementar API Flask | BLOQUEADO (GRACE) |
| 4.9 | Integrar con GRACE | BLOQUEADO (GRACE) |
### FELDMAN (Consolidación)
### FELDMAN (Consolidacion)
| # | 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
| # | Accion | Estado |
|---|--------|--------|
| 4.10 | Crear schema SQL | BLOQUEADO (MASON) |
| 4.11 | Implementar API Flask | BLOQUEADO (MASON) |
| 4.12 | Generar bloques 24h | BLOQUEADO (MASON) |
---
## FASE 5: APPS DE USUARIO
**Objetivo:** PACKET publicada, VISION BUILDER operativo
## FASE 5: APPS DE USUARIO - PENDIENTE
### 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 |
| # | Accion | Estado |
|---|--------|--------|
| 5.1 | Configurar firma Android | PENDIENTE |
| 5.2 | Build APK release | PENDIENTE |
| 5.3 | Publicar en Gitea releases | PENDIENTE |
### 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
| # | Accion | Estado |
|---|--------|--------|
| 5.4 | Implementar schema SQL | BLOQUEADO (FACTORY) |
| 5.5 | Crear API Flask | BLOQUEADO (FACTORY) |
| 5.6 | Integrar con THE FACTORY | BLOQUEADO (FACTORY) |
---
## FASE 6: OBSERVABILIDAD
## FASE 6: OBSERVABILIDAD - PENDIENTE
**Objetivo:** SENTINEL monitoreando todo
### SENTINEL
### 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
| # | Accion | Estado |
|---|--------|--------|
| 6.1 | Crear schema SQL | PENDIENTE |
| 6.2 | Implementar hooks | PENDIENTE |
| 6.3 | Dashboard Grafana | PENDIENTE |
| 6.4 | Alertas ntfy | PENDIENTE |
---
## CRONOGRAMA SUGERIDO
## PROXIMO PASO RECOMENDADO
| 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 |
### Opcion A: Desbloquear GRACE (alto impacto)
1. Configurar cuenta RunPod
2. Desplegar GRACE
3. Habilita MASON, FELDMAN, THE FACTORY
**Total estimado:** 17-26 días de trabajo
### Opcion B: Implementar ALFRED/JARED (sin bloqueo)
1. Flujos predefinidos sin IA
2. Integrar con CLARA/MARGARET
3. Puede hacerse en paralelo
### Opcion C: Publicar PACKET (usuario final)
1. Build APK
2. Publicar en Gitea
3. Permite pruebas end-to-end
---
## DECISIONES PENDIENTES
## SCRIPTS DE IMPLEMENTACION
### 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?
Ver carpeta `/PHASES/` para scripts detallados.
---
## SCRIPTS DE IMPLEMENTACIÓN
Ver carpeta `/PHASES/` para scripts detallados de cada fase.
---
*Plan generado automáticamente - Revisar antes de ejecutar*
*Plan actualizado automaticamente - 2025-12-24*