proyectos/docs-mission-control
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Documentación inicial de Control de Misión

Browse Source
This commit is contained in:
Daniel Arroyo
2026-03-27 18:18:52 +00:00
parent f1e9265bd2
commit bd4eab54ce
7 changed files with 575 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
CONFIGURACION.md Normal file
View File

@@ -0,0 +1,24 @@
# Configuración para Gitea
## Repo Remoto
- **URL**: https://gitea.danielarroyo.cl/openclaw-team/control-mision
- **Estado**: Pendiente de configuración
## Pasos para Conectar
```bash
# 1. Agregar login de Gitea (requiere token API)
tea login add --name=gitea --url=https://gitea.danielarroyo.cl --token=TU_TOKEN
# 2. Verificar conexión
tea repos list
# 3. Agregar remote al repo local
git remote add origin https://gitea.danielarroyo.cl/openclaw-team/control-mision.git
# 4. Push inicial
git push -u origin main
```
## Nota
La documentación local está completa y lista para ser empujada al remote cuando se configure el acceso a Gitea.

65
README.md
View File

@@ -1,3 +1,64 @@
# docs-mission-control
# Control de Misión
Documentación del sistema de Control de Misión
Sistema de gestión y coordinación de agentes para el equipo OpenClaw.
## 📋 Descripción
Control de Misión documenta cómo nuestros agentes trabajan juntos para completar objetivos complejos. Define roles, flujos de trabajo, protocolos de comunicación y ejemplos prácticos.
## 🧑‍💼 Agentes del Equipo
| Agente | Rol | Responsabilidad |
|--------|-----|-----------------|
| 🎯 Erwin | Orquestador | Coordina y delega tareas |
| 🏗️ Bulma | Arquitecto | Diseño de sistemas y arquitectura |
| 🚀 Rocket | Desarrollador | Implementación de código |
| 🎨 Hiro | Diseñador | UI/UX y experiencia de usuario |
| 🔍 Sherlock | Revisor | Revisión y validación |
| 📝 Claudia | Asistente | Documentación y organización |
## 📁 Estructura del Repo
```
control-mision/
├── docs/
│ ├── agentes/ # Perfiles de cada agente
│ ├── workflow/ # Flujos de trabajo definidos
│ └── comunicacion/ # Protocolos de comunicación
├── proyectos/ # Misiones gestionadas
└── ejemplos/ # Casos de uso documentados
```
## 🔄 Flujo de Trabajo Estándar
1. **Definición** → Erwin recibe y define la misión
2. **Análisis** → Bulma diseña la solución
3. **Implementación** → Rocket desarrolla
4. **UI/UX** → Hiro diseña interfaces (si aplica)
5. **Revisión** → Sherlock valida
6. **Documentación** → Claudia archiva
## 📖 Documentación
- [Requisitos del Sistema](docs/REQUISITOS.md)
- [Protocolo de Comunicación](docs/comunicacion/proTOCOLO.md)
- [Workflow Estándar](docs/workflow/flujo-estandar.md)
- [Perfil de Agente (template)](docs/agentes/PERFIL.md)
## 🚀 Empezar
1. Clonar el repo
2. Leer docs/REQUISITOS.md para entender el sistema
3. Revisar ejemplos/ para ver casos reales
4. Consultar docs/agentes/ para entender cada rol
## 📝 Agregar una Misión
1. Crear carpeta en `proyectos/[nombre]/`
2. Definir metadatos en `mision.yaml`
3. Documentar progreso en `README.md` del proyecto
4. Usar el workflow estándar como guía
---
*Sistema de Coordinación de Agentes — OpenClaw Team*

154
docs/REQUISITOS.md Normal file
View File

