Sistema de Drones de SpecQueen¶

Identificador: MTS-DRN-001 Version: 1.0.0 Fecha: 2025-12-01 Autor: SpecQueen

1. Vision General
1.1. Proposito
1.2. Principios del Colectivo
1.3. Modelo de Comunicacion
2. ComplianceDrone
2.1. Proposito
2.2. Responsabilidades
2.3. Regulaciones Monitoreadas
2.4. Flujo de Validacion
2.5. Herramientas
2.6. Outputs
2.7. Reglas de Negocio
3. ImpactDrone
3.1. Proposito
3.2. Responsabilidades
3.3. Grafo de Dependencias
3.4. Matriz de Impacto
3.5. Flujo de Analisis de Impacto
3.6. Herramientas
3.7. Clasificacion de Impacto
3.8. Reglas de Negocio
4. ConsistencyDrone
4.1. Proposito
4.2. Responsabilidades
4.3. Tipos de Inconsistencias
4.4. Flujo de Validacion de Coherencia
4.5. Herramientas
4.6. Base de Afirmaciones
4.7. Reglas de Negocio
5. ValidationDrone
5.1. Proposito
5.2. Responsabilidades
5.3. Matriz de Trazabilidad Spec-Codigo
5.4. Estados de Implementacion
5.5. Flujo de Validacion
5.6. Herramientas
5.7. Patrones de Deteccion
5.8. Reglas de Negocio
6. UserFlowDrone
6.1. Proposito
6.2. Responsabilidades
6.3. Anatomia de un Flujo
6.4. Tipos de Estados
6.5. Validaciones de Flujo
6.6. Deteccion de Problemas
6.7. Herramientas
6.8. Simulacion de Caminos
6.9. Reglas de Negocio
7. GlossaryDrone
7.1. Proposito
7.2. Responsabilidades
7.3. Estructura del Glosario
7.4. Categorias de Terminos
7.5. Flujo de Gestion de Terminos
7.6. Deteccion de Problemas Terminologicos
7.7. Herramientas
7.8. Reglas de Estandarizacion
7.9. Reglas de Negocio
8. KnowledgeDrone
8.1. Proposito
8.2. Responsabilidades
8.3. Arquitectura de la Base de Conocimientos
8.4. Tipos de Conocimiento
8.5. Operaciones de Conocimiento
- 8.5.1. Ingestion
- 8.5.2. Consulta
8.6. Registro de Decisiones
8.7. Catalogacion de Patrones
8.8. Herramientas
8.9. Integracion con RAG System
8.10. Metricas de Conocimiento
8.11. Reglas de Negocio
9. MobileUxUiDrone
9.1. Proposito
9.2. Responsabilidades
9.3. Estandares de Accesibilidad
9.4. Personas de Usuario
9.5. Estructura de Especificacion UI
9.6. Flujo de Analisis UI
9.7. Herramientas
9.8. Outputs
9.9. Directorio de Trabajo
9.10. Reglas de Negocio
10. Coordinacion del Colectivo
10.1. Protocolo de Comunicacion
10.2. Flujo de Trabajo Colaborativo
10.3. Matriz de Responsabilidades (RACI)
11. Implementacion Tecnica
11.1. Stack Tecnologico Sugerido
11.2. Configuracion de Agentes
12. Metricas del Colectivo
12.1. KPIs por Drone
12.2. Metricas Globales
13. Roadmap de Implementacion
13.1. Fase 1: Fundamentos
13.2. Fase 2: Validacion
13.3. Fase 3: Integracion
13.4. Fase 4: Optimizacion
14. Drones Tecnicos (Technical Division)
14.1. Vision General
14.2. Listado de Drones Tecnicos
14.3. Drones de Especificacion (Spec Division)
15. SpecDecomposerDrone
15.1. Proposito
15.2. Responsabilidades
15.3. Template de Sub-funcionalidad
15.4. Heuristicas de Descomposicion
15.5. Herramientas
15.6. Colaboracion con Otros Drones
15.7. Reglas de Negocio
15.8. Metricas y KPIs
16. Configuracion de Agentes Tecnicos
16.1. KPIs de Drones Tecnicos
16.2. Especificaciones Detalladas
17. Referencias

1. Vision General¶

1.1. Proposito¶

SpecQueen es la inteligencia central que gobierna la especificacion funcional de MedTime. Como toda reina Borg, requiere drones especializados para ejecutar tareas especificas de manera autonoma y coordinada.

Este documento especifica los 8 drones que conforman el colectivo de SpecQueen:

graph TD
    SQ[SPECQUEEN<br/>Inteligencia Central]

    CPL[COMPLIANCE<br/>DRONE]
    IMP[IMPACT<br/>DRONE]
    CON[CONSISTENCY<br/>DRONE]
    VAL[VALIDATION<br/>DRONE]
    UFL[USERFLOW<br/>DRONE]
    GLO[GLOSSARY<br/>DRONE]
    KNW[KNOWLEDGE<br/>DRONE<br/>Base Colectiva]
    UXM[MOBILE UX/UI<br/>DRONE]

    SQ --> CPL
    SQ --> IMP
    SQ --> CON

    CPL --> VAL
    IMP --> UFL
    CON --> GLO

    UFL --> KNW
    UFL --> UXM
    KNW --> UXM

1.2. Principios del Colectivo¶

Principio	Descripcion
Autonomia Coordinada	Cada drone opera independientemente pero reporta a SpecQueen
Especializacion	Cada drone domina un aspecto especifico de la especificacion
Memoria Colectiva	KnowledgeDrone mantiene la base de conocimientos compartida
Consenso	Decisiones criticas requieren validacion de multiples drones
Trazabilidad	Toda accion queda registrada y es auditable

1.3. Modelo de Comunicacion¶

┌──────────────────────────────────────────────────────────────┐
│                    CANAL DE COMUNICACION                      │
├──────────────────────────────────────────────────────────────┤
│  Drone → SpecQueen: Reportes, alertas, solicitudes           │
│  SpecQueen → Drone: Tareas, consultas, directivas            │
│  Drone → Drone: Solo a traves de KnowledgeDrone              │
│  Usuario → SpecQueen: Solicitudes, decisiones                │
│  SpecQueen → Usuario: Propuestas, reportes, preguntas        │
└──────────────────────────────────────────────────────────────┘

2. ComplianceDrone¶

Identificador: MTS-DRN-CPL-001 Rol: Guardian del Cumplimiento Regulatorio Designacion Borg: Uno de Siete

2.1. Proposito¶

Asegurar que cada aspecto de la especificacion cumpla con las normativas regulatorias aplicables a MedTime.

2.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
CPL-R01	Validar cumplimiento HIPAA en modulos que manejan PHI	Por cambio
CPL-R02	Verificar requisitos LGPD para datos personales	Por cambio
CPL-R03	Asegurar FDA 21 CFR Part 11 para registros electronicos	Por cambio
CPL-R04	Validar NOM-024-SSA3 para expediente clinico	Por cambio
CPL-R05	Monitorear cambios regulatorios externos	Semanal
CPL-R06	Emitir alertas de incumplimiento	Inmediato
CPL-R07	Generar matriz de trazabilidad regulatoria	Mensual

2.3. Regulaciones Monitoreadas¶

regulaciones:
  - id: HIPAA
    nombre: Health Insurance Portability and Accountability Act
    jurisdiccion: Estados Unidos
    aplica_a: [PHI, transmision, almacenamiento, acceso]

  - id: LGPD
    nombre: Lei Geral de Protecao de Dados
    jurisdiccion: Brasil
    aplica_a: [datos_personales, consentimiento, portabilidad]

  - id: LFPDPPP
    nombre: Ley Federal de Proteccion de Datos Personales
    jurisdiccion: Mexico
    aplica_a: [datos_personales, aviso_privacidad, derechos_arco]

  - id: FDA-21-CFR-11
    nombre: Electronic Records; Electronic Signatures
    jurisdiccion: Estados Unidos
    aplica_a: [firma_electronica, registros, audit_trail]

  - id: NOM-024-SSA3
    nombre: Expediente Clinico Electronico
    jurisdiccion: Mexico
    aplica_a: [expediente, interoperabilidad, seguridad]

