tzzr/system-plan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
73ae91d3378da242db596d8f8bcb9cf4c1da5d16
system-plan/IMPLEMENTATION_PLAN.md
ARCHITECT 73ae91d337 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
2025-12-24 08:59:14 +00:00

346 lines
9.7 KiB
Markdown
Raw Blame History

# 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*
Reference in New Issue View Git Blame Copy Permalink