@@ -0,0 +1,154 @@
# Control de Misión — Requisitos del Sistema
## 1. Objetivo del Sistema
Control de Misión es un sistema de coordinación de agentes que permite:
- Definir misiones (objetivos) con claridad
- Asignar tareas a agentes especializados según sus capacidades
- Rastrear el progreso y mantener trazabilidad
- Documentar decisiones y resultados automáticamente
## 2. Funcionalidades Principales
### 2.1 Gestión de Misiones
- **Crear misión**: Título, descripción, prioridad,deadline
- **Descomponer misión**: Erwin divide en subtareas
- **Asignar subtareas**: Cada tarea va al agente apropiado
- **Estado de misión**: Pendiente → En Progreso → Completada / Bloqueada
- **Historial**: Todas las acciones quedan registradas
### 2.2 Catálogo de Agentes
Cada agente tiene perfil documentado con:
- Rol y responsabilidades
- Capacidades y limitaciones
- Protocolos de comunicación preferidos
- Métricas de rendimiento
### 2.3 Protocolo de Comunicación
- Formato estándar de mensajes entre agentes
- Canales: Síncrono (chat directo) / Asíncrono (cola de tareas)
- Reglas de escalamiento: Si un agente se bloquea, escala a Erwin
- Timeouts y reintentos automáticos
### 2.4 Workflows Predefinidos
- **Workflow estándar**: Idea → Análisis → Diseño → Implementación → Revisión → Documentación
- **Workflow rápido**: Para tareas simples de una sola paso
- **Workflow de emergencia**: Prioridad máxima con revisión simplificada
### 2.5 Dashboard de Estado
- Misiones activas y su progreso
- Agentes disponibles/ocupados
- Tareas pendientes por agente
- Alertas de bloqueos o demoras
## 3. Estructura de Documentación Requerida
```
control-mision/
├── docs/
│ ├── agentes/ # Perfiles de cada agente
│ │ ├── erwin.md
│ │ ├── bulma.md
│ │ ├── rocket.md
│ │ ├── hiro.md
│ │ ├── sherlock.md
│ │ └── claudia.md
│ ├── workflow/ # Flujos de trabajo
│ │ ├── flujo-estandar.md
│ │ ├── flujo-rapido.md
│ │ └── flujo-emergencia.md
│ ├── comunicacion/ # Protocolos
│ │ ├── protocolo-mensajes.md
│ │ ├── escalamiento.md
│ │ └── formatos.md
│ └── REQUISITOS.md # Este documento
├── proyectos/ # Misiones activas y completadas
│ └── [proyecto-001]/...
├── ejemplos/ # Casos de uso reales
│ ├── ejemplo-001.md
│ └── ejemplo-002.md
└── README.md
```
## 4. Metadatos de Misión
Cada misión debe tener:
```yaml
nombre: string
descripcion: string
prioridad: baja|media|alta|critica
creada_por: agente
creada_en: timestamp
deadline: timestamp (opcional)
estado: pendiente|en_progreso|completada|bloqueada
subtareas:
- id: string
nombre: string
asignada_a: agente
estado: pendiente|en_progreso|completada
resultado: string (al completar)
```
## 5. Reglas de Coordinación
### 5.1 Asignación por Defecto
| Tipo de Tarea | Agente Asignado |
|---------------|------------------|
| Arquitectura, diseño de sistemas | Bulma |
| Código, scripts, implementación | Rocket |
| UI/UX, interfaces | Hiro |
| Revisión, validación, testing | Sherlock |
| Documentación, organización | Claudia |
| Coordinación, decisión,拆分 de trabajo | Erwin |
### 5.2 Reglas de Escalamiento
1. Agente bloqueado → informa a Erwin con contexto
2. Erwin reasigna o ajusta el plan
3. Si se requiere cambio de arquitectura → consulta a Bulma
4. Si hay conflicto de prioridades → Erwin decide
### 5.3 Comunicación Entre Agentes
- **Agente → Agente**: Formato libre para consulta/coordinación
- **Agente → Erwin**: Formato estructurado con estado, bloqueo, solicitud
- **Erwin → Agente**: Órdenes claras con contexto y expectativa
## 6. Estados y Transiciones
```
┌─────────────┐
│ PENDIENTE │ (Misión creada)
└──────┬──────┘
│ Erwin la approve y asigna
▼
┌─────────────┐
┌─────│ EN PROGRESO │─────┐
│ └─────────────┘ │
Bloqueo │ Todas subtareas completadas
│ │
▼ ▼
┌──────────┐ ┌───────────┐
│ BLOQUEADA│ │ COMPLETADA│
└──────────┘ └───────────┘
│ ▲
Erwin resuelve │
└─────────────────────────┘
```
## 7. Métricas del Sistema
- Tiempo promedio de resolución por tipo de tarea
- Tasa de bloqueo por agente
- Carga de trabajo por agente (tareas activas)
- Precisión de estimaciones vs tiempo real
## 8. Integraciones Futuras (Opcional)
- Bot de Telegram para crear/monitorear misiones
- Hooks de Gitea para automatizar estados
- API REST para herramientas externas
- Dashboard web para visualización
---
*Documento creado como parte del proyecto Control de Misión*
*Fecha: 2026-03-27*