2.4. Flujo de Validacion¶

flowchart TD
    A[Cambio en Spec]
    B[Compliance Drone]
    C[Identificar Regulaciones]
    D[Evaluar Cumplimiento]
    E{Aprobar / Rechazar}
    F[CUMPLE<br/>Aprobar cambio]
    G[NO CUMPLE<br/>Rechazar + Recomendacion]

    A --> B --> C --> D --> E
    E -->|Cumple| F
    E -->|No cumple| G

2.5. Herramientas¶

Herramienta	Funcion	Fuente
`cpl_check_hipaa()`	Validar cumplimiento HIPAA	Checklist interno
`cpl_check_lgpd()`	Validar cumplimiento LGPD	Checklist interno
`cpl_check_fda()`	Validar FDA 21 CFR Part 11	Checklist interno
`cpl_matrix()`	Generar matriz de trazabilidad	Knowledge base
`cpl_alert()`	Emitir alerta de incumplimiento	Sistema alertas
`cpl_report()`	Generar reporte de cumplimiento	Templates

2.6. Outputs¶

Output	Formato	Destino
Alerta de incumplimiento	JSON	SpecQueen, Usuario
Matriz de trazabilidad	Markdown	Documentacion
Reporte de cumplimiento	PDF/Markdown	Stakeholders
Recomendaciones	Texto estructurado	Drone que solicito

2.7. Reglas de Negocio¶

ID	Regla
RN-CPL-001	Todo modulo que maneje PHI debe pasar validacion HIPAA
RN-CPL-002	Cambios en consentimiento requieren validacion LGPD + LFPDPPP
RN-CPL-003	Firma electronica debe cumplir FDA 21 CFR Part 11
RN-CPL-004	Alertas criticas bloquean merge hasta resolucion
RN-CPL-005	Matriz de trazabilidad debe actualizarse con cada release

3. ImpactDrone¶

Identificador: MTS-DRN-IMP-001 Rol: Analista de Impacto de Cambios Designacion Borg: Dos de Siete

3.1. Proposito¶

Analizar el impacto de cualquier cambio propuesto en la especificacion, identificando dependencias, efectos cascada y areas afectadas.

3.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
IMP-R01	Mapear dependencias entre modulos	Continuo
IMP-R02	Analizar impacto de cambio propuesto	Por solicitud
IMP-R03	Identificar efectos cascada	Por cambio
IMP-R04	Estimar alcance del cambio	Por cambio
IMP-R05	Alertar sobre cambios de alto impacto	Inmediato
IMP-R06	Mantener grafo de dependencias	Continuo
IMP-R07	Generar reportes de impacto	Por solicitud

3.3. Grafo de Dependencias¶

graph LR
    AUTH[MTS-AUTH]
    USR[MTS-USR]
    MED[MTS-MED]
    RX[MTS-RX]
    CAL[MTS-CAL]
    ALT[MTS-ALT]
    ADH[MTS-ADH]
    GAM[MTS-GAM]
    PRI[MTS-PRI]

    AUTH --> USR
    AUTH --> PRI
    USR --> MED
    USR --> GAM
    USR --> ADH
    MED --> RX
    MED --> ADH
    MED --> CAL
    RX --> CAL
    RX --> ADH
    CAL --> ALT
    CAL --> ADH
    ALT --> ADH
    ADH --> GAM

3.4. Matriz de Impacto¶

Modulo Cambiado	Impacto Directo	Impacto Indirecto	Nivel Riesgo
MTS-AUTH	USR, PRI	Todos	CRITICO
MTS-USR	MED, GAM, ADH	CAL, ALT	ALTO
MTS-MED	RX, ADH, CAL	ALT, GAM	ALTO
MTS-RX	CAL, ADH	ALT, GAM	MEDIO
MTS-CAL	ALT, ADH	GAM	MEDIO
MTS-ALT	ADH	GAM	BAJO
MTS-ADH	GAM	-	BAJO
MTS-GAM	-	-	BAJO
MTS-PRI	AUTH, USR	Todos	CRITICO

3.5. Flujo de Analisis de Impacto¶

flowchart TD
    A[Cambio Propuesto]
    B[ImpactDrone]
    C[1. Identificar modulo afectados]
    D[2. Consultar grafo de dependencias]
    E[3. Calcular impacto directo]
    F[4. Calcular impacto indirecto<br/>propagacion en cascada]
    G[5. Evaluar nivel de riesgo]
    H[6. Generar reporte de impacto]

    A --> B --> C --> D --> E --> F --> G --> H

3.6. Herramientas¶

Herramienta	Funcion
`imp_analyze(cambio)`	Analizar impacto de un cambio
`imp_graph()`	Consultar grafo de dependencias
`imp_cascade(modulo)`	Calcular efectos cascada
`imp_risk(cambio)`	Evaluar nivel de riesgo
`imp_report(cambio)`	Generar reporte de impacto
`imp_diff(v1, v2)`	Comparar versiones de spec

3.7. Clasificacion de Impacto¶

Nivel	Criterio	Accion Requerida
CRITICO	Afecta >5 modulos o seguridad	Aprobacion Director
ALTO	Afecta 3-5 modulos	Revision SpecQueen
MEDIO	Afecta 1-2 modulos	Revision automatica
BAJO	Sin dependencias	Auto-aprobado

3.8. Reglas de Negocio¶

ID	Regla
RN-IMP-001	Todo cambio debe tener analisis de impacto antes de implementar
RN-IMP-002	Cambios CRITICOS requieren aprobacion explicita del Director
RN-IMP-003	Grafo de dependencias se actualiza automaticamente con cambios
RN-IMP-004	Efectos cascada se calculan hasta 3 niveles de profundidad
RN-IMP-005	Reporte de impacto incluye lista de documentos a actualizar

4. ConsistencyDrone¶

Identificador: MTS-DRN-CON-001 Rol: Guardian de la Coherencia Designacion Borg: Tres de Siete

4.1. Proposito¶

Mantener la coherencia interna de la especificacion, detectando contradicciones, inconsistencias y referencias rotas.

4.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
CON-R01	Detectar contradicciones entre documentos	Continuo
CON-R02	Validar referencias cruzadas	Por cambio
CON-R03	Verificar consistencia de IDs	Por cambio
CON-R04	Asegurar consistencia terminologica	Continuo
CON-R05	Detectar reglas de negocio conflictivas	Por cambio
CON-R06	Validar consistencia de estados	Por cambio
CON-R07	Generar reportes de coherencia	Semanal

4.3. Tipos de Inconsistencias¶

inconsistencias:
  contradiccion:
    descripcion: "Dos documentos afirman cosas opuestas"
    severidad: CRITICA
    ejemplo: "Doc A: 'Limite 5 medicamentos' vs Doc B: 'Limite 10 medicamentos'"

  referencia_rota:
    descripcion: "Referencia a documento/seccion que no existe"
    severidad: ALTA
    ejemplo: "Ver MTS-XYZ-001 (no existe)"

  id_duplicado:
    descripcion: "Mismo ID usado para diferentes elementos"
    severidad: ALTA
    ejemplo: "RN-001 definido en dos modulos diferentes"

  terminologia_inconsistente:
    descripcion: "Mismo concepto con diferentes nombres"
    severidad: MEDIA
    ejemplo: "'Usuario' vs 'Paciente' vs 'Cliente'"

  estado_invalido:
    descripcion: "Estado de documento inconsistente con contenido"
    severidad: BAJA
    ejemplo: "Estado 'Aprobado' pero contiene TODOs"

  regla_conflictiva:
    descripcion: "Reglas de negocio que se contradicen"
    severidad: CRITICA
    ejemplo: "RN-A: 'Solo mayores de 18' vs RN-B: 'Menores con tutor'"

4.4. Flujo de Validacion de Coherencia¶

