# ALEPH CRM — Decision Log

## Propósito

Documentar las decisiones de diseño del flujo Gemelo → ALEPH → CRM.

---

## D-001 — Orden jerárquico

El flujo sigue:

EMPRESA → PERSONA → PERSONA_PROYECTO

Razón:
evitar registros huérfanos y mantener integridad en ALEPH.

---

## D-002 — Dry-run obligatorio

Toda escritura pasa por:

preview → dry-run → ejecución

Razón:
minimizar errores en base productiva y permitir auditoría.

---

## D-003 — Resolución de empresa

Se resuelve por:

1. NIT
2. nombre normalizado

Estados:

- MATCHED
- AMBIGUOUS
- NOT_FOUND

---

## D-004 — Creación de empresa condicionada

Solo se permite crear empresa si existe NIT.

Razón:
evitar contaminar maestros con datos incompletos.

---

## D-005 — Contacto mínimo

Para CRM operativo se requiere:

- full_name
- email o phone

---

## D-006 — Regla de nombres

- 1 palabra → nombre
- 2 palabras → nombre + apellido
- 3+ palabras → nombre = todas menos última

Siempre:

nombreC = full_name

---

## D-007 — Defaults de EMPRESAS

- id_tipo = 'NA'
- id_estado = 'OK'
- persona_natural = 0

Razón:
usar valores válidos mínimos mientras no se modele completamente.

---

## D-008 — Idempotencia CRM

Antes de escribir:

PERSONAS:
- buscar por email
- o por (nombre + NIT)

PERSONA_PROYECTO:
- buscar por (id_persona + id_proyecto)

Si ambos existen:

→ CRM_ALREADY_SYNCED

---

## D-009 — Separación lectura/escritura DB

- run_query → SELECT
- run_execute → INSERT/UPDATE

Razón:
evitar errores por uso incorrecto de funciones.

---

## D-010 — Proyecto interno obligatorio

Para CRM operativo se requiere:

internal_commercial_project_id

Razón:
PERSONA_PROYECTO depende de ese identificador.

---

## D-011 — Vendor registration no bloqueante

Inicialmente se consideró como prerequisito.

Se corrigió a:

- NO bloquea contacto ni actividad inicial
- SÍ afecta madurez comercial

Razón:
en la práctica comercial se puede iniciar contacto antes del registro.