38
docs/agentes/PERFIL.md Normal file
View File

@@ -0,0 +1,38 @@
# Agente: [NOMBRE]
## Identidad
- **Rol**: [Rol principal]
- **Reporta a**: [A quién reporta]
- **Delegado por**: [Quién le delega]
- **Emoji distintivo**: [Emoji]
## Capacidades
- [Capacidad 1]
- [Capacidad 2]
- [Capacidad N]
## Limitaciones
- [Limitación 1]
- [Limitación 2]
## Protocolo de Comunicación
- **Recibe tareas de**: [Agente(s)]
- **Envía resultados a**: [Agente(s)]
- **Formato preferido**: [ markdown / structured / libre ]
## Interacciones Típicas
1. [Recibir tarea] → [Procesar] → [Entregar resultado]
2. [Recibir consulta] → [Analizar] → [Responder]
## Métricas
- Tiempo promedio por tarea tipo:
- Tasa de bloqueo:
## Historial de Misiones
| Fecha | Misión | Resultado | Tiempo |
|-------|--------|-----------|--------|
| - | - | - | - |
---
*Completar con datos reales del agente*

100
docs/comunicacion/proTOCOLO.md Normal file
View File

@@ -0,0 +1,100 @@
# Protocolo de Comunicación entre Agentes
## 1. Principios Fundamentales
1. **Claridad**: Cada mensaje debe tener intención clara (pedir, informar, decidir)
2. **Contexto**: Incluir información relevante para que el receptor pueda actuar
3. **Trazabilidad**: Guardar las comunicaciones importantes en documentación
4. **Brevedad**: Ir al punto, evitar información innecesaria
## 2. Formato de Mensajes
### 2.1 Formato Estructurado (para reportes a Erwin)
```
## [TIPO] | De: [Agente] | Para: [Destinatario]
**Asunto**: [Título claro]
**Estado**: [OK / Bloqueado / Completado]
**Contexto**: [Qué está pasando]
**Acción requerida**: [Solo si necesita respuesta]
**Próximo paso**: [Si hay seguimiento]
---
Timestamp: [YYYY-MM-DD HH:MM]
```
### 2.2 Formato Libre (entre agentes)
```
**De [Agente] → [Agente]**: [Mensaje directo]
[Contenido]
```
## 3. Tipos de Comunicación
| Tipo | De | Para | Ejemplo |
|------|----|----|---------|
| Asignación | Erwin | [Agente] | "Rocket: implementa feature X" |
| Consulta | [Agente] | [Agente] | "Bulma: ¿正当 su arquitectura para Y?" |
| Reporte | [Agente] | Erwin | "Completado: feature X" |
| Escalamiento | [Agente] | Erwin | "Bloqueado: necesito decisión sobre Z" |
| Revisión | Erwin | Sherlock | "Revisa la implementación de X" |
## 4. Reglas de Respuesta
- **Asignación**: Confirmar recibo + tiempo estimado (si no es obvio)
- **Consulta**: Responder en mismo hilo, máximo 3 intercambios
- **Reporte**: Erwin confirma recepción
- **Escalamiento**: Erwin responde en prioridad
## 5. Canales
1. **Directo (OpenClaw)**: Para comunicación inmediata
2. **Documentación (repo)**: Para decisiones y resultados formales
3. **Cola de tareas**: Para asignaciones asíncronas
## 6. Escalamiento
```
Agente detecta problema
│
▼
¿Puede resolverlo solo? ──Sí──→ Resuelve y documenta
│
No
│
▼
Informa a Erwin con:
- Qué pasó
- Qué intentó
- Qué necesita para continuar
│
▼
Erwin decide:
- Reasigna
- Cambia enfoque
- Provee recursos/decisión
```
## 7. Timeouts
| Situación | Timeout | Acción |
|-----------|---------|--------|
| Asignación sin confirmación | 5 min | Reenviar |
| Consulta sin respuesta | 15 min | Escalar a Erwin |
| Tarea asignada sin progreso | 1h | Check-in con agente |
| Bloqueo sin resolución | 30 min | Erwin interviene |
## 8. Best Practices
- ✅ Siempre confirmar cuando recibes una asignación
- ✅ Informar a Erwin de bloqueos inmediatamente
- ✅ Documentar decisiones importantes en el repo
- ✅ Mantener los mensajes enfocados en una sola cosa
- ❌ No dejar mensajes sin respuesta por más de 1h
- ❌ No escalar sin antes intentar resolver
---
*Protocolo v1.0 — Control de Misión*