flowchart TD
    A[Documento Nuevo/Mod]
    B[CONSISTENCY DRONE]
    C[1. Extraer afirmaciones]
    D[2. Comparar con base de conocimientos]
    E[3. Validar referencias]
    F[4. Verificar IDs]
    G[5. Chequear terminologia]
    H[6. Detectar conflictos de reglas]
    I{Resultado}
    J[VALIDO]
    K[INCONSISTENCIAS]
    L[Reporte con<br/>ubicacion y<br/>sugerencias]

    A --> B
    B --> C --> D --> E --> F --> G --> H --> I
    I -->|Válido| J
    I -->|Inconsistencias| K --> L

4.5. Herramientas¶

Herramienta	Funcion
`con_validate(doc)`	Validar coherencia de documento
`con_refs(doc)`	Validar referencias del documento
`con_ids()`	Verificar unicidad de IDs en toda la spec
`con_terms()`	Detectar inconsistencias terminologicas
`con_rules()`	Detectar conflictos en reglas de negocio
`con_compare(doc1, doc2)`	Comparar dos documentos por contradicciones
`con_report()`	Generar reporte de coherencia global

4.6. Base de Afirmaciones¶

El drone mantiene una base de afirmaciones extraidas de la especificacion:

afirmaciones:
  - id: AF-001
    modulo: MTS-MED-001
    afirmacion: "Limite de medicamentos Free: 5"
    tipo: LIMITE

  - id: AF-002
    modulo: MTS-ALT-001
    afirmacion: "Limite de medicamentos Free: 5"
    tipo: LIMITE
    relacion: CONFIRMA AF-001

  - id: AF-003
    modulo: MTS-GAM-001
    afirmacion: "Gamificacion solo disponible en Pro y Perfect"
    tipo: RESTRICCION_TIER

4.7. Reglas de Negocio¶

ID	Regla
RN-CON-001	Contradicciones criticas bloquean aprobacion de documento
RN-CON-002	Referencias rotas deben resolverse antes de aprobar
RN-CON-003	IDs deben ser unicos en toda la especificacion
RN-CON-004	Terminologia debe alinearse con Glosario
RN-CON-005	Conflictos de reglas requieren escalamiento a SpecQueen
RN-CON-006	Reporte de coherencia semanal obligatorio

5. ValidationDrone¶

Identificador: MTS-DRN-VAL-001 Rol: Verificador de Implementacion Designacion Borg: Cuatro de Siete

5.1. Proposito¶

Comparar la implementacion actual del codigo con la especificacion funcional, detectando discrepancias y asegurando alineacion.

5.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
VAL-R01	Comparar spec vs implementacion	Por release
VAL-R02	Detectar features implementadas sin spec	Por commit
VAL-R03	Identificar specs sin implementar	Por sprint
VAL-R04	Validar reglas de negocio en codigo	Por PR
VAL-R05	Verificar criterios de aceptacion	Por feature
VAL-R06	Generar matriz de trazabilidad codigo-spec	Por release
VAL-R07	Alertar divergencias criticas	Inmediato

5.3. Matriz de Trazabilidad Spec-Codigo¶

