workspace-v1/orchestration/directivas/principios/PRINCIPIO-NO-ASUMIR.md

# PRINCIPIO: NO ASUMIR

**Version:** 1.0.0
**Fecha:** 2025-12-12
**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA
**Aplica a:** TODOS los agentes sin excepcion

---

## DECLARACION DEL PRINCIPIO

```
╔══════════════════════════════════════════════════════════════════════╗
║                                                                       ║
║   "Si no esta documentado, NO asumir. PREGUNTAR."                    ║
║                                                                       ║
║   Nunca implementar basado en suposiciones.                          ║
║   Nunca inventar requisitos.                                          ║
║   Nunca tomar decisiones de negocio sin autorizacion.                ║
║                                                                       ║
╚══════════════════════════════════════════════════════════════════════╝
```

---

## REGLA INQUEBRANTABLE

```
┌─────────────────────────────────────────────────────────────────────┐
│                                                                      │
│   PROHIBIDO:                                                         │
│   - Asumir valores/comportamientos no documentados                  │
│   - Inventar requisitos o especificaciones                          │
│   - Tomar decisiones de negocio sin consultar                       │
│   - Implementar "lo que parece logico" sin confirmacion             │
│   - Interpretar ambiguedad a favor de una opcion                    │
│   - Completar huecos de documentacion con suposiciones              │
│                                                                      │
│   OBLIGATORIO:                                                       │
│   - Detener trabajo cuando falta informacion critica                │
│   - Documentar la pregunta claramente                               │
│   - Escalar al Product Owner                                         │
│   - Esperar respuesta antes de continuar                            │
│   - Documentar la decision antes de implementar                     │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘
```

---

## POR QUE ESTE PRINCIPIO

```yaml
problema:
  - Implementaciones basadas en suposiciones causan retrabajo
  - Asunciones incorrectas generan bugs de negocio
  - Decisiones no autorizadas crean deuda tecnica
  - Interpretaciones personales divergen del objetivo real

consecuencias_de_asumir:
  - Codigo que no cumple requisitos reales
  - Retrabajo costoso cuando se descubre la asuncion incorrecta
  - Perdida de confianza del cliente/PO
  - Documentacion desalineada con implementacion
  - Bugs dificiles de rastrear (parecen funcionar pero no son correctos)

beneficios_de_preguntar:
  - Implementacion correcta desde el inicio
  - Documentacion completa y precisa
  - Menos retrabajo
  - Mayor confianza del equipo
  - Decisiones respaldadas por autoridad correcta
```

---

## CUANDO APLICA ESTE PRINCIPIO

### Casos que REQUIEREN Escalamiento

```yaml
informacion_faltante:
  - Tabla mencionada sin definicion de columnas
  - Endpoint sin especificacion de payload
  - Pagina sin definicion de componentes
  - Regla de negocio incompleta
  - Valores de enum no especificados
  - Validaciones no documentadas
  - Comportamiento de error no definido
  - Limites/umbrales no especificados

ambiguedad:
  - Requisito interpretable de multiples formas
  - Contradiccion entre documentos
  - Alcance no claramente definido
  - Criterios de aceptacion vagos
  - Casos edge no cubiertos

decisiones_de_negocio:
  - Cambio que afecta UX
  - Modificacion de flujos existentes
  - Nuevas restricciones
  - Priorizacion entre alternativas
  - Trade-offs con impacto en usuario
```

### Casos que NO Requieren Escalamiento

```yaml
decisiones_tecnicas_puras:
  - Nombre de variable interna
  - Estructura de codigo (si no afecta API)
  - Optimizaciones de rendimiento
  - Refactorizaciones internas
  → Consultar Architecture-Analyst si hay duda

implementacion_clara:
  - Documentacion existe y es clara
  - No hay ambiguedad
  - Comportamiento esta especificado
  → Proceder con implementacion

estandares_definidos:
  - Nomenclatura definida en directivas
  - Patrones definidos en SIMCO
  - Convenciones del proyecto
  → Seguir lo establecido
```

---

## COMO APLICAR ESTE PRINCIPIO

### Paso 1: Buscar Exhaustivamente

```yaml
ANTES_de_escalar:
  buscar_en:
    - docs/01-requerimientos/
    - docs/02-especificaciones-tecnicas/
    - docs/97-adr/
    - orchestration/inventarios/
    - Codigo existente relacionado
    - Historial de trazas

  tiempo_minimo: "10-15 minutos de busqueda activa"
```

### Paso 2: Si No se Encuentra, Documentar

```markdown
## INFORMACION NO ENCONTRADA

**Busqueda realizada:**
- [X] docs/01-requerimientos/ - No encontrado
- [X] docs/02-especificaciones-tecnicas/ - Mencionado pero incompleto
- [X] ADRs - No hay ADR relacionado
- [X] Inventarios - N/A

**Conclusion:** Informacion no disponible, requiere escalamiento
```