95
docs/workflow/flujo-estandar.md Normal file
View File

@@ -0,0 +1,95 @@
# Workflow Estándar
Flujo completo para misiones de complejidad media/alta.
## Fases
```
┌─────────────────────────────────────────────────────────────────────┐
│ FASE 1: DEFINICIÓN (Erwin) │
├─────────────────────────────────────────────────────────────────────┤
│ 1.1 Recibir solicitud de misión │
│ 1.2 Definir objetivo claro │
│ 1.3 Identificar restricciones y contexto │
│ 1.4 Asignar ID de misión │
│ 1.5 Crear documento de misión │
└──────────────────────────────┬──────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────────┐
│ FASE 2: ANÁLISIS (Bulma) │
├─────────────────────────────────────────────────────────────────────┤
│ 2.1 Analizar requisitos técnicos │
│ 2.2 Diseñar arquitectura/solución conceptual │
│ 2.3 Identificar riesgos técnicas │
│ 2.4 Proponer descomposición en subtareas │
│ 2.5 Documentar decisión de diseño │
└──────────────────────────────┬──────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────────┐
│ FASE 3: IMPLEMENTACIÓN (Rocket) │
├─────────────────────────────────────────────────────────────────────┤
│ 3.1 Recibir especificación de Bulma │
│ 3.2 Implementar código │
│ 3.3 Tests unitarios básicos │
│ 3.4 Documentar decisiones de implementación │
│ 3.5 Reportar a Erwin con resultado/link │
└──────────────────────────────┬──────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────────┐
│ FASE 4: UI/UX (Hiro) [opcional, si aplica] │
├─────────────────────────────────────────────────────────────────────┤
│ 4.1 Diseñar interfaz según specs │
│ 4.2 Obtener feedback de usuario (si disponible) │
│ 4.3 Ajustar diseño │
│ 4.4 Entregar specs a Rocket o documentación │
└──────────────────────────────┬──────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────────┐
│ FASE 5: REVISIÓN (Sherlock) │
├─────────────────────────────────────────────────────────────────────┤
│ 5.1 Recibir entregable │
│ 5.2 Revisar código/documentación/diseño │
│ 5.3 Probar funcionalidad │
│ 5.4 Documentar hallazgos │
│ 5.5 Si hay problemas → volver a fase correspondiente │
│ 5.6 Si está OK → aprobar │
└──────────────────────────────┬──────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────────┐
│ FASE 6: DOCUMENTACIÓN (Claudia) │
├─────────────────────────────────────────────────────────────────────┤
│ 6.1 Recopilar toda la información de la misión │
│ 6.2 Estructurar documentación final │
│ 6.3 Actualizar índices del repo │
│ 6.4 Archivar misión como completada │
└─────────────────────────────────────────────────────────────────────┘
```
## Roles por Fase
| Fase | Agente Principal | Support |
|------|-----------------|---------|
| Definición | Erwin | - |
| Análisis | Bulma | Erwin, Sherlock (review técnico) |
| Implementación | Rocket | Bulma (consultas) |
| UI/UX | Hiro | Rocket (integración), Erwin (feedback) |
| Revisión | Sherlock | Bulma, Rocket |
| Documentación | Claudia | Todos |
## Criterios de Avance
- Para pasar de fase se requiere:
- Entregable completo según criterios definidos
- Aprobación del agente de fase (o de Erwin si hay conflicto)
- Documentación actualizada
## Indicadores de Bloqueo
- Fase sin progreso en >2h (en horario activo)
- Agente reporta uncertainty
- Conflicto entre dos agentes
- Cambio de requisitos sin notificación
---
*Workflow v1.0 — Control de Misión*