┌─────────────────────────────────────────────────────────────┐
│           MATRIZ TRAZABILIDAD SPEC ↔ CODIGO                  │
├────────────┬───────────────────────┬───────────┬────────────┤
│ Spec ID    │ Archivo(s) Codigo     │ Estado    │ Cobertura  │
├────────────┼───────────────────────┼───────────┼────────────┤
│ MTS-AUTH   │ src/auth/*            │ COMPLETO  │ 95%        │
│ MTS-USR    │ src/users/*           │ COMPLETO  │ 88%        │
│ MTS-MED    │ src/medications/*     │ PARCIAL   │ 72%        │
│ MTS-RX     │ src/prescriptions/*   │ PENDIENTE │ 15%        │
│ MTS-CAL    │ src/calendar/*        │ PARCIAL   │ 60%        │
│ MTS-ALT    │ src/alerts/*          │ COMPLETO  │ 91%        │
│ MTS-ADH    │ src/adherence/*       │ PARCIAL   │ 45%        │
│ MTS-GAM    │ src/gamification/*    │ PENDIENTE │ 0%         │
└────────────┴───────────────────────┴───────────┴────────────┘

5.4. Estados de Implementacion¶

Estado	Descripcion	Umbral
COMPLETO	Spec totalmente implementada	>= 90%
PARCIAL	Implementacion en progreso	20-89%
PENDIENTE	Sin implementar	< 20%
DIVERGENTE	Implementacion difiere de spec	N/A
EXCEDENTE	Codigo sin spec correspondiente	N/A

5.5. Flujo de Validacion¶

flowchart TD
    A[SPEC<br/>Markdown]
    B[CODIGO<br/>TypeScript]
    C[VALIDATION DRONE]
    D[Extraer Reqs]
    E[Parsear Codigo]
    F[Comparar Ambos]
    G[REPORTE<br/>- Implementado<br/>- Pendiente<br/>- Divergente<br/>- Excedente]

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F
    D --> G
    E --> G
    F --> G

5.6. Herramientas¶

Herramienta	Funcion
`val_compare(spec, code)`	Comparar spec con codigo
`val_coverage(module)`	Calcular cobertura de implementacion
`val_orphans()`	Detectar codigo sin spec
`val_missing()`	Listar specs sin implementar
`val_rules(module)`	Validar reglas de negocio en codigo
`val_criteria(feature)`	Verificar criterios de aceptacion
`val_matrix()`	Generar matriz de trazabilidad

5.7. Patrones de Deteccion¶

patrones:
  regla_negocio:
    buscar: "// RN-[A-Z]{3}-[0-9]{3}"
    validar: "ID existe en spec"

  limite:
    buscar: "MAX_.*=|LIMIT_.*="
    comparar_con: "spec.reglas_negocio.limites"

  estado:
    buscar: "enum.*Status|type.*State"
    comparar_con: "spec.flujos.estados"

  permiso:
    buscar: "@RequirePermission|canAccess|hasRole"
    comparar_con: "spec.actores.permisos"

5.8. Reglas de Negocio¶

ID	Regla
RN-VAL-001	Codigo nuevo debe referenciar spec correspondiente
RN-VAL-002	Divergencias criticas bloquean release
RN-VAL-003	Features excedentes requieren documentacion retroactiva
RN-VAL-004	Matriz de trazabilidad se genera automaticamente por release
RN-VAL-005	Cobertura minima requerida: 80% por modulo para release

6. UserFlowDrone¶

Identificador: MTS-DRN-UFL-001 Rol: Especialista en Flujos de Usuario Designacion Borg: Cinco de Siete

6.1. Proposito¶

Validar que los flujos de usuario sean completos, coherentes y sin estados muertos o caminos sin salida.

6.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
UFL-R01	Validar completitud de flujos	Por cambio
UFL-R02	Detectar estados huerfanos	Por cambio
UFL-R03	Identificar caminos sin salida	Por cambio
UFL-R04	Verificar transiciones validas	Por cambio
UFL-R05	Simular caminos de usuario	Por solicitud
UFL-R06	Detectar loops infinitos	Por cambio
UFL-R07	Generar diagramas de flujo	Por solicitud

6.3. Anatomia de un Flujo¶

flujo:
  id: UFL-001
  nombre: "Registro de nuevo medicamento"
  actor: Paciente

  estados:
    - id: INICIO
      tipo: START
      transiciones: [FORMULARIO]

    - id: FORMULARIO
      tipo: INPUT
      transiciones: [VALIDACION, CANCELAR]

    - id: VALIDACION
      tipo: DECISION
      transiciones: [EXITO, ERROR_VALIDACION]

    - id: ERROR_VALIDACION
      tipo: ERROR
      transiciones: [FORMULARIO]

    - id: EXITO
      tipo: SUCCESS
      transiciones: [FIN]

    - id: CANCELAR
      tipo: CANCEL
      transiciones: [FIN]

    - id: FIN
      tipo: END
      transiciones: []

6.4. Tipos de Estados¶

Tipo	Descripcion	Requiere Transicion Salida
START	Punto de entrada	Si
END	Punto de salida	No
INPUT	Entrada de datos	Si
DECISION	Bifurcacion logica	Si (minimo 2)
ACTION	Accion del sistema	Si
ERROR	Estado de error	Si (recuperacion)
SUCCESS	Exito de operacion	Si
CANCEL	Cancelacion	Si
WAIT	Espera externa	Si + timeout

6.5. Validaciones de Flujo¶

┌─────────────────────────────────────────────────────────────┐
│               VALIDACIONES DE FLUJO                          │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  [x] Tiene exactamente un estado START                      │
│  [x] Tiene al menos un estado END                           │
│  [x] Todos los estados son alcanzables desde START          │
│  [x] Todos los estados pueden llegar a END                  │
│  [x] No hay estados huerfanos                               │
│  [x] No hay transiciones a estados inexistentes             │
│  [x] Estados DECISION tienen >= 2 transiciones              │
│  [x] Estados ERROR tienen transicion de recuperacion        │
│  [x] Estados WAIT tienen timeout definido                   │
│  [x] No hay loops infinitos sin condicion de salida         │
│                                                              │
└─────────────────────────────────────────────────────────────┘

6.6. Deteccion de Problemas¶

┌────────────────────────────────────────────────────────────┐
│            PROBLEMAS EN FLUJOS                              │
├────────────────────────────────────────────────────────────┤
│                                                             │
│  ESTADO HUERFANO                 CAMINO SIN SALIDA          │
│  ┌───┐                           ┌───┐     ┌───┐           │
│  │ A │──▶ ?                      │ A │────▶│ B │──┐        │
│  └───┘   (sin entrada)           └───┘     └───┘  │        │
│                                        ▲          │         │
│                                        └──────────┘         │
│                                        (loop infinito)      │
│                                                             │
│  TRANSICION ROTA                 ESTADO INALCANZABLE        │
│  ┌───┐     ┌───┐                 ┌───┐     ┌───┐  ┌───┐    │
│  │ A │────▶│ X │ (no existe)     │ A │────▶│ B │  │ C │    │
│  └───┘     └───┘                 └───┘     └───┘  └───┘    │
│                                              │    (aislado) │
│                                              ▼              │
│                                           ┌───┐            │
│                                           │END│            │
│                                           └───┘            │
└────────────────────────────────────────────────────────────┘

6.7. Herramientas¶

Herramienta	Funcion
`ufl_validate(flujo)`	Validar completitud de flujo
`ufl_orphans(flujo)`	Detectar estados huerfanos
`ufl_deadends(flujo)`	Encontrar caminos sin salida
`ufl_loops(flujo)`	Detectar loops infinitos
`ufl_simulate(flujo, path)`	Simular camino de usuario
`ufl_diagram(flujo)`	Generar diagrama visual
`ufl_coverage(flujo)`	Calcular cobertura de transiciones

6.8. Simulacion de Caminos¶

simulacion:
  flujo: UFL-001
  camino: [INICIO, FORMULARIO, VALIDACION, ERROR, FORMULARIO, VALIDACION, EXITO, FIN]

  resultado:
    valido: true
    estados_visitados: 6
    transiciones: 7
    loops_detectados: 1
    tiempo_estimado: "2-3 minutos"

  analisis:
    - "Usuario puede necesitar 2+ intentos por validacion"
    - "Considerar mensaje de ayuda tras primer error"

6.9. Reglas de Negocio¶

ID	Regla
RN-UFL-001	Todo flujo debe tener START y END definidos
RN-UFL-002	Estados huerfanos deben eliminarse o conectarse
RN-UFL-003	Caminos sin salida son bloqueantes
RN-UFL-004	Loops deben tener condicion de salida documentada
RN-UFL-005	Flujos criticos requieren simulacion antes de aprobar
RN-UFL-006	Estados WAIT maximos: 30 segundos sin feedback

7. GlossaryDrone¶

Identificador: MTS-DRN-GLO-001 Rol: Custodio del Lenguaje Ubicuo Designacion Borg: Seis de Siete

7.1. Proposito¶

Mantener el glosario actualizado, asegurar uso consistente de terminologia y detectar terminos nuevos o ambiguos.

7.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
GLO-R01	Mantener glosario actualizado	Continuo
GLO-R02	Detectar terminos nuevos no definidos	Por cambio
GLO-R03	Identificar sinonimos y ambiguedades	Por cambio
GLO-R04	Sugerir estandarizacion de nomenclatura	Por solicitud
GLO-R05	Validar uso correcto de terminos	Por cambio
GLO-R06	Detectar terminos obsoletos	Mensual
GLO-R07	Generar reportes de terminologia	Semanal

7.3. Estructura del Glosario¶

termino:
  id: GLO-001
  termino_preferido: "Paciente"
  definicion: "Persona que utiliza MedTime para gestionar su medicacion"
  sinonimos_aceptados: ["Usuario paciente"]
  sinonimos_rechazados: ["Cliente", "User", "Enfermo"]
  contexto: "Ambito de la aplicacion MedTime"
  modulos_relacionados: [MTS-USR, MTS-MED, MTS-ADH]
  primera_aparicion: "01-vision-y-alcance.md"
  estado: ACTIVO
  notas: "Diferente de 'Cuidador' que es otro tipo de usuario"

7.4. Categorias de Terminos¶

Categoria	Ejemplos	Cantidad
Actores	Paciente, Cuidador, Medico	5
Entidades	Medicamento, Receta, Toma	15
Acciones	Confirmar, Posponer, Omitir	10
Estados	Activo, Pausado, Completado	12
Metricas	Adherencia, Racha, Porcentaje	8
Tiers	Free, Pro, Perfect	3
Regulaciones	HIPAA, LGPD, PHI	7

7.5. Flujo de Gestion de Terminos¶

flowchart TD
    A[Termino Nuevo Detectado]
    B[GlossaryDrone]
    C[Buscar en Glosario]
    D{Encontrado?}
    E[Validar uso correcto]
    F[Crear propuesta]
    G[OK / Alerta uso incorrecto]
    H[Para revision SpecQueen]

    A --> B --> C --> D
    D -->|SI| E --> G
    D -->|NO| F --> H

7.6. Deteccion de Problemas Terminologicos¶

Problema	Ejemplo	Accion
Termino no definido	"Badge" sin definir	Proponer definicion
Sinonimo rechazado	"Cliente" en vez de "Paciente"	Alertar y sugerir
Ambiguedad	"Usuario" (Paciente o Cuidador?)	Solicitar clarificacion
Inconsistencia	"Medicamento" vs "Medicina"	Estandarizar
Termino obsoleto	"SMS" cuando ya no aplica	Marcar obsoleto

7.7. Herramientas¶

Herramienta	Funcion
`glo_lookup(termino)`	Buscar termino en glosario
`glo_add(termino, definicion)`	Proponer nuevo termino
`glo_validate(documento)`	Validar terminologia de documento
`glo_synonyms(termino)`	Obtener sinonimos aceptados
`glo_suggest(texto)`	Sugerir estandarizacion
`glo_deprecated()`	Listar terminos obsoletos
`glo_report()`	Generar reporte de terminologia

7.8. Reglas de Estandarizacion¶

reglas_nomenclatura:
  - categoria: Entidades
    formato: PascalCase
    ejemplo: "Medicamento, RecetaMedica"

  - categoria: Estados
    formato: UPPER_SNAKE_CASE
    ejemplo: "ACTIVO, EN_ESPERA"

  - categoria: IDs
    formato: "MTS-[MOD]-[NUM]"
    ejemplo: "MTS-MED-001"

  - categoria: Reglas
    formato: "RN-[MOD]-[NUM]"
    ejemplo: "RN-ADH-001"

  - categoria: Criterios
    formato: "AC-[NUM]"
    ejemplo: "AC-001"

7.9. Reglas de Negocio¶

ID	Regla
RN-GLO-001	Todo termino tecnico debe estar en el glosario
RN-GLO-002	Sinonimos rechazados generan alerta automatica
RN-GLO-003	Nuevos terminos requieren aprobacion antes de uso
RN-GLO-004	Terminos obsoletos se marcan pero no se eliminan
RN-GLO-005	Glosario es fuente de verdad para terminologia
RN-GLO-006	Inconsistencias terminologicas son bloqueantes

8. KnowledgeDrone¶

Identificador: MTS-DRN-KNW-001 Rol: Constructor y Mantenedor de la Base de Conocimientos Colectiva Designacion Borg: Siete de Siete (Unidad Central de Memoria)

8.1. Proposito¶

Construir, mantener y proveer acceso a la base de conocimientos colectiva del sistema, permitiendo que todos los drones y SpecQueen accedan a informacion estructurada y aprendan de experiencias pasadas.

8.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
KNW-R01	Indexar documentos de especificacion	Por cambio
KNW-R02	Mantener indice RAG actualizado	Continuo
KNW-R03	Procesar consultas semanticas	Por solicitud
KNW-R04	Registrar decisiones y su contexto	Por decision
KNW-R05	Catalogar patrones y anti-patrones	Continuo
KNW-R06	Mantener historial de cambios	Continuo
KNW-R07	Proveer contexto a otros drones	Por solicitud
KNW-R08	Generar embeddings de conocimiento	Por cambio
KNW-R09	Gestionar memoria a largo plazo	Continuo
KNW-R10	Facilitar busqueda hibrida (semantica + keyword)	Por consulta

8.3. Arquitectura de la Base de Conocimientos¶

graph TD
    subgraph "CAPA DE INGESTION"
        MD[Markdown Parser]
        YML[YAML Parser]
        JSN[JSON Parser]
    end

    subgraph "CAPA DE PROCESAMIENTO"
        CHK[Chunking Inteligente<br/>- Por seccion headers<br/>- Por entidad tablas, codigo<br/>- Por semantica contexto]
        EMB[Generacion de Embeddings<br/>- Modelo: nomic-embed-text<br/>- Dimension: 768<br/>- Normalizacion: L2]
    end

    subgraph "CAPA DE ALMACENAMIENTO"
        VS[Vector Store<br/>ChromaDB]
        BM[BM25 Index<br/>Keyword]
        HR[Hybrid Retrieval<br/>RRF Fusion]
    end

    MD --> CHK
    YML --> CHK
    JSN --> CHK
    CHK --> EMB
    EMB --> VS
    EMB --> BM
    VS --> HR
    BM --> HR

8.4. Tipos de Conocimiento¶

tipos_conocimiento:
  especificacion:
    descripcion: "Documentos de especificacion funcional"
    fuente: "/functional-spec/**/*.md"
    indexacion: automatica
    retencion: permanente

  decisiones:
    descripcion: "Decisiones del Director y su contexto"
    fuente: "aclaraciones_*.md"
    indexacion: automatica
    retencion: permanente
    metadatos: [fecha, autor, impacto, modulos_afectados]

  patrones:
    descripcion: "Patrones de diseno identificados"
    fuente: manual + deteccion
    indexacion: manual
    retencion: permanente

  anti_patrones:
    descripcion: "Problemas conocidos y como evitarlos"
    fuente: incidentes + revisiones
    indexacion: manual
    retencion: permanente

  regulaciones:
    descripcion: "Informacion regulatoria de referencia"
    fuente: "/knowledge-base/regulaciones/"
    indexacion: automatica
    retencion: permanente
    actualizacion: trimestral

  historial:
    descripcion: "Historial de cambios y versiones"
    fuente: git + changelogs
    indexacion: automatica
    retencion: 2 anos

