8bb46e4d08
- Move 6 non-standard folders to _archive/ - Update _MAP.md with standardized structure Standard: SIMCO-ESTANDAR-ORCHESTRATION v1.0.0 Level: SUB-CONSUMER Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
362 lines
11 KiB
Markdown
362 lines
11 KiB
Markdown
# 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
|