101
ejemplos/ejemplo-mision.md Normal file
View File

@@ -0,0 +1,101 @@
# Ejemplo de Misión Completa
## Misión: Migrar sistema de autenticación a OAuth2
```yaml
id: MISION-2026-001
nombre: Migrar sistema de autenticación a OAuth2
descripcion: |
El sistema actual usa autenticación básica con usuario/contraseña.
Necesitamos migrar a OAuth2 para mejorar seguridad y permitir
integración con proveedores externos (Google, GitHub).
prioridad: alta
creada_por: Erwin
creada_en: 2026-03-27T10:00:00Z
deadline: 2026-04-10T23:59:59Z
estado: completada
subtareas:
- id: ST-001
nombre: Análisis de arquitectura OAuth2
asignada_a: Bulma
estado: completada
resultado: doc/oauth2-arquitectura.md creado
- id: ST-002
nombre: Implementar provider OAuth2 con Passport.js
asignada_a: Rocket
estado: completada
resultado: src/auth/oauth2/ - 3 archivos
- id: ST-003
nombre: Diseñar pantalla de login
asignada_to: Hiro
estado: completada
resultado: mockups/login-oauth.fig
- id: ST-004
nombre: Revisar código de seguridad
asignada_to: Sherlock
estado: completada
resultado: 2 hallazgos menores, corregidos
- id: ST-005
nombre: Documentar proceso de deployment
asignada_to: Claudia
estado: completada
resultado: docs/deployment-oauth2.md
```
## Línea de Tiempo
| Fecha | Hora | Agente | Acción |
|-------|------|--------|--------|
| 2026-03-27 | 10:00 | Erwin | Crea misión, asigna a Bulma |
| 2026-03-27 | 14:30 | Bulma | Entrega análisis, asigna a Rocket |
| 2026-03-28 | 11:00 | Rocket | Implementa provider básico |
| 2026-03-28 | 15:00 | Hiro | Entrega mockups |
| 2026-03-29 | 09:00 | Sherlock | Inicia revisión |
| 2026-03-29 | 16:00 | Sherlock | Reporta hallazgos menores |
| 2026-03-30 | 10:00 | Rocket | Corrige hallazgos |
| 2026-03-30 | 14:00 | Sherlock | Aprueba |
| 2026-03-30 | 17:00 | Claudia | Documenta todo |
## Comunicación Registrada
### 2026-03-27 | Bulma → Erwin
```
Estado: OK
Contexto: Analicé los requisitos de OAuth2.
Hay 3 opciones: Passport.js, Auth0, o implementación custom.
Recomendación: Passport.js (balance costo flexibidad).
Próximo paso: Espero aprobación para proceder con ST-001.
```
### 2026-03-29 | Sherlock → Erwin
```
Estado: Bloqueado (menor)
Contexto: Encontré 2 hallazgos en el código:
1. Token refresh no implementa rotación
2. Falta validación de redirect_uri
Severidad: Media
Recomendación: Corregir antes de merge.
Acción requerida: Rocket necesita hacer fix.
```
### 2026-03-30 | Rocket → Sherlock
```
Corregidos ambos hallazgos. Código en branch fix/oauth-tokens.
Por favor revisa de nuevo.
```
## Resultado Final
✅ Misión completada en 3 días
⏱ Tiempo real: ~24h de trabajo distribuido
📝 Documentación: Completa
🔒 Seguridad: Aprobada por Sherlock
---
*Ejemplo v1.0 — Control de Misión*