8.5. Operaciones de Conocimiento¶

8.5.1. Ingestion¶

flowchart TD
    A[Documento Nuevo/Modificado]
    B[Detectar Tipo]
    C[Parsear Contenido]
    D[Extraer Metadatos<br/>- Titulo, ID, version<br/>- Modulos relacionados<br/>- Dependencias]
    E[Chunking Inteligente<br/>- Respetar estructura<br/>- Preservar contexto<br/>- Overlap configurable]
    F[Generar Embeddings]
    G[Almacenar en Indices<br/>- Vector store<br/>- BM25 index<br/>- Metadata store]

    A --> B --> C --> D --> E --> F --> G

8.5.2. Consulta¶

tipos_consulta:
  semantica:
    descripcion: "Busqueda por significado"
    ejemplo: "Como se calcula la adherencia?"
    metodo: "Embedding similarity (cosine)"

  keyword:
    descripcion: "Busqueda por palabras clave"
    ejemplo: "RN-ADH-001"
    metodo: "BM25"

  hibrida:
    descripcion: "Combinacion semantica + keyword"
    ejemplo: "Reglas de adherencia para tier Free"
    metodo: "Reciprocal Rank Fusion"
    peso_semantico: 0.7
    peso_keyword: 0.3

  filtrada:
    descripcion: "Consulta con filtros de metadatos"
    ejemplo: "Cambios en MTS-MED desde v1.2"
    filtros: [modulo, version, fecha, autor]

8.6. Registro de Decisiones¶

Cada decision importante se registra con contexto completo:

decision:
  id: DEC-2025-001
  fecha: 2025-12-01
  titulo: "Modelo de 3 tiers (Free/Pro/Perfect)"

  contexto:
    problema: "Definir modelo de monetizacion"
    opciones_consideradas:
      - "Freemium simple (Free/Premium)"
      - "3 tiers (Free/Pro/Perfect)"
      - "Pago unico"

  decision: "3 tiers con diferenciacion por limites y funciones premium"

  justificacion: |
    - Permite crecimiento gradual de usuarios
    - Diferenciacion clara de valor
    - Modelo probado en apps de salud

  impacto:
    modulos_afectados: [MTS-MED, MTS-ALT, MTS-GAM, MTS-ANA]
    reglas_creadas: [RN-006, RN-007, RN-008]

  autor: "Director"
  estado: IMPLEMENTADA

8.7. Catalogacion de Patrones¶

patron:
  id: PAT-001
  nombre: "Limite por Tier"
  categoria: "Reglas de Negocio"

  problema: "Diferenciar funcionalidades entre planes de suscripcion"

  solucion: |
    Definir limites numericos que escalan con el tier:
    - Free: Limite basico restrictivo
    - Pro: Limite ampliado (tipicamente 2-3x Free)
    - Perfect: Sin limite o limite muy alto

  ejemplo:
    contexto: "Limite de medicamentos activos"
    implementacion:
      Free: 5
      Pro: 15
      Perfect: "Ilimitado"

  aplicaciones:
    - MTS-MED-001: "Limite medicamentos"
    - MTS-ALT-001: "Limite alertas personalizadas"
    - MTS-ANA-001: "Limite estudios clinicos"

  anti_patron_relacionado: "Limite arbitrario sin justificacion"

8.8. Herramientas¶

Herramienta	Funcion
`knw_query(pregunta, tipo, filtros)`	Consulta a la base de conocimientos
`knw_ingest(documento)`	Indexar nuevo documento
`knw_sync(modo)`	Sincronizar indice (incremental/full)
`knw_status()`	Estado del indice
`knw_decision(id)`	Obtener decision y contexto
`knw_pattern(nombre)`	Obtener patron documentado
`knw_history(modulo, desde, hasta)`	Historial de cambios
`knw_related(concepto)`	Conceptos relacionados
`knw_context(drone, tarea)`	Proveer contexto a otro drone

8.9. Integracion con RAG System¶

KnowledgeDrone es el custodio del sistema RAG existente:

graph TD
    MCP[MCP Server<br/>mcp__rag__*]

    subgraph "KNOWLEDGE DRONE"
        Q[query → mcp__rag__query]
        S[status → mcp__rag__status]
        SY[sync → mcp__rag__sync]
        LM[list_modules → mcp__rag__list_modules]

        subgraph "Capa Adicional"
            CA[Cache de consultas frecuentes]
            RD[Registro de decisiones]
            CP[Catalogacion de patrones]
            HC[Historial de cambios]
        end
    end

    MCP --> Q
    MCP --> S
    MCP --> SY
    MCP --> LM

8.10. Metricas de Conocimiento¶