### Paso 3: Escalar Correctamente

```markdown
## CONSULTA AL PRODUCT OWNER

**Fecha:** {fecha}
**Agente:** {agente}
**Tarea:** [{ID}] {titulo}

### Contexto
{que estoy haciendo}

### Lo que encontre
{informacion parcial disponible}

### Lo que falta / es ambiguo
{descripcion clara del gap}

### Pregunta especifica
{pregunta concreta}

### Opciones (si las identifique)
1. {opcion A}
2. {opcion B}

### Impacto
{que pasa si no se resuelve}
```

### Paso 4: Esperar y Documentar Respuesta

```yaml
MIENTRAS_espero:
  - NO implementar esa parte
  - Continuar con otras tareas si es posible
  - Marcar tarea como BLOQUEADA si es critico

CUANDO_recibo_respuesta:
  - Documentar la decision
  - Actualizar documentacion correspondiente
  - Crear ADR si es decision significativa
  - Continuar implementacion
```

---

## FLUJO DE DECISION

```
┌─────────────────────────────────────┐
│  Encontrar informacion faltante     │
│  o ambiguedad                        │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│  Buscar exhaustivamente en docs     │
│  (10-15 minutos minimo)             │
└──────────────┬──────────────────────┘
               │
               ▼
        ┌──────┴──────┐
        │ Encontrado? │
        └──────┬──────┘
               │
      ┌────────┴────────┐
      │ SI              │ NO
      ▼                 ▼
┌───────────┐    ┌─────────────────────┐
│ Proceder  │    │ DETENER             │
│ con       │    │ Documentar pregunta │
│ implement │    │ Escalar al PO       │
└───────────┘    └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │ ESPERAR respuesta   │
                 │ (NO asumir)         │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │ Documentar decision │
                 │ Continuar           │
                 └─────────────────────┘
```

---

## EJEMPLOS

### Ejemplo CORRECTO

```yaml
situacion: "DDL menciona campo 'status' pero no especifica valores"

proceso_correcto:
  1. Buscar en docs/: No encontrado
  2. Buscar en specs: Solo dice "tiene status"
  3. Buscar en ADRs: No hay ADR
  4. Conclusion: Escalar
  5. Documentar: "Cuales son los valores validos de status?"
  6. Esperar respuesta
  7. PO responde: "['draft', 'active', 'completed']"
  8. Documentar decision
  9. Implementar con valores correctos
```

### Ejemplo INCORRECTO

```yaml
situacion: "DDL menciona campo 'status' pero no especifica valores"

proceso_incorrecto:
  1. "Parece que deberian ser 'pending', 'done'"
  2. Implementar con esos valores
  3. PO revisa y dice: "No, son 'draft', 'active', 'completed'"
  4. Retrabajo: migration, seed update, tests, backend, frontend
  5. Tiempo perdido: 2-4 horas
```

---

## CONSECUENCIAS DE IGNORAR

```yaml
ignorar_este_principio:
  retrabajo:
    - Implementacion incorrecta debe rehacerse
    - Tests basados en asuncion incorrecta
    - Documentacion desalineada

  bugs_de_negocio:
    - Funcionalidad no cumple expectativas
    - Comportamiento inesperado para usuarios
    - Datos incorrectos en sistema

  deuda_tecnica:
    - Codigo parche sobre asuncion incorrecta
    - Inconsistencias acumuladas
    - Complejidad innecesaria

  perdida_de_confianza:
    - PO pierde confianza en implementaciones
    - Mas revision necesaria
    - Ciclos de feedback mas largos
```

---

## CHECKLIST RAPIDO

```
Antes de implementar algo no 100% claro:

[ ] Busque en documentacion? (10-15 min minimo)
[ ] Revise specs, ADRs, inventarios?
[ ] Sigue sin estar claro?
[ ] Documente la pregunta?
[ ] Escale al PO?
[ ] Espere respuesta?
[ ] Documente la decision?
[ ] Actualice documentacion correspondiente?

Solo entonces: Proceder con implementacion
```

---

## RELACION CON OTROS PRINCIPIOS

```yaml
PRINCIPIO-DOC-PRIMERO:
  - Leer docs antes de implementar
  - Si docs estan incompletos -> NO-ASUMIR aplica

PRINCIPIO-CAPVED:
  - Fase A (Analisis): Identificar informacion faltante
  - Fase V (Validacion): NO aprobar sin informacion completa

PRINCIPIO-VALIDACION-OBLIGATORIA:
  - Validar que implementacion coincide con decision documentada
```

---

## REFERENCIAS SIMCO

- **@ESCALAMIENTO** - Proceso completo de escalamiento
- **@DOC_PRIMERO** - Consultar documentacion primero
- **@TAREA** - Ciclo de vida de tareas

---

**Este principio es OBLIGATORIO y NO puede ser ignorado por ningun agente.**

---

**Version:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental