Compare commits

...

No commits in common. "main" and "master" have entirely different histories.
main ... master

93 changed files with 1843 additions and 14789 deletions

76
.gitignore vendored
View File

@ -1,76 +0,0 @@
# =============================================================================
# CLINICA-DENTAL .gitignore
# =============================================================================
# -----------------------------------------------------------------------------
# DEPENDENCIAS
# -----------------------------------------------------------------------------
node_modules/
.pnp/
.pnp.js
# -----------------------------------------------------------------------------
# BUILD OUTPUTS
# -----------------------------------------------------------------------------
dist/
build/
.next/
out/
# -----------------------------------------------------------------------------
# ENVIRONMENT Y SECRETOS
# -----------------------------------------------------------------------------
.env
.env.local
.env.*.local
!.env.example
# -----------------------------------------------------------------------------
# CLAVES Y CERTIFICADOS
# -----------------------------------------------------------------------------
*.pem
*.key
*.p8
*.p12
*.pfx
*.crt
certificates/
keys/
# -----------------------------------------------------------------------------
# LOGS
# -----------------------------------------------------------------------------
logs/
*.log
npm-debug.log*
# -----------------------------------------------------------------------------
# IDE Y EDITORES
# -----------------------------------------------------------------------------
.idea/
.vscode/
*.sublime-project
*.sublime-workspace
# -----------------------------------------------------------------------------
# SISTEMA OPERATIVO
# -----------------------------------------------------------------------------
.DS_Store
Thumbs.db
*.swp
*.swo
*~
# -----------------------------------------------------------------------------
# TESTING Y COVERAGE
# -----------------------------------------------------------------------------
coverage/
.nyc_output/
# -----------------------------------------------------------------------------
# TEMPORALES
# -----------------------------------------------------------------------------
tmp/
temp/
.cache/
.turbo/

11
.gitmodules vendored
View File

@ -1,11 +0,0 @@
[submodule "backend"]
path = apps/backend
url = git@gitea-server:rckrdmrd/clinica-dental-backend-v2.git
[submodule "database"]
path = apps/database
url = git@gitea-server:rckrdmrd/clinica-dental-database-v2.git
[submodule "frontend"]
path = apps/frontend-web
url = git@gitea-server:rckrdmrd/clinica-dental-frontend-v2.git

158
CLAUDE.md
View File

@ -1,158 +0,0 @@
# CLAUDE.md - Clínica Dental
**Hereda de:** workspace-v2/CLAUDE.md, erp-clinicas/CLAUDE.md
**Sistema:** SIMCO v4.0.0 + NEXUS v4.0
**Proyecto:** clinica-dental
**Tipo:** SUB-CONSUMER (hereda de erp-clinicas)
**Especialización:** Odontología
**Versión:** 2.0.0
**Actualizado:** 2026-02-06
---
## EXTENSIONES LOCALES
Este archivo EXTIENDE (no reemplaza) las reglas del workspace y de erp-clinicas.
Para reglas base, ver: `../../CLAUDE.md`
Para reglas de ERP Clínicas, ver: `../erp-clinicas/CLAUDE.md`
---
## DESCRIPCIÓN DEL PROYECTO
Sistema ERP especializado para clínicas dentales. Hereda funcionalidades base de erp-clinicas y extiende con módulos odontológicos específicos.
**Cadena de herencia:**
```
template-saas → erp-core → erp-clinicas → clinica-dental
```
---
## STACK TECNOLÓGICO
- **Backend:** NestJS (heredado de erp-clinicas)
- **Frontend:** React (heredado)
- **Database:** PostgreSQL con schema `sub_dental`
- **Arquitectura:** Microservicios
---
## MÓDULOS DEL PROYECTO
### Módulos Heredados de erp-clinicas
- `pacientes` - Gestión de pacientes odontológicos
- `citas` - Agenda dental
- `expedientes` - Historia clínica odontológica
- `prescripciones` - Recetas dentales
### Módulos Heredados de erp-core
- `catalogs` - Catálogos generales
- `inventory` - Inventario de materiales dentales
### Módulos Heredados de template-saas
- `auth` - Autenticación
- `tenants` - Gestión de tenants
- `billing` - Facturación
- `notifications` - Notificaciones
### Módulos Propios (Sub-Dental)
| Módulo | ID | Estado | Descripción | Tablas |
|--------|-----|--------|-------------|--------|
| odontograma | CDT-001 | 30% | Odontograma digital interactivo | odontograms, tooth_conditions, tooth_treatments |
| tratamientos-dentales | CDT-002 | 25% | Catálogo de tratamientos dentales | dental_treatments, treatment_plans, treatment_progress |
| ortodoncia | CDT-003 | 20% | Módulo de ortodoncia y brackets | orthodontic_cases, bracket_types, orthodontic_progress |
| protesis | CDT-004 | 15% | Prótesis dentales y laboratorio | prosthetics, lab_orders |
| radiografias-dentales | CDT-005 | 20% | Radiografías panorámicas y periapicales | dental_xrays, xray_analysis |
| presupuestos-dentales | CDT-006 | 25% | Presupuestos de tratamiento dental | dental_quotes, quote_items |
---
## CONFIGURACIÓN LOCAL
### Schema de Base de Datos
```yaml
schema_prefix: "sub_dental"
schemas_propios:
- "sub_dental"
```
### Normativa Aplicable
| Norma | Descripción | Aplica a |
|-------|-------------|----------|
| NOM-013-SSA2-2015 | Prevención y control de enfermedades bucales | odontograma, tratamientos-dentales |
| NOM-004-SSA3-2012 | Del expediente clínico | expedientes |
| COFEPRIS | Regulación de consultorios dentales | Todos los módulos |
---
## REGLAS LOCALES ESPECÍFICAS
### R1: Convención de Nombres
- Tablas: `sub_dental.<modulo_nombre>`
- Entidades: `DentalXXX` (ej: DentalTreatment, OdontogramEntry)
- Servicios: `XXXDentalService`
- Controllers: `XXXDentalController`
### R2: Campos Especializados en Pacientes
Extensión heredada de erp-clinicas, con campos dentales:
- `tipo_denticion` - Temporal, permanente, mixta
- `historial_fluorosis` - Control de fluorosis
- `sensibilidad_dental` - Registro de sensibilidad
### R3: Integridad de Odontograma
- Todo paciente debe tener odontograma inicial
- Los 32 dientes deben estar registrados
- Cambios en odontograma generan auditoría automática
### R4: Planes de Tratamiento
- Vinculados obligatoriamente a paciente
- Requieren presupuesto aprobado
- Generan cronograma de citas automáticamente
---
## ALIAS LOCALES
| Alias | Ruta |
|-------|------|
| @LOCAL-ORCHESTRATION | orchestration/ |
| @INHERITANCE | orchestration/_inheritance.yml |
| @DENTAL-MODULES | Módulos en sub_dental schema |
| @CODIGOS-TRATAMIENTOS | Catálogo de códigos dentales |
---
## BLOQUEOS ACTUALES
**REGLA BLOCK-002:** No puede avanzar más allá de documentación si `erp-clinicas < 50%`
Estado actual: `erp-clinicas al 10%`
Acción: Solo documentación hasta que erp-clinicas llegue a 50%
---
## VALIDACIÓN
- Última validación: 2026-01-16
- Parent compatible: ✓
- erp-clinicas v1.0.0: ✓
- Módulos clínica disponibles: ⏳ Pendiente
---
## RELACIONADOS
- `orchestration/_inheritance.yml` - Declaración de herencia completa
- `orchestration/DEPENDENCY-GRAPH.yml` - Grafo de dependencias
- `orchestration/TRACEABILITY.yml` - Trazabilidad
- `../erp-clinicas/CLAUDE.md` - Reglas de ERP Clínicas
- `../../CLAUDE.md` - Reglas del workspace
---
**Sistema:** SIMCO v4.0.0 | **Tipo:** Instrucciones de Proyecto | **Última actualización:** 2026-02-02

View File

@ -1,7 +0,0 @@
# apps/ - Componentes de Aplicacion
| Directorio | Tipo | Descripcion |
|------------|------|-------------|
| backend/ | Submodulo | API backend |
| database/ | Submodulo | DDL y esquemas |
| frontend-web/ | Submodulo | Aplicacion web frontend |

@ -1 +0,0 @@
Subproject commit 5169565752ff93989b76bf56e52a856cb7b6738e

@ -1 +0,0 @@
Subproject commit 3fb40d599cc59cc265033d2e13fcb1b2d5847bbd

@ -1 +0,0 @@
Subproject commit 9c27ad9c2e6ca97a55e7336105d0656bd4dd9c1f

View File

@ -0,0 +1,502 @@
-- ============================================================================
-- DENTAL SCHEMA - Especialización de ERP-Clínicas
-- Clínica Dental
-- ============================================================================
-- Fecha: 2026-01-04
-- Versión: 1.0
-- Hereda de: erp-clinicas FASE-8
-- ============================================================================
-- Schema
CREATE SCHEMA IF NOT EXISTS dental;
-- ============================================================================
-- ENUMS
-- ============================================================================
DO $$ BEGIN
CREATE TYPE dental.estado_pieza AS ENUM (
'sano', 'caries', 'obturacion', 'endodoncia', 'corona',
'puente', 'implante', 'ausente', 'extraccion_indicada',
'diente_temporal', 'fractura', 'movilidad'
);
EXCEPTION WHEN duplicate_object THEN NULL;
END $$;
DO $$ BEGIN
CREATE TYPE dental.cara_dental AS ENUM (
'mesial', 'distal', 'oclusal', 'incisal',
'vestibular', 'bucal', 'lingual', 'palatino'
);
EXCEPTION WHEN duplicate_object THEN NULL;
END $$;
DO $$ BEGIN
CREATE TYPE dental.estado_tratamiento AS ENUM (
'pendiente', 'en_proceso', 'completado', 'cancelado'
);
EXCEPTION WHEN duplicate_object THEN NULL;
END $$;
DO $$ BEGIN
CREATE TYPE dental.tipo_ortodoncia AS ENUM (
'brackets_metalicos', 'brackets_esteticos', 'brackets_linguales',
'alineadores', 'removible', 'retenedor'
);
EXCEPTION WHEN duplicate_object THEN NULL;
END $$;
-- ============================================================================
-- CATÁLOGOS
-- ============================================================================
-- Piezas dentales
CREATE TABLE IF NOT EXISTS dental.piezas_dentales (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
numero VARCHAR(10) NOT NULL UNIQUE, -- '11', '12', ... '48', '51'...'85'
nombre VARCHAR(50) NOT NULL,
cuadrante INTEGER NOT NULL CHECK (cuadrante BETWEEN 1 AND 8),
es_temporal BOOLEAN DEFAULT false,
descripcion TEXT,
created_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.piezas_dentales IS 'Catálogo de piezas dentales (nomenclatura FDI)';
-- Tratamientos dentales
CREATE TABLE IF NOT EXISTS dental.tratamientos_catalogo (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(100) NOT NULL,
categoria VARCHAR(50), -- 'prevencion', 'restauracion', 'endodoncia', etc.
descripcion TEXT,
duracion_minutos INTEGER DEFAULT 30,
precio_base NUMERIC(10,2),
requiere_rx BOOLEAN DEFAULT false,
requiere_anestesia BOOLEAN DEFAULT false,
active BOOLEAN DEFAULT true,
created_at TIMESTAMPTZ DEFAULT NOW(),
CONSTRAINT uq_tratamientos_tenant_codigo UNIQUE(tenant_id, codigo)
);
COMMENT ON TABLE dental.tratamientos_catalogo IS 'Catálogo de tratamientos dentales';
-- ============================================================================
-- TABLAS PRINCIPALES
-- ============================================================================
-- Odontograma
CREATE TABLE IF NOT EXISTS dental.odontogramas (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
patient_id UUID NOT NULL, -- Referencia a clinica.patients
fecha_creacion DATE NOT NULL DEFAULT CURRENT_DATE,
fecha_actualizacion DATE,
notas TEXT,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.odontogramas IS 'Odontogramas de pacientes';
-- Estado de piezas dentales por odontograma
CREATE TABLE IF NOT EXISTS dental.odontograma_piezas (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
odontograma_id UUID NOT NULL REFERENCES dental.odontogramas(id) ON DELETE CASCADE,
pieza_id UUID NOT NULL REFERENCES dental.piezas_dentales(id),
-- Estado general
estado dental.estado_pieza DEFAULT 'sano',
-- Estados por cara (JSONB para flexibilidad)
caras_afectadas JSONB, -- {"mesial": "caries", "oclusal": "obturacion"}
-- Notas
observaciones TEXT,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW(),
CONSTRAINT uq_odontograma_pieza UNIQUE(odontograma_id, pieza_id)
);
COMMENT ON TABLE dental.odontograma_piezas IS 'Estado de cada pieza dental en el odontograma';
-- Tratamientos de paciente
CREATE TABLE IF NOT EXISTS dental.tratamientos_paciente (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
patient_id UUID NOT NULL,
odontograma_id UUID REFERENCES dental.odontogramas(id),
tratamiento_id UUID REFERENCES dental.tratamientos_catalogo(id),
odontologo_id UUID, -- Referencia a clinica.doctors
consultation_id UUID, -- Referencia a clinica.consultations
-- Pieza(s) tratada(s)
pieza_id UUID REFERENCES dental.piezas_dentales(id),
caras_tratadas dental.cara_dental[],
-- Datos del tratamiento
fecha_inicio DATE NOT NULL DEFAULT CURRENT_DATE,
fecha_fin DATE,
estado dental.estado_tratamiento DEFAULT 'pendiente',
-- Costo
precio NUMERIC(10,2),
descuento NUMERIC(5,2) DEFAULT 0,
precio_final NUMERIC(10,2),
-- Notas
notas TEXT,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.tratamientos_paciente IS 'Tratamientos realizados a pacientes';
-- Ortodoncia
CREATE TABLE IF NOT EXISTS dental.ortodoncia (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
patient_id UUID NOT NULL,
odontologo_id UUID,
-- Tipo de tratamiento
tipo dental.tipo_ortodoncia NOT NULL,
marca VARCHAR(100),
-- Fechas
fecha_inicio DATE NOT NULL,
fecha_estimada_fin DATE,
fecha_real_fin DATE,
-- Estado
estado dental.estado_tratamiento DEFAULT 'en_proceso',
meses_estimados INTEGER,
-- Costo
costo_total NUMERIC(10,2),
enganche NUMERIC(10,2),
mensualidad NUMERIC(10,2),
-- Notas
notas TEXT,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.ortodoncia IS 'Tratamientos de ortodoncia';
-- Citas de ortodoncia (seguimiento)
CREATE TABLE IF NOT EXISTS dental.ortodoncia_citas (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
ortodoncia_id UUID NOT NULL REFERENCES dental.ortodoncia(id) ON DELETE CASCADE,
appointment_id UUID, -- Referencia a clinica.appointments
-- Datos de la cita
fecha DATE NOT NULL,
numero_cita INTEGER,
-- Procedimiento
procedimiento TEXT,
arco_superior VARCHAR(50),
arco_inferior VARCHAR(50),
ligas VARCHAR(50),
-- Observaciones
observaciones TEXT,
proxima_cita DATE,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.ortodoncia_citas IS 'Citas de seguimiento de ortodoncia';
-- Prótesis
CREATE TABLE IF NOT EXISTS dental.protesis (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
patient_id UUID NOT NULL,
odontologo_id UUID,
-- Tipo
tipo VARCHAR(50) NOT NULL, -- 'corona', 'puente', 'parcial', 'total', 'implante'
-- Piezas involucradas
piezas_involucradas TEXT[], -- ['11', '12', '13']
-- Laboratorio
laboratorio_id UUID, -- Referencia a proveedor
fecha_envio_lab DATE,
fecha_recepcion_lab DATE,
-- Material
material VARCHAR(100),
color VARCHAR(50),
-- Estado
estado dental.estado_tratamiento DEFAULT 'en_proceso',
fecha_colocacion DATE,
-- Garantía
tiene_garantia BOOLEAN DEFAULT false,
meses_garantia INTEGER,
-- Costo
costo_laboratorio NUMERIC(10,2),
precio_paciente NUMERIC(10,2),
-- Notas
notas TEXT,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.protesis IS 'Registro de prótesis dentales';
-- Radiografías
CREATE TABLE IF NOT EXISTS dental.radiografias (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
patient_id UUID NOT NULL,
consultation_id UUID,
-- Tipo
tipo VARCHAR(50) NOT NULL, -- 'periapical', 'panoramica', 'cefalometrica', 'oclusal'
pieza_id UUID REFERENCES dental.piezas_dentales(id),
-- Archivo
fecha DATE NOT NULL DEFAULT CURRENT_DATE,
url_imagen VARCHAR(255),
-- Interpretación
interpretacion TEXT,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.radiografias IS 'Registro de radiografías dentales';
-- Presupuestos
CREATE TABLE IF NOT EXISTS dental.presupuestos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
patient_id UUID NOT NULL,
odontologo_id UUID,
-- Datos
numero VARCHAR(20),
fecha DATE NOT NULL DEFAULT CURRENT_DATE,
fecha_vencimiento DATE,
-- Estado
estado VARCHAR(20) DEFAULT 'pendiente', -- 'pendiente', 'aprobado', 'rechazado', 'vencido'
-- Totales
subtotal NUMERIC(12,2) DEFAULT 0,
descuento_porcentaje NUMERIC(5,2) DEFAULT 0,
descuento_monto NUMERIC(12,2) DEFAULT 0,
total NUMERIC(12,2) DEFAULT 0,
-- Plan de pago
requiere_financiamiento BOOLEAN DEFAULT false,
enganche NUMERIC(12,2),
numero_pagos INTEGER,
monto_pago NUMERIC(12,2),
-- Notas
notas TEXT,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.presupuestos IS 'Presupuestos de tratamiento';
-- Líneas de presupuesto
CREATE TABLE IF NOT EXISTS dental.presupuesto_lineas (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL,
presupuesto_id UUID NOT NULL REFERENCES dental.presupuestos(id) ON DELETE CASCADE,
tratamiento_id UUID REFERENCES dental.tratamientos_catalogo(id),
-- Pieza
pieza_id UUID REFERENCES dental.piezas_dentales(id),
descripcion TEXT,
-- Cantidades
cantidad INTEGER DEFAULT 1,
precio_unitario NUMERIC(10,2),
descuento NUMERIC(5,2) DEFAULT 0,
subtotal NUMERIC(10,2),
-- Secuencia
sequence INTEGER DEFAULT 10,
-- Control
created_at TIMESTAMPTZ DEFAULT NOW()
);
COMMENT ON TABLE dental.presupuesto_lineas IS 'Líneas de presupuesto';
-- ============================================================================
-- EXTENSIONES A TABLAS DE ERP-CLINICAS
-- ============================================================================
DO $$
BEGIN
-- Extensión a clinica.patients
IF EXISTS (SELECT 1 FROM information_schema.tables
WHERE table_schema = 'clinica' AND table_name = 'patients') THEN
IF NOT EXISTS (SELECT 1 FROM information_schema.columns
WHERE table_schema = 'clinica' AND table_name = 'patients'
AND column_name = 'odontograma_activo_id') THEN
ALTER TABLE clinica.patients ADD COLUMN odontograma_activo_id UUID;
END IF;
IF NOT EXISTS (SELECT 1 FROM information_schema.columns
WHERE table_schema = 'clinica' AND table_name = 'patients'
AND column_name = 'tiene_ortodoncia') THEN
ALTER TABLE clinica.patients ADD COLUMN tiene_ortodoncia BOOLEAN DEFAULT false;
END IF;
IF NOT EXISTS (SELECT 1 FROM information_schema.columns
WHERE table_schema = 'clinica' AND table_name = 'patients'
AND column_name = 'tiene_protesis') THEN
ALTER TABLE clinica.patients ADD COLUMN tiene_protesis BOOLEAN DEFAULT false;
END IF;
END IF;
END $$;
-- ============================================================================
-- SEED: Piezas dentales (catálogo global)
-- ============================================================================
INSERT INTO dental.piezas_dentales (numero, nombre, cuadrante, es_temporal) VALUES
-- Cuadrante 1 - Superior derecho (permanentes)
('18', 'Tercer molar superior derecho', 1, false),
('17', 'Segundo molar superior derecho', 1, false),
('16', 'Primer molar superior derecho', 1, false),
('15', 'Segundo premolar superior derecho', 1, false),
('14', 'Primer premolar superior derecho', 1, false),
('13', 'Canino superior derecho', 1, false),
('12', 'Incisivo lateral superior derecho', 1, false),
('11', 'Incisivo central superior derecho', 1, false),
-- Cuadrante 2 - Superior izquierdo (permanentes)
('21', 'Incisivo central superior izquierdo', 2, false),
('22', 'Incisivo lateral superior izquierdo', 2, false),
('23', 'Canino superior izquierdo', 2, false),
('24', 'Primer premolar superior izquierdo', 2, false),
('25', 'Segundo premolar superior izquierdo', 2, false),
('26', 'Primer molar superior izquierdo', 2, false),
('27', 'Segundo molar superior izquierdo', 2, false),
('28', 'Tercer molar superior izquierdo', 2, false),
-- Cuadrante 3 - Inferior izquierdo (permanentes)
('31', 'Incisivo central inferior izquierdo', 3, false),
('32', 'Incisivo lateral inferior izquierdo', 3, false),
('33', 'Canino inferior izquierdo', 3, false),
('34', 'Primer premolar inferior izquierdo', 3, false),
('35', 'Segundo premolar inferior izquierdo', 3, false),
('36', 'Primer molar inferior izquierdo', 3, false),
('37', 'Segundo molar inferior izquierdo', 3, false),
('38', 'Tercer molar inferior izquierdo', 3, false),
-- Cuadrante 4 - Inferior derecho (permanentes)
('41', 'Incisivo central inferior derecho', 4, false),
('42', 'Incisivo lateral inferior derecho', 4, false),
('43', 'Canino inferior derecho', 4, false),
('44', 'Primer premolar inferior derecho', 4, false),
('45', 'Segundo premolar inferior derecho', 4, false),
('46', 'Primer molar inferior derecho', 4, false),
('47', 'Segundo molar inferior derecho', 4, false),
('48', 'Tercer molar inferior derecho', 4, false),
-- Cuadrante 5 - Superior derecho (temporales)
('55', 'Segundo molar temporal superior derecho', 5, true),
('54', 'Primer molar temporal superior derecho', 5, true),
('53', 'Canino temporal superior derecho', 5, true),
('52', 'Incisivo lateral temporal superior derecho', 5, true),
('51', 'Incisivo central temporal superior derecho', 5, true),
-- Cuadrante 6 - Superior izquierdo (temporales)
('61', 'Incisivo central temporal superior izquierdo', 6, true),
('62', 'Incisivo lateral temporal superior izquierdo', 6, true),
('63', 'Canino temporal superior izquierdo', 6, true),
('64', 'Primer molar temporal superior izquierdo', 6, true),
('65', 'Segundo molar temporal superior izquierdo', 6, true),
-- Cuadrante 7 - Inferior izquierdo (temporales)
('71', 'Incisivo central temporal inferior izquierdo', 7, true),
('72', 'Incisivo lateral temporal inferior izquierdo', 7, true),
('73', 'Canino temporal inferior izquierdo', 7, true),
('74', 'Primer molar temporal inferior izquierdo', 7, true),
('75', 'Segundo molar temporal inferior izquierdo', 7, true),
-- Cuadrante 8 - Inferior derecho (temporales)
('81', 'Incisivo central temporal inferior derecho', 8, true),
('82', 'Incisivo lateral temporal inferior derecho', 8, true),
('83', 'Canino temporal inferior derecho', 8, true),
('84', 'Primer molar temporal inferior derecho', 8, true),
('85', 'Segundo molar temporal inferior derecho', 8, true)
ON CONFLICT (numero) DO NOTHING;
-- ============================================================================
-- ÍNDICES
-- ============================================================================
CREATE INDEX IF NOT EXISTS idx_tratamientos_catalogo_tenant ON dental.tratamientos_catalogo(tenant_id);
CREATE INDEX IF NOT EXISTS idx_tratamientos_catalogo_categoria ON dental.tratamientos_catalogo(tenant_id, categoria);
CREATE INDEX IF NOT EXISTS idx_odontogramas_tenant ON dental.odontogramas(tenant_id);
CREATE INDEX IF NOT EXISTS idx_odontogramas_patient ON dental.odontogramas(patient_id);
CREATE INDEX IF NOT EXISTS idx_odontograma_piezas_odontograma ON dental.odontograma_piezas(odontograma_id);
CREATE INDEX IF NOT EXISTS idx_odontograma_piezas_pieza ON dental.odontograma_piezas(pieza_id);
CREATE INDEX IF NOT EXISTS idx_tratamientos_paciente_tenant ON dental.tratamientos_paciente(tenant_id);
CREATE INDEX IF NOT EXISTS idx_tratamientos_paciente_patient ON dental.tratamientos_paciente(patient_id);
CREATE INDEX IF NOT EXISTS idx_tratamientos_paciente_estado ON dental.tratamientos_paciente(tenant_id, estado);
CREATE INDEX IF NOT EXISTS idx_ortodoncia_tenant ON dental.ortodoncia(tenant_id);
CREATE INDEX IF NOT EXISTS idx_ortodoncia_patient ON dental.ortodoncia(patient_id);
CREATE INDEX IF NOT EXISTS idx_ortodoncia_estado ON dental.ortodoncia(tenant_id, estado);
CREATE INDEX IF NOT EXISTS idx_ortodoncia_citas_ortodoncia ON dental.ortodoncia_citas(ortodoncia_id);
CREATE INDEX IF NOT EXISTS idx_protesis_tenant ON dental.protesis(tenant_id);
CREATE INDEX IF NOT EXISTS idx_protesis_patient ON dental.protesis(patient_id);
CREATE INDEX IF NOT EXISTS idx_radiografias_tenant ON dental.radiografias(tenant_id);
CREATE INDEX IF NOT EXISTS idx_radiografias_patient ON dental.radiografias(patient_id);
CREATE INDEX IF NOT EXISTS idx_presupuestos_tenant ON dental.presupuestos(tenant_id);
CREATE INDEX IF NOT EXISTS idx_presupuestos_patient ON dental.presupuestos(patient_id);
CREATE INDEX IF NOT EXISTS idx_presupuestos_estado ON dental.presupuestos(tenant_id, estado);
CREATE INDEX IF NOT EXISTS idx_presupuesto_lineas_presupuesto ON dental.presupuesto_lineas(presupuesto_id);
-- ============================================================================
-- RLS
-- ============================================================================
ALTER TABLE dental.tratamientos_catalogo ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.odontogramas ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.odontograma_piezas ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.tratamientos_paciente ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.ortodoncia ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.ortodoncia_citas ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.protesis ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.radiografias ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.presupuestos ENABLE ROW LEVEL SECURITY;
ALTER TABLE dental.presupuesto_lineas ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation_tratamientos_cat ON dental.tratamientos_catalogo;
CREATE POLICY tenant_isolation_tratamientos_cat ON dental.tratamientos_catalogo
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_odontogramas ON dental.odontogramas;
CREATE POLICY tenant_isolation_odontogramas ON dental.odontogramas
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_odontograma_piezas ON dental.odontograma_piezas;
CREATE POLICY tenant_isolation_odontograma_piezas ON dental.odontograma_piezas
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_tratamientos_pac ON dental.tratamientos_paciente;
CREATE POLICY tenant_isolation_tratamientos_pac ON dental.tratamientos_paciente
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_ortodoncia ON dental.ortodoncia;
CREATE POLICY tenant_isolation_ortodoncia ON dental.ortodoncia
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_ortodoncia_citas ON dental.ortodoncia_citas;
CREATE POLICY tenant_isolation_ortodoncia_citas ON dental.ortodoncia_citas
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_protesis ON dental.protesis;
CREATE POLICY tenant_isolation_protesis ON dental.protesis
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_radiografias ON dental.radiografias;
CREATE POLICY tenant_isolation_radiografias ON dental.radiografias
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_presupuestos ON dental.presupuestos;
CREATE POLICY tenant_isolation_presupuestos ON dental.presupuestos
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
DROP POLICY IF EXISTS tenant_isolation_presupuesto_lineas ON dental.presupuesto_lineas;
CREATE POLICY tenant_isolation_presupuesto_lineas ON dental.presupuesto_lineas
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
-- ============================================================================
-- FIN DENTAL SCHEMA
-- ============================================================================

View File

@ -0,0 +1,101 @@
-- ============================================================================
-- SEED DATA: Catálogos de Clínica Dental
-- Especialización de ERP-Clínicas
-- ============================================================================
-- NOTA: Ejecutar después de SET app.current_tenant_id = 'UUID-DEL-TENANT';
-- ============================================================================
-- Tratamientos dentales
INSERT INTO dental.tratamientos_catalogo (tenant_id, codigo, nombre, categoria, duracion_minutos, precio_base, requiere_rx, requiere_anestesia)
SELECT current_setting('app.current_tenant_id', true)::UUID, codigo, nombre, categoria, duracion, precio, rx, anestesia
FROM (VALUES
-- Prevención
('PREV-001', 'Limpieza dental básica', 'prevencion', 45, 600.00, false, false),
('PREV-002', 'Limpieza dental profunda', 'prevencion', 60, 1200.00, false, true),
('PREV-003', 'Aplicación de flúor', 'prevencion', 15, 300.00, false, false),
('PREV-004', 'Sellador de fosetas', 'prevencion', 20, 400.00, false, false),
-- Restauración
('REST-001', 'Resina simple (1 cara)', 'restauracion', 30, 800.00, true, true),
('REST-002', 'Resina compuesta (2 caras)', 'restauracion', 45, 1000.00, true, true),
('REST-003', 'Resina compleja (3+ caras)', 'restauracion', 60, 1300.00, true, true),
('REST-004', 'Incrustación de resina', 'restauracion', 90, 2500.00, true, true),
('REST-005', 'Incrustación de porcelana', 'restauracion', 90, 4000.00, true, true),
-- Endodoncia
('ENDO-001', 'Endodoncia unirradicular', 'endodoncia', 60, 3000.00, true, true),
('ENDO-002', 'Endodoncia birradicular', 'endodoncia', 90, 4000.00, true, true),
('ENDO-003', 'Endodoncia multirradicular', 'endodoncia', 120, 5000.00, true, true),
('ENDO-004', 'Retratamiento endodóntico', 'endodoncia', 120, 5500.00, true, true),
-- Periodoncia
('PERIO-001', 'Raspado y alisado radicular (cuadrante)', 'periodoncia', 60, 1500.00, true, true),
('PERIO-002', 'Cirugía periodontal', 'periodoncia', 120, 6000.00, true, true),
-- Cirugía
('CIRUG-001', 'Extracción simple', 'cirugia', 30, 800.00, true, true),
('CIRUG-002', 'Extracción de tercer molar', 'cirugia', 60, 3500.00, true, true),
('CIRUG-003', 'Extracción quirúrgica compleja', 'cirugia', 90, 5000.00, true, true),
-- Prótesis
('PROT-001', 'Corona de porcelana', 'protesis', 60, 6000.00, true, true),
('PROT-002', 'Corona de zirconia', 'protesis', 60, 8000.00, true, true),
('PROT-003', 'Puente fijo (3 unidades)', 'protesis', 120, 18000.00, true, true),
('PROT-004', 'Prótesis parcial removible', 'protesis', 120, 8000.00, true, false),
('PROT-005', 'Prótesis total', 'protesis', 180, 12000.00, true, false),
-- Implantes
('IMPL-001', 'Implante dental (sin corona)', 'implantes', 90, 15000.00, true, true),
('IMPL-002', 'Corona sobre implante', 'implantes', 60, 8000.00, false, false),
-- Ortodoncia
('ORTO-001', 'Brackets metálicos (tratamiento completo)', 'ortodoncia', 60, 35000.00, true, false),
('ORTO-002', 'Brackets estéticos (tratamiento completo)', 'ortodoncia', 60, 45000.00, true, false),
('ORTO-003', 'Alineadores invisibles', 'ortodoncia', 45, 60000.00, true, false),
('ORTO-004', 'Control mensual ortodoncia', 'ortodoncia', 30, 800.00, false, false),
('ORTO-005', 'Retenedor fijo', 'ortodoncia', 45, 3000.00, false, false),
-- Estética
('ESTE-001', 'Blanqueamiento en consultorio', 'estetica', 90, 5000.00, false, false),
('ESTE-002', 'Blanqueamiento casero', 'estetica', 30, 3000.00, false, false),
('ESTE-003', 'Carilla de resina', 'estetica', 60, 3500.00, false, false),
('ESTE-004', 'Carilla de porcelana', 'estetica', 60, 8000.00, false, false),
-- Diagnóstico
('DIAG-001', 'Radiografía periapical', 'diagnostico', 5, 100.00, false, false),
('DIAG-002', 'Radiografía panorámica', 'diagnostico', 10, 500.00, false, false),
('DIAG-003', 'Radiografía cefalométrica', 'diagnostico', 10, 400.00, false, false),
('DIAG-004', 'Tomografía dental', 'diagnostico', 15, 1500.00, false, false)
) AS t(codigo, nombre, categoria, duracion, precio, rx, anestesia)
WHERE current_setting('app.current_tenant_id', true) IS NOT NULL
AND current_setting('app.current_tenant_id', true) != ''
ON CONFLICT (tenant_id, codigo) DO NOTHING;
-- Skills específicos dentales
INSERT INTO hr.skills (tenant_id, skill_type_id, name, requiere_cedula)
SELECT
current_setting('app.current_tenant_id', true)::UUID,
st.id,
unnest(ARRAY[
'Odontología General',
'Ortodoncia',
'Endodoncia',
'Periodoncia',
'Cirugía Maxilofacial',
'Odontopediatría',
'Prostodoncia',
'Implantología',
'Estética Dental',
'Rehabilitación Oral'
]),
true
FROM hr.skill_types st
WHERE st.name = 'Especialidad Médica'
AND st.tenant_id = current_setting('app.current_tenant_id', true)::UUID
ON CONFLICT DO NOTHING;
-- Ubicaciones (unidades dentales)
INSERT INTO hr.work_locations (tenant_id, name, tipo_consultorio, capacidad, equipamiento)
SELECT current_setting('app.current_tenant_id', true)::UUID, name, tipo, capacidad, equipamiento::TEXT[]
FROM (VALUES
('Unidad Dental 1', 'especialidad', 1, ARRAY['sillon', 'rayos_x', 'ultrasonido']),
('Unidad Dental 2', 'especialidad', 1, ARRAY['sillon', 'rayos_x', 'ultrasonido']),
('Unidad Dental 3', 'especialidad', 1, ARRAY['sillon', 'rayos_x']),
('Quirófano Dental', 'quirofano', 1, ARRAY['sillon', 'rayos_x', 'equipo_cirugia']),
('Sala de Rayos X', 'laboratorio', 2, ARRAY['panoramico', 'cefalometrico']),
('Laboratorio Dental', 'laboratorio', 2, ARRAY['modelos', 'protesis'])
) AS t(name, tipo, capacidad, equipamiento)
WHERE current_setting('app.current_tenant_id', true) IS NOT NULL
AND current_setting('app.current_tenant_id', true) != ''
ON CONFLICT DO NOTHING;

View File

@ -1,37 +0,0 @@
# VISION GENERAL: CLINICA DENTAL
**Proyecto:** Clinica Dental
**Tipo:** Vertical ERP Clinicas - Especializacion Dental
**Sistema:** NEXUS v4.0 + SIMCO
**Actualizado:** 2026-01-10
---
## Documentos en esta Seccion
| Documento | Descripcion |
|-----------|-------------|
| README.md | Introduccion al proyecto |
| VISION.md | Vision estrategica del producto |
---
## Navegacion
| Destino | Enlace |
|---------|--------|
| Indice docs/ | [../_MAP.md](../_MAP.md) |
| Orquestacion | [../../orchestration/_MAP.md](../../orchestration/_MAP.md) |
| Contexto Proyecto | [../../orchestration/00-guidelines/CONTEXTO-PROYECTO.md](../../orchestration/00-guidelines/CONTEXTO-PROYECTO.md) |
---
## Herencia
Este proyecto hereda de:
- **erp-clinicas** (vertical de clinicas)
- **erp-core** (base ERP)
---
**Actualizado:** 2026-01-10

View File

@ -1,232 +0,0 @@
---
id: MGN-016-billing
title: Modulo Billing - Suscripciones para Clinica Dental
type: ModuleOverview
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
module: billing
priority: P0
normativas: [NOM-013-SSA2-2015, CFDI-4.0]
---
# MGN-016: Billing - Sistema de Facturacion y Suscripciones Dentales
## Resumen Ejecutivo
El modulo Billing implementa el sistema de facturacion y suscripciones para consultorios y clinicas dentales, integrando Stripe Billing como proveedor de pagos. Permite gestionar suscripciones por tipo de consultorio (individual, grupal, centro dental), periodos de prueba, upgrades/downgrades y facturacion automatica con soporte para CFDI 4.0.
---
## Objetivos
### Objetivo Principal
Implementar un sistema de billing completo para clinicas dentales que permita:
- Suscripciones mensuales y anuales por tipo de consultorio
- Planes diferenciados por numero de sillones dentales
- Facturacion automatica recurrente con CFDI 4.0
- Portal de cliente self-service via Stripe
### Objetivos Secundarios
- Sincronizacion bidireccional con Stripe via webhooks
- Soporte para periodos de prueba (14 dias)
- Manejo de pagos fallidos y dunning
- Historial de facturas accesible para clinicas
- Facturacion adicional por servicios especiales
---
## Planes para Clinica Dental
| Plan | Precio/mes | Sillones | Usuarios | Storage | Features |
|------|------------|----------|----------|---------|----------|
| **Consultorio** | $499 MXN | 1 | 3 | 5 GB | Odontograma, Citas, Expedientes |
| **Clinica** | $1,499 MXN | 5 | 15 | 25 GB | + Ortodoncia, Radiografias, Reportes |
| **Centro Dental** | $3,999 MXN | Ilimitado | Ilimitado | 100 GB | + IA, WhatsApp, Multi-sucursal |
---
## Alcance
### Incluido (In Scope)
| Caracteristica | Descripcion | Prioridad |
|----------------|-------------|-----------|
| Stripe Billing | Integracion completa con Stripe | P0 |
| Planes dentales | Consultorio, Clinica, Centro | P0 |
| Suscripciones | Crear, actualizar, cancelar | P0 |
| Webhooks Stripe | Recibir y procesar eventos | P0 |
| Portal cliente | Redirect a Stripe Customer Portal | P0 |
| CFDI 4.0 | Generacion de facturas fiscales | P0 |
| Pagos OXXO | Soporte para pago en efectivo | P1 |
| Invoices | Historial con PDF | P1 |
### Excluido (Out of Scope)
| Caracteristica | Razon | Fase Futura |
|----------------|-------|-------------|
| Multi-currency | Solo MXN por ahora | Fase 2 |
| Servicios adicionales | Pagos one-time | Fase 2 |
| Facturacion por tratamiento | Complejidad | Fase 3 |
---
## Arquitectura
### Diagrama de Integracion
```
+-------------------+ +-------------------+ +-------------------+
| Frontend |---->| Billing API |---->| Stripe API |
| (Checkout) | | (NestJS) | | |
+-------------------+ +-------------------+ +-------------------+
| |
+-------+---------+ |
| | v
+----------+ +-----------+ +-------------+
| Plans DB | | Invoices | | Webhooks |
| (Dental) | | + CFDI | | (events) |
+----------+ +-----------+ +-------------+
|
v
+-----------+
| SAT/CFDI |
| Timbrado |
+-----------+
```
### Flujo de Suscripcion Dental
```
1. Dentista selecciona plan en frontend
|
2. Frontend llama POST /billing/checkout
|
3. Backend crea Checkout Session en Stripe
|
4. Backend retorna URL de Stripe Checkout
|
5. Frontend redirige a Stripe Checkout
|
6. Dentista paga (tarjeta o OXXO)
|
7. Stripe envia webhook: checkout.session.completed
|
8. Backend crea/actualiza subscription en DB
|
9. Backend activa features del plan (sillones, odontograma, etc.)
|
10. Clinica operativa con funcionalidades activas
```
---
## Facturacion CFDI 4.0
### Datos Requeridos
- RFC de la clinica
- Razon social
- Regimen fiscal
- Uso CFDI (G03 - Gastos en general)
- Codigo postal fiscal
### Flujo de Facturacion
```
1. Stripe cobra suscripcion
|
2. Webhook notifica pago exitoso
|
3. Backend genera pre-CFDI
|
4. Envia a PAC para timbrado
|
5. Almacena XML y PDF
|
6. Notifica a clinica via email
```
---
## Dependencias
### Modulos Prerequisito
| Modulo | Tipo | Descripcion |
|--------|------|-------------|
| MGN-001-auth | Requerido | Autenticacion JWT |
| MGN-002-users | Requerido | Usuario owner clinica |
| MGN-004-tenants | Requerido | Contexto multi-tenant |
| MGN-007-audit | Requerido | Logs de cambios |
### Servicios Externos
| Servicio | Proposito | Requerido |
|----------|-----------|-----------|
| Stripe | Billing y pagos | Si |
| PAC CFDI | Timbrado facturas | Si |
| Redis | Cache de planes | Opcional |
---
## Seguridad y Normativas
| Medida | Implementacion |
|--------|----------------|
| PCI Compliance | No almacenar datos de tarjeta |
| Webhook Signature | Verificar Stripe-Signature |
| CFDI Seguro | Almacenar XMLs firmados |
| Access Control | Solo owner gestiona billing |
| NOM-013-SSA2-2015 | Registro de servicios |
| LFPDPPP | Proteccion datos clinica |
---
## Configuracion
### Variables de Entorno
```bash
# Stripe
STRIPE_SECRET_KEY=sk_live_xxx
STRIPE_PUBLISHABLE_KEY=pk_live_xxx
STRIPE_WEBHOOK_SECRET=whsec_xxx
# Billing Config Dental
BILLING_TRIAL_DAYS=14
BILLING_DEFAULT_PLAN=consultorio
BILLING_SUCCESS_URL=https://clinica.ejemplo.com/billing/success
BILLING_CANCEL_URL=https://clinica.ejemplo.com/billing/cancel
# CFDI
CFDI_PAC_URL=https://pac.ejemplo.com
CFDI_PAC_USER=xxx
CFDI_PAC_PASSWORD=xxx
```
---
## Indices
- [Requerimientos Funcionales](requerimientos/INDICE-RF-BILLING.md)
- [Especificaciones Tecnicas](especificaciones/INDICE-ET-BILLING.md)
- [Historias de Usuario](historias-usuario/INDICE-US-BILLING.md)
- [Trazabilidad](implementacion/TRACEABILITY.yml)
---
## Referencias
- [erp-core/MGN-016-billing](../../../../../erp-core/docs/04-fase-saas/MGN-016-billing/) - Origen
- [Stripe Billing Docs](https://stripe.com/docs/billing) - Documentacion oficial
- [SAT CFDI 4.0](https://www.sat.gob.mx/consultas/42214/cfdi-version-4.0) - Especificacion
---
*Modulo: MGN-016-billing | Clinica Dental | Version: 1.0.0*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,112 +0,0 @@
---
id: MAP-MGN-016-billing
title: Mapa de Navegacion - Modulo Billing
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - MGN-016: Billing Dental
## Estructura del Modulo
```
MGN-016-billing/
+-- README.md <- Vision general del modulo
+-- _MAP.md <- ESTE ARCHIVO
|
+-- requerimientos/ <- Requerimientos funcionales
| +-- INDICE-RF-BILLING.md <- Indice de RFs
| +-- RF-BILLING-001.md <- Suscripciones dentales
| +-- RF-BILLING-002.md <- Webhooks de Stripe
| +-- RF-BILLING-003.md <- Portal cliente
| +-- RF-BILLING-004.md <- Facturacion CFDI 4.0
|
+-- especificaciones/ <- Especificaciones tecnicas
| +-- INDICE-ET-BILLING.md <- Indice de ETs
| +-- ET-BILLING-DATABASE.md <- Modelo de datos SQL
| +-- ET-BILLING-BACKEND.md <- API endpoints y servicios
| +-- ET-BILLING-FRONTEND.md <- Componentes UI
|
+-- historias-usuario/ <- User stories
| +-- INDICE-US-BILLING.md <- Indice de USs
|
+-- implementacion/ <- Artefactos de implementacion
+-- TRACEABILITY.yml <- Matriz de trazabilidad
```
---
## Indice de Documentos
### Vision General
| Documento | Descripcion | Estado |
|-----------|-------------|--------|
| [README.md](README.md) | Vision general del modulo Billing Dental | Draft |
### Requerimientos Funcionales
| ID | Documento | Descripcion | Estado |
|----|-----------|-------------|--------|
| RF-BILLING-001 | Suscripciones | Planes: Consultorio, Clinica, Centro | Draft |
| RF-BILLING-002 | Webhooks | Procesamiento de webhooks Stripe | Draft |
| RF-BILLING-003 | Portal | Portal de cliente Stripe | Draft |
| RF-BILLING-004 | CFDI | Facturacion CFDI 4.0 | Draft |
### Especificaciones Tecnicas
| ID | Documento | Descripcion | Estado |
|----|-----------|-------------|--------|
| ET-BILLING-DATABASE | Database | Modelo de datos (plans, subscriptions) | Draft |
| ET-BILLING-BACKEND | Backend | API endpoints NestJS | Draft |
| ET-BILLING-FRONTEND | Frontend | Componentes React | Draft |
---
## Planes Dentales
| Plan | Precio | Sillones | Features |
|------|--------|----------|----------|
| Consultorio | $499/mes | 1 | Basico |
| Clinica | $1,499/mes | 5 | + Ortodoncia, Radiografias |
| Centro Dental | $3,999/mes | Ilimitado | + IA, WhatsApp |
---
## Flujo de Navegacion Recomendado
### Para Entender el Modulo
```
1. README.md -> Vision general y planes
2. RF-BILLING-001.md -> Suscripciones dentales
3. ET-BILLING-DATABASE.md -> Modelo de datos
4. ET-BILLING-BACKEND.md -> API y servicios
```
### Para Implementar
```
1. ET-BILLING-DATABASE.md -> Crear schema billing
2. ET-BILLING-BACKEND.md -> Implementar servicios Stripe
3. ET-BILLING-FRONTEND.md -> Crear UI de suscripcion
4. TRACEABILITY.yml -> Verificar completitud
```
---
## Referencias Externas
| Recurso | URL |
|---------|-----|
| Stripe Billing | https://stripe.com/docs/billing |
| Stripe Webhooks | https://stripe.com/docs/webhooks |
| SAT CFDI 4.0 | https://www.sat.gob.mx/consultas/42214/cfdi-version-4.0 |
---
*Mapa de Navegacion | MGN-016-billing | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,173 +0,0 @@
---
id: MGN-017-plans
title: Modulo Plans - Planes y Feature Gating para Clinica Dental
type: Module
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
source: erp-core/MGN-017-plans
normativas: [NOM-013-SSA2-2015]
---
# MGN-017: Modulo Plans - Planes y Feature Gating Dental
## Descripcion
El modulo **Plans** gestiona la definicion de planes de suscripcion para clinicas dentales, feature gating por plan, y enforcement de limites y cuotas por consultorio. Controla acceso a funcionalidades especializadas como odontograma digital, radiografias, ortodoncia 3D y herramientas de IA.
## Objetivos
1. **Definicion de Planes Dentales** - Planes diferenciados por tipo de consultorio
2. **Feature Gating Odontologico** - Control de acceso a funcionalidades dentales
3. **Limites por Sillon** - Enforcar limites por numero de sillones
4. **Usage Tracking** - Monitorear uso de funcionalidades
5. **Upgrade/Downgrade** - Flujos para cambio de plan
## Planes para Clinica Dental
| Plan | Precio/mes | Sillones | Usuarios | Storage | Pacientes/mes |
|------|------------|----------|----------|---------|---------------|
| **Consultorio** | $499 MXN | 1 | 3 | 5 GB | 100 |
| **Clinica** | $1,499 MXN | 5 | 15 | 25 GB | 500 |
| **Centro Dental** | $3,999 MXN | Ilimitado | Ilimitado | 100 GB | Ilimitado |
## Features por Plan
| Feature | Consultorio | Clinica | Centro Dental |
|---------|-------------|---------|---------------|
| odontograma_basico | Si | Si | Si |
| odontograma_digital | No | Si | Si |
| radiografias_digitales | No | Si | Si |
| ortodoncia_3d | No | No | Si |
| presupuestos_dentales | Si | Si | Si |
| reportes_basicos | Si | Si | Si |
| reportes_avanzados | No | Si | Si |
| whatsapp_business | No | No | Si |
| asistente_ia | No | No | Si |
| multi_sucursal | No | No | Si |
| api_access | No | Si | Si |
| exportar_datos | Si | Si | Si |
| historial_auditoria | 7 dias | 30 dias | 365 dias |
## Limites por Plan
| Limite | Consultorio | Clinica | Centro Dental |
|--------|-------------|---------|---------------|
| Sillones | 1 | 5 | Ilimitado |
| Usuarios | 3 | 15 | Ilimitado |
| Pacientes/mes | 100 | 500 | Ilimitado |
| Storage | 5 GB | 25 GB | 100 GB |
| Radiografias/mes | 50 | 250 | Ilimitado |
| API calls/mes | 0 | 10,000 | Ilimitado |
## Alcance
| Caracteristica | Incluido | Notas |
|----------------|----------|-------|
| Plans CRUD | Si | Admin only |
| Limites por sillon | Si | Enforcement estricto |
| Feature flags dentales | Si | Boolean y limites |
| Quota enforcement | Si | Middleware |
| Usage tracking | Si | Snapshots diarios |
| Usage alerts | Si | 80%, 90%, 100% |
| Overage billing | No | Fase posterior |
## Arquitectura
### Flujo de Quota Check
```
Request (ej: crear_radiografia)
|
v
+-------------------+
| QuotaMiddleware |-----> Permitido (si dentro de limite)
+-------------------+
|
v (check)
+-------------------+
| PlanLimitsService |
+-------------------+
|
v
+-------------------+
| Usage Tracking |
+-------------------+
|
v (excede limite)
QuotaExceededException -> "Limite de radiografias alcanzado"
```
### Prioridad de Evaluacion
1. **Tenant Override** - Maxima prioridad, excepciones manuales
2. **Plan Features** - Features incluidas en plan de la clinica
3. **Global Flag** - Valor default con soporte de rollout
## Casos de Uso Odontologicos
### Ejemplo: Verificar Feature Odontograma Digital
```typescript
// Controller
@Get('odontograma/digital')
@FeatureGuard('odontograma_digital')
async getDigitalOdontograma(@Tenant() tenant: Tenant) {
// Solo accesible para planes Clinica y Centro
return this.odontogramaService.getDigital(tenant.id);
}
```
### Ejemplo: Verificar Limite de Radiografias
```typescript
// Antes de crear radiografia
const canCreate = await this.quotaService.checkLimit(
tenantId,
'radiografias_mes',
1 // cantidad a crear
);
if (!canCreate) {
throw new QuotaExceededException(
'Limite de radiografias mensuales alcanzado. ' +
'Actualiza a plan Clinica para mas radiografias.'
);
}
```
## Contenido del Modulo
- [_MAP.md](./_MAP.md) - Indice del modulo
- [requerimientos/](./requerimientos/) - Requerimientos funcionales
- [especificaciones/](./especificaciones/) - Especificaciones tecnicas
- [historias-usuario/](./historias-usuario/) - User stories
- [implementacion/](./implementacion/) - Trazabilidad
## Dependencias
### Modulos Requeridos
- **MGN-001-tenants** - Gestion de tenants (tenant_id)
- **MGN-016-billing** - Suscripciones y pagos (plan_id)
### Modulos Dependientes
- Odontograma (feature gating)
- Radiografias (limites)
- Ortodoncia (feature gating)
- IA (feature gating)
- WhatsApp (feature gating)
## Referencias
- **Fuente:** [erp-core/MGN-017-plans](../../../../../erp-core/docs/04-fase-saas/MGN-017-plans/)
- **Billing:** [MGN-016-billing](../MGN-016-billing/)
- **Feature Flags:** [MGN-019-feature-flags](../MGN-019-feature-flags/)
---
*Modulo: MGN-017-plans | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,101 +0,0 @@
---
id: MAP-MGN-017-plans
title: Mapa de Navegacion - Modulo Plans
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - MGN-017: Plans Dental
## Estructura del Modulo
```
MGN-017-plans/
+-- README.md <- Vision general del modulo
+-- _MAP.md <- ESTE ARCHIVO
|
+-- requerimientos/ <- Requerimientos funcionales
| +-- INDICE-RF-PLANS.md <- Indice de RFs
| +-- RF-PLANS-001.md <- Definicion de planes dentales
| +-- RF-PLANS-002.md <- Feature gating
| +-- RF-PLANS-003.md <- Limites y cuotas
|
+-- especificaciones/ <- Especificaciones tecnicas
| +-- INDICE-ET-PLANS.md <- Indice de ETs
| +-- ET-PLANS-DATABASE.md <- Modelo de datos
| +-- ET-PLANS-BACKEND.md <- API y servicios
|
+-- historias-usuario/ <- User stories
| +-- INDICE-US-PLANS.md <- Indice de USs
|
+-- implementacion/ <- Artefactos
+-- TRACEABILITY.yml <- Matriz de trazabilidad
```
---
## Planes Dentales
| Plan | Precio | Sillones | Features Clave |
|------|--------|----------|----------------|
| Consultorio | $499/mes | 1 | Odontograma basico |
| Clinica | $1,499/mes | 5 | + Radiografias, Ortodoncia |
| Centro Dental | $3,999/mes | Ilimitado | + IA, WhatsApp |
---
## Features por Plan
| Feature | Consultorio | Clinica | Centro |
|---------|:-----------:|:-------:|:------:|
| odontograma_digital | - | X | X |
| radiografias_digitales | - | X | X |
| ortodoncia_3d | - | - | X |
| asistente_ia | - | - | X |
| whatsapp_business | - | - | X |
---
## Indice de Documentos
### Requerimientos Funcionales
| ID | Descripcion | Estado |
|----|-------------|--------|
| RF-PLANS-001 | Planes Consultorio/Clinica/Centro | Draft |
| RF-PLANS-002 | Feature gating odontologico | Draft |
| RF-PLANS-003 | Limites por sillon y pacientes | Draft |
### Especificaciones Tecnicas
| ID | Descripcion | Estado |
|----|-------------|--------|
| ET-PLANS-DATABASE | Modelo de datos de planes | Draft |
| ET-PLANS-BACKEND | API y middleware de cuotas | Draft |
---
## Flujo de Navegacion
### Para Entender
```
1. README.md -> Vision y planes
2. RF-PLANS-001.md -> Definicion de planes
3. RF-PLANS-002.md -> Feature gating
```
### Para Implementar
```
1. ET-PLANS-DATABASE.md -> Schema de planes
2. ET-PLANS-BACKEND.md -> Middleware de cuotas
```
---
*Mapa | MGN-017-plans | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,198 +0,0 @@
---
id: MGN-018-webhooks
title: Modulo Webhooks para Clinica Dental
type: Module
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
phase: 04-fase-saas
normativas: [NOM-013-SSA2-2015, LFPDPPP]
---
# MGN-018: Webhooks Outbound para Clinica Dental
**Modulo:** MGN-018
**Nombre:** Webhooks Outbound
**Fase:** 04 - SaaS
**Estado:** Pendiente Documentacion
**Ultima actualizacion:** 2026-01-13
---
## Descripcion
Sistema de webhooks outbound para notificar eventos de la clinica dental a sistemas externos. Permite a las clinicas registrar endpoints HTTP para recibir notificaciones automaticas cuando ocurren eventos como agendamiento de citas, finalizacion de tratamientos, actualizacion de odontogramas, pagos de servicios, etc.
---
## Funcionalidades Principales
1. **Registro de Endpoints** - CRUD de endpoints webhook por clinica
2. **Firma HMAC-SHA256** - Firma criptografica de payloads
3. **Reintentos con Backoff** - Politica de reintentos exponencial
4. **Dead Letter Queue** - Almacenamiento de entregas fallidas
5. **Delivery Logs** - Historial completo de entregas
---
## Eventos Disponibles para Clinica Dental
| Categoria | Eventos |
|-----------|---------|
| **Citas** | `cita.creada`, `cita.confirmada`, `cita.cancelada`, `cita.completada` |
| **Pacientes** | `paciente.creado`, `paciente.actualizado` |
| **Tratamientos** | `tratamiento.iniciado`, `tratamiento.completado`, `tratamiento.cancelado` |
| **Odontograma** | `odontograma.actualizado`, `pieza.tratada` |
| **Pagos** | `pago.recibido`, `pago.fallido` |
| **Presupuestos** | `presupuesto.creado`, `presupuesto.aprobado`, `presupuesto.rechazado` |
---
## Casos de Uso Odontologicos
- Sincronizar pacientes con sistema de laboratorio dental
- Notificar a aseguradoras sobre tratamientos completados
- Actualizar sistema contable con pagos recibidos
- Integrar con Slack/Teams para alertas del equipo
- Trigger de recordatorios automaticos en herramientas externas
- Notificar a sistema de rayos X sobre nuevas citas
---
## Arquitectura
```
+-------------------+ +-------------------+ +-------------------+
| Evento Dental |---->| Webhook Service |---->| BullMQ Queue |
| (cita, tratam.) | | (enqueue) | | (webhooks) |
+-------------------+ +-------------------+ +-------------------+
|
v
+-------------------+
| Webhook Processor |
| (worker) |
+-------------------+
|
+-------------------+-------------------+
| |
v v
+---------------+ +---------------+
| HTTP POST | | Retry Queue |
| (lab dental, | | (backoff) |
| aseguradora) | +---------------+
+---------------+ |
| v (5 fails)
v +---------------+
+---------------+ | DLQ |
| Delivery Log | | (failed) |
| (success) | +---------------+
+---------------+
```
---
## Ejemplo de Payload
### Evento: cita.confirmada
```json
{
"event": "cita.confirmada",
"timestamp": "2026-01-13T10:30:00Z",
"webhook_id": "wh_dental_001",
"data": {
"cita_id": "cita_xyz789",
"paciente": {
"id": "pac_abc123",
"nombre": "Maria Garcia",
"telefono": "+521234567890"
},
"fecha": "2026-01-15",
"hora": "10:00",
"tratamiento": "Limpieza dental",
"doctor": "Dr. Rodriguez",
"sillon": 2,
"duracion_minutos": 45
}
}
```
### Evento: tratamiento.completado
```json
{
"event": "tratamiento.completado",
"timestamp": "2026-01-13T11:45:00Z",
"webhook_id": "wh_dental_002",
"data": {
"tratamiento_id": "trat_def456",
"paciente_id": "pac_abc123",
"tipo": "Resina",
"piezas_tratadas": ["16", "17"],
"doctor": "Dr. Martinez",
"costo": 1500.00,
"moneda": "MXN",
"notas": "Resina compuesta en molares superiores"
}
}
```
---
## Dependencias
**Este modulo depende de:**
- MGN-001 Auth (autenticacion de administradores)
- MGN-004 Tenants (aislamiento por clinica)
- MGN-017 Plans (feature gating - solo planes Clinica y Centro)
**Modulos que dependen de este:**
- Integraciones con laboratorios dentales
- Sistemas de aseguradoras
- Herramientas de notificacion
---
## Seguridad y Normativas
| Medida | Implementacion |
|--------|----------------|
| HMAC signature | SHA-256 con secret por endpoint |
| Timestamp | Previene ataques de replay (5 min) |
| URL validation | Solo HTTPS en produccion |
| Timeout | 30 segundos maximo |
| NOM-013-SSA2-2015 | No enviar datos sensibles de salud sin consentimiento |
| LFPDPPP | Cumplimiento de privacidad de datos |
### Datos Sensibles
Los webhooks NO deben incluir:
- Expediente clinico completo
- Diagnosticos detallados
- Radiografias o imagenes
- Datos de pago completos
Para datos sensibles, el receptor debe hacer una consulta autenticada a la API.
---
## Documentacion
- **Requerimientos:** [requerimientos/](./requerimientos/)
- **Especificaciones:** [especificaciones/](./especificaciones/)
- **User Stories:** [historias-usuario/](./historias-usuario/)
- **Trazabilidad:** [implementacion/TRACEABILITY.yml](./implementacion/TRACEABILITY.yml)
---
## Referencias
- **Fuente:** [erp-core/MGN-018-webhooks](../../../../../erp-core/docs/04-fase-saas/MGN-018-webhooks/)
- **Arquitectura SaaS:** [ARQUITECTURA-SAAS.md](../../00-vision-general/ARQUITECTURA-SAAS.md)
---
*Modulo: MGN-018-webhooks | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,82 +0,0 @@
---
id: MAP-MGN-018-webhooks
title: Mapa de Navegacion - Modulo Webhooks
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - MGN-018: Webhooks Dental
## Estructura del Modulo
```
MGN-018-webhooks/
+-- README.md <- Vision general
+-- _MAP.md <- ESTE ARCHIVO
|
+-- requerimientos/ <- RFs
| +-- INDICE-RF-WEBHOOKS.md
| +-- RF-WEBHOOKS-001.md <- Registro de endpoints
| +-- RF-WEBHOOKS-002.md <- Eventos dentales
| +-- RF-WEBHOOKS-003.md <- Reintentos y DLQ
|
+-- especificaciones/ <- ETs
| +-- INDICE-ET-WEBHOOKS.md
| +-- ET-WEBHOOKS-DATABASE.md
| +-- ET-WEBHOOKS-BACKEND.md
|
+-- historias-usuario/
| +-- INDICE-US-WEBHOOKS.md
|
+-- implementacion/
+-- TRACEABILITY.yml
```
---
## Eventos Dentales Disponibles
| Evento | Descripcion |
|--------|-------------|
| cita.creada | Nueva cita agendada |
| cita.confirmada | Paciente confirmo cita |
| cita.cancelada | Cita cancelada |
| tratamiento.completado | Tratamiento finalizado |
| odontograma.actualizado | Cambio en odontograma |
| pago.recibido | Pago procesado |
---
## Indice de Documentos
### Requerimientos
| ID | Descripcion | Estado |
|----|-------------|--------|
| RF-WEBHOOKS-001 | Registro de endpoints | Draft |
| RF-WEBHOOKS-002 | Eventos dentales | Draft |
| RF-WEBHOOKS-003 | Reintentos y DLQ | Draft |
### Especificaciones
| ID | Descripcion | Estado |
|----|-------------|--------|
| ET-WEBHOOKS-DATABASE | Modelo de datos | Draft |
| ET-WEBHOOKS-BACKEND | API y workers | Draft |
---
## Seguridad
- HMAC-SHA256 signature
- Solo HTTPS en produccion
- No enviar datos sensibles de salud sin consentimiento
- Cumplimiento LFPDPPP
---
*Mapa | MGN-018-webhooks | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,176 +0,0 @@
---
id: MGN-019-feature-flags
title: Sistema de Feature Flags para Clinica Dental
type: Module
status: Draft
priority: P1
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
source: erp-core/MGN-019-feature-flags
normativas: [NOM-013-SSA2-2015]
---
# MGN-019: Sistema de Feature Flags Dental
## Descripcion
Sistema propio de feature flags para control granular de funcionalidades odontologicas por clinica y plan. Permite toggle de features dentales sin redeploy, rollout gradual de nuevas funcionalidades, y override manual por clinica para casos especiales.
## Objetivos
- Toggle de features dentales sin necesidad de redeploy
- Flags configurables por clinica y por plan
- Gradual rollout (porcentaje de clinicas)
- A/B testing de funcionalidades
- Override manual por clinica con expiracion opcional
## Alcance
| Caracteristica | Incluido | Notas |
|----------------|----------|-------|
| Boolean flags | Si | On/off simple |
| Plan-based flags | Si | Por tier de plan |
| Tenant override | Si | Admin puede activar/desactivar |
| Percentage rollout | Si | % de clinicas |
| User targeting | No | Fase posterior |
| Analytics | No | Fase posterior |
## Feature Flags Odontologicos
### Funcionalidades por Plan
| Feature Flag | Consultorio | Clinica | Centro |
|--------------|:-----------:|:-------:|:------:|
| `odontograma_digital` | - | X | X |
| `radiografias_digitales` | - | X | X |
| `ortodoncia_3d` | - | - | X |
| `asistente_ia_dental` | - | - | X |
| `whatsapp_pacientes` | - | - | X |
| `multi_sucursal` | - | - | X |
| `reportes_avanzados` | - | X | X |
| `integracion_laboratorio` | - | X | X |
| `presupuestos_financiados` | - | X | X |
### Features en Rollout
| Feature Flag | Descripcion | Rollout % | Estado |
|--------------|-------------|-----------|--------|
| `nuevo_odontograma_v2` | Nueva UI de odontograma | 25% | Beta |
| `radiografia_ia` | Analisis IA de radiografias | 10% | Alpha |
| `agenda_inteligente` | Sugerencias de agenda | 50% | Beta |
| `recordatorio_sms` | Recordatorios via SMS | 100% | GA |
### Features de Normativa
| Feature Flag | Descripcion | Default |
|--------------|-------------|---------|
| `consentimiento_digital` | Firma digital de consentimientos | Activado |
| `historial_nom013` | Historial conforme NOM-013-SSA2 | Activado |
| `bitacora_cofepris` | Bitacora de procedimientos | Activado |
## Arquitectura de Evaluacion
```
Request (ej: acceder odontograma_digital)
|
v
+-------------------+
| FeatureFlagService|
+-------------------+
|
+---> 1. Check tenant override (clinica especifica)
| |
| v (si existe)
| Return override value
|
+---> 2. Check plan features (Consultorio/Clinica/Centro)
| |
| v (si definido en plan)
| Return plan value
|
+---> 3. Check global flag + rollout
| |
| v
| Evaluate (boolean/percentage)
|
v
Return final value
```
## Prioridad de Evaluacion
1. **Tenant Override** - Maxima prioridad, permite excepciones (ej: demo, VIP)
2. **Plan Features** - Features incluidas en plan de la clinica
3. **Global Flag** - Valor default con soporte de rollout gradual
## Casos de Uso
### Ejemplo: Activar ortodoncia_3d para demo
```typescript
// Override para clinica en demo
await featureFlagService.setOverride({
tenantId: 'clinica_demo_123',
flag: 'ortodoncia_3d',
value: true,
expiresAt: addDays(new Date(), 14), // 14 dias de demo
reason: 'Demo para cliente potencial'
});
```
### Ejemplo: Rollout gradual de radiografia_ia
```typescript
// Configurar rollout al 25% de clinicas
await featureFlagService.setRollout({
flag: 'radiografia_ia',
percentage: 25,
filterByPlan: ['clinica', 'centro_dental']
});
```
### Ejemplo: Verificar feature en codigo
```typescript
@Get('odontograma/3d')
@FeatureGuard('ortodoncia_3d')
async getOdontograma3D(@Tenant() tenant: Tenant) {
// Solo accesible si flag activo para esta clinica
return this.ortodonciaService.get3DModel(tenant.id);
}
```
## Documentacion del Modulo
- [Mapa del Modulo](./_MAP.md)
- [Requerimientos](./requerimientos/INDICE-RF-FFLAGS.md)
- [Especificaciones](./especificaciones/INDICE-ET-FFLAGS.md)
- [Historias de Usuario](./historias-usuario/INDICE-US-FFLAGS.md)
- [Trazabilidad](./implementacion/TRACEABILITY.yml)
## Dependencias
### Modulos Requeridos
- **MGN-004-tenants** - Contexto de clinica
- **MGN-017-plans** - Planes de suscripcion
### Modulos Dependientes
- Odontograma (feature: odontograma_digital)
- Radiografias (feature: radiografias_digitales)
- Ortodoncia (feature: ortodoncia_3d)
- IA (feature: asistente_ia_dental)
- WhatsApp (feature: whatsapp_pacientes)
## Referencias
- **Fuente:** [erp-core/MGN-019-feature-flags](../../../../../erp-core/docs/04-fase-saas/MGN-019-feature-flags/)
- **Plans:** [MGN-017-plans](../MGN-017-plans/)
---
*Modulo MGN-019 - Feature Flags | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,91 +0,0 @@
---
id: MAP-MGN-019-feature-flags
title: Mapa de Navegacion - Feature Flags
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - MGN-019: Feature Flags Dental
## Estructura del Modulo
```
MGN-019-feature-flags/
+-- README.md <- Vision general
+-- _MAP.md <- ESTE ARCHIVO
|
+-- requerimientos/
| +-- INDICE-RF-FFLAGS.md
| +-- RF-FFLAGS-001.md <- Boolean flags
| +-- RF-FFLAGS-002.md <- Plan-based flags
| +-- RF-FFLAGS-003.md <- Rollout gradual
|
+-- especificaciones/
| +-- INDICE-ET-FFLAGS.md
| +-- ET-FFLAGS-DATABASE.md
| +-- ET-FFLAGS-BACKEND.md
|
+-- historias-usuario/
| +-- INDICE-US-FFLAGS.md
|
+-- implementacion/
+-- TRACEABILITY.yml
```
---
## Feature Flags Odontologicos
| Flag | Consultorio | Clinica | Centro |
|------|:-----------:|:-------:|:------:|
| odontograma_digital | - | X | X |
| radiografias_digitales | - | X | X |
| ortodoncia_3d | - | - | X |
| asistente_ia_dental | - | - | X |
| whatsapp_pacientes | - | - | X |
---
## Rollout Actual
| Flag | % Rollout | Estado |
|------|-----------|--------|
| nuevo_odontograma_v2 | 25% | Beta |
| radiografia_ia | 10% | Alpha |
| agenda_inteligente | 50% | Beta |
| recordatorio_sms | 100% | GA |
---
## Prioridad de Evaluacion
1. Tenant Override (clinica especifica)
2. Plan Features (Consultorio/Clinica/Centro)
3. Global Flag (rollout %)
---
## Indice de Documentos
### Requerimientos
| ID | Descripcion | Estado |
|----|-------------|--------|
| RF-FFLAGS-001 | Boolean flags | Draft |
| RF-FFLAGS-002 | Plan-based flags | Draft |
| RF-FFLAGS-003 | Rollout gradual | Draft |
### Especificaciones
| ID | Descripcion | Estado |
|----|-------------|--------|
| ET-FFLAGS-DATABASE | Modelo de datos | Draft |
| ET-FFLAGS-BACKEND | FeatureFlagService | Draft |
---
*Mapa | MGN-019-feature-flags | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,104 +0,0 @@
---
id: fase-04-saas
title: Fase 04 - Capacidades SaaS para Clinica Dental
type: PhaseOverview
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
normativas: [NOM-013-SSA2-2015, COFEPRIS]
---
# Fase 04: Capacidades SaaS para Clinica Dental
## Descripcion
Esta fase implementa las capacidades de Software as a Service (SaaS) para la plataforma de gestion de clinicas dentales. Permite la monetizacion mediante suscripciones, la gestion de planes diferenciados por tipo de consultorio (individual, grupal, clinica), y la integracion con sistemas externos via webhooks.
---
## Modulos de la Fase
| ID | Modulo | Descripcion | Prioridad |
|----|--------|-------------|-----------|
| MGN-016 | [Billing](./MGN-016-billing/) | Facturacion y suscripciones con Stripe | P0 |
| MGN-017 | [Plans](./MGN-017-plans/) | Planes y Feature Gating para consultorios | P0 |
| MGN-018 | [Webhooks](./MGN-018-webhooks/) | Webhooks outbound para integraciones | P1 |
| MGN-019 | [Feature Flags](./MGN-019-feature-flags/) | Control granular de funcionalidades | P1 |
---
## Planes Propuestos para Clinica Dental
| Plan | Precio/mes | Sillones | Storage | Caracteristicas Clave |
|------|------------|----------|---------|----------------------|
| **Consultorio** | $499 MXN | 1 | 5 GB | Odontograma basico, Citas, Expedientes |
| **Clinica** | $1,499 MXN | 5 | 25 GB | + Ortodoncia, Radiografias digitales, Reportes |
| **Centro Dental** | $3,999 MXN | Ilimitado | 100 GB | + Multi-sucursal, IA, WhatsApp Business |
---
## Normativas Aplicables
### NOM-013-SSA2-2015
Norma Oficial Mexicana para la prevencion y control de enfermedades bucales. Aplica a:
- Registro y trazabilidad de tratamientos
- Consentimiento informado digital
- Protocolos de atencion
### COFEPRIS
Comision Federal para la Proteccion contra Riesgos Sanitarios:
- Registro de materiales y medicamentos
- Trazabilidad de insumos odontologicos
- Bitacora de procedimientos
### Ley General de Proteccion de Datos Personales (LGPDP)
- Expediente clinico como dato sensible
- Consentimiento para almacenamiento en nube
- Derecho ARCO (Acceso, Rectificacion, Cancelacion, Oposicion)
---
## Flujo de Suscripcion para Clinicas
```
1. Dentista registra clinica
|
2. Selecciona plan (Consultorio/Clinica/Centro)
|
3. Checkout con Stripe (tarjeta o OXXO)
|
4. Webhook confirma pago
|
5. Se activan features del plan
|
6. Clinica operativa con su odontograma
```
---
## Estructura de Directorios
```
04-fase-saas/
+-- README.md <- ESTE ARCHIVO
+-- _MAP.md <- Indice de navegacion
+-- MGN-016-billing/ <- Facturacion y suscripciones
+-- MGN-017-plans/ <- Planes y cuotas
+-- MGN-018-webhooks/ <- Integraciones externas
+-- MGN-019-feature-flags/ <- Control de features
```
---
## Referencias
- [ARQUITECTURA-SAAS.md](../00-vision-general/ARQUITECTURA-SAAS.md) - Arquitectura SaaS
- [erp-core/04-fase-saas](../../../../erp-core/docs/04-fase-saas/) - Documentacion origen
- [Stripe Docs](https://stripe.com/docs) - Integracion de pagos
---
*Fase 04 - SaaS | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,101 +0,0 @@
---
id: MAP-fase-04-saas
title: Mapa de Navegacion - Fase 04 SaaS
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - Fase 04: SaaS
## Estructura de la Fase
```
04-fase-saas/
+-- README.md <- Vision general de la fase
+-- _MAP.md <- ESTE ARCHIVO
|
+-- MGN-016-billing/ <- Facturacion dental
| +-- README.md <- Vision del modulo
| +-- _MAP.md <- Indice del modulo
| +-- requerimientos/ <- RFs de billing
| +-- especificaciones/ <- ETs tecnicas
| +-- historias-usuario/ <- User stories
| +-- implementacion/ <- Trazabilidad
|
+-- MGN-017-plans/ <- Planes de clinica
| +-- README.md <- Vision del modulo
| +-- _MAP.md <- Indice del modulo
| +-- ... <- Subdirectorios
|
+-- MGN-018-webhooks/ <- Integraciones
| +-- README.md <- Vision del modulo
| +-- _MAP.md <- Indice del modulo
| +-- ... <- Subdirectorios
|
+-- MGN-019-feature-flags/ <- Control features
+-- README.md <- Vision del modulo
+-- _MAP.md <- Indice del modulo
+-- ... <- Subdirectorios
```
---
## Indice de Modulos
| Modulo | Descripcion | Estado | Prioridad |
|--------|-------------|--------|-----------|
| [MGN-016-billing](./MGN-016-billing/) | Suscripciones y facturacion para clinicas | Draft | P0 |
| [MGN-017-plans](./MGN-017-plans/) | Planes (Consultorio, Clinica, Centro) | Draft | P0 |
| [MGN-018-webhooks](./MGN-018-webhooks/) | Webhooks para integraciones externas | Draft | P1 |
| [MGN-019-feature-flags](./MGN-019-feature-flags/) | Feature flags para odontologia | Draft | P1 |
---
## Flujo de Navegacion Recomendado
### Para Entender la Fase
```
1. README.md -> Vision general SaaS
2. MGN-016-billing/README.md -> Sistema de facturacion
3. MGN-017-plans/README.md -> Planes disponibles
```
### Para Implementar
```
1. MGN-016-billing/ -> Configurar Stripe
2. MGN-017-plans/ -> Definir planes de clinica
3. MGN-019-feature-flags/ -> Configurar features por plan
4. MGN-018-webhooks/ -> Integraciones externas
```
---
## Adaptaciones al Dominio Odontologico
| Aspecto | Adaptacion |
|---------|------------|
| Planes | Consultorio (1 sillon), Clinica (5), Centro (ilimitado) |
| Features | odontograma_digital, radiografias, ortodoncia_3d |
| Limites | Por numero de sillones, pacientes, tratamientos |
| Facturacion | CFDI 4.0, SAT, formato dental |
| Normativas | NOM-013-SSA2-2015, COFEPRIS |
---
## Referencias Cruzadas
| Documento | Ubicacion | Descripcion |
|-----------|-----------|-------------|
| Arquitectura SaaS | ../00-vision-general/ | Arquitectura general |
| Origen erp-core | erp-core/docs/04-fase-saas/ | Documentacion base |
| Herencia erp-clinicas | erp-clinicas/docs/ | Adaptaciones clinicas |
---
*Mapa de Navegacion | Fase 04 SaaS | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,34 +0,0 @@
# TRACEABILITY-MASTER.yml v2.0
# Proyecto: Clinica Dental
# Prefijo v2: CDN
traceability_version: "2.0"
project:
code: "CDN"
name: "Clinica Dental - Sistema de Gestion para Clinicas Dentales"
updated: "2026-01-10"
epics_summary:
total: 0
completed: 0
in_progress: 0
planned: 0
nomenclature_mapping:
legacy: "CDN-EP"
epics: []
dependency_graph: {}
inventories:
master: "docs/90-transversal/inventarios/"
health:
last_validated: "2026-01-10"
score: 0.50
issues:
- severity: "low"
type: "initialization"
description: "Proyecto en migracion inicial v2"

View File

@ -1,210 +0,0 @@
---
id: MGN-020-ai-integration
title: Modulo AI Integration - Gateway LLM para Clinica Dental
type: Module
status: Draft
version: 1.0.0
priority: P1
phase: Fase IA
created_date: 2026-01-13
updated_date: 2026-01-13
source: erp-core/MGN-020-ai-integration
normativas: [NOM-013-SSA2-2015, LFPDPPP]
---
# MGN-020: AI Integration - Gateway LLM para Clinica Dental
> Capa de abstraccion unificada para integracion con modelos de lenguaje especializados en odontologia
## Resumen Ejecutivo
El modulo AI Integration proporciona un gateway centralizado para consumir servicios de modelos de lenguaje (LLM) de multiples proveedores a traves de OpenRouter. Esta adaptado para el dominio odontologico, con conocimiento de nomenclatura dental FDI, tratamientos, y normativas mexicanas de salud bucal.
---
## 1. Objetivos del Modulo
| Objetivo | Descripcion | Prioridad |
|----------|-------------|-----------|
| Gateway unificado | API unica para multiples providers LLM | P0 |
| Fallback automatico | Cambio automatico a modelo backup | P0 |
| Cost tracking | Registro de costos por clinica | P0 |
| Streaming | Respuestas en tiempo real via SSE | P1 |
| Prompt templates dentales | Templates especializados en odontologia | P1 |
| Rate limiting | Limites por plan de suscripcion | P1 |
---
## 2. System Prompt Especializado en Odontologia
```
Eres el asistente virtual de {{CLINICA_DENTAL}}, una clinica dental en Mexico.
## Especialidades
- Odontologia general y preventiva
- Ortodoncia (brackets, alineadores, retenedores)
- Endodoncia (tratamientos de conductos)
- Periodoncia (enfermedad periodontal)
- Estetica dental (blanqueamiento, carillas)
- Cirugia oral (extracciones, implantes)
## Conocimientos Tecnicos
- Nomenclatura dental FDI (sistema de dos digitos)
- Cuadrantes dentales:
* Cuadrante 1: Superior derecho (11-18)
* Cuadrante 2: Superior izquierdo (21-28)
* Cuadrante 3: Inferior izquierdo (31-38)
* Cuadrante 4: Inferior derecho (41-48)
- Piezas deciduas (temporales):
* 51-55, 61-65, 71-75, 81-85
- Estados de piezas: Sano, Caries, Obturacion, Endodoncia, Corona, Ausente
- Caras dentales: Mesial, Distal, Oclusal, Vestibular, Lingual/Palatino
## Normativas
- NOM-013-SSA2-2015: Prevencion y control de enfermedades bucales
- COFEPRIS: Regulacion de materiales e insumos
- NOM-004-SSA3-2012: Expediente clinico
## Reglas de Comportamiento
1. Responde en espanol mexicano profesional pero calido
2. NUNCA des diagnosticos clinicos - siempre recomienda visita al odontologo
3. Explica procedimientos de forma clara y sin tecnicismos excesivos
4. Para citas, usa el sistema de agenda del consultorio
5. Respeta la confidencialidad del expediente clinico
6. No compartas informacion de un paciente con otro
7. Para urgencias (dolor intenso, trauma, sangrado), indica acudir de inmediato
```
---
## 3. Modelos Soportados
### 3.1 Tabla de Modelos y Costos
| Modelo | ID OpenRouter | Input/1M tokens | Output/1M tokens | Uso Dental |
|--------|---------------|----------------:|-----------------:|------------|
| Claude 3 Haiku | anthropic/claude-3-haiku | $0.25 | $1.25 | Chat rapido |
| Claude 3 Sonnet | anthropic/claude-3-sonnet | $3.00 | $15.00 | Consultas complejas |
| GPT-4 Turbo | openai/gpt-4-turbo | $10.00 | $30.00 | Analisis detallado |
| GPT-4o-mini | openai/gpt-4o-mini | $0.15 | $0.60 | Alto volumen |
### 3.2 Recomendacion por Caso de Uso Dental
| Caso de Uso | Modelo Recomendado | Justificacion |
|-------------|-------------------|---------------|
| Chat con pacientes | Claude 3 Haiku | Rapido y natural |
| Explicar tratamientos | Claude 3 Sonnet | Alta calidad |
| Analisis de caso | GPT-4 Turbo | Profundidad |
| Recordatorios masivos | GPT-4o-mini | Costo bajo |
---
## 4. Rate Limits por Plan
| Plan | Requests/dia | Tokens/dia | Max Tokens/Request |
|------|-------------:|-----------:|-------------------:|
| Consultorio | 0 | 0 | 0 (sin acceso) |
| Clinica | 0 | 0 | 0 (sin acceso) |
| Centro Dental | 500 | 100,000 | 2,000 |
> Nota: La funcionalidad de IA solo esta disponible en el plan Centro Dental.
---
## 5. Capacidades Principales
### 5.1 Funcionalidades Core
- **Chat con Pacientes**: Respuestas a dudas comunes sobre tratamientos
- **Explicacion de Procedimientos**: Descripcion detallada de tratamientos
- **Recomendaciones de Cuidado**: Instrucciones pre y post operatorias
- **Informacion de Precios**: Consulta de costos aproximados (via MCP)
- **Agendamiento**: Asistencia para agendar citas (via MCP)
### 5.2 Seguridad y Normativas
| Medida | Implementacion |
|--------|----------------|
| API key rotation | Secrets manager con encriptacion |
| Rate limiting | Por clinica segun plan |
| Content filtering | OpenRouter builtin |
| Cost caps | Limite mensual configurable |
| Audit trail | Log de todas las consultas |
| NOM-013-SSA2 | No diagnosticar, solo informar |
| LFPDPPP | No almacenar datos sensibles en prompts |
---
## 6. Estructura del Modulo
```
MGN-020-ai-integration/
+-- README.md <- Este archivo
+-- _MAP.md <- Indice y navegacion
+-- requerimientos/
| +-- RF-AI-001.md <- Gateway LLM
| +-- RF-AI-002.md <- Streaming
| +-- RF-AI-003.md <- Cost tracking
| +-- RF-AI-004.md <- Prompt templates dentales
| +-- INDICE-RF-AI.md
+-- especificaciones/
| +-- ET-AI-DATABASE.md <- Modelo de datos
| +-- ET-AI-BACKEND.md <- API y servicios
| +-- ET-AI-FRONTEND.md <- UI de chat
| +-- INDICE-ET-AI.md
+-- historias-usuario/
| +-- INDICE-US-AI.md
+-- implementacion/
+-- TRACEABILITY.yml
```
---
## 7. Dependencias
### 7.1 Internas
| Modulo | Relacion |
|--------|----------|
| MGN-004-tenants | Aislamiento por clinica |
| MGN-001-auth | Autenticacion JWT |
| MGN-017-plans | Feature gating (solo Centro Dental) |
| MGN-022-mcp-server | Herramientas de negocio |
### 7.2 Externas
| Servicio | Proposito |
|----------|-----------|
| OpenRouter API | Gateway multi-provider |
| Redis | Cache de configuraciones |
---
## 8. Configuracion
```bash
# OpenRouter
OPENROUTER_API_KEY=sk-or-xxx
OPENROUTER_SITE_URL=https://clinica.ejemplo.com
OPENROUTER_SITE_NAME=Clinica Dental Ejemplo
# Defaults para odontologia
AI_DEFAULT_MODEL=anthropic/claude-3-haiku
AI_DEFAULT_TEMPERATURE=0.7
AI_DEFAULT_MAX_TOKENS=1000
AI_SYSTEM_PROMPT_TYPE=dental
```
---
## Referencias
- **Fuente**: [erp-core/MGN-020-ai-integration](../../../../../erp-core/docs/05-fase-ia/MGN-020-ai-integration/)
- **MCP Server**: [MGN-022-mcp-server](../MGN-022-mcp-server/)
- **OpenRouter Docs**: https://openrouter.ai/docs
---
*Modulo MGN-020 - AI Integration | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,95 +0,0 @@
---
id: MAP-MGN-020-ai-integration
title: Mapa de Navegacion - AI Integration
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - MGN-020: AI Integration Dental
## Estructura del Modulo
```
MGN-020-ai-integration/
+-- README.md <- Vision general
+-- _MAP.md <- ESTE ARCHIVO
|
+-- requerimientos/
| +-- INDICE-RF-AI.md
| +-- RF-AI-001.md <- Gateway LLM
| +-- RF-AI-002.md <- Streaming SSE
| +-- RF-AI-003.md <- Cost tracking
| +-- RF-AI-004.md <- Prompts dentales
|
+-- especificaciones/
| +-- INDICE-ET-AI.md
| +-- ET-AI-DATABASE.md
| +-- ET-AI-BACKEND.md
| +-- ET-AI-FRONTEND.md
|
+-- historias-usuario/
| +-- INDICE-US-AI.md
|
+-- implementacion/
+-- TRACEABILITY.yml
```
---
## Modelos Recomendados
| Caso de Uso | Modelo | Costo |
|-------------|--------|-------|
| Chat pacientes | Claude 3 Haiku | Bajo |
| Explicar tratamientos | Claude 3 Sonnet | Medio |
| Analisis complejo | GPT-4 Turbo | Alto |
---
## Disponibilidad por Plan
| Plan | Acceso IA |
|------|-----------|
| Consultorio | No |
| Clinica | No |
| Centro Dental | Si |
---
## System Prompt Dental
El asistente IA conoce:
- Nomenclatura FDI (11-48, 51-85)
- Estados de piezas dentales
- Tratamientos comunes
- Normativas NOM-013-SSA2-2015
- COFEPRIS
---
## Indice de Documentos
### Requerimientos
| ID | Descripcion | Estado |
|----|-------------|--------|
| RF-AI-001 | Gateway LLM multi-proveedor | Draft |
| RF-AI-002 | Streaming SSE | Draft |
| RF-AI-003 | Cost tracking por clinica | Draft |
| RF-AI-004 | Prompt templates dentales | Draft |
### Especificaciones
| ID | Descripcion | Estado |
|----|-------------|--------|
| ET-AI-DATABASE | Modelo de datos | Draft |
| ET-AI-BACKEND | API y servicios | Draft |
| ET-AI-FRONTEND | UI de chat | Draft |
---
*Mapa | MGN-020-ai-integration | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,363 +0,0 @@
---
id: MGN-021-whatsapp-business
title: Modulo WhatsApp Business con IA para Clinica Dental
type: Module
status: Draft
priority: P1
phase: 05-fase-ia
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
normativas: [NOM-013-SSA2-2015, LFPDPPP]
---
# MGN-021: WhatsApp Business con IA para Clinica Dental
> Integracion de WhatsApp Business API con procesamiento inteligente para comunicacion con pacientes
## Resumen Ejecutivo
El modulo WhatsApp Business permite a las clinicas dentales comunicarse con sus pacientes a traves de WhatsApp, procesando mensajes entrantes con inteligencia artificial para proporcionar respuestas contextuales sobre citas, tratamientos, instrucciones de cuidado y ejecutar acciones de negocio automaticamente.
---
## 1. Objetivos del Modulo
### 1.1 Objetivos Principales
- **Recepcion de mensajes**: Webhook para recibir mensajes de pacientes via Meta Cloud API
- **Procesamiento inteligente**: Analisis con LLM especializado en odontologia
- **Ejecucion de acciones**: Uso de herramientas MCP para consultar citas, odontogramas
- **Respuestas automaticas**: Generacion de respuestas en espanol mexicano profesional
- **Trazabilidad**: Registro completo de conversaciones y acciones
### 1.2 Objetivos Secundarios
- Soporte multi-clinica (un numero por clinica)
- Templates pre-aprobados por Meta
- Recordatorios automaticos de citas
- Dashboard de conversaciones
- Metricas de respuesta
---
## 2. Alcance
### 2.1 Incluido
| Caracteristica | Descripcion | Prioridad |
|----------------|-------------|-----------|
| Recepcion mensajes | Webhook Meta + almacenamiento | P0 |
| Procesamiento LLM | Analisis con Claude/GPT | P0 |
| Herramientas MCP | Citas, Odontograma, Tratamientos | P0 |
| Envio respuestas | API Meta para texto | P0 |
| Templates dentales | Mensajes pre-aprobados | P1 |
| Audio (voz) | Transcripcion con Whisper | P1 |
| Imagenes | Recepcion de radiografias | P2 |
| UI Bandeja | Dashboard de conversaciones | P1 |
### 2.2 Excluido (Futuro)
- Chatbots de otras plataformas
- Llamadas de voz
- Pagos dentro de WhatsApp
- Envio de radiografias via WhatsApp
---
## 3. Flujo de Mensaje Completo
```
+----------+ +----------+ +---------------+ +------------+
| Paciente |---->| WhatsApp |---->| Meta API |---->| Webhook |
| (movil) | | (app) | | (Cloud API) | | (Backend) |
+----------+ +----------+ +---------------+ +------------+
|
v
+------------------+
| WhatsApp Service |
| 1. Verificar |
| 2. Extraer clinica|
| 3. Guardar msg |
+------------------+
|
v
+------------------+
| LLM Service |
| 1. Cargar ctx |
| 2. System prompt |
| (dental) |
| 3. Llamar modelo |
+------------------+
|
v
+------------------+
| MCP Server |
| Tools dentales: |
| - consultar_cita |
| - ver_odontograma|
| - agendar_cita |
+------------------+
|
v
+------------------+
| LLM Service |
| 4. Generar resp |
| en espanol |
+------------------+
|
v
+----------+ +----------+ +---------------+ +------------+
| Paciente |<----| WhatsApp |<----| Meta API |<----| WA Service |
| (movil) | | (app) | | (send msg) | | (responde) |
+----------+ +----------+ +---------------+ +------------+
```
---
## 4. Templates WhatsApp para Clinica Dental
### 4.1 Recordatorio de Cita (recordatorio_cita_dental)
```
Hola {{1}}, te recordamos tu cita en {{2}}:
Fecha: {{3}}
Hora: {{4}}
Doctor(a): {{5}}
Tratamiento: {{6}}
Por favor confirma tu asistencia respondiendo SI o reprogramar respondiendo CAMBIAR.
Si tienes alguna duda, estamos para ayudarte.
```
Variables:
1. Nombre del paciente
2. Nombre de la clinica
3. Fecha (ej: "Miercoles 15 de enero")
4. Hora (ej: "10:00 AM")
5. Nombre del doctor
6. Tipo de tratamiento
### 4.2 Confirmacion de Tratamiento (confirmacion_tratamiento)
```
{{1}}, tu tratamiento ha sido registrado:
Procedimiento: {{2}}
Pieza(s) dental(es): {{3}}
Doctor(a): {{4}}
Fecha: {{5}}
Proxima cita: {{6}}
{{7}}
Cualquier duda sobre los cuidados, escribenos.
Clinica {{8}}
```
Variables:
1. Nombre del paciente
2. Nombre del procedimiento
3. Piezas tratadas (ej: "16, 17")
4. Nombre del doctor
5. Fecha del tratamiento
6. Proxima cita o "Pendiente de agendar"
7. Instrucciones breves de cuidado
8. Nombre de la clinica
### 4.3 Instrucciones Postoperatorio (instrucciones_postoperatorio)
```
{{1}}, instrucciones despues de tu {{2}}:
{{3}}
Medicamentos:
{{4}}
IMPORTANTE: Si presentas {{5}}, acude de inmediato o llama a {{6}}.
Recuerda tu cita de seguimiento el {{7}}.
Clinica {{8}} - Cuidamos tu sonrisa
```
Variables:
1. Nombre del paciente
2. Tipo de procedimiento
3. Lista de instrucciones de cuidado
4. Medicamentos recetados
5. Sintomas de alerta
6. Telefono de emergencias
7. Fecha de seguimiento
8. Nombre de la clinica
---
## 5. Integracion con MCP Dental
### 5.1 Herramientas Disponibles
El LLM tiene acceso a herramientas especializadas en odontologia:
| Herramienta | Descripcion | Uso |
|-------------|-------------|-----|
| `consultar_odontograma` | Ver estado de piezas dentales | Cuando paciente pregunta sobre dientes |
| `consultar_historial_dental` | Historial de tratamientos | Preguntas sobre tratamientos previos |
| `agendar_cita_dental` | Programar nueva cita | Solicitudes de cita |
| `verificar_disponibilidad` | Horarios disponibles | Antes de agendar |
| `consultar_cita_proxima` | Proxima cita del paciente | Preguntas sobre citas |
| `cancelar_reprogramar_cita` | Modificar cita existente | Cambios de cita |
### 5.2 Ejemplo de Interaccion
```
Paciente: "Hola, necesito saber cuando es mi proxima cita"
LLM piensa: Necesito consultar las citas del paciente
LLM llama: consultar_cita_proxima({ paciente_telefono: "+521234567890" })
MCP retorna: {
"fecha": "2026-01-15",
"hora": "10:00",
"doctor": "Dra. Garcia",
"tratamiento": "Limpieza dental",
"sillon": 2
}
LLM responde: "Hola! Tu proxima cita es el miercoles 15 de enero a las 10:00 AM
con la Dra. Garcia para una limpieza dental. Te esperamos!"
```
---
## 6. System Prompts Dentales
### 6.1 Para Pacientes
```
Eres el asistente virtual de {{CLINICA_DENTAL}}, una clinica dental en Mexico.
Ayudas a los pacientes con:
- Informacion sobre tratamientos dentales
- Agendar, confirmar o reprogramar citas
- Consultar proximas citas
- Dudas sobre cuidados bucales
- Instrucciones pre y post operatorias
Reglas:
1. Responde en espanol mexicano profesional pero calido
2. Se breve y claro
3. NUNCA diagnostiques - recomienda siempre visita al odontologo
4. Para urgencias (dolor intenso, sangrado, trauma), indica acudir de inmediato
5. Usa las herramientas MCP para consultar informacion real
6. No inventes datos de citas o tratamientos
7. Respeta la confidencialidad del expediente
8. Si no puedes ayudar, ofrece comunicar con recepcion
```
### 6.2 Para Staff de Clinica
```
Eres el asistente de {{CLINICA_DENTAL}} para el equipo de trabajo.
Ayudas al staff con:
- Consulta rapida de agenda
- Estado de citas del dia
- Recordatorios pendientes
- Busqueda de pacientes
Se directo, profesional y eficiente.
Proporciona informacion precisa usando las herramientas MCP.
```
---
## 7. Estructura del Modulo
```
docs/05-fase-ia/MGN-021-whatsapp-business/
+-- README.md <- Este archivo
+-- _MAP.md <- Indice del modulo
+-- requerimientos/
| +-- INDICE-RF-WHATSAPP.md
| +-- RF-WHATSAPP-001.md <- Recepcion de mensajes
| +-- RF-WHATSAPP-002.md <- Procesamiento con LLM
| +-- RF-WHATSAPP-003.md <- Templates dentales
+-- especificaciones/
| +-- INDICE-ET-WHATSAPP.md
| +-- ET-WHATSAPP-DATABASE.md <- Modelo de datos
| +-- ET-WHATSAPP-BACKEND.md <- Servicios y webhook
| +-- ET-WHATSAPP-FRONTEND.md <- UI de conversaciones
+-- historias-usuario/
| +-- INDICE-US-WHATSAPP.md
+-- implementacion/
+-- TRACEABILITY.yml
```
---
## 8. Dependencias
### 8.1 Internas
- `MGN-022-mcp-server` - Herramientas MCP dentales
- `MGN-020-ai-integration` - Gateway LLM
- `MGN-017-plans` - Feature gating (solo Centro Dental)
### 8.2 Externas
- Meta Cloud API (WhatsApp Business)
- OpenRouter (Gateway LLM)
- Whisper API (transcripcion de audio)
---
## 9. Normativas y Privacidad
### 9.1 NOM-013-SSA2-2015
- No proporcionar diagnosticos via WhatsApp
- Registrar interacciones relacionadas con tratamientos
- Mantener trazabilidad de comunicaciones
### 9.2 LFPDPPP (Datos Personales)
- Expediente clinico es dato sensible
- Requerir consentimiento para comunicacion via WhatsApp
- No almacenar radiografias recibidas sin cifrar
- Anonimizar logs para analytics
### 9.3 Reglas de Confidencialidad
- No compartir informacion de un paciente con otro
- No enviar resultados de estudios sin confirmar identidad
- Mensajes deben ser leidos solo por destinatario
---
## 10. Metricas de Exito
| Metrica | Target | Medicion |
|---------|--------|----------|
| Tiempo de respuesta | < 5 segundos | P95 latencia |
| Tasa de resolucion | > 70% | Mensajes resueltos sin staff |
| Satisfaccion | > 4.0/5.0 | Encuestas post-chat |
| Costo por mensaje | < $0.02 USD | Tokens LLM + API Meta |
| Citas agendadas via WA | > 30% | Del total de citas |
---
## Referencias
- [ARQUITECTURA-IA.md](../../00-vision-general/ARQUITECTURA-IA.md)
- [erp-core/MGN-021-whatsapp](../../../../../erp-core/docs/05-fase-ia/MGN-021-whatsapp-business/)
- [Meta Cloud API](https://developers.facebook.com/docs/whatsapp/cloud-api)
---
*Modulo MGN-021 - WhatsApp Business | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,126 +0,0 @@
---
id: MAP-MGN-021-whatsapp-business
title: Mapa de Navegacion - WhatsApp Business
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - MGN-021: WhatsApp Business Dental
## Estructura del Modulo
```
MGN-021-whatsapp-business/
+-- README.md <- Vision general
+-- _MAP.md <- ESTE ARCHIVO
|
+-- requerimientos/
| +-- INDICE-RF-WHATSAPP.md
| +-- RF-WHATSAPP-001.md <- Recepcion mensajes
| +-- RF-WHATSAPP-002.md <- Procesamiento LLM
| +-- RF-WHATSAPP-003.md <- Templates dentales
|
+-- especificaciones/
| +-- INDICE-ET-WHATSAPP.md
| +-- ET-WHATSAPP-DATABASE.md
| +-- ET-WHATSAPP-BACKEND.md
| +-- ET-WHATSAPP-FRONTEND.md
|
+-- historias-usuario/
| +-- INDICE-US-WHATSAPP.md
|
+-- implementacion/
+-- TRACEABILITY.yml
```
---
## Templates WhatsApp Dentales
| Template | Uso | Aprobado Meta |
|----------|-----|---------------|
| recordatorio_cita_dental | 24h antes de cita | Pendiente |
| confirmacion_tratamiento | Post-procedimiento | Pendiente |
| instrucciones_postoperatorio | Cuidados especiales | Pendiente |
---
## Herramientas MCP Disponibles
| Tool | Descripcion |
|------|-------------|
| consultar_odontograma | Ver piezas dentales |
| consultar_historial_dental | Tratamientos previos |
| agendar_cita_dental | Programar cita |
| verificar_disponibilidad | Horarios libres |
| consultar_cita_proxima | Proxima cita |
| cancelar_reprogramar_cita | Modificar cita |
---
## Flujo de Mensaje
```
Paciente envia mensaje
|
v
Webhook recibe
|
v
LLM procesa (system prompt dental)
|
v
MCP ejecuta tools
|
v
LLM genera respuesta
|
v
Paciente recibe
```
---
## Disponibilidad por Plan
| Plan | Acceso WhatsApp IA |
|------|-------------------|
| Consultorio | No |
| Clinica | No |
| Centro Dental | Si |
---
## Indice de Documentos
### Requerimientos
| ID | Descripcion | Estado |
|----|-------------|--------|
| RF-WHATSAPP-001 | Recepcion de mensajes | Draft |
| RF-WHATSAPP-002 | Procesamiento LLM | Draft |
| RF-WHATSAPP-003 | Templates dentales | Draft |
### Especificaciones
| ID | Descripcion | Estado |
|----|-------------|--------|
| ET-WHATSAPP-DATABASE | Modelo de datos | Draft |
| ET-WHATSAPP-BACKEND | Webhook y servicios | Draft |
| ET-WHATSAPP-FRONTEND | UI bandeja | Draft |
---
## Normativas
- NOM-013-SSA2-2015: No diagnosticar
- LFPDPPP: Expediente es dato sensible
- Consentimiento WhatsApp requerido
---
*Mapa | MGN-021-whatsapp-business | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,316 +0,0 @@
---
id: MGN-022-mcp-server
title: MCP Server para Clinica Dental
type: Module
status: Draft
priority: P0
phase: 05-fase-ia
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
normativas: [NOM-013-SSA2-2015, NOM-004-SSA3-2012, COFEPRIS]
---
# MGN-022: MCP Server para Clinica Dental
**Modulo:** MGN-022
**Nombre:** MCP Server (Model Context Protocol) Dental
**Fase:** 05 - Inteligencia Artificial
**Story Points:** 55 SP
**Estado:** En Diseno
**Ultima actualizacion:** 2026-01-13
---
## Descripcion
Modulo que implementa un servidor MCP (Model Context Protocol) siguiendo el estandar de Anthropic, especializado en odontologia. Expone herramientas (tools) de negocio dental a los modelos de lenguaje de manera estandarizada, permitiendo que agentes IA interactuen con el sistema para consultar odontogramas, gestionar citas, registrar tratamientos y administrar presupuestos dentales.
---
## Funcionalidades Principales
1. **Odontograma Tools** - Consulta y actualizacion de odontogramas usando nomenclatura FDI
2. **Tratamientos Tools** - Registro y consulta de tratamientos dentales
3. **Citas Tools** - Gestion completa de citas dentales
4. **Pacientes Tools** - Busqueda y consulta de pacientes
5. **Presupuestos Tools** - Generacion y consulta de presupuestos
6. **Historial Tools** - Consulta de historial clinico dental
7. **MCP Resources** - Recursos expuestos (catalogo tratamientos, precios)
8. **Tool Call Logging** - Registro de llamadas para auditoria (NOM-004)
---
## Herramientas MCP Odontologicas
### Odontograma Tools (4 herramientas)
| Tool | Descripcion | Parametros |
|------|-------------|------------|
| `consultar_odontograma` | Ver estado completo de piezas dentales | paciente_id |
| `consultar_pieza_dental` | Detalle de una pieza especifica | paciente_id, pieza (ej: "16") |
| `registrar_estado_pieza` | Actualizar estado de pieza | paciente_id, pieza, estado, cara?, notas? |
| `historial_pieza` | Tratamientos previos en pieza | paciente_id, pieza |
**Estados de Pieza Soportados:**
- `sano` - Sin patologia
- `caries` - Caries activa
- `obturacion_resina` - Obturacion con resina
- `obturacion_amalgama` - Obturacion con amalgama
- `endodoncia` - Tratamiento de conducto
- `corona` - Protesis fija
- `puente_pilar` - Pilar de puente
- `puente_pontico` - Pontico de puente
- `implante` - Implante dental
- `ausente` - Pieza ausente
- `extraccion_indicada` - Extraccion planificada
**Caras Dentales (parametro cara):**
- `M` - Mesial
- `D` - Distal
- `O` - Oclusal (molares/premolares)
- `I` - Incisal (incisivos/caninos)
- `V` - Vestibular
- `L` - Lingual
- `P` - Palatino
### Tratamientos Tools (4 herramientas)
| Tool | Descripcion | Parametros |
|------|-------------|------------|
| `registrar_tratamiento` | Documentar tratamiento realizado | paciente_id, tipo, piezas[], doctor_id, notas? |
| `consultar_tratamiento` | Detalle de un tratamiento | tratamiento_id |
| `listar_tratamientos_paciente` | Historial de tratamientos | paciente_id, desde?, hasta? |
| `catalogo_tratamientos` | Lista de tratamientos disponibles | categoria? |
**Categorias de Tratamiento:**
- `preventivo` - Limpiezas, selladores, fluor
- `restaurador` - Resinas, amalgamas, incrustaciones
- `endodoncia` - Tratamientos de conducto
- `periodoncia` - Raspados, cirugia periodontal
- `cirugia` - Extracciones, implantes
- `ortodoncia` - Brackets, alineadores
- `protesis` - Coronas, puentes, dentaduras
- `estetica` - Blanqueamiento, carillas
### Citas Tools (5 herramientas)
| Tool | Descripcion | Parametros |
|------|-------------|------------|
| `agendar_cita_dental` | Crear nueva cita | paciente_id, fecha, hora, tratamiento_tipo, doctor_id?, sillon? |
| `consultar_cita` | Detalle de cita | cita_id |
| `consultar_citas_paciente` | Citas de un paciente | paciente_id, estado? |
| `verificar_disponibilidad_sillon` | Horarios libres | fecha, sillon?, doctor_id? |
| `cancelar_reprogramar_cita` | Modificar cita | cita_id, accion, nueva_fecha?, nueva_hora? |
### Pacientes Tools (3 herramientas)
| Tool | Descripcion | Parametros |
|------|-------------|------------|
| `buscar_paciente` | Buscar por nombre/telefono | query, limit? |
| `consultar_paciente` | Datos completos del paciente | paciente_id |
| `consultar_historial_dental` | Historial clinico completo | paciente_id |
### Presupuestos Tools (3 herramientas)
| Tool | Descripcion | Parametros |
|------|-------------|------------|
| `generar_presupuesto_dental` | Crear presupuesto | paciente_id, tratamientos[], descuento? |
| `consultar_presupuesto` | Detalle de presupuesto | presupuesto_id |
| `aprobar_rechazar_presupuesto` | Cambiar estado | presupuesto_id, decision, notas? |
---
## Recursos MCP Dentales
| URI | Descripcion | Retorna |
|-----|-------------|---------|
| `dental://catalogo/tratamientos` | Catalogo de tratamientos con precios | Array de tratamientos |
| `dental://catalogo/materiales` | Materiales dentales disponibles | Array de materiales |
| `dental://config/clinica` | Configuracion de la clinica | Nombre, horarios, sillones |
| `dental://config/doctores` | Lista de doctores | Array de doctores y especialidades |
| `dental://nomenclatura/fdi` | Referencia nomenclatura FDI | Cuadrantes y piezas |
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/v1/mcp/tools/call | Ejecutar una herramienta MCP |
| GET | /api/v1/mcp/tools | Listar herramientas disponibles |
| GET | /api/v1/mcp/tools/:name | Obtener definicion de herramienta |
| GET | /api/v1/mcp/resources | Listar recursos disponibles |
| GET | /api/v1/mcp/resources/:uri | Obtener recurso |
| GET | /api/v1/mcp/tool-calls | Historial de llamadas (auditoria) |
| GET | /api/v1/mcp/tool-calls/:id | Detalle de una llamada |
---
## Ejemplos de Uso
### Consultar Odontograma
```json
// Request
{
"tool": "consultar_odontograma",
"parameters": {
"paciente_id": "pac_123"
}
}
// Response
{
"paciente": "Maria Garcia",
"fecha_actualizacion": "2026-01-13",
"piezas": [
{ "numero": "11", "estado": "sano" },
{ "numero": "16", "estado": "obturacion_resina", "caras": ["O", "M"], "fecha": "2025-06-15" },
{ "numero": "36", "estado": "endodoncia", "fecha": "2024-03-20" },
{ "numero": "46", "estado": "caries", "caras": ["O"], "notas": "Caries oclusal, indicada resina" }
],
"piezas_ausentes": ["18", "28", "38", "48"],
"tratamientos_pendientes": [
{ "pieza": "46", "tratamiento": "Resina compuesta" }
]
}
```
### Agendar Cita Dental
```json
// Request
{
"tool": "agendar_cita_dental",
"parameters": {
"paciente_id": "pac_123",
"fecha": "2026-01-20",
"hora": "10:00",
"tratamiento_tipo": "resina",
"doctor_id": "doc_456",
"sillon": 2
}
}
// Response
{
"cita_id": "cita_789",
"confirmada": true,
"fecha": "2026-01-20",
"hora": "10:00",
"duracion_minutos": 45,
"doctor": "Dra. Rodriguez",
"sillon": 2,
"tratamiento": "Resina compuesta",
"recordatorio_programado": true
}
```
---
## Dependencias
**Este modulo depende de:**
- MGN-001 Auth (autenticacion, clinica_id)
- MGN-004 Tenants (multi-tenant, aislamiento por clinica)
- DENTAL-001 Odontograma (consulta/actualizacion)
- DENTAL-002 Tratamientos (registro/consulta)
- Citas (agendamiento)
- Pacientes (busqueda/consulta)
**Modulos que dependen de este:**
- MGN-021 WhatsApp Business (chatbots con herramientas MCP)
- MGN-020 AI Integration (agentes IA)
---
## Arquitectura
```
+-------------------+
| Clientes MCP |
+-------------------+
| AI Agents |
| WhatsApp Service |
| API Externa |
+---------+---------+
|
v
+-------------------+
| MCP Server |
+-------------------+
| MCP Controller |
| Tool Registry |
| Tool Executor |
| Audit Logger |
+---------+---------+
|
+---------------------+---------------------+
| | | | |
v v v v v
+------------+ +--------+ +--------+ +----------+ +--------+
| Odontograma| | Citas | | Tratam.| | Pacientes| | Presup.|
| Tools | | Tools | | Tools | | Tools | | Tools |
+------------+ +--------+ +--------+ +----------+ +--------+
| | | | |
v v v v v
+------------+ +--------+ +--------+ +----------+ +--------+
| Odontograma| | Citas | | Tratam.| | Pacientes| | Presup.|
| Service | | Service| | Service| | Service | | Service|
+------------+ +--------+ +--------+ +----------+ +--------+
```
---
## Seguridad y Normativas
### Seguridad General
- Todas las herramientas requieren autenticacion JWT
- Aislamiento por clinica (RLS)
- Rate limiting por clinica
- Sanitizacion de inputs
- Validacion de permisos por herramienta
### NOM-004-SSA3-2012 (Expediente Clinico)
- Registro completo de todas las llamadas a herramientas
- Trazabilidad de consultas y modificaciones
- Almacenamiento seguro de logs
### NOM-013-SSA2-2015 (Salud Bucal)
- Uso correcto de nomenclatura FDI
- Registro adecuado de tratamientos
- Protocolos de atencion
### COFEPRIS
- Registro de materiales utilizados
- Trazabilidad de insumos
- Bitacora de procedimientos
---
## Documentacion
- [Mapa del Modulo](./_MAP.md)
- [Requerimientos](./requerimientos/)
- [Especificaciones](./especificaciones/)
- [Historias de Usuario](./historias-usuario/)
- [Trazabilidad](./implementacion/TRACEABILITY.yml)
---
## Referencias
- **Fuente:** [erp-core/MGN-022-mcp-server](../../../../../erp-core/docs/05-fase-ia/MGN-022-mcp-server/)
- **MCP Spec:** [Model Context Protocol](https://modelcontextprotocol.io/)
- **Anthropic MCP:** [Anthropic MCP Docs](https://docs.anthropic.com/en/docs/mcp)
---
*Modulo MGN-022 - MCP Server | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,167 +0,0 @@
---
id: MAP-MGN-022-mcp-server
title: Mapa de Navegacion - MCP Server
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - MGN-022: MCP Server Dental
## Estructura del Modulo
```
MGN-022-mcp-server/
+-- README.md <- Vision general
+-- _MAP.md <- ESTE ARCHIVO
|
+-- requerimientos/
| +-- INDICE-RF-MCP.md
| +-- RF-MCP-001.md <- Odontograma Tools
| +-- RF-MCP-002.md <- Tratamientos Tools
| +-- RF-MCP-003.md <- Citas Tools
| +-- RF-MCP-004.md <- Auditoria NOM-004
|
+-- especificaciones/
| +-- INDICE-ET-MCP.md
| +-- ET-MCP-DATABASE.md
| +-- ET-MCP-BACKEND.md
| +-- ET-MCP-TOOLS.md <- Definicion de herramientas
|
+-- historias-usuario/
| +-- INDICE-US-MCP.md
|
+-- implementacion/
+-- TRACEABILITY.yml
```
---
## Herramientas MCP Dentales
### Odontograma (4 tools)
| Tool | Descripcion |
|------|-------------|
| consultar_odontograma | Estado completo de piezas |
| consultar_pieza_dental | Detalle de una pieza |
| registrar_estado_pieza | Actualizar estado |
| historial_pieza | Tratamientos en pieza |
### Tratamientos (4 tools)
| Tool | Descripcion |
|------|-------------|
| registrar_tratamiento | Documentar tratamiento |
| consultar_tratamiento | Detalle de tratamiento |
| listar_tratamientos_paciente | Historial |
| catalogo_tratamientos | Catalogo disponible |
### Citas (5 tools)
| Tool | Descripcion |
|------|-------------|
| agendar_cita_dental | Crear cita |
| consultar_cita | Detalle de cita |
| consultar_citas_paciente | Citas del paciente |
| verificar_disponibilidad_sillon | Horarios libres |
| cancelar_reprogramar_cita | Modificar cita |
### Pacientes (3 tools)
| Tool | Descripcion |
|------|-------------|
| buscar_paciente | Buscar por nombre/telefono |
| consultar_paciente | Datos del paciente |
| consultar_historial_dental | Historial completo |
### Presupuestos (3 tools)
| Tool | Descripcion |
|------|-------------|
| generar_presupuesto_dental | Crear presupuesto |
| consultar_presupuesto | Ver presupuesto |
| aprobar_rechazar_presupuesto | Cambiar estado |
---
## Recursos MCP
| URI | Descripcion |
|-----|-------------|
| dental://catalogo/tratamientos | Catalogo con precios |
| dental://catalogo/materiales | Materiales disponibles |
| dental://config/clinica | Config de clinica |
| dental://config/doctores | Lista de doctores |
| dental://nomenclatura/fdi | Referencia FDI |
---
## Nomenclatura FDI
### Cuadrantes
| Cuadrante | Descripcion | Piezas |
|-----------|-------------|--------|
| 1 | Superior derecho | 11-18 |
| 2 | Superior izquierdo | 21-28 |
| 3 | Inferior izquierdo | 31-38 |
| 4 | Inferior derecho | 41-48 |
### Piezas Deciduas
| Cuadrante | Piezas |
|-----------|--------|
| 5 | 51-55 |
| 6 | 61-65 |
| 7 | 71-75 |
| 8 | 81-85 |
---
## Estados de Pieza
- `sano` - Sin patologia
- `caries` - Caries activa
- `obturacion_resina` - Resina
- `obturacion_amalgama` - Amalgama
- `endodoncia` - Tratamiento de conducto
- `corona` - Protesis fija
- `implante` - Implante dental
- `ausente` - Pieza ausente
---
## Normativas
- **NOM-004-SSA3-2012**: Auditoria de llamadas
- **NOM-013-SSA2-2015**: Nomenclatura FDI
- **COFEPRIS**: Registro de materiales
---
## Indice de Documentos
### Requerimientos
| ID | Descripcion | Estado |
|----|-------------|--------|
| RF-MCP-001 | Odontograma Tools | Draft |
| RF-MCP-002 | Tratamientos Tools | Draft |
| RF-MCP-003 | Citas Tools | Draft |
| RF-MCP-004 | Auditoria NOM-004 | Draft |
### Especificaciones
| ID | Descripcion | Estado |
|----|-------------|--------|
| ET-MCP-DATABASE | Modelo de datos | Draft |
| ET-MCP-BACKEND | API y servicios | Draft |
| ET-MCP-TOOLS | Definicion de tools | Draft |
---
*Mapa | MGN-022-mcp-server | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,172 +0,0 @@
---
id: fase-05-ia
title: Fase 05 - Inteligencia Artificial para Clinica Dental
type: PhaseOverview
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
normativas: [NOM-013-SSA2-2015, COFEPRIS, LFPDPPP]
---
# Fase 05: Inteligencia Artificial para Clinica Dental
## Descripcion
Esta fase implementa capacidades de Inteligencia Artificial especializadas para el dominio odontologico. Incluye un gateway LLM multi-proveedor, integracion con WhatsApp Business para comunicacion con pacientes, y un servidor MCP con herramientas especificas para consultar odontogramas, registrar tratamientos y gestionar citas dentales.
---
## Modulos de la Fase
| ID | Modulo | Descripcion | Prioridad |
|----|--------|-------------|-----------|
| MGN-020 | [AI Integration](./MGN-020-ai-integration/) | Gateway LLM multi-proveedor | P1 |
| MGN-021 | [WhatsApp Business](./MGN-021-whatsapp-business/) | Comunicacion IA con pacientes | P1 |
| MGN-022 | [MCP Server](./MGN-022-mcp-server/) | Herramientas MCP odontologicas | P0 |
---
## Capacidades IA Especializadas
### Asistente Dental Virtual
El asistente IA esta especializado en:
- Consulta de odontogramas y estado de piezas dentales
- Explicacion de tratamientos y procedimientos
- Recordatorios de citas y seguimiento de tratamientos
- Instrucciones postoperatorias personalizadas
- Respuesta a dudas sobre higiene bucal
### System Prompt Especializado
```
Eres el asistente virtual de {{CLINICA_DENTAL}}, una clinica dental en Mexico.
Especialidades:
- Odontologia general y preventiva
- Ortodoncia y alineadores
- Endodoncia y tratamientos de conductos
- Periodoncia y cirugia
- Estetica dental
Conocimientos:
- Nomenclatura dental FDI (sistema de dos digitos)
- Cuadrantes: 1-Superior derecho, 2-Superior izq, 3-Inferior izq, 4-Inferior der
- Piezas permanentes: 11-18, 21-28, 31-38, 41-48
- Piezas deciduas: 51-55, 61-65, 71-75, 81-85
Reglas:
1. Responde en espanol mexicano profesional pero calido
2. Nunca des diagnosticos, siempre recomienda visita al odontologo
3. Explica procedimientos de forma clara y sin tecnicismos excesivos
4. Para citas, usa el calendario del consultorio
5. Respeta la confidencialidad del expediente clinico
6. Cumple con NOM-013-SSA2-2015 y normativas COFEPRIS
```
---
## Herramientas MCP Odontologicas
| Herramienta | Descripcion | Categoria |
|-------------|-------------|-----------|
| `consultar_odontograma` | Ver estado completo de piezas dentales | Diagnostico |
| `registrar_tratamiento` | Registrar procedimiento realizado | Tratamientos |
| `agendar_cita_dental` | Programar cita con disponibilidad | Citas |
| `consultar_historial_dental` | Ver historial de tratamientos | Expediente |
| `verificar_disponibilidad_sillon` | Consultar agenda por sillon | Citas |
| `generar_presupuesto_dental` | Crear presupuesto de tratamiento | Facturacion |
---
## WhatsApp Templates Dentales
### Recordatorio de Cita
```
Hola {{NOMBRE}}, te recordamos tu cita dental:
Fecha: {{FECHA}}
Hora: {{HORA}}
Doctor(a): {{DOCTOR}}
Tratamiento: {{TRATAMIENTO}}
Clinica Dental {{CLINICA_DENTAL}}
Confirma tu asistencia respondiendo SI o NO.
```
### Confirmacion de Tratamiento
```
{{NOMBRE}}, tu tratamiento ha sido registrado:
Pieza(s): {{PIEZAS}}
Procedimiento: {{PROCEDIMIENTO}}
Proxima cita: {{PROXIMA_CITA}}
Instrucciones de cuidado:
{{INSTRUCCIONES}}
Cualquier duda, contactanos.
```
### Instrucciones Postoperatorio
```
{{NOMBRE}}, instrucciones post-{{PROCEDIMIENTO}}:
1. {{INSTRUCCION_1}}
2. {{INSTRUCCION_2}}
3. {{INSTRUCCION_3}}
Medicamentos recetados:
{{MEDICAMENTOS}}
Si presentas {{SINTOMAS_ALERTA}}, acude de inmediato.
Tel. emergencias: {{TELEFONO}}
```
---
## Normativas y Privacidad
### NOM-013-SSA2-2015
- Trazabilidad de tratamientos
- Registros de procedimientos
- Protocolos de atencion
### COFEPRIS
- Registro de materiales dentales
- Trazabilidad de insumos
- Bitacora de procedimientos
### LFPDPPP (Datos Personales)
- Expediente clinico como dato sensible
- Consentimiento para uso de IA
- No almacenar datos biometricos sin autorizacion
---
## Estructura de Directorios
```
05-fase-ia/
+-- README.md <- ESTE ARCHIVO
+-- _MAP.md <- Indice de navegacion
+-- MGN-020-ai-integration/ <- Gateway LLM
+-- MGN-021-whatsapp-business/ <- Comunicacion pacientes
+-- MGN-022-mcp-server/ <- Herramientas MCP dentales
```
---
## Referencias
- [ARQUITECTURA-IA.md](../00-vision-general/ARQUITECTURA-IA.md) - Arquitectura IA
- [erp-core/05-fase-ia](../../../../erp-core/docs/05-fase-ia/) - Documentacion origen
- [OpenRouter Docs](https://openrouter.ai/docs) - Gateway LLM
- [Meta WhatsApp Cloud API](https://developers.facebook.com/docs/whatsapp/cloud-api)
---
*Fase 05 - IA | Clinica Dental*
*Propagado desde erp-core via erp-clinicas*
*Actualizado: 2026-01-13*

View File

@ -1,115 +0,0 @@
---
id: MAP-fase-05-ia
title: Mapa de Navegacion - Fase 05 IA
type: NavigationMap
status: Draft
version: 1.0.0
created_date: 2026-01-13
updated_date: 2026-01-13
---
# Mapa de Navegacion - Fase 05: Inteligencia Artificial
## Estructura de la Fase
```
05-fase-ia/
+-- README.md <- Vision general de la fase
+-- _MAP.md <- ESTE ARCHIVO
|
+-- MGN-020-ai-integration/ <- Gateway LLM
| +-- README.md <- Vision del modulo
| +-- _MAP.md <- Indice del modulo
| +-- requerimientos/ <- RFs de AI
| +-- especificaciones/ <- ETs tecnicas
| +-- historias-usuario/ <- User stories
| +-- implementacion/ <- Trazabilidad
|
+-- MGN-021-whatsapp-business/ <- WhatsApp + IA
| +-- README.md <- Vision del modulo
| +-- _MAP.md <- Indice del modulo
| +-- ... <- Subdirectorios
|
+-- MGN-022-mcp-server/ <- Herramientas MCP
+-- README.md <- Vision del modulo
+-- _MAP.md <- Indice del modulo
+-- ... <- Subdirectorios
```
---
## Indice de Modulos
| Modulo | Descripcion | Estado | Prioridad |
|--------|-------------|--------|-----------|
| [MGN-020-ai-integration](./MGN-020-ai-integration/) | Gateway LLM multi-proveedor | Draft | P1 |
| [MGN-021-whatsapp-business](./MGN-021-whatsapp-business/) | Comunicacion IA con pacientes | Draft | P1 |
| [MGN-022-mcp-server](./MGN-022-mcp-server/) | Herramientas MCP odontologicas | Draft | P0 |
---
## Flujo de Navegacion Recomendado
### Para Entender la Fase
```
1. README.md -> Vision general IA
2. MGN-022-mcp-server/README.md -> Herramientas disponibles
3. MGN-020-ai-integration/README.md -> Gateway LLM
4. MGN-021-whatsapp-business/README.md -> WhatsApp
```
### Para Implementar
```
1. MGN-020-ai-integration/ -> Configurar OpenRouter
2. MGN-022-mcp-server/ -> Implementar tools dentales
3. MGN-021-whatsapp-business/ -> Configurar Meta API
```
---
## Herramientas MCP Odontologicas
| Tool | Categoria | Descripcion |
|------|-----------|-------------|
| `consultar_odontograma` | Diagnostico | Ver piezas dentales y estados |
| `registrar_tratamiento` | Tratamiento | Documentar procedimiento |
| `agendar_cita_dental` | Citas | Programar con disponibilidad |
| `consultar_historial_dental` | Expediente | Historial del paciente |
| `verificar_disponibilidad` | Citas | Agenda de sillones |
| `generar_presupuesto` | Facturacion | Cotizacion de tratamiento |
---
## Templates WhatsApp Dentales
| Template | Uso |
|----------|-----|
| `recordatorio_cita_dental` | 24h antes de cita |
| `confirmacion_tratamiento` | Post-procedimiento |
| `instrucciones_postoperatorio` | Cuidados especiales |
---
## Privacidad y Normativas
- **NOM-013-SSA2-2015**: Registros de tratamientos
- **COFEPRIS**: Materiales y procedimientos
- **LFPDPPP**: Expediente clinico como dato sensible
- **Consentimiento IA**: Requerido para procesamiento
---
## Referencias Cruzadas
| Documento | Ubicacion | Descripcion |
|-----------|-----------|-------------|
| Arquitectura IA | ../00-vision-general/ | Arquitectura general |
| Origen erp-core | erp-core/docs/05-fase-ia/ | Documentacion base |
| OpenRouter | openrouter.ai/docs | Gateway LLM |
---
*Mapa de Navegacion | Fase 05 IA | Clinica Dental*
*Actualizado: 2026-01-13*

View File

@ -1,50 +0,0 @@
# Clinica Dental - Documentacion
Sistema de gestion especializado para clinicas dentales y odontologicas.
## Nivel Jerarquico
- **Nivel:** SUB_CONSUMER
- **Parent:** erp-clinicas
- **Especialidad:** Odontologia
## Estructura de Documentacion
```
docs/
├── README.md # Este archivo
├── 00-vision-general/ # Vision y objetivos del proyecto
├── 01-requisitos/ # Requisitos funcionales y tecnicos
├── 02-arquitectura/ # Diagramas y decisiones arquitectonicas
├── 03-diseno/ # Diseno de modulos y flujos
├── 04-SAAS/ # Modulos SaaS (billing, plans, etc)
├── 05-IA/ # Integraciones de IA
└── 95-guias-desarrollo/ # Guias y estandares
```
## Modulos Especializados
1. **Odontograma Digital** - Registro visual de estado dental
2. **Historia Clinica Dental** - Historial odontologico completo
3. **Agenda de Citas** - Gestion de turnos y recordatorios
4. **Tratamientos y Presupuestos** - Planes de tratamiento con costos
5. **Radiografias e Imagenes** - Gestion de estudios dentales
6. **Facturacion CFDI** - Facturacion electronica mexicana
## Herencia
Este proyecto hereda funcionalidad de:
- `erp-clinicas` (parent directo)
- `erp-core` (core ERP)
- `template-saas` (funcionalidades SaaS base)
## Cumplimiento Normativo
- NOM-013-SSA2-2015 (Control de enfermedades bucales)
- COFEPRIS (Registros sanitarios)
## Referencias
- [DEPENDENCY-GRAPH.yml](/orchestration/DEPENDENCY-GRAPH.yml)
- [MASTER_INVENTORY.yml](/orchestration/inventarios/MASTER_INVENTORY.yml)
- [Mirror Index](/shared/mirrors/MIRRORS-INDEX.yml)

View File

@ -2,9 +2,8 @@
**Proyecto:** clinica-dental
**Tipo:** ERP Especializado (hereda de erp-clinicas)
**Fecha:** 2026-01-16
**Estado:** Fase 0 - Preparacion + Fases SaaS/IA Propagadas
**Nivel Herencia:** 3 (erp-core -> erp-clinicas -> clinica-dental)
**Fecha:** 2026-01-07
**Estado:** Fase 0 - Preparacion
---
@ -12,86 +11,31 @@
```
docs/
+-- _MAP.md <- ESTE ARCHIVO
+-- _definitions/ <- NUEVO: Definiciones canonicas
| +-- _INDEX.yml <- Indice de definiciones
| +-- DATABASE-SCHEMA.md <- Schema de base de datos
| +-- ENTITIES-CATALOG.md <- Catalogo de entidades
| +-- SERVICES-CATALOG.md <- Catalogo de servicios
| +-- MODULES-CATALOG.md <- Catalogo de modulos
|
+-- _quick/ <- NUEVO: Navegacion rapida
| +-- QUICK-INDEX.yml <- Indice de accesos rapidos
| +-- QUICK-MODULES.yml <- Modulos por estado/categoria
| +-- QUICK-DATABASE.yml <- Tablas y schemas
| +-- QUICK-API.yml <- Endpoints planificados
|
+-- 00-vision-general/
| +-- README.md <- Indice de vision
| +-- VISION.md <- Vision estrategica [PENDIENTE]
|
+-- 01-epicas/
| +-- DENTAL-001-odontograma.md <- Odontograma digital
| +-- DENTAL-002-tratamientos.md <- Tratamientos dentales
| +-- DENTAL-003-ortodoncia.md <- Control ortodoncia
| +-- DENTAL-004-protesis.md <- Trabajos protesicos
| +-- DENTAL-005-radiografias.md <- Radiografias dentales
| +-- DENTAL-006-presupuestos.md <- Presupuestos de tratamiento
|
+-- 02-definicion-modulos/
| +-- _MAP.md <- Indice de modulos [PENDIENTE]
| +-- modulo-odontograma.md <- Odontograma digital [PENDIENTE]
|
+-- 04-fase-saas/ <- Capacidades SaaS (Heredado)
| +-- README.md <- Vision de fase SaaS
| +-- _MAP.md <- Indice de modulos SaaS
| +-- MGN-016-billing/ <- Facturacion y suscripciones
| +-- MGN-017-plans/ <- Planes dentales (Consultorio/Clinica/Centro)
| +-- MGN-018-webhooks/ <- Integraciones externas
| +-- MGN-019-feature-flags/ <- Control de features odontologicas
|
+-- 05-fase-ia/ <- Inteligencia Artificial (Heredado)
| +-- README.md <- Vision de fase IA
| +-- _MAP.md <- Indice de modulos IA
| +-- MGN-020-ai-integration/ <- Gateway LLM dental
| +-- MGN-021-whatsapp-business/ <- WhatsApp IA para pacientes
| +-- MGN-022-mcp-server/ <- Herramientas MCP odontologicas
|
+-- 03-especificaciones/
| +-- ... (futuras especificaciones tecnicas)
|
+-- 04-modelado/
| +-- trazabilidad/
| +-- TRACEABILITY-MASTER.yml <- Trazabilidad de modulos
|
+-- 90-transversal/
+-- ... (documentacion transversal)
├── _MAP.md <- ESTE ARCHIVO
├── 00-vision-general/
│ ├── README.md <- Indice de vision
│ └── VISION.md <- Vision estrategica [PENDIENTE]
├── 02-definicion-modulos/
│ ├── _MAP.md <- Indice de modulos [PENDIENTE]
│ ├── modulo-odontograma.md <- Odontograma digital [PENDIENTE]
│ ├── modulo-tratamientos.md <- Tratamientos dentales [PENDIENTE]
│ ├── modulo-ortodoncia.md <- Control ortodoncia [PENDIENTE]
│ ├── modulo-protesis.md <- Trabajos protesicos [PENDIENTE]
│ ├── modulo-endodoncia.md <- Tratamientos conductos [PENDIENTE]
│ ├── modulo-periodoncia.md <- Enfermedad periodontal [PENDIENTE]
│ ├── modulo-prevencion.md <- Profilaxis, selladores [PENDIENTE]
│ └── modulo-estetica.md <- Blanqueamiento, carillas [PENDIENTE]
├── 03-especificaciones/
│ └── ... (futuras especificaciones tecnicas)
└── 90-transversal/
└── ... (documentacion transversal)
```
---
## Navegacion Rapida
### Definiciones Canonicas (@PROJ_DEF_*)
| Alias | Archivo | Descripcion |
|-------|---------|-------------|
| @PROJ_DEF_DB | [DATABASE-SCHEMA.md](./_definitions/DATABASE-SCHEMA.md) | Schema de base de datos dental |
| @PROJ_DEF_ENTITIES | [ENTITIES-CATALOG.md](./_definitions/ENTITIES-CATALOG.md) | Catalogo de entidades |
| @PROJ_DEF_SERVICES | [SERVICES-CATALOG.md](./_definitions/SERVICES-CATALOG.md) | Catalogo de servicios |
| @PROJ_DEF_MODULES | [MODULES-CATALOG.md](./_definitions/MODULES-CATALOG.md) | Catalogo de modulos |
### Accesos Rapidos (@PROJ_QUICK_*)
| Alias | Archivo | Descripcion |
|-------|---------|-------------|
| @PROJ_QUICK_INDEX | [QUICK-INDEX.yml](./_quick/QUICK-INDEX.yml) | Punto de entrada rapido |
| @PROJ_QUICK_MODULES | [QUICK-MODULES.yml](./_quick/QUICK-MODULES.yml) | Modulos por estado |
| @PROJ_QUICK_DB | [QUICK-DATABASE.yml](./_quick/QUICK-DATABASE.yml) | Tablas y schemas |
| @PROJ_QUICK_API | [QUICK-API.yml](./_quick/QUICK-API.yml) | Endpoints planificados |
---
## Modulos Especializados (Odontologia)
### Modulos Core
@ -180,89 +124,14 @@ Nomenclatura FDI:
---
## Fase 04: Capacidades SaaS (Propagada desde erp-core)
Modulos de monetizacion y suscripciones adaptados al dominio odontologico.
| Modulo | Descripcion | Estado |
|--------|-------------|--------|
| [MGN-016-billing](./04-fase-saas/MGN-016-billing/) | Facturacion y suscripciones con Stripe | Propagado |
| [MGN-017-plans](./04-fase-saas/MGN-017-plans/) | Planes: Consultorio, Clinica, Centro Dental | Propagado |
| [MGN-018-webhooks](./04-fase-saas/MGN-018-webhooks/) | Webhooks para integraciones externas | Propagado |
| [MGN-019-feature-flags](./04-fase-saas/MGN-019-feature-flags/) | Feature flags odontologicos | Propagado |
### Planes Dentales
| Plan | Precio/mes | Sillones | Features Clave |
|------|------------|----------|----------------|
| Consultorio | $499 MXN | 1 | Odontograma basico |
| Clinica | $1,499 MXN | 5 | + Ortodoncia, Radiografias |
| Centro Dental | $3,999 MXN | Ilimitado | + IA, WhatsApp, Multi-sucursal |
---
## Fase 05: Inteligencia Artificial (Propagada desde erp-core)
Modulos de IA especializados en odontologia con herramientas MCP dentales.
| Modulo | Descripcion | Estado |
|--------|-------------|--------|
| [MGN-020-ai-integration](./05-fase-ia/MGN-020-ai-integration/) | Gateway LLM con system prompt dental | Propagado |
| [MGN-021-whatsapp-business](./05-fase-ia/MGN-021-whatsapp-business/) | WhatsApp IA para comunicacion con pacientes | Propagado |
| [MGN-022-mcp-server](./05-fase-ia/MGN-022-mcp-server/) | Herramientas MCP: odontograma, citas, tratamientos | Propagado |
### Herramientas MCP Odontologicas
- `consultar_odontograma` - Ver estado de piezas dentales
- `registrar_tratamiento` - Documentar procedimiento
- `agendar_cita_dental` - Programar cita
- `consultar_historial_dental` - Historial del paciente
- `generar_presupuesto_dental` - Cotizacion de tratamiento
### Templates WhatsApp Dentales
- `recordatorio_cita_dental` - 24h antes de cita
- `confirmacion_tratamiento` - Post-procedimiento
- `instrucciones_postoperatorio` - Cuidados especiales
---
## Normativas Aplicables
| Normativa | Descripcion | Estado |
|-----------|-------------|--------|
| NOM-013-SSA2-2015 | Prevencion y control enfermedades bucales | Pendiente |
| NOM-004-SSA3-2012 | Expediente clinico | Pendiente |
| COFEPRIS | Regulacion sanitaria | Pendiente |
| LFPDPPP | Proteccion de datos personales | Pendiente |
---
## Referencias
- [CONTEXTO-PROYECTO.md](../orchestration/00-guidelines/CONTEXTO-PROYECTO.md)
- [HERENCIA-ERP-CLINICAS.md](../orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md)
- [PROXIMA-ACCION.md](../orchestration/PROXIMA-ACCION.md)
- [CONTEXT-MAP.yml](../orchestration/CONTEXT-MAP.yml)
- [04-fase-saas/README.md](./04-fase-saas/README.md) - Vision SaaS
- [05-fase-ia/README.md](./05-fase-ia/README.md) - Vision IA
- [PROPAGATION-STATUS.yml](../../shared/mirrors/clinica-dental/PROPAGATION-STATUS.yml) - Estado de propagacion
---
## Orchestration
### Referencias y Trazabilidad
| Archivo | Descripcion |
|---------|-------------|
| [WS-REFERENCES.yml](../orchestration/_refs/WS-REFERENCES.yml) | Referencias a workspace (nivel=3) |
| [DEPENDENCY-GRAPH.yml](../orchestration/DEPENDENCY-GRAPH.yml) | Grafo de dependencias |
| [TRACEABILITY.yml](../orchestration/TRACEABILITY.yml) | Trazabilidad modulo-objetos |
| [CONTEXT-MAP.yml](../orchestration/CONTEXT-MAP.yml) | Contexto del proyecto |
---
**Ultima actualizacion:** 2026-01-16
**Version:** 1.2.0
**Propagacion:** PROP-CDT-002 (Fases SaaS + IA desde erp-core via erp-clinicas)
**Ultima actualizacion:** 2026-01-07
**Version:** 1.0.0

View File

@ -1,34 +0,0 @@
# Single Source of Truth (SSOT) - CLINICA-DENTAL
**Version:** 1.0.0
**Fecha:** 2026-01-18
**Proyecto:** clinica-dental
**Sistema:** SIMCO v4.0.0
---
## Herencia
```
template-saas (PROVIDER)
erp-core (INTERMEDIATE)
erp-clinicas (INTERMEDIATE)
clinica-dental (SPECIALIZES) ← ESTE PROYECTO
```
---
## Archivos SSOT
| Archivo | Descripcion | Estado |
|---------|-------------|--------|
| EPIC-INDEX.yml | Indice de epicas | PENDIENTE |
| TRACEABILITY-MASTER.yml | Trazabilidad maestra | PENDIENTE |
---
**Creado:** 2026-01-18
**Mantenido por:** @CLINICA_DENTAL_ORCHESTRATOR

View File

@ -1,526 +0,0 @@
# Database Schema - clinica-dental
**Alias:** @PROJ_DEF_DB
**Version:** 1.0.0
**Ultima actualizacion:** 2026-01-16
---
## 1. RESUMEN
| Metrica | Valor |
|---------|-------|
| **Total Schemas** | 1 (dental) |
| **Total Tablas** | 11 |
| **Total Catalogos** | 2 |
| **Total Enums** | 4 |
| **Total Relaciones** | 15+ |
---
## 2. HERENCIA DE SCHEMAS
```yaml
herencia:
desde_erp_core:
- auth # Autenticacion y sesiones
- tenants # Multi-tenancy
- users # Usuarios del sistema
desde_erp_clinicas:
- clinica # Pacientes, citas, consultas
propio:
- dental # Especializacion odontologica
```
---
## 3. ENUMS
```yaml
enums:
estado_pieza:
valores: ["sano", "caries", "obturacion", "endodoncia", "corona", "puente", "implante", "ausente", "extraccion_indicada", "diente_temporal", "fractura", "movilidad"]
uso: "Estado de una pieza dental"
cara_dental:
valores: ["mesial", "distal", "oclusal", "incisal", "vestibular", "bucal", "lingual", "palatino"]
uso: "Caras de una pieza dental"
estado_tratamiento:
valores: ["pendiente", "en_proceso", "completado", "cancelado"]
uso: "Estado de un tratamiento"
tipo_ortodoncia:
valores: ["brackets_metalicos", "brackets_esteticos", "brackets_linguales", "alineadores", "removible", "retenedor"]
uso: "Tipo de tratamiento ortodontico"
```
---
## 4. CATALOGOS
### 4.1 dental.piezas_dentales
```yaml
tabla: "piezas_dentales"
schema: "dental"
tipo: "catalogo_global"
descripcion: "Catalogo de piezas dentales (nomenclatura FDI)"
registros: 52
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "numero"
tipo: "VARCHAR(10)"
unique: true
descripcion: "Numero FDI (11-48, 51-85)"
- nombre: "nombre"
tipo: "VARCHAR(50)"
not_null: true
- nombre: "cuadrante"
tipo: "INTEGER"
check: "BETWEEN 1 AND 8"
- nombre: "es_temporal"
tipo: "BOOLEAN"
default: false
- nombre: "descripcion"
tipo: "TEXT"
```
### 4.2 dental.tratamientos_catalogo
```yaml
tabla: "tratamientos_catalogo"
schema: "dental"
tipo: "catalogo_tenant"
descripcion: "Catalogo de tratamientos dentales por tenant"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "codigo"
tipo: "VARCHAR(20)"
not_null: true
- nombre: "nombre"
tipo: "VARCHAR(100)"
not_null: true
- nombre: "categoria"
tipo: "VARCHAR(50)"
descripcion: "prevencion, restauracion, endodoncia, etc."
- nombre: "duracion_minutos"
tipo: "INTEGER"
default: 30
- nombre: "precio_base"
tipo: "NUMERIC(10,2)"
- nombre: "requiere_rx"
tipo: "BOOLEAN"
default: false
- nombre: "requiere_anestesia"
tipo: "BOOLEAN"
default: false
- nombre: "active"
tipo: "BOOLEAN"
default: true
constraints:
- nombre: "uq_tratamientos_tenant_codigo"
tipo: "UNIQUE"
columnas: ["tenant_id", "codigo"]
```
---
## 5. TABLAS PRINCIPALES
### 5.1 dental.odontogramas
```yaml
tabla: "odontogramas"
schema: "dental"
modulo: "DENTAL-001"
descripcion: "Odontogramas de pacientes"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "patient_id"
tipo: "UUID"
not_null: true
fk: "clinica.patients"
- nombre: "fecha_creacion"
tipo: "DATE"
default: "CURRENT_DATE"
- nombre: "fecha_actualizacion"
tipo: "DATE"
- nombre: "notas"
tipo: "TEXT"
indices:
- "idx_odontogramas_tenant"
- "idx_odontogramas_patient"
```
### 5.2 dental.odontograma_piezas
```yaml
tabla: "odontograma_piezas"
schema: "dental"
modulo: "DENTAL-001"
descripcion: "Estado de cada pieza en el odontograma"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "odontograma_id"
tipo: "UUID"
not_null: true
fk: "dental.odontogramas"
- nombre: "pieza_id"
tipo: "UUID"
not_null: true
fk: "dental.piezas_dentales"
- nombre: "estado"
tipo: "dental.estado_pieza"
default: "sano"
- nombre: "caras_afectadas"
tipo: "JSONB"
descripcion: '{"mesial": "caries", "oclusal": "obturacion"}'
- nombre: "observaciones"
tipo: "TEXT"
constraints:
- nombre: "uq_odontograma_pieza"
tipo: "UNIQUE"
columnas: ["odontograma_id", "pieza_id"]
```
### 5.3 dental.tratamientos_paciente
```yaml
tabla: "tratamientos_paciente"
schema: "dental"
modulo: "DENTAL-002"
descripcion: "Tratamientos realizados a pacientes"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "patient_id"
tipo: "UUID"
not_null: true
- nombre: "odontograma_id"
tipo: "UUID"
fk: "dental.odontogramas"
- nombre: "tratamiento_id"
tipo: "UUID"
fk: "dental.tratamientos_catalogo"
- nombre: "odontologo_id"
tipo: "UUID"
fk: "clinica.doctors"
- nombre: "consultation_id"
tipo: "UUID"
fk: "clinica.consultations"
- nombre: "pieza_id"
tipo: "UUID"
fk: "dental.piezas_dentales"
- nombre: "caras_tratadas"
tipo: "dental.cara_dental[]"
- nombre: "fecha_inicio"
tipo: "DATE"
default: "CURRENT_DATE"
- nombre: "fecha_fin"
tipo: "DATE"
- nombre: "estado"
tipo: "dental.estado_tratamiento"
default: "pendiente"
- nombre: "precio"
tipo: "NUMERIC(10,2)"
- nombre: "descuento"
tipo: "NUMERIC(5,2)"
default: 0
- nombre: "precio_final"
tipo: "NUMERIC(10,2)"
indices:
- "idx_tratamientos_paciente_tenant"
- "idx_tratamientos_paciente_patient"
- "idx_tratamientos_paciente_estado"
```
### 5.4 dental.ortodoncia
```yaml
tabla: "ortodoncia"
schema: "dental"
modulo: "DENTAL-003"
descripcion: "Casos de ortodoncia"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "patient_id"
tipo: "UUID"
not_null: true
- nombre: "odontologo_id"
tipo: "UUID"
- nombre: "tipo"
tipo: "dental.tipo_ortodoncia"
not_null: true
- nombre: "marca"
tipo: "VARCHAR(100)"
- nombre: "fecha_inicio"
tipo: "DATE"
not_null: true
- nombre: "fecha_estimada_fin"
tipo: "DATE"
- nombre: "fecha_real_fin"
tipo: "DATE"
- nombre: "estado"
tipo: "dental.estado_tratamiento"
default: "en_proceso"
- nombre: "meses_estimados"
tipo: "INTEGER"
- nombre: "costo_total"
tipo: "NUMERIC(10,2)"
- nombre: "enganche"
tipo: "NUMERIC(10,2)"
- nombre: "mensualidad"
tipo: "NUMERIC(10,2)"
indices:
- "idx_ortodoncia_tenant"
- "idx_ortodoncia_patient"
- "idx_ortodoncia_estado"
```
### 5.5 dental.protesis
```yaml
tabla: "protesis"
schema: "dental"
modulo: "DENTAL-004"
descripcion: "Trabajos protesicos"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "patient_id"
tipo: "UUID"
not_null: true
- nombre: "odontologo_id"
tipo: "UUID"
- nombre: "tipo"
tipo: "VARCHAR(50)"
not_null: true
descripcion: "corona, puente, parcial, total, implante"
- nombre: "piezas_involucradas"
tipo: "TEXT[]"
- nombre: "laboratorio_id"
tipo: "UUID"
- nombre: "fecha_envio_lab"
tipo: "DATE"
- nombre: "fecha_recepcion_lab"
tipo: "DATE"
- nombre: "material"
tipo: "VARCHAR(100)"
- nombre: "color"
tipo: "VARCHAR(50)"
- nombre: "estado"
tipo: "dental.estado_tratamiento"
default: "en_proceso"
- nombre: "fecha_colocacion"
tipo: "DATE"
- nombre: "tiene_garantia"
tipo: "BOOLEAN"
default: false
- nombre: "meses_garantia"
tipo: "INTEGER"
- nombre: "costo_laboratorio"
tipo: "NUMERIC(10,2)"
- nombre: "precio_paciente"
tipo: "NUMERIC(10,2)"
indices:
- "idx_protesis_tenant"
- "idx_protesis_patient"
```
### 5.6 dental.radiografias
```yaml
tabla: "radiografias"
schema: "dental"
modulo: "DENTAL-005"
descripcion: "Radiografias dentales"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "patient_id"
tipo: "UUID"
not_null: true
- nombre: "consultation_id"
tipo: "UUID"
- nombre: "tipo"
tipo: "VARCHAR(50)"
not_null: true
descripcion: "periapical, panoramica, cefalometrica, oclusal"
- nombre: "pieza_id"
tipo: "UUID"
fk: "dental.piezas_dentales"
- nombre: "fecha"
tipo: "DATE"
default: "CURRENT_DATE"
- nombre: "url_imagen"
tipo: "VARCHAR(255)"
- nombre: "interpretacion"
tipo: "TEXT"
indices:
- "idx_radiografias_tenant"
- "idx_radiografias_patient"
```
### 5.7 dental.presupuestos
```yaml
tabla: "presupuestos"
schema: "dental"
modulo: "DENTAL-006"
descripcion: "Presupuestos de tratamiento"
columnas:
- nombre: "id"
tipo: "UUID"
pk: true
- nombre: "tenant_id"
tipo: "UUID"
not_null: true
- nombre: "patient_id"
tipo: "UUID"
not_null: true
- nombre: "odontologo_id"
tipo: "UUID"
- nombre: "numero"
tipo: "VARCHAR(20)"
- nombre: "fecha"
tipo: "DATE"
default: "CURRENT_DATE"
- nombre: "fecha_vencimiento"
tipo: "DATE"
- nombre: "estado"
tipo: "VARCHAR(20)"
default: "pendiente"
descripcion: "pendiente, aprobado, rechazado, vencido"
- nombre: "subtotal"
tipo: "NUMERIC(12,2)"
default: 0
- nombre: "descuento_porcentaje"
tipo: "NUMERIC(5,2)"
default: 0
- nombre: "descuento_monto"
tipo: "NUMERIC(12,2)"
default: 0
- nombre: "total"
tipo: "NUMERIC(12,2)"
default: 0
- nombre: "requiere_financiamiento"
tipo: "BOOLEAN"
default: false
- nombre: "enganche"
tipo: "NUMERIC(12,2)"
- nombre: "numero_pagos"
tipo: "INTEGER"
- nombre: "monto_pago"
tipo: "NUMERIC(12,2)"
indices:
- "idx_presupuestos_tenant"
- "idx_presupuestos_patient"
- "idx_presupuestos_estado"
```
---
## 6. RELACIONES
```
dental Schema:
┌─────────────────────┐
│ piezas_dentales │ (catalogo global)
└──────────┬──────────┘
┌─────────────────┼─────────────────┬───────────────────┐
│ │ │ │
▼ ▼ ▼ ▼
┌──────────┐ ┌─────────────┐ ┌───────────┐ ┌─────────────┐
│odontograma│ │tratamientos │ │radiografias│ │presupuesto_ │
│_piezas │ │_paciente │ │ │ │lineas │
└────┬─────┘ └──────┬──────┘ └───────────┘ └──────┬──────┘
│ │ │
│ │ │
▼ │ ▼
┌──────────┐ │ ┌─────────────┐
│odontogramas│◄────────┘ │presupuestos │
└────┬─────┘ └─────────────┘
│ clinica Schema (heredado):
┌──────────┐ ┌──────────┐ ┌────────────────┐
│ patients │◄────────│ doctors │◄────────│ specialties │
└──────────┘ └──────────┘ └────────────────┘
│ │
│ │
▼ ▼
┌──────────┐ ┌──────────────┐
│ortodoncia│ │consultations │
└────┬─────┘ └──────────────┘
┌──────────────┐
│ortodoncia_ │
│citas │
└──────────────┘
```
---
## 7. ROW LEVEL SECURITY
Todas las tablas del schema `dental` tienen RLS habilitado con politica de aislamiento por tenant:
```sql
-- Patron aplicado a todas las tablas
CREATE POLICY tenant_isolation_{tabla} ON dental.{tabla}
USING (tenant_id = current_setting('app.current_tenant_id', true)::UUID);
```
---
## 8. REFERENCIAS
- DDL completo: `database/schemas/01-dental-schema-ddl.sql`
- Seeds: `database/seeds/fase8/01-dental-catalogos.sql`
- Inventario: `orchestration/inventarios/DATABASE_INVENTORY.yml`
- Entities: Ver @PROJ_DEF_ENTITIES
- Herencia: `orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md`
---
*Database Schema | clinica-dental | v1.0.0*
*Ultima actualizacion: 2026-01-16*

View File

@ -1,216 +0,0 @@
# Entities Catalog - clinica-dental
**Alias:** @PROJ_DEF_ENTITIES
**Version:** 1.0.0
**Ultima actualizacion:** 2026-01-16
---
## 1. RESUMEN
| Metrica | Valor |
|---------|-------|
| **Total Entities Propias** | 0 (Pendiente implementacion) |
| **Total Entities Heredadas** | 10 (de erp-clinicas) |
| **Estado** | Planificado |
---
## 2. ENTITIES PLANIFICADAS
### 2.1 Modulo: Odontograma (DENTAL-001)
| Entity | Archivo Planificado | Tabla BD | Descripcion |
|--------|---------------------|----------|-------------|
| Odontograma | `odontograma.entity.ts` | dental.odontogramas | Registro de odontograma |
| OdontogramaPieza | `odontograma-pieza.entity.ts` | dental.odontograma_piezas | Estado de piezas |
| PiezaDental | `pieza-dental.entity.ts` | dental.piezas_dentales | Catalogo de piezas |
### 2.2 Modulo: Tratamientos (DENTAL-002)
| Entity | Archivo Planificado | Tabla BD | Descripcion |
|--------|---------------------|----------|-------------|
| TratamientoCatalogo | `tratamiento-catalogo.entity.ts` | dental.tratamientos_catalogo | Catalogo de tratamientos |
| TratamientoPaciente | `tratamiento-paciente.entity.ts` | dental.tratamientos_paciente | Tratamientos realizados |
### 2.3 Modulo: Ortodoncia (DENTAL-003)
| Entity | Archivo Planificado | Tabla BD | Descripcion |
|--------|---------------------|----------|-------------|
| Ortodoncia | `ortodoncia.entity.ts` | dental.ortodoncia | Casos de ortodoncia |
| OrtodonciaCita | `ortodoncia-cita.entity.ts` | dental.ortodoncia_citas | Seguimiento ortodontico |
### 2.4 Modulo: Protesis (DENTAL-004)
| Entity | Archivo Planificado | Tabla BD | Descripcion |
|--------|---------------------|----------|-------------|
| Protesis | `protesis.entity.ts` | dental.protesis | Trabajos protesicos |
### 2.5 Modulo: Radiografias (DENTAL-005)
| Entity | Archivo Planificado | Tabla BD | Descripcion |
|--------|---------------------|----------|-------------|
| Radiografia | `radiografia.entity.ts` | dental.radiografias | Radiografias dentales |
### 2.6 Modulo: Presupuestos (DENTAL-006)
| Entity | Archivo Planificado | Tabla BD | Descripcion |
|--------|---------------------|----------|-------------|
| Presupuesto | `presupuesto.entity.ts` | dental.presupuestos | Presupuestos de tratamiento |
| PresupuestoLinea | `presupuesto-linea.entity.ts` | dental.presupuesto_lineas | Lineas de presupuesto |
---
## 3. UBICACION PLANIFICADA
```
backend/src/modules/
├── odontograma/
│ └── entities/
│ ├── odontograma.entity.ts
│ ├── odontograma-pieza.entity.ts
│ └── pieza-dental.entity.ts
├── tratamientos/
│ └── entities/
│ ├── tratamiento-catalogo.entity.ts
│ └── tratamiento-paciente.entity.ts
├── ortodoncia/
│ └── entities/
│ ├── ortodoncia.entity.ts
│ └── ortodoncia-cita.entity.ts
├── protesis/
│ └── entities/
│ └── protesis.entity.ts
├── radiografias/
│ └── entities/
│ └── radiografia.entity.ts
└── presupuestos/
└── entities/
├── presupuesto.entity.ts
└── presupuesto-linea.entity.ts
```
---
## 4. RELACIONES PLANIFICADAS
```yaml
relaciones:
Odontograma:
belongs_to: [Patient]
has_many: [OdontogramaPieza, TratamientoPaciente]
OdontogramaPieza:
belongs_to: [Odontograma, PiezaDental]
PiezaDental:
has_many: [OdontogramaPieza, TratamientoPaciente, Radiografia, PresupuestoLinea]
TratamientoCatalogo:
has_many: [TratamientoPaciente, PresupuestoLinea]
TratamientoPaciente:
belongs_to: [Patient, Doctor, Odontograma, TratamientoCatalogo, PiezaDental, Consultation]
Ortodoncia:
belongs_to: [Patient, Doctor]
has_many: [OrtodonciaCita]
OrtodonciaCita:
belongs_to: [Ortodoncia, Appointment]
Protesis:
belongs_to: [Patient, Doctor]
Radiografia:
belongs_to: [Patient, Consultation, PiezaDental]
Presupuesto:
belongs_to: [Patient, Doctor]
has_many: [PresupuestoLinea]
PresupuestoLinea:
belongs_to: [Presupuesto, TratamientoCatalogo, PiezaDental]
```
---
## 5. ENTIDADES HEREDADAS (de erp-clinicas)
| Entity | Origen | Uso en clinica-dental |
|--------|--------|----------------------|
| Patient | erp-clinicas | Pacientes dentales |
| Doctor | erp-clinicas | Odontologos |
| Specialty | erp-clinicas | Especialidades dentales |
| Appointment | erp-clinicas | Citas dentales |
| AppointmentSlot | erp-clinicas | Horarios de odontologos |
| Consultation | erp-clinicas | Consultas dentales |
| Diagnosis | erp-clinicas | Diagnosticos |
| Prescription | erp-clinicas | Recetas |
| PrescriptionItem | erp-clinicas | Items de receta |
| VitalSigns | erp-clinicas | Signos vitales |
---
## 6. ENUMS TYPESCRIPT (Planificados)
```typescript
// Definidos en el schema SQL, replicados en TypeScript
enum EstadoPieza {
SANO = 'sano',
CARIES = 'caries',
OBTURACION = 'obturacion',
ENDODONCIA = 'endodoncia',
CORONA = 'corona',
PUENTE = 'puente',
IMPLANTE = 'implante',
AUSENTE = 'ausente',
EXTRACCION_INDICADA = 'extraccion_indicada',
DIENTE_TEMPORAL = 'diente_temporal',
FRACTURA = 'fractura',
MOVILIDAD = 'movilidad'
}
enum CaraDental {
MESIAL = 'mesial',
DISTAL = 'distal',
OCLUSAL = 'oclusal',
INCISAL = 'incisal',
VESTIBULAR = 'vestibular',
BUCAL = 'bucal',
LINGUAL = 'lingual',
PALATINO = 'palatino'
}
enum EstadoTratamiento {
PENDIENTE = 'pendiente',
EN_PROCESO = 'en_proceso',
COMPLETADO = 'completado',
CANCELADO = 'cancelado'
}
enum TipoOrtodoncia {
BRACKETS_METALICOS = 'brackets_metalicos',
BRACKETS_ESTETICOS = 'brackets_esteticos',
BRACKETS_LINGUALES = 'brackets_linguales',
ALINEADORES = 'alineadores',
REMOVIBLE = 'removible',
RETENEDOR = 'retenedor'
}
```
---
## 7. REFERENCIAS
- Database Schema: @PROJ_DEF_DB
- Services: @PROJ_DEF_SERVICES
- Ubicacion futura: `backend/src/modules/*/entities/`
- DDL: `database/schemas/01-dental-schema-ddl.sql`
- Herencia erp-clinicas: `orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md`
---
*Entities Catalog | clinica-dental | v1.0.0*
*Ultima actualizacion: 2026-01-16*

View File

@ -1,332 +0,0 @@
# Modules Catalog - clinica-dental
**Alias:** @PROJ_DEF_MODULES
**Version:** 1.0.0
**Ultima actualizacion:** 2026-01-16
---
## 1. RESUMEN
| Metrica | Valor |
|---------|-------|
| **Total Modulos Propios** | 6 |
| **Total Modulos Heredados (erp-core)** | 16 |
| **Total Modulos Heredados (erp-clinicas)** | 10 |
| **Documentados** | 6 |
| **En Desarrollo** | 0 |
| **Planificados** | 6 |
---
## 2. INDICE DE MODULOS
### 2.1 Modulos Core (Heredados de erp-core)
| ID | Nombre | Herencia | Estado | Documentacion |
|----|--------|----------|--------|---------------|
| MGN-001 | Authentication | 100% | Heredado | @WS_DEF_CCA |
| MGN-002 | Users | 100% | Heredado | @WS_DEF_CCA |
| MGN-003 | Roles | 100% | Heredado | @WS_DEF_CCA |
| MGN-004 | Tenants | Extendido | Heredado | @WS_DEF_CCA |
| MGN-005 | Catalogs | Extendido | Heredado | @WS_DEF_CCA |
| MGN-007 | Audit | 100% | Heredado | @WS_DEF_CCA |
| MGN-008 | Notifications | 100% | Heredado | @WS_DEF_CCA |
| MGN-009 | Reports | Extendido | Heredado | @WS_DEF_CCA |
| MGN-010 | Financial | Extendido | Heredado | @WS_DEF_CCA |
### 2.2 Modulos SaaS (Heredados - Fase 4)
| ID | Nombre | Estado | Documentacion |
|----|--------|--------|---------------|
| MGN-016 | Billing | Heredado | docs/04-fase-saas/MGN-016-billing/ |
| MGN-017 | Plans | Heredado | docs/04-fase-saas/MGN-017-plans/ |
| MGN-018 | Webhooks | Heredado | docs/04-fase-saas/MGN-018-webhooks/ |
| MGN-019 | Feature Flags | Heredado | docs/04-fase-saas/MGN-019-feature-flags/ |
### 2.3 Modulos IA (Heredados - Fase 5)
| ID | Nombre | Estado | Documentacion |
|----|--------|--------|---------------|
| MGN-020 | AI Integration | Heredado | docs/05-fase-ia/MGN-020-ai-integration/ |
| MGN-021 | WhatsApp Business | Heredado | docs/05-fase-ia/MGN-021-whatsapp-business/ |
| MGN-022 | MCP Server | Heredado | docs/05-fase-ia/MGN-022-mcp-server/ |
### 2.4 Modulos Clinicos (Heredados de erp-clinicas)
| ID | Nombre | Herencia | Adaptacion Dental |
|----|--------|----------|-------------------|
| CL-001 | Fundamentos | 100% | Ninguna |
| CL-002 | Pacientes | Extendido | + odontograma_activo_id, tiene_ortodoncia, tiene_protesis |
| CL-003 | Citas | Extendido | + tipos cita dental |
| CL-004 | Consultas | Extendido | + exploracion dental |
| CL-005 | Recetas | 100% | Ninguna |
| CL-006 | Laboratorio | Parcial | Solo laboratorio dental |
| CL-008 | Facturacion | 100% | Ninguna |
| CL-009 | Reportes | Extendido | + reportes odontologicos |
| CL-011 | Expediente | Extendido | + odontograma |
| CL-012 | Imagenologia | Extendido | + radiografias dentales |
### 2.5 Modulos Propios (Odontologicos)
| ID | Nombre | Estado | Documentacion |
|----|--------|--------|---------------|
| DENTAL-001 | Odontograma | Planificado | docs/01-epicas/DENTAL-001-odontograma.md |
| DENTAL-002 | Tratamientos | Planificado | docs/01-epicas/DENTAL-002-tratamientos.md |
| DENTAL-003 | Ortodoncia | Planificado | docs/01-epicas/DENTAL-003-ortodoncia.md |
| DENTAL-004 | Protesis | Planificado | docs/01-epicas/DENTAL-004-protesis.md |
| DENTAL-005 | Radiografias | Planificado | docs/01-epicas/DENTAL-005-radiografias.md |
| DENTAL-006 | Presupuestos | Planificado | docs/01-epicas/DENTAL-006-presupuestos.md |
---
## 3. DETALLE POR MODULO PROPIO
### DENTAL-001: Odontograma
```yaml
modulo:
id: "DENTAL-001"
nombre: "Odontograma"
estado: "planificado"
version: "1.0.0"
documentacion:
especificacion: "docs/01-epicas/DENTAL-001-odontograma.md"
requerimientos: []
historias: []
descripcion: |
Registro grafico del estado dental del paciente:
- Nomenclatura FDI (32 piezas permanentes + 20 temporales)
- Estados por pieza (sano, caries, obturacion, etc.)
- Estados por cara (mesial, distal, oclusal, etc.)
- Historial de cambios
objetos:
tablas: ["dental.odontogramas", "dental.odontograma_piezas", "dental.piezas_dentales"]
entities: ["Odontograma", "OdontogramaPieza", "PiezaDental"]
services: ["OdontogramaService", "OdontogramaPiezaService"]
controllers: []
story_points:
backend: 21
frontend: 21
total: 42
dependencias:
modulos: ["CL-002"]
externos: []
```
### DENTAL-002: Tratamientos
```yaml
modulo:
id: "DENTAL-002"
nombre: "Tratamientos"
estado: "planificado"
version: "1.0.0"
documentacion:
especificacion: "docs/01-epicas/DENTAL-002-tratamientos.md"
descripcion: |
Gestion de tratamientos dentales:
- Catalogo de tratamientos por tenant
- Registro de tratamientos realizados
- Vinculacion con odontograma y piezas
- Seguimiento de estado
objetos:
tablas: ["dental.tratamientos_catalogo", "dental.tratamientos_paciente"]
entities: ["TratamientoCatalogo", "TratamientoPaciente"]
services: ["TratamientoCatalogoService", "TratamientoPacienteService"]
story_points:
backend: 21
frontend: 13
total: 34
dependencias:
modulos: ["DENTAL-001", "CL-002", "CL-004"]
```
### DENTAL-003: Ortodoncia
```yaml
modulo:
id: "DENTAL-003"
nombre: "Ortodoncia"
estado: "planificado"
version: "1.0.0"
documentacion:
especificacion: "docs/01-epicas/DENTAL-003-ortodoncia.md"
descripcion: |
Control de tratamientos de ortodoncia:
- Registro de casos (brackets, alineadores, etc.)
- Seguimiento de citas de ajuste
- Control de pagos mensuales
- Estimacion de duracion
objetos:
tablas: ["dental.ortodoncia", "dental.ortodoncia_citas"]
entities: ["Ortodoncia", "OrtodonciaCita"]
services: ["OrtodonciaService", "OrtodonciaCitaService"]
story_points:
backend: 21
frontend: 21
total: 42
dependencias:
modulos: ["CL-002", "CL-003"]
```
### DENTAL-004: Protesis
```yaml
modulo:
id: "DENTAL-004"
nombre: "Protesis"
estado: "planificado"
version: "1.0.0"
documentacion:
especificacion: "docs/01-epicas/DENTAL-004-protesis.md"
descripcion: |
Gestion de trabajos protesicos:
- Coronas, puentes, parciales, totales
- Seguimiento con laboratorio
- Control de materiales y colores
- Garantias
objetos:
tablas: ["dental.protesis"]
entities: ["Protesis"]
services: ["ProtesisService"]
story_points:
backend: 13
frontend: 13
total: 26
dependencias:
modulos: ["CL-002", "DENTAL-001"]
```
### DENTAL-005: Radiografias
```yaml
modulo:
id: "DENTAL-005"
nombre: "Radiografias"
estado: "planificado"
version: "1.0.0"
documentacion:
especificacion: "docs/01-epicas/DENTAL-005-radiografias.md"
descripcion: |
Gestion de radiografias dentales:
- Periapicales, panoramicas, cefalometricas
- Almacenamiento de imagenes
- Interpretacion y notas
objetos:
tablas: ["dental.radiografias"]
entities: ["Radiografia"]
services: ["RadiografiaService"]
story_points:
backend: 13
frontend: 13
total: 26
dependencias:
modulos: ["CL-002", "CL-004", "CL-012"]
```
### DENTAL-006: Presupuestos
```yaml
modulo:
id: "DENTAL-006"
nombre: "Presupuestos"
estado: "planificado"
version: "1.0.0"
documentacion:
especificacion: "docs/01-epicas/DENTAL-006-presupuestos.md"
descripcion: |
Presupuestos de tratamiento dental:
- Lineas de tratamiento con precios
- Descuentos y financiamiento
- Generacion de PDF
- Conversion a tratamientos
objetos:
tablas: ["dental.presupuestos", "dental.presupuesto_lineas"]
entities: ["Presupuesto", "PresupuestoLinea"]
services: ["PresupuestoService"]
story_points:
backend: 21
frontend: 13
total: 34
dependencias:
modulos: ["CL-002", "DENTAL-002"]
```
---
## 4. MATRIZ DE DEPENDENCIAS
```
┌────────────┬──────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ │ DENTAL-1 │ DENTAL-2 │ DENTAL-3 │ DENTAL-4 │ DENTAL-5 │ DENTAL-6 │
├────────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ DENTAL-001 │ - │ │ │ │ │ │
│ DENTAL-002 │ X │ - │ │ │ │ │
│ DENTAL-003 │ │ │ - │ │ │ │
│ DENTAL-004 │ X │ │ │ - │ │ │
│ DENTAL-005 │ │ │ │ │ - │ │
│ DENTAL-006 │ │ X │ │ │ │ - │
└────────────┴──────────┴──────────┴──────────┴──────────┴──────────┴──────────┘
X = depende de
```
---
## 5. STORY POINTS TOTALES
| Modulo | SP Backend | SP Frontend | SP Total |
|--------|-----------|-------------|----------|
| DENTAL-001 | 21 | 21 | 42 |
| DENTAL-002 | 21 | 13 | 34 |
| DENTAL-003 | 21 | 21 | 42 |
| DENTAL-004 | 13 | 13 | 26 |
| DENTAL-005 | 13 | 13 | 26 |
| DENTAL-006 | 21 | 13 | 34 |
| **Total** | **110** | **94** | **204** |
---
## 6. REFERENCIAS
- Database: @PROJ_DEF_DB
- Entities: @PROJ_DEF_ENTITIES
- Services: @PROJ_DEF_SERVICES
- Navegacion rapida: docs/_quick/QUICK-MODULES.yml
- Herencia: orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md
---
*Modules Catalog | clinica-dental | v1.0.0*
*Ultima actualizacion: 2026-01-16*

View File

@ -1,202 +0,0 @@
# Services Catalog - clinica-dental
**Alias:** @PROJ_DEF_SERVICES
**Version:** 1.0.0
**Ultima actualizacion:** 2026-01-16
---
## 1. RESUMEN
| Metrica | Valor |
|---------|-------|
| **Total Services Propios** | 0 (Pendiente implementacion) |
| **Total Services Heredados** | 10+ (de erp-clinicas) |
| **Estado** | Planificado |
---
## 2. SERVICES PLANIFICADOS
### 2.1 Modulo: Odontograma (DENTAL-001)
| Service | Archivo Planificado | Descripcion |
|---------|---------------------|-------------|
| OdontogramaService | `odontograma.service.ts` | CRUD de odontogramas |
| OdontogramaPiezaService | `odontograma-pieza.service.ts` | Gestion de piezas |
### 2.2 Modulo: Tratamientos (DENTAL-002)
| Service | Archivo Planificado | Descripcion |
|---------|---------------------|-------------|
| TratamientoCatalogoService | `tratamiento-catalogo.service.ts` | Catalogo de tratamientos |
| TratamientoPacienteService | `tratamiento-paciente.service.ts` | Tratamientos realizados |
### 2.3 Modulo: Ortodoncia (DENTAL-003)
| Service | Archivo Planificado | Descripcion |
|---------|---------------------|-------------|
| OrtodonciaService | `ortodoncia.service.ts` | Gestion casos ortodoncia |
| OrtodonciaCitaService | `ortodoncia-cita.service.ts` | Seguimiento de citas |
### 2.4 Modulo: Protesis (DENTAL-004)
| Service | Archivo Planificado | Descripcion |
|---------|---------------------|-------------|
| ProtesisService | `protesis.service.ts` | Gestion trabajos protesicos |
### 2.5 Modulo: Radiografias (DENTAL-005)
| Service | Archivo Planificado | Descripcion |
|---------|---------------------|-------------|
| RadiografiaService | `radiografia.service.ts` | Gestion radiografias |
### 2.6 Modulo: Presupuestos (DENTAL-006)
| Service | Archivo Planificado | Descripcion |
|---------|---------------------|-------------|
| PresupuestoService | `presupuesto.service.ts` | Gestion presupuestos |
---
## 3. UBICACION PLANIFICADA
```
backend/src/modules/
├── odontograma/
│ └── services/
│ ├── odontograma.service.ts
│ └── odontograma-pieza.service.ts
├── tratamientos/
│ └── services/
│ ├── tratamiento-catalogo.service.ts
│ └── tratamiento-paciente.service.ts
├── ortodoncia/
│ └── services/
│ ├── ortodoncia.service.ts
│ └── ortodoncia-cita.service.ts
├── protesis/
│ └── services/
│ └── protesis.service.ts
├── radiografias/
│ └── services/
│ └── radiografia.service.ts
└── presupuestos/
└── services/
└── presupuesto.service.ts
```
---
## 4. SERVICES HEREDADOS (de erp-clinicas)
| Service | Origen | Uso en clinica-dental |
|---------|--------|----------------------|
| PatientsService | erp-clinicas | Gestion pacientes |
| DoctorsService | erp-clinicas | Gestion odontologos |
| SpecialtiesService | erp-clinicas | Especialidades dentales |
| AppointmentsService | erp-clinicas | Citas dentales |
| AppointmentSlotsService | erp-clinicas | Horarios disponibles |
| AppointmentSchedulerService | erp-clinicas | Programacion de citas |
| ConsultationsService | erp-clinicas | Consultas dentales |
| DiagnosesService | erp-clinicas | Diagnosticos |
| PrescriptionsService | erp-clinicas | Recetas |
| VitalSignsService | erp-clinicas | Signos vitales |
---
## 5. OPERACIONES PRINCIPALES POR SERVICE
### OdontogramaService
```yaml
operaciones:
crear:
descripcion: "Crear nuevo odontograma para paciente"
parametros: [patient_id, notas]
retorna: Odontograma
obtenerActivo:
descripcion: "Obtener odontograma activo del paciente"
parametros: [patient_id]
retorna: Odontograma
actualizarPieza:
descripcion: "Actualizar estado de pieza dental"
parametros: [odontograma_id, pieza_id, estado, caras_afectadas]
retorna: OdontogramaPieza
obtenerHistorial:
descripcion: "Historial de odontogramas del paciente"
parametros: [patient_id]
retorna: Odontograma[]
```
### TratamientoPacienteService
```yaml
operaciones:
crear:
descripcion: "Registrar tratamiento realizado"
parametros: [patient_id, tratamiento_id, pieza_id, caras_tratadas, precio]
retorna: TratamientoPaciente
completar:
descripcion: "Marcar tratamiento como completado"
parametros: [tratamiento_id]
retorna: TratamientoPaciente
obtenerPorPaciente:
descripcion: "Listar tratamientos de un paciente"
parametros: [patient_id, estado?]
retorna: TratamientoPaciente[]
obtenerPendientes:
descripcion: "Listar tratamientos pendientes"
parametros: [patient_id]
retorna: TratamientoPaciente[]
```
### PresupuestoService
```yaml
operaciones:
crear:
descripcion: "Crear presupuesto de tratamiento"
parametros: [patient_id, odontologo_id, lineas]
retorna: Presupuesto
aprobar:
descripcion: "Aprobar presupuesto"
parametros: [presupuesto_id]
retorna: Presupuesto
rechazar:
descripcion: "Rechazar presupuesto"
parametros: [presupuesto_id, motivo]
retorna: Presupuesto
generarPDF:
descripcion: "Generar PDF del presupuesto"
parametros: [presupuesto_id]
retorna: Buffer
convertirATratamientos:
descripcion: "Convertir presupuesto aprobado a tratamientos"
parametros: [presupuesto_id]
retorna: TratamientoPaciente[]
```
---
## 6. REFERENCIAS
- Entities: @PROJ_DEF_ENTITIES
- Database: @PROJ_DEF_DB
- Ubicacion futura: `backend/src/modules/*/services/`
- Herencia erp-clinicas: `orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md`
---
*Services Catalog | clinica-dental | v1.0.0*
*Ultima actualizacion: 2026-01-16*

View File

@ -1,135 +0,0 @@
# Indice de Definiciones del Proyecto
# Proyecto: clinica-dental
# Sistema de Gestion para Clinicas Dentales
version: "1.0.0"
proyecto: "clinica-dental"
fecha_creacion: "2026-01-16"
descripcion: "Definiciones canonicas del proyecto Clinica Dental"
# ============================================================================
# REFERENCIAS A WORKSPACE (Definiciones Globales)
# ============================================================================
referencias_workspace:
protocolos:
CCA: "@WS_DEF_CCA"
CAPVED: "@WS_DEF_CAPVED"
validaciones:
backend: "@WS_DEF_VAL_BE"
frontend: "@WS_DEF_VAL_FE"
ddl: "@WS_DEF_VAL_DDL"
devops: "@WS_DEF_VAL_DEVOPS"
# ============================================================================
# DEFINICIONES LOCALES DEL PROYECTO
# ============================================================================
definiciones_locales:
database:
archivo: "DATABASE-SCHEMA.md"
alias: "@PROJ_DEF_DB"
descripcion: "Schema canonico de base de datos dental"
tablas_principales:
- "dental.piezas_dentales"
- "dental.tratamientos_catalogo"
- "dental.odontogramas"
- "dental.odontograma_piezas"
- "dental.tratamientos_paciente"
- "dental.ortodoncia"
- "dental.ortodoncia_citas"
- "dental.protesis"
- "dental.radiografias"
- "dental.presupuestos"
- "dental.presupuesto_lineas"
entities:
archivo: "ENTITIES-CATALOG.md"
alias: "@PROJ_DEF_ENTITIES"
descripcion: "Catalogo de entidades del proyecto"
total_entities: 0 # Pendiente de implementacion
services:
archivo: "SERVICES-CATALOG.md"
alias: "@PROJ_DEF_SERVICES"
descripcion: "Catalogo de servicios del proyecto"
total_services: 0 # Pendiente de implementacion
modules:
archivo: "MODULES-CATALOG.md"
alias: "@PROJ_DEF_MODULES"
descripcion: "Catalogo de modulos del proyecto"
total_modules: 6
# ============================================================================
# HERENCIA (Nivel 3: erp-core -> erp-clinicas -> clinica-dental)
# ============================================================================
herencia:
padre: "erp-clinicas"
nivel: 3
cadena_herencia:
- { proyecto: "erp-core", nivel: 1, tipo: "core" }
- { proyecto: "erp-clinicas", nivel: 2, tipo: "vertical" }
- { proyecto: "clinica-dental", nivel: 3, tipo: "sub-vertical" }
definiciones_heredadas:
- "@WS_DEF_CCA"
- "@WS_DEF_VAL_BE"
- "@WS_DEF_VAL_FE"
- "@WS_DEF_VAL_DDL"
modulos_heredados_erp_core:
fase_1_3_base:
- { id: "MGN-001", nombre: "Authentication", herencia: "100%" }
- { id: "MGN-002", nombre: "Users", herencia: "100%" }
- { id: "MGN-003", nombre: "Roles", herencia: "100%" }
- { id: "MGN-004", nombre: "Tenants", herencia: "extendido" }
- { id: "MGN-005", nombre: "Catalogs", herencia: "extendido" }
- { id: "MGN-007", nombre: "Audit", herencia: "100%" }
- { id: "MGN-008", nombre: "Notifications", herencia: "100%" }
- { id: "MGN-009", nombre: "Reports", herencia: "extendido" }
- { id: "MGN-010", nombre: "Financial", herencia: "extendido" }
fase_4_saas:
- { id: "MGN-016", nombre: "Billing", herencia: "100%" }
- { id: "MGN-017", nombre: "Plans", herencia: "100%" }
- { id: "MGN-018", nombre: "Webhooks", herencia: "100%" }
- { id: "MGN-019", nombre: "Feature Flags", herencia: "100%" }
fase_5_ia:
- { id: "MGN-020", nombre: "AI Integration", herencia: "100%" }
- { id: "MGN-021", nombre: "WhatsApp Business", herencia: "100%" }
- { id: "MGN-022", nombre: "MCP Server", herencia: "100%" }
modulos_heredados_erp_clinicas:
- { id: "CL-001", nombre: "Fundamentos", herencia: "100%" }
- { id: "CL-002", nombre: "Pacientes", herencia: "extendido" }
- { id: "CL-003", nombre: "Citas", herencia: "extendido" }
- { id: "CL-004", nombre: "Consultas", herencia: "extendido" }
- { id: "CL-005", nombre: "Recetas", herencia: "100%" }
- { id: "CL-006", nombre: "Laboratorio", herencia: "parcial" }
- { id: "CL-008", nombre: "Facturacion", herencia: "100%" }
- { id: "CL-009", nombre: "Reportes", herencia: "extendido" }
- { id: "CL-011", nombre: "Expediente", herencia: "extendido" }
- { id: "CL-012", nombre: "Imagenologia", herencia: "extendido" }
# ============================================================================
# CONSIDERACIONES ODONTOLOGICAS
# ============================================================================
odontologia:
nomenclatura:
sistema: "FDI (Federacion Dental Internacional)"
cuadrantes_permanentes: [1, 2, 3, 4]
cuadrantes_temporales: [5, 6, 7, 8]
total_piezas_permanentes: 32
total_piezas_temporales: 20
regulaciones:
- { nombre: "NOM-013-SSA2-2015", estado: "planificado", descripcion: "Prevencion enfermedades bucales" }
- { nombre: "NOM-004-SSA3-2012", estado: "planificado", descripcion: "Expediente clinico" }
- { nombre: "COFEPRIS", estado: "planificado", descripcion: "Regulacion sanitaria" }
- { nombre: "LFPDPPP", estado: "planificado", descripcion: "Proteccion datos personales" }
# ============================================================================
# ESTADISTICAS
# ============================================================================
estadisticas:
total_definiciones: 4
total_referencias_ws: 6
total_modulos_heredados_core: 16
total_modulos_heredados_clinicas: 10
total_modulos_propios: 6
ultima_actualizacion: "2026-01-16"

View File

@ -1,157 +0,0 @@
# Navegacion Rapida de API
# Proyecto: clinica-dental
version: "1.0.0"
proyecto: "clinica-dental"
fecha_creacion: "2026-01-16"
estado: "planificado"
# ============================================================================
# ENDPOINTS PLANIFICADOS POR MODULO
# ============================================================================
por_modulo:
odontograma:
base: "/api/v1/dental/odontogramas"
estado: "planificado"
endpoints:
- { method: "POST", path: "/", descripcion: "Crear odontograma" }
- { method: "GET", path: "/paciente/:patientId", descripcion: "Obtener odontograma activo" }
- { method: "GET", path: "/paciente/:patientId/historial", descripcion: "Historial de odontogramas" }
- { method: "PATCH", path: "/:id/pieza", descripcion: "Actualizar estado de pieza" }
- { method: "GET", path: "/:id", descripcion: "Obtener odontograma por ID" }
tratamientos:
base: "/api/v1/dental/tratamientos"
estado: "planificado"
endpoints:
- { method: "GET", path: "/catalogo", descripcion: "Listar catalogo de tratamientos" }
- { method: "POST", path: "/catalogo", descripcion: "Crear tratamiento en catalogo" }
- { method: "POST", path: "/", descripcion: "Registrar tratamiento a paciente" }
- { method: "GET", path: "/paciente/:patientId", descripcion: "Tratamientos de paciente" }
- { method: "PATCH", path: "/:id/completar", descripcion: "Marcar como completado" }
- { method: "GET", path: "/pendientes", descripcion: "Tratamientos pendientes" }
ortodoncia:
base: "/api/v1/dental/ortodoncia"
estado: "planificado"
endpoints:
- { method: "POST", path: "/", descripcion: "Crear caso de ortodoncia" }
- { method: "GET", path: "/paciente/:patientId", descripcion: "Casos de ortodoncia del paciente" }
- { method: "GET", path: "/:id", descripcion: "Detalle de caso" }
- { method: "POST", path: "/:id/citas", descripcion: "Registrar cita de seguimiento" }
- { method: "GET", path: "/:id/citas", descripcion: "Historial de citas" }
- { method: "PATCH", path: "/:id/completar", descripcion: "Finalizar tratamiento" }
protesis:
base: "/api/v1/dental/protesis"
estado: "planificado"
endpoints:
- { method: "POST", path: "/", descripcion: "Crear trabajo protesico" }
- { method: "GET", path: "/paciente/:patientId", descripcion: "Protesis del paciente" }
- { method: "GET", path: "/:id", descripcion: "Detalle de protesis" }
- { method: "PATCH", path: "/:id/laboratorio", descripcion: "Actualizar estado laboratorio" }
- { method: "PATCH", path: "/:id/colocar", descripcion: "Registrar colocacion" }
radiografias:
base: "/api/v1/dental/radiografias"
estado: "planificado"
endpoints:
- { method: "POST", path: "/", descripcion: "Subir radiografia" }
- { method: "GET", path: "/paciente/:patientId", descripcion: "Radiografias del paciente" }
- { method: "GET", path: "/:id", descripcion: "Detalle de radiografia" }
- { method: "PATCH", path: "/:id/interpretacion", descripcion: "Agregar interpretacion" }
presupuestos:
base: "/api/v1/dental/presupuestos"
estado: "planificado"
endpoints:
- { method: "POST", path: "/", descripcion: "Crear presupuesto" }
- { method: "GET", path: "/paciente/:patientId", descripcion: "Presupuestos del paciente" }
- { method: "GET", path: "/:id", descripcion: "Detalle de presupuesto" }
- { method: "PATCH", path: "/:id/aprobar", descripcion: "Aprobar presupuesto" }
- { method: "PATCH", path: "/:id/rechazar", descripcion: "Rechazar presupuesto" }
- { method: "GET", path: "/:id/pdf", descripcion: "Generar PDF" }
- { method: "POST", path: "/:id/convertir", descripcion: "Convertir a tratamientos" }
# ============================================================================
# ENDPOINTS HEREDADOS
# ============================================================================
heredados:
erp_clinicas:
pacientes:
base: "/api/v1/patients"
heredado_de: "erp-clinicas"
citas:
base: "/api/v1/appointments"
heredado_de: "erp-clinicas"
consultas:
base: "/api/v1/consultations"
heredado_de: "erp-clinicas"
erp_core:
auth:
base: "/api/v1/auth"
heredado_de: "erp-core"
users:
base: "/api/v1/users"
heredado_de: "erp-core"
tenants:
base: "/api/v1/tenants"
heredado_de: "erp-core"
# ============================================================================
# ENDPOINTS POR METODO (Planificados)
# ============================================================================
por_metodo:
GET:
- "/api/v1/dental/odontogramas/paciente/:patientId"
- "/api/v1/dental/tratamientos/catalogo"
- "/api/v1/dental/tratamientos/paciente/:patientId"
- "/api/v1/dental/ortodoncia/paciente/:patientId"
- "/api/v1/dental/protesis/paciente/:patientId"
- "/api/v1/dental/radiografias/paciente/:patientId"
- "/api/v1/dental/presupuestos/paciente/:patientId"
POST:
- "/api/v1/dental/odontogramas"
- "/api/v1/dental/tratamientos"
- "/api/v1/dental/tratamientos/catalogo"
- "/api/v1/dental/ortodoncia"
- "/api/v1/dental/protesis"
- "/api/v1/dental/radiografias"
- "/api/v1/dental/presupuestos"
PATCH:
- "/api/v1/dental/odontogramas/:id/pieza"
- "/api/v1/dental/tratamientos/:id/completar"
- "/api/v1/dental/ortodoncia/:id/completar"
- "/api/v1/dental/presupuestos/:id/aprobar"
# ============================================================================
# AUTENTICACION
# ============================================================================
autenticacion:
tipo: "JWT Bearer"
header: "Authorization"
formato: "Bearer {token}"
endpoints_publicos:
- "/api/v1/auth/login"
- "/api/v1/auth/register"
- "/api/v1/health"
# ============================================================================
# ERRORES COMUNES
# ============================================================================
errores:
400: "Bad Request - Datos invalidos"
401: "Unauthorized - Token invalido o expirado"
403: "Forbidden - Sin permisos"
404: "Not Found - Recurso no encontrado"
422: "Unprocessable Entity - Validacion fallida"
500: "Internal Server Error"
# ============================================================================
# REFERENCIAS
# ============================================================================
referencias:
swagger: "/api/docs"
services: "@PROJ_DEF_SERVICES"
modules: "@PROJ_DEF_MODULES"

View File

@ -1,197 +0,0 @@
# Navegacion Rapida de Base de Datos
# Proyecto: clinica-dental
version: "1.0.0"
proyecto: "clinica-dental"
fecha_creacion: "2026-01-16"
# ============================================================================
# SCHEMAS
# ============================================================================
schemas:
dental:
descripcion: "Schema principal de especializacion dental"
tablas_count: 11
tablas_principales:
- piezas_dentales
- tratamientos_catalogo
- odontogramas
- odontograma_piezas
- tratamientos_paciente
- ortodoncia
- ortodoncia_citas
- protesis
- radiografias
- presupuestos
- presupuesto_lineas
clinica:
descripcion: "Schema heredado de erp-clinicas"
desde: "erp-clinicas"
tablas_principales:
- patients
- doctors
- specialties
- appointments
- consultations
auth:
descripcion: "Schema de autenticacion"
desde: "erp-core"
tenants:
descripcion: "Schema de multi-tenancy"
desde: "erp-core"
# ============================================================================
# TABLAS PRINCIPALES (Top 10)
# ============================================================================
tablas_principales:
- nombre: "odontogramas"
schema: "dental"
descripcion: "Odontogramas de pacientes"
modulo: "DENTAL-001"
relaciones: ["odontograma_piezas", "tratamientos_paciente"]
- nombre: "odontograma_piezas"
schema: "dental"
descripcion: "Estado de cada pieza en el odontograma"
modulo: "DENTAL-001"
relaciones: ["odontogramas", "piezas_dentales"]
- nombre: "piezas_dentales"
schema: "dental"
descripcion: "Catalogo de piezas dentales (FDI)"
tipo: "catalogo_global"
registros: 52
- nombre: "tratamientos_catalogo"
schema: "dental"
descripcion: "Catalogo de tratamientos por tenant"
modulo: "DENTAL-002"
tipo: "catalogo_tenant"
- nombre: "tratamientos_paciente"
schema: "dental"
descripcion: "Tratamientos realizados a pacientes"
modulo: "DENTAL-002"
relaciones: ["tratamientos_catalogo", "odontogramas", "piezas_dentales"]
- nombre: "ortodoncia"
schema: "dental"
descripcion: "Casos de ortodoncia"
modulo: "DENTAL-003"
relaciones: ["ortodoncia_citas"]
- nombre: "protesis"
schema: "dental"
descripcion: "Trabajos protesicos"
modulo: "DENTAL-004"
- nombre: "radiografias"
schema: "dental"
descripcion: "Radiografias dentales"
modulo: "DENTAL-005"
relaciones: ["piezas_dentales"]
- nombre: "presupuestos"
schema: "dental"
descripcion: "Presupuestos de tratamiento"
modulo: "DENTAL-006"
relaciones: ["presupuesto_lineas"]
- nombre: "presupuesto_lineas"
schema: "dental"
descripcion: "Lineas de presupuesto"
modulo: "DENTAL-006"
relaciones: ["presupuestos", "tratamientos_catalogo", "piezas_dentales"]
# ============================================================================
# BUSQUEDA RAPIDA
# ============================================================================
busqueda:
por_modulo:
DENTAL-001: ["odontogramas", "odontograma_piezas", "piezas_dentales"]
DENTAL-002: ["tratamientos_catalogo", "tratamientos_paciente"]
DENTAL-003: ["ortodoncia", "ortodoncia_citas"]
DENTAL-004: ["protesis"]
DENTAL-005: ["radiografias"]
DENTAL-006: ["presupuestos", "presupuesto_lineas"]
por_tipo:
catalogo_global:
- piezas_dentales
catalogo_tenant:
- tratamientos_catalogo
transaccional:
- odontogramas
- odontograma_piezas
- tratamientos_paciente
- ortodoncia
- ortodoncia_citas
- protesis
- radiografias
- presupuestos
- presupuesto_lineas
# ============================================================================
# ENUMS
# ============================================================================
enums:
estado_pieza:
schema: "dental"
valores: ["sano", "caries", "obturacion", "endodoncia", "corona", "puente", "implante", "ausente", "extraccion_indicada", "diente_temporal", "fractura", "movilidad"]
cara_dental:
schema: "dental"
valores: ["mesial", "distal", "oclusal", "incisal", "vestibular", "bucal", "lingual", "palatino"]
estado_tratamiento:
schema: "dental"
valores: ["pendiente", "en_proceso", "completado", "cancelado"]
tipo_ortodoncia:
schema: "dental"
valores: ["brackets_metalicos", "brackets_esteticos", "brackets_linguales", "alineadores", "removible", "retenedor"]
# ============================================================================
# ARCHIVOS DDL
# ============================================================================
ddl:
ubicacion: "database/schemas/"
archivos:
- archivo: "01-dental-schema-ddl.sql"
descripcion: "Schema dental completo"
fecha: "2026-01-04"
# ============================================================================
# SEEDS
# ============================================================================
seeds:
ubicacion: "database/seeds/fase8/"
archivos:
- archivo: "01-dental-catalogos.sql"
descripcion: "Seeds de catalogos dentales"
# ============================================================================
# RLS (Row Level Security)
# ============================================================================
rls:
habilitado: true
patron: "tenant_id = current_setting('app.current_tenant_id', true)::UUID"
tablas_con_rls:
- tratamientos_catalogo
- odontogramas
- odontograma_piezas
- tratamientos_paciente
- ortodoncia
- ortodoncia_citas
- protesis
- radiografias
- presupuestos
- presupuesto_lineas
# ============================================================================
# REFERENCIAS
# ============================================================================
referencias:
schema_completo: "@PROJ_DEF_DB"
entities: "@PROJ_DEF_ENTITIES"
inventario: "orchestration/inventarios/DATABASE_INVENTORY.yml"

View File

@ -1,162 +0,0 @@
# Indice de Navegacion Rapida
# Proyecto: clinica-dental
# Sistema de Gestion para Clinicas Dentales
version: "1.0.0"
proyecto: "clinica-dental"
fecha_creacion: "2026-01-16"
descripcion: "Navegacion rapida del proyecto Clinica Dental"
# ============================================================================
# PUNTO DE ENTRADA RAPIDO
# ============================================================================
inicio_rapido:
descripcion: "Accesos directos a recursos principales"
documentacion:
principal: "docs/README.md"
mapa: "docs/_MAP.md"
vision: "docs/00-vision-general/"
definiciones:
indice: "docs/_definitions/_INDEX.yml"
database: "docs/_definitions/DATABASE-SCHEMA.md"
entities: "docs/_definitions/ENTITIES-CATALOG.md"
services: "docs/_definitions/SERVICES-CATALOG.md"
modules: "docs/_definitions/MODULES-CATALOG.md"
orchestration:
indice: "orchestration/_MAP.md"
inventarios: "orchestration/inventarios/"
trazas: "orchestration/trazas/"
referencias: "orchestration/_refs/WS-REFERENCES.yml"
codigo:
database_schemas: "database/schemas/"
database_seeds: "database/seeds/"
# ============================================================================
# INDICES RAPIDOS
# ============================================================================
indices_rapidos:
modulos: "QUICK-MODULES.yml"
database: "QUICK-DATABASE.yml"
api: "QUICK-API.yml"
# ============================================================================
# MODULOS DENTALES - ACCESO DIRECTO
# ============================================================================
modulos_dentales:
odontograma:
id: "DENTAL-001"
docs: "docs/01-epicas/DENTAL-001-odontograma.md"
tablas: ["dental.odontogramas", "dental.odontograma_piezas"]
estado: "planificado"
tratamientos:
id: "DENTAL-002"
docs: "docs/01-epicas/DENTAL-002-tratamientos.md"
tablas: ["dental.tratamientos_catalogo", "dental.tratamientos_paciente"]
estado: "planificado"
ortodoncia:
id: "DENTAL-003"
docs: "docs/01-epicas/DENTAL-003-ortodoncia.md"
tablas: ["dental.ortodoncia", "dental.ortodoncia_citas"]
estado: "planificado"
protesis:
id: "DENTAL-004"
docs: "docs/01-epicas/DENTAL-004-protesis.md"
tablas: ["dental.protesis"]
estado: "planificado"
radiografias:
id: "DENTAL-005"
docs: "docs/01-epicas/DENTAL-005-radiografias.md"
tablas: ["dental.radiografias"]
estado: "planificado"
presupuestos:
id: "DENTAL-006"
docs: "docs/01-epicas/DENTAL-006-presupuestos.md"
tablas: ["dental.presupuestos", "dental.presupuesto_lineas"]
estado: "planificado"
# ============================================================================
# FASES HEREDADAS
# ============================================================================
fases_heredadas:
saas:
descripcion: "Fase 4 - Capacidades SaaS"
mapa: "docs/04-fase-saas/_MAP.md"
modulos:
- { id: "MGN-016", nombre: "Billing", ruta: "docs/04-fase-saas/MGN-016-billing/" }
- { id: "MGN-017", nombre: "Plans", ruta: "docs/04-fase-saas/MGN-017-plans/" }
- { id: "MGN-018", nombre: "Webhooks", ruta: "docs/04-fase-saas/MGN-018-webhooks/" }
- { id: "MGN-019", nombre: "Feature Flags", ruta: "docs/04-fase-saas/MGN-019-feature-flags/" }
ia:
descripcion: "Fase 5 - Inteligencia Artificial"
mapa: "docs/05-fase-ia/_MAP.md"
modulos:
- { id: "MGN-020", nombre: "AI Integration", ruta: "docs/05-fase-ia/MGN-020-ai-integration/" }
- { id: "MGN-021", nombre: "WhatsApp Business", ruta: "docs/05-fase-ia/MGN-021-whatsapp-business/" }
- { id: "MGN-022", nombre: "MCP Server", ruta: "docs/05-fase-ia/MGN-022-mcp-server/" }
# ============================================================================
# ATAJOS POR ROL
# ============================================================================
por_rol:
backend_developer:
- "docs/_definitions/ENTITIES-CATALOG.md"
- "docs/_definitions/SERVICES-CATALOG.md"
- "docs/_definitions/DATABASE-SCHEMA.md"
- "database/schemas/"
frontend_developer:
- "docs/_quick/QUICK-API.yml"
- "docs/_definitions/MODULES-CATALOG.md"
database_admin:
- "docs/_definitions/DATABASE-SCHEMA.md"
- "docs/_quick/QUICK-DATABASE.yml"
- "database/schemas/01-dental-schema-ddl.sql"
- "orchestration/inventarios/DATABASE_INVENTORY.yml"
architect:
- "docs/00-vision-general/"
- "docs/_definitions/MODULES-CATALOG.md"
- "orchestration/DEPENDENCY-GRAPH.yml"
odontologo:
- "docs/01-epicas/DENTAL-001-odontograma.md"
- "docs/01-epicas/DENTAL-002-tratamientos.md"
- "docs/01-epicas/DENTAL-006-presupuestos.md"
auxiliar_dental:
- "docs/01-epicas/DENTAL-003-ortodoncia.md"
- "docs/01-epicas/DENTAL-005-radiografias.md"
recepcionista:
- "docs/04-fase-saas/MGN-017-plans/"
- "docs/05-fase-ia/MGN-021-whatsapp-business/"
administrador_clinica:
- "docs/01-epicas/DENTAL-006-presupuestos.md"
- "docs/04-fase-saas/MGN-016-billing/"
# ============================================================================
# HERENCIA Y PADRES
# ============================================================================
herencia:
padre: "erp-clinicas"
nivel: 3
cadena:
- { proyecto: "erp-core", nivel: 1 }
- { proyecto: "erp-clinicas", nivel: 2 }
- { proyecto: "clinica-dental", nivel: 3 }
referencias_padre: "orchestration/_refs/WS-REFERENCES.yml"
# ============================================================================
# REFERENCIAS A WORKSPACE
# ============================================================================
workspace:
quick_index: "@WS_QUICK_INDEX"
definitions: "@WS_DEF_*"
catalog: "shared/catalog/"
templates: "shared/templates/"

View File

@ -1,122 +0,0 @@
# Navegacion Rapida de Modulos
# Proyecto: clinica-dental
version: "1.0.0"
proyecto: "clinica-dental"
fecha_creacion: "2026-01-16"
# ============================================================================
# MODULOS POR ESTADO
# ============================================================================
por_estado:
produccion: []
desarrollo: []
planificado:
- id: "DENTAL-001"
nombre: "Odontograma"
ruta: "docs/01-epicas/DENTAL-001-odontograma.md"
- id: "DENTAL-002"
nombre: "Tratamientos"
ruta: "docs/01-epicas/DENTAL-002-tratamientos.md"
- id: "DENTAL-003"
nombre: "Ortodoncia"
ruta: "docs/01-epicas/DENTAL-003-ortodoncia.md"
- id: "DENTAL-004"
nombre: "Protesis"
ruta: "docs/01-epicas/DENTAL-004-protesis.md"
- id: "DENTAL-005"
nombre: "Radiografias"
ruta: "docs/01-epicas/DENTAL-005-radiografias.md"
- id: "DENTAL-006"
nombre: "Presupuestos"
ruta: "docs/01-epicas/DENTAL-006-presupuestos.md"
# ============================================================================
# MODULOS POR CATEGORIA
# ============================================================================
por_categoria:
clinico_dental:
descripcion: "Modulos especificos de odontologia"
modulos:
- { id: "DENTAL-001", nombre: "Odontograma", estado: "planificado" }
- { id: "DENTAL-002", nombre: "Tratamientos", estado: "planificado" }
- { id: "DENTAL-005", nombre: "Radiografias", estado: "planificado" }
especialidades:
descripcion: "Especialidades odontologicas"
modulos:
- { id: "DENTAL-003", nombre: "Ortodoncia", estado: "planificado" }
- { id: "DENTAL-004", nombre: "Protesis", estado: "planificado" }
administrativo:
descripcion: "Gestion administrativa dental"
modulos:
- { id: "DENTAL-006", nombre: "Presupuestos", estado: "planificado" }
heredados_clinicas:
descripcion: "Modulos heredados de erp-clinicas"
modulos:
- { id: "CL-001", nombre: "Fundamentos", herencia: "100%" }
- { id: "CL-002", nombre: "Pacientes", herencia: "extendido" }
- { id: "CL-003", nombre: "Citas", herencia: "extendido" }
- { id: "CL-004", nombre: "Consultas", herencia: "extendido" }
- { id: "CL-005", nombre: "Recetas", herencia: "100%" }
- { id: "CL-008", nombre: "Facturacion", herencia: "100%" }
- { id: "CL-009", nombre: "Reportes", herencia: "extendido" }
- { id: "CL-011", nombre: "Expediente", herencia: "extendido" }
- { id: "CL-012", nombre: "Imagenologia", herencia: "extendido" }
heredados_saas:
descripcion: "Capacidades SaaS heredadas"
modulos:
- { id: "MGN-016", nombre: "Billing", herencia: "100%" }
- { id: "MGN-017", nombre: "Plans", herencia: "100%" }
- { id: "MGN-018", nombre: "Webhooks", herencia: "100%" }
- { id: "MGN-019", nombre: "Feature Flags", herencia: "100%" }
heredados_ia:
descripcion: "Capacidades IA heredadas"
modulos:
- { id: "MGN-020", nombre: "AI Integration", herencia: "100%" }
- { id: "MGN-021", nombre: "WhatsApp Business", herencia: "100%" }
- { id: "MGN-022", nombre: "MCP Server", herencia: "100%" }
# ============================================================================
# BUSQUEDA RAPIDA
# ============================================================================
busqueda:
por_prefijo:
DENTAL: "Modulo dental especializado"
CL: "Modulo clinico (heredado de erp-clinicas)"
MGN: "Modulo generico (heredado de erp-core)"
por_archivo:
epica: "DENTAL-*.md"
especificacion: "ET-*.md"
requerimiento: "RF-*.md"
historia: "US-*.md"
# ============================================================================
# STORY POINTS
# ============================================================================
story_points:
por_modulo:
DENTAL-001: { backend: 21, frontend: 21, total: 42 }
DENTAL-002: { backend: 21, frontend: 13, total: 34 }
DENTAL-003: { backend: 21, frontend: 21, total: 42 }
DENTAL-004: { backend: 13, frontend: 13, total: 26 }
DENTAL-005: { backend: 13, frontend: 13, total: 26 }
DENTAL-006: { backend: 21, frontend: 13, total: 34 }
totales:
backend: 110
frontend: 94
total: 204
# ============================================================================
# REFERENCIAS
# ============================================================================
referencias:
catalogo_completo: "@PROJ_DEF_MODULES"
indice_general: "docs/_MAP.md"

View File

@ -105,31 +105,12 @@ psql -f erp-clinicas/database/seeds/fase8/*.sql
psql -f clinica-dental/database/seeds/fase8/*.sql
```
## 6. Herencia Indirecta de ERP-CORE
Este proyecto también hereda funcionalidades de `erp-core` a través de `erp-clinicas`:
### 6.1 Módulos Fase 04 - SaaS (Propagados 2026-01-13)
- MGN-016: Billing (Facturación SaaS)
- MGN-017: Plans (Planes de suscripción)
- MGN-018: Webhooks (Eventos webhook)
- MGN-019: Feature Flags (Toggles de funcionalidad)
### 6.2 Módulos Fase 05 - IA (Propagados 2026-01-13)
- MGN-020: AI Integration (Integración LLMs)
- MGN-021: WhatsApp Business (Mensajería)
- MGN-022: MCP Server (Servidor MCP)
Ver: `HERENCIA-ERP-CORE.md` para detalles completos.
## 7. Versionado
## 6. Versionado
| Versión | Fecha | Cambios |
|---------|-------|---------|
| 1.0 | 2026-01-04 | Creación inicial, herencia de erp-clinicas FASE-8 |
| 1.1 | 2026-01-13 | Agregada herencia indirecta erp-core Fases 04-05 |
---
**Última actualización:** 2026-01-13
**Propagación:** PROP-CORE-002
**Última actualización:** 2026-01-04

View File

@ -1,138 +0,0 @@
# Herencia ERP-CORE (Indirecta via ERP-Clínicas) - Clínica Dental
## Información de Herencia
| Campo | Valor |
|-------|-------|
| **Proyecto:** | clinica-dental |
| **Hereda de (directo):** | erp-clinicas |
| **Hereda de (indirecto):** | erp-core |
| **Cadena completa:** | template-saas -> erp-core -> erp-clinicas -> clinica-dental |
| **Fecha actualización:** | 2026-01-13 |
| **Versión ERP-Core:** | 1.3.0 |
---
## 1. Cadena de Herencia
```
template-saas (PROVIDER - v1.2.1)
│ DEPENDS_ON
erp-core (INTERMEDIATE - v1.3.0)
│ EXTENDS
erp-clinicas (VERTICAL - v1.0.0)
│ SPECIALIZES
clinica-dental (SUB-VERTICAL - v1.0.0) ← ESTE PROYECTO
```
## 2. Módulos Heredados de ERP-CORE (via erp-clinicas)
### 2.1 Fase 03 - Core ERP (17 módulos base)
| Código | Módulo | Descripción | Hereda |
|--------|--------|-------------|--------|
| MGN-001 | Auth | Autenticación JWT | ✅ |
| MGN-002 | Users | Gestión de usuarios | ✅ |
| MGN-003 | Roles | RBAC | ✅ |
| MGN-004 | Tenants | Multi-tenancy | ✅ |
| MGN-005 | Branches | Sucursales | ✅ |
| MGN-006 | Geo | Geolocalización | ✅ |
| MGN-007 | Mobile | APIs móviles | ✅ |
| MGN-008 | Terminals | Terminales de pago | ✅ |
| MGN-009 | Biometrics | Biométricos | ⚠️ Parcial |
| MGN-010 | Catalog | Catálogos | ✅ |
| MGN-011 | Products | Productos | ✅ |
| MGN-012 | Inventory | Inventario | ✅ |
| MGN-013 | Customers | Clientes/Pacientes | ✅ |
| MGN-014 | Sales | Ventas | ✅ |
| MGN-015 | Invoicing | Facturación | ✅ |
### 2.2 Fase 04 - SaaS (4 módulos) - Propagados 2026-01-13
| Código | Módulo | Descripción | Hereda | Adaptación Dental |
|--------|--------|-------------|--------|-------------------|
| MGN-016 | Billing | Facturación SaaS | ✅ | Planes para clínicas |
| MGN-017 | Plans | Planes de suscripción | ✅ | Básico/Pro/Enterprise |
| MGN-018 | Webhooks | Eventos webhook | ✅ | Notificaciones de citas |
| MGN-019 | Feature Flags | Toggles de funcionalidad | ✅ | Módulos opcionales |
### 2.3 Fase 05 - IA (3 módulos) - Propagados 2026-01-13
| Código | Módulo | Descripción | Hereda | Adaptación Dental |
|--------|--------|-------------|--------|-------------------|
| MGN-020 | AI Integration | Integración LLMs | ✅ | Asistente diagnóstico |
| MGN-021 | WhatsApp Business | Mensajería WhatsApp | ✅ | Recordatorio de citas |
| MGN-022 | MCP Server | Servidor MCP | ✅ | Tools odontológicos |
## 3. Adaptaciones Específicas Dental
### 3.1 Terminología
| ERP-Core/Clínicas | Dental |
|-------------------|--------|
| Paciente | Paciente odontológico |
| Consulta | Consulta dental |
| Tratamiento | Tratamiento dental |
| Prescripción | Receta dental |
### 3.2 Módulos Específicos Dentales
| Código | Módulo | Descripción |
|--------|--------|-------------|
| DENTAL-001 | Odontograma | Estado dental del paciente |
| DENTAL-002 | Tratamientos | Catálogo de tratamientos dentales |
| DENTAL-003 | Ortodoncia | Seguimiento ortodóntico |
| DENTAL-004 | Prótesis | Registro de prótesis |
| DENTAL-005 | Radiografías | Radiografías dentales |
| DENTAL-006 | Presupuestos | Presupuestos de tratamiento |
### 3.3 Adaptaciones IA para Dental
| Funcionalidad IA | Uso Dental |
|------------------|------------|
| AI Integration | Análisis de radiografías, sugerencias de diagnóstico |
| WhatsApp Business | Recordatorios de citas, seguimiento post-tratamiento |
| MCP Server | Tools: crear_cita_dental, consultar_odontograma, presupuesto_tratamiento |
## 4. Normativa Aplicable
| Normativa | Descripción |
|-----------|-------------|
| NOM-013-SSA2-2015 | Prevención y control enfermedades bucales |
| NOM-004-SSA3-2012 | Expediente clínico |
| NOM-024-SSA3-2012 | Sistemas de información |
| LFPDPPP | Protección de datos personales |
| COFEPRIS | Registro de establecimientos |
## 5. Propagación
### 5.1 Estado de Propagación
| Tipo | Estado | Fecha |
|------|--------|-------|
| Documentación | ✅ Propagado | 2026-01-13 |
| Definiciones | ✅ Propagado | 2026-01-13 |
| Código | ⏳ Pendiente | - |
### 5.2 Referencia de Propagación
- ID: `PROP-CORE-002`
- Tipo: `bulk_propagation`
- Cadena: `erp-core -> erp-clinicas -> clinica-dental`
## 6. Archivos Relacionados
- `HERENCIA-ERP-CLINICAS.md` - Herencia directa de erp-clinicas
- `../referencias/DEPENDENCIAS-ERP-CORE.yml` - Dependencias técnicas
- `docs/04-modelado/especificaciones-tecnicas-core/README.md` - Specs técnicas
---
**Última actualización:** 2026-01-13
**Propagación ID:** PROP-CORE-002

View File

@ -1,191 +0,0 @@
# Herencia SIMCO - clinica-dental
**Sistema:** SIMCO v4.0.0 + CAPVED + SCRUM
**Fecha:** 2026-01-10
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | Clinica Dental - Sistema para Clinicas Dentales |
| **Código v2** | CDN |
| **SIMCO Version** | 4.0.0 |
| **CAPVED** | Habilitado |
| **SCRUM** | Habilitado |
---
## Metodología CAPVED+SCRUM
Este proyecto utiliza la metodología integrada CAPVED+SCRUM definida en SIMCO v4.0.0.
### Ciclo CAPVED dentro de Sprint
```
Sprint Start
├── Sprint Planning (usar @TPL_SPRINT_PLANNING)
└── Por cada HU:
├── [C] Contexto → Cargar directivas, verificar DoR
├── [A] Análisis → Analizar requerimientos
├── [P] Plan → Planificar implementación
├── [V] Validación → Validar plan técnico
├── [E] Ejecución → Implementar código
└── [D] Documentar → Actualizar docs, verificar DoD
├── Sprint Review
└── Sprint Retrospective (usar @TPL_RETROSPECTIVA)
```
---
## Directivas SCRUM (SIMCO v4.0.0)
### Ejecución de Sprint
| Alias | Directiva | Propósito |
|-------|-----------|-----------|
| `@SPRINT_EXECUTION` | `SIMCO-SPRINT-EXECUTION.md` | Ciclo completo de Sprint |
| `@AGILE_METRICS` | `SIMCO-AGILE-METRICS.md` | Métricas Velocity, Burndown |
| `@SCRUM_INTEGRATION` | `SIMCO-SCRUM-INTEGRATION.md` | Integración CAPVED+SCRUM |
### Definition of Ready (DoR)
| Criterio | Descripción |
|----------|-------------|
| ID asignado | `CDN-US-NNN` |
| Historia completa | Como/Quiero/Para |
| Criterios de aceptación | 3-8 criterios |
| Story Points | Fibonacci (1,2,3,5,8,13) |
| Dependencias identificadas | Sin bloqueos |
| PO aprobado | ✓ |
### Definition of Done (DoD)
| Criterio | Descripción |
|----------|-------------|
| Código implementado | Según especificación |
| Build pasa | Sin errores |
| Tests pasando | Unitarios + integración |
| Code review | Completado |
| Documentación | Actualizada |
| TRACEABILITY.yml | Actualizado |
### Templates SCRUM
| Alias | Template | Uso |
|-------|----------|-----|
| `@TPL_DEFINICION_READY` | `TEMPLATE-DEFINICION-READY.md` | Validar DoR de HU |
| `@TPL_SPRINT_BACKLOG` | `TEMPLATE-SPRINT-BACKLOG.yml` | Tracking de Sprint |
| `@TPL_RETROSPECTIVA` | `TEMPLATE-RETROSPECTIVA.yml` | Retro Start-Stop-Continue |
| `@TPL_SPRINT_PLANNING` | `TEMPLATE-ACTA-SPRINT-PLANNING.md` | Acta de Planning |
### Checklist DoD/DoR
| Alias | Checklist | Items |
|-------|-----------|-------|
| `@CHK_DOD_DOR` | `CHECKLIST-DOD-DOR.md` | 32 items |
---
## Directivas CAPVED (Heredadas)
### Ciclo de Vida
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@TAREA` | `SIMCO-TAREA.md` | Punto de entrada |
| `@CAPVED` | `PRINCIPIO-CAPVED.md` | Ciclo de 6 fases |
| `@INICIALIZACION` | `SIMCO-INICIALIZACION.md` | Bootstrap de agentes |
### Operaciones
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@CREAR` | `SIMCO-CREAR.md` | Crear archivos |
| `@MODIFICAR` | `SIMCO-MODIFICAR.md` | Modificar archivos |
| `@VALIDAR` | `SIMCO-VALIDAR.md` | Validar código |
| `@DOCUMENTAR` | `SIMCO-DOCUMENTAR.md` | Documentar trabajo |
| `@BUSCAR` | `SIMCO-BUSCAR.md` | Buscar información |
---
## Directivas de Documentación
| Alias | Directiva | Propósito |
|-------|-----------|-----------|
| `@DOC_PROYECTO` | `SIMCO-DOCUMENTACION-PROYECTO.md` | Estructura docs/ |
| `@NOMENCLATURA` | `SIMCO-NOMENCLATURA.md` | Convenciones de IDs |
| `@ESTRUCTURA_DOCS` | `SIMCO-ESTRUCTURA-DOCS.md` | Estructura interna |
| `@INVENTARIOS` | `SIMCO-INVENTARIOS.md` | Inventarios YAML |
| `@MANTENIMIENTO_DOCS` | `SIMCO-MANTENIMIENTO-DOCUMENTACION.md` | Ciclo mantenimiento |
| `@SYNC_BD` | `SIMCO-SINCRONIZACION-BD.md` | Sincronización BD↔Docs |
---
## Trazabilidad v2
### TRACEABILITY-MASTER.yml
Ubicación: `docs/04-modelado/trazabilidad/TRACEABILITY-MASTER.yml`
Este archivo consolida:
- Mapeo de nomenclatura v1 → v2
- Lista de épicas con estados
- Grafo de dependencias
- Health score del proyecto
### Nomenclatura v2
| Tipo | Formato | Ejemplo |
|------|---------|---------|
| Épica | `CDN-EP-NNN` | CDN-EP-001 |
| Requerimiento | `CDN-RF-NNN` | CDN-RF-001 |
| User Story | `CDN-US-NNN` | CDN-US-001 |
| Tarea | `CDN-TT-NNN` | CDN-TT-001 |
| Bug | `CDN-BG-NNN` | CDN-BG-001 |
---
## Flujo de Trabajo Sprint
```yaml
# Sprint Planning
1. Cargar: @SPRINT_EXECUTION
2. Seleccionar HUs del backlog
3. Validar DoR con @CHK_DOD_DOR
4. Estimar con Planning Poker
5. Crear Sprint Backlog con @TPL_SPRINT_BACKLOG
# Durante Sprint (por HU)
1. Cargar: @TAREA + @CAPVED
2. Ejecutar ciclo CAPVED
3. Validar DoD con @CHK_DOD_DOR
4. Actualizar TRACEABILITY.yml
# Sprint Review
1. Demo de funcionalidades
2. Actualizar @AGILE_METRICS
# Sprint Retrospective
1. Usar @TPL_RETROSPECTIVA
2. Registrar Start-Stop-Continue
3. Crear action items
```
---
## Referencias
- Directivas SIMCO: `workspace-v2/orchestration/directivas/simco/`
- Templates SCRUM: `workspace-v2/orchestration/templates/scrum/`
- Checklists: `workspace-v2/orchestration/checklists/`
- TRACEABILITY-MASTER: `docs/04-modelado/trazabilidad/TRACEABILITY-MASTER.yml`
---
**Sistema:** SIMCO v4.0.0 + CAPVED + SCRUM
**Última actualización:** 2026-01-10

View File

@ -1,185 +0,0 @@
# BOOTLOADER - Clinica Dental
**Sistema:** NEXUS v4.0 - Protocolo de Arranque Local
**Proyecto:** Clinica Dental
**Tipo:** SUB-CONSUMER (Especializa erp-clinicas)
**Version:** 1.0.0
**Fecha:** 2026-01-24
---
## 1. Proposito
Este BOOTLOADER define la secuencia de arranque para Clinica Dental.
Sub-vertical especializada en odontologia que hereda de erp-clinicas.
---
## 2. Cadena de Herencia
```
workspace-v2 (L0)
template-saas (PROVIDER)
erp-core (INTERMEDIATE)
erp-clinicas (CONSUMER)
clinica-dental (SUB-CONSUMER) ◄── ESTE PROYECTO
```
---
## 3. Secuencia de Arranque (5 Pasos)
```
┌─────────────────────────────────────────────────────────────────────────┐
│ BOOTLOADER CLINICA-DENTAL - 5 PASOS │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ PASO 1: Cargar L0 (Sistema - Workspace) │
│ ════════════════════════════════════════ │
│ ├── Leer workspace-v2/CLAUDE.md │
│ └── Tokens: ~4000 │
│ │ │
│ ▼ │
│ PASO 2: Cargar L1 (Proyecto) │
│ ════════════════════════════════════════ │
│ ├── Leer orchestration/CONTEXT-MAP.yml │
│ ├── Leer orchestration/_inheritance.yml (SUB-CONSUMER) │
│ └── Tokens: ~2000 │
│ │ │
│ ▼ │
│ PASO 3: Verificar Bloqueos de Herencia │
│ ════════════════════════════════════════ │
│ ├── VERIFICAR: erp-clinicas >= 50% │
│ ├── Si NO: Solo documentacion permitida │
│ └── Si SI: Desarrollo habilitado │
│ │ │
│ ▼ │
│ PASO 4: Determinar Dominio │
│ ════════════════════════════════════════ │
│ ├── ¿Modulo odontograma? │
│ ├── ¿Modulo tratamientos-dentales? │
│ ├── ¿Modulo ortodoncia? │
│ ├── ¿Modulo protesis? │
│ ├── ¿Modulo radiografias-dentales? │
│ └── ¿Modulo presupuestos-dentales? │
│ │ │
│ ▼ │
│ PASO 5: Iniciar Tarea │
│ ════════════════════════════════════════ │
│ ├── git fetch origin && git status │
│ └── Ejecutar FASE C de CAPVED │
│ │
└─────────────────────────────────────────────────────────────────────────┘
```
---
## 4. Rol SUB-CONSUMER (Especializa)
Clinica Dental especializa erp-clinicas para odontologia:
```yaml
herencia:
parent: erp-clinicas
tipo: SPECIALIZES
especializacion: odontologia
cadena: "template-saas -> erp-core -> erp-clinicas -> clinica-dental"
modulos_heredados:
de_template_saas: [auth, tenants, billing, notifications]
de_erp_core: [catalogs, inventory]
de_erp_clinicas: [pacientes, citas, expedientes, prescripciones]
modulos_propios:
- odontograma # Odontograma digital (30%)
- tratamientos-dentales # Catalogo tratamientos (25%)
- ortodoncia # Brackets y ortodoncia (20%)
- protesis # Protesis dentales (15%)
- radiografias-dentales # Rx panoramicas (20%)
- presupuestos-dentales # Presupuestos (25%)
```
---
## 5. Bloqueos Activos
```yaml
bloqueo_activo:
regla: "BLOCK-002"
descripcion: "No puede avanzar si erp-clinicas < 50%"
estado_actual: "erp-clinicas al 10%"
acciones_permitidas:
- Documentacion de requerimientos
- Definicion de tablas DDL (sub_dental.*)
- Planeacion de modulos
acciones_bloqueadas:
- Implementacion de codigo
- Testing
- Integracion con erp-clinicas
```
---
## 6. Variables Pre-Resueltas
```yaml
PROJECT_ROOT: projects/clinica-dental
PARENT_PROJECT: projects/erp-clinicas
SCHEMA_PREFIX: sub_dental
COMPLETITUD: ~25%
BLOQUEADO: true (hasta erp-clinicas >= 50%)
```
---
## 7. Normativa Aplicable
```yaml
normativa:
- nombre: "NOM-013-SSA2-2015"
descripcion: "Prevencion y control de enfermedades bucales"
aplica_a: ["odontograma", "tratamientos-dentales"]
- nombre: "NOM-004-SSA3-2012"
descripcion: "Del expediente clinico"
aplica_a: ["expedientes"]
- nombre: "COFEPRIS"
descripcion: "Regulacion de consultorios dentales"
aplica_a: ["todos"]
```
---
## 8. Checklist de Arranque
- [ ] PASO 1: workspace-v2/CLAUDE.md leido
- [ ] PASO 2: CONTEXT-MAP.yml cargado
- [ ] PASO 2: _inheritance.yml verificado
- [ ] PASO 3: Estado de erp-clinicas verificado
- [ ] PASO 3: Bloqueo confirmado si aplica
- [ ] PASO 4: Dominio identificado
- [ ] PASO 5: Tarea iniciada (solo si permitido)
---
## 9. Referencias
- **BOOTLOADER Global:** `workspace-v2/orchestration/directivas/simco/SIMCO-BOOTLOADER.md`
- **Parent (erp-clinicas):** `../erp-clinicas/orchestration/BOOTLOADER.md`
- **CONTEXT-MAP:** `orchestration/CONTEXT-MAP.yml`
---
*BOOTLOADER Clinica Dental v1.0.0 - Sistema NEXUS v4.0*
*Tipo: SUB-CONSUMER - Especializa erp-clinicas (odontologia)*

View File

@ -9,9 +9,9 @@ metadata:
nivel: "VERTICAL"
version: "1.0.0"
ultima_actualizacion: "2026-01-07"
workspace_root: "/home/isem/workspace-v2"
project_root: "/home/isem/workspace-v2/projects/clinica-dental"
hereda_de: "/home/isem/workspace-v2/projects/erp-clinicas"
workspace_root: "/home/isem/workspace-v1"
project_root: "/home/isem/workspace-v1/projects/clinica-dental"
hereda_de: "/home/isem/workspace-v1/projects/erp-clinicas"
# ===============================================================================
# VARIABLES DEL PROYECTO (PRE-RESUELTAS)
@ -26,23 +26,23 @@ variables:
# Base de datos
DB_NAME: "clinica_dental"
DB_DDL_PATH: "/home/isem/workspace-v2/projects/clinica-dental/database/schemas"
DB_SCRIPTS_PATH: "/home/isem/workspace-v2/projects/clinica-dental/database"
DB_SEEDS_PATH: "/home/isem/workspace-v2/projects/clinica-dental/database/seeds"
DB_DDL_PATH: "/home/isem/workspace-v1/projects/clinica-dental/database/schemas"
DB_SCRIPTS_PATH: "/home/isem/workspace-v1/projects/clinica-dental/database"
DB_SEEDS_PATH: "/home/isem/workspace-v1/projects/clinica-dental/database/seeds"
RECREATE_CMD: "drop-and-recreate-database.sh"
# Backend
BACKEND_ROOT: "/home/isem/workspace-v2/projects/clinica-dental/backend"
BACKEND_SRC: "/home/isem/workspace-v2/projects/clinica-dental/backend/src"
BACKEND_TESTS: "/home/isem/workspace-v2/projects/clinica-dental/backend/tests"
BACKEND_ROOT: "/home/isem/workspace-v1/projects/clinica-dental/backend"
BACKEND_SRC: "/home/isem/workspace-v1/projects/clinica-dental/backend/src"
BACKEND_TESTS: "/home/isem/workspace-v1/projects/clinica-dental/backend/tests"
# Frontend
FRONTEND_ROOT: "/home/isem/workspace-v2/projects/clinica-dental/frontend"
FRONTEND_SRC: "/home/isem/workspace-v2/projects/clinica-dental/frontend/src"
FRONTEND_ROOT: "/home/isem/workspace-v1/projects/clinica-dental/frontend"
FRONTEND_SRC: "/home/isem/workspace-v1/projects/clinica-dental/frontend/src"
# Documentacion
DOCS_PATH: "/home/isem/workspace-v2/projects/clinica-dental/docs"
ORCHESTRATION_PATH: "/home/isem/workspace-v2/projects/clinica-dental/orchestration"
DOCS_PATH: "/home/isem/workspace-v1/projects/clinica-dental/docs"
ORCHESTRATION_PATH: "/home/isem/workspace-v1/projects/clinica-dental/orchestration"
# ===============================================================================
# ALIASES RESUELTOS
@ -50,32 +50,32 @@ variables:
aliases:
# Directivas globales
"@SIMCO": "/home/isem/workspace-v2/orchestration/directivas/simco"
"@PRINCIPIOS": "/home/isem/workspace-v2/orchestration/directivas/principios"
"@PERFILES": "/home/isem/workspace-v2/orchestration/agents/perfiles"
"@CATALOG": "/home/isem/workspace-v2/shared/catalog"
"@SIMCO": "/home/isem/workspace-v1/orchestration/directivas/simco"
"@PRINCIPIOS": "/home/isem/workspace-v1/orchestration/directivas/principios"
"@PERFILES": "/home/isem/workspace-v1/orchestration/agents/perfiles"
"@CATALOG": "/home/isem/workspace-v1/shared/catalog"
# Proyecto padre (erp-clinicas)
"@PARENT": "/home/isem/workspace-v2/projects/erp-clinicas"
"@PARENT_CORE": "/home/isem/workspace-v2/projects/erp-core"
"@PARENT": "/home/isem/workspace-v1/projects/erp-clinicas"
"@PARENT_CORE": "/home/isem/workspace-v1/projects/erp-core"
# Proyecto especifico
"@DDL": "/home/isem/workspace-v2/projects/clinica-dental/database/schemas"
"@SEEDS": "/home/isem/workspace-v2/projects/clinica-dental/database/seeds"
"@BACKEND": "/home/isem/workspace-v2/projects/clinica-dental/backend/src"
"@FRONTEND": "/home/isem/workspace-v2/projects/clinica-dental/frontend/src"
"@DOCS": "/home/isem/workspace-v2/projects/clinica-dental/docs"
"@DDL": "/home/isem/workspace-v1/projects/clinica-dental/database/schemas"
"@SEEDS": "/home/isem/workspace-v1/projects/clinica-dental/database/seeds"
"@BACKEND": "/home/isem/workspace-v1/projects/clinica-dental/backend/src"
"@FRONTEND": "/home/isem/workspace-v1/projects/clinica-dental/frontend/src"
"@DOCS": "/home/isem/workspace-v1/projects/clinica-dental/docs"
# Inventarios
"@INVENTORY": "/home/isem/workspace-v2/projects/clinica-dental/orchestration/inventarios"
"@INV_DB": "/home/isem/workspace-v2/projects/clinica-dental/orchestration/inventarios/DATABASE_INVENTORY.yml"
"@INV_BE": "/home/isem/workspace-v2/projects/clinica-dental/orchestration/inventarios/BACKEND_INVENTORY.yml"
"@INV_FE": "/home/isem/workspace-v2/projects/clinica-dental/orchestration/inventarios/FRONTEND_INVENTORY.yml"
"@INVENTORY": "/home/isem/workspace-v1/projects/clinica-dental/orchestration/inventarios"
"@INV_DB": "/home/isem/workspace-v1/projects/clinica-dental/orchestration/inventarios/DATABASE_INVENTORY.yml"
"@INV_BE": "/home/isem/workspace-v1/projects/clinica-dental/orchestration/inventarios/BACKEND_INVENTORY.yml"
"@INV_FE": "/home/isem/workspace-v1/projects/clinica-dental/orchestration/inventarios/FRONTEND_INVENTORY.yml"
# Trazas
"@TRAZA_DB": "/home/isem/workspace-v2/projects/clinica-dental/orchestration/trazas/TRAZA-TAREAS-DATABASE.md"
"@TRAZA_BE": "/home/isem/workspace-v2/projects/clinica-dental/orchestration/trazas/TRAZA-TAREAS-BACKEND.md"
"@TRAZA_FE": "/home/isem/workspace-v2/projects/clinica-dental/orchestration/trazas/TRAZA-TAREAS-FRONTEND.md"
"@TRAZA_DB": "/home/isem/workspace-v1/projects/clinica-dental/orchestration/trazas/TRAZA-TAREAS-DATABASE.md"
"@TRAZA_BE": "/home/isem/workspace-v1/projects/clinica-dental/orchestration/trazas/TRAZA-TAREAS-BACKEND.md"
"@TRAZA_FE": "/home/isem/workspace-v1/projects/clinica-dental/orchestration/trazas/TRAZA-TAREAS-FRONTEND.md"
# ===============================================================================
# CONTEXTO POR NIVEL
@ -87,25 +87,25 @@ contexto_por_nivel:
tokens_estimados: 4500
obligatorio: true
archivos:
- path: "/home/isem/workspace-v2/orchestration/directivas/principios/PRINCIPIO-CAPVED.md"
- path: "/home/isem/workspace-v1/orchestration/directivas/principios/PRINCIPIO-CAPVED.md"
proposito: "Ciclo de vida de tareas"
tokens: 800
- path: "/home/isem/workspace-v2/orchestration/directivas/principios/PRINCIPIO-DOC-PRIMERO.md"
- path: "/home/isem/workspace-v1/orchestration/directivas/principios/PRINCIPIO-DOC-PRIMERO.md"
proposito: "Documentacion antes de codigo"
tokens: 500
- path: "/home/isem/workspace-v2/orchestration/directivas/principios/PRINCIPIO-ANTI-DUPLICACION.md"
- path: "/home/isem/workspace-v1/orchestration/directivas/principios/PRINCIPIO-ANTI-DUPLICACION.md"
proposito: "Verificar catalogo antes de crear"
tokens: 600
- path: "/home/isem/workspace-v2/orchestration/directivas/principios/PRINCIPIO-VALIDACION-OBLIGATORIA.md"
- path: "/home/isem/workspace-v1/orchestration/directivas/principios/PRINCIPIO-VALIDACION-OBLIGATORIA.md"
proposito: "Build/lint deben pasar"
tokens: 600
- path: "/home/isem/workspace-v2/orchestration/directivas/principios/PRINCIPIO-ECONOMIA-TOKENS.md"
- path: "/home/isem/workspace-v1/orchestration/directivas/principios/PRINCIPIO-ECONOMIA-TOKENS.md"
proposito: "Limites de contexto"
tokens: 500
- path: "/home/isem/workspace-v2/orchestration/directivas/principios/PRINCIPIO-NO-ASUMIR.md"
- path: "/home/isem/workspace-v1/orchestration/directivas/principios/PRINCIPIO-NO-ASUMIR.md"
proposito: "Preguntar si falta informacion"
tokens: 500
- path: "/home/isem/workspace-v2/orchestration/referencias/ALIASES.yml"
- path: "/home/isem/workspace-v1/orchestration/referencias/ALIASES.yml"
proposito: "Resolucion de @ALIAS"
tokens: 400
@ -114,13 +114,13 @@ contexto_por_nivel:
tokens_estimados: 3000
obligatorio: true
archivos:
- path: "/home/isem/workspace-v2/projects/clinica-dental/orchestration/00-guidelines/CONTEXTO-PROYECTO.md"
- path: "/home/isem/workspace-v1/projects/clinica-dental/orchestration/00-guidelines/CONTEXTO-PROYECTO.md"
proposito: "Variables y configuracion del proyecto"
tokens: 1500
- path: "/home/isem/workspace-v2/projects/clinica-dental/orchestration/PROXIMA-ACCION.md"
- path: "/home/isem/workspace-v1/projects/clinica-dental/orchestration/PROXIMA-ACCION.md"
proposito: "Estado actual y siguiente paso"
tokens: 500
- path: "/home/isem/workspace-v2/projects/clinica-dental/orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md"
- path: "/home/isem/workspace-v1/projects/clinica-dental/orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md"
proposito: "Herencia de modulos del padre"
tokens: 800
@ -129,23 +129,23 @@ contexto_por_nivel:
tokens_estimados: 2500
archivos_por_operacion:
CREAR:
- "/home/isem/workspace-v2/orchestration/directivas/simco/SIMCO-CREAR.md"
- "/home/isem/workspace-v1/orchestration/directivas/simco/SIMCO-CREAR.md"
MODIFICAR:
- "/home/isem/workspace-v2/orchestration/directivas/simco/SIMCO-MODIFICAR.md"
- "/home/isem/workspace-v1/orchestration/directivas/simco/SIMCO-MODIFICAR.md"
VALIDAR:
- "/home/isem/workspace-v2/orchestration/directivas/simco/SIMCO-VALIDAR.md"
- "/home/isem/workspace-v1/orchestration/directivas/simco/SIMCO-VALIDAR.md"
DELEGAR:
- "/home/isem/workspace-v2/orchestration/directivas/simco/SIMCO-DELEGACION.md"
- "/home/isem/workspace-v1/orchestration/directivas/simco/SIMCO-DELEGACION.md"
archivos_por_dominio:
DDL:
- "/home/isem/workspace-v2/orchestration/directivas/simco/SIMCO-DDL.md"
- "/home/isem/workspace-v2/projects/clinica-dental/orchestration/inventarios/DATABASE_INVENTORY.yml"
- "/home/isem/workspace-v1/orchestration/directivas/simco/SIMCO-DDL.md"
- "/home/isem/workspace-v1/projects/clinica-dental/orchestration/inventarios/DATABASE_INVENTORY.yml"
BACKEND:
- "/home/isem/workspace-v2/orchestration/directivas/simco/SIMCO-BACKEND.md"
- "/home/isem/workspace-v2/projects/clinica-dental/orchestration/inventarios/BACKEND_INVENTORY.yml"
- "/home/isem/workspace-v1/orchestration/directivas/simco/SIMCO-BACKEND.md"
- "/home/isem/workspace-v1/projects/clinica-dental/orchestration/inventarios/BACKEND_INVENTORY.yml"
FRONTEND:
- "/home/isem/workspace-v2/orchestration/directivas/simco/SIMCO-FRONTEND.md"
- "/home/isem/workspace-v2/projects/clinica-dental/orchestration/inventarios/FRONTEND_INVENTORY.yml"
- "/home/isem/workspace-v1/orchestration/directivas/simco/SIMCO-FRONTEND.md"
- "/home/isem/workspace-v1/projects/clinica-dental/orchestration/inventarios/FRONTEND_INVENTORY.yml"
L3_tarea:
descripcion: "Contexto especifico de la tarea"
@ -284,9 +284,9 @@ validacion_tokens:
herencia:
tipo: "VERTICAL"
hereda_de:
- "/home/isem/workspace-v2/projects/erp-clinicas/"
- "/home/isem/workspace-v2/projects/erp-core/"
- "/home/isem/workspace-v2/orchestration/"
- "/home/isem/workspace-v1/projects/erp-clinicas/"
- "/home/isem/workspace-v1/projects/erp-core/"
- "/home/isem/workspace-v1/orchestration/"
# ===============================================================================
# BUSQUEDA DE HISTORICO
@ -295,7 +295,7 @@ herencia:
busqueda_historico:
habilitado: true
ubicaciones:
- "/home/isem/workspace-v2/projects/clinica-dental/orchestration/trazas/"
- "/home/isem/workspace-v2/projects/erp-clinicas/orchestration/trazas/"
- "/home/isem/workspace-v2/orchestration/errores/REGISTRO-ERRORES.yml"
- "/home/isem/workspace-v2/shared/knowledge-base/lessons-learned/"
- "/home/isem/workspace-v1/projects/clinica-dental/orchestration/trazas/"
- "/home/isem/workspace-v1/projects/erp-clinicas/orchestration/trazas/"
- "/home/isem/workspace-v1/orchestration/errores/REGISTRO-ERRORES.yml"
- "/home/isem/workspace-v1/shared/knowledge-base/lessons-learned/"

View File

@ -1,198 +0,0 @@
# Grafo de Dependencias del Proyecto
# Proyecto: clinica-dental
version: "1.0.0"
proyecto: "clinica-dental"
fecha_creacion: "2026-01-16"
# ============================================================================
# DEPENDENCIAS EXTERNAS (NPM, etc.)
# ============================================================================
dependencias_externas:
backend:
framework: "NestJS"
version: "^10.0.0"
principales:
- nombre: "@nestjs/core"
version: "^10.0.0"
uso: "Framework core"
- nombre: "@nestjs/typeorm"
version: "^10.0.0"
uso: "ORM integration"
- nombre: "typeorm"
version: "^0.3.0"
uso: "ORM"
- nombre: "pg"
version: "^8.0.0"
uso: "PostgreSQL driver"
frontend:
framework: "React"
version: "^18.0.0"
principales:
- nombre: "react"
version: "^18.0.0"
- nombre: "react-router-dom"
version: "^6.0.0"
database:
tipo: "PostgreSQL"
version: "15+"
orm: "TypeORM"
# ============================================================================
# DEPENDENCIAS INTERNAS (Entre modulos del proyecto)
# ============================================================================
dependencias_internas:
modulos:
DENTAL-001:
nombre: "Odontograma"
depende_de: ["CL-002"]
dependientes: ["DENTAL-002", "DENTAL-004"]
descripcion: "Depende de Pacientes (CL-002)"
DENTAL-002:
nombre: "Tratamientos"
depende_de: ["DENTAL-001", "CL-002", "CL-004"]
dependientes: ["DENTAL-006"]
descripcion: "Depende de Odontograma, Pacientes, Consultas"
DENTAL-003:
nombre: "Ortodoncia"
depende_de: ["CL-002", "CL-003"]
dependientes: []
descripcion: "Depende de Pacientes y Citas"
DENTAL-004:
nombre: "Protesis"
depende_de: ["CL-002", "DENTAL-001"]
dependientes: []
descripcion: "Depende de Pacientes y Odontograma"
DENTAL-005:
nombre: "Radiografias"
depende_de: ["CL-002", "CL-004", "CL-012"]
dependientes: []
descripcion: "Depende de Pacientes, Consultas, Imagenologia"
DENTAL-006:
nombre: "Presupuestos"
depende_de: ["CL-002", "DENTAL-002"]
dependientes: []
descripcion: "Depende de Pacientes y Tratamientos"
# ============================================================================
# DEPENDENCIAS DE WORKSPACE
# ============================================================================
dependencias_workspace:
definiciones:
- "@WS_DEF_CCA"
- "@WS_DEF_VAL_BE"
- "@WS_DEF_VAL_FE"
- "@WS_DEF_VAL_DDL"
catalogos:
- "shared/catalog/auth/"
- "shared/catalog/notifications/"
# ============================================================================
# DEPENDENCIAS DE OTROS PROYECTOS (Herencia)
# ============================================================================
dependencias_proyectos:
proyectos:
- proyecto: "erp-clinicas"
tipo: "herencia"
nivel: 2
modulos_usados:
- { id: "CL-001", nombre: "Fundamentos", uso: "100%" }
- { id: "CL-002", nombre: "Pacientes", uso: "extendido" }
- { id: "CL-003", nombre: "Citas", uso: "extendido" }
- { id: "CL-004", nombre: "Consultas", uso: "extendido" }
- { id: "CL-005", nombre: "Recetas", uso: "100%" }
- { id: "CL-006", nombre: "Laboratorio", uso: "parcial" }
- { id: "CL-008", nombre: "Facturacion", uso: "100%" }
- { id: "CL-009", nombre: "Reportes", uso: "extendido" }
- { id: "CL-011", nombre: "Expediente", uso: "extendido" }
- { id: "CL-012", nombre: "Imagenologia", uso: "extendido" }
- proyecto: "erp-core"
tipo: "herencia indirecta"
nivel: 1
modulos_usados:
core:
- { id: "MGN-001", nombre: "Authentication" }
- { id: "MGN-002", nombre: "Users" }
- { id: "MGN-003", nombre: "Roles" }
- { id: "MGN-004", nombre: "Tenants" }
- { id: "MGN-005", nombre: "Catalogs" }
- { id: "MGN-007", nombre: "Audit" }
- { id: "MGN-008", nombre: "Notifications" }
- { id: "MGN-009", nombre: "Reports" }
- { id: "MGN-010", nombre: "Financial" }
saas:
- { id: "MGN-016", nombre: "Billing" }
- { id: "MGN-017", nombre: "Plans" }
- { id: "MGN-018", nombre: "Webhooks" }
- { id: "MGN-019", nombre: "Feature Flags" }
ia:
- { id: "MGN-020", nombre: "AI Integration" }
- { id: "MGN-021", nombre: "WhatsApp Business" }
- { id: "MGN-022", nombre: "MCP Server" }
# ============================================================================
# GRAFO VISUAL
# ============================================================================
grafo:
formato: "mermaid"
diagrama: |
graph TD
subgraph "Nivel 1: erp-core"
CORE[MGN-001..022<br/>Core + SaaS + IA]
end
subgraph "Nivel 2: erp-clinicas"
CL002[CL-002<br/>Pacientes]
CL003[CL-003<br/>Citas]
CL004[CL-004<br/>Consultas]
CL012[CL-012<br/>Imagenologia]
end
subgraph "Nivel 3: clinica-dental"
D001[DENTAL-001<br/>Odontograma]
D002[DENTAL-002<br/>Tratamientos]
D003[DENTAL-003<br/>Ortodoncia]
D004[DENTAL-004<br/>Protesis]
D005[DENTAL-005<br/>Radiografias]
D006[DENTAL-006<br/>Presupuestos]
end
CORE --> CL002
CORE --> CL003
CORE --> CL004
CORE --> CL012
CL002 --> D001
D001 --> D002
CL004 --> D002
D002 --> D006
CL002 --> D003
CL003 --> D003
D001 --> D004
CL002 --> D004
CL002 --> D005
CL004 --> D005
CL012 --> D005
# ============================================================================
# ESTADISTICAS
# ============================================================================
estadisticas:
total_dependencias_externas: 6
total_dependencias_internas: 12
total_dependencias_workspace: 6
total_modulos_heredados: 26
total_modulos_propios: 6
ultima_actualizacion: "2026-01-16"

View File

@ -1,356 +0,0 @@
# ===============================================================================
# MAPA DE DOCUMENTACION - CLINICA DENTAL
# ===============================================================================
#
# Proposito: Centro de referencias a toda la documentacion del proyecto
# Alias: @DENTAL_MAPA_DOC
# Tipo: SUB-VERTICAL (hereda de erp-clinicas)
#
# ===============================================================================
version: "1.0.0"
created: "2026-01-16"
updated: "2026-01-16"
proyecto: "clinica-dental"
tipo: "SUB-VERTICAL"
nivel: 3
# -------------------------------------------------------------------------------
# CADENA DE HERENCIA COMPLETA
# -------------------------------------------------------------------------------
cadena_herencia:
origen:
proyecto: "template-saas"
tipo: "PROVIDER"
nivel: 0
alias: "@TS_MAPA_DOC"
ubicacion: "projects/template-saas/orchestration/MAPA-DOCUMENTACION.yml"
abuelo:
proyecto: "erp-core"
tipo: "INTERMEDIATE"
nivel: 1
alias: "@ERP_MAPA_DOC"
ubicacion: "projects/erp-core/orchestration/MAPA-DOCUMENTACION.yml"
padre:
proyecto: "erp-clinicas"
tipo: "CONSUMER"
nivel: 2
alias: "@CLINICAS_MAPA_DOC"
ubicacion: "projects/erp-clinicas/orchestration/MAPA-DOCUMENTACION.yml"
actual:
proyecto: "clinica-dental"
tipo: "SUB-VERTICAL"
nivel: 3
alias: "@DENTAL_MAPA_DOC"
especializacion: "Odontologia"
# -------------------------------------------------------------------------------
# DOCUMENTACION DE USUARIO (docs/)
# -------------------------------------------------------------------------------
docs:
raiz:
README.md:
alias: "@DENTAL_README"
descripcion: "Punto de entrada del proyecto"
_MAP.md:
alias: "@DENTAL_MAP"
descripcion: "Mapa maestro de navegacion"
vision:
ruta: "docs/00-vision-general/"
alias: "@DENTAL_VISION"
archivos:
- VISION-CLINICA-DENTAL.md
- ARQUITECTURA-ODONTOLOGICA.md
modulos:
ruta: "docs/01-modulos/"
alias: "@DENTAL_MODULOS"
patron: "CDT-{NNN}-{nombre}.md"
archivos:
- CDT-001-Odontograma.md
- CDT-002-Tratamientos-Dentales.md
- CDT-003-Ortodoncia.md
- CDT-004-Protesis.md
- CDT-005-Radiografias-Dentales.md
- CDT-006-Presupuestos-Dentales.md
normativa:
ruta: "docs/02-normativa/"
alias: "@DENTAL_NORMATIVA"
archivos:
- NOM-013-SSA2-2015-Implementacion.md
- NOM-004-SSA3-2012-Expediente.md
- COFEPRIS-Consultorios.md
definitions:
ruta: "docs/_definitions/"
alias: "@DENTAL_DEF"
archivos:
_INDEX.yml:
alias: "@DENTAL_DEF_INDEX"
DATABASE-SCHEMA.md:
alias: "@DENTAL_DEF_DB"
descripcion: "Schema sub_dental (15+ tablas)"
ENTITIES-CATALOG.md:
alias: "@DENTAL_DEF_ENTITIES"
descripcion: "Catalogo de entities dentales"
SERVICES-CATALOG.md:
alias: "@DENTAL_DEF_SERVICES"
descripcion: "Catalogo de services dentales"
MODULES-CATALOG.md:
alias: "@DENTAL_DEF_MODULES"
descripcion: "Catalogo de 6 modulos CDT"
quick:
ruta: "docs/_quick/"
alias: "@DENTAL_QUICK"
archivos:
QUICK-INDEX.yml:
alias: "@DENTAL_QUICK_INDEX"
QUICK-MODULES.yml:
alias: "@DENTAL_QUICK_MODULES"
QUICK-DATABASE.yml:
alias: "@DENTAL_QUICK_DATABASE"
QUICK-API.yml:
alias: "@DENTAL_QUICK_API"
# -------------------------------------------------------------------------------
# DOCUMENTACION OPERACIONAL (orchestration/)
# -------------------------------------------------------------------------------
orchestration:
raiz:
_MAP.md:
alias: "@DENTAL_ORCH_MAP"
PROJECT-STATUS.md:
alias: "@DENTAL_STATUS"
descripcion: "Estado actual del proyecto"
PROXIMA-ACCION.md:
alias: "@DENTAL_NEXT"
descripcion: "Siguiente tarea a ejecutar"
trazabilidad:
TRACEABILITY.yml:
alias: "@DENTAL_TRACEABILITY"
descripcion: "Trazabilidad de 6 modulos CDT"
DEPENDENCY-GRAPH.yml:
alias: "@DENTAL_DEP_GRAPH"
descripcion: "Grafo de dependencias"
CONTEXT-MAP.yml:
alias: "@DENTAL_CONTEXT"
descripcion: "Mapeo de contexto"
_inheritance.yml:
alias: "@DENTAL_INHERITANCE"
descripcion: "Herencia: SUB-VERTICAL nivel 3"
MAPA-DOCUMENTACION.yml:
alias: "@DENTAL_MAPA_DOC"
descripcion: "Este archivo"
inventarios:
ruta: "orchestration/inventarios/"
alias: "@DENTAL_INV"
archivos:
MASTER_INVENTORY.yml:
alias: "@DENTAL_INV_MASTER"
DATABASE_INVENTORY.yml:
alias: "@DENTAL_INV_DB"
BACKEND_INVENTORY.yml:
alias: "@DENTAL_INV_BE"
FRONTEND_INVENTORY.yml:
alias: "@DENTAL_INV_FE"
directivas:
ruta: "orchestration/directivas/"
alias: "@DENTAL_DIRECTIVAS"
hereda_de: "@CLINICAS_DIRECTIVAS"
archivos:
- TRIGGER-COHERENCIA-CAPAS.md
- TRIGGER-INVENTARIOS.md
agentes:
ruta: "orchestration/agents/"
alias: "@DENTAL_AGENTS"
archivos:
perfiles:
_INDEX.yml:
alias: "@DENTAL_AGENTS_INDEX"
PERFIL-ODONTOLOGO-AGENT.yml:
alias: "@DENTAL_AGENT_ODONTOLOGO"
PERFIL-DDL-DENTAL-AGENT.yml:
alias: "@DENTAL_AGENT_DDL"
trazas:
ruta: "orchestration/agents/trazas/"
referencias:
ruta: "orchestration/referencias/"
alias: "@DENTAL_REFS"
environment:
ruta: "orchestration/environment/"
alias: "@DENTAL_ENV"
# -------------------------------------------------------------------------------
# REFERENCIAS AL WORKSPACE Y CADENA
# -------------------------------------------------------------------------------
referencias_cadena:
template_saas:
mapa: "@TS_MAPA_DOC"
ubicacion: "projects/template-saas/orchestration/MAPA-DOCUMENTACION.yml"
hereda:
- "Directivas base"
- "Estructura de inventarios"
- "Perfiles de agentes base"
erp_core:
mapa: "@ERP_MAPA_DOC"
ubicacion: "projects/erp-core/orchestration/MAPA-DOCUMENTACION.yml"
hereda:
- "23 modulos MGN"
- "Triggers de coherencia"
- "Modelo multi-tenant"
erp_clinicas:
mapa: "@CLINICAS_MAPA_DOC"
ubicacion: "projects/erp-clinicas/orchestration/MAPA-DOCUMENTACION.yml"
hereda:
- "Modulos de pacientes, citas, expedientes"
- "Directivas clinicas"
- "Normativa salud base"
workspace:
archivo: "orchestration/_refs/WS-REFERENCES.yml"
alias: "@DENTAL_WS_REFS"
contenido:
- "@WS_DIRECTIVAS"
- "@WS_PERFILES"
- "@WS_TEMPLATES"
- "@WS_DEFINITIONS"
# -------------------------------------------------------------------------------
# MODULOS CDT (CLINICA DENTAL)
# -------------------------------------------------------------------------------
modulos_cdt:
CDT-001:
nombre: "Odontograma"
estado: "30%"
alias: "@DENTAL_MOD_ODONTOGRAMA"
normativa: "NOM-013-SSA2-2015"
CDT-002:
nombre: "Tratamientos Dentales"
estado: "25%"
alias: "@DENTAL_MOD_TRATAMIENTOS"
normativa: "NOM-013-SSA2-2015"
CDT-003:
nombre: "Ortodoncia"
estado: "20%"
alias: "@DENTAL_MOD_ORTODONCIA"
CDT-004:
nombre: "Protesis"
estado: "15%"
alias: "@DENTAL_MOD_PROTESIS"
CDT-005:
nombre: "Radiografias Dentales"
estado: "20%"
alias: "@DENTAL_MOD_RADIOGRAFIAS"
CDT-006:
nombre: "Presupuestos Dentales"
estado: "25%"
alias: "@DENTAL_MOD_PRESUPUESTOS"
# -------------------------------------------------------------------------------
# NORMATIVA APLICABLE
# -------------------------------------------------------------------------------
normativa:
obligatoria:
- codigo: "NOM-013-SSA2-2015"
nombre: "Prevencion y control de enfermedades bucales"
aplica_a: ["CDT-001", "CDT-002"]
alias: "@DENTAL_NOM_013"
- codigo: "NOM-004-SSA3-2012"
nombre: "Del expediente clinico"
aplica_a: ["expedientes", "consentimientos"]
alias: "@DENTAL_NOM_004"
- codigo: "COFEPRIS"
nombre: "Regulacion de consultorios dentales"
aplica_a: ["todos"]
alias: "@DENTAL_COFEPRIS"
complementaria:
- codigo: "NOM-087-SEMARNAT-SSA1-2002"
nombre: "Residuos peligrosos biologico-infecciosos"
aplica_a: ["inventario-materiales"]
# -------------------------------------------------------------------------------
# ESTADISTICAS
# -------------------------------------------------------------------------------
estadisticas:
docs:
total_archivos: TBD
carpetas: 8
modulos_documentados: 6
orchestration:
total_archivos: 15
inventarios: 4
trazas: 1
perfiles_agentes: 2
triggers: 2
total_aliases: 50+
cobertura_documentacion: "80%"
ultima_auditoria: "2026-01-16"
# -------------------------------------------------------------------------------
# NAVEGACION RAPIDA POR ROL
# -------------------------------------------------------------------------------
por_rol:
odontologo:
inicio: "@DENTAL_NORMATIVA"
modulos: "@DENTAL_MODULOS"
odontograma: "@DENTAL_MOD_ODONTOGRAMA"
desarrollador_backend:
inicio: "@DENTAL_DEF_ENTITIES"
api: "@DENTAL_QUICK_API"
inventario: "@DENTAL_INV_BE"
desarrollador_frontend:
inicio: "@DENTAL_QUICK_MODULES"
api: "@DENTAL_QUICK_API"
inventario: "@DENTAL_INV_FE"
dba:
inicio: "@DENTAL_DEF_DB"
inventario: "@DENTAL_INV_DB"
quick: "@DENTAL_QUICK_DATABASE"
arquitecto:
inicio: "@DENTAL_VISION"
dependencias: "@DENTAL_DEP_GRAPH"
herencia: "@DENTAL_INHERITANCE"
cadena: "Ver seccion cadena_herencia"
orquestador:
inicio: "@DENTAL_STATUS"
siguiente: "@DENTAL_NEXT"
trazabilidad: "@DENTAL_TRACEABILITY"
# ===============================================================================
# FIN DEL MAPA DE DOCUMENTACION
# ===============================================================================

View File

@ -1,368 +0,0 @@
# PROJECT-PROFILE.yml - clinica-dental
# Perfil de proyecto para el Agente de Propagación Automático
# Version: 1.0.0
# Fecha: 2026-01-18
project:
name: "clinica-dental"
code: "DEN"
type: "SUB-VERTICAL"
level: "SUB-CONSUMER"
giro: "odontologia"
version: "1.0.0"
completeness: 15
description: |
ERP sub-vertical para clínicas y consultorios dentales:
- Odontología general
- Ortodoncia
- Endodoncia
- Periodoncia
- Cirugía maxilofacial
- Estética dental
Hereda de erp-clinicas y especializa para odontología.
# =============================================================================
# JERARQUÍA DE HERENCIA
# =============================================================================
inheritance:
parent: "erp-clinicas"
grandparent: "erp-core"
chain: ["erp-core", "erp-clinicas", "clinica-dental"]
# =============================================================================
# ESTRUCTURA DEL PROYECTO
# =============================================================================
structure:
type: "monorepo"
root_path: "projects/clinica-dental"
apps:
backend:
path: "apps/backend"
framework: "NestJS"
modules_path: "src/modules"
entities_path: "src/modules/*/entities"
frontend:
path: "apps/frontend"
framework: "React"
features_path: "src/features"
pages_path: "src/pages"
database:
path: "apps/database"
ddl_path: "ddl"
# =============================================================================
# MAPEO DE MÓDULOS: clinicas → dental
# =============================================================================
module_mapping:
# Heredados de erp-clinicas (se mantienen)
auth: "auth"
users: "users"
roles: "roles"
tenants: "tenants"
catalogs: "catalogs"
patients: "dental-patients" # Pacientes → Pacientes dentales
medical-supplies: "dental-supplies"
financial: "financial"
appointments: "dental-appointments"
purchases: "purchases"
patient-relations: "patient-relations"
audit: "audit"
notifications: "notifications"
clinical-reports: "dental-reports"
# De erp-clinicas que se especializan
medical-records: "dental-records"
scheduling: "dental-scheduling"
prescriptions: "dental-prescriptions"
insurance: "dental-insurance"
lab-integration: "dental-lab" # Integración con laboratorios dentales
# =============================================================================
# ADAPTACIONES ESPECÍFICAS DE ODONTOLOGÍA
# =============================================================================
adaptations:
entities:
# Desde erp-clinicas
Patient: "DentalPatient"
MedicalSupply: "DentalSupply"
Appointment: "DentalAppointment"
MedicalRecord: "DentalRecord"
fields_additions:
DentalPatient:
- name: "odontogram"
type: "jsonb"
nullable: true
reason: "Odontograma completo del paciente"
- name: "dental_history"
type: "jsonb"
nullable: true
reason: "Historial dental específico"
- name: "orthodontic_treatment"
type: "boolean"
default: false
reason: "Si está en tratamiento de ortodoncia"
- name: "last_cleaning_date"
type: "date"
nullable: true
reason: "Última limpieza dental"
- name: "periodontal_status"
type: "varchar(50)"
enum: ["healthy", "gingivitis", "mild_periodontitis", "moderate_periodontitis", "severe_periodontitis"]
nullable: true
reason: "Estado periodontal"
- name: "bruxism"
type: "boolean"
default: false
reason: "Si presenta bruxismo"
DentalSupply:
- name: "dental_category"
type: "varchar(50)"
enum: ["restorative", "endodontic", "orthodontic", "surgical", "preventive", "prosthetic", "anesthetic", "instrument"]
reason: "Categoría de insumo dental"
- name: "tooth_application"
type: "jsonb"
nullable: true
reason: "Dientes donde se puede aplicar"
- name: "shade_guide"
type: "varchar(20)"
nullable: true
reason: "Guía de color (para restauraciones)"
DentalAppointment:
- name: "treatment_type"
type: "varchar(50)"
enum: ["cleaning", "filling", "extraction", "root_canal", "crown", "implant", "orthodontic", "whitening", "veneer", "emergency"]
reason: "Tipo de tratamiento dental"
- name: "teeth_involved"
type: "jsonb"
nullable: true
reason: "Dientes involucrados (notación FDI)"
- name: "quadrant"
type: "varchar(20)"
enum: ["upper_right", "upper_left", "lower_right", "lower_left", "full_mouth"]
nullable: true
reason: "Cuadrante a tratar"
- name: "anesthesia_required"
type: "boolean"
default: false
reason: "Si requiere anestesia"
- name: "anesthesia_type"
type: "varchar(50)"
nullable: true
reason: "Tipo de anestesia"
- name: "x_rays_required"
type: "boolean"
default: false
reason: "Si requiere radiografías"
DentalRecord:
- name: "odontogram_history"
type: "jsonb"
nullable: true
reason: "Historial de cambios en odontograma"
- name: "treatment_plan"
type: "jsonb"
nullable: true
reason: "Plan de tratamiento completo"
- name: "x_ray_images"
type: "jsonb"
nullable: true
reason: "Referencias a imágenes de rayos X"
- name: "intraoral_photos"
type: "jsonb"
nullable: true
reason: "Fotos intraorales"
fields_removals:
DentalPatient:
- "blood_type" # Menos crítico en odontología general
# =============================================================================
# MÓDULOS ESPECÍFICOS DE ODONTOLOGÍA
# =============================================================================
vertical_modules:
- id: "DEN-001"
name: "odontogram"
description: "Gestión de odontograma digital"
status: "planned"
priority: "P0"
entities:
- Odontogram
- ToothStatus
- ToothHistory
- id: "DEN-002"
name: "treatment-plans"
description: "Planes de tratamiento dental"
status: "planned"
priority: "P0"
entities:
- TreatmentPlan
- TreatmentPhase
- TreatmentProcedure
- id: "DEN-003"
name: "orthodontics"
description: "Módulo de ortodoncia"
status: "planned"
priority: "P1"
entities:
- OrthodonticCase
- BracketPlacement
- WireChange
- OrthoProgress
- id: "DEN-004"
name: "dental-imaging"
description: "Imagenología dental"
status: "planned"
priority: "P1"
entities:
- DentalImage
- Panoramic
- Periapical
- Bitewing
- id: "DEN-005"
name: "dental-lab-orders"
description: "Pedidos a laboratorio dental"
status: "planned"
priority: "P1"
entities:
- LabOrder
- LabWork
- ShadeSelection
# =============================================================================
# TERMINOLOGÍA ODONTOLÓGICA
# =============================================================================
terminology:
# Heredado de clínicas
paciente: "paciente dental"
cita: "cita dental"
consulta: "consulta dental"
# Específico de odontología
tratamiento: "tratamiento dental"
limpieza: "profilaxis"
empaste: "restauración"
extraccion: "extracción/exodoncia"
endodoncia: "tratamiento de conductos"
corona: "corona dental"
implante: "implante dental"
ortodoncia: "ortodoncia"
blanqueamiento: "blanqueamiento dental"
carilla: "carilla/veneer"
radiografia: "radiografía dental"
odontograma: "odontograma"
# =============================================================================
# NOTACIÓN DENTAL
# =============================================================================
dental_notation:
system: "FDI" # Federación Dental Internacional (ISO 3950)
quadrants:
1: "Superior derecho (11-18)"
2: "Superior izquierdo (21-28)"
3: "Inferior izquierdo (31-38)"
4: "Inferior derecho (41-48)"
tooth_surfaces:
- code: "M"
name: "Mesial"
- code: "D"
name: "Distal"
- code: "V"
name: "Vestibular/Bucal"
- code: "L"
name: "Lingual/Palatino"
- code: "O"
name: "Oclusal/Incisal"
# =============================================================================
# REGLAS DE PROPAGACIÓN
# =============================================================================
propagation_rules:
accept_from:
- erp-clinicas # Padre directo
- erp-core # Si erp-clinicas lo propaga
auto_accept:
- documentation
- definitions
- security_fixes
- bug_fixes
- patient_base_changes
require_adaptation:
- entities
- ddl_schema
- medical_records # Adaptar a registros dentales
require_review:
- breaking_changes
- schema_migrations
- hipaa_related
reject:
- veterinary_features
- general_surgery_features
# =============================================================================
# VALIDACIONES ESPECÍFICAS
# =============================================================================
validations:
pre_propagation:
- "Verificar que módulo padre (erp-clinicas) está actualizado"
- "Validar que entity mapping está definido"
post_propagation:
- "npm run build"
- "npm run lint"
- "npm run test:affected"
business_rules:
- "Odontograma usa notación FDI"
- "Tratamientos de ortodoncia requieren plan aprobado"
- "Radiografías requieren consentimiento del paciente"
- "Anestesia registra tipo y cantidad"
- "Laboratorio dental requiere guía de color"
# =============================================================================
# HISTORIAL
# =============================================================================
history:
- date: "2026-01-18"
action: "Creación de PROJECT-PROFILE.yml"
author: "Claude-Opus-4.5"

View File

@ -27,14 +27,14 @@
| Artefacto | Estado | Prioridad |
|-----------|--------|-----------|
| docs/00-vision-general/VISION.md | EXISTE | - |
| docs/00-vision-general/_MAP.md | EXISTE | - |
| docs/00-vision-general/VISION.md | FALTA | P0 |
| docs/00-vision-general/_MAP.md | FALTA | P1 |
| docs/02-definicion-modulos/_MAP.md | FALTA | P0 |
| modulo-odontograma.md | FALTA | P1 |
| modulo-tratamientos.md | FALTA | P1 |
| modulo-ortodoncia.md | FALTA | P2 |
| modulo-protesis.md | FALTA | P2 |
| orchestration/_MAP.md | EXISTE | - |
| orchestration/_MAP.md | FALTA | P1 |
---

View File

@ -1,285 +0,0 @@
# Trazabilidad del Proyecto
# Proyecto: clinica-dental
version: "1.0.0"
proyecto: "clinica-dental"
fecha_creacion: "2026-01-16"
# ============================================================================
# TRAZABILIDAD MODULO <-> OBJETOS
# ============================================================================
trazabilidad_modulos:
DENTAL-001:
nombre: "Odontograma"
documentacion:
especificacion: "docs/01-epicas/DENTAL-001-odontograma.md"
requerimientos: []
historias: []
objetos_bd:
tablas:
- "dental.odontogramas"
- "dental.odontograma_piezas"
- "dental.piezas_dentales"
schemas: ["dental"]
objetos_backend:
entities:
- "Odontograma"
- "OdontogramaPieza"
- "PiezaDental"
services:
- "OdontogramaService"
- "OdontogramaPiezaService"
controllers:
- "OdontogramaController"
objetos_frontend:
componentes: []
stores: []
hooks: []
DENTAL-002:
nombre: "Tratamientos"
documentacion:
especificacion: "docs/01-epicas/DENTAL-002-tratamientos.md"
requerimientos: []
historias: []
objetos_bd:
tablas:
- "dental.tratamientos_catalogo"
- "dental.tratamientos_paciente"
schemas: ["dental"]
objetos_backend:
entities:
- "TratamientoCatalogo"
- "TratamientoPaciente"
services:
- "TratamientoCatalogoService"
- "TratamientoPacienteService"
controllers:
- "TratamientoController"
DENTAL-003:
nombre: "Ortodoncia"
documentacion:
especificacion: "docs/01-epicas/DENTAL-003-ortodoncia.md"
requerimientos: []
historias: []
objetos_bd:
tablas:
- "dental.ortodoncia"
- "dental.ortodoncia_citas"
schemas: ["dental"]
objetos_backend:
entities:
- "Ortodoncia"
- "OrtodonciaCita"
services:
- "OrtodonciaService"
- "OrtodonciaCitaService"
controllers:
- "OrtodonciaController"
DENTAL-004:
nombre: "Protesis"
documentacion:
especificacion: "docs/01-epicas/DENTAL-004-protesis.md"
requerimientos: []
historias: []
objetos_bd:
tablas:
- "dental.protesis"
schemas: ["dental"]
objetos_backend:
entities:
- "Protesis"
services:
- "ProtesisService"
controllers:
- "ProtesisController"
DENTAL-005:
nombre: "Radiografias"
documentacion:
especificacion: "docs/01-epicas/DENTAL-005-radiografias.md"
requerimientos: []
historias: []
objetos_bd:
tablas:
- "dental.radiografias"
schemas: ["dental"]
objetos_backend:
entities:
- "Radiografia"
services:
- "RadiografiaService"
controllers:
- "RadiografiaController"
DENTAL-006:
nombre: "Presupuestos"
documentacion:
especificacion: "docs/01-epicas/DENTAL-006-presupuestos.md"
requerimientos: []
historias: []
objetos_bd:
tablas:
- "dental.presupuestos"
- "dental.presupuesto_lineas"
schemas: ["dental"]
objetos_backend:
entities:
- "Presupuesto"
- "PresupuestoLinea"
services:
- "PresupuestoService"
controllers:
- "PresupuestoController"
# ============================================================================
# MATRIZ DE COBERTURA
# ============================================================================
cobertura:
total_modulos: 6
con_documentacion: 6
con_ddl: 6
con_backend: 0
con_frontend: 0
con_tests: 0
con_trazabilidad_completa: 0
detalle:
DENTAL-001:
documentacion: true
ddl: true
backend: false
frontend: false
tests: false
DENTAL-002:
documentacion: true
ddl: true
backend: false
frontend: false
tests: false
DENTAL-003:
documentacion: true
ddl: true
backend: false
frontend: false
tests: false
DENTAL-004:
documentacion: true
ddl: true
backend: false
frontend: false
tests: false
DENTAL-005:
documentacion: true
ddl: true
backend: false
frontend: false
tests: false
DENTAL-006:
documentacion: true
ddl: true
backend: false
frontend: false
tests: false
# ============================================================================
# REFERENCIAS CRUZADAS
# ============================================================================
referencias_cruzadas:
por_tabla:
"dental.odontogramas":
modulos: ["DENTAL-001"]
entities: ["Odontograma"]
documentos: ["DENTAL-001-odontograma.md"]
"dental.odontograma_piezas":
modulos: ["DENTAL-001"]
entities: ["OdontogramaPieza"]
documentos: ["DENTAL-001-odontograma.md"]
"dental.tratamientos_catalogo":
modulos: ["DENTAL-002"]
entities: ["TratamientoCatalogo"]
documentos: ["DENTAL-002-tratamientos.md"]
"dental.tratamientos_paciente":
modulos: ["DENTAL-002"]
entities: ["TratamientoPaciente"]
documentos: ["DENTAL-002-tratamientos.md"]
"dental.ortodoncia":
modulos: ["DENTAL-003"]
entities: ["Ortodoncia"]
documentos: ["DENTAL-003-ortodoncia.md"]
"dental.protesis":
modulos: ["DENTAL-004"]
entities: ["Protesis"]
documentos: ["DENTAL-004-protesis.md"]
"dental.radiografias":
modulos: ["DENTAL-005"]
entities: ["Radiografia"]
documentos: ["DENTAL-005-radiografias.md"]
"dental.presupuestos":
modulos: ["DENTAL-006"]
entities: ["Presupuesto"]
documentos: ["DENTAL-006-presupuestos.md"]
# ============================================================================
# IMPACTO DE CAMBIOS
# ============================================================================
impacto:
"dental.odontogramas":
tipo: "tabla"
impacta:
entities: ["Odontograma"]
services: ["OdontogramaService"]
modulos: ["DENTAL-001", "DENTAL-002", "DENTAL-004"]
"dental.tratamientos_catalogo":
tipo: "tabla"
impacta:
entities: ["TratamientoCatalogo"]
services: ["TratamientoCatalogoService", "TratamientoPacienteService", "PresupuestoService"]
modulos: ["DENTAL-002", "DENTAL-006"]
"clinica.patients":
tipo: "tabla heredada"
impacta:
modulos: ["DENTAL-001", "DENTAL-002", "DENTAL-003", "DENTAL-004", "DENTAL-005", "DENTAL-006"]
# ============================================================================
# HISTORIAL DE CAMBIOS
# ============================================================================
historial:
- fecha: "2026-01-16"
tipo: "creacion"
descripcion: "Trazabilidad inicial del proyecto"
autor: "Claude"
# ============================================================================
# ESTADISTICAS
# ============================================================================
estadisticas:
modulos_mapeados: 6
tablas_mapeadas: 11
entities_mapeadas: 0
documentos_referenciados: 6
ultima_actualizacion: "2026-01-16"

View File

@ -1,131 +0,0 @@
# MAPA DE ORQUESTACION: clinica-dental
**Proyecto:** clinica-dental
**Nivel:** SUB-CONSUMER (hereda de erp-clinicas)
**Sistema:** NEXUS v4.0 + SIMCO + SAAD
**Estandar:** SIMCO-ESTANDAR-ORCHESTRATION v1.0.0
**Ultima actualizacion:** 2026-01-24
---
## Estructura Estandarizada
```
orchestration/
├── _MAP.md # [OBLIGATORIO] Mapa de navegacion
├── _inheritance.yml # [OBLIGATORIO] Herencia de erp-clinicas
├── BOOTLOADER.md # [OBLIGATORIO] Protocolo de arranque
├── CONTEXT-MAP.yml # [OBLIGATORIO] Mapa de contexto NEXUS
├── PROJECT-PROFILE.yml # [OBLIGATORIO] Perfil del proyecto
├── PROJECT-STATUS.md # [OBLIGATORIO] Estado actual
├── PROXIMA-ACCION.md # [OBLIGATORIO] Checkpoint de sesion
├── DEPENDENCY-GRAPH.yml # [OBLIGATORIO] Grafo de dependencias
├── TRACEABILITY.yml # [OBLIGATORIO] Trazabilidad
├── MAPA-DOCUMENTACION.yml # [OBLIGATORIO] Mapa de documentacion
├── 00-guidelines/ # [OBLIGATORIO] Guias y contexto
│ ├── CONTEXTO-PROYECTO.md
│ ├── HERENCIA-ERP-CLINICAS.md
│ ├── HERENCIA-ERP-CORE.md
│ └── HERENCIA-SIMCO.md
├── inventarios/ # [OBLIGATORIO] Inventarios
│ ├── MASTER_INVENTORY.yml
│ ├── DATABASE_INVENTORY.yml
│ ├── BACKEND_INVENTORY.yml
│ └── FRONTEND_INVENTORY.yml
├── trazas/ # [OBLIGATORIO] Trazas de operaciones
│ ├── REPORTE-EJECUCION-*.md
│ └── TRAZA-TAREAS-DATABASE.md
├── directivas/ # [OPCIONAL] Directivas especificas locales
│ ├── checklists/
│ ├── principios/
│ ├── simco/
│ └── triggers/
└── _archive/ # Carpetas archivadas (no estandar)
├── _definitions/
├── _refs/
├── agents/
├── environment/
├── referencias/
└── tareas/
```
---
## Archivos Obligatorios (10/10)
| Archivo | Proposito | Estado |
|---------|-----------|--------|
| _MAP.md | Mapa de navegacion | OK |
| _inheritance.yml | Herencia de erp-clinicas | OK |
| BOOTLOADER.md | Protocolo de arranque NEXUS | OK |
| CONTEXT-MAP.yml | Configuracion de contexto | OK |
| PROJECT-PROFILE.yml | Perfil y metadata | OK |
| PROJECT-STATUS.md | Estado actual del proyecto | OK |
| PROXIMA-ACCION.md | Checkpoint de sesion | OK |
| DEPENDENCY-GRAPH.yml | Grafo de dependencias | OK |
| TRACEABILITY.yml | Trazabilidad del proyecto | OK |
| MAPA-DOCUMENTACION.yml | Mapa de documentacion | OK |
---
## Carpetas Obligatorias (3/3)
| Carpeta | Contenido Minimo | Estado |
|---------|------------------|--------|
| 00-guidelines/ | CONTEXTO-PROYECTO.md | OK |
| inventarios/ | MASTER_INVENTORY.yml | OK |
| trazas/ | Trazas por capa | OK |
---
## Navegacion
| Destino | Enlace |
|---------|--------|
| Documentacion Proyecto | [../docs/_MAP.md](../docs/_MAP.md) |
| Orchestration Central | [../../orchestration/_MAP.md](../../orchestration/_MAP.md) |
| Directivas SIMCO | [../../orchestration/directivas/simco/](../../orchestration/directivas/simco/) |
| erp-clinicas (padre) | [../erp-clinicas/orchestration/_MAP.md](../erp-clinicas/orchestration/_MAP.md) |
| erp-core (abuelo) | [../erp-core/orchestration/_MAP.md](../erp-core/orchestration/_MAP.md) |
---
## Cadena de Herencia
```
workspace-v2/orchestration/ (LEVEL 0 - Workspace Root)
template-saas/orchestration/ (LEVEL 1A - Provider)
erp-core/orchestration/ (LEVEL 1B - Intermediate)
erp-clinicas/orchestration/ (LEVEL 2 - Consumer)
clinica-dental/orchestration/ (SUB-CONSUMER) ← ESTE
```
---
## Nota sobre _archive/
Las siguientes carpetas fueron movidas a `_archive/` por no ser parte del estandar
SIMCO-ESTANDAR-ORCHESTRATION v1.0.0 para nivel SUB-CONSUMER:
- `_definitions/` - Usar workspace central
- `_refs/` - Usar workspace central
- `agents/` - Hereda de workspace (opcional para CONSUMER)
- `environment/` - Consolidar con inventarios
- `referencias/` - Usar workspace central
- `tareas/` - Hereda de workspace (opcional para CONSUMER)
El contenido puede ser recuperado si se requiere.
---
**Actualizado:** 2026-01-24
**Estandar aplicado:** SIMCO-ESTANDAR-ORCHESTRATION v1.0.0

View File

@ -1,229 +0,0 @@
# ═══════════════════════════════════════════════════════════════════════════════
# DECLARACION DE HERENCIA - CLINICA-DENTAL
# ═══════════════════════════════════════════════════════════════════════════════
#
# Proyecto: clinica-dental
# Rol: Sub-vertical especializada en odontologia
# Nivel: SUB-CONSUMER (Hereda de erp-clinicas)
#
# ═══════════════════════════════════════════════════════════════════════════════
version: "1.0.0"
created: "2026-01-16"
updated: "2026-01-16"
proyecto: "clinica-dental"
# ─────────────────────────────────────────────────────────────────────────────────
# RELACION DE HERENCIA
# ─────────────────────────────────────────────────────────────────────────────────
herencia:
parent: "erp-clinicas"
parent_version: "1.0.0"
tipo: "SPECIALIZES"
cadena: "template-saas -> erp-core -> erp-clinicas -> clinica-dental"
especializacion: "odontologia"
# ─────────────────────────────────────────────────────────────────────────────────
# MODULOS HEREDADOS
# ─────────────────────────────────────────────────────────────────────────────────
modulos:
heredados:
# De la cadena completa
- name: "auth"
version: "1.0.0"
status: "active"
origen: "template-saas"
- name: "tenants"
version: "1.0.0"
status: "active"
origen: "template-saas"
- name: "billing"
version: "1.0.0"
status: "active"
origen: "template-saas"
- name: "notifications"
version: "1.0.0"
status: "active"
origen: "template-saas"
# De erp-core
- name: "catalogs"
version: "1.0.0"
status: "active"
origen: "erp-core"
- name: "inventory"
version: "1.0.0"
status: "active"
origen: "erp-core"
uso: "Inventario de materiales dentales"
# De erp-clinicas
- name: "pacientes"
version: "1.0.0"
status: "active"
origen: "erp-clinicas"
uso: "Gestion de pacientes odontologicos"
- name: "citas"
version: "1.0.0"
status: "active"
origen: "erp-clinicas"
uso: "Agenda dental"
- name: "expedientes"
version: "1.0.0"
status: "active"
origen: "erp-clinicas"
uso: "Historia clinica odontologica"
- name: "prescripciones"
version: "1.0.0"
status: "active"
origen: "erp-clinicas"
uso: "Recetas dentales"
# Modulos adaptados para odontologia
extendidos:
- name: "pacientes"
adaptacion: "Campos especificos dentales"
campos_agregados:
- "tipo_denticion"
- "historial_fluorosis"
- "sensibilidad_dental"
- name: "expedientes"
adaptacion: "Historia clinica dental"
campos_agregados:
- "odontograma_inicial"
- "plan_tratamiento"
# Modulos propios de clinica-dental
propios:
- name: "odontograma"
id: "CDT-001"
version: "1.0.0"
estado: "30%"
descripcion: "Odontograma digital interactivo"
tablas:
- "sub_dental.odontograms"
- "sub_dental.tooth_conditions"
- "sub_dental.tooth_treatments"
- name: "tratamientos-dentales"
id: "CDT-002"
version: "1.0.0"
estado: "25%"
descripcion: "Catalogo de tratamientos dentales"
tablas:
- "sub_dental.dental_treatments"
- "sub_dental.treatment_plans"
- "sub_dental.treatment_progress"
- name: "ortodoncia"
id: "CDT-003"
version: "1.0.0"
estado: "20%"
descripcion: "Modulo de ortodoncia y brackets"
tablas:
- "sub_dental.orthodontic_cases"
- "sub_dental.bracket_types"
- "sub_dental.orthodontic_progress"
- name: "protesis"
id: "CDT-004"
version: "1.0.0"
estado: "15%"
descripcion: "Protesis dentales y laboratorio"
tablas:
- "sub_dental.prosthetics"
- "sub_dental.lab_orders"
- name: "radiografias-dentales"
id: "CDT-005"
version: "1.0.0"
estado: "20%"
descripcion: "Radiografias panoramicas y periapicales"
tablas:
- "sub_dental.dental_xrays"
- "sub_dental.xray_analysis"
- name: "presupuestos-dentales"
id: "CDT-006"
version: "1.0.0"
estado: "25%"
descripcion: "Presupuestos de tratamiento dental"
tablas:
- "sub_dental.dental_quotes"
- "sub_dental.quote_items"
# ─────────────────────────────────────────────────────────────────────────────────
# CONFIGURACION
# ─────────────────────────────────────────────────────────────────────────────────
configuracion:
schema_prefix: "sub_dental"
schemas_propios:
- "sub_dental"
normativa:
- nombre: "NOM-013-SSA2-2015"
descripcion: "Para la prevencion y control de enfermedades bucales"
aplica_a: ["odontograma", "tratamientos-dentales"]
- nombre: "NOM-004-SSA3-2012"
descripcion: "Del expediente clinico"
aplica_a: ["expedientes"]
- nombre: "COFEPRIS"
descripcion: "Regulacion de consultorios dentales"
aplica_a: ["todos"]
# ─────────────────────────────────────────────────────────────────────────────────
# CONSUMIDORES
# ─────────────────────────────────────────────────────────────────────────────────
consumidores:
# clinica-dental es nodo terminal, no tiene consumidores
proyectos: []
# ─────────────────────────────────────────────────────────────────────────────────
# VALIDACION
# ─────────────────────────────────────────────────────────────────────────────────
validacion:
ultima_validacion: "2026-01-16"
parent_compatible: true
checklist:
- item: "erp-clinicas v1.0.0 existe"
status: "passed"
- item: "Modulos clinica disponibles"
status: "pending"
bloqueos:
- regla: "BLOCK-002"
descripcion: "No puede avanzar si erp-clinicas < 50%"
estado_actual: "erp-clinicas al 10%"
accion: "Solo documentacion hasta que erp-clinicas llegue a 50%"
# ─────────────────────────────────────────────────────────────────────────────────
# METADATA
# ─────────────────────────────────────────────────────────────────────────────────
metadata:
created_by: "Claude Opus 4.5"
created_at: "2026-01-16"
task_id: "TASK-2026-01-16-002"
related_documents:
- "orchestration/DEPENDENCY-GRAPH.yml"
- "orchestration/TRACEABILITY.yml"
# ═══════════════════════════════════════════════════════════════════════════════
# FIN DE DECLARACION DE HERENCIA
# ═══════════════════════════════════════════════════════════════════════════════

View File

@ -1,165 +0,0 @@
# TRIGGER: Coherencia Entre Capas - Clinica Dental
**ID:** TRIGGER-DENTAL-COHERENCIA
**Version:** 1.0.0
**Proyecto:** clinica-dental
**Hereda de:** @ERP_TRIGGER_COHERENCIA -> @CLINICAS_TRIGGER_COHERENCIA
**Alias:** @DENTAL_TRIGGER_COHERENCIA
---
## Proposito
Validar que cada objeto creado en una capa tenga su correspondiente en las demas capas, manteniendo coherencia DDL - Backend - Frontend, con validaciones especificas para el dominio odontologico.
## Cadena de Herencia
```
template-saas (PROVIDER)
|
v
erp-core (INTERMEDIATE)
|
v
erp-clinicas (CONSUMER)
|
v
clinica-dental (SUB-VERTICAL) <- ESTE PROYECTO
```
## Activacion
### Automatica
- Creacion/modificacion de tabla DDL en schema `sub_dental`
- Creacion/modificacion de entity TypeORM en modulos dentales
- Creacion/modificacion de endpoint API especifico dental
### Manual
- Comando: `@DENTAL_VALIDATE_COHERENCE`
- Pre-commit hook
## Reglas de Validacion
### DDL -> Backend (OBLIGATORIO)
```yaml
regla_1:
condicion: "Nueva tabla DDL creada en sub_dental.*"
accion: "Verificar entity correspondiente existe"
bloquea: true
regla_2:
condicion: "Columna agregada a tabla dental"
accion: "Verificar campo en entity existe"
bloquea: true
regla_3:
condicion: "Constraint FK agregado a tabla dental"
accion: "Verificar relacion TypeORM existe"
bloquea: true
```
### Backend -> Frontend (CONDICIONAL)
```yaml
regla_4:
condicion: "Endpoint CRUD dental creado"
accion: "Verificar hook/servicio frontend existe"
bloquea: false # Solo warning
regla_5:
condicion: "DTO dental modificado"
accion: "Verificar tipos TypeScript frontend"
bloquea: false
```
## Validaciones Especificas Clinica Dental
### Modulos CDT (Clinica Dental)
| Modulo | DDL Schema | Backend Path | Frontend Path |
|--------|------------|--------------|---------------|
| CDT-001 Odontograma | sub_dental.odontograms, tooth_* | modules/odontograma/ | pages/odontograma/ |
| CDT-002 Tratamientos | sub_dental.dental_treatments | modules/tratamientos-dentales/ | pages/tratamientos/ |
| CDT-003 Ortodoncia | sub_dental.orthodontic_* | modules/ortodoncia/ | pages/ortodoncia/ |
| CDT-004 Protesis | sub_dental.prosthetics | modules/protesis/ | pages/protesis/ |
| CDT-005 Radiografias | sub_dental.dental_xrays | modules/radiografias/ | pages/radiografias/ |
| CDT-006 Presupuestos | sub_dental.dental_quotes | modules/presupuestos/ | pages/presupuestos/ |
### Coherencia de Nombres
```
DDL: sub_dental.tabla_nombre (snake_case)
Entity: TablaNombre (PascalCase)
Service: tabla-nombre.service.ts (kebab-case)
Controller: tabla-nombre.controller.ts (kebab-case)
```
## Validaciones Normativas (NOM-013-SSA2-2015)
### Campos Obligatorios para Expediente Clinico Dental
```yaml
validacion_normativa:
condicion: "Entity de expediente dental"
campos_requeridos:
- "historia_clinica_general"
- "examen_extraoral"
- "examen_intraoral"
- "odontograma_inicial"
- "diagnostico_presuntivo"
- "plan_tratamiento"
- "consentimiento_informado"
referencia_normativa: "NOM-013-SSA2-2015"
bloquea: true
```
### Integridad de Odontograma
```yaml
validacion_odontograma:
condicion: "Tabla odontograms creada/modificada"
reglas:
- "32 piezas dentales adulto o 20 deciduos"
- "Estado por superficie (5 superficies por pieza)"
- "Codigos CIE-10 para diagnosticos"
bloquea: true
```
## Excepciones Permitidas
1. **Tablas M:N gestionadas por TypeORM**
- Documentar en ENTITIES-CATALOG.md
2. **Tablas de auditoria/sistema**
- Prefijo: `_audit_dental`, `_system_dental`
3. **Tablas heredadas de erp-clinicas**
- No requieren entity local si se usa la del padre
4. **Vistas para reportes NOM**
- Documentar en DATABASE-SCHEMA.md
## Metricas
| Metrica | Objetivo | Actual |
|---------|----------|--------|
| Coherencia DDL-Entity | 100% | TBD |
| Coherencia Entity-Service | 100% | TBD |
| Coherencia API-Frontend | 95% | TBD |
| Cumplimiento NOM-013 | 100% | TBD |
## Referencias
- `@DENTAL_DEF_DB` - DATABASE-SCHEMA.md
- `@DENTAL_DEF_ENTITIES` - ENTITIES-CATALOG.md
- `@CLINICAS_TRIGGER_COHERENCIA` - Trigger padre en erp-clinicas
- `@ERP_TRIGGER_COHERENCIA` - Trigger abuelo en erp-core
- `@WS_TRIGGER_COHERENCIA` - Trigger raiz del workspace
---
**Normativa Aplicable:**
- NOM-013-SSA2-2015: Prevencion y control de enfermedades bucales
- NOM-004-SSA3-2012: Del expediente clinico
- COFEPRIS: Regulacion de consultorios dentales

View File

@ -1,249 +0,0 @@
# TRIGGER: Inventarios Sincronizados - Clinica Dental
**ID:** TRIGGER-DENTAL-INVENTARIOS
**Version:** 1.0.0
**Proyecto:** clinica-dental
**Hereda de:** @ERP_TRIGGER_INVENTARIOS -> @CLINICAS_TRIGGER_INVENTARIOS
**Alias:** @DENTAL_TRIGGER_INVENTARIOS
---
## Proposito
Mantener los inventarios sincronizados con el codigo fuente, asegurando que cada objeto nuevo/modificado este registrado, con enfasis en componentes especificos del dominio odontologico.
## Cadena de Herencia
```
template-saas (PROVIDER)
|
v
erp-core (INTERMEDIATE)
|
v
erp-clinicas (CONSUMER)
|
v
clinica-dental (SUB-VERTICAL) <- ESTE PROYECTO
```
## Activacion
### Post-Tarea
- Creacion de entity/service/controller dental
- Creacion de tabla DDL en sub_dental
- Creacion de componente frontend dental
- Modificacion de modulo CDT
### Automatica
- Post-commit (via hook)
- Pre-release
## Inventarios a Sincronizar
### DATABASE_INVENTORY.yml
```yaml
ubicacion: "orchestration/inventarios/DATABASE_INVENTORY.yml"
contenido:
schemas_propios:
- sub_dental
tablas_dental:
- sub_dental.odontograms
- sub_dental.tooth_conditions
- sub_dental.tooth_treatments
- sub_dental.dental_treatments
- sub_dental.treatment_plans
- sub_dental.treatment_progress
- sub_dental.orthodontic_cases
- sub_dental.bracket_types
- sub_dental.orthodontic_progress
- sub_dental.prosthetics
- sub_dental.lab_orders
- sub_dental.dental_xrays
- sub_dental.xray_analysis
- sub_dental.dental_quotes
- sub_dental.quote_items
tablas_heredadas:
- "clinicas.pacientes (extendido)"
- "clinicas.citas (adaptado)"
- "clinicas.expedientes (extendido)"
```
### BACKEND_INVENTORY.yml
```yaml
ubicacion: "orchestration/inventarios/BACKEND_INVENTORY.yml"
contenido:
modulos_CDT:
- CDT-001: odontograma
- CDT-002: tratamientos-dentales
- CDT-003: ortodoncia
- CDT-004: protesis
- CDT-005: radiografias-dentales
- CDT-006: presupuestos-dentales
entities_por_modulo: TBD
services_por_modulo: TBD
controllers_y_endpoints: TBD
dtos: TBD
guards_especificos:
- dental-professional.guard.ts
- patient-consent.guard.ts
```
### FRONTEND_INVENTORY.yml
```yaml
ubicacion: "orchestration/inventarios/FRONTEND_INVENTORY.yml"
contenido:
pages_dentales:
- OdontogramaPage
- TratamientosPage
- OrtodonciaDashboard
- ProtesisPage
- RadiografiaViewer
- PresupuestoEditor
components_especializados:
- OdontogramaInteractivo
- ToothSelector
- TreatmentPlanBuilder
- BracketTracker
- XRayViewer
- QuoteCalculator
hooks_dental:
- useOdontograma
- useTreatmentPlan
- useDentalHistory
```
### MASTER_INVENTORY.yml
```yaml
ubicacion: "orchestration/inventarios/MASTER_INVENTORY.yml"
contenido:
totales_consolidados: TBD
estadisticas_por_capa: TBD
ultima_sincronizacion: TBD
cobertura_tests: TBD
cumplimiento_normativo: TBD
```
## Reglas de Actualizacion
```yaml
regla_1:
evento: "Entity dental creada"
acciones:
- Agregar a BACKEND_INVENTORY.yml
- Incrementar contador en MASTER_INVENTORY.yml
- Verificar campos NOM-013 si aplica
regla_2:
evento: "Tabla DDL dental creada"
acciones:
- Agregar a DATABASE_INVENTORY.yml
- Verificar entity correspondiente
- Validar schema sub_dental
regla_3:
evento: "Componente React dental creado"
acciones:
- Agregar a FRONTEND_INVENTORY.yml
- Clasificar por tipo (page/component/hook)
- Verificar accesibilidad WCAG si es UI paciente
```
## Validacion de Consistencia
### Conteos Esperados
| Inventario | Metrica | Valor Esperado |
|------------|---------|----------------|
| DATABASE | Schemas propios | 1 (sub_dental) |
| DATABASE | Tablas propias | 15+ |
| DATABASE | Tablas heredadas | 10+ (de clinicas) |
| BACKEND | Modulos CDT | 6 |
| BACKEND | Entities | 15+ |
| FRONTEND | Pages | 6+ |
| FRONTEND | Components especializados | 10+ |
### Script de Validacion
```bash
# Validar sincronizacion
npm run inventory:validate
# Actualizar inventarios
npm run inventory:sync
# Validar cumplimiento NOM-013
npm run inventory:validate-nom
```
## Inventarios de Materiales Dentales
### Categorias Especiales (Control NOM)
```yaml
materiales_controlados:
anestesicos:
- lidocaina
- articaina
- mepivacaina
registro_obligatorio: true
trazabilidad: "por ampolleta"
amalgamas:
- alto_contenido_cobre
- bajo_contenido_cobre
registro_obligatorio: true
disposicion_especial: true
resinas:
- composites
- ionomeros_vidrio
lote_tracking: true
instrumental_esteril:
- espejos
- exploradores
- pinzas
ciclos_esterilizacion: tracking
```
## Formato de Entrada
```yaml
# Nueva entity dental
entities:
- nombre: "OdontogramEntity"
archivo: "odontogram.entity.ts"
modulo: "odontograma"
tabla_ddl: "sub_dental.odontograms"
estado: "implementado"
tests: true
cumple_nom_013: true
```
## Metricas
| Metrica | Objetivo | Actual |
|---------|----------|--------|
| Sincronizacion DB | 100% | TBD |
| Sincronizacion BE | 100% | TBD |
| Sincronizacion FE | 100% | TBD |
| Trazabilidad materiales | 100% | TBD |
| Ultima actualizacion | Diaria | TBD |
## Referencias
- `@DENTAL_INV_MASTER` - MASTER_INVENTORY.yml
- `@DENTAL_INV_DB` - DATABASE_INVENTORY.yml
- `@DENTAL_INV_BE` - BACKEND_INVENTORY.yml
- `@DENTAL_INV_FE` - FRONTEND_INVENTORY.yml
- `@CLINICAS_TRIGGER_INVENTARIOS` - Trigger padre
- `@ERP_TRIGGER_INVENTARIOS` - Trigger abuelo
- `@WS_TRIGGER_INVENTARIOS` - Trigger raiz del workspace
---
**Normativa Aplicable para Inventarios:**
- NOM-013-SSA2-2015: Control de materiales e instrumental
- NOM-087-SEMARNAT-SSA1-2002: Residuos peligrosos biologico-infecciosos (RPBI)
- COFEPRIS: Registro de medicamentos controlados

View File

@ -1,185 +0,0 @@
# CHECKLIST-CIERRE: Gate Final de Tarea
**Version:** 1.0.0
**Actualizado:** 2026-01-18
**Alias:** `@CHK-CIERRE`, `@DEF_CHK_POST`
## Proposito
Gate BLOQUEANTE final antes de marcar una tarea como completada.
**NINGUN ITEM PUEDE QUEDAR SIN MARCAR.**
---
## SECCION 1: GOBERNANZA (OBLIGATORIO)
### Estructura de Tarea
- [ ] Carpeta de tarea existe: `orchestration/tareas/TASK-YYYY-MM-DD-NNN/`
- [ ] METADATA.yml completo y correcto
- [ ] SUBTASKS.yml con summary actualizado
- [ ] LESSONS-LEARNED.yml iniciado (minimo summary)
### Registro en Indices
- [ ] Entrada en `orchestration/tareas/_INDEX.yml`
- [ ] Status: completed
- [ ] Path correcto
---
## SECCION 2: VALIDACIONES TECNICAS (OBLIGATORIO)
### Build (segun dominios afectados)
- [ ] Backend: `npm run build` PASA
- [ ] Frontend: `npm run build` PASA
- [ ] Database: `recreate-database.sh` exitoso
### Lint
- [ ] Backend: `npm run lint` PASA (< 5 warnings nuevos)
- [ ] Frontend: `npm run lint` PASA
### Tests
- [ ] Backend: `npm run test` PASA (tests existentes)
- [ ] Frontend: `npm run test` PASA (si existen)
- [ ] Ningun test nuevo falla
### TypeCheck
- [ ] Frontend: `npm run typecheck` PASA
---
## SECCION 3: COHERENCIA ENTRE CAPAS (OBLIGATORIO)
### DDL -> Backend
- [ ] Toda tabla nueva tiene entity correspondiente
- [ ] Campos de entity coinciden con columnas de tabla
- [ ] Tipos TypeScript compatibles con tipos PostgreSQL
- [ ] EXCEPCIONES documentadas (tablas M:N, audit, etc.)
### Backend -> Frontend (si aplica)
- [ ] Endpoints nuevos documentados
- [ ] DTOs expuestos correctamente
- [ ] Frontend consume endpoints correctamente
---
## SECCION 4: INVENTARIOS (OBLIGATORIO)
### Actualizacion
- [ ] DATABASE_INVENTORY.yml actualizado (si cambio DDL)
- [ ] BACKEND_INVENTORY.yml actualizado (si cambio backend)
- [ ] FRONTEND_INVENTORY.yml actualizado (si cambio frontend)
- [ ] MASTER_INVENTORY.yml actualizado con totales
### Cobertura
- [ ] Cobertura de inventarios = 100% (sin objetos sin documentar)
---
## SECCION 5: TRAZAS (OBLIGATORIO)
### Archivos de Traza
- [ ] TRAZA-TAREAS-*.md correspondiente actualizado
- [ ] Cambios documentados con fecha y descripcion
### SSOT (si nueva funcionalidad)
- [ ] TRACEABILITY-MASTER.yml actualizado
- [ ] EPIC-INDEX.yml actualizado si cambio estado de epica
---
## SECCION 6: PROPAGACION (EVALUACION)
### Evaluacion
- [ ] Se evaluo si cambio requiere propagacion a otros proyectos
- [ ] Si SI requiere: plan de propagacion documentado
- [ ] Si NO requiere: marcado como N/A
---
## SECCION 7: GIT (OBLIGATORIO)
### Estado del Repositorio
- [ ] `git status` = "working tree clean"
- [ ] Todos los cambios commiteados
- [ ] Commit message sigue convencion: `[TASK-ID] tipo: descripcion`
### Push (segun politica)
- [ ] Cambios pusheados a remote (si aplica)
- [ ] `git log origin/main..HEAD` vacio (si aplica)
---
## RESUMEN DE VALIDACION
| Seccion | Estado |
|---------|--------|
| 1. Gobernanza | [ ] PASA |
| 2. Validaciones Tecnicas | [ ] PASA |
| 3. Coherencia Entre Capas | [ ] PASA |
| 4. Inventarios | [ ] PASA |
| 5. Trazas | [ ] PASA |
| 6. Propagacion | [ ] EVALUADO |
| 7. Git | [ ] PASA |
---
## CRITERIO FINAL
### TAREA COMPLETADA si:
- [ ] **TODAS** las secciones marcadas como PASA/EVALUADO
- [ ] **NINGUN** item critico sin marcar
- [ ] **NINGUN** build/lint/test fallando
### TAREA NO COMPLETADA si:
- Cualquier seccion falla
- Items pendientes sin justificacion
- Errores de build/lint/test
---
## ACCION POST-CIERRE
Si PASA:
1. Marcar METADATA.yml status: completed
2. Marcar SUBTASKS.yml todas completadas
3. Actualizar _INDEX.yml con status: completed
4. Commit final con mensaje: `[TASK-ID] docs: cierre de tarea`
Si NO PASA:
1. Identificar items faltantes
2. Completar items
3. Re-ejecutar este checklist
---
## NOTAS
Este checklist integra:
- `@TRIGGER_CIERRE` - Trigger de cierre obligatorio
- `@TRIGGER_COHERENCIA` - Coherencia entre capas
- `@TRIGGER_INVENTARIOS` - Inventarios sincronizados
**NO se puede marcar tarea como completada sin pasar este checklist.**
---
## Referencias
- Trigger Cierre: `orchestration/directivas/triggers/TRIGGER-CIERRE-TAREA-OBLIGATORIO.md`
- Trigger Coherencia: `orchestration/directivas/triggers/TRIGGER-COHERENCIA-CAPAS.md`
- Trigger Inventarios: `orchestration/directivas/triggers/TRIGGER-INVENTARIOS-SINCRONIZADOS.md`

View File

@ -1,74 +0,0 @@
# CHECKLIST-FASE-A: Gate de Analisis
**Version:** 1.0.0
**Actualizado:** 2026-01-18
**Alias:** `@CHK-ANALISIS`
## Proposito
Validar que el analisis de impacto y dependencias esta completo antes de planificar.
---
## Checklist
### Analisis de Dependencias
- [ ] Identificados archivos que IMPORTAN los archivos a modificar (dependientes)
- [ ] Identificados archivos que los archivos a modificar IMPORTAN (dependencias)
- [ ] Evaluado impacto del cambio en dependientes
- [ ] Si hay cambios breaking: incluidos en el alcance
### Analisis de Codigo Existente
- [ ] Leido y entendido el codigo actual a modificar
- [ ] Identificados patrones existentes a seguir
- [ ] Identificados anti-patrones a evitar
- [ ] Documentado estado actual (si es complejo)
### Analisis de Riesgos
- [ ] Riesgos tecnicos identificados
- [ ] Riesgos de integracion identificados
- [ ] Plan de mitigacion para riesgos altos
- [ ] Riesgos documentados en METADATA.yml o SUBTASKS.yml
### Validacion de Alcance
- [ ] Alcance claramente definido (que SI y que NO incluye)
- [ ] Criterios de aceptacion identificados
- [ ] Entregables esperados listados
### Dependencias de Tareas
- [ ] Tareas previas requeridas identificadas
- [ ] Tareas bloqueadas por esta identificadas
- [ ] Si hay bloqueantes: documentados y plan de resolucion
---
## Criterios de Paso
**PASA** si:
- Dependencias de codigo mapeadas
- Riesgos identificados (aunque sea "sin riesgos significativos")
- Alcance definido
**NO PASA** si:
- No se leyó el codigo existente
- Cambios breaking no identificados
- Riesgos no evaluados
---
## Siguiente Fase
Si PASA: Continuar a **Fase P: Plan**
Si NO PASA: Completar analisis faltante
---
## Referencias
- Trigger Analisis Dependencias: `orchestration/directivas/triggers/TRIGGER-ANALISIS-DEPENDENCIAS.md`
- DEPENDENCY-GRAPH: `orchestration/trazabilidad/DEPENDENCY-GRAPH-VISUAL.yml`

View File

@ -1,77 +0,0 @@
# CHECKLIST-FASE-C: Gate de Contexto
**Version:** 1.0.0
**Actualizado:** 2026-01-18
**Alias:** `@CHK-CONTEXTO`
## Proposito
Validar que la tarea esta correctamente contextualizada antes de pasar a Analisis.
---
## Checklist
### Identificacion
- [ ] Task ID asignado (TASK-YYYY-MM-DD-NNN)
- [ ] Titulo descriptivo definido
- [ ] Tipo de tarea clasificado (feature/bug/refactor/audit/migration/documentation)
- [ ] Prioridad asignada (P0-P3)
- [ ] Epic relacionada identificada (si aplica)
### Vinculacion con Requerimientos
- [ ] RF (Requerimientos Funcionales) vinculados
- [ ] ET (Especificaciones Tecnicas) vinculados
- [ ] US (User Stories) vinculadas
- [ ] Verificado que RF existe en documentacion (no inventado)
### Verificacion Anti-Duplicacion
- [ ] Consultado `shared/catalog/CATALOG-INDEX.yml` por funcionalidad similar
- [ ] Verificado en inventarios que no existe duplicado
- [ ] Si existe similar: documentado diferencia o marcado como extension
### Dominios Afectados
- [ ] Identificados dominios que seran afectados:
- [ ] Database (DDL, seeds, migrations)
- [ ] Backend (entities, services, controllers)
- [ ] Frontend (components, pages, stores)
- [ ] Documentation (inventarios, trazas)
### Metadata Inicial
- [ ] METADATA.yml creado con campos basicos
- [ ] SUBTASKS.yml inicializado (puede estar vacio)
---
## Criterios de Paso
**PASA** si:
- Todos los items de "Identificacion" estan marcados
- Al menos 1 RF o US esta vinculado
- Verificacion anti-duplicacion realizada
- Dominios afectados identificados
**NO PASA** si:
- Tarea no tiene RF/ET/US vinculados y no es tarea tecnica
- No se verifico duplicacion
- Dominios no estan claros
---
## Siguiente Fase
Si PASA: Continuar a **Fase A: Analisis**
Si NO PASA: Completar items faltantes antes de continuar
---
## Referencias
- Trigger Anti-Duplicacion: `orchestration/directivas/triggers/TRIGGER-ANTI-DUPLICACION.md`
- SSOT: `docs/_SSOT/REQUIREMENTS-INDEX.yml`
- Catalogo: `shared/catalog/CATALOG-INDEX.yml`

View File

@ -1,111 +0,0 @@
# CHECKLIST-FASE-D: Gate de Documentacion
**Version:** 1.0.0
**Actualizado:** 2026-01-18
**Alias:** `@CHK-DOCUMENTACION`
## Proposito
Validar que toda la documentacion necesaria ha sido actualizada.
---
## Checklist
### Inventarios (OBLIGATORIO)
- [ ] DATABASE_INVENTORY.yml actualizado (si cambio DDL):
- [ ] Conteo de tablas correcto
- [ ] Conteo de enums correcto
- [ ] Conteo de funciones/triggers correcto
- [ ] BACKEND_INVENTORY.yml actualizado (si cambio backend):
- [ ] Conteo de entities correcto
- [ ] Conteo de DTOs correcto
- [ ] Conteo de services/controllers correcto
- [ ] FRONTEND_INVENTORY.yml actualizado (si cambio frontend):
- [ ] Conteo de components correcto
- [ ] Conteo de pages correcto
- [ ] Conteo de stores correcto
- [ ] MASTER_INVENTORY.yml actualizado:
- [ ] Resumen consolidado correcto
- [ ] Fecha de actualizacion
### Trazas (OBLIGATORIO)
- [ ] TRAZA-TAREAS-DATABASE.md actualizado (si cambio DDL)
- [ ] TRAZA-TAREAS-BACKEND.md actualizado (si cambio backend)
- [ ] TRAZA-TAREAS-FRONTEND.md actualizado (si cambio frontend)
- [ ] TRAZA-CORRECCIONES.md actualizado (si fue fix)
### Indice de Tareas (OBLIGATORIO)
- [ ] _INDEX.yml actualizado con nueva entrada:
```yaml
- id: TASK-YYYY-MM-DD-NNN
title: "Titulo"
date: "YYYY-MM-DD"
status: completed
path: "orchestration/tareas/TASK-.../"
```
### SSOT (si aplica)
- [ ] docs/_SSOT/TRACEABILITY-MASTER.yml actualizado (si nueva funcionalidad)
- [ ] docs/_SSOT/EPIC-INDEX.yml actualizado (si cambio estado de epica)
- [ ] docs/_SSOT/CODE-MAPPINGS.yml actualizado (si nuevos mappings)
### Documentacion de Tarea
- [ ] METADATA.yml de la tarea completado:
- [ ] Status: completed
- [ ] Completion: 100%
- [ ] Todas las fases marcadas como completed
- [ ] Metricas finales
- [ ] SUBTASKS.yml de la tarea actualizado:
- [ ] Todas las subtareas marcadas como completed
- [ ] Summary actualizado
### Lecciones Aprendidas
- [ ] LESSONS-LEARNED.yml iniciado:
- [ ] Al menos "what_worked" o "what_didnt_work" completado
- [ ] Recomendaciones si aplica
### Propagacion (si aplica)
- [ ] Evaluada necesidad de propagacion a otros proyectos
- [ ] Si requiere propagacion: documentado en METADATA.yml
---
## Criterios de Paso
**PASA** si:
- Inventarios afectados actualizados
- _INDEX.yml actualizado
- METADATA.yml de tarea completado
- SUBTASKS.yml con summary correcto
**NO PASA** si:
- Inventarios desactualizados
- Tarea no registrada en _INDEX.yml
- METADATA.yml incompleto
---
## Siguiente Fase
Si PASA: Continuar a **CHECKLIST-CIERRE.md** (Gate Final)
Si NO PASA: Completar documentacion faltante
---
## Referencias
- Trigger Inventarios: `orchestration/directivas/triggers/TRIGGER-INVENTARIOS-SINCRONIZADOS.md`
- Inventarios: `orchestration/inventarios/`
- SSOT: `docs/_SSOT/`

View File

@ -1,184 +0,0 @@
# CHECKLIST-FASE-E: Gate de Ejecucion
**Version:** 1.0.0
**Actualizado:** 2026-01-18
**Alias:** `@CHK-EJECUCION`
## Proposito
Validar ejecucion por checkpoints. Cada checkpoint es un gate de validacion.
---
## Checkpoint CP1: Post-Database
**Ejecutar despues de cambios en DDL**
### Validaciones
- [ ] DDL ejecuta sin errores de sintaxis
- [ ] `./scripts/recreate-database.sh` exitoso
- [ ] Tablas creadas/modificadas verificadas
- [ ] Enums definidos correctamente
- [ ] Foreign keys validas
- [ ] Indexes creados si aplica
### Comandos de Validacion
```bash
cd apps/database
./scripts/recreate-database.sh
# Verificar output sin errores
```
### Criterios de Paso CP1
- [ ] Sin errores de ejecucion DDL
- [ ] Estructura de BD consistente
---
## Checkpoint CP2: Post-Backend
**Ejecutar despues de cambios en Backend**
### Validaciones
- [ ] `npm run build` - PASA
- [ ] `npm run lint` - PASA (o warnings aceptables)
- [ ] `npm run test` - PASA (si existen tests)
- [ ] Entity alineada con DDL (campos, tipos)
- [ ] DTO definidos correctamente
- [ ] Service implementado
- [ ] Controller endpoints funcionan
### Comandos de Validacion
```bash
cd apps/backend
npm run build
npm run lint
npm run test
```
### Criterios de Paso CP2
- [ ] Build exitoso
- [ ] Lint pasa (< 5 warnings nuevos)
- [ ] Tests existentes pasan
- [ ] No hay errores de TypeScript
---
## Checkpoint CP3: Post-Frontend
**Ejecutar despues de cambios en Frontend**
### Validaciones
- [ ] `npm run build` - PASA
- [ ] `npm run typecheck` - PASA
- [ ] Componentes renderizan sin errores
- [ ] Integracion con API funciona
- [ ] Tipos alineados con backend DTOs
### Comandos de Validacion
```bash
cd apps/frontend
npm run build
npm run typecheck
```
### Criterios de Paso CP3
- [ ] Build exitoso
- [ ] Typecheck pasa
- [ ] Sin errores de consola en runtime
---
## Checkpoint CP4: Coherencia Entre Capas
**Ejecutar al final de ejecucion**
### Validaciones
- [ ] Entity alineada con DDL:
- [ ] Todos los campos de tabla tienen propiedad en entity
- [ ] Tipos TypeScript compatibles con tipos PostgreSQL
- [ ] Relaciones correctamente definidas
- [ ] DTO alineado con Entity:
- [ ] DTOs exponen campos necesarios
- [ ] Transformaciones correctas
- [ ] Validaciones implementadas
- [ ] Frontend consume correctamente:
- [ ] Endpoints correctos
- [ ] Tipos de respuesta alineados
- [ ] Manejo de errores
### Matriz de Coherencia
| DDL | Backend Entity | Backend DTO | Frontend |
|-----|----------------|-------------|----------|
| [ ] Tabla | [ ] Entity | [ ] DTO | [ ] API call |
### Criterios de Paso CP4
- [ ] Sin gaps de coherencia criticos
- [ ] Documentacion de gaps menores si existen
---
## Checklist General de Ejecucion
### Durante Ejecucion
- [ ] Seguir orden de SUBTASKS.yml
- [ ] Marcar subtareas completadas conforme avanzan
- [ ] No saltarse checkpoints
- [ ] Documentar decisiones tomadas
### Manejo de Errores
- [ ] Si falla un checkpoint: detener y resolver
- [ ] No avanzar con errores pendientes
- [ ] Documentar errores encontrados y resoluciones
### Control de Cambios
- [ ] Commits atomicos por subtarea
- [ ] Mensajes de commit descriptivos
- [ ] No mezclar cambios no relacionados
---
## Criterios de Paso Fase E
**PASA** si:
- CP1 pasa (si hubo cambios DB)
- CP2 pasa (si hubo cambios BE)
- CP3 pasa (si hubo cambios FE)
- CP4 pasa
- Todas las subtareas de E marcadas como completadas
**NO PASA** si:
- Cualquier checkpoint falla
- Build/lint/test fallan
- Gaps de coherencia criticos
---
## Siguiente Fase
Si PASA: Continuar a **Fase D: Documentacion**
Si NO PASA: Resolver errores y re-ejecutar checkpoint
---
## Referencias
- Trigger Coherencia: `orchestration/directivas/triggers/TRIGGER-COHERENCIA-CAPAS.md`
- Inventarios: `orchestration/inventarios/`

View File

@ -1,75 +0,0 @@
# CHECKLIST-FASE-P: Gate de Plan
**Version:** 1.0.0
**Actualizado:** 2026-01-18
**Alias:** `@CHK-PLAN`
## Proposito
Validar que el plan de ejecucion esta completo y es viable.
---
## Checklist
### Desglose de Subtareas
- [ ] SUBTASKS.yml completado con subtareas especificas
- [ ] Subtareas agrupadas por dominio (E.DB, E.BE, E.FE)
- [ ] Criterios de aceptacion definidos por subtarea
- [ ] Dependencias entre subtareas claras
### Orden de Ejecucion
- [ ] Secuencia de ejecucion definida
- [ ] Checkpoints identificados (CP1-CP4)
- [ ] Grupos que se pueden paralelizar identificados
- [ ] Bloqueantes considerados en secuencia
### Validaciones Planeadas
- [ ] Validaciones de build planificadas
- [ ] Validaciones de lint planificadas
- [ ] Validaciones de tests planificadas (si existen)
- [ ] Validacion de coherencia entre capas planificada
### Recursos Necesarios
- [ ] Archivos a crear identificados
- [ ] Archivos a modificar identificados
- [ ] Dependencias externas identificadas (si aplica)
- [ ] Acceso a sistemas necesarios confirmado
### Estimacion
- [ ] Complejidad estimada (low/medium/high)
- [ ] Esfuerzo estimado (horas/story points)
- [ ] Riesgos de tiempo considerados
---
## Criterios de Paso
**PASA** si:
- SUBTASKS.yml tiene al menos las fases E y D detalladas
- Orden de ejecucion es claro
- Checkpoints definidos
**NO PASA** si:
- No hay desglose de subtareas
- Orden de ejecucion ambiguo
- Sin criterios de aceptacion
---
## Siguiente Fase
Si PASA: Continuar a **Fase V: Validacion Pre-Ejecucion**
Si NO PASA: Refinar plan
---
## Referencias
- SUBTASKS Template: `orchestration/tareas/_templates/TASK-TEMPLATE-UNIFIED/SUBTASKS.yml`
- Principio CAPVED: `orchestration/directivas/principios/PRINCIPIO-CAPVED.md`

View File

@ -1,81 +0,0 @@
# CHECKLIST-FASE-V: Gate de Validacion Pre-Ejecucion
**Version:** 1.0.0
**Actualizado:** 2026-01-18
**Alias:** `@CHK-VALIDACION`
## Proposito
Gate de validacion antes de iniciar ejecucion. Verificar alineacion con requerimientos y viabilidad del plan.
---
## Checklist
### Alineacion con Requerimientos
- [ ] Plan cubre todos los RF vinculados
- [ ] Plan cubre todos los criterios de las US
- [ ] No hay scope creep (alcance no autorizado)
- [ ] Cambios no contradicen documentacion existente
### Viabilidad Tecnica
- [ ] Codigo base esta en estado limpio (git status clean)
- [ ] Build actual pasa antes de iniciar
- [ ] No hay conflictos pendientes
- [ ] Ambiente de desarrollo funcional
### Validacion de Dependencias
- [ ] Tareas previas requeridas estan completadas
- [ ] Dependencias de codigo disponibles
- [ ] Si hay bloqueantes: resueltos o plan de resolucion
### Coherencia Documental
- [ ] Plan no contradice ADRs existentes
- [ ] Plan sigue estandares del proyecto
- [ ] Plan usa patrones establecidos
### Aprobacion
- [ ] Plan revisado (auto-revision o peer review)
- [ ] Riesgos aceptados
- [ ] Listo para ejecutar
---
## Criterios de Paso
**PASA** si:
- Plan alineado con RF/US
- Build actual pasa
- No hay bloqueantes activos
- Plan aprobado
**NO PASA** si:
- Desalineacion con requerimientos
- Build actual falla
- Bloqueantes sin resolver
- Plan contradice documentacion
---
## Siguiente Fase
Si PASA: Continuar a **Fase E: Ejecucion**
Si NO PASA: Ajustar plan o resolver bloqueantes
---
## Notas
Este es el ultimo gate antes de modificar codigo. Asegurarse de que todo esta listo.
---
## Referencias
- ADRs: `docs/97-adr/`
- Estandares: `docs/40-estandares/`

View File

@ -1,100 +0,0 @@
# Checklists por Fase CAPVED
**Version:** 1.0.0
**Actualizado:** 2026-01-18
## Proposito
Gates de validacion para cada fase del ciclo CAPVED.
## Archivos
| Checklist | Fase | Alias | Proposito |
|-----------|------|-------|-----------|
| CHECKLIST-FASE-C.md | Contexto | `@CHK-CONTEXTO` | Validar contextualizacion |
| CHECKLIST-FASE-A.md | Analisis | `@CHK-ANALISIS` | Validar analisis de impacto |
| CHECKLIST-FASE-P.md | Plan | `@CHK-PLAN` | Validar plan de ejecucion |
| CHECKLIST-FASE-V.md | Validacion | `@CHK-VALIDACION` | Gate pre-ejecucion |
| CHECKLIST-FASE-E.md | Ejecucion | `@CHK-EJECUCION` | Checkpoints CP1-CP4 |
| CHECKLIST-FASE-D.md | Documentacion | `@CHK-DOCUMENTACION` | Validar documentacion |
| CHECKLIST-CIERRE.md | Final | `@CHK-CIERRE`, `@DEF_CHK_POST` | Gate bloqueante final |
## Flujo de Validacion
```
Tarea iniciada
|
v
[CHECKLIST-FASE-C] ── NO PASA ──> Completar items faltantes
|
PASA
|
v
[CHECKLIST-FASE-A] ── NO PASA ──> Completar analisis
|
PASA
|
v
[CHECKLIST-FASE-P] ── NO PASA ──> Refinar plan
|
PASA
|
v
[CHECKLIST-FASE-V] ── NO PASA ──> Resolver bloqueantes
|
PASA
|
v
[CHECKLIST-FASE-E] ── CP FALLA ──> Resolver y re-ejecutar
(CP1-CP4)
|
TODOS PASAN
|
v
[CHECKLIST-FASE-D] ── NO PASA ──> Completar documentacion
|
PASA
|
v
[CHECKLIST-CIERRE] ── NO PASA ──> Completar items
|
PASA
|
v
TAREA COMPLETADA
```
## Checkpoints de Ejecucion (Fase E)
| Checkpoint | Cuando | Validaciones |
|------------|--------|--------------|
| CP1 | Post-Database | DDL, recreate-database |
| CP2 | Post-Backend | build, lint, test |
| CP3 | Post-Frontend | build, typecheck |
| CP4 | Final | Coherencia entre capas |
## Uso
### Durante ejecucion de tarea
1. Antes de pasar a siguiente fase, ejecutar checklist correspondiente
2. Si no pasa, resolver items faltantes
3. Solo avanzar cuando todos los items pasen
### Al finalizar tarea
1. Ejecutar CHECKLIST-CIERRE.md completo
2. **BLOQUEANTE**: No marcar tarea como completada sin pasar
3. Documentar cualquier excepcion con justificacion
## Integracion con Templates
Los checklists estan referenciados en:
- `METADATA.yml` - Campo `phases.{fase}.checklist`
- `SUBTASKS.yml` - Dentro de cada fase
## Referencias
- Template de tarea: `orchestration/tareas/_templates/TASK-TEMPLATE-UNIFIED/`
- Triggers: `orchestration/directivas/triggers/`
- Principio CAPVED: `orchestration/directivas/principios/PRINCIPIO-CAPVED.md`

View File

@ -1,287 +0,0 @@
# PRINCIPIO: ANTI-DUPLICACIÓN
**Versión:** 1.0.0
**Fecha:** 2025-12-08
**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA
**Aplica a:** TODOS los agentes sin excepción
---
## DECLARACIÓN DEL PRINCIPIO
```
╔══════════════════════════════════════════════════════════════════════╗
║ ║
║ ANTES DE CREAR, VERIFICAR QUE NO EXISTE ║
║ ║
║ "Un duplicado creado es tiempo perdido y confusión garantizada." ║
║ "2 minutos de verificación ahorran horas de corrección." ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝
```
---
## REGLA DE ORO
```
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ NUNCA crear un objeto (tabla, entity, componente, etc.) │
│ sin antes verificar que NO existe algo igual o similar. │
│ │
└─────────────────────────────────────────────────────────────────────┘
```
---
## PROCESO DE VERIFICACIÓN
### Paso 0: Consultar Catálogo de Funcionalidades (NUEVO - OBLIGATORIO)
```bash
# 🆕 PRIMERO: Verificar si existe funcionalidad en catálogo global
grep -i "{funcionalidad}" @CATALOG_INDEX
# Funcionalidades comunes ya catalogadas:
# - auth (login, registro, JWT)
# - session-management (sesiones, dispositivos)
# - rate-limiting (throttle, 429)
# - notifications (email, push)
# - multi-tenancy (tenant, RLS)
# - feature-flags (toggles)
# - websocket (realtime)
# - payments (stripe)
```
**Si encuentra en @CATALOG:**
```
✅ USAR CÓDIGO DEL CATÁLOGO
1. Ir a @CATALOG/{funcionalidad}/
2. Leer README.md (descripción y trade-offs)
3. Seguir IMPLEMENTATION.md (pasos)
4. Copiar _reference/ (código base)
5. Adaptar configuración al proyecto
Ver: @REUTILIZAR (SIMCO-REUTILIZAR.md)
```
### Paso 1: Consultar Inventario del Proyecto
```bash
# Buscar en inventario maestro
grep -i "{nombre}" @INVENTORY
# Buscar en inventario específico
grep -i "{nombre}" @INV_DB # Para database
grep -i "{nombre}" @INV_BE # Para backend
grep -i "{nombre}" @INV_FE # Para frontend
```
### Paso 2: Buscar en Código
```bash
# Buscar archivos con nombre similar
find apps/ -name "*{nombre}*" -type f
# Buscar definiciones en código
grep -rn "CREATE TABLE.*{nombre}" apps/
grep -rn "class {Nombre}" apps/
grep -rn "export.*{Nombre}" apps/
```
### Paso 3: Evaluar Resultado
| Resultado | Acción |
|-----------|--------|
| Existe en @CATALOG | ✅ REUTILIZAR del catálogo (ver @REUTILIZAR) |
| No encontrado | ✅ Proceder a crear |
| Encontrado idéntico | 🛑 DETENER - No crear, usar existente |
| Encontrado similar | ⚠️ PREGUNTAR - ¿Modificar existente o crear diferente? |
---
## QUÉ VERIFICAR POR TIPO
### Database (DDL)
```bash
# Verificar tabla
grep -rn "CREATE TABLE.*{nombre}" @DDL_ROOT
grep -i "{nombre}" @INV_DB
# Verificar schema
grep -rn "CREATE SCHEMA.*{nombre}" @DDL_ROOT
# Verificar función
grep -rn "CREATE.*FUNCTION.*{nombre}" @DDL_ROOT
```
### Backend (NestJS)
```bash
# Verificar entity
find @BACKEND -name "*{nombre}*.entity.ts"
grep -rn "class {Nombre}Entity" @BACKEND
# Verificar service
find @BACKEND -name "*{nombre}*.service.ts"
grep -rn "class {Nombre}Service" @BACKEND
# Verificar controller
find @BACKEND -name "*{nombre}*.controller.ts"
```
### Frontend (React)
```bash
# Verificar componente
find @FRONTEND -name "*{Nombre}*.tsx"
grep -rn "export.*{Nombre}" @FRONTEND_ROOT
# Verificar hook
find @FRONTEND -name "use{Nombre}*.ts"
# Verificar type
grep -rn "interface {Nombre}\|type {Nombre}" @FRONTEND_ROOT
```
---
## SI ENCUENTRAS DUPLICADO
### Duplicado Exacto
```markdown
🛑 DETENER INMEDIATAMENTE
El objeto `{nombre}` YA EXISTE:
- **Ubicación:** {ruta}
- **Inventario:** {línea en inventario}
- **Estado:** {estado}
**Acción:** Usar el existente, NO crear nuevo.
**Si necesitas modificarlo:**
Ver @MODIFICAR (SIMCO-MODIFICAR.md)
```
### Objeto Similar
```markdown
⚠️ OBJETO SIMILAR ENCONTRADO
Encontré `{nombre_similar}` que podría ser lo mismo:
- **Ubicación:** {ruta}
- **Propósito:** {descripción}
**Preguntas a resolver:**
1. ¿Es el mismo objeto con diferente nombre?
2. ¿Debo modificar el existente?
3. ¿Son diferentes y debo crear con otro nombre?
ESPERAR CLARIFICACIÓN antes de proceder.
```
---
## CONSECUENCIAS DE DUPLICAR
```
❌ Confusión sobre cuál usar
→ Diferentes partes del código usan diferentes versiones
❌ Mantenimiento duplicado
→ Cambios deben hacerse en múltiples lugares
❌ Bugs por inconsistencia
→ Un objeto se actualiza, el duplicado no
❌ Inventarios incorrectos
→ Estado del proyecto confuso
❌ Tiempo perdido
→ Trabajo que hay que deshacer
```
---
## PREVENCIÓN PROACTIVA
### Al Planificar
```markdown
ANTES de diseñar nuevo objeto:
1. [ ] Busqué en inventarios
2. [ ] Busqué en código
3. [ ] Confirmé que no existe
```
### Al Crear
```markdown
DURANTE creación de objeto:
1. [ ] Nombre no colisiona con existente
2. [ ] Ubicación es única
3. [ ] Propósito no está cubierto por otro objeto
```
### Al Completar
```markdown
DESPUÉS de crear:
1. [ ] Actualicé inventario
2. [ ] No hay advertencias de duplicados
```
---
## CASOS ESPECIALES
### ¿Qué pasa si necesito algo PARECIDO pero diferente?
```markdown
Ejemplo: Existe `UserEntity`, necesito `AdminUserEntity`
Verificar:
1. ¿Es una extensión? → Heredar/extender existente
2. ¿Es un caso especial? → Agregar campo al existente
3. ¿Es realmente diferente? → Crear nuevo con nombre claro
Nombrar claramente:
- ❌ `User2Entity` (confuso)
- ✅ `AdminUserEntity` (claro y diferenciado)
```
### ¿Qué pasa si el existente está mal?
```markdown
Si el objeto existente tiene problemas:
1. Documentar los problemas
2. Decidir: ¿Corregir existente o reemplazar?
3. Si reemplazar: eliminar viejo completamente
4. NUNCA tener ambos coexistiendo
```
---
## CHECKLIST RÁPIDO
```
Antes de crear CUALQUIER objeto:
[ ] 🆕 Busqué funcionalidad en @CATALOG_INDEX (PRIMERO)
[ ] Busqué "{nombre}" en @INVENTORY
[ ] Busqué archivos con find
[ ] Busqué definiciones con grep
[ ] Confirmé que NO existe en catálogo NI en proyecto
[ ] Si existe en catálogo, seguí @REUTILIZAR
[ ] Si existe similar, pregunté qué hacer
```
---
## REFERENCIAS SIMCO
- **@CATALOG** - Catálogo de funcionalidades reutilizables (CONSULTAR PRIMERO)
- **@REUTILIZAR** - Proceso para reutilizar del catálogo
- **@CREAR** - Proceso completo de creación (incluye verificación)
- **@BUSCAR** - Estrategias de búsqueda
- **@DOCUMENTAR** - Actualización de inventarios
---
**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.**
---
**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental

View File

@ -1,384 +0,0 @@
---
tipo: ssot-normativo
nivel: 3-completo
es_ssot: true
versiones_derivadas:
- docs/30-directivas/CICLO-CAPVED.md (nivel 1 - resumen usuario)
- orchestration/_definitions/protocols/CAPVED-CYCLE.md (nivel 2 - tecnico)
actualizado: 2026-01-16
---
# PRINCIPIO: CAPVED - Ciclo de Vida de Tareas
**Versión:** 1.0.0
**Fecha:** 2025-12-08
**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA - **SSOT**
**Aplica a:** TODOS los agentes sin excepción
**Alias:** @CAPVED
---
## DECLARACIÓN DEL PRINCIPIO
```
╔══════════════════════════════════════════════════════════════════════════════╗
║ ║
║ CAPVED: Contexto → Análisis → Planeación → Validación → Ejecución → Doc ║
║ ║
║ "Toda tarea que modifica código o documentación DEBE pasar por ║
║ el ciclo completo CAPVED antes de considerarse Done." ║
║ ║
║ "Si aparece trabajo fuera del alcance original, se genera HU nueva." ║
║ ║
╚══════════════════════════════════════════════════════════════════════════════╝
```
---
## QUÉ ES CAPVED
CAPVED es un **ciclo de vida obligatorio** para toda Historia de Usuario (HU) o tarea técnica que involucre modificación de código o documentación. Garantiza:
1. **Trazabilidad completa**: Desde el origen hasta la implementación
2. **Análisis de impacto**: Antes de tocar código
3. **Validación de coherencia**: Plan vs Análisis
4. **Generación controlada**: HUs derivadas para descubrimientos
5. **Documentación actualizada**: Como criterio de Done
---
## LAS 6 FASES DE CAPVED
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ C - CONTEXTO │
│ • Vincular HU a proyecto/módulo/epic │
│ • Clasificar tipo: feature | fix | refactor | spike | doc-only │
│ • Registrar origen: plan-original | descubrimiento | incidencia │
│ • Cargar documentos SIMCO relevantes │
├─────────────────────────────────────────────────────────────────────────────┤
│ ↓ │
├─────────────────────────────────────────────────────────────────────────────┤
│ A - ANÁLISIS │
│ • Comportamiento deseado (perspectiva de negocio) │
│ • Restricciones: seguridad, performance, UX │
│ • Objetos impactados: BD, Backend, Frontend, otros proyectos │
│ • Dependencias con otras HUs (bloquea/bloqueada por) │
│ • Riesgos identificados │
│ → SALIDA: Lista de objetos + dependencias + riesgos │
├─────────────────────────────────────────────────────────────────────────────┤
│ ↓ │
├─────────────────────────────────────────────────────────────────────────────┤
│ P - PLANEACIÓN │
│ • Desglose en subtareas por dominio (BD, BE, FE, Docs) │
│ • Orden de ejecución y dependencias │
│ • Criterios de aceptación por subtarea │
│ • Plan de pruebas: unitarias, integración, regresión │
│ • Asignación de agentes/subagentes │
│ → SALIDA: Plan de ejecución con subtareas asignadas │
├─────────────────────────────────────────────────────────────────────────────┤
│ ↓ │
├─────────────────────────────────────────────────────────────────────────────┤
│ V - VALIDACIÓN (⚠️ NO DELEGAR - EJECUTAR DIRECTAMENTE) │
│ • ¿Todo lo detectado en A tiene acción concreta en P? │
│ • ¿Hay dependencias ocultas sin atender? │
│ • ¿Criterios de aceptación cubren los riesgos? │
│ • ¿Hay scope creep? → Registrar y crear HU derivada │
│ → GATE: Solo pasa a Ejecución si todo cuadra │
├─────────────────────────────────────────────────────────────────────────────┤
│ ↓ │
├─────────────────────────────────────────────────────────────────────────────┤
│ E - EJECUCIÓN │
│ • Actualizar docs/ del proyecto PRIMERO │
│ • Ejecutar subtareas en orden establecido │
│ • Cada subtarea: código + notas + validación (build/lint) │
│ • Registrar progreso y desviaciones │
│ → USAR: SIMCO correspondientes (CREAR, MODIFICAR, DDL, etc.) │
├─────────────────────────────────────────────────────────────────────────────┤
│ ↓ │
├─────────────────────────────────────────────────────────────────────────────┤
│ D - DOCUMENTACIÓN CONTINUA │
│ • Actualizar diagramas y modelos de dominio │
│ • Actualizar especificaciones técnicas (BD, APIs, contratos) │
│ • Crear/actualizar ADRs si hubo decisiones arquitectónicas │
│ • Actualizar inventarios (DATABASE, BACKEND, FRONTEND) │
│ • Actualizar trazas de tareas │
│ • Registrar HUs derivadas (si se generaron) │
│ • Registrar lecciones aprendidas │
│ → GATE: HU NO está Done si documentación no está actualizada │
└─────────────────────────────────────────────────────────────────────────────┘
```
---
## CUÁNDO APLICA CAPVED
### APLICA A (Obligatorio):
```yaml
Tareas_que_DEBEN_seguir_CAPVED:
- Nuevas features (cualquier tamaño)
- Bug fixes que modifican código
- Refactorizaciones
- Cambios en estructura de BD
- Nuevos endpoints de API
- Nuevos componentes de UI
- Cambios en lógica de negocio
- Integraciones con sistemas externos
- Cualquier tarea que genere commit
```
### NO APLICA A (Excepciones):
```yaml
Tareas_exentas_de_CAPVED_completo:
- Corrección de typos en código (solo E+D)
- Actualización de dependencias menores (solo E+D)
- Tareas puramente exploratorias (solo lectura)
- Consultas de información
- Spikes de investigación sin implementación
NOTA: Incluso las excepciones DEBEN documentar en trazas
```
---
## INTEGRACIÓN CON SIMCO
CAPVED es el **ciclo de vida**, SIMCO son las **operaciones**:
```
CAPVED SIMCO
─────── ─────
C - Contexto → SIMCO-INICIALIZACION.md (CCA)
A - Análisis → SIMCO-BUSCAR.md + docs/
P - Planeación → TEMPLATE-PLAN.md
V - Validación → Checklist CAPVED (este documento)
E - Ejecución → SIMCO-CREAR/MODIFICAR/DDL/BACKEND/FRONTEND
D - Documentación → SIMCO-DOCUMENTAR.md + inventarios + trazas
```
### Orden de Lectura para Agentes:
```yaml
1. SIMCO-INICIALIZACION.md # Bootstrap con CCA
2. PRINCIPIO-CAPVED.md # Este documento (ciclo obligatorio)
3. PRINCIPIO-DOC-PRIMERO.md # Documentación antes de código
4. PRINCIPIO-ANTI-DUPLICACION.md # Verificar antes de crear
5. PRINCIPIO-VALIDACION-OBLIGATORIA.md # Build/lint obligatorios
6. SIMCO-TAREA.md # Proceso detallado CAPVED
7. SIMCO específicos según operación
```
---
## GENERACIÓN DE HUs DERIVADAS
### Cuándo Generar HU Nueva:
```yaml
Generar_HU_derivada_cuando:
# Durante Análisis (A)
- Se detecta bug estructural no relacionado al objetivo
- Se identifica deuda técnica que bloquea
- Se descubre dependencia no documentada
# Durante Validación (V)
- Hay trabajo detectado fuera del alcance original
- Se requiere refactor previo no planificado
- Se identifica mejora de UX no solicitada
# Durante Ejecución (E)
- Se encuentra código legacy que debe corregirse
- Se descubre inconsistencia en otra parte del sistema
- Se identifica oportunidad de optimización
```
### Proceso de Generación:
```markdown
1. DETECTAR: Identificar que algo está fuera del alcance
2. REGISTRAR: Documentar en la sección "HUs Derivadas" de la HU actual
3. CREAR: Generar archivo de HU con prefijo DERIVED-{HU-ORIGEN}-{N}
4. VINCULAR: Referenciar la HU origen en la nueva HU
5. PRIORIZAR: Marcar como pendiente para siguiente planificación
6. CONTINUAR: Seguir con la HU original sin desviarse
```
### Template de Registro:
```yaml
HUs_Derivadas:
- id: "DERIVED-HU-001-001"
origen: "HU-001"
tipo: "bug | feature | refactor | deuda-tecnica"
descripcion: "Descripción breve de lo detectado"
detectado_en_fase: "A | V | E"
prioridad_sugerida: "P0 | P1 | P2 | P3"
notas: "Contexto adicional relevante"
```
---
## CHECKLIST RÁPIDO CAPVED
### Antes de Iniciar (C):
```
[ ] HU vinculada a proyecto/módulo/epic
[ ] Tipo clasificado (feature/fix/refactor/spike/doc-only)
[ ] Origen registrado (plan/descubrimiento/incidencia)
[ ] Documentos SIMCO relevantes identificados
```
### Antes de Planificar (A completado):
```
[ ] Comportamiento de negocio entendido
[ ] Objetos impactados listados (todas las capas)
[ ] Dependencias identificadas
[ ] Riesgos documentados
```
### Antes de Ejecutar (P+V completados):
```
[ ] Subtareas definidas por dominio
[ ] Orden de ejecución establecido
[ ] Criterios de aceptación definidos
[ ] Plan vs Análisis validado (todo cubierto)
[ ] Scope creep registrado (si existe)
[ ] HUs derivadas creadas (si aplica)
```
### Durante Ejecución (E):
```
[ ] docs/ actualizado PRIMERO
[ ] Subtareas ejecutadas en orden
[ ] Build/lint pasa por subtarea
[ ] Progreso registrado
```
### Antes de Cerrar (D):
```
[ ] Diagramas/modelos actualizados
[ ] Specs técnicas actualizadas
[ ] ADRs creados (si decisión arquitectónica)
[ ] Inventarios actualizados
[ ] Trazas actualizadas
[ ] HUs derivadas vinculadas
[ ] Lecciones aprendidas registradas
```
### GATE DE CIERRE (OBLIGATORIO - @DEF_CHK_POST)
> **ANTES de declarar una HU/tarea como DONE, ejecutar @DEF_CHK_POST**
```markdown
## Checklist de Cierre Obligatorio
### Gobernanza (BLOQUEANTE)
[ ] Carpeta de tarea existe: orchestration/tareas/TASK-{ID}/
[ ] METADATA.yml completo con fases C, E, D
[ ] _INDEX.yml de tareas actualizado
### Validaciones Técnicas
[ ] Build pasa (backend y/o frontend)
[ ] Lint pasa
[ ] Tests pasan (si existen)
### Coherencia Entre Capas
[ ] DDL ↔ Backend verificado
[ ] Backend ↔ Frontend verificado (si aplica)
### Inventarios
[ ] DATABASE_INVENTORY.yml (si cambió BD)
[ ] BACKEND_INVENTORY.yml (si cambió BE)
[ ] FRONTEND_INVENTORY.yml (si cambió FE)
[ ] MASTER_INVENTORY.yml actualizado
### Trazas
[ ] Traza de tarea correspondiente actualizada
[ ] PROXIMA-ACCION.md actualizado
### Propagación
[ ] Evaluado si aplica a otros proyectos
```
**SI FALLA CUALQUIER ITEM BLOQUEANTE:** HU permanece EN PROGRESO.
**REFERENCIA:** `@TRIGGER_CIERRE` - orchestration/directivas/triggers/TRIGGER-CIERRE-TAREA-OBLIGATORIO.md
---
## CONSECUENCIAS DE IGNORAR CAPVED
```
❌ Saltar Contexto (C)
→ HU sin trazabilidad, trabajo desconectado del plan
❌ Saltar Análisis (A)
→ Impacto no previsto, bugs en otras partes del sistema
❌ Saltar Planeación (P)
→ Ejecución caótica, trabajo rehecho, tiempo perdido
❌ Saltar Validación (V)
→ Scope creep no controlado, trabajo infinito
❌ Saltar Documentación (D)
→ Sistema diverge de docs/, confusión futura, onboarding difícil
```
---
## LECCIONES APRENDIDAS
### Registro Obligatorio:
Al cerrar cada HU, registrar:
```yaml
Lecciones_Aprendidas:
que_funciono_bien:
- "Descripción de práctica exitosa"
que_se_puede_mejorar:
- "Descripción de área de mejora"
para_futuras_HUs_similares:
- "Recomendación específica para HUs del mismo tipo"
```
### Ubicación:
- En el archivo de la HU (sección final)
- Consolidar mensualmente en `orchestration/retrospectivas/`
---
## REFERENCIAS SIMCO
| Fase CAPVED | SIMCO Relacionados |
|-------------|-------------------|
| C - Contexto | `SIMCO-INICIALIZACION.md`, `CONTEXTO-PROYECTO.md` |
| A - Análisis | `SIMCO-BUSCAR.md`, `TEMPLATE-ANALISIS.md` |
| P - Planeación | `TEMPLATE-PLAN.md`, `SIMCO-DELEGACION.md` |
| V - Validación | `TEMPLATE-VALIDACION.md` |
| E - Ejecución | `SIMCO-CREAR.md`, `SIMCO-MODIFICAR.md`, `SIMCO-DDL.md`, etc. |
| D - Documentación | `SIMCO-DOCUMENTAR.md`, inventarios, trazas |
---
## ALIAS
```yaml
@CAPVED: core/orchestration/directivas/principios/PRINCIPIO-CAPVED.md
@TAREA: core/orchestration/directivas/simco/SIMCO-TAREA.md
@TPL_CAPVED: core/orchestration/templates/TEMPLATE-TAREA-CAPVED.md
```
---
**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.**
---
**Versión:** 1.0.0 | **Sistema:** SIMCO + CAPVED | **Tipo:** Principio Fundamental

View File

@ -1,190 +0,0 @@
# PRINCIPIO: DOCUMENTACIÓN PRIMERO
**Versión:** 1.0.0
**Fecha:** 2025-12-08
**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA
**Aplica a:** TODOS los agentes sin excepción
---
## DECLARACIÓN DEL PRINCIPIO
```
╔══════════════════════════════════════════════════════════════════════╗
║ ║
║ DOCUMENTACIÓN PRIMERO, IMPLEMENTACIÓN DESPUÉS ║
║ ║
║ "Si no está documentado, no existe." ║
║ "Si contradice la documentación, está mal." ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝
```
---
## REGLA EN 3 PASOS
```
PASO 1: ANTES DE IMPLEMENTAR
─────────────────────────────
Consultar docs/ para entender:
- ¿Qué dice la documentación sobre esto?
- ¿Hay especificaciones o diseños?
- ¿Hay ADRs relacionados?
PASO 2: SI HAY CAMBIO DE DISEÑO
─────────────────────────────
Actualizar docs/ PRIMERO:
- Documentar el nuevo diseño
- Crear ADR si es decisión arquitectónica
- Actualizar especificaciones
PASO 3: IMPLEMENTAR
─────────────────────────────
Solo entonces escribir código:
- Seguir lo documentado
- Referenciar docs/ en comentarios si aplica
```
---
## FLUJO VISUAL
```
┌─────────────────────┐
│ TAREA NUEVA │
└──────────┬──────────┘
┌─────────────────────┐
│ ¿Consulté docs/? │──── NO ────► CONSULTAR DOCS/ PRIMERO
└──────────┬──────────┘
│ SÍ
┌─────────────────────┐
│ ¿Hay contradicción? │──── SÍ ────► ACTUALIZAR DOCS/ PRIMERO
└──────────┬──────────┘
│ NO
┌─────────────────────┐
│ ¿Falta documentar? │──── SÍ ────► DOCUMENTAR PRIMERO
└──────────┬──────────┘
│ NO
┌─────────────────────┐
│ IMPLEMENTAR │
└─────────────────────┘
```
---
## DOCUMENTACIÓN A CONSULTAR
### Antes de CUALQUIER tarea:
```yaml
Obligatorio:
- docs/00-vision-general/ # Visión y alcance
- docs/95-guias-desarrollo/ # Estándares y convenciones
- docs/97-adr/ # Decisiones arquitectónicas
Si aplica:
- docs/01-fase-*/ # Especificaciones por fase
- docs/modulos/{modulo}/ # Especificaciones del módulo
- orchestration/inventarios/ # Estado actual del proyecto
```
### Para cada tipo de tarea:
```yaml
Database:
- @GUIAS/database/ (si existe)
- @ADR (decisiones de BD)
Backend:
- @GUIAS_BE/DTO-CONVENTIONS.md
- @GUIAS_BE/API-CONVENTIONS.md
- @ADR
Frontend:
- @GUIAS_FE/TYPES-CONVENTIONS.md
- @GUIAS_FE/COMPONENT-PATTERNS.md
- @ADR
```
---
## CUÁNDO ACTUALIZAR DOCS/ PRIMERO
| Situación | Acción |
|-----------|--------|
| Nueva feature no documentada | Documentar diseño antes de implementar |
| Cambio de arquitectura | Crear ADR antes de implementar |
| Contradicción docs/ vs realidad | Actualizar docs/ (si realidad es correcta) |
| Nueva convención | Documentar en guías antes de usar |
| Nuevo módulo/schema | Documentar estructura antes de crear |
---
## CUÁNDO NO APLICA
```yaml
Excepciones (no requiere actualizar docs/ primero):
- Bug fixes menores (solo corrección, no cambio de diseño)
- Refactors internos (misma funcionalidad)
- Actualizaciones de dependencias
- Corrección de typos en código
PERO siempre aplica:
- Consultar docs/ para entender el contexto
- Documentar en traza lo realizado
- Actualizar inventarios si hay cambios estructurales
```
---
## CONSECUENCIAS DE IGNORAR ESTE PRINCIPIO
```
❌ Código que contradice documentación
→ Confusión, bugs, deuda técnica
❌ Features no documentadas
→ Nadie sabe qué hace ni por qué
❌ Implementar sin consultar docs/
→ Duplicados, inconsistencias, trabajo rehecho
❌ Cambiar arquitectura sin ADR
→ Decisiones perdidas, errores repetidos
```
---
## CHECKLIST RÁPIDO
```
Antes de escribir código:
[ ] Consulté docs/ relevantes
[ ] No hay contradicción con lo documentado
[ ] Si hay cambio de diseño, actualicé docs/ primero
Al terminar:
[ ] Código sigue lo documentado
[ ] Actualicé inventarios
[ ] Documenté en traza
```
---
## REFERENCIAS SIMCO
- **@DOCUMENTAR** - Cómo documentar correctamente
- **@VALIDAR** - Validación de coherencia docs/código
- **@BUSCAR** - Cómo encontrar documentación
---
**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.**
---
**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental

View File

@ -1,292 +0,0 @@
# PRINCIPIO: ECONOMÍA DE TOKENS
**Versión:** 1.0.0
**Fecha:** 2025-12-08
**Aplica a:** Todos los agentes
**Prioridad:** OBLIGATORIA para evitar errores de context overflow
---
## RESUMEN EJECUTIVO
> **Los agentes tienen límites de tokens. Excederlos = fallo de tarea.**
> Planificar con economía de tokens = tareas exitosas.
> Tareas grandes sin desglose = error garantizado.
---
## LÍMITES CRÍTICOS
```yaml
CONTEXTO_MAXIMO:
entrada: ~200,000 tokens # Lo que el agente puede "ver"
salida: ~8,000 tokens # Lo que puede generar por respuesta
recomendado_carga: <50,000 tokens # Para dejar espacio de trabajo
ARCHIVO_INDIVIDUAL:
maximo_recomendado: 500 líneas (~2,000 tokens)
ideal: 200-300 líneas (~1,000 tokens)
alerta: >400 líneas → considerar división
PROMPT_DELEGACION:
maximo: 3,000 tokens (~750 líneas de prompt)
recomendado: 1,500 tokens (~375 líneas)
minimo_efectivo: 500 tokens (~125 líneas)
```
---
## REGLAS DE ECONOMÍA
### Regla 1: Cargar Solo Lo Necesario
```yaml
MAL:
- Cargar TODOS los archivos del proyecto
- Leer archivos completos cuando solo necesitas una sección
- Incluir documentación extendida en prompts de delegación
BIEN:
- Cargar SOLO archivos relevantes para la tarea actual
- Usar SIMCO-QUICK-REFERENCE.md en lugar de _INDEX.md completo
- Referencias a archivos en vez de copiar contenido
```
### Regla 2: Desglosar Tareas Grandes
```yaml
TAREA_GRANDE (>2000 tokens de output esperado):
- Dividir en subtareas independientes
- Cada subtarea = máximo 1 archivo o 1 función
- Secuenciar: crear → validar → siguiente
EJEMPLO_MALO:
"Crear el módulo completo de usuarios con entity, service,
controller, DTOs, tests, y documentación"
# Esto generará >8000 tokens de salida = ERROR
EJEMPLO_BUENO:
ST-001: Crear UserEntity alineada con DDL
ST-002: Crear CreateUserDto y UpdateUserDto
ST-003: Crear UserService con CRUD básico
ST-004: Crear UserController con endpoints
ST-005: Ejecutar build + lint
# Cada una <2000 tokens = ÉXITO
```
### Regla 3: Prompts de Delegación Concisos
```yaml
INCLUIR:
- Contexto mínimo necesario (nivel, variables críticas)
- Tarea específica (1 cosa)
- Criterios de aceptación (checklist corto)
- 1-2 archivos de referencia máximo
NO INCLUIR:
- Historia completa del proyecto
- Documentación extendida
- Múltiples opciones/alternativas
- Código de ejemplo extenso (>50 líneas)
```
---
## ESTRATEGIAS DE DESGLOSE
### Por Capa (Vertical)
```yaml
# En lugar de: "Crear feature de notificaciones"
# Desglosar en:
ST-001_DATABASE:
tarea: "Crear tabla notifications.notifications"
output_esperado: ~300 tokens (1 archivo DDL)
ST-002_BACKEND_ENTITY:
tarea: "Crear NotificationEntity"
output_esperado: ~200 tokens (1 archivo)
ST-003_BACKEND_DTO:
tarea: "Crear DTOs de Notification"
output_esperado: ~300 tokens (2 archivos pequeños)
ST-004_BACKEND_SERVICE:
tarea: "Crear NotificationService con CRUD"
output_esperado: ~400 tokens (1 archivo)
ST-005_BACKEND_CONTROLLER:
tarea: "Crear NotificationController con endpoints"
output_esperado: ~350 tokens (1 archivo)
ST-006_VALIDACION:
tarea: "Ejecutar build + lint backend"
output_esperado: ~100 tokens (comandos)
```
### Por Funcionalidad (Horizontal)
```yaml
# En lugar de: "Implementar autenticación"
# Desglosar en:
ST-001: Verificar @CATALOG (¿existe auth?)
ST-002: Si existe → usar SIMCO-REUTILIZAR
ST-003: Si no existe → crear esquema auth (DDL)
ST-004: Crear AuthModule básico (register/login)
ST-005: Crear JWT strategy
ST-006: Crear guards
ST-007: Integrar en app.module
ST-008: Validar build + lint
```
---
## ESTIMACIÓN DE TOKENS
### Fórmula Rápida
```
tokens ≈ caracteres / 4
tokens ≈ palabras * 1.3
tokens ≈ líneas * 10 (código promedio)
```
### Tabla de Referencia
| Tipo de Archivo | Líneas Típicas | Tokens Estimados |
|-----------------|----------------|------------------|
| Entity simple | 30-50 | 300-500 |
| Entity con relaciones | 80-120 | 800-1200 |
| DTO | 20-40 | 200-400 |
| Service CRUD | 100-150 | 1000-1500 |
| Controller REST | 80-120 | 800-1200 |
| Tabla DDL | 30-60 | 300-600 |
| Componente React simple | 50-80 | 500-800 |
| Componente React complejo | 150-250 | 1500-2500 |
| Hook | 30-60 | 300-600 |
---
## DETECCIÓN DE PROBLEMAS
### Señales de Alerta
```yaml
ANTES_DE_EJECUTAR:
- [ ] ¿La tarea pide crear >3 archivos? → Desglosar
- [ ] ¿El prompt de delegación >1500 tokens? → Reducir
- [ ] ¿Se pide "módulo completo"? → Desglosar por componente
- [ ] ¿Se incluye código de referencia >50 líneas? → Usar referencia a archivo
DURANTE_EJECUCION:
- [ ] ¿Respuesta truncada? → Tarea muy grande
- [ ] ¿Error de context? → Demasiados archivos cargados
- [ ] ¿Alucinaciones? → Contexto insuficiente o confuso
```
### Acciones Correctivas
```yaml
SI_RESPUESTA_TRUNCADA:
1. Dividir tarea en 2-3 subtareas
2. Re-ejecutar cada subtarea por separado
3. Validar entre subtareas
SI_ERROR_CONTEXT:
1. Descargar archivos no esenciales
2. Usar SIMCO-QUICK-REFERENCE en lugar de _INDEX completo
3. Referencias en lugar de contenido inline
SI_ALUCINACIONES:
1. Verificar que archivos de referencia se cargaron
2. Incluir más contexto específico (menos genérico)
3. Ser más explícito en criterios de aceptación
```
---
## TEMPLATE DE DELEGACIÓN OPTIMIZADO
```yaml
# PROMPT OPTIMIZADO (~800 tokens)
## SUBAGENTE: {Tipo}
Nivel: {nivel} | Proyecto: {proyecto} | Ruta: {orchestration_path}
## TAREA ÚNICA
{Descripción en 1-2 oraciones}
## ESPECIFICACIÓN
{Solo lo necesario, máximo 10 líneas}
## REFERENCIA
- Archivo: `{ruta exacta}` (copiar patrón de líneas X-Y)
## CRITERIOS (máximo 5)
- [ ] {criterio 1}
- [ ] {criterio 2}
- [ ] {criterio 3}
## VALIDACIÓN
```bash
{1-2 comandos}
```
## ENTREGABLES
1. {archivo a crear/modificar}
```
---
## INTEGRACIÓN CON CAPVED
### Fase P (Planeación) - Verificar Tokens
```yaml
ANTES_DE_APROBAR_PLAN:
- [ ] Cada subtarea genera <2000 tokens de output
- [ ] Cada prompt de delegación <1500 tokens
- [ ] No hay subtareas que pidan "módulo completo"
- [ ] Subtareas son independientes (pueden fallar sin afectar otras)
```
### Fase E (Ejecución) - Monitorear
```yaml
DURANTE_EJECUCION:
- Si subtarea falla por tokens → subdividir más
- Si contexto insuficiente → cargar archivo específico
- Si respuesta truncada → dividir y reintentar
```
---
## MÉTRICAS DE ÉXITO
```yaml
TAREA_BIEN_DESGLOSADA:
- 0 errores de token overflow
- 0 respuestas truncadas
- Cada subtarea completa en 1 iteración
- Build pasa después de cada subtarea
DELEGACION_OPTIMA:
- Prompt <1500 tokens
- Respuesta completa sin truncar
- Criterios verificables cumplidos
- Sin re-trabajo por malentendidos
```
---
## REFERENCIAS
- **Referencia rápida:** `SIMCO-QUICK-REFERENCE.md`
- **Delegación:** `SIMCO-DELEGACION.md`
- **Desglose de tareas:** `SIMCO-TAREA.md`
---
**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental

View File

@ -1,361 +0,0 @@
# 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

View File

@ -1,248 +0,0 @@
# PRINCIPIO: VALIDACIÓN OBLIGATORIA
**Versión:** 1.0.0
**Fecha:** 2025-12-08
**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA
**Aplica a:** TODOS los agentes sin excepción
---
## DECLARACIÓN DEL PRINCIPIO
```
╔══════════════════════════════════════════════════════════════════════╗
║ ║
║ BUILD PASA + LINT PASA = REQUISITO MÍNIMO ║
║ ║
║ "Código que no compila NO está terminado." ║
║ "Tarea con errores NO está completada." ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝
```
---
## REGLA INQUEBRANTABLE
```
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ NINGUNA tarea se marca como COMPLETADA si: │
│ │
│ • Build falla │
│ • Lint tiene errores críticos │
│ • Carga limpia falla (para DDL) │
│ • Tests fallan (si existen) │
│ │
└─────────────────────────────────────────────────────────────────────┘
```
---
## VALIDACIONES POR CAPA
### Database (DDL)
```bash
# OBLIGATORIO
cd @DB_SCRIPTS
./{RECREATE_CMD} # Carga limpia DEBE pasar
# Verificación
psql -d {DB_NAME} -c "\dt {schema}.*" # Tablas creadas
psql -d {DB_NAME} -c "\di {schema}.*" # Índices creados
```
### Backend (NestJS)
```bash
# OBLIGATORIO
cd @BACKEND_ROOT
npm run build # DEBE pasar
npm run lint # DEBE pasar
# Adicional
npm run test # Si hay tests, DEBEN pasar
npm run start:dev # DEBE iniciar sin errores
```
### Frontend (React)
```bash
# OBLIGATORIO
cd @FRONTEND_ROOT
npm run build # DEBE pasar
npm run lint # DEBE pasar
# Adicional
npm run typecheck # DEBE pasar
npm run dev # DEBE iniciar sin errores
```
---
## FLUJO DE VALIDACIÓN
```
TERMINAR IMPLEMENTACIÓN
┌─────────────────────┐
│ EJECUTAR BUILD │
└──────────┬──────────┘
┌─────────────────────┐ ┌─────────────────────┐
│ ¿BUILD PASA? │──NO──►│ CORREGIR ERRORES │
└──────────┬──────────┘ └──────────┬──────────┘
│ SÍ │
│◄────────────────────────────┘
┌─────────────────────┐ ┌─────────────────────┐
│ EJECUTAR LINT │──NO──►│ CORREGIR ERRORES │
│ ¿LINT PASA? │ └──────────┬──────────┘
└──────────┬──────────┘ │
│ SÍ │
│◄────────────────────────────┘
┌─────────────────────┐ ┌─────────────────────┐
│ EJECUTAR TESTS │──NO──►│ CORREGIR TESTS │
│ ¿TESTS PASAN? │ └──────────┬──────────┘
└──────────┬──────────┘ │
│ SÍ │
│◄────────────────────────────┘
┌─────────────────────┐
│ ✅ TAREA COMPLETA │
└─────────────────────┘
```
---
## QUÉ HACER CUANDO FALLA
### Build Falla
```markdown
1. NO marcar tarea como completada
2. Leer el error completo
3. Identificar archivo y línea
4. Corregir el error
5. Volver a ejecutar build
6. Repetir hasta que pase
```
### Lint Falla (Errores)
```markdown
1. NO marcar tarea como completada
2. Distinguir errores de warnings
- Errores (error): DEBEN corregirse
- Warnings (warn): Pueden ignorarse (pero mejor corregir)
3. Corregir todos los errores
4. Volver a ejecutar lint
5. Repetir hasta que pase
```
### Carga Limpia Falla (DDL)
```markdown
1. NO marcar tarea como completada
2. NO ejecutar fix manual en BD
3. Leer el error de PostgreSQL
4. Corregir archivo DDL
5. Volver a ejecutar carga limpia completa
6. Repetir hasta que pase
```
### Tests Fallan
```markdown
1. NO marcar tarea como completada
2. Identificar test que falla
3. Determinar si:
a. El código tiene bug → Corregir código
b. El test está desactualizado → Actualizar test
4. Volver a ejecutar tests
5. Repetir hasta que pasen
```
---
## EXCEPCIONES (MUY LIMITADAS)
```yaml
Puede marcarse completa SIN tests:
- Si no existen tests para el módulo (pero build y lint DEBEN pasar)
- Se documenta: "Tests pendientes de crear"
Puede tener warnings de lint:
- Si son warnings menores (no errores)
- Se documenta: "N warnings de lint pendientes"
NUNCA puede marcarse completa:
- Con build fallando
- Con errores de lint
- Con carga limpia fallando
```
---
## REPORTE DE VALIDACIÓN
En toda entrega incluir:
```markdown
## Validaciones
| Validación | Comando | Resultado |
|------------|---------|-----------|
| Build | `npm run build` | ✅ Pasa / ❌ Falla |
| Lint | `npm run lint` | ✅ Pasa / ⚠️ Warnings / ❌ Errores |
| Tests | `npm run test` | ✅ Pasa / ❌ Falla / ⏭️ N/A |
| Carga Limpia | `./{RECREATE_CMD}` | ✅ Pasa / ❌ Falla / ⏭️ N/A |
**Estado:** ✅ Validaciones completas / ❌ Pendiente corrección
```
---
## CONSECUENCIAS DE IGNORAR
```
❌ Código que no compila entregado
→ Bloquea a otros agentes/desarrolladores
❌ Errores de lint ignorados
→ Código inconsistente, bugs potenciales
❌ Tests fallando ignorados
→ Regresiones, bugs en producción
❌ DDL con errores
→ BD inconsistente, datos corruptos
```
---
## CHECKLIST RÁPIDO
```
Antes de marcar CUALQUIER tarea como completada:
[ ] Build pasa sin errores
[ ] Lint pasa sin errores (warnings OK)
[ ] Tests pasan (si existen)
[ ] Carga limpia pasa (si es DDL)
[ ] Aplicación inicia correctamente
```
---
## REFERENCIAS SIMCO
- **@VALIDAR** - Proceso completo de validación
- **@OP_DDL** - Validación específica de database
- **@OP_BACKEND** - Validación específica de backend
- **@OP_FRONTEND** - Validación específica de frontend
---
**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.**
---
**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental

View File

@ -1,316 +0,0 @@
# PROPAGACION-ARCHITECTURE: Arquitectura de Propagacion del Workspace
**ID:** PROPAGACION-ARCHITECTURE
**Version:** 1.0.0
**Fecha:** 2026-01-13
**Autor:** CLAUDE-CAPVED
---
## Proposito
Este documento clarifica la arquitectura de propagacion del workspace, cuando usar cada mecanismo, y como se relacionan los diferentes componentes del sistema de propagacion.
---
## Jerarquia de Propagacion
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ NIVELES DE PROPAGACION │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ NIVEL 0: PROVIDER │
│ ┌──────────────────┐ │
│ │ template-saas │ → Provee funcionalidades base a todos │
│ │ (v1.2.1) │ │
│ └────────┬─────────┘ │
│ │ │
│ ▼ │
│ NIVEL 1: INTERMEDIATE │
│ ┌──────────────────┐ │
│ │ erp-core │ → Extiende y adapta para verticales ERP │
│ │ (v1.3.0) │ │
│ └────────┬─────────┘ │
│ │ │
│ ├─────────────────────────────────────────────────┐ │
│ ▼ ▼ │
│ NIVEL 2: CONSUMERS NIVEL 2: INTERMEDIATE │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ erp-construccion │ │ erp-clinicas │ │
│ │ erp-mecanicas │ │ (v1.0.0) │ │
│ │ erp-retail │ └────────┬─────────┘ │
│ │ erp-vidrio │ │ │
│ └──────────────────┘ ▼ │
│ NIVEL 3: SUB-CONSUMERS │
│ ┌──────────────────┐ │
│ │ clinica-dental │ │
│ │ clinica-veterina │ │
│ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
---
## Componentes del Sistema de Propagacion
### 1. Directivas
| Componente | Ubicacion | Proposito |
|------------|-----------|-----------|
| **MODE-PROPAGATION** | `directivas/modos/` | Modo de ejecucion para propagar cambios entre proyectos |
| **TRIGGER-PROPAGACION-AUTOMATICA** | `directivas/triggers/` | Activa automaticamente en Fase D para evaluar propagacion |
| **SIMCO-PROPAGACION** | `directivas/simco/` | Propagacion de documentacion en verticales (interno) |
### 2. Referencias
| Componente | Ubicacion | Proposito |
|------------|-----------|-----------|
| **PROPAGATION-CRITERIA-MATRIX** | `referencias/` | Matriz de criterios para decidir propagacion |
| **DEPENDENCY-GRAPH** | `orchestration/` | Grafo de dependencias entre proyectos |
| **TRACEABILITY-MASTER** | `orchestration/` | Trazabilidad centralizada del workspace |
### 3. Mirrors
| Componente | Ubicacion | Proposito |
|------------|-----------|-----------|
| **MIRRORS-INDEX** | `shared/mirrors/` | Indice de todos los repositorios espejo |
| **PROPAGATION-STATUS** | `shared/mirrors/{proyecto}/` | Estado de propagacion por proyecto |
---
## Cuando Usar Cada Mecanismo
### MODE-PROPAGATION (@PROPAGATE)
**Usar cuando:**
- Necesitas propagar un cambio especifico a multiples proyectos
- Cambio en erp-core que debe ir a verticales
- Fix de seguridad que afecta multiples proyectos
- Bug fix en modulo compartido
- Actualizacion de dependencias compartidas
**Ejemplos:**
```bash
@PROPAGATE-ERP Distribuir fix de JWT a verticales
@PROPAGATE-SECURITY Fix de vulnerabilidad XSS
@PROPAGATE-CATALOG Actualizar modulo de notificaciones
```
**Flujo:**
```
Cambio en origen → CAPVED completo → Aplicar en cada destino → Validar → Documentar
```
---
### TRIGGER-PROPAGACION-AUTOMATICA
**Usar cuando:**
- Se activa automaticamente al completar Fase D
- No lo invocas directamente, el sistema lo evalua
**Cuando se activa:**
1. Completas una tarea en proyecto con propagacion (erp-core, shared/catalog)
2. El trigger evalua tipo de cambio
3. Sugiere o inicia propagacion segun reglas
**Flujo:**
```
Tarea completada → Trigger evalua → Decide accion → Notifica o propaga
```
---
### SIMCO-PROPAGACION
**Usar cuando:**
- Propagas documentacion DENTRO de un proyecto vertical
- No es para propagacion ENTRE proyectos
- Es para estructurar documentacion de modulos heredados
**Cuando se usa:**
- Al documentar un modulo heredado en una vertical
- Para asegurar que la documentacion refleja la herencia
**NO usar para:**
- Propagar codigo entre proyectos (usar MODE-PROPAGATION)
- Propagar cambios de core a verticales (usar MODE-PROPAGATION)
---
## Flujo de Decision
```
┌─────────────────────────────────────────────────────────────────┐
│ PREGUNTA: Que necesitas propagar? │
└────────────────────────────┬────────────────────────────────────┘
┌──────────────┴──────────────┐
▼ ▼
┌────────────────┐ ┌─────────────────┐
│ CODIGO/CAMBIO │ │ DOCUMENTACION │
│ entre proyectos│ │ dentro de │
└───────┬────────┘ │ proyecto │
│ └────────┬────────┘
▼ │
┌────────────────────┐ ▼
│ Es security fix? │ ┌─────────────────┐
└─────────┬──────────┘ │ SIMCO-PROPAGACION│
│ │ (interno) │
┌────────┴────────┐ └─────────────────┘
▼ ▼
┌─────────┐ ┌─────────┐
│ SI │ │ NO │
└────┬────┘ └────┬────┘
│ │
▼ ▼
┌──────────────┐ ┌───────────────────────┐
@PROPAGATE- │ │ Es bug fix? │
│ SECURITY │ └───────────┬───────────┘
│ (inmediato) │ ┌──────┴──────┐
└──────────────┘ ▼ ▼
┌─────────┐ ┌─────────┐
│ SI │ │ NO │
└────┬────┘ └────┬────┘
│ │
▼ ▼
┌──────────────┐ ┌───────────────┐
@PROPAGATE- │ │ @PROPAGATE
│ ERP │ │ (evaluar) │
│ (72h SLA) │ │ │
└──────────────┘ └───────────────┘
```
---
## SLAs Unificados
| Tipo de Cambio | SLA | Prioridad | Accion |
|----------------|-----|-----------|--------|
| **Security Fix** | 24 horas | CRITICA | Propagar inmediatamente |
| **Bug Fix** | 72 horas | ALTA | Propagar con prioridad |
| **Feature** | 1 semana | MEDIA | Evaluar si aplica |
| **Refactor** | 2 semanas | BAJA | Opcional |
| **Documentacion** | Inmediato | N/A | Auto-sync via mirrors |
| **Definiciones** | Inmediato | N/A | Auto-sync via mirrors |
---
## Sistema de Mirrors
### Proposito
Los mirrors son repositorios espejo que facilitan la propagacion automatica de:
- Documentacion (README, CHANGELOG)
- Definiciones (YAML de modulos)
- Interfaces (TypeScript .d.ts)
### Mirrors Activos
| Mirror | Version | Consumidores |
|--------|---------|--------------|
| template-saas | 1.2.1 | erp-core |
| erp-core | 1.3.0 | 5 verticales + 2 sub-verticales |
| erp-clinicas | 1.0.0 | clinica-dental, clinica-veterinaria |
### Auto-Propagacion via Mirrors
```yaml
Tipo: Documentacion/Definiciones
Flujo:
1. Cambio en proyecto origen
2. Sync automatico a shared/mirrors/{proyecto}/
3. Consumidores leen del mirror
4. Actualizacion inmediata disponible
Tipo: Codigo
Flujo:
1. Cambio en proyecto origen
2. Validacion local (build+lint+tests)
3. Propagar manualmente via MODE-PROPAGATION
4. Actualizar PROPAGATION-STATUS.yml
```
---
## Trazabilidad
### Donde se registra cada propagacion
| Registro | Ubicacion | Contenido |
|----------|-----------|-----------|
| **TRACEABILITY-MASTER** | `orchestration/` | Registro centralizado de todas las propagaciones |
| **PROPAGATION-STATUS** | `shared/mirrors/{proyecto}/` | Estado por proyecto mirror |
| **MASTER_INVENTORY** | `{proyecto}/orchestration/inventarios/` | Referencia a ultima propagacion recibida |
### Formato de Registro
```yaml
propagacion:
id: "PROP-CORE-002"
fecha: "2026-01-13"
tipo: "bulk_propagation"
origen: "erp-core"
destinos:
- erp-construccion
- erp-clinicas
- erp-mecanicas-diesel
- erp-retail
- erp-vidrio-templado
sub_destinos:
- clinica-dental (via erp-clinicas)
- clinica-veterinaria (via erp-clinicas)
modulos: MGN-016 a MGN-022
estado: "completed"
```
---
## Comandos Rapidos
| Alias | Descripcion | Ejemplo |
|-------|-------------|---------|
| `@PROPAGATE-ERP` | Propagar de erp-core a verticales | `@PROPAGATE-ERP Fix de autenticacion` |
| `@PROPAGATE-CATALOG` | Propagar cambio de catalogo | `@PROPAGATE-CATALOG Actualizar notifications` |
| `@PROPAGATE-SECURITY` | Propagacion urgente de seguridad | `@PROPAGATE-SECURITY Vulnerabilidad XSS` |
| `@SYNC-MIRRORS` | Sincronizar todos los mirrors | `@SYNC-MIRRORS` |
| `@PROPAGATE-DOC` | Propagar documentacion | `@PROPAGATE-DOC {proyecto}` |
| `@PROPAGATE-DEF` | Propagar definiciones | `@PROPAGATE-DEF {proyecto}` |
| `@PROPAGATE-CODE` | Propagar codigo validado | `@PROPAGATE-CODE {proyecto}` |
---
## Errores Comunes
### 1. Confundir MODE-PROPAGATION con SIMCO-PROPAGACION
- **MODE-PROPAGATION:** Entre proyectos (erp-core → verticales)
- **SIMCO-PROPAGACION:** Dentro de un proyecto (documentacion interna)
### 2. Propagar sin validar
- **Correcto:** Siempre ejecutar build+lint+tests antes de propagar
- **Incorrecto:** Propagar directamente sin validacion
### 3. Olvidar actualizar trazabilidad
- **Correcto:** Registrar en TRACEABILITY-MASTER y PROPAGATION-STATUS
- **Incorrecto:** Propagar sin documentar
### 4. Propagar codigo no validado
- **Documentacion/Definiciones:** OK propagar inmediatamente
- **Codigo:** SIEMPRE validar antes de propagar
---
## Referencias
- `orchestration/directivas/modos/MODE-PROPAGATION.md`
- `orchestration/directivas/triggers/TRIGGER-PROPAGACION-AUTOMATICA.md`
- `orchestration/directivas/simco/SIMCO-PROPAGACION.md`
- `orchestration/referencias/PROPAGATION-CRITERIA-MATRIX.yml`
- `orchestration/TRACEABILITY-MASTER.yml`
- `orchestration/DEPENDENCY-GRAPH.yml`
- `shared/mirrors/MIRRORS-INDEX.yml`
---
*PROPAGACION-ARCHITECTURE v1.0.0 - Sistema SAAD*

View File

@ -1,510 +0,0 @@
# SIMCO: GIT (Control de Versiones)
**Version:** 1.2.0
**Fecha:** 2026-01-16
**Aplica a:** TODO agente que modifica codigo o documentacion
**Prioridad:** OBLIGATORIA
---
## RESUMEN EJECUTIVO
> **Todo cambio en codigo o documentacion DEBE versionarse correctamente.**
> **Commits frecuentes, atomicos y descriptivos.**
> **PUSH OBLIGATORIO al finalizar cada tarea.**
> **FETCH OBLIGATORIO antes de verificar estado.**
> **Nunca perder trabajo por falta de commits o push.**
---
## REGLA CRITICA 1: FETCH ANTES DE OPERAR
```
╔══════════════════════════════════════════════════════════════════════════╗
║ ║
║ ANTES DE CUALQUIER VERIFICACION DE ESTADO GIT: ║
║ ║
║ 1. git fetch origin ║
║ → Obtener estado actual del remoto ║
║ ║
║ 2. git log HEAD..origin/main --oneline ║
║ → Si hay output = hay commits remotos que no tienes ║
║ ║
║ 3. Si hay commits remotos: ║
║ git pull --no-recurse-submodules ║
║ → Sincronizar antes de continuar ║
║ ║
║ 4. AHORA SI: git status ║
║ → Verificar estado local ║
║ ║
║ SIN FETCH = ESTADO INCOMPLETO ║
║ (Otro agente pudo hacer cambios en otra sesion) ║
║ ║
║ Referencia: INC-2026-01-16-001 ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
```
### Secuencia Obligatoria de Verificacion
```bash
# SIEMPRE ejecutar en este orden:
git fetch origin
git log HEAD..origin/main --oneline # Si hay output, hacer pull
git pull --no-recurse-submodules # Solo si paso anterior tiene output
git status # Ahora si verificar estado local
```
---
## REGLA CRITICA 2: COMMIT + PUSH OBLIGATORIO
```
╔══════════════════════════════════════════════════════════════════════════╗
║ ║
║ TODA TAREA QUE CREA O MODIFICA ARCHIVOS DEBE TERMINAR CON: ║
║ ║
║ 1. git add . ║
║ 2. git commit -m "[ID] tipo: descripcion" ║
║ 3. git push origin {rama} ║
║ ║
║ SIN PUSH = TAREA INCOMPLETA ║
║ ║
║ En workspace con SUBMODULES: ║
║ - Commitear y push en CADA submodule afectado ║
║ - Luego commitear y push en workspace principal ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
```
### Checklist Fin de Tarea (OBLIGATORIO)
```yaml
ANTES_de_reportar_tarea_completada:
- [ ] Todos los archivos creados/modificados estan guardados
- [ ] git status muestra archivos a commitear
- [ ] git add {archivos}
- [ ] git commit -m "[TAREA-ID] tipo: descripcion"
- [ ] git push origin {rama}
- [ ] Verificar: git status muestra "nothing to commit, working tree clean"
- [ ] Verificar: git log origin/main..HEAD muestra vacio (todo pusheado)
SI_hay_SUBMODULES:
- [ ] Repetir proceso en CADA submodule modificado
- [ ] Luego actualizar referencias en workspace principal
- [ ] Push final del workspace principal
```
### Secuencia para Workspace con Submodules
```bash
# 1. Commitear en cada submodule modificado
cd projects/{submodule}
git add .
git commit -m "[TAREA-ID] tipo: descripcion"
git push origin main
# 2. Repetir para cada submodule afectado
# ...
# 3. Actualizar workspace principal
cd /home/isem/workspace-v2
git add projects/{submodule} # Actualiza referencia del submodule
git commit -m "[WORKSPACE] chore: Update submodule references"
git push origin main
# 4. Verificar todo sincronizado
git status # Debe mostrar "clean"
```
---
## PRINCIPIOS FUNDAMENTALES
```
╔══════════════════════════════════════════════════════════════════════╗
║ ║
║ "Commitear temprano, commitear frecuentemente" ║
║ ║
║ Cada commit debe: ║
║ - Representar un cambio logico completo ║
║ - Ser funcional (no romper compilacion) ║
║ - Ser reversible sin afectar otros cambios ║
║ - Tener mensaje descriptivo con ID de tarea ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝
```
---
## FRECUENCIA DE COMMITS
```yaml
OBLIGATORIO_commitear:
- Al finalizar cada fase (Analisis, Planeacion, Ejecucion)
- Al completar cada archivo significativo
- Cada 30-45 minutos de trabajo continuo
- Antes de lanzar subagentes
- Despues de validar trabajo de subagentes
- Antes de cambiar de tarea
- Cuando build + lint pasan
RAZON: "Minimizar perdida de trabajo en caso de error"
```
---
## FORMATO DE MENSAJE DE COMMIT
### Estructura Obligatoria
```
[{TAREA-ID}] {tipo}: {descripcion concisa}
{cuerpo opcional - descripcion detallada}
{footer opcional - referencias, breaking changes}
```
### Ejemplos Correctos
```bash
# Feature nueva
[DB-042] feat: Crear tabla projects con soporte PostGIS
# Bug fix
[BE-015] fix: Corregir validacion de codigo unico en ProjectService
# Refactor
[FE-008] refactor: Extraer componente ProjectCard de ProjectList
# Documentacion
[DB-042] docs: Actualizar DATABASE_INVENTORY con tabla projects
# Tests
[BE-015] test: Agregar tests unitarios para ProjectService
# Subtarea
[DB-042-SUB-001] feat: Implementar indices para tabla projects
```
### Ejemplos Incorrectos
```bash
# Sin ID de tarea
fix: Corregir bug
# Muy vago
[BE-015] update: Cambios varios
# Demasiado largo en primera linea
[DB-042] feat: Crear tabla projects con todas las columnas necesarias incluyendo soporte para PostGIS y configuracion de indices compuestos para optimizar queries
# Sin tipo
[FE-008] Mejorar componente
```
---
## TIPOS DE COMMITS
| Tipo | Uso | Ejemplo |
|------|-----|---------|
| `feat` | Nueva funcionalidad | `[DB-042] feat: Agregar soporte PostGIS` |
| `fix` | Correccion de bug | `[BE-015] fix: Resolver error en constraint` |
| `refactor` | Refactorizacion sin cambio funcional | `[FE-008] refactor: Mejorar estructura componentes` |
| `docs` | Solo documentacion | `[DB-042] docs: Actualizar README con schema` |
| `test` | Agregar/modificar tests | `[BE-015] test: Agregar tests para ProjectService` |
| `chore` | Tareas de mantenimiento | `[DB-042] chore: Actualizar dependencias` |
| `style` | Formato/estilo (sin cambio logico) | `[FE-008] style: Aplicar prettier` |
| `perf` | Mejora de performance | `[DB-042] perf: Agregar indice compuesto` |
| `build` | Cambios en build/deps | `[BE-015] build: Actualizar TypeORM a v0.3` |
| `ci` | Cambios en CI/CD | `[INFRA-001] ci: Agregar workflow de tests` |
---
## COMMITS ATOMICOS
### Que es un Commit Atomico
```yaml
atomico:
- Representa UN cambio logico completo
- Es funcional (build pasa)
- Es reversible individualmente
- No mezcla cambios no relacionados
NO_atomico:
- Multiples cambios no relacionados
- Trabajo incompleto (excepto WIP explicito)
- Mezcla de fix y feat
- Cambios en multiples features
```
### Ejemplo de Atomicidad
```bash
# CORRECTO - Commits atomicos separados
[DB-042] feat: Crear tabla projects
[DB-042] feat: Agregar indices a tabla projects
[DB-042] feat: Crear seeds para projects
[DB-042] docs: Actualizar inventario con tabla projects
# INCORRECTO - Un commit masivo
[DB-042] feat: Crear tabla projects con indices, seeds y actualizacion de inventario
```
---
## FLUJO DE TRABAJO GIT
### Antes de Empezar Tarea
```bash
# 1. Asegurar rama actualizada
git fetch origin
git pull origin main
# 2. Crear rama de trabajo (si aplica)
git checkout -b feature/{TAREA-ID}-descripcion-corta
# 3. Verificar estado limpio
git status
```
### Durante la Tarea
```bash
# 1. Hacer cambios
# ... editar archivos ...
# 2. Verificar que build pasa
npm run build
npm run lint
# 3. Agregar cambios
git add {archivos especificos}
# o para todos los cambios relacionados:
git add .
# 4. Commit con mensaje descriptivo
git commit -m "[TAREA-ID] tipo: descripcion"
# 5. Repetir para cada cambio logico
```
### Al Completar Tarea
```bash
# 1. Verificar historial
git log --oneline -5
# 2. Push a remoto
git push origin {rama}
# 3. Crear PR si aplica
gh pr create --title "[TAREA-ID] Descripcion" --body "..."
```
---
## CHECKLIST PRE-COMMIT
```yaml
ANTES_de_cada_commit:
- [ ] Build pasa sin errores
- [ ] Lint pasa sin errores criticos
- [ ] Tests pasan (si existen)
- [ ] Cambios son logicamente completos
- [ ] No hay archivos no deseados (node_modules, .env, etc.)
- [ ] Mensaje sigue formato correcto
VERIFICAR:
git status # Ver archivos modificados
git diff # Ver cambios en detalle
git diff --cached # Ver cambios staged
```
---
## ERRORES COMUNES
| Error | Consecuencia | Solucion |
|-------|--------------|----------|
| No commitear frecuentemente | Perdida de trabajo | Commit cada 30-45 min |
| Commits masivos | Dificil revertir | Commits atomicos |
| Mensajes vagos | Historial incomprensible | Seguir formato |
| Commit con build roto | Bloquea CI/CD | Verificar antes de commit |
| Olvidar ID de tarea | Perdida de trazabilidad | Siempre incluir [TAREA-ID] |
| Commitear secretos | Brecha de seguridad | Verificar .gitignore |
---
## ARCHIVOS A IGNORAR (.gitignore)
```yaml
SIEMPRE_ignorar:
- node_modules/
- .env
- .env.*
- dist/
- build/
- coverage/
- *.log
- .DS_Store
- *.tmp
- *.cache
NUNCA_commitear:
- Credenciales
- API keys
- Passwords
- Certificados privados
- Archivos de configuracion local
```
---
## RAMAS (BRANCHING)
### Convencion de Nombres
```yaml
ramas:
feature: feature/{TAREA-ID}-descripcion-corta
bugfix: bugfix/{TAREA-ID}-descripcion-corta
hotfix: hotfix/{TAREA-ID}-descripcion-corta
release: release/v{X.Y.Z}
ejemplos:
- feature/DB-042-crear-tabla-projects
- bugfix/BE-015-fix-validacion
- hotfix/SEC-001-fix-xss
- release/v2.1.0
```
### Flujo de Ramas
```
main (produccion)
├─── develop (desarrollo)
│ │
│ ├─── feature/DB-042-*
│ │ └── merge a develop
│ │
│ ├─── feature/BE-015-*
│ │ └── merge a develop
│ │
│ └── release/v2.1.0
│ └── merge a main + tag
└─── hotfix/SEC-001-*
└── merge a main + develop
```
---
## REVERTIR CAMBIOS
### Revertir Ultimo Commit (no pusheado)
```bash
# Mantener cambios en working directory
git reset --soft HEAD~1
# Descartar cambios completamente
git reset --hard HEAD~1
```
### Revertir Commit ya Pusheado
```bash
# Crear commit de reversion (seguro)
git revert {commit-hash}
git push
```
### Deshacer Cambios en Archivo
```bash
# Descartar cambios no staged
git checkout -- {archivo}
# Descartar cambios staged
git reset HEAD {archivo}
git checkout -- {archivo}
```
---
## SITUACIONES ESPECIALES
### Work in Progress (WIP)
```bash
# Cuando necesitas commitear trabajo incompleto
git commit -m "[TAREA-ID] WIP: descripcion de estado actual"
# Luego, completar y hacer commit final
# (opcional: squash commits WIP antes de PR)
```
### Antes de Lanzar Subagente
```bash
# SIEMPRE commitear antes de delegar
git add .
git commit -m "[TAREA-ID] chore: Estado antes de delegacion a {SubAgente}"
```
### Despues de Validar Subagente
```bash
# Commitear resultado de subagente
git add .
git commit -m "[TAREA-ID-SUB-XXX] tipo: Resultado de {SubAgente}"
```
---
## VALIDACION DE COMMITS
### Verificar Historial
```bash
# Ver ultimos commits
git log --oneline -10
# Ver commits de tarea especifica
git log --oneline --grep="DB-042"
# Ver cambios de un commit
git show {commit-hash}
```
### Verificar Formato de Mensaje
```yaml
formato_valido:
- Tiene [TAREA-ID] al inicio
- Tiene tipo valido (feat, fix, etc.)
- Descripcion concisa (<72 caracteres primera linea)
- No tiene errores de ortografia graves
verificar_manualmente:
git log --oneline -1
# Debe mostrar: {hash} [TAREA-ID] tipo: descripcion
```
---
## REFERENCIAS
- **Principio de Validacion:** @PRINCIPIOS/PRINCIPIO-VALIDACION-OBLIGATORIA.md
- **Documentar:** @SIMCO/SIMCO-DOCUMENTAR.md
- **Crear:** @SIMCO/SIMCO-CREAR.md
---
**Version:** 1.0.0 | **Sistema:** SIMCO | **Mantenido por:** Tech Lead

View File

@ -1,829 +0,0 @@
# SIMCO: CICLO DE VIDA DE TAREAS (CAPVED)
**Versión:** 1.1.0
**Sistema:** SIMCO - Gestión de Tareas con CAPVED
**Propósito:** Definir el proceso completo para toda HU/Tarea que modifica código o documentación
**Actualizado:** 2025-12-08
---
## PRINCIPIO FUNDAMENTAL
> **Toda tarea que genera commit DEBE pasar por el ciclo CAPVED completo.**
> **Si algo aparece fuera del alcance, se registra y genera HU nueva.**
> **NUEVO: Antes de CAPVED, ejecutar FASE 0 para identificar nivel y contexto.**
---
## FASE 0: IDENTIFICACIÓN DE NIVEL (NUEVA - CRÍTICA)
**OBLIGATORIO antes de iniciar CAPVED**
### 0.1 Determinar Nivel Jerárquico
```yaml
Paso_1: Identificar en qué nivel del workspace estás trabajando
NIVEL_0_WORKSPACE:
ruta: "/workspace/orchestration/"
identificador: "Es directiva global o índice de workspace"
NIVEL_1_CORE:
ruta: "/workspace/core/"
identificador: "Es funcionalidad de catálogo o directiva"
NIVEL_2A_STANDALONE:
ruta: "/workspace/projects/{proyecto}/"
identificador: "NO tiene subcarpeta verticales/"
ejemplos: "gamilit, trading-platform, betting-analytics"
NIVEL_2B_SUITE:
ruta: "/workspace/projects/{suite}/"
identificador: "TIENE subcarpeta apps/verticales/"
ejemplo: "erp-suite"
NIVEL_2B1_SUITE_CORE:
ruta: "/workspace/projects/{suite}/apps/erp-core/"
identificador: "Es el núcleo de la suite"
NIVEL_2B2_VERTICAL:
ruta: "/workspace/projects/{suite}/apps/verticales/{vertical}/"
identificador: "Es vertical especializada"
ejemplos: "construccion, vidrio-templado, clinicas, retail"
NIVEL_3_CATALOGO:
ruta: "/workspace/shared/catalog/{funcionalidad}/"
identificador: "Es funcionalidad reutilizable"
```
### 0.2 Cargar Contexto del Nivel
```yaml
Archivos_a_leer_según_nivel:
STANDALONE:
- orchestration/templates/TEMPLATE-CONTEXTO-PROYECTO.md
- orchestration/templates/HERENCIA-SIMCO.md
- orchestration/inventarios/MASTER_INVENTORY.yml
VERTICAL:
- orchestration/templates/TEMPLATE-CONTEXTO-PROYECTO.md
- orchestration/templates/HERENCIA-SIMCO.md
- orchestration/templates/HERENCIA-ERP-CORE-TEMPLATE.md
- orchestration/inventarios/MASTER_INVENTORY.yml
SUITE_CORE:
- orchestration/templates/TEMPLATE-CONTEXTO-PROYECTO.md
- orchestration/inventarios/MASTER_INVENTORY.yml
- orchestration/inventarios/DEVENV-MASTER-INVENTORY.yml
```
### 0.3 Identificar Ruta de Propagación
```yaml
Según_tu_nivel_actual:
STANDALONE → propagar a:
- WORKSPACE (orchestration/WORKSPACE-STATUS.md)
VERTICAL → propagar a:
- SUITE (../../../orchestration/inventarios/)
- WORKSPACE (orchestration/WORKSPACE-STATUS.md)
SUITE_CORE → propagar a:
- SUITE (../../orchestration/inventarios/)
- WORKSPACE (orchestration/WORKSPACE-STATUS.md)
- VERTICALES (si afecta herencia)
CATALOGO → propagar a:
- CORE (inventarios/CORE_INVENTORY.yml)
- CONSUMIDORES (CATALOG-USAGE-TRACKING.yml)
```
### 0.4 Registrar Identificación
```yaml
# Resultado de Fase 0 (incluir en reporte)
fase_0_identificacion:
nivel: "{NIVEL_IDENTIFICADO}"
proyecto: "{NOMBRE}"
path: "{RUTA_COMPLETA}"
propagacion_a:
- "{nivel_superior_1}"
- "{nivel_superior_2}"
contexto_cargado:
- TEMPLATE-CONTEXTO-PROYECTO.md ✓
- HERENCIA-SIMCO.md ✓
- MASTER_INVENTORY.yml ✓
herencia_especifica: "{Si aplica: HERENCIA-ERP-CORE-TEMPLATE.md}"
```
### 0.5 Verificar Catálogo
```yaml
ANTES_de_proceder_a_CAPVED:
verificar: "¿Lo que voy a crear existe en @CATALOG?"
comando: "Buscar en shared/catalog/CATALOG-INDEX.yml"
SI_EXISTE:
- Leer SIMCO-REUTILIZAR.md
- Adaptar en lugar de crear
- Documentar adaptación
SI_NO_EXISTE:
- Proceder con CAPVED normal
- Considerar contribuir al catálogo al finalizar
```
---
## CUÁNDO USAR ESTE SIMCO
```yaml
USAR_SIMCO_TAREA_cuando:
- Recibes una HU o tarea técnica
- La tarea involucra modificar código
- La tarea involucra modificar documentación
- La tarea generará uno o más commits
- Cualquier trabajo que no sea puramente exploratorio
NO_USAR_cuando:
- Solo estás investigando/explorando (usa SIMCO-BUSCAR)
- Solo estás consultando información
- Es un spike sin implementación
```
---
## FLUJO COMPLETO CAPVED
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ │
│ ENTRADA: HU o Tarea Técnica │
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ FASE C: CONTEXTO (~5 min) │ │
│ │ ──────────────────────────── │ │
│ │ 1. Identificar proyecto/módulo/epic │ │
│ │ 2. Clasificar tipo de tarea │ │
│ │ 3. Registrar origen │ │
│ │ 4. Cargar contexto SIMCO (CCA) │ │
│ │ 5. Vincular documentos relevantes │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ FASE A: ANÁLISIS (~15 min) │ │
│ │ ────────────────────────── │ │
│ │ 1. Entender comportamiento deseado (negocio) │ │
│ │ 2. Identificar restricciones (seguridad/perf/UX) │ │
│ │ 3. Mapear objetos impactados (BD, BE, FE, otros) │ │
│ │ 4. Identificar dependencias (HUs bloqueantes/bloqueadas) │ │
│ │ 5. Detectar riesgos │ │
│ │ → SALIDA: Reporte de análisis │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ FASE P: PLANEACIÓN (~10 min) │ │
│ │ ───────────────────────────── │ │
│ │ 1. Desglosar en subtareas por dominio │ │
│ │ 2. Establecer orden de ejecución │ │
│ │ 3. Definir criterios de aceptación │ │
│ │ 4. Planificar pruebas │ │
│ │ 5. Asignar agentes/subagentes (si aplica) │ │
│ │ → SALIDA: Plan de ejecución │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ FASE V: VALIDACIÓN (~5 min) ⚠️ NO DELEGAR │ │
│ │ ──────────────────────────────────────────── │ │
│ │ 1. ¿Todo lo de A tiene acción en P? │ │
│ │ 2. ¿Dependencias resueltas o planificadas? │ │
│ │ 3. ¿Criterios cubren riesgos? │ │
│ │ 4. ¿Hay scope creep? → Registrar + crear HU derivada │ │
│ │ → GATE: Solo pasa si TODO cuadra │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────┴─────────┐ │
│ │ ¿VALIDACIÓN OK? │ │
│ └─────────┬─────────┘ │
│ NO │ │ SÍ │
│ ▼ ▼ │
│ ┌────────────┐ ┌──────────────────────────────────────────┐ │
│ │ AJUSTAR │ │ FASE E: EJECUCIÓN (variable) │ │
│ │ A o P │ │ ───────────────────────────── │ │
│ │ y volver │ │ 1. Actualizar docs/ PRIMERO │ │
│ │ a V │ │ 2. Ejecutar subtareas en orden │ │
│ └────────────┘ │ 3. Validar build/lint por subtarea │ │
│ │ 4. Registrar progreso │ │
│ │ 5. Usar SIMCO correspondientes │ │
│ │ → SALIDA: Código implementado │ │
│ └──────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ FASE D: DOCUMENTACIÓN (~10 min) │ │
│ │ ─────────────────────────────── │ │
│ │ 1. Actualizar diagramas/modelos │ │
│ │ 2. Actualizar specs técnicas │ │
│ │ 3. Crear ADR (si decisión arquitectónica) │ │
│ │ 4. Actualizar inventarios │ │
│ │ 5. Actualizar trazas │ │
│ │ 6. Vincular HUs derivadas │ │
│ │ 7. Registrar lecciones aprendidas │ │
│ │ → GATE: HU NO está Done sin esto │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ │
│ SALIDA: HU Completada, Documentada, Trazable │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
---
## FASE C: CONTEXTO (Detalle)
### C.1 Identificar Proyecto/Módulo/Epic
```yaml
Contexto_Obligatorio:
proyecto: "{nombre del proyecto}"
ruta_proyecto: "projects/{proyecto}/"
modulo: "{nombre del módulo afectado}"
epic_padre: "{EPIC-ID} - {nombre}"
feature_padre: "{FEATURE-ID} - {nombre}" # si aplica
```
### C.2 Clasificar Tipo de Tarea
```yaml
Tipos_de_Tarea:
feature: "Nueva funcionalidad"
enhancement: "Mejora a funcionalidad existente"
fix: "Corrección de bug"
refactor: "Reestructuración sin cambio funcional"
spike: "Investigación técnica"
doc-only: "Solo documentación"
tech-debt: "Pago de deuda técnica"
security: "Corrección de seguridad"
performance: "Optimización de rendimiento"
```
### C.3 Registrar Origen
```yaml
Origenes_de_Tarea:
plan-original: "Parte del plan de proyecto/sprint"
descubrimiento: "Detectada durante otra tarea"
incidencia: "Reportada por usuario/QA"
mejora-continua: "Identificada en retrospectiva"
dependencia: "Requerida por otra HU"
```
### C.4 Cargar Contexto SIMCO (CCA)
```
Seguir protocolo de SIMCO-INICIALIZACION.md:
1. Leer principios fundamentales (4 ahora con CAPVED)
2. Leer perfil del agente
3. Leer CONTEXTO-PROYECTO.md
4. Leer inventarios relevantes
5. Cargar SIMCO de operación según tipo de tarea
```
### C.5 Vincular Documentos Relevantes
```yaml
Documentos_a_Vincular:
docs_proyecto:
- "docs/{fase}/{epic}/README.md"
- "docs/{fase}/{epic}/requerimientos/{archivo}.md"
- "docs/{fase}/{epic}/especificaciones/{archivo}.md"
docs_tecnicos:
- "docs/95-guias-desarrollo/{relevantes}.md"
- "docs/97-adr/{relacionados}.md"
orchestration:
- "orchestration/inventarios/{relevantes}.yml"
- "orchestration/trazas/TRAZA-{tipo}.md"
```
---
## FASE A: ANÁLISIS (Detalle)
### A.1 Comportamiento Deseado (Negocio)
```yaml
Preguntas_de_Negocio:
- "¿Qué debe poder hacer el usuario al completar esta HU?"
- "¿Qué problema de negocio resuelve?"
- "¿Cuál es el criterio de éxito desde perspectiva de usuario?"
- "¿Hay casos de uso específicos documentados?"
Formato_Respuesta:
como: "{rol de usuario}"
quiero: "{acción deseada}"
para: "{beneficio/valor}"
```
### A.2 Restricciones
```yaml
Restricciones_a_Identificar:
seguridad:
- "¿Requiere autenticación?"
- "¿Requiere autorización por rol?"
- "¿Maneja datos sensibles?"
- "¿Aplica RLS?"
performance:
- "¿Volumen esperado de datos?"
- "¿Tiempo de respuesta esperado?"
- "¿Requiere paginación?"
- "¿Requiere caché?"
ux:
- "¿Hay wireframes/mockups?"
- "¿Estados de carga definidos?"
- "¿Manejo de errores definido?"
- "¿Responsive requerido?"
```
### A.3 Mapear Objetos Impactados
```yaml
Objetos_por_Capa:
database:
schemas: [] # Schemas afectados
tablas: [] # Tablas a crear/modificar
vistas: [] # Vistas afectadas
funciones: [] # Funciones a crear/modificar
indices: [] # Índices necesarios
triggers: [] # Triggers afectados
rls_policies: [] # Políticas RLS
backend:
modulos: [] # Módulos NestJS
entities: [] # Entities TypeORM
services: [] # Services
controllers: [] # Controllers
dtos: [] # DTOs (Request/Response)
guards: [] # Guards de autorización
pipes: [] # Pipes de validación
frontend:
paginas: [] # Páginas/rutas
componentes: [] # Componentes React
hooks: [] # Custom hooks
stores: [] # Stores Zustand
types: [] # TypeScript types/interfaces
services: [] # Services de API
otros:
proyectos: [] # Otros proyectos afectados
integraciones: [] # Integraciones externas
jobs: [] # Jobs/colas
caches: [] # Caché a invalidar
```
### A.4 Identificar Dependencias
```yaml
Dependencias:
bloquea_a: # Esta HU bloquea a otras
- hu_id: "HU-XXX"
razon: "Necesita la tabla que creo"
bloqueada_por: # Esta HU depende de otras
- hu_id: "HU-YYY"
razon: "Necesito el endpoint de auth"
estado: "completada | en-progreso | pendiente"
relacionadas: # HUs relacionadas (no bloqueo directo)
- hu_id: "HU-ZZZ"
relacion: "Mismo módulo"
```
### A.5 Detectar Riesgos
```yaml
Riesgos_Identificados:
- id: "R1"
descripcion: "Cambio en tabla users afecta auth de todos los tenants"
probabilidad: "alta | media | baja"
impacto: "alto | medio | bajo"
mitigacion: "Ejecutar en horario de bajo tráfico, tener rollback listo"
```
---
## FASE P: PLANEACIÓN (Detalle)
### P.1 Desglosar en Subtareas
```yaml
Subtareas:
documentacion: # SIEMPRE PRIMERO
- id: "ST-001"
descripcion: "Actualizar spec de API en docs/"
artefactos: ["docs/.../.md"]
database:
- id: "ST-002"
descripcion: "Crear tabla users en schema auth"
artefactos: ["ddl/schemas/auth/tables/users.sql"]
agente: "Database-Agent"
backend:
- id: "ST-003"
descripcion: "Crear UserEntity alineada con DDL"
artefactos: ["src/modules/users/entities/user.entity.ts"]
agente: "Backend-Agent"
depende_de: ["ST-002"]
- id: "ST-004"
descripcion: "Crear UsersService con CRUD"
artefactos: ["src/modules/users/users.service.ts"]
agente: "Backend-Agent"
depende_de: ["ST-003"]
frontend:
- id: "ST-005"
descripcion: "Crear UserList component"
artefactos: ["src/components/users/UserList.tsx"]
agente: "Frontend-Agent"
depende_de: ["ST-004"]
validacion: # SIEMPRE AL FINAL
- id: "ST-006"
descripcion: "Validación final build/lint/tests"
agente: "Ejecutar directamente"
```
### P.2 Orden de Ejecución
```
1. Documentación (docs/ actualizados)
2. Database (DDL, migraciones)
3. Backend (Entities → Services → Controllers)
4. Frontend (Types → Hooks → Components → Pages)
5. Validación (build, lint, tests)
6. Documentación final (inventarios, trazas)
```
### P.3 Criterios de Aceptación
```yaml
Criterios_de_Aceptacion:
funcionales:
- "Usuario puede crear registro"
- "Usuario puede listar registros con paginación"
- "Usuario puede editar registro existente"
- "Usuario puede eliminar registro (soft delete)"
tecnicos:
- "Build pasa sin errores"
- "Lint pasa sin errores"
- "Tests unitarios cubren >80%"
- "API documentada en Swagger"
documentacion:
- "Inventarios actualizados"
- "Trazas registradas"
- "ADR creado (si aplica)"
```
### P.4 Plan de Pruebas
```yaml
Plan_de_Pruebas:
unitarias:
- "Service: CRUD operations"
- "Guards: permission checks"
integracion:
- "API: endpoints responden correctamente"
- "DB: datos persisten correctamente"
e2e:
- "Flujo completo crear-editar-eliminar"
regresion:
- "Auth sigue funcionando"
- "Otros módulos no afectados"
```
---
## FASE V: VALIDACIÓN (Detalle)
### V.1 Verificar Cobertura Análisis → Plan
```yaml
Verificacion_Cobertura:
objetos_database:
- objeto: "tabla users"
en_analisis: true
en_plan: "ST-002"
✓ CUBIERTO
objetos_backend:
- objeto: "UserEntity"
en_analisis: true
en_plan: "ST-003"
✓ CUBIERTO
# Si algo en Análisis NO tiene subtarea en Plan:
gap_detectado:
- objeto: "índice en email"
en_analisis: true
en_plan: false
accion: "Agregar subtarea ST-002b"
```
### V.2 Verificar Dependencias
```yaml
Verificacion_Dependencias:
- hu_dependencia: "HU-YYY"
estado: "completada"
✓ LISTA
- hu_dependencia: "HU-ZZZ"
estado: "pendiente"
⚠️ BLOQUEADOR
accion: "Esperar o crear subtarea previa"
```
### V.3 Detectar Scope Creep
```yaml
Scope_Creep_Detectado:
- item: "Se necesita también endpoint de búsqueda"
parte_de_hu_original: false
accion: "CREAR HU DERIVADA"
hu_derivada:
id: "DERIVED-HU-001-001"
descripcion: "Endpoint de búsqueda de usuarios"
prioridad: "P2"
```
### V.4 Gate de Validación
```
CHECKLIST GATE:
[ ] Todo objeto de Análisis tiene subtarea en Plan
[ ] Todas las dependencias están resueltas o planificadas
[ ] Criterios de aceptación cubren todos los riesgos
[ ] Scope creep registrado y HUs derivadas creadas
[ ] No hay gaps sin resolver
→ Si TODO marcado: PROCEDER A EJECUCIÓN
→ Si algo falta: VOLVER A AJUSTAR A o P
```
---
## FASE E: EJECUCIÓN (Detalle)
### E.1 Actualizar docs/ PRIMERO
```yaml
Antes_de_Codigo:
- Actualizar specs de API
- Actualizar diagramas de entidades
- Actualizar documentación de módulo
- Verificar que docs/ refleja lo que se va a implementar
```
### E.2 Ejecutar Subtareas en Orden
Para cada subtarea:
```yaml
Por_Subtarea:
1_iniciar:
- Marcar subtarea "en progreso"
- Cargar SIMCO correspondiente (CREAR/MODIFICAR/DDL/etc)
2_implementar:
- Seguir checklist del SIMCO
- Aplicar principios (doc-primero, anti-dup, validación)
- Generar código/cambios
3_validar:
- Ejecutar build
- Ejecutar lint
- Verificar que compila
4_registrar:
- Marcar subtarea "completada"
- Notas de lo implementado
- Desviaciónes (si las hubo)
5_siguiente:
- Pasar a siguiente subtarea
```
### E.3 Usar SIMCO Correspondientes
```yaml
SIMCO_por_Subtarea:
crear_tabla: "@SIMCO-CREAR + @SIMCO-DDL"
crear_entity: "@SIMCO-CREAR + @SIMCO-BACKEND"
crear_componente: "@SIMCO-CREAR + @SIMCO-FRONTEND"
modificar_algo: "@SIMCO-MODIFICAR + @SIMCO-{dominio}"
validar: "@SIMCO-VALIDAR"
```
---
## FASE D: DOCUMENTACIÓN (Detalle)
### D.1 Actualizar Diagramas/Modelos
```yaml
Diagramas_a_Actualizar:
- tipo: "ERD"
ubicacion: "docs/{epic}/diseño/erd.md"
cambio: "Agregar tabla users"
- tipo: "Arquitectura"
ubicacion: "docs/00-vision-general/arquitectura.md"
cambio: "Agregar módulo users" # si aplica
```
### D.2 Actualizar Specs Técnicas
```yaml
Specs_a_Actualizar:
- tipo: "API"
ubicacion: "docs/{epic}/especificaciones/api-users.md"
cambio: "Documentar endpoints CRUD"
- tipo: "BD"
ubicacion: "docs/{epic}/especificaciones/modelo-datos.md"
cambio: "Agregar tabla users"
```
### D.3 Crear ADR (si aplica)
```yaml
ADR_Requerido_Si:
- "Se tomó decisión arquitectónica importante"
- "Se eligió tecnología/librería nueva"
- "Se cambió patrón establecido"
- "Se hizo trade-off significativo"
Ubicacion: "docs/97-adr/ADR-{NNN}-{titulo}.md"
```
### D.4 Actualizar Inventarios
```yaml
Inventarios_a_Actualizar:
- archivo: "orchestration/inventarios/DATABASE_INVENTORY.yml"
agregar: "Nueva tabla users en schema auth"
- archivo: "orchestration/inventarios/BACKEND_INVENTORY.yml"
agregar: "Nuevo módulo users"
- archivo: "orchestration/inventarios/FRONTEND_INVENTORY.yml"
agregar: "Nuevo componente UserList"
```
### D.5 Actualizar Trazas
```yaml
Traza_a_Registrar:
archivo: "orchestration/trazas/TRAZA-TAREAS-{tipo}.md"
entrada:
fecha: "2025-12-08"
hu_id: "HU-001"
descripcion: "CRUD de usuarios"
archivos_creados: [lista]
archivos_modificados: [lista]
agente: "Backend-Agent"
duracion: "2h"
notas: "Sin incidencias"
```
### D.6 Vincular HUs Derivadas
```yaml
HUs_Derivadas:
- id: "DERIVED-HU-001-001"
descripcion: "Endpoint de búsqueda de usuarios"
origen: "HU-001"
detectado_en: "Fase V - Validación"
estado: "pendiente"
prioridad: "P2"
```
### D.7 Registrar Lecciones Aprendidas
```yaml
Lecciones_Aprendidas:
que_funciono_bien:
- "Seguir orden DB → BE → FE evitó retrabajos"
- "Validar contra Swagger antes de FE ahorró tiempo"
que_se_puede_mejorar:
- "Definir tipos compartidos desde el inicio"
para_futuras_HUs:
- "En módulos CRUD, siempre incluir paginación desde V1"
```
### D.8 Gate Final
```
CHECKLIST DOCUMENTACIÓN:
[ ] Diagramas actualizados
[ ] Specs técnicas actualizadas
[ ] ADR creado (si aplica)
[ ] Inventarios actualizados
[ ] Trazas registradas
[ ] HUs derivadas vinculadas
[ ] Lecciones aprendidas registradas
→ Si TODO marcado: HU COMPLETADA
→ Si algo falta: COMPLETAR ANTES DE CERRAR
```
---
## TEMPLATE DE REGISTRO RÁPIDO
```yaml
# Registro CAPVED para HU-{ID}
# ────────────────────────────
hu_id: "HU-XXX"
titulo: "Título de la HU"
fecha_inicio: "YYYY-MM-DD"
fecha_fin: "YYYY-MM-DD"
contexto:
proyecto: ""
modulo: ""
epic: ""
tipo: "feature | fix | refactor | etc"
origen: "plan | descubrimiento | incidencia"
analisis:
objetos_impactados: N
dependencias: N
riesgos: N
planeacion:
subtareas: N
agentes_asignados: []
validacion:
gaps_detectados: N
scope_creep: "sí | no"
hus_derivadas: N
ejecucion:
subtareas_completadas: "N/N"
build_status: "✓ | ✗"
lint_status: "✓ | ✗"
documentacion:
inventarios: "✓ | ✗"
trazas: "✓ | ✗"
adr: "✓ | N/A"
lecciones: "✓ | ✗"
estado_final: "COMPLETADA | EN_PROGRESO | BLOQUEADA"
```
---
## REFERENCIAS
| Documento | Propósito |
|-----------|-----------|
| `PRINCIPIO-CAPVED.md` | Declaración del principio |
| `SIMCO-INICIALIZACION.md` | Protocolo CCA |
| `TEMPLATE-TAREA-CAPVED.md` | Template completo para tracking |
| `TEMPLATE-ANALISIS.md` | Template de análisis |
| `TEMPLATE-PLAN.md` | Template de planeación |
| `TEMPLATE-VALIDACION.md` | Template de validación |
---
**Versión:** 1.0.0 | **Sistema:** SIMCO + CAPVED | **Tipo:** Directiva de Proceso

View File

@ -1,394 +0,0 @@
# SIMCO: VALIDAR
**Versión:** 1.0.0
**Fecha:** 2025-12-08
**Aplica a:** TODO agente antes de marcar una tarea como completada
**Prioridad:** OBLIGATORIA - NO SE PUEDE OMITIR
---
## RESUMEN EJECUTIVO
> **NINGUNA tarea se marca como completada sin pasar TODAS las validaciones.**
> **Si una validación falla, la tarea NO está completa.**
---
## PRINCIPIO FUNDAMENTAL
```
╔══════════════════════════════════════════════════════════════════════╗
║ BUILD PASA + LINT PASA + TESTS PASAN = TAREA PUEDE COMPLETARSE ║
║ CUALQUIER FALLO = TAREA NO COMPLETADA ║
╚══════════════════════════════════════════════════════════════════════╝
```
---
## CHECKLIST UNIVERSAL DE VALIDACIÓN
```
VALIDACIONES TÉCNICAS (OBLIGATORIAS)
├── [ ] 1. Build compila sin errores
├── [ ] 2. Lint pasa sin errores críticos
├── [ ] 3. Tests pasan (si existen)
└── [ ] 4. Aplicación inicia correctamente
VALIDACIONES DE COHERENCIA
├── [ ] 5. Código alineado con documentación
├── [ ] 6. Sin duplicados creados
├── [ ] 7. Convenciones seguidas
└── [ ] 8. Inventarios actualizados
VALIDACIONES DE INTEGRACIÓN
├── [ ] 9. Coherencia entre capas (DB↔BE↔FE)
└── [ ] 10. APIs funcionan correctamente
```
---
## VALIDACIONES POR CAPA
> **Definiciones canónicas disponibles:**
> - @DEF_VAL_BE`_definitions/validations/VALIDATION-BACKEND.md`
> - @DEF_VAL_FE`_definitions/validations/VALIDATION-FRONTEND.md`
> - @DEF_VAL_DDL`_definitions/validations/VALIDATION-DDL.md`
> - @DEF_VAL_DEVOPS`_definitions/validations/VALIDATION-DEVOPS.md`
### Database (DDL)
> **Definición canónica:** @DEF_VAL_DDL
**Comando obligatorio:**
```bash
# Carga limpia COMPLETA
cd @DB_SCRIPTS
./{RECREATE_CMD}
```
**Criterios de éxito:**
```
✅ Script ejecuta sin errores
✅ Todas las tablas se crean
✅ Todos los índices se crean
✅ Constraints se aplican
✅ Seeds se cargan (si existen)
✅ Integridad referencial OK
```
**Verificación post-creación:**
```bash
# Verificar tablas
psql -d {DB_NAME} -c "\dt {schema}.*"
# Verificar índices
psql -d {DB_NAME} -c "\di {schema}.*"
# Verificar estructura
psql -d {DB_NAME} -c "\d {schema}.{tabla}"
# Test de insert
psql -d {DB_NAME} -c "INSERT INTO {schema}.{tabla} (...) VALUES (...);"
```
**Si falla:**
```
🛑 NO marcar como completada
1. Identificar error en DDL
2. Corregir archivo DDL (NO fix manual en BD)
3. Re-ejecutar carga limpia
4. Solo entonces continuar
```
---
### Backend (NestJS/TypeScript)
> **Definición canónica:** @DEF_VAL_BE
**Comandos obligatorios:**
```bash
cd @BACKEND_ROOT
# 1. Build (OBLIGATORIO)
npm run build
# ✅ Debe completar sin errores
# 2. Lint (OBLIGATORIO)
npm run lint
# ✅ Debe pasar o corregir errores
# 3. Tests (si existen)
npm run test
# ✅ Deben pasar
# 4. Iniciar aplicación
npm run start:dev
# ✅ Debe iniciar sin errores de runtime
```
**Criterios de éxito:**
```
✅ TypeScript compila sin errores
✅ ESLint sin errores (warnings aceptables)
✅ Tests unitarios pasan
✅ Aplicación inicia
✅ Endpoints responden
```
**Verificación de endpoints:**
```bash
# Verificar health
curl http://localhost:3000/api/health
# Verificar endpoint creado
curl http://localhost:3000/api/{recurso}
# Verificar Swagger
curl http://localhost:3000/api/docs
```
**Si falla:**
```
🛑 NO marcar como completada
1. Revisar errores de TypeScript
2. Corregir código
3. Re-ejecutar build + lint
4. Solo entonces continuar
```
---
### Frontend (React/TypeScript)
> **Definición canónica:** @DEF_VAL_FE
**Comandos obligatorios:**
```bash
cd @FRONTEND_ROOT
# 1. Build (OBLIGATORIO)
npm run build
# ✅ Debe completar sin errores
# 2. Lint (OBLIGATORIO)
npm run lint
# ✅ Debe pasar o corregir errores
# 3. Type check
npm run typecheck # o tsc --noEmit
# ✅ Debe pasar
# 4. Iniciar aplicación
npm run dev
# ✅ Debe iniciar sin errores
```
**Criterios de éxito:**
```
✅ TypeScript compila sin errores
✅ ESLint sin errores críticos
✅ Aplicación renderiza correctamente
✅ Sin errores en consola del navegador
✅ Componentes funcionan según diseño
```
**Si falla:**
```
🛑 NO marcar como completada
1. Revisar errores de TypeScript/React
2. Corregir código
3. Re-ejecutar build + lint
4. Solo entonces continuar
```
---
## VALIDACIÓN DE COHERENCIA
### Coherencia Documentación ↔ Código
**Verificar:**
```markdown
- [ ] Lo implementado coincide con docs/
- [ ] No hay features documentadas sin implementar
- [ ] No hay código sin documentación correspondiente
- [ ] ADRs actualizados si hay decisiones nuevas
```
### Coherencia Entre Capas (3-Tier)
**Database ↔ Backend:**
```markdown
- [ ] Entity mapea correctamente a tabla
- [ ] Tipos de columnas coinciden
- [ ] Relaciones (FK) correctas
- [ ] Nombres de campos alineados
```
**Backend ↔ Frontend:**
```markdown
- [ ] DTOs coinciden con types del frontend
- [ ] Endpoints documentados en Swagger
- [ ] Respuestas API coinciden con interfaces FE
- [ ] Errores manejados consistentemente
```
### Anti-Duplicación
**Verificar después de crear:**
```bash
# Buscar objetos con nombre similar
grep -rn "{nombre}" @INVENTORY
# No debe haber entradas duplicadas
# Si hay duplicados → ERROR → Corregir
```
---
## MATRIZ DE VALIDACIONES POR TIPO DE TAREA
| Tipo de Tarea | Build | Lint | Tests | Carga Limpia | Coherencia 3-Tier |
|---------------|-------|------|-------|--------------|-------------------|
| Nueva tabla | - | - | - | ✅ OBLIGATORIO | ✅ |
| Nueva entity | ✅ BE | ✅ BE | ✅ BE | - | ✅ |
| Nuevo service | ✅ BE | ✅ BE | ✅ BE | - | - |
| Nuevo controller | ✅ BE | ✅ BE | ✅ BE | - | ✅ |
| Nuevo componente | ✅ FE | ✅ FE | ✅ FE | - | ✅ |
| Nueva página | ✅ FE | ✅ FE | ✅ FE | - | ✅ |
| Bug fix | ✅ Afectado | ✅ Afectado | ✅ Afectado | Si DDL | - |
| Refactor | ✅ TODO | ✅ TODO | ✅ TODO | Si DDL | ✅ |
---
## PROTOCOLO DE FALLA
### Si Build Falla
```markdown
## ❌ Build Fallido
**Error:**
{copiar error completo}
**Archivo(s) afectado(s):**
- {lista de archivos}
**Análisis:**
{descripción del problema}
**Acción:**
1. Corregir {archivo} línea {N}
2. Re-ejecutar build
3. Continuar solo si pasa
```
### Si Lint Falla (Errores Críticos)
```markdown
## ❌ Lint Fallido
**Errores críticos:**
{lista de errores}
**Acción:**
1. Corregir cada error
2. Re-ejecutar lint
3. Warnings son aceptables
4. Errores NO son aceptables
```
### Si Tests Fallan
```markdown
## ❌ Tests Fallidos
**Tests que fallan:**
- {test 1}: {razón}
- {test 2}: {razón}
**Acción:**
1. Analizar si es error de código o de test
2. Si error de código → Corregir código
3. Si test desactualizado → Actualizar test
4. Re-ejecutar tests
```
### Si Carga Limpia Falla
```markdown
## ❌ Carga Limpia Fallida
**Error:**
{error de PostgreSQL}
**Archivo DDL problemático:**
{archivo.sql}
**Acción:**
1. NO ejecutar fix manual en BD
2. Corregir archivo DDL
3. Re-ejecutar carga limpia completa
4. Repetir hasta éxito
```
---
## REPORTE DE VALIDACIÓN
**Incluir en cada entrega:**
```markdown
## Validaciones Ejecutadas
### Build
- Backend: ✅ Pasa | ❌ Falla
- Frontend: ✅ Pasa | ❌ Falla | ⏭️ N/A
### Lint
- Backend: ✅ Pasa | ❌ Falla
- Frontend: ✅ Pasa | ❌ Falla | ⏭️ N/A
### Tests
- Backend: ✅ Pasa | ❌ Falla | ⏭️ N/A
- Frontend: ✅ Pasa | ❌ Falla | ⏭️ N/A
### Carga Limpia (DDL)
- Database: ✅ Pasa | ❌ Falla | ⏭️ N/A
### Coherencia
- Docs ↔ Código: ✅ OK | ❌ Discrepancia
- DB ↔ BE: ✅ OK | ❌ Discrepancia | ⏭️ N/A
- BE ↔ FE: ✅ OK | ❌ Discrepancia | ⏭️ N/A
### Estado Final
✅ TODAS LAS VALIDACIONES PASAN → Tarea completable
❌ ALGUNA VALIDACIÓN FALLA → Tarea NO completable
```
---
## ERRORES COMUNES
| Error | Causa | Solución |
|-------|-------|----------|
| Reportar sin validar | Prisa por entregar | SIEMPRE ejecutar validaciones |
| Fix manual en BD | Carga limpia falla | Corregir DDL, no BD directamente |
| Ignorar warnings de lint | Parecer inofensivos | Revisar si son errores disfrazados |
| Saltar tests | "No hay tiempo" | Tests son OBLIGATORIOS |
| No verificar coherencia | Asumir que está bien | Verificar SIEMPRE entre capas |
---
## REFERENCIAS
- **Ciclo de vida de tareas:** @CAPVED (PRINCIPIO-CAPVED.md) - Fase V y E
- **Punto de entrada HU:** @TAREA (SIMCO-TAREA.md)
- **Crear archivos:** @CREAR (SIMCO-CREAR.md)
- **Documentar:** @DOCUMENTAR (SIMCO-DOCUMENTAR.md)
- **Directiva completa de validación:** @DIRECTIVAS/PROCESO-VALIDACION.md
---
**Versión:** 1.1.0 | **Sistema:** SIMCO + CAPVED | **Mantenido por:** Tech Lead

View File

@ -1,345 +0,0 @@
# TRIGGER-ANALISIS-DEPENDENCIAS
**ID:** TRIGGER-ANALISIS-DEPENDENCIAS
**Version:** 1.0.0
**Tipo:** Automatico
**Fase CAPVED:** Se activa en Fase A (Analisis)
---
## Proposito
Analizar automaticamente las dependencias de un archivo antes de modificarlo,
identificando tanto los archivos de los que depende (imports) como los archivos
que dependen de el (dependientes), para evaluar el impacto del cambio y
asegurar que todos los archivos afectados sean considerados en el plan.
---
## Cuando Se Activa
```yaml
activadores:
palabras_clave:
- "modificar"
- "cambiar"
- "actualizar"
- "refactorizar"
- "eliminar"
- "renombrar"
- "mover"
tipos_operacion:
- Modificacion de archivo existente
- Eliminacion de archivo
- Renombrado de archivo/clase/funcion
- Cambio de firma de funcion/metodo
- Cambio de estructura de tabla/entity
ejemplos:
- "Modificar UserEntity para agregar campo email_verified"
- "Cambiar estructura de tabla payments"
- "Refactorizar AuthService"
- "Renombrar componente Dashboard a AdminDashboard"
- "Eliminar funcion deprecada calculateTotal"
```
---
## Acciones del Trigger
### Paso 1: Identificar Dependencias (Imports)
```yaml
accion: "Identificar archivos que el archivo modificado importa"
descripcion: "Estos son los archivos de los que DEPENDE el archivo a modificar"
comandos:
typescript:
- grep -E "^import .* from" {archivo}
- grep -E "require\(" {archivo}
python:
- grep -E "^from .* import|^import " {archivo}
sql:
- grep -E "REFERENCES|FOREIGN KEY" {archivo}
output:
formato: |
## Dependencias (de los que depende)
| Archivo | Tipo de Dependencia |
|---------|---------------------|
| {ruta} | {import/extends/uses} |
```
### Paso 2: Identificar Dependientes
```yaml
accion: "Identificar archivos que importan o usan el archivo a modificar"
descripcion: "Estos son los archivos que DEPENDEN del archivo a modificar"
comandos:
buscar_imports:
- grep -rn "from.*{nombre_modulo}" apps/ libs/ src/
- grep -rn "import.*{NombreClase}" apps/ libs/ src/
- grep -rn "require.*{nombre}" apps/ libs/ src/
buscar_uso:
- grep -rn "{NombreClase}" apps/ libs/ src/ --include="*.ts"
- grep -rn "{nombre_funcion}\(" apps/ libs/ src/
buscar_referencias_bd:
- grep -rn "REFERENCES.*{tabla}" database/
- grep -rn "{tabla}\." apps/ libs/ src/
output:
formato: |
## Dependientes (los que dependen de este)
| Archivo | Linea | Tipo de Uso |
|---------|-------|-------------|
| {ruta} | {linea} | {import/call/extends} |
```
### Paso 3: Evaluar Impacto
```yaml
accion: "Clasificar el nivel de impacto del cambio"
clasificacion:
ALTO:
condiciones:
- Mas de 5 dependientes
- Cambio es breaking (firma, estructura, nombre)
- Afecta multiples capas (DB + BE + FE)
- Afecta modulo compartido
acciones:
- Listar TODOS los archivos afectados
- Incluir actualizacion de dependientes en plan
- Considerar migracion gradual
- Verificar tests existentes
MEDIO:
condiciones:
- 2-5 dependientes
- Cambio es aditivo (nuevo campo, nueva funcion)
- Afecta una capa principalmente
acciones:
- Listar archivos afectados
- Evaluar si dependientes necesitan cambios
- Actualizar tests si existen
BAJO:
condiciones:
- 0-1 dependientes
- Cambio interno (no afecta API publica)
- Refactoring sin cambio de comportamiento
acciones:
- Proceder con precaucion normal
- Verificar build y lint
```
### Paso 4: Generar Plan de Modificacion
```yaml
accion: "Proponer orden de modificacion basado en dependencias"
reglas_orden:
1. Modificar dependencias primero (lo que importa)
2. Modificar archivo principal
3. Modificar dependientes (los que importan)
4. Actualizar tests
5. Validar build completo
ejemplo:
si_modifica: "UserEntity"
orden_sugerido:
1. user.entity.ts (archivo principal)
2. user.service.ts (usa UserEntity)
3. user.controller.ts (usa UserService)
4. user.dto.ts (si hay cambios de estructura)
5. user.spec.ts (tests)
6. components usando user (frontend)
```
---
## Formato de Reporte
```markdown
## Analisis de Dependencias
### Archivo a Modificar
- Ruta: {ruta_completa}
- Tipo: {entity|service|component|table|...}
- Proyecto: {proyecto}
### Tipo de Cambio
- Descripcion: {que se va a cambiar}
- Breaking: {SI | NO}
- Afecta API Publica: {SI | NO}
### Dependencias (de los que depende)
| # | Archivo | Tipo |
|---|---------|------|
| 1 | {ruta} | {import/extends} |
### Dependientes (los que dependen de este)
| # | Archivo | Linea | Tipo de Uso | Requiere Cambio |
|---|---------|-------|-------------|-----------------|
| 1 | {ruta} | {n} | {import} | {SI/NO/EVALUAR} |
### Clasificacion de Impacto
**Nivel: {ALTO | MEDIO | BAJO}**
Razon: {explicacion}
### Plan de Modificacion Sugerido
1. {paso_1}
2. {paso_2}
...
### Archivos a Incluir en el Plan
- [ ] {archivo_1}
- [ ] {archivo_2}
...
### Advertencias
{lista_de_advertencias_si_aplica}
```
---
## Casos Especiales
### Cambio en Entity de Base de Datos
```yaml
si_modifica: "*.entity.ts"
buscar_adicional:
- Archivo de migracion relacionado
- DTOs que exponen la entity
- Services que usan la entity
- Controllers que exponen endpoints
- Componentes frontend que muestran datos
verificar:
- Coherencia con esquema DDL
- Migracion necesaria si es produccion
- Validaciones en DTOs
```
### Cambio en Tabla DDL
```yaml
si_modifica: "*.sql (CREATE TABLE, ALTER TABLE)"
buscar_adicional:
- Entity correspondiente en backend
- Otras tablas con FOREIGN KEY
- Vistas que usan la tabla
- Funciones/triggers que referencian
verificar:
- Script recreate-database.sh actualizado
- Migracion para produccion
- Seed data si aplica
```
### Cambio en Servicio Compartido
```yaml
si_modifica: "shared/modules/*.ts"
buscar_adicional:
- Todos los proyectos que importan el modulo
- Proyectos en projects/ que usan shared/
alerta: |
ATENCION: Cambio en modulo compartido.
Este cambio puede afectar multiples proyectos.
Considerar:
1. Versionado del modulo
2. Cambio backward-compatible si es posible
3. Propagacion coordinada a proyectos
```
---
## Ejemplos de Ejecucion
### Ejemplo 1: Modificar Entity
```
Usuario: Modificar UserEntity para agregar campo email_verified
Sistema:
== TRIGGER-ANALISIS-DEPENDENCIAS ACTIVADO ==
### Archivo a Modificar
- Ruta: apps/api/src/modules/users/entities/user.entity.ts
- Tipo: Entity
### Dependencias
| Archivo | Tipo |
|---------|------|
| typeorm | import |
| base.entity.ts | extends |
### Dependientes (12 encontrados)
| Archivo | Linea | Tipo | Requiere Cambio |
|---------|-------|------|-----------------|
| user.service.ts | 5 | import | EVALUAR |
| user.controller.ts | 8 | import | NO |
| auth.service.ts | 12 | import | NO |
| create-user.dto.ts | 3 | reference | SI |
| update-user.dto.ts | 3 | reference | SI |
| user.spec.ts | 10 | import | SI |
... (6 mas)
### Impacto: ALTO (>5 dependientes, cambio de estructura)
### Plan Sugerido
1. Actualizar user.entity.ts (agregar campo)
2. Actualizar create-user.dto.ts (agregar campo opcional)
3. Actualizar update-user.dto.ts (agregar campo)
4. Actualizar user.spec.ts (agregar tests)
5. Verificar migracion de BD necesaria
6. Build + lint + test
```
### Ejemplo 2: Cambio Bajo Impacto
```
Usuario: Refactorizar metodo interno en PaymentService
Sistema:
== TRIGGER-ANALISIS-DEPENDENCIAS ACTIVADO ==
### Archivo a Modificar
- Ruta: apps/api/src/modules/payments/payment.service.ts
- Tipo: Service
### Dependientes (2 encontrados)
| Archivo | Tipo | Requiere Cambio |
|---------|------|-----------------|
| payment.controller.ts | import | NO (metodo interno) |
| payment.spec.ts | import | EVALUAR (tests) |
### Impacto: BAJO (metodo interno, no afecta API publica)
### Plan Sugerido
1. Refactorizar metodo en payment.service.ts
2. Actualizar tests si cambia comportamiento
3. Build + lint
```
---
## Integracion con Modos
### En MODE-FULL
- Se ejecuta siempre en Fase A
- Resultado incluido en plan de Fase P
### En MODE-QUICK
- NO se ejecuta (cambios menores no requieren)
- Si build falla, escalar a MODE-FULL
### En MODE-ANALYSIS
- Se ejecuta para generar reporte de impacto
- No se incluye plan de ejecucion
---
*TRIGGER-ANALISIS-DEPENDENCIAS v1.0.0 - Sistema SAAD*

View File

@ -1,282 +0,0 @@
# TRIGGER-ANTI-DUPLICACION
**ID:** TRIGGER-ANTI-DUPLICACION
**Version:** 1.0.0
**Tipo:** Automatico
**Fase CAPVED:** Se activa en Fase A (Analisis)
---
## Proposito
Prevenir la creacion de objetos duplicados verificando automaticamente el
catalogo global y los inventarios del proyecto antes de crear cualquier
archivo, componente, servicio, entidad o tabla nueva.
---
## Cuando Se Activa
```yaml
activadores:
palabras_clave:
- "crear"
- "nuevo"
- "agregar"
- "implementar"
- "anadir"
- "generar"
tipos_objeto:
- tabla (DDL)
- entity
- service
- controller
- componente
- hook
- modulo
- funcionalidad
ejemplos:
- "Crear nueva tabla de usuarios"
- "Agregar entidad PaymentMethod"
- "Implementar servicio de notificaciones"
- "Nuevo componente de dashboard"
```
---
## Acciones del Trigger
### Paso 1: Verificar Catalogo Global
```yaml
accion: "Buscar en catalogo de funcionalidades reutilizables"
comando: |
grep -i "{funcionalidad}" shared/catalog/CATALOG-INDEX.yml
catalogo_contiene:
- auth (autenticacion y autorizacion)
- session-management (gestion de sesiones)
- rate-limiting (limitacion de tasa)
- notifications (notificaciones email/push)
- multi-tenancy (soporte multi-tenant)
- feature-flags (flags dinamicos)
- websocket (comunicacion tiempo real)
- payments (integracion pagos)
- audit-logs (auditoria)
- portales (templates de portales)
- template-saas (template SaaS completo)
si_existe_en_catalogo:
accion: "DETENER creacion"
mensaje: |
ATENCION: Esta funcionalidad ya existe en el catalogo global.
Ubicacion: shared/catalog/{funcionalidad}/
Documentacion: shared/catalog/{funcionalidad}/README.md
Recomendacion: Usar SIMCO-REUTILIZAR.md para integrar
el modulo existente en lugar de crear uno nuevo.
Si necesita modificaciones, considerar:
1. Extender el modulo existente
2. Contribuir mejoras al catalogo
Para continuar de todos modos, confirmar explicitamente.
```
### Paso 2: Verificar Inventario del Proyecto
```yaml
accion: "Buscar en inventarios del proyecto actual"
comandos:
- grep -i "{nombre}" orchestration/inventarios/MASTER_INVENTORY.yml
- grep -i "{nombre}" orchestration/inventarios/DATABASE_INVENTORY.yml
- grep -i "{nombre}" orchestration/inventarios/BACKEND_INVENTORY.yml
- grep -i "{nombre}" orchestration/inventarios/FRONTEND_INVENTORY.yml
si_existe_en_inventario:
accion: "DETENER creacion"
mensaje: |
ATENCION: Ya existe un objeto similar en este proyecto.
Nombre: {nombre_existente}
Tipo: {tipo}
Ubicacion: {ruta}
Opciones:
1. Reutilizar el existente
2. Extender el existente
3. Renombrar el nuevo si es diferente
Para continuar, clarificar la diferencia.
```
### Paso 3: Buscar Archivos Similares
```yaml
accion: "Buscar archivos con nombre similar en el codigo"
comandos:
- find apps/ libs/ -name "*{nombre}*" -type f
- find src/ -name "*{nombre}*" -type f
- grep -rn "class {Nombre}" apps/ libs/ src/
- grep -rn "interface {Nombre}" apps/ libs/ src/
- grep -rn "CREATE TABLE.*{nombre}" database/
si_encuentra_similar:
accion: "ALERTAR y preguntar"
mensaje: |
ATENCION: Se encontraron archivos similares:
{lista_archivos}
Por favor confirmar:
1. Es el mismo objeto? -> Usar el existente
2. Es diferente? -> Explicar la diferencia
3. Es un duplicado a consolidar? -> Usar @DELETE-SAFE primero
```
### Paso 4: Evaluar Resultado
```yaml
matriz_decision:
existe_en_catalogo:
accion: "REUTILIZAR del catalogo"
simco: "SIMCO-REUTILIZAR.md"
no_encontrado:
accion: "PROCEDER a crear"
simco: "SIMCO-CREAR.md"
existe_identico:
accion: "DETENER"
mensaje: "Ya existe, no crear duplicado"
existe_similar:
accion: "PREGUNTAR"
mensaje: "Clarificar diferencia antes de continuar"
```
---
## Checklist Rapido Anti-Duplicacion
Antes de crear cualquier objeto nuevo, verificar:
```markdown
[ ] Busque funcionalidad en shared/catalog/CATALOG-INDEX.yml
[ ] Busque "{nombre}" en orchestration/inventarios/
[ ] Busque archivos con find en apps/ y src/
[ ] Busque definiciones con grep (class, interface, CREATE TABLE)
[ ] Confirme que NO existe en catalogo NI en proyecto
[ ] Si existe en catalogo, use SIMCO-REUTILIZAR.md
[ ] Si existe similar, pregunte que hacer antes de continuar
```
---
## Formato de Reporte
Cuando se activa este trigger, generar reporte:
```markdown
## Verificacion Anti-Duplicacion
### Objeto a Crear
- Nombre: {nombre}
- Tipo: {tabla|entity|service|component|...}
- Proyecto: {proyecto}
### Resultado Catalogo Global
- Estado: {ENCONTRADO | NO_ENCONTRADO}
- Detalles: {ubicacion si encontrado}
### Resultado Inventario Proyecto
- Estado: {ENCONTRADO | NO_ENCONTRADO}
- Detalles: {nombre y ubicacion si encontrado}
### Resultado Busqueda Codigo
- Estado: {ENCONTRADO | NO_ENCONTRADO}
- Archivos similares: {lista si encontrados}
### Decision
- [ ] PROCEDER: No se encontraron duplicados
- [ ] REUTILIZAR: Usar modulo del catalogo
- [ ] DETENER: Ya existe en proyecto
- [ ] CONSULTAR: Existe similar, clarificar
```
---
## Excepciones
### Cuando NO aplicar este trigger
```yaml
excepciones:
- Archivos de configuracion (no son objetos reutilizables)
- Tests (cada modulo tiene sus propios tests)
- Documentacion (puede haber docs similares)
- Migraciones de BD (tienen timestamp unico)
```
---
## Integracion con SIMCO
### Si se encuentra en catalogo
```yaml
siguiente_paso: "Leer SIMCO-REUTILIZAR.md"
acciones:
1. Leer documentacion del modulo en catalogo
2. Verificar compatibilidad con proyecto
3. Seguir instrucciones de integracion
4. Registrar uso en inventario
```
### Si no se encuentra
```yaml
siguiente_paso: "Leer SIMCO-CREAR.md"
acciones:
1. Proceder con creacion normal
2. Seguir principio Doc-Primero
3. Registrar en inventario al crear
4. Evaluar si debe agregarse al catalogo
```
---
## Ejemplo de Ejecucion
```
Usuario: Crear servicio de autenticacion para erp-construccion
Sistema:
== TRIGGER-ANTI-DUPLICACION ACTIVADO ==
Paso 1: Verificando catalogo global...
Buscando: "auth" en shared/catalog/CATALOG-INDEX.yml
ENCONTRADO: shared/catalog/auth/
Paso 2: Verificando inventario...
(No aplica - se encontro en catalogo)
Paso 3: Busqueda codigo...
(No aplica - se encontro en catalogo)
== RESULTADO ==
DETENIDO: Funcionalidad existe en catalogo global.
Ubicacion: shared/catalog/auth/
Contenido:
- NestJS + JWT + Passport
- Guards, strategies, decorators
- Documentacion completa
Recomendacion:
Usar SIMCO-REUTILIZAR.md para integrar el modulo
de autenticacion del catalogo.
Comando sugerido:
@CREATE-SAFE Integrar modulo auth del catalogo en erp-construccion
```
---
*TRIGGER-ANTI-DUPLICACION v1.0.0 - Sistema SAAD*

View File

@ -1,267 +0,0 @@
# TRIGGER: CIERRE DE TAREA OBLIGATORIO
**Versión:** 1.0.0
**Fecha:** 2026-01-16
**Sistema:** SIMCO v4.0.0
**Alias:** @TRIGGER_CIERRE
---
## RESUMEN EJECUTIVO
Este trigger OBLIGA la ejecución del checklist post-tarea (@DEF_CHK_POST) antes de que cualquier tarea pueda ser marcada como completada.
**PRINCIPIO:** "Una tarea no está completada hasta que su checklist de cierre esté 100% verificado."
---
## CONDICIONES DE ACTIVACIÓN
```yaml
activar_cuando:
- Agente intenta marcar tarea como "completada"
- Agente dice "tarea finalizada" o variantes
- Agente termina la última subtarea del plan
- Agente declara "Done" o "DONE"
- Agente reporta que terminó el trabajo
palabras_clave_trigger:
- "completada"
- "finalizada"
- "terminada"
- "Done"
- "DONE"
- "tarea cerrada"
- "trabajo terminado"
- "implementación completa"
```
---
## ACCIÓN REQUERIDA
### Secuencia Obligatoria
```
AGENTE DECLARA TAREA TERMINADA
┌─────────────────────────────────────┐
│ 1. DETENER │
│ No marcar como completada aún │
└─────────────────┬───────────────────┘
┌─────────────────────────────────────┐
│ 2. CARGAR @DEF_CHK_POST
│ CHECKLIST-POST-TASK.md │
└─────────────────┬───────────────────┘
┌─────────────────────────────────────┐
│ 3. EJECUTAR CHECKLIST │
│ - Gobernanza (BLOQUEANTE) │
│ - Validaciones técnicas │
│ - Coherencia entre capas │
│ - Inventarios │
│ - Trazas │
│ - Propagación │
└─────────────────┬───────────────────┘
┌───────────────┐
│ ¿TODOS PASAN? │
└───────┬───────┘
/ \
Sí No
│ │
▼ ▼
┌──────────────┐ ┌──────────────────────┐
│ 4. MARCAR │ │ 4. MANTENER EN │
│ COMPLETADA │ │ PROGRESO │
└──────────────┘ │ │
│ - Documentar items │
│ faltantes │
│ - Completar antes │
│ de cerrar │
└──────────────────────┘
```
---
## CHECKLIST RÁPIDO DE CIERRE
```markdown
## Verificación Pre-Cierre (@DEF_CHK_POST)
### 0. Gobernanza (BLOQUEANTE - SI FALLA, NO CONTINUAR)
[ ] Carpeta de tarea existe: orchestration/tareas/TASK-{ID}/
[ ] METADATA.yml completo con fases C, E, D
[ ] _INDEX.yml de tareas actualizado
### 1. Validaciones Técnicas
[ ] Build pasa (backend y/o frontend según aplique)
[ ] Lint pasa
[ ] Tests pasan (si existen)
### 2. Coherencia Entre Capas
[ ] DDL ↔ Backend coherente (o excepciones documentadas)
[ ] Backend ↔ Frontend coherente (si aplica)
### 3. Inventarios Actualizados
[ ] DATABASE_INVENTORY.yml (si cambió BD)
[ ] BACKEND_INVENTORY.yml (si cambió BE)
[ ] FRONTEND_INVENTORY.yml (si cambió FE)
[ ] MASTER_INVENTORY.yml (siempre)
### 4. Trazas Actualizadas
[ ] Traza de tarea correspondiente actualizada
[ ] PROXIMA-ACCION.md actualizado
### 5. Propagación Evaluada
[ ] ¿Cambio debe propagarse a otros proyectos? (evaluar)
[ ] Si aplica: propagación ejecutada o documentada como pendiente
```
---
## BLOQUEO
### SI el checklist NO pasa:
```yaml
accion: "BLOQUEAR cierre de tarea"
estado: "EN PROGRESO"
mensaje: |
Tarea NO puede ser marcada como completada.
Items faltantes del checklist:
- [listar items que fallaron]
Acción requerida:
- Completar items faltantes
- Re-ejecutar checklist
- Solo entonces marcar como completada
reintentar: "Después de completar items faltantes"
```
### Items BLOQUEANTES (no negociables):
```yaml
bloqueantes_absolutos:
- Gobernanza (carpeta + METADATA + _INDEX)
- Build que falla
- Tests que fallan
advertencias_serias:
- Inventarios desactualizados
- Trazas desactualizadas
- Coherencia no verificada
advertencias_menores:
- Propagación no evaluada (si proyecto aislado)
```
---
## INTEGRACIÓN CON OTROS TRIGGERS
```yaml
secuencia_de_triggers:
1: "Agente ejecuta trabajo"
2: "Agente intenta cerrar tarea"
3: "→ TRIGGER-CIERRE-TAREA-OBLIGATORIO se activa"
4: "→ Carga @DEF_CHK_POST"
5: "→ TRIGGER-INVENTARIOS-SINCRONIZADOS verifica inventarios"
6: "→ TRIGGER-COHERENCIA-CAPAS verifica coherencia"
7: "→ TRIGGER-DOCUMENTACION-OBLIGATORIA verifica gobernanza"
8: "Si todo pasa: tarea = COMPLETADA"
9: "Si algo falla: tarea = EN PROGRESO"
dependencias:
- "@TRIGGER_INVENTARIOS"
- "@TRIGGER_COHERENCIA"
- "@TRIGGER_DOC"
```
---
## MENSAJES ESTÁNDAR
### Al detectar intento de cierre:
```
⚠️ TRIGGER-CIERRE-TAREA-OBLIGATORIO activado
Antes de marcar la tarea como completada, debo ejecutar el checklist post-tarea.
Ejecutando @DEF_CHK_POST...
```
### Si todo pasa:
```
✅ Checklist post-tarea completado exitosamente
Verificaciones:
- [✓] Gobernanza
- [✓] Validaciones técnicas
- [✓] Coherencia entre capas
- [✓] Inventarios sincronizados
- [✓] Trazas actualizadas
- [✓] Propagación evaluada
TAREA MARCADA COMO COMPLETADA
```
### Si algo falla:
```
❌ Checklist post-tarea NO completado
Items faltantes:
- [ ] {item que falló}
- [ ] {otro item que falló}
Acción: Completar items faltantes antes de cerrar.
Estado: EN PROGRESO (no completada)
```
---
## EXCEPCIONES
```yaml
excepciones_permitidas:
tareas_triviales:
- Corrección de typos
- Actualización de comentarios
- Cambios cosméticos
checklist_reducido:
- Solo Gobernanza
- Solo Validación build
investigación_pura:
- Análisis sin cambios de código
- Spikes exploratorios
checklist_reducido:
- Solo documentación de hallazgos
nota: "Incluso excepciones DEBEN documentar en trazas"
```
---
## REFERENCIAS
| Alias | Archivo |
|-------|---------|
| @DEF_CHK_POST | orchestration/_definitions/checklists/CHECKLIST-POST-TASK.md |
| @TRIGGER_INVENTARIOS | orchestration/directivas/triggers/TRIGGER-INVENTARIOS-SINCRONIZADOS.md |
| @TRIGGER_COHERENCIA | orchestration/directivas/triggers/TRIGGER-COHERENCIA-CAPAS.md |
| @TRIGGER_DOC | orchestration/directivas/triggers/TRIGGER-DOCUMENTACION-OBLIGATORIA.md |
| @CAPVED | orchestration/directivas/principios/PRINCIPIO-CAPVED.md |
---
**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Trigger de Cierre Obligatorio

View File

@ -1,151 +0,0 @@
# TRIGGER: Commit y Push Obligatorio
**Version:** 1.0.0
**Fecha:** 2026-01-16
**Tipo:** AUTOMATICO
**Prioridad:** CRITICA
---
## ACTIVACION
Este trigger se activa AUTOMATICAMENTE cuando:
1. Se completa una tarea que creo o modifico archivos
2. Se marca un todo como "completed"
3. Se reporta al usuario que una tarea esta finalizada
4. Se cambia de contexto a otra tarea
5. Antes de finalizar una sesion de trabajo
---
## ACCION OBLIGATORIA
```
╔══════════════════════════════════════════════════════════════════════════╗
║ ║
║ ANTES DE REPORTAR TAREA COMPLETADA: ║
║ ║
║ 1. Ejecutar: git status ║
║ - Si hay cambios pendientes -> continuar ║
║ - Si esta limpio -> verificar que push se hizo ║
║ ║
║ 2. Si hay cambios: ║
║ git add . ║
║ git commit -m "[TAREA-ID] tipo: descripcion" ║
║ git push origin main ║
║ ║
║ 3. Si hay SUBMODULES modificados: ║
║ - Commitear y push en CADA submodule primero ║
║ - Luego actualizar workspace principal ║
║ ║
║ 4. Verificar sincronizacion: ║
║ git log origin/main..HEAD --oneline ║
║ - Debe estar VACIO (sin commits pendientes de push) ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
```
---
## SECUENCIA WORKSPACE-V2
El workspace-v2 usa submodules. Secuencia obligatoria:
```bash
# PASO 1: Identificar submodules modificados
cd /home/isem/workspace-v2
git status
# PASO 2: Para CADA submodule con cambios
cd projects/{submodule}
git add .
git commit -m "[{submodule}] tipo: descripcion"
git push origin main
cd ../..
# PASO 3: Actualizar workspace principal
git add .
git commit -m "[WORKSPACE] chore: descripcion de cambios"
git push origin main
# PASO 4: Verificar TODO sincronizado
git status # Debe mostrar "clean"
git submodule foreach 'git status' # Todos deben estar "clean"
```
---
## ERRORES A EVITAR
| Error | Consecuencia | Prevencion |
|-------|--------------|------------|
| No hacer push | Archivos solo en local | Siempre push despues de commit |
| Olvidar submodules | Referencias desincronizadas | Commitear submodules primero |
| Reportar sin verificar | Usuario cree que esta hecho | Verificar git status antes |
| Commitear sin push | Cambios no en remoto | Push inmediato tras commit |
---
## VERIFICACION RAPIDA
```bash
# Comando unico para verificar todo sincronizado
git status && git log origin/main..HEAD --oneline
# Salida esperada:
# On branch main
# Your branch is up to date with 'origin/main'.
# nothing to commit, working tree clean
# (sin output del log = todo pusheado)
```
---
## INTEGRACION CON CAPVED
Este trigger se ejecuta en:
- **Fase E (Ejecucion):** Commit atomico por cada cambio logico
- **Fase D (Documentacion):** Commit final con documentacion
- **Post-Tarea:** Push OBLIGATORIO antes de reportar completado
```yaml
fase_D_documentacion:
ultimo_paso: "Commit + Push de todos los cambios"
verificacion: "git status clean + git log empty"
reportar_solo_si: "Todo sincronizado con remoto"
```
---
## MENSAJE AL AGENTE
```
╔══════════════════════════════════════════════════════════════════════════╗
║ ║
║ RECUERDA: Una tarea NO esta completa hasta que: ║
║ ║
║ 1. Todos los archivos estan GUARDADOS en disco ║
║ 2. Todos los cambios estan COMMITEADOS ║
║ 3. Todos los commits estan PUSHEADOS al remoto ║
║ 4. git status muestra "working tree clean" ║
║ 5. git log origin/main..HEAD esta VACIO ║
║ ║
║ SIN PUSH = TRABAJO PERDIDO POTENCIAL ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
```
---
## REFERENCIAS
- SIMCO-GIT.md - Directiva principal de control de versiones
- PRINCIPIO-CAPVED.md - Ciclo de vida de tareas
- SIMCO-TAREA.md - Punto de entrada de tareas
---
**Sistema:** SIMCO v4.0.0
**Mantenido por:** Workspace Admin

View File

@ -1,178 +0,0 @@
# TRIGGER: Fetch Obligatorio Antes de Operar
**Version:** 1.0.0
**Fecha:** 2026-01-16
**Tipo:** AUTOMATICO
**Prioridad:** CRITICA
**Incidente de Origen:** INC-2026-01-16-001
---
## ACTIVACION
Este trigger se activa AUTOMATICAMENTE cuando:
1. Se inicia una sesion de trabajo en el workspace
2. Se va a verificar el estado de git (git status)
3. Se va a realizar cualquier operacion git (commit, push, pull)
4. Se retoma trabajo despues de una pausa
5. Se cambia de contexto entre proyectos/submodulos
---
## ACCION OBLIGATORIA
```
╔══════════════════════════════════════════════════════════════════════════╗
║ ║
║ ANTES DE VERIFICAR ESTADO O REALIZAR OPERACIONES GIT: ║
║ ║
║ 1. Ejecutar: git fetch origin ║
║ → Obtiene el estado actual del repositorio remoto ║
║ ║
║ 2. Verificar: git log HEAD..origin/main --oneline ║
║ → Si hay output = HAY COMMITS REMOTOS QUE NO TIENES ║
║ → Si esta vacio = Estas sincronizado ║
║ ║
║ 3. Si hay commits remotos: ║
║ git pull --no-recurse-submodules ║
║ → Sincroniza tu local con el remoto ║
║ ║
║ 4. AHORA SI verificar estado: ║
║ git status ║
║ ║
║ MOTIVO: Otro agente pudo haber hecho cambios en otra sesion. ║
║ Sin FETCH, reportaras estado incompleto. ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
```
---
## SECUENCIA COMPLETA
```bash
# PASO 1: Fetch del remoto
git fetch origin
# PASO 2: Verificar si hay commits remotos no sincronizados
REMOTE_COMMITS=$(git log HEAD..origin/main --oneline)
# PASO 3: Si hay commits remotos, sincronizar
if [ -n "$REMOTE_COMMITS" ]; then
echo "Commits remotos detectados:"
echo "$REMOTE_COMMITS"
git pull --no-recurse-submodules
fi
# PASO 4: Ahora verificar estado local
git status
```
---
## PARA WORKSPACE CON SUBMODULOS
En workspace-v2 con multiples niveles de submodulos:
```bash
# NIVEL 0: Workspace principal
cd /home/isem/workspace-v2
git fetch origin
git log HEAD..origin/main --oneline
# Si hay output: git pull --no-recurse-submodules
git status
# NIVEL 1: Proyectos (si vas a trabajar en uno)
cd projects/{proyecto}
git fetch origin
git log HEAD..origin/main --oneline
# Si hay output: git pull --no-recurse-submodules
git status
# NIVEL 2: Subrepositorios (si vas a trabajar en uno)
cd {componente} # backend, database, frontend
git fetch origin
git log HEAD..origin/main --oneline
# Si hay output: git pull --no-recurse-submodules
git status
```
---
## ERRORES A EVITAR
| Error | Consecuencia | Prevencion |
|-------|--------------|------------|
| Solo hacer git status | No detectar commits remotos | SIEMPRE fetch primero |
| Reportar "clean" sin fetch | Usuario confundido | Seguir secuencia completa |
| Asumir que no hay cambios | Desincronizacion | Verificar con log HEAD..origin |
| Olvidar en submodulos | Referencias inconsistentes | Fetch en cada nivel |
---
## INCIDENTE DE ORIGEN
### INC-2026-01-16-001
**Descripcion:** Un agente reporto "working tree clean" cuando habia un commit
remoto (c027da53) que no habia sido detectado.
**Causa Raiz:** No se ejecuto `git fetch` antes de verificar estado con `git status`.
**Impacto:** Usuario confundido sobre el estado real del repositorio.
**Resolucion:**
- Creado este trigger obligatorio
- Actualizado SIMCO-GIT.md v1.2.0 con regla critica
- Actualizado SIMCO-SUBMODULOS.md v1.1.0 con secuencia obligatoria
- Documentado en TRAZA-GIT-OPERATIONS.md
---
## VERIFICACION RAPIDA
```bash
# Comando unico para verificar sincronizacion completa
git fetch origin && git log HEAD..origin/main --oneline && git status
# Salida esperada si todo sincronizado:
# (sin output del log)
# On branch main
# Your branch is up to date with 'origin/main'.
# nothing to commit, working tree clean
```
---
## INTEGRACION CON CAPVED
Este trigger se ejecuta en:
- **Pre-Tarea:** SIEMPRE antes de iniciar cualquier tarea
- **Pre-Commit:** Antes de hacer commit (verificar no hay conflictos)
- **Pre-Push:** Antes de push (verificar no hay rechazos pendientes)
- **Post-Pausa:** Al retomar trabajo despues de interrupcion
```yaml
pre_tarea:
primer_paso: "git fetch origin"
verificar: "git log HEAD..origin/main"
sincronizar_si_necesario: "git pull --no-recurse-submodules"
luego: "Continuar con la tarea"
```
---
## REFERENCIAS
- `orchestration/directivas/simco/SIMCO-GIT.md` - Directiva principal git (v1.2.0)
- `orchestration/directivas/simco/SIMCO-SUBMODULOS.md` - Protocolo submodulos (v1.1.0)
- `orchestration/SUBMODULES-POLICY.yml` - Politicas de sincronizacion (v1.1.0)
- `orchestration/trazas/TRAZA-GIT-OPERATIONS.md` - Registro de operaciones
- `orchestration/directivas/triggers/TRIGGER-COMMIT-PUSH-OBLIGATORIO.md` - Trigger complementario
---
**Sistema:** SIMCO v4.0.0
**Mantenido por:** Workspace Admin

View File

@ -1,160 +0,0 @@
# ═══════════════════════════════════════════════════════════════════════════════
# TRIGGER-INICIO-TAREA
# ═══════════════════════════════════════════════════════════════════════════════
#
# Version: 1.0.0
# Creado: 2026-01-16
# Origen: Auditoría post-tarea TASK-2026-01-16-004
# Proposito: Garantizar creación de carpeta de tarea ANTES de ejecutar código
#
# ═══════════════════════════════════════════════════════════════════════════════
## CONDICION DE ACTIVACION
Este trigger se activa **AUTOMATICAMENTE** cuando:
1. Se recibe una solicitud que implica **modificar código**
2. Se recibe una solicitud que implica **crear archivos nuevos**
3. Se usa `@FULL` o `@CREATE-SAFE` o `@MODIFY-SAFE`
4. El primer item de TodoWrite incluye una tarea de implementación
**EXCEPCION:** No aplica para:
- Modo `@QUICK` en fixes menores (typos, config simple)
- Modo `@ANALYSIS` (solo investigación)
- Tareas puramente de lectura/exploración
---
## ACCION OBLIGATORIA
### Paso 1: Generar ID de Tarea
```
TASK-{YYYY-MM-DD}-{NNN}
```
Donde:
- `YYYY-MM-DD`: Fecha actual
- `NNN`: Siguiente secuencial del día (consultar `_INDEX.yml`)
### Paso 2: Crear Estructura de Carpeta
```bash
# Ruta base
orchestration/tareas/TASK-{ID}/
# Archivos mínimos obligatorios
├── METADATA.yml # Copiar de _templates/TASK-TEMPLATE/
├── 01-CONTEXTO.md # Llenar con clasificación inicial
└── (otros según avance)
```
### Paso 3: Registrar en Inventario
Agregar entrada en `tareas_activas` de `_INDEX.yml`:
```yaml
tareas_activas:
- task_id: "TASK-2026-01-XX-NNN"
titulo: "Título descriptivo"
agente: "PERFIL-AGENTE"
estado: "en_progreso"
fase: "C" # Inicia en Contexto
proyecto: "nombre-proyecto"
```
### Paso 4: Incluir en TodoWrite
El **PRIMER item** de TodoWrite debe ser:
```
- Crear carpeta de tarea TASK-{ID} en orchestration/tareas/
```
O si ya existe:
```
- Documentar contexto en TASK-{ID}/01-CONTEXTO.md
```
---
## CHECKPOINT DE VALIDACION
**ANTES de ejecutar cualquier código (fase E):**
```
[ ] ¿Existe carpeta orchestration/tareas/TASK-{ID}/?
[ ] ¿Existe METADATA.yml con información básica?
[ ] ¿Se registró en _INDEX.yml como tarea activa?
[ ] ¿TodoWrite incluye la tarea de documentación?
```
**SI algún checkbox falla:** BLOQUEAR ejecución hasta completar.
---
## INTEGRACION CON TODOWRITE
Cuando se use TodoWrite para planificar una tarea de código, incluir SIEMPRE:
```typescript
// Ejemplo de TodoWrite correcto
[
{ content: "Crear carpeta TASK-2026-01-16-004", status: "pending" },
{ content: "Documentar contexto y clasificación", status: "pending" },
{ content: "Analizar dependencias", status: "pending" },
// ... tareas técnicas ...
{ content: "Actualizar _INDEX.yml al completar", status: "pending" }
]
```
---
## REFERENCIAS
- `@TAREAS` - orchestration/tareas/
- `@NUEVA-TAREA` - orchestration/tareas/_templates/TASK-TEMPLATE/
- `@TRIGGER-DOC` - TRIGGER-DOCUMENTACION-OBLIGATORIA.md
- `@MAPA-DOC` - orchestration/MAPA-DOCUMENTACION.yml
---
## CASO DE ESTUDIO: TASK-2026-01-16-004
Esta directiva nace del análisis post-mortem de la tarea:
**"Integración de Servicios de API en Trading Platform Frontend"**
### Problema Detectado
- La tarea se ejecutó correctamente (build pasa, código funcional)
- PERO no se creó carpeta de tarea antes de ejecutar
- No se documentaron fases C, A, P, V formalmente
- No se actualizó _INDEX.yml hasta auditoría posterior
### Causa Raíz
1. No existía trigger bloqueante para creación de carpeta
2. TodoWrite no recordaba incluir checkpoint de gobernanza
3. Las reglas estaban en CLAUDE.md pero sin enforcement automático
### Solución Implementada
1. Crear este trigger (TRIGGER-INICIO-TAREA)
2. Documentación retroactiva de la tarea
3. Actualización de _INDEX.yml
4. Propuesta de mejora a flujo de TodoWrite
---
## METRICAS DE CUMPLIMIENTO
| Métrica | Objetivo | Medición |
|---------|----------|----------|
| Tareas con carpeta antes de E | 100% | `tareas_con_carpeta / total_tareas` |
| Fases documentadas por tarea | >= 3 | `promedio(fases_doc)` |
| _INDEX.yml actualizado | 100% | `tareas_en_index / total_tareas` |
---
# ═══════════════════════════════════════════════════════════════════════════════
# FIN DEL TRIGGER
# ═══════════════════════════════════════════════════════════════════════════════

View File

@ -1,281 +0,0 @@
# TRIGGER: INVENTARIOS SINCRONIZADOS
**Versión:** 1.0.0
**Fecha:** 2026-01-16
**Sistema:** SIMCO v4.0.0
**Alias:** @TRIGGER_INVENTARIOS
---
## RESUMEN EJECUTIVO
Este trigger OBLIGA a mantener los inventarios sincronizados con el código real. Se activa al completar cualquier tarea que modifique código o estructura.
**PRINCIPIO:** "Los inventarios son la fuente de verdad. Si no está en el inventario, no existe oficialmente."
---
## CONDICIONES DE ACTIVACIÓN
```yaml
activar_cuando:
- Se completa cualquier tarea con cambios de código
- Se crea/modifica/elimina: tabla, entity, service, módulo, componente
- Se ejecuta auditoría de proyecto
- Han pasado más de 7 días desde última sincronización
```
---
## INVENTARIOS REQUERIDOS POR PROYECTO
```yaml
inventarios_obligatorios:
DATABASE_INVENTORY.yml:
contenido:
- Lista completa de schemas
- Lista completa de tablas por schema
- Conteo de funciones, triggers, policies
- Estado de cada objeto (active/deprecated/planned)
actualizar_cuando:
- Crear/modificar/eliminar tabla
- Crear/modificar/eliminar schema
- Agregar/modificar funciones o triggers
BACKEND_INVENTORY.yml:
contenido:
- Lista completa de módulos
- Lista completa de entities por módulo
- Lista completa de services por módulo
- Conteo de endpoints por módulo
- Estado de cada objeto
actualizar_cuando:
- Crear/modificar/eliminar entity
- Crear/modificar/eliminar service
- Crear/modificar/eliminar módulo
- Agregar/modificar endpoints
FRONTEND_INVENTORY.yml:
contenido:
- Lista completa de componentes
- Lista completa de páginas
- Lista completa de hooks/stores
- Estado de cada objeto
actualizar_cuando:
- Crear/modificar/eliminar componente
- Crear/modificar/eliminar página
- Crear/modificar/eliminar hook/store
MASTER_INVENTORY.yml:
contenido:
- Resumen de todos los inventarios
- Totales consolidados
- Última fecha de sincronización
- Score de coherencia
actualizar_cuando:
- Se actualiza cualquier otro inventario
```
---
## VERIFICACIONES DE SINCRONIZACIÓN
### 1. Verificar Cobertura de Inventarios
```yaml
cobertura_minima:
DATABASE_INVENTORY:
schemas: "100% de schemas en DDL"
tablas: "100% de tablas en DDL"
funciones: "100% de funciones en DDL"
BACKEND_INVENTORY:
modulos: "100% de carpetas en modules/"
entities: "100% de archivos .entity.ts"
services: "100% de archivos .service.ts"
FRONTEND_INVENTORY:
componentes: "100% de archivos .tsx en components/"
paginas: "100% de archivos en pages/"
stores: "100% de stores/hooks"
```
### 2. Verificar Consistencia de Conteos
```yaml
validacion_conteos:
comparar:
- "Conteo en inventario vs archivos reales"
- "Conteo reportado en _INDEX.yml vs inventario"
- "Conteo entre inventarios relacionados"
tolerancia: "0% - Debe ser exacto"
si_discrepancia:
accion: "BLOQUEAR hasta sincronizar"
```
### 3. Verificar Actualización Reciente
```yaml
frescura:
maxima_antiguedad: "7 días"
verificar:
- "Fecha de última actualización en inventario"
- "Comparar con fecha de último commit en código"
si_desactualizado:
accion: "ADVERTIR y solicitar sincronización"
```
---
## PROCESO DE SINCRONIZACIÓN
### Sincronización Manual
```bash
# El agente debe ejecutar para cada inventario:
# 1. Contar objetos reales
find apps/database/ddl -name "*.sql" -exec grep -l "CREATE TABLE" {} \; | wc -l
find apps/backend/src/modules -name "*.entity.ts" | wc -l
find apps/backend/src/modules -name "*.service.ts" | wc -l
# 2. Comparar con inventario
# 3. Actualizar inventario si hay discrepancia
# 4. Actualizar timestamp de sincronización
```
### Campos Obligatorios en Inventarios
```yaml
metadata_obligatoria:
version: "Semver del inventario"
updated: "Fecha ISO de última actualización"
updated_by: "Agente que actualizó"
sync_status: "SYNCED | OUT_OF_SYNC | PARTIAL"
coverage:
total_expected: "N objetos esperados"
total_documented: "N objetos documentados"
percentage: "100%"
```
---
## CHECKLIST DE SINCRONIZACIÓN
### Al Completar Tarea
```markdown
## Verificación de Inventarios
### DATABASE_INVENTORY.yml
[ ] Conteo de schemas correcto
[ ] Conteo de tablas correcto
[ ] Nuevos objetos agregados
[ ] Objetos eliminados removidos
[ ] Timestamp actualizado
### BACKEND_INVENTORY.yml
[ ] Conteo de módulos correcto
[ ] Conteo de entities correcto
[ ] Conteo de services correcto
[ ] Conteo de endpoints correcto
[ ] Nuevos objetos agregados
[ ] Timestamp actualizado
### FRONTEND_INVENTORY.yml
[ ] Conteo de componentes correcto
[ ] Conteo de páginas correcto
[ ] Nuevos objetos agregados
[ ] Timestamp actualizado
### MASTER_INVENTORY.yml
[ ] Totales consolidados correctos
[ ] Score de coherencia actualizado
[ ] Timestamp actualizado
```
---
## INTEGRACIÓN CON TRIGGER-COHERENCIA-CAPAS
```yaml
secuencia:
1: "TRIGGER-COHERENCIA-CAPAS verifica estructura"
2: "TRIGGER-INVENTARIOS-SINCRONIZADOS verifica documentación"
3: "TRIGGER-DOCUMENTACION-OBLIGATORIA verifica gobernanza"
dependencia:
- "Coherencia debe pasar ANTES de sincronizar inventarios"
- "Inventarios deben estar sincronizados ANTES de documentar"
```
---
## MENSAJES DE ERROR
```yaml
errores:
E-INV-001:
mensaje: "Inventario desactualizado (más de 7 días)"
accion: "Ejecutar sincronización de inventario"
bloqueante: false (advertencia)
E-INV-002:
mensaje: "Discrepancia de conteo en inventario"
accion: "Sincronizar inventario con código real"
bloqueante: true
E-INV-003:
mensaje: "Objeto en código no documentado en inventario"
accion: "Agregar objeto al inventario"
bloqueante: true
E-INV-004:
mensaje: "Objeto en inventario no existe en código"
accion: "Remover objeto del inventario o restaurar código"
bloqueante: true
E-INV-005:
mensaje: "Inventario faltante"
accion: "Crear inventario siguiendo template"
bloqueante: true
```
---
## AUTOMATIZACIÓN FUTURA
```yaml
scripts_recomendados:
sync-database-inventory:
descripcion: "Sincronizar DATABASE_INVENTORY.yml automáticamente"
implementar_en: "scripts/sync-inventories.sh"
sync-backend-inventory:
descripcion: "Sincronizar BACKEND_INVENTORY.yml automáticamente"
implementar_en: "scripts/sync-inventories.sh"
validate-inventories:
descripcion: "Validar que todos los inventarios estén sincronizados"
implementar_en: "scripts/validate-inventories.sh"
estado: "DOCUMENTADO - Por implementar"
```
---
## REFERENCIAS
| Alias | Descripción |
|-------|-------------|
| @TRIGGER_INVENTARIOS | Este trigger |
| @TRIGGER_COHERENCIA | Coherencia entre capas |
| @DEF_CHK_POST | Checklist post-tarea |
---
**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Trigger de Sincronización

View File

@ -0,0 +1,804 @@
# =============================================================================
# ENVIRONMENT-INVENTORY.yml - CLINICA-DENTAL
# =============================================================================
# Inventario Completo de Entorno de Desarrollo y Produccion
# Generado por: @PERFIL_DEVENV
# Basado en: orchestration/templates/TEMPLATE-ENVIRONMENT-INVENTORY.yml
# =============================================================================
version: "1.1.0"
fecha_creacion: "2026-01-04"
fecha_actualizacion: "2026-01-04"
responsable: "@PERFIL_DEVENV"
# -----------------------------------------------------------------------------
# IDENTIFICACION DEL PROYECTO
# -----------------------------------------------------------------------------
proyecto:
nombre: "Clinica Dental"
alias: "clinica-dental"
codigo: "CD"
nivel: "NIVEL_2B.3"
tipo: "vertical-especializada"
estado: "desarrollo"
descripcion: "Sistema de gestion para clinicas dentales y odontologicas"
parent: "erp-clinicas"
herencia:
- erp-core
- erp-clinicas
normativas:
- "NOM-024-SSA3-2012 (Expediente clinico electronico)"
- "NOM-013-SSA2-2015 (Prevencion y control enfermedades bucales)"
# -----------------------------------------------------------------------------
# HERRAMIENTAS Y RUNTIME
# -----------------------------------------------------------------------------
herramientas:
runtime:
node:
version: "20.x"
version_minima: "18.x"
requerido: true
notas: "LTS recomendado para NestJS y React"
python:
version: ""
requerido: false
notas: "No requerido para este proyecto"
package_managers:
npm:
version: "10.x"
requerido: true
pnpm:
version: "8.x"
requerido: false
notas: "Alternativa opcional"
build_tools:
- nombre: "Vite"
version: "5.x"
uso: "Frontend build y dev server"
- nombre: "TypeScript"
version: "5.x"
uso: "Compilacion de codigo"
- nombre: "NestJS CLI"
version: "10.x"
uso: "Backend scaffolding y build"
linters:
- nombre: "ESLint"
version: "8.x"
config: ".eslintrc.js"
- nombre: "Prettier"
version: "3.x"
config: ".prettierrc"
testing:
- nombre: "Jest"
version: "29.x"
tipo: "unit backend"
config: "jest.config.js"
- nombre: "Vitest"
version: "1.x"
tipo: "unit frontend"
config: "vitest.config.ts"
- nombre: "Supertest"
version: "6.x"
tipo: "e2e"
config: "jest-e2e.config.js"
# -----------------------------------------------------------------------------
# SERVICIOS Y PUERTOS
# -----------------------------------------------------------------------------
servicios:
frontend:
nombre: "clinica-dental-frontend"
framework: "React"
version: "18.x"
puerto: 3130
comando_dev: "npm run dev"
comando_build: "npm run build"
comando_preview: "npm run preview"
ubicacion: "apps/frontend/"
url_local: "http://localhost:3130"
build_output: "dist/"
backend:
nombre: "clinica-dental-backend"
framework: "NestJS"
version: "10.x"
puerto: 3131
comando_dev: "npm run start:dev"
comando_build: "npm run build"
comando_prod: "npm run start:prod"
ubicacion: "apps/backend/"
url_local: "http://localhost:3131"
api_prefix: "/api/v1"
swagger_url: "http://localhost:3131/api/docs"
# -----------------------------------------------------------------------------
# BASE DE DATOS - CONFIGURACION COMPLETA
# -----------------------------------------------------------------------------
base_de_datos:
principal:
engine: "PostgreSQL"
version: "15"
host_variable: "DB_HOST"
puerto_variable: "DB_PORT"
ambientes:
development:
host: "localhost"
puerto: 5441
nombre: "clinica_dental_dev"
usuario: "dental_dev"
password_ref: "DB_PASSWORD en .env"
ssl: false
pool_size: 10
conexion: "postgresql://dental_dev:{password}@localhost:5441/clinica_dental_dev"
test:
host: "localhost"
puerto: 5441
nombre: "clinica_dental_test"
usuario: "dental_dev"
password_ref: "DB_PASSWORD en .env"
ssl: false
pool_size: 5
conexion: "postgresql://dental_dev:{password}@localhost:5441/clinica_dental_test"
staging:
host: "${DB_HOST}"
puerto: 5432
nombre: "clinica_dental_staging"
usuario: "dental_staging"
password_ref: "DB_PASSWORD en variables de CI/CD"
ssl: true
pool_size: 20
conexion: "postgresql://dental_staging:{password}@${DB_HOST}:5432/clinica_dental_staging?sslmode=require"
production:
host: "${DB_HOST}"
puerto: 5432
nombre: "clinica_dental_prod"
usuario: "dental_prod"
password_ref: "DB_PASSWORD en secrets manager"
ssl: true
pool_size: 50
conexion: "postgresql://dental_prod:{password}@${DB_HOST}:5432/clinica_dental_prod?sslmode=require"
schemas:
- nombre: "public"
descripcion: "Schema principal PostgreSQL"
- nombre: "dental"
descripcion: "Entidades odontologicas (odontograma, piezas, tratamientos, ortodoncia)"
- nombre: "clinical"
descripcion: "Heredado de erp-clinicas (consultorios, citas, historiales)"
- nombre: "financial"
descripcion: "Heredado de erp-core (pagos, facturacion, presupuestos)"
- nombre: "hr"
descripcion: "Heredado de erp-core (empleados, especialidades)"
- nombre: "inventory"
descripcion: "Heredado de erp-core (materiales, insumos dentales)"
scripts_inicializacion:
orden:
- "database/init/00-extensions.sql"
- "database/init/01-schemas.sql"
- "database/schemas/01-dental-schema-ddl.sql"
- "database/seeds/fase8/01-dental-catalogos.sql"
- "database/seeds/fase8/02-piezas-dentales-fdi.sql"
datos_iniciales:
piezas_dentales:
total: 52
nomenclatura: "FDI (Federation Dentaire Internationale)"
cuadrantes:
- id: 1
nombre: "Superior derecho"
piezas: "18-11"
tipo: "permanente"
- id: 2
nombre: "Superior izquierdo"
piezas: "21-28"
tipo: "permanente"
- id: 3
nombre: "Inferior izquierdo"
piezas: "31-38"
tipo: "permanente"
- id: 4
nombre: "Inferior derecho"
piezas: "41-48"
tipo: "permanente"
- id: 5
nombre: "Superior derecho temporal"
piezas: "55-51"
tipo: "temporal"
- id: 6
nombre: "Superior izquierdo temporal"
piezas: "61-65"
tipo: "temporal"
- id: 7
nombre: "Inferior izquierdo temporal"
piezas: "71-75"
tipo: "temporal"
- id: 8
nombre: "Inferior derecho temporal"
piezas: "81-85"
tipo: "temporal"
redis:
host_variable: "REDIS_HOST"
puerto_variable: "REDIS_PORT"
ambientes:
development:
host: "localhost"
puerto: 6388
database: 0
password: ""
conexion: "redis://localhost:6388/0"
production:
host: "${REDIS_HOST}"
puerto: 6379
database: 0
password_ref: "REDIS_PASSWORD en secrets"
conexion: "redis://:${REDIS_PASSWORD}@${REDIS_HOST}:6379/0"
uso:
- "Cache de sesiones"
- "Cache de odontogramas"
- "Rate limiting"
- "Queue de tareas (Bull)"
# -----------------------------------------------------------------------------
# VARIABLES DE ENTORNO - DESARROLLO
# -----------------------------------------------------------------------------
variables_entorno:
archivos:
ejemplo: ".env.example"
desarrollo: ".env"
test: ".env.test"
produccion: ".env.production"
development:
- nombre: "NODE_ENV"
valor: "development"
descripcion: "Ambiente de ejecucion"
requerido: true
sensible: false
- nombre: "APP_NAME"
valor: "clinica-dental"
descripcion: "Nombre de la aplicacion"
requerido: true
sensible: false
- nombre: "APP_VERSION"
valor: "1.0.0"
descripcion: "Version de la aplicacion"
requerido: false
sensible: false
# Puertos
- nombre: "FRONTEND_PORT"
valor: "3130"
descripcion: "Puerto del frontend React"
requerido: true
sensible: false
- nombre: "BACKEND_PORT"
valor: "3131"
descripcion: "Puerto del backend NestJS"
requerido: true
sensible: false
# Base de datos
- nombre: "DB_HOST"
valor: "localhost"
descripcion: "Host de PostgreSQL"
requerido: true
sensible: false
- nombre: "DB_PORT"
valor: "5441"
descripcion: "Puerto de PostgreSQL"
requerido: true
sensible: false
- nombre: "DB_NAME"
valor: "clinica_dental_dev"
descripcion: "Nombre de la base de datos"
requerido: true
sensible: false
- nombre: "DB_USER"
valor: "dental_dev"
descripcion: "Usuario de PostgreSQL"
requerido: true
sensible: false
- nombre: "DB_PASSWORD"
valor: ""
descripcion: "Password de PostgreSQL"
requerido: true
sensible: true
generacion: "openssl rand -base64 32"
- nombre: "DATABASE_URL"
valor: "postgresql://dental_dev:${DB_PASSWORD}@localhost:5441/clinica_dental_dev"
descripcion: "Connection string completo"
requerido: true
sensible: true
# Redis
- nombre: "REDIS_HOST"
valor: "localhost"
descripcion: "Host de Redis"
requerido: true
sensible: false
- nombre: "REDIS_PORT"
valor: "6388"
descripcion: "Puerto de Redis"
requerido: true
sensible: false
- nombre: "REDIS_URL"
valor: "redis://localhost:6388/0"
descripcion: "Connection string de Redis"
requerido: true
sensible: false
# Autenticacion
- nombre: "JWT_SECRET"
valor: ""
descripcion: "Secreto para firmar JWT (min 32 caracteres)"
requerido: true
sensible: true
generacion: "openssl rand -base64 64"
- nombre: "JWT_EXPIRES_IN"
valor: "24h"
descripcion: "Tiempo de expiracion del access token"
requerido: true
sensible: false
- nombre: "JWT_REFRESH_EXPIRES_IN"
valor: "7d"
descripcion: "Tiempo de expiracion del refresh token"
requerido: true
sensible: false
# CORS
- nombre: "FRONTEND_URL"
valor: "http://localhost:3130"
descripcion: "URL del frontend para CORS"
requerido: true
sensible: false
- nombre: "ALLOWED_ORIGINS"
valor: "http://localhost:3130,http://localhost:3131"
descripcion: "Origenes permitidos (comma separated)"
requerido: true
sensible: false
# Logging
- nombre: "LOG_LEVEL"
valor: "debug"
descripcion: "Nivel de logging (debug, info, warn, error)"
requerido: false
sensible: false
- nombre: "LOG_FORMAT"
valor: "pretty"
descripcion: "Formato de logs (pretty, json)"
requerido: false
sensible: false
# File Storage (radiografias, documentos)
- nombre: "STORAGE_TYPE"
valor: "local"
descripcion: "Tipo de storage (local, s3, minio)"
requerido: false
sensible: false
- nombre: "STORAGE_PATH"
valor: "./uploads"
descripcion: "Path para almacenamiento local"
requerido: false
sensible: false
- nombre: "MAX_FILE_SIZE"
valor: "20971520"
descripcion: "Tamano maximo de archivo en bytes (20MB para radiografias)"
requerido: false
sensible: false
- nombre: "ALLOWED_FILE_TYPES"
valor: "image/jpeg,image/png,image/dicom,application/pdf"
descripcion: "Tipos de archivo permitidos"
requerido: false
sensible: false
# Email (opcional)
- nombre: "SMTP_HOST"
valor: "localhost"
descripcion: "Host SMTP para emails"
requerido: false
sensible: false
- nombre: "SMTP_PORT"
valor: "1025"
descripcion: "Puerto SMTP (1025 para MailHog)"
requerido: false
sensible: false
# Configuracion Dental Especifica
- nombre: "DENTAL_FDI_NOTATION"
valor: "true"
descripcion: "Usar notacion FDI para piezas dentales"
requerido: false
sensible: false
- nombre: "ODONTOGRAM_VERSION"
valor: "2.0"
descripcion: "Version del formato de odontograma"
requerido: false
sensible: false
production:
notas: |
En produccion, las siguientes variables deben configurarse
via secrets manager o variables de CI/CD:
- DB_PASSWORD (secreto)
- JWT_SECRET (secreto)
- REDIS_PASSWORD (secreto)
- AWS_ACCESS_KEY_ID (si usa S3)
- AWS_SECRET_ACCESS_KEY (si usa S3)
IMPORTANTE - Cumplimiento Normativo:
- NOM-024-SSA3-2012: Logs de auditoria obligatorios
- Encriptacion de datos sensibles (historiales)
- Backups diarios con retencion minima 5 anos
diferencias:
- nombre: "NODE_ENV"
valor: "production"
- nombre: "LOG_LEVEL"
valor: "info"
- nombre: "LOG_FORMAT"
valor: "json"
- nombre: "DB_PORT"
valor: "5432"
- nombre: "REDIS_PORT"
valor: "6379"
- nombre: "STORAGE_TYPE"
valor: "s3"
- nombre: "AUDIT_ENABLED"
valor: "true"
- nombre: "DATA_ENCRYPTION"
valor: "true"
# -----------------------------------------------------------------------------
# CONTENEDORES DOCKER
# -----------------------------------------------------------------------------
docker:
compose_file: "docker-compose.yml"
compose_dev: "docker-compose.dev.yml"
compose_prod: "docker-compose.prod.yml"
services:
- nombre: "db"
imagen: "postgres:15-alpine"
puerto_host: 5441
puerto_container: 5432
variables:
POSTGRES_DB: "clinica_dental_dev"
POSTGRES_USER: "dental_dev"
POSTGRES_PASSWORD: "${DB_PASSWORD}"
volumes:
- "postgres_data:/var/lib/postgresql/data"
healthcheck: "pg_isready -U dental_dev"
- nombre: "redis"
imagen: "redis:7-alpine"
puerto_host: 6388
puerto_container: 6379
volumes:
- "redis_data:/data"
healthcheck: "redis-cli ping"
- nombre: "mailhog"
imagen: "mailhog/mailhog"
puerto_smtp: 1025
puerto_web: 8025
uso: "Testing de emails en desarrollo"
volumes:
- nombre: "postgres_data"
descripcion: "Datos persistentes de PostgreSQL"
- nombre: "redis_data"
descripcion: "Datos persistentes de Redis"
- nombre: "uploads_data"
descripcion: "Radiografias y documentos"
networks:
- nombre: "clinica_dental_network"
driver: "bridge"
# -----------------------------------------------------------------------------
# MIGRACIONES Y SEEDS
# -----------------------------------------------------------------------------
migraciones:
herramienta: "TypeORM"
directorio: "apps/backend/src/database/migrations"
comandos:
generar: "npm run migration:generate -- -n NombreMigracion"
ejecutar: "npm run migration:run"
revertir: "npm run migration:revert"
mostrar: "npm run migration:show"
seeds:
directorio: "database/seeds"
orden:
- "fase8/01-dental-catalogos.sql"
- "fase8/02-piezas-dentales-fdi.sql"
comandos:
ejecutar: "npm run seed"
desarrollo: "npm run seed:dev"
# -----------------------------------------------------------------------------
# SCRIPTS DE DESARROLLO
# -----------------------------------------------------------------------------
scripts:
setup:
descripcion: "Configurar entorno desde cero"
pasos:
- comando: "npm install"
descripcion: "Instalar dependencias"
- comando: "cp .env.example .env"
descripcion: "Crear archivo de configuracion"
- comando: "docker-compose up -d db redis"
descripcion: "Levantar servicios de infraestructura"
- comando: "npm run db:create"
descripcion: "Crear base de datos"
- comando: "npm run migration:run"
descripcion: "Ejecutar migraciones"
- comando: "npm run seed"
descripcion: "Cargar datos iniciales (incluye 52 piezas FDI)"
desarrollo:
frontend: "cd apps/frontend && npm run dev"
backend: "cd apps/backend && npm run start:dev"
ambos: "npm run dev:all"
docker: "docker-compose up -d"
testing:
unit: "npm run test"
unit_watch: "npm run test:watch"
e2e: "npm run test:e2e"
coverage: "npm run test:cov"
build:
frontend: "cd apps/frontend && npm run build"
backend: "cd apps/backend && npm run build"
docker: "docker-compose -f docker-compose.prod.yml build"
database:
create: "npm run db:create"
drop: "npm run db:drop"
reset: "npm run db:reset"
migrations_run: "npm run migration:run"
migrations_revert: "npm run migration:revert"
seed: "npm run seed"
linting:
lint: "npm run lint"
lint_fix: "npm run lint:fix"
format: "npm run format"
# -----------------------------------------------------------------------------
# INSTRUCCIONES DE SETUP
# -----------------------------------------------------------------------------
setup_instrucciones: |
## Setup del Entorno de Desarrollo - Clinica Dental
### Prerequisitos
- Node.js 20.x (LTS)
- PostgreSQL 15 (o Docker)
- Redis 7 (o Docker)
- npm 10.x
- Git
### Opcion 1: Setup con Docker (Recomendado)
```bash
# 1. Clonar repositorio
git clone <url_repo>
cd clinica-dental
# 2. Instalar dependencias
npm install
# 3. Configurar variables de entorno
cp .env.example .env
# Editar .env - generar passwords seguros:
# openssl rand -base64 32 # para DB_PASSWORD
# openssl rand -base64 64 # para JWT_SECRET
# 4. Levantar infraestructura
docker-compose up -d db redis
# 5. Crear base de datos y ejecutar migraciones
npm run db:create
npm run migration:run
npm run seed # Carga 52 piezas dentales FDI
# 6. Iniciar desarrollo
npm run dev:all
```
### Opcion 2: Setup con PostgreSQL Local
```bash
# 1-3. Igual que arriba
# 4. Crear usuario y base de datos en PostgreSQL
sudo -u postgres psql
CREATE USER dental_dev WITH PASSWORD 'tu_password';
CREATE DATABASE clinica_dental_dev OWNER dental_dev;
GRANT ALL PRIVILEGES ON DATABASE clinica_dental_dev TO dental_dev;
\q
# 5. Configurar Redis local o Docker
docker run -d --name redis-dental -p 6388:6379 redis:7-alpine
# 6-7. Continuar con migraciones y seeds
```
### Verificar Instalacion
- Frontend: http://localhost:3130
- Backend API: http://localhost:3131/api/v1
- Swagger Docs: http://localhost:3131/api/docs
- Health Check: http://localhost:3131/health
### Usuarios de Prueba (despues de seed)
- Admin: admin@clinica-dental.local / Admin123!
- Odontologo: doctor@clinica-dental.local / Doctor123!
- Recepcion: recepcion@clinica-dental.local / Recep123!
### Nomenclatura Dental FDI
El sistema usa la nomenclatura FDI (Federation Dentaire Internationale):
- Cuadrante 1: Superior derecho (18-11)
- Cuadrante 2: Superior izquierdo (21-28)
- Cuadrante 3: Inferior izquierdo (31-38)
- Cuadrante 4: Inferior derecho (41-48)
- Cuadrantes 5-8: Denticion temporal
# -----------------------------------------------------------------------------
# TROUBLESHOOTING
# -----------------------------------------------------------------------------
troubleshooting:
- problema: "Puerto 3130 o 3131 en uso"
solucion: |
Verificar con: lsof -i :3130
Terminar proceso: kill -9 <PID>
O cambiar puertos en .env
- problema: "Error de conexion a PostgreSQL"
solucion: |
1. Verificar que PostgreSQL esta corriendo:
docker-compose ps
# o: systemctl status postgresql
2. Verificar credenciales en .env
3. Verificar que la BD existe:
psql -h localhost -p 5441 -U dental_dev -l
- problema: "Error de conexion a Redis"
solucion: |
1. Verificar que Redis esta corriendo:
docker-compose ps
# o: redis-cli -p 6388 ping
2. Verificar puerto en .env
- problema: "Migraciones fallan"
solucion: |
1. Verificar que la BD existe
2. Verificar permisos del usuario
3. Revisar logs: npm run migration:run --verbose
4. Si es necesario, resetear: npm run db:reset
- problema: "Piezas dentales no cargadas"
solucion: |
Ejecutar seeds manualmente:
npm run seed
Verificar: SELECT COUNT(*) FROM dental.piezas_dentales;
Debe retornar 52 (32 permanentes + 20 temporales)
- problema: "Radiografias no se suben"
solucion: |
1. Verificar STORAGE_PATH existe y tiene permisos
2. Verificar MAX_FILE_SIZE en .env (default 20MB)
3. Verificar ALLOWED_FILE_TYPES incluye el tipo de archivo
- problema: "JWT errors"
solucion: |
Verificar que JWT_SECRET esta configurado (min 32 caracteres)
Generar nuevo: openssl rand -base64 64
- problema: "CORS errors en frontend"
solucion: |
Verificar FRONTEND_URL y ALLOWED_ORIGINS en .env
Deben coincidir con la URL del frontend
# -----------------------------------------------------------------------------
# CONFIGURACION DE PRODUCCION
# -----------------------------------------------------------------------------
produccion:
checklist:
- item: "Variables de entorno configuradas via secrets manager"
- item: "SSL/TLS habilitado para BD y Redis"
- item: "Backups automaticos configurados (retencion 5 anos)"
- item: "Monitoreo y alertas activas"
- item: "Rate limiting configurado"
- item: "CORS restringido a dominios autorizados"
- item: "Logs en formato JSON para agregacion"
- item: "Audit logging habilitado (NOM-024-SSA3-2012)"
- item: "Encriptacion de datos sensibles"
infraestructura_recomendada:
base_de_datos: "AWS RDS PostgreSQL 15 o equivalente"
cache: "AWS ElastiCache Redis o equivalente"
storage: "AWS S3 o equivalente (para radiografias)"
cdn: "CloudFront o equivalente"
ci_cd: "GitHub Actions / GitLab CI"
escalado:
backend_replicas: 2
pool_db_size: 50
redis_maxmemory: "512mb"
storage_bucket_region: "us-east-1"
cumplimiento:
nom_024_ssa3:
descripcion: "Expediente clinico electronico"
requisitos:
- "Logs de auditoria inmutables"
- "Firma electronica de expedientes"
- "Control de versiones de historiales"
retencion_datos:
expedientes: "5 anos minimo"
radiografias: "5 anos minimo"
logs_auditoria: "5 anos"
# -----------------------------------------------------------------------------
# REFERENCIAS
# -----------------------------------------------------------------------------
referencias:
perfil_devenv: "orchestration/agents/perfiles/PERFIL-DEVENV.md"
inventario_master: "orchestration/inventarios/DEVENV-MASTER-INVENTORY.yml"
inventario_puertos: "orchestration/inventarios/DEVENV-PORTS-INVENTORY.yml"
contexto_proyecto: "orchestration/00-guidelines/CONTEXTO-PROYECTO.md"
parent_clinicas: "../erp-clinicas/orchestration/environment/ENVIRONMENT-INVENTORY.yml"
schema_dental: "database/schemas/01-dental-schema-ddl.sql"
nomenclatura_fdi: "https://www.fdiworlddental.org/tooth-numbering-system"
# =============================================================================
# FIN DE INVENTARIO
# =============================================================================

View File

@ -1,22 +0,0 @@
# BACKEND_INVENTORY.yml - clinica-dental
# Generado: 2026-01-18T13:01:47-06:00
project: "clinica-dental"
layer: "backend"
modules: []
entities: []
services: []
controllers: []
total:
modules: 0
entities: 0
services: 0
controllers: 0
tests: 0
last_updated: "2026-01-18T13:01:47-06:00"

View File

@ -1,21 +1,284 @@
# DATABASE_INVENTORY.yml - clinica-dental
# Generado: 2026-01-18T13:01:47-06:00
---
# DATABASE INVENTORY - Clinica Dental
# Version: 1.0.0
# Ultima actualizacion: 2026-01-07
project: "clinica-dental"
layer: "database"
proyecto: "clinica-dental"
schema_principal: "dental"
version_ddl: "1.0"
estado: "completado"
schemas: []
herencia:
vertical_padre: "erp-clinicas"
suite_core: "erp-core"
schemas_heredados:
- name: "auth"
desde: "erp-core"
- name: "tenants"
desde: "erp-core"
- name: "users"
desde: "erp-core"
- name: "clinica"
desde: "erp-clinicas"
tablas: ["patients", "doctors", "appointments", "consultations"]
tables: []
enums:
- name: "estado_pieza"
values:
- "sano"
- "caries"
- "obturacion"
- "endodoncia"
- "corona"
- "puente"
- "implante"
- "ausente"
- "extraccion_indicada"
- "diente_temporal"
- "fractura"
- "movilidad"
functions: []
- name: "cara_dental"
values:
- "mesial"
- "distal"
- "oclusal"
- "incisal"
- "vestibular"
- "bucal"
- "lingual"
- "palatino"
triggers: []
- name: "estado_tratamiento"
values:
- "pendiente"
- "en_proceso"
- "completado"
- "cancelado"
total:
schemas: 0
tables: 0
functions: 0
triggers: 0
- name: "tipo_ortodoncia"
values:
- "brackets_metalicos"
- "brackets_esteticos"
- "brackets_linguales"
- "alineadores"
- "removible"
- "retenedor"
last_updated: "2026-01-18T13:01:47-06:00"
catalogos:
- name: "piezas_dentales"
descripcion: "Catalogo de piezas dentales (nomenclatura FDI)"
registros: 52
columnas:
- "id: UUID PK"
- "numero: VARCHAR(10) UNIQUE"
- "nombre: VARCHAR(50)"
- "cuadrante: INTEGER (1-8)"
- "es_temporal: BOOLEAN"
- "descripcion: TEXT"
- name: "tratamientos_catalogo"
descripcion: "Catalogo de tratamientos por tenant"
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "codigo: VARCHAR(20)"
- "nombre: VARCHAR(100)"
- "categoria: VARCHAR(50)"
- "duracion_minutos: INTEGER"
- "precio_base: NUMERIC(10,2)"
- "requiere_rx: BOOLEAN"
- "requiere_anestesia: BOOLEAN"
tablas:
- name: "odontogramas"
descripcion: "Odontogramas de pacientes"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "patient_id: UUID FK (clinica.patients)"
- "fecha_creacion: DATE"
- "fecha_actualizacion: DATE"
- "notas: TEXT"
indices:
- "idx_odontogramas_tenant"
- "idx_odontogramas_patient"
- name: "odontograma_piezas"
descripcion: "Estado de cada pieza en el odontograma"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "odontograma_id: UUID FK"
- "pieza_id: UUID FK (piezas_dentales)"
- "estado: dental.estado_pieza"
- "caras_afectadas: JSONB"
- "observaciones: TEXT"
indices:
- "idx_odontograma_piezas_odontograma"
- "idx_odontograma_piezas_pieza"
- name: "tratamientos_paciente"
descripcion: "Tratamientos realizados a pacientes"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "patient_id: UUID FK"
- "odontograma_id: UUID FK"
- "tratamiento_id: UUID FK (tratamientos_catalogo)"
- "odontologo_id: UUID FK"
- "consultation_id: UUID FK"
- "pieza_id: UUID FK"
- "caras_tratadas: dental.cara_dental[]"
- "fecha_inicio: DATE"
- "fecha_fin: DATE"
- "estado: dental.estado_tratamiento"
- "precio: NUMERIC(10,2)"
- "descuento: NUMERIC(5,2)"
- "precio_final: NUMERIC(10,2)"
indices:
- "idx_tratamientos_paciente_tenant"
- "idx_tratamientos_paciente_patient"
- "idx_tratamientos_paciente_estado"
- name: "ortodoncia"
descripcion: "Casos de ortodoncia"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "patient_id: UUID FK"
- "odontologo_id: UUID FK"
- "tipo: dental.tipo_ortodoncia"
- "marca: VARCHAR(100)"
- "fecha_inicio: DATE"
- "fecha_estimada_fin: DATE"
- "fecha_real_fin: DATE"
- "estado: dental.estado_tratamiento"
- "meses_estimados: INTEGER"
- "costo_total: NUMERIC(10,2)"
- "enganche: NUMERIC(10,2)"
- "mensualidad: NUMERIC(10,2)"
indices:
- "idx_ortodoncia_tenant"
- "idx_ortodoncia_patient"
- "idx_ortodoncia_estado"
- name: "ortodoncia_citas"
descripcion: "Citas de seguimiento de ortodoncia"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "ortodoncia_id: UUID FK"
- "appointment_id: UUID FK"
- "fecha: DATE"
- "numero_cita: INTEGER"
- "procedimiento: TEXT"
- "arco_superior: VARCHAR(50)"
- "arco_inferior: VARCHAR(50)"
- "ligas: VARCHAR(50)"
- "proxima_cita: DATE"
indices:
- "idx_ortodoncia_citas_ortodoncia"
- name: "protesis"
descripcion: "Trabajos protesicos"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "patient_id: UUID FK"
- "odontologo_id: UUID FK"
- "tipo: VARCHAR(50)"
- "piezas_involucradas: TEXT[]"
- "laboratorio_id: UUID FK"
- "fecha_envio_lab: DATE"
- "fecha_recepcion_lab: DATE"
- "material: VARCHAR(100)"
- "color: VARCHAR(50)"
- "estado: dental.estado_tratamiento"
- "fecha_colocacion: DATE"
- "tiene_garantia: BOOLEAN"
- "meses_garantia: INTEGER"
- "costo_laboratorio: NUMERIC(10,2)"
- "precio_paciente: NUMERIC(10,2)"
indices:
- "idx_protesis_tenant"
- "idx_protesis_patient"
- name: "radiografias"
descripcion: "Radiografias dentales"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "patient_id: UUID FK"
- "consultation_id: UUID FK"
- "tipo: VARCHAR(50)"
- "pieza_id: UUID FK"
- "fecha: DATE"
- "url_imagen: VARCHAR(255)"
- "interpretacion: TEXT"
indices:
- "idx_radiografias_tenant"
- "idx_radiografias_patient"
- name: "presupuestos"
descripcion: "Presupuestos de tratamiento"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "patient_id: UUID FK"
- "odontologo_id: UUID FK"
- "numero: VARCHAR(20)"
- "fecha: DATE"
- "fecha_vencimiento: DATE"
- "estado: VARCHAR(20)"
- "subtotal: NUMERIC(12,2)"
- "descuento_porcentaje: NUMERIC(5,2)"
- "descuento_monto: NUMERIC(12,2)"
- "total: NUMERIC(12,2)"
- "requiere_financiamiento: BOOLEAN"
- "enganche: NUMERIC(12,2)"
- "numero_pagos: INTEGER"
- "monto_pago: NUMERIC(12,2)"
indices:
- "idx_presupuestos_tenant"
- "idx_presupuestos_patient"
- "idx_presupuestos_estado"
- name: "presupuesto_lineas"
descripcion: "Lineas de presupuesto"
rls: true
columnas:
- "id: UUID PK"
- "tenant_id: UUID FK"
- "presupuesto_id: UUID FK"
- "tratamiento_id: UUID FK"
- "pieza_id: UUID FK"
- "descripcion: TEXT"
- "cantidad: INTEGER"
- "precio_unitario: NUMERIC(10,2)"
- "descuento: NUMERIC(5,2)"
- "subtotal: NUMERIC(10,2)"
- "sequence: INTEGER"
indices:
- "idx_presupuesto_lineas_presupuesto"
resumen:
total_enums: 4
total_catalogos: 2
total_tablas: 10
total_con_rls: 10
archivos_ddl:
- "database/schemas/01-dental-schema-ddl.sql"
archivos_seeds:
- "database/seeds/fase8/01-dental-catalogos.sql"
ultima_actualizacion: "2026-01-07"
actualizado_por: "Orquestador Workspace"

View File

@ -1,24 +0,0 @@
# FRONTEND_INVENTORY.yml - clinica-dental
# Generado: 2026-01-18T13:01:47-06:00
project: "clinica-dental"
layer: "frontend"
features: []
components: []
pages: []
stores: []
hooks: []
total:
features: 0
components: 0
pages: 0
stores: 0
hooks: 0
last_updated: "2026-01-18T13:01:47-06:00"

View File

@ -1,25 +1,76 @@
# MASTER_INVENTORY.yml - clinica-dental
# Generado: 2026-01-18T13:01:47-06:00
---
# MASTER INVENTORY - Clinica Dental
# Version: 1.0.0
# Ultima actualizacion: 2026-01-07
project:
name: "clinica-dental"
type: "erp-vertical"
parent: "erp-core"
version: "0.1.0"
proyecto: "clinica-dental"
descripcion: "ERP especializado para clinicas dentales"
version: "0.1.0"
estado: "desarrollo"
tipo: "vertical"
base: "erp-clinicas"
summary:
total_modules: 0
backend_entities: 0
frontend_components: 0
database_tables: 0
test_files: 0
coverage_percentage: 0
progreso:
fase_actual: "Database"
porcentaje: 15
database_completado: true
backend_completado: false
frontend_completado: false
inventories:
backend: "BACKEND_INVENTORY.yml"
frontend: "FRONTEND_INVENTORY.yml"
database: "DATABASE_INVENTORY.yml"
herencia:
vertical_padre: "erp-clinicas"
suite_core: "erp-core"
modulos_heredados:
- "auth"
- "users"
- "tenants"
- "roles"
- "patients"
- "appointments"
- "billing"
last_updated: "2026-01-18T13:01:47-06:00"
updated_by: "propagate-governance.sh"
modulos_especificos:
- id: "DENTAL-001"
nombre: "odontograma"
descripcion: "Registro grafico del estado dental"
estado: "ddl_completado"
- id: "DENTAL-002"
nombre: "tratamientos-dentales"
descripcion: "Procedimientos odontologicos"
estado: "ddl_completado"
- id: "DENTAL-003"
nombre: "ortodoncia"
descripcion: "Control de tratamientos ortodonticos"
estado: "ddl_completado"
- id: "DENTAL-004"
nombre: "protesis"
descripcion: "Registro de trabajos protesicos"
estado: "ddl_completado"
database:
schema: "dental"
archivo_ddl: "database/schemas/01-dental-schema-ddl.sql"
archivo_seeds: "database/seeds/fase8/01-dental-catalogos.sql"
tablas_especificas:
- "dental_pieces"
- "dental_charts"
- "dental_treatments"
- "orthodontic_cases"
- "prosthetics"
catalogos:
- "especialidades_odontologicas"
- "estados_piezas_dentales"
- "caras_dentales"
- "tipos_tratamiento_dental"
proximas_tareas:
- "Implementar backend modulo odontograma"
- "Crear frontend para odontograma digital"
- "Integracion con erp-clinicas"
ultima_actualizacion: "2026-01-07"
actualizado_por: "Orquestador"

View File

@ -1,27 +0,0 @@
# Indice de Tareas - clinica-dental
version: "1.0.0"
proyecto: clinica-dental
tipo: SUB_CONSUMER
created: "2026-01-24"
updated: "2026-01-24"
resumen:
total_tareas: 0
completadas: 0
en_progreso: 0
pendientes: 0
formato_id:
patron: "TASK-{YYYY-MM-DD}-{NNN}"
ejemplo: "TASK-2026-01-24-001"
por_fecha: {}
tareas_activas: []
instrucciones:
crear_tarea: |
1. Crear carpeta YYYY-MM-DD/ si no existe
2. Copiar _templates/TASK-TEMPLATE/ a YYYY-MM-DD/TASK-NNN-descripcion/
3. Completar METADATA.yml
4. Documentar fases CAPVED conforme avanza
5. Actualizar este indice al completar

View File

@ -1,30 +0,0 @@
# Fase C - Contexto
**Tarea:** [ID de tarea]
**Fecha:** [YYYY-MM-DD]
**Agente:** [agente responsable]
---
## Vinculacion
| Campo | Valor |
|-------|-------|
| Proyecto | template-saas |
| Modulo | [modulo afectado] |
| Epic | [ID de epic si aplica] |
| Feature | [ID de feature si aplica] |
## Clasificacion
- **Tipo:** [feature|bugfix|refactor|analysis|documentation]
- **Origen:** [ticket|plan|incidente|mejora]
- **Prioridad:** [P0|P1|P2|P3]
## Documentos SIMCO Cargados
1. [Lista de directivas consultadas]
## Estado Inicial
[Descripcion del estado inicial antes de la tarea]

View File

@ -1,26 +0,0 @@
# Fase A - Analisis
**Tarea:** [ID de tarea]
**Fecha:** [YYYY-MM-DD]
---
## Comportamiento Deseado
[Descripcion del resultado esperado]
## Objetos Impactados
| Capa | Impacto |
|------|---------|
| [DDL/Backend/Frontend] | [descripcion] |
## Dependencias
- [Lista de dependencias]
## Riesgos
| Riesgo | Mitigacion |
|--------|------------|
| [riesgo] | [mitigacion] |

View File

@ -1,21 +0,0 @@
# Fase P - Planeacion
**Tarea:** [ID de tarea]
**Fecha:** [YYYY-MM-DD]
---
## Subtareas
| # | Subtarea | Dominio | Criterio de Aceptacion |
|---|----------|---------|------------------------|
| 1 | [subtarea] | [dominio] | [criterio] |
## Orden de Ejecucion
[secuencia de subtareas]
## Asignacion
- Agente principal: [agente]
- Subagentes: [lista o ninguno]

View File

@ -1,24 +0,0 @@
# Fase V - Validacion
**Tarea:** [ID de tarea]
**Fecha:** [YYYY-MM-DD]
---
## Checklist de Validacion
### Cobertura Analisis -> Plan
- [ ] Todas las acciones del analisis tienen subtarea correspondiente
- [ ] No hay acciones huerfanas
### Dependencias
- [ ] No hay dependencias ocultas
- [ ] Orden de ejecucion respeta dependencias
### Scope Creep
- [ ] No detectado / [descripcion si hay]
## Gate de Validacion
- **Resultado:** [APROBADO|RECHAZADO]
- **Notas:** [notas adicionales]

View File

@ -1,20 +0,0 @@
# Fase E - Ejecucion
**Tarea:** [ID de tarea]
**Fecha:** [YYYY-MM-DD]
---
## Progreso de Subtareas
| # | Subtarea | Estado | Notas |
|---|----------|--------|-------|
| 1 | [subtarea] | [pendiente|completada] | [notas] |
## Validaciones Build/Lint
- [resultado de validaciones]
## Desviaciones
- [desviaciones del plan si las hay]

View File

@ -1,32 +0,0 @@
# Fase D - Documentacion
**Tarea:** [ID de tarea]
**Fecha:** [YYYY-MM-DD]
---
## Actualizaciones Realizadas
### Documentacion
- [ ] _MAP.md actualizado
- [ ] README.md actualizado si aplica
### Inventarios
- [ ] Inventarios actualizados si cambio codigo
### Trazas
- [ ] Registrado en indice de tareas
### ADRs
- [ ] ADR creado si decision arquitectonica
## Lecciones Aprendidas
### Que funciono bien
[descripcion]
### Que se puede mejorar
[descripcion]
### Para futuras tareas similares
[recomendaciones]

View File

@ -1,41 +0,0 @@
# METADATA.yml - Template para tareas
id: TASK-YYYY-MM-DD-NNN
fecha: "YYYY-MM-DD"
titulo: "[Titulo de la tarea]"
descripcion: "[Descripcion detallada]"
clasificacion:
tipo: "[feature|bugfix|refactor|analysis|documentation]"
origen: "[ticket|plan|incidente|mejora]"
prioridad: "[P0|P1|P2|P3]"
feature: "[ID de feature si aplica]"
proyecto:
nombre: template-saas
path: projects/template-saas
nivel: PROVIDER
estado:
actual: pendiente
progreso: 0%
fecha_inicio: null
fecha_fin: null
fases_capved:
contexto: pendiente
analisis: pendiente
planeacion: pendiente
validacion: pendiente
ejecucion: pendiente
documentacion: pendiente
agente:
principal: "[agente responsable]"
subagentes: []
commits: []
metricas:
archivos_modificados: 0
archivos_creados: 0
lineas_codigo: 0