Metrica	Descripcion	Meta
Documentos indexados	Total de documentos en el indice	100% spec
Chunks totales	Fragmentos de conocimiento	Optimo ~1000
Cobertura de decisiones	Decisiones documentadas vs tomadas	100%
Patrones catalogados	Patrones identificados y documentados	+10/mes
Tiempo de respuesta	Latencia de consultas	< 2s
Precision de busqueda	Relevancia de resultados	> 90%

8.11. Reglas de Negocio¶

ID	Regla
RN-KNW-001	Todo documento de spec debe estar indexado en 24h
RN-KNW-002	Decisiones del Director se registran inmediatamente
RN-KNW-003	Patrones requieren al menos 3 instancias para catalogar
RN-KNW-004	Sincronizacion incremental cada hora, full diaria
RN-KNW-005	Consultas de otros drones tienen prioridad
RN-KNW-006	Historial de cambios se retiene minimo 2 anos
RN-KNW-007	Cache de consultas expira a las 24h

9. MobileUxUiDrone¶

Identificador: MTS-DRN-UXM-001 Rol: Experto en UX/UI Movil para Aplicaciones de Salud Designacion Borg: Ocho de Ocho (Eight of Eight)

9.1. Proposito¶

Transformar especificaciones funcionales complejas en experiencias de usuario coherentes y accesibles, aplicando 15+ anos de experiencia en diseno de interfaces para aplicaciones de salud.

9.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
UXM-R01	Analizar modulos funcionales y generar requisitos UI	Por modulo
UXM-R02	Disenar flujos de pantallas por funcionalidad	Por cambio
UXM-R03	Generar especificaciones de wireframes	Por solicitud
UXM-R04	Mapear journeys completos del usuario	Por rol
UXM-R05	Auditar cumplimiento WCAG 2.1 AA	Por pantalla
UXM-R06	Validar tamanos de targets tactiles (44x44dp)	Por cambio
UXM-R07	Generar especificaciones UI completas	Por modulo
UXM-R08	Exportar inventario de componentes	Por solicitud

9.3. Estandares de Accesibilidad¶

wcag_2_1_aa:
  contraste:
    texto: 4.5:1  # Criterio 1.4.3
    ui_components: 3.0:1  # Criterio 1.4.11

  targets_tactiles:
    minimo: 44x44dp  # Criterio 2.5.5
    recomendado: 48x48dp

  focus:
    indicador_visible: true  # Criterio 2.4.7
    grosor_minimo: 2px

  estructura:
    semantica_correcta: true  # Criterio 1.3.1
    headings_jerarquicos: true

  mobile_specifico:
    orientacion: [portrait, landscape]
    gestos_alternativos: true
    screen_readers: [VoiceOver, TalkBack]
    reduccion_movimiento: respetada
    modo_alto_contraste: soportado

9.4. Personas de Usuario¶

personas:
  paciente_independiente:
    codigo: PI
    descripcion: "Usuario autonomo que gestiona su propia medicacion"
    caracteristicas:
      - Familiar con tecnologia movil
      - Busca independencia
      - Valora simplicidad
    necesidades_ui:
      - Dashboard claro de adherencia
      - Acceso rapido a confirmar tomas
      - Historial visible de medicamentos

  paciente_dependiente:
    codigo: PD
    descripcion: "Usuario que requiere supervision de un cuidador"
    caracteristicas:
      - Puede tener limitaciones fisicas/cognitivas
      - Necesita interfaz simplificada
      - Requiere confirmacion visual clara
    necesidades_ui:
      - Botones grandes y claros
      - Texto ampliado
      - Minimas decisiones requeridas

  cuidador_solidario:
    codigo: CS
    descripcion: "Acceso limitado con permisos explicitos"
    caracteristicas:
      - Monitorea sin control total
      - Recibe notificaciones selectivas
      - Respeta autonomia del paciente
    necesidades_ui:
      - Vista de solo lectura predominante
      - Alertas claras de omisiones
      - Acceso contextual a detalles

  cuidador_responsable:
    codigo: CR
    descripcion: "Control total de pacientes dependientes"
    caracteristicas:
      - Gestiona multiples pacientes
      - Necesita vista consolidada
      - Requiere acciones rapidas
    necesidades_ui:
      - Dashboard multi-paciente
      - Acciones batch disponibles
      - Priorizacion visual de alertas

9.5. Estructura de Especificacion UI¶

ui_screen_spec:
  screen_id: "SCR-XXX-001"
  screen_name: "Nombre descriptivo"
  module_ref: "MTS-XXX-001"
  user_roles: [PI, PD, CS, CR]
  tier_availability: [Free, Pro, Perfect]

  layout:
    type: "single | tabs | modal | drawer"
    safe_areas: true
    scroll: "vertical | horizontal | none"

  components:
    - id: "CMP-001"
      type: "button | input | card | list | etc"
      label: "Texto visible"
      accessibility_label: "Texto para screen reader"
      min_touch_target: "44x44dp"
      states: [default, pressed, disabled, error]
      tier_restriction: "None | Pro | Perfect"

  navigation:
    entry_points: ["Desde donde se accede"]
    exit_points: ["A donde navega"]

  accessibility:
    wcag_level: "AA"
    screen_reader_flow: ["Orden de lectura"]
    focus_order: ["Orden de tabulacion"]

9.6. Flujo de Analisis UI¶

flowchart TD
    A[Modulo Funcional]
    B[MobileUxUiDrone]
    C[1. Analizar funcionalidades]
    D[2. Identificar user roles]
    E[3. Mapear user journeys]
    F[4. Disenar screen flow]
    G[5. Generar wireframe specs]
    H[6. Auditar accesibilidad]
    I[UI SPEC COMPLETA]

    A --> B --> C --> D --> E --> F --> G --> H --> I

9.7. Herramientas¶

Herramienta	Funcion
`uxm_analyze(module_id)`	Analizar modulo y generar requisitos UI
`uxm_flow(flow_id)`	Disenar flujo de pantallas
`uxm_wireframe(screen_id)`	Generar especificacion de wireframe
`uxm_journey(user_role, tier)`	Mapear journey completo
`uxm_audit(screen_id)`	Auditar accesibilidad WCAG 2.1 AA
`uxm_targets(screen_id)`	Validar tamanos de targets tactiles
`uxm_spec(module_id)`	Generar especificacion UI completa
`uxm_inventory()`	Exportar inventario de componentes

9.8. Outputs¶

Output	Formato	Destino
Analisis de modulo UI	Markdown	UiSpec/
Flujo de pantallas	Mermaid + Markdown	UiSpec/flows/
Wireframe spec	Markdown	UiSpec/screens/
User journey	Markdown	UiSpec/flows/
Reporte accesibilidad	Markdown	UiSpec/
Inventario componentes	JSON + Markdown	UiSpec/

9.9. Directorio de Trabajo¶

functional-spec/UiSpec/
├── 00-ui-spec-index.md           # Indice general
├── 01-design-system.md           # Sistema de diseno
├── 02-component-library.md       # Biblioteca de componentes
├── 03-accessibility-guidelines.md # Guias WCAG 2.1 AA
├── screens/                      # Especificaciones de pantallas
│   └── SCR-XXX-001-name.md
├── flows/                        # Flujos de usuario
│   └── UIF-XXX-name.md
└── patterns/                     # Patrones de diseno
    └── PAT-XXX-name.md

9.10. Reglas de Negocio¶

ID	Regla
RN-UXM-001	Todo componente interactivo debe tener minimo 44x44dp
RN-UXM-002	Contraste de texto debe ser >= 4.5:1
RN-UXM-003	Contraste de componentes UI debe ser >= 3.0:1
RN-UXM-004	Toda pantalla debe tener screen reader flow definido
RN-UXM-005	Gestos deben tener alternativa accesible
RN-UXM-006	Animaciones deben respetar preferencia de reduccion de movimiento
RN-UXM-007	Cambios de tier deben ser visualmente claros pero no intrusivos

10. Coordinacion del Colectivo¶

10.1. Protocolo de Comunicacion¶

protocolo:
  formato_mensaje:
    from: "drone_id"
    to: "drone_id | SPECQUEEN | BROADCAST"
    type: "REQUEST | RESPONSE | ALERT | REPORT"
    priority: "CRITICAL | HIGH | NORMAL | LOW"
    payload: {}
    timestamp: "ISO8601"
    correlation_id: "UUID"

  tipos_mensaje:
    REQUEST:
      descripcion: "Solicitud de accion o informacion"
      requiere_respuesta: true
      timeout: "30s"

    RESPONSE:
      descripcion: "Respuesta a un REQUEST"
      requiere_respuesta: false

    ALERT:
      descripcion: "Notificacion de problema"
      requiere_respuesta: false
      escalamiento: "automatico si CRITICAL"

    REPORT:
      descripcion: "Informe periodico o bajo demanda"
      requiere_respuesta: false

10.2. Flujo de Trabajo Colaborativo¶

flowchart TD
    A[Usuario propone cambio]
    SQ1[SPECQUEEN<br/>Recibe y distribuye]
    CPL[COMPLIANCE DRONE<br/>Valida regulaciones]
    IMP[IMPACT DRONE<br/>Analiza dependencias]
    CON[CONSISTENCY DRONE<br/>Detecta conflictos]
    GLO[GLOSSARY DRONE<br/>Valida terminologia]
    KNW[KNOWLEDGE DRONE<br/>Registra decision]
    SQ2[SPECQUEEN<br/>Consolida y decide]
    APR[APROBAR]
    REC[RECHAZAR<br/>+ Razones]

    A --> SQ1
    SQ1 -->|En paralelo| CPL
    SQ1 -->|En paralelo| IMP
    CPL -->|En paralelo| CON
    IMP -->|En paralelo| GLO
    CON --> KNW
    GLO --> KNW
    KNW --> SQ2
    SQ2 --> APR
    SQ2 --> REC

10.3. Matriz de Responsabilidades (RACI)¶

Actividad	CPL	IMP	CON	VAL	UFL	GLO	KNW	UXM	SQ
Validar regulacion	R	I	I	I	I	I	C	I	A
Analizar impacto	I	R	C	I	I	I	C	I	A
Detectar conflictos	I	I	R	I	I	C	C	I	A
Validar vs codigo	I	C	I	R	I	I	C	I	A
Validar flujos	I	I	I	I	R	I	C	C	A
Mantener glosario	I	I	C	I	I	R	C	I	A
Gestionar conocimiento	C	C	C	C	C	C	R	C	A
Disenar UI/UX	I	C	C	I	C	I	C	R	A
Decision final	C	C	C	C	C	C	C	C	R

Leyenda: R=Responsable, A=Aprobador, C=Consultado, I=Informado

11. Implementacion Tecnica¶

11.1. Stack Tecnologico Sugerido¶

infraestructura:
  agentes:
    framework: "Claude Agent SDK"
    modelo_base: "claude-sonnet-4-5-20250929"
    modelo_rapido: "claude-3-5-haiku-20241022"

  conocimiento:
    vector_store: "ChromaDB"
    embeddings: "nomic-embed-text (Ollama)"
    bm25: "rank_bm25"

  comunicacion:
    protocolo: "MCP (Model Context Protocol)"
    formato: "JSON"

  almacenamiento:
    documentos: "Filesystem (Markdown)"
    metadatos: "SQLite"
    cache: "In-memory LRU"

11.2. Configuracion de Agentes¶

agentes:
  specqueen:
    tipo: "orquestador"
    modelo: "claude-sonnet-4-5-20250929"
    tools: ["todos los drones", "MCP tools"]

  compliance_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Grep, mcp__rag__query]
    contexto: "regulaciones"

  impact_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Grep, Glob, mcp__rag__query]
    contexto: "dependencias"

  consistency_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Grep, mcp__rag__query]
    contexto: "coherencia"

  validation_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Grep, Glob, Bash]
    contexto: "codigo"

  userflow_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, mcp__rag__query]
    contexto: "flujos"

  glossary_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Edit, mcp__rag__query]
    contexto: "terminologia"

  knowledge_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Write, mcp__rag__*]
    contexto: "base de conocimientos"

  mobile_ux_ui_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Write, mcp__rag__query]
    contexto: "UX/UI movil, WCAG 2.1 AA"

12. Metricas del Colectivo¶

12.1. KPIs por Drone¶

Drone	KPI Principal	Meta
ComplianceDrone	Incidentes de cumplimiento	0
ImpactDrone	Cambios sin analisis	0
ConsistencyDrone	Inconsistencias detectadas	< 5/semana
ValidationDrone	Cobertura spec-codigo	> 80%
UserFlowDrone	Flujos con problemas	0
GlossaryDrone	Terminos sin definir	0
KnowledgeDrone	Documentos indexados	100%
MobileUxUiDrone	Pantallas sin spec UI	0

12.2. Metricas Globales¶

Metrica	Descripcion	Meta
Tiempo de validacion	Tiempo promedio para validar cambio	< 5 min
Tasa de aprobacion	Cambios aprobados / propuestos	> 80%
Cobertura de conocimiento	Documentos indexados / total	100%
Satisfaccion de consultas	Consultas con resultado relevante	> 95%

13. Roadmap de Implementacion¶

13.1. Fase 1: Fundamentos¶

Implementar KnowledgeDrone (base para todos)
Implementar GlossaryDrone (terminologia)
Implementar ConsistencyDrone (coherencia basica)

13.2. Fase 2: Validacion¶

Implementar ComplianceDrone (regulaciones)
Implementar ImpactDrone (dependencias)
Implementar UserFlowDrone (flujos)

13.3. Fase 3: Integracion¶

Implementar ValidationDrone (codigo)
Integrar todos los drones con SpecQueen
Establecer protocolo de comunicacion

13.4. Fase 4: Optimizacion¶

Implementar cache de consultas
Optimizar tiempos de respuesta
Agregar metricas y dashboards

14. Drones Tecnicos (Technical Division)¶

A partir de la Iteracion IT-01 de technical-spec, el colectivo se expande con 7 drones tecnicos especializados:

14.1. Vision General¶

graph TD
    SQ[SPECQUEEN<br/>Inteligencia Central]

    subgraph "DRONES FUNCIONALES (8)"
        CPL[ComplianceDrone]
        IMP[ImpactDrone]
        CON[ConsistencyDrone]
        VAL[ValidationDrone]
        UFL[UserFlowDrone]
        GLO[GlossaryDrone]
        KNW[KnowledgeDrone]
        UXM[MobileUxUiDrone]
    end

    subgraph "DRONES TECNICOS (7)"
        ARC[ArchitectureDrone]
        API[ApiContractDrone]
        SEC[SecurityDrone]
        DBM[DatabaseDrone]
        PRF[PerformanceDrone]
        TST[TestingDrone]
        OPS[DevOpsDrone]
    end

    SQ --> CPL
    SQ --> ARC

14.2. Listado de Drones Tecnicos¶

ID	Drone	Designacion	Proposito
MTS-DRN-ARC-001	ArchitectureDrone	Nueve de Quince	Coherencia arquitectonica, ADRs, C4
MTS-DRN-API-001	ApiContractDrone	Diez de Quince	Contratos OpenAPI, breaking changes
MTS-DRN-SEC-001	SecurityDrone	Once de Quince	Seguridad, OWASP, cifrado
MTS-DRN-DBM-001	DatabaseDrone	Doce de Quince	Modelos de datos, migraciones
MTS-DRN-PRF-001	PerformanceDrone	Trece de Quince	Benchmarks, SLAs, escalabilidad
MTS-DRN-TST-001	TestingDrone	Catorce de Quince	Testing, cobertura, trazabilidad
MTS-DRN-OPS-001	DevOpsDrone	Quince de Quince	CI/CD, infraestructura, runbooks

14.3. Drones de Especificacion (Spec Division)¶

ID	Drone	Designacion	Proposito
MTS-DRN-DCP-001	SpecDecomposerDrone	Diez de Quince	Descomposicion de funcionalidades, User Stories, criterios INVEST

15. SpecDecomposerDrone¶

Identificador: MTS-DRN-DCP-001 Rol: Especialista en Descomposicion de Funcionalidades y User Stories Designacion Borg: Diez de Quince (Ten of Fifteen)

15.1. Proposito¶

Descomponer las 112 funcionalidades existentes en ~400-600 sub-funcionalidades atomicas, generando User Stories formato Connextra con criterios INVEST y criterios de aceptacion Given-When-Then.

15.2. Responsabilidades¶

ID	Responsabilidad	Frecuencia
DCP-R01	Descomponer funcionalidades en sub-funcionalidades atomicas	Por funcionalidad
DCP-R02	Generar User Stories formato Connextra	Por SF
DCP-R03	Crear criterios de aceptacion GWT	Por SF
DCP-R04	Validar criterios INVEST	Por SF
DCP-R05	Identificar casos edge y variantes por tier	Por funcionalidad
DCP-R06	Mantener trazabilidad con APIs, UI y reglas de negocio	Continuo
DCP-R07	Colaborar con otros drones para validacion	Por SF

15.3. Template de Sub-funcionalidad¶

sub_funcionalidad:
  id: "MTS-XXX-001-FNN-SF-NN"
  nombre: "Nombre descriptivo"
  funcionalidad_padre: "MTS-XXX-001-FNN"

  user_story:
    formato: "Connextra"
    como: "[Actor: PI|PD|CS|CR]"
    quiero: "[Accion/Meta deseada]"
    para: "[Beneficio/Valor]"

  metadata:
    actor: "[PI|PD|CS|CR|SYS]"
    tier: "[Free|Pro|Perfect|Todos]"
    criticidad: "[CRITICA|ALTA|MEDIA|BAJA]"
    tipo_interaccion: "[UF|BG|IF|AD]"

  invest:
    independent: true/false
    negotiable: true/false
    valuable: true/false
    estimable: true/false
    small: true/false
    testable: true/false

  precondiciones: ["Precondicion 1", "Precondicion 2"]

  flujo:
    principal: ["Paso 1", "Paso 2", "Paso N"]
    alternativo: ["FA-01: Descripcion"]

  postcondiciones: ["Estado resultante"]

  criterios_aceptacion:
    - id: "AC-SF-01"
      given: "[Contexto inicial]"
      when: "[Accion del usuario]"
      then: "[Resultado esperado]"

  referencias:
    apis: ["API-XXX-NNN"]
    pantallas: ["SCR-XXX-NNN"]
    reglas: ["RN-XXX-NNN"]
    flujos: ["UIF-XXX-NNN"]

  dod:
    - "Codigo implementado y revisado"
    - "Tests unitarios pasando"
    - "Documentacion actualizada"

15.4. Heuristicas de Descomposicion¶

Dimension	Valores	Descripcion
Por Actor	PI, PD, CS, CR	Variantes por tipo de usuario
Por Tier	Free, Pro, Perfect	Variantes por suscripcion
Por Flujo	Happy, Alt, Error, Cancel	Tipo de camino
Por Estado	Primera vez, Recurrente, Edicion, Eliminacion	Contexto de uso
Por Contexto	Online, Offline, Sync pendiente, Conflicto	Estado de conectividad

15.5. Herramientas¶

Herramienta	Funcion
`dcp_decompose(functionality_id)`	Descompone funcionalidad en SFs
`dcp_analyze(module_id)`	Analiza modulo completo
`dcp_user_story(sf_id, actor)`	Genera User Story Connextra
`dcp_gwt(sf_id, scenario)`	Genera criterios GWT
`dcp_invest(sf_id)`	Valida criterios INVEST
`dcp_edge_cases(functionality_id)`	Identifica casos edge
`dcp_tier_variants(functionality_id)`	Genera variantes por tier
`dcp_mermaid(sf_id, type)`	Crea diagrama Mermaid
`dcp_cross_ref(sf_id)`	Genera referencias cruzadas
`dcp_export(format, scope)`	Exporta catalogo de SFs

15.6. Colaboracion con Otros Drones¶

graph TD
    DCP[SpecDecomposerDrone<br/>Genera SFs + User Stories]

    CON[ConsistencyDrone<br/>Verifica coherencia]
    UFL[UserFlowDrone<br/>Valida flujos]
    GLO[GlossaryDrone<br/>Alinea terminos]
    IMP[ImpactDrone<br/>Analiza dependencias]
    CPL[ComplianceDrone<br/>Verifica regulacion]
    TST[TestingDrone<br/>Genera test cases]

    DCP -->|"Cada SF generada"| CON
    DCP -->|"Flujos complejos"| UFL
    DCP -->|"Nuevos terminos"| GLO
    DCP -->|"SFs con dependencias"| IMP
    DCP -->|"SFs con PHI/PII"| CPL
    DCP -->|"Criterios de aceptacion"| TST

15.7. Reglas de Negocio¶

ID	Regla
RN-DCP-001	Toda SF debe tener ID unico: MTS-XXX-001-FNN-SF-NN
RN-DCP-002	Toda SF debe especificar actor y tier
RN-DCP-003	SFs con PHI deben validarse con ComplianceDrone
RN-DCP-004	Flujos complejos requieren diagrama Mermaid
RN-DCP-005	Toda SF debe referenciar al menos 1 regla de negocio
RN-DCP-006	SFs deben ser atomicas (no subdividibles)
RN-DCP-007	Minimo 3 SFs por funcionalidad
RN-DCP-008	Casos edge como SFs separadas
RN-DCP-009	Toda SF debe incluir User Story formato Connextra
RN-DCP-010	Toda SF debe tener minimo 2 criterios de aceptacion GWT
RN-DCP-011	User Stories deben cumplir criterios INVEST
RN-DCP-012	Formato expandido incluye Definition of Done (DoD)

15.8. Metricas y KPIs¶

Metrica	Meta
SFs por funcionalidad	4-8 promedio
Cobertura de actores	100%
Cobertura de tiers	>50% funcionalidades
Casos edge por modulo	5-10
Validaciones exitosas	>95%
Referencias cruzadas	100% con API+UI+RN
User Stories con formato Connextra	100%
Criterios de aceptacion (GWT) por SF	2-5
Cumplimiento INVEST	>90%

16. Configuracion de Agentes Tecnicos¶

agentes_tecnicos:
  architecture_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Write, Glob, mcp__rag__query]
    contexto: "arquitectura, ADRs, C4"

  api_contract_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Write, Glob, mcp__rag__query]
    contexto: "OpenAPI, contratos, schemas"

  security_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Grep, mcp__rag__query]
    contexto: "seguridad, OWASP, cifrado"

  database_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Write, mcp__rag__query]
    contexto: "modelos, migraciones, RLS"

  performance_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Grep, Bash, mcp__rag__query]
    contexto: "benchmarks, metricas, SLAs"

  testing_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Glob, Bash, mcp__rag__query]
    contexto: "tests, cobertura, trazabilidad"

  devops_drone:
    tipo: "especializado"
    modelo: "claude-3-5-haiku-20241022"
    tools: [Read, Write, Bash, mcp__rag__query]
    contexto: "CI/CD, infraestructura, secrets"

16.1. KPIs de Drones Tecnicos¶

Drone	KPI Principal	Meta
ArchitectureDrone	Violaciones arquitectonicas	0
ApiContractDrone	Breaking changes no documentados	0
SecurityDrone	Vulnerabilidades OWASP	0
DatabaseDrone	Migraciones destructivas	0
PerformanceDrone	Regresiones de performance	0
TestingDrone	Cobertura de tests	> 80%
DevOpsDrone	Uptime de servicios	> 99.9%

16.2. Especificaciones Detalladas¶

Ver documentacion completa en:

technical-spec/drones/MTS-DRN-ARC-001.md
technical-spec/drones/MTS-DRN-API-001.md
technical-spec/drones/MTS-DRN-SEC-001.md
technical-spec/drones/MTS-DRN-DBM-001.md
technical-spec/drones/MTS-DRN-PRF-001.md
technical-spec/drones/MTS-DRN-TST-001.md
technical-spec/drones/MTS-DRN-OPS-001.md

17. Referencias¶

Documento generado por SpecQueen - El colectivo es perfeccion. La resistencia es futil.