# FASE 2: Analisis Detallado de Implementacion

---
id: ANALISIS-VISION-002
title: Analisis Detallado de Cambios por Archivo
type: Analysis
status: InProgress
priority: P0
version: 1.0.0
created_date: 2026-01-10
updated_date: 2026-01-10
perfil_ejecutor: DOCUMENTATION-MAINTAINER + REQUIREMENTS-ANALYST
depends_on: FASE-1-ANALISIS-PLANEACION-INICIAL-2026-01-10.md
---

## 1. Objetivo de Esta Fase

Definir con precision los cambios especificos que deben realizarse en cada archivo de la carpeta `vision-general/`, incluyendo:

- Estructura final de cada documento
- Contenido exacto a agregar (frontmatter, metadata, secciones)
- Transformaciones de contenido existente
- Nuevos documentos a crear
- Integraciones con estandares SaaS y flujos ERP

---

## 2. Cambios Detallados por Archivo

### 2.1 VISION-PROYECTO.md

#### 2.1.1 Cambios Estructurales

| Seccion | Estado Actual | Estado Final | Accion |
|---------|---------------|--------------|--------|
| Frontmatter YAML | NO EXISTE | Completo | AGREGAR |
| Metadata tabla | NO EXISTE | Tabla estandar | AGREGAR |
| El Problema | OK | OK + referencias | MODIFICAR |
| La Solucion | OK | OK | MANTENER |
| Filosofia de Diseno | OK | OK | MANTENER |
| Mercado Objetivo | OK | OK | MANTENER |
| Modelo de Negocio | OK | OK + referencias SaaS | MODIFICAR |
| Diferenciadores | OK | OK | MANTENER |
| Roadmap | OK | OK + links a epicas | MODIFICAR |
| Tecnologia | OK | OK + links arquitectura | MODIFICAR |
| KPIs | OK | OK | MANTENER |
| Riesgos | OK | OK | MANTENER |
| Equipo | OK | OK | MANTENER |
| Footer | Informal | Estandar | MODIFICAR |
| Referencias | NO EXISTE | Seccion completa | AGREGAR |

#### 2.1.2 Frontmatter YAML a Agregar

```yaml
---
id: VIS-MCH-001
title: Vision del Proyecto MiChangarrito
type: Vision
status: Published
priority: P0
module: core
epic: null
version: 1.1.0
created_date: 2026-01-04
updated_date: 2026-01-10
owner: Product Team
reviewers:
  - Tech Lead
  - Stakeholders
tags:
  - vision
  - estrategia
  - producto
  - saas
---
```

#### 2.1.3 Metadata Tabla a Agregar (despues de titulo)

```markdown
| Campo | Valor |
|-------|-------|
| **ID** | VIS-MCH-001 |
| **Tipo** | Vision |
| **Estado** | Published |
| **Prioridad** | P0 |
| **Version** | 1.1.0 |
| **Ultima Actualizacion** | 2026-01-10 |
| **Owner** | Product Team |
```

#### 2.1.4 Referencias a Agregar al Final

```markdown
## Referencias

### Documentos Relacionados

| Documento | Relacion | Path |
|-----------|----------|------|
| Requerimientos Funcionales | Define los RF | [REQUERIMIENTOS-FUNCIONALES.md](./REQUERIMIENTOS-FUNCIONALES.md) |
| Arquitectura Tecnica | Define el stack | [ARQUITECTURA-TECNICA.md](./ARQUITECTURA-TECNICA.md) |
| Arquitectura Database | Detalle BD | [../02-especificaciones/ARQUITECTURA-DATABASE.md] |
| Epicas del Proyecto | Implementacion | [../01-epicas/_MAP.md] |

### ADRs Relacionados

| ADR | Tema | Path |
|-----|------|------|
| ADR-0001 | Multi-tenancy WhatsApp | [../97-adr/ADR-0001-multi-tenancy-whatsapp.md] |
| ADR-0002 | LLM Provider Strategy | [../97-adr/ADR-0002-llm-provider.md] |

### Referencias Externas

- [Meta WhatsApp Business API](https://developers.facebook.com/docs/whatsapp)
- [Stripe Billing](https://stripe.com/docs/billing)
- [MCP Protocol](https://modelcontextprotocol.io/)
```

#### 2.1.5 Modificaciones en Secciones Existentes

**Seccion "Modelo de Negocio" - Agregar referencia:**

Despues del bloque de pricing, agregar:

```markdown
> Para detalles tecnicos de implementacion de planes y suscripciones, ver:
> - [RF-009: Pagos y Suscripciones](./REQUERIMIENTOS-FUNCIONALES.md#rf-009-pagos-y-suscripciones)
> - Patron de referencia: [template-saas/SAAS-004-billing](../../template-saas/docs/)
```

**Seccion "Roadmap" - Agregar links a epicas:**

Modificar cada fase para incluir links:

```markdown
### Fase 1: MVP (Completada - 95%)
> Epicas: MCH-001 a MCH-009
> Ver: [01-epicas/_MAP.md](../01-epicas/_MAP.md)

- App movil basica (ventas, cobros) - MCH-004
- Integracion Mercado Pago y Clip - MCH-005
- WhatsApp basico con LLM - MCH-011
- Dashboard web simple - MCH-001
```

---

### 2.2 REQUERIMIENTOS-FUNCIONALES.md

#### 2.2.1 Cambios Estructurales

| Seccion | Estado Actual | Estado Final | Accion |
|---------|---------------|--------------|--------|
| Frontmatter YAML | NO EXISTE | Completo | AGREGAR |
| Metadata tabla | NO EXISTE | Tabla estandar | AGREGAR |
| Indice de RF | NO EXISTE | Tabla con status | AGREGAR |
| RF-001 a RF-017 | Sin metadata individual | Con metadata y CA | MODIFICAR TODOS |
| Criterios Aceptacion | NO EXISTEN | BDD/Gherkin | AGREGAR por RF |
| Referencias a epicas | NO EXISTEN | Links a MCH-XXX | AGREGAR |
| Trazabilidad | NO EXISTE | Matriz RF->Epica->Code | AGREGAR |
| Referencias | NO EXISTE | Seccion completa | AGREGAR |

#### 2.2.2 Frontmatter YAML a Agregar

```yaml
---
id: RF-MCH-001
title: Requerimientos Funcionales MiChangarrito
type: Requirement
status: Approved
priority: P0
module: core
version: 1.1.0
created_date: 2026-01-04
updated_date: 2026-01-10
total_requirements: 17
implemented: 15
pending: 2
owner: Product Team
reviewers:
  - Tech Lead
  - Backend Lead
tags:
  - requerimientos
  - funcional
  - especificacion
---
```

#### 2.2.3 Metadata Tabla a Agregar

```markdown
| Campo | Valor |
|-------|-------|
| **ID** | RF-MCH-001 |
| **Tipo** | Requirement Specification |
| **Estado** | Approved |
| **Total Requisitos** | 17 |
| **Implementados** | 15 (88%) |
| **Pendientes** | 2 |
| **Version** | 1.1.0 |
| **Ultima Actualizacion** | 2026-01-10 |
```

#### 2.2.4 Indice de Requerimientos a Agregar (despues de metadata)

```markdown
## Indice de Requerimientos

| ID | Nombre | Prioridad | Estado | Epica | Implementacion |
|----|--------|-----------|--------|-------|----------------|
| RF-001 | Punto de Venta (POS) | P0 | Implementado | MCH-004 | 100% |
| RF-002 | Catalogo de Productos | P0 | Implementado | MCH-003 | 100% |
| RF-003 | Inventario | P0 | Implementado | MCH-006 | 95% |
| RF-004 | Sistema de Fiados | P1 | Implementado | MCH-014 | 100% |
| RF-005 | Clientes | P1 | Implementado | MCH-014 | 100% |
| RF-006 | Pedidos de Clientes | P1 | Implementado | MCH-015 | 90% |
| RF-007 | Asistente IA (LLM) | P0 | Implementado | MCH-010 | 100% |
| RF-008 | WhatsApp Business | P0 | Implementado | MCH-011 | 100% |
| RF-009 | Pagos y Suscripciones | P0 | Implementado | MCH-005, MCH-013 | 95% |
| RF-010 | Reportes y Analytics | P1 | Implementado | MCH-012 | 90% |
| RF-011 | Notificaciones | P1 | Implementado | MCH-017 | 85% |
| RF-012 | Modo Offline | P1 | Implementado | MCH-018 | 100% |
| RF-013 | Integraciones Terminal | P0 | Implementado | MCH-005 | 90% |
| RF-014 | Onboarding | P1 | Implementado | MCH-019 | 95% |
| RF-015 | Seguridad y Acceso | P0 | Implementado | MCH-002 | 100% |
| RF-016 | Programa de Referidos | P2 | Pendiente | MCH-025 | 0% |
| RF-017 | Soporte | P2 | Parcial | MCH-020 | 50% |

**Leyenda de Estados:**
- Implementado: Funcionalidad completa en produccion
- Parcial: Funcionalidad basica implementada
- Pendiente: No iniciado
```

#### 2.2.5 Estructura Estandar por Requisito

Cada RF debe transformarse a este formato:

```markdown
## RF-XXX: Nombre del Requisito

### Metadata

| Campo | Valor |
|-------|-------|
| **ID** | RF-XXX |
| **Prioridad** | P0/P1/P2 |
| **Estado** | Implementado/Parcial/Pendiente |
| **Epica** | MCH-XXX |
| **Modulo Backend** | xxx.module |
| **Modulo Frontend** | pages/xxx |

### Descripcion
[Descripcion existente]

### Subsecciones
[Contenido existente con formato mejorado]

### Criterios de Aceptacion

```gherkin
Feature: RF-XXX - Nombre del Requisito

  Scenario: [Escenario principal]
    Given [Precondicion]
    When [Accion]
    Then [Resultado esperado]

  Scenario: [Escenario alternativo]
    Given [Precondicion]
    When [Accion alternativa]
    Then [Resultado alternativo]
```

### Dependencias

| Tipo | Dependencia | Descripcion |
|------|-------------|-------------|
| Requiere | RF-YYY | [Razon] |
| Habilita | RF-ZZZ | [Razon] |
| API | /api/xxx | [Endpoints relacionados] |
| Tabla | schema.tabla | [Tablas BD relacionadas] |

### Referencias
- Epica: [MCH-XXX](../01-epicas/MCH-XXX-nombre.md)
- API Spec: [Backend Inventory](../../orchestration/inventarios/BACKEND_INVENTORY.yml)
- Database: [Database Inventory](../../orchestration/inventarios/DATABASE_INVENTORY.yml)
```

#### 2.2.6 Criterios de Aceptacion a Agregar (Ejemplos)

**RF-001 - Punto de Venta:**

```gherkin
Feature: RF-001 - Punto de Venta (POS)

  Background:
    Given el usuario esta autenticado como dueno
    And tiene al menos un producto registrado
    And la caja esta abierta

  Scenario: Registrar venta con efectivo
    Given el carrito tiene productos por $150 MXN
    When el usuario selecciona "Efectivo" como metodo de pago
    And ingresa $200 como monto recibido
    Then el sistema calcula cambio de $50 MXN
    And genera ticket de venta
    And actualiza inventario
    And la venta aparece en historial

  Scenario: Registrar venta con terminal MP
    Given el carrito tiene productos por $150 MXN
    And la terminal Mercado Pago esta pareada
    When el usuario selecciona "Mercado Pago" como metodo de pago
    Then el sistema envia monto a terminal
    And espera confirmacion de pago
    And genera ticket de venta

  Scenario: Venta a credito (fiado)
    Given el carrito tiene productos por $150 MXN
    And existe un cliente "Juan Perez" registrado
    When el usuario selecciona "Fiar" como metodo de pago
    And selecciona al cliente
    Then el sistema registra la deuda
    And genera ticket con "FIADO" marcado
    And envia notificacion WhatsApp al cliente

  Scenario: Corte de caja
    Given hay ventas registradas en el dia
    When el usuario solicita "Corte de caja"
    Then el sistema muestra resumen por metodo de pago
    And calcula diferencia efectivo esperado vs real
    And genera reporte de corte
    And envia resumen por WhatsApp
```

**RF-007 - Asistente IA:**

```gherkin
Feature: RF-007 - Asistente IA (LLM)

  Background:
    Given el negocio tiene saldo de tokens > 0
    And WhatsApp esta configurado

  Scenario: Dueno consulta ventas por WhatsApp
    Given el usuario es el dueno del negocio
    When envia mensaje "Cuanto vendi hoy?"
    Then el LLM detecta intencion de consulta de ventas
    And ejecuta tool obtener_ventas(periodo="hoy")
    And responde con total de ventas del dia
    And descuenta tokens utilizados

  Scenario: Cliente hace pedido por WhatsApp
    Given el usuario es un cliente (no dueno)
    When envia mensaje "Quiero 3 tacos y una coca"
    Then el LLM detecta que es cliente
    And detecta intencion de pedido
    And estructura el pedido con productos
    And notifica al dueno del negocio
    And responde al cliente con confirmacion

  Scenario: Sin saldo de tokens
    Given el negocio tiene saldo de tokens = 0
    When el dueno envia mensaje por WhatsApp
    Then el sistema responde con mensaje de saldo agotado
    And ofrece opciones de recarga
    And NO procesa la consulta con LLM
```

#### 2.2.7 Requisitos SaaS a Agregar

Agregar al final del documento una nueva seccion:

```markdown
---

## Requisitos SaaS Adicionales (Nuevos)

Basado en patrones de template-saas, se requieren los siguientes requisitos adicionales:

### RF-018: Sistema de Audit Logs

**Prioridad:** P1
**Estado:** Pendiente
**Referencia:** SAAS-008

#### Descripcion
Sistema de auditoria que registra todas las acciones criticas del sistema para compliance, debugging y seguridad.

#### Subsecciones

##### RF-018.1: Registro de Eventos
- Log de acciones de usuario (login, logout, cambios)
- Log de operaciones de negocio (ventas, cambios de precio)
- Log de eventos de sistema (errores, integraciones)
- Metadata: timestamp, user_id, tenant_id, ip, action, details

##### RF-018.2: Consulta de Logs
- Filtros por fecha, usuario, tipo de accion
- Busqueda full-text en detalles
- Exportacion CSV/JSON
- Retencion configurable (90 dias default)

### RF-019: Feature Flags por Plan

**Prioridad:** P1
**Estado:** Pendiente
**Referencia:** SAAS-009

#### Descripcion
Sistema de banderas de caracteristicas que permite habilitar/deshabilitar funcionalidades por plan de suscripcion o por tenant individual.

#### Subsecciones

##### RF-019.1: Configuracion de Flags
- Flags globales (on/off para todos)
- Flags por plan (Changarrito vs Tiendita)
- Flags por tenant (override individual)
- UI de administracion para superadmin

##### RF-019.2: Evaluacion de Flags
- SDK para evaluar flag en backend
- Hook para evaluar flag en frontend
- Cache de evaluaciones
- Default values seguros

### RF-020: Rate Limiting por Plan

**Prioridad:** P1
**Estado:** Parcial
**Referencia:** SAAS-005 (Plans)

#### Descripcion
Sistema de limites de uso por plan de suscripcion para prevenir abuso y diferenciar planes.

#### Subsecciones

##### RF-020.1: Limites por Plan

| Limite | Changarrito | Tiendita |
|--------|-------------|----------|
| Transacciones/dia | 200 | Ilimitadas |
| Productos | 500 | 5,000 |
| Tokens IA/mes | 500 base | 2,000 base |
| Storage (MB) | 100 | 500 |
| Usuarios | 1 | 3 |

##### RF-020.2: Enforcement
- Middleware de validacion en cada request
- Contadores en Redis
- Reset diario/mensual segun tipo
- Mensajes claros al alcanzar limite
- Upgrade path (link a subir plan)
```

---

### 2.3 ARQUITECTURA-TECNICA.md

#### 2.3.1 Cambios Estructurales

| Seccion | Estado Actual | Estado Final | Accion |
|---------|---------------|--------------|--------|
| Frontmatter YAML | NO EXISTE | Completo | AGREGAR |
| Metadata tabla | NO EXISTE | Tabla estandar | AGREGAR |
| Diagrama General | OK | OK | MANTENER |
| Componentes | OK | OK + links a inventarios | MODIFICAR |
| Base de Datos | OK | OK + link a ARQUITECTURA-DATABASE | MODIFICAR |
| Integraciones | OK | OK + links a INT-XXX | MODIFICAR |
| Seguridad | OK | OK | MANTENER |
| Infraestructura | OK | OK | MANTENER |
| Performance | OK | OK | MANTENER |
| ADRs relacionados | NO EXISTE | Seccion nueva | AGREGAR |
| Referencias | NO EXISTE | Seccion completa | AGREGAR |

#### 2.3.2 Frontmatter YAML a Agregar

```yaml
---
id: ET-ARQ-MCH-001
title: Arquitectura Tecnica MiChangarrito
type: Specification
subtype: Architecture
status: Published
priority: P0
module: core
version: 2.1.0
created_date: 2026-01-04
updated_date: 2026-01-10
owner: Tech Lead
reviewers:
  - Backend Lead
  - DevOps Lead
  - Security Lead
tags:
  - arquitectura
  - tecnico
  - infraestructura
  - saas
---
```

#### 2.3.3 Metadata Tabla a Agregar

```markdown
| Campo | Valor |
|-------|-------|
| **ID** | ET-ARQ-MCH-001 |
| **Tipo** | Especificacion Tecnica - Arquitectura |
| **Estado** | Published |
| **Prioridad** | P0 |
| **Version** | 2.1.0 |
| **Ultima Actualizacion** | 2026-01-10 |
| **Owner** | Tech Lead |

### Stack Resumen

| Capa | Tecnologia | Version |
|------|------------|---------|
| Backend | NestJS | 10.3.0 |
| Frontend | React | 19.2.0 |
| Mobile | React Native + Expo | 0.73+ |
| Database | PostgreSQL | 16+ |
| Cache | Redis | 7.x |
| LLM Gateway | MCP Server | Custom |
```

#### 2.3.4 Seccion ADRs a Agregar (antes de Referencias)

```markdown
## ADRs Relacionados

Las siguientes decisiones arquitectonicas estan documentadas formalmente:

| ADR | Titulo | Estado | Fecha |
|-----|--------|--------|-------|
| [ADR-0001](../97-adr/ADR-0001-multi-tenancy-whatsapp.md) | Multi-tenancy para WhatsApp | Accepted | 2026-01-XX |
| [ADR-0002](../97-adr/ADR-0002-llm-provider.md) | Estrategia de proveedores LLM | Accepted | 2026-01-XX |
| ADR-0003 (pendiente) | Offline-First Strategy | Proposed | - |
| ADR-0004 (pendiente) | Rate Limiting Implementation | Proposed | - |
| ADR-0005 (pendiente) | Webhook Multi-tenant Routing | Proposed | - |

### ADRs Pendientes de Documentar

Basado en decisiones implicitas en la arquitectura:

1. **ADR-0003: Offline-First Strategy**
   - Contexto: Mobile app necesita funcionar sin internet
   - Decision: SQLite local + sync queue

2. **ADR-0004: Rate Limiting Implementation**
   - Contexto: Diferenciar planes, prevenir abuso
   - Decision: Redis counters + middleware

3. **ADR-0005: Webhook Multi-tenant Routing**
   - Contexto: Stripe/WhatsApp webhooks para multiples tenants
   - Decision: Tenant ID en metadata + queue por tenant
```

#### 2.3.5 Modificaciones a Secciones Existentes

**Seccion "Base de Datos" - Agregar link:**

Al final del bloque de schemas:

```markdown
**Total: 12 schemas, ~49 tablas**

> Para especificacion completa de cada tabla, constraints, indices y RLS policies, ver:
> - [ARQUITECTURA-DATABASE.md](../02-especificaciones/ARQUITECTURA-DATABASE.md)
> - [DATABASE_INVENTORY.yml](../../orchestration/inventarios/DATABASE_INVENTORY.yml)
```

**Seccion "Integraciones Externas" - Agregar links:**

Despues de cada tabla de integraciones:

```markdown
> Documentacion detallada de cada integracion:
> - [INT-001: WhatsApp Meta](../02-integraciones/INT-001-whatsapp-meta.md)
> - [INT-002: Stripe](../02-integraciones/INT-002-stripe.md)
> - [INT-003: OpenRouter](../02-integraciones/INT-003-openrouter.md)
> - [INT-004: Mercado Pago](../02-integraciones/INT-004-mercadopago.md)
```

#### 2.3.6 Seccion Referencias a Agregar

```markdown
## Referencias

### Documentos Internos

| Documento | Relacion | Path |
|-----------|----------|------|
| Vision del Proyecto | Contexto de negocio | [VISION-PROYECTO.md](./VISION-PROYECTO.md) |
| Requerimientos Funcionales | Requisitos implementados | [REQUERIMIENTOS-FUNCIONALES.md](./REQUERIMIENTOS-FUNCIONALES.md) |
| Arquitectura Database | Detalle completo BD | [../02-especificaciones/ARQUITECTURA-DATABASE.md] |
| Integraciones Externas | Detalle de integraciones | [../02-integraciones/] |
| ADRs | Decisiones arquitectonicas | [../97-adr/] |

### Inventarios

| Inventario | Contenido | Path |
|------------|-----------|------|
| MASTER_INVENTORY | Estado consolidado | [orchestration/inventarios/MASTER_INVENTORY.yml] |
| BACKEND_INVENTORY | Modulos, endpoints | [orchestration/inventarios/BACKEND_INVENTORY.yml] |
| FRONTEND_INVENTORY | Paginas, componentes | [orchestration/inventarios/FRONTEND_INVENTORY.yml] |
| DATABASE_INVENTORY | Schemas, tablas | [orchestration/inventarios/DATABASE_INVENTORY.yml] |

### Referencias Externas

- [NestJS Documentation](https://docs.nestjs.com/)
- [React Documentation](https://react.dev/)
- [PostgreSQL RLS](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)
- [AWS ECS Fargate](https://docs.aws.amazon.com/ecs/)
```

---

### 2.4 _MAP.md (NUEVO - Crear)

#### 2.4.1 Contenido Completo

```markdown
# Vision General - Indice de Documentacion

---
id: MAP-VISION-001
title: Indice de Documentacion Vision General
type: Index
status: Published
version: 1.0.0
created_date: 2026-01-10
updated_date: 2026-01-10
---

## Resumen

| Metrica | Valor |
|---------|-------|
| **Documentos** | 3 |
| **Total Lineas** | 1,237 |
| **Ultima Actualizacion** | 2026-01-10 |
| **Cobertura** | Vision, Requerimientos, Arquitectura |

## Contenido de la Carpeta

| # | Documento | Tipo | Estado | Descripcion |
|---|-----------|------|--------|-------------|
| 1 | [VISION-PROYECTO.md](./VISION-PROYECTO.md) | Vision | Published | Propuesta de valor, modelo de negocio, roadmap |
| 2 | [REQUERIMIENTOS-FUNCIONALES.md](./REQUERIMIENTOS-FUNCIONALES.md) | Requirement | Approved | 17 requisitos funcionales (RF-001 a RF-017) |
| 3 | [ARQUITECTURA-TECNICA.md](./ARQUITECTURA-TECNICA.md) | Specification | Published | Stack tecnologico, diagramas, infraestructura |

## Navegacion Rapida

### Por Tema

| Tema | Documento | Seccion |
|------|-----------|---------|
| Problema de mercado | VISION-PROYECTO | El Problema |
| Propuesta de valor | VISION-PROYECTO | La Solucion |
| Modelo de precios | VISION-PROYECTO | Modelo de Negocio |
| Punto de Venta | REQUERIMIENTOS-FUNCIONALES | RF-001 |
| Catalogo | REQUERIMIENTOS-FUNCIONALES | RF-002 |
| Inventario | REQUERIMIENTOS-FUNCIONALES | RF-003 |
| Fiados | REQUERIMIENTOS-FUNCIONALES | RF-004 |
| Asistente IA | REQUERIMIENTOS-FUNCIONALES | RF-007 |
| WhatsApp | REQUERIMIENTOS-FUNCIONALES | RF-008 |
| Stack tecnologico | ARQUITECTURA-TECNICA | Componentes Principales |
| Base de datos | ARQUITECTURA-TECNICA | Base de Datos |
| Integraciones | ARQUITECTURA-TECNICA | Integraciones Externas |
| Seguridad | ARQUITECTURA-TECNICA | Seguridad |
| Infraestructura | ARQUITECTURA-TECNICA | Infraestructura |

### Por Rol

| Rol | Documentos Relevantes |
|-----|----------------------|
| Product Manager | VISION-PROYECTO (completo), REQUERIMIENTOS-FUNCIONALES |
| Tech Lead | ARQUITECTURA-TECNICA, REQUERIMIENTOS-FUNCIONALES |
| Backend Developer | ARQUITECTURA-TECNICA (Backend API, BD, Seguridad) |
| Frontend Developer | ARQUITECTURA-TECNICA (Web Dashboard, Mobile) |
| DevOps | ARQUITECTURA-TECNICA (Infraestructura, Performance) |

## Relaciones con Otros Documentos

```
00-vision-general/
├── VISION-PROYECTO.md
│   ├── → 01-epicas/_MAP.md (implementacion del roadmap)
│   └── → orchestration/PROJECT-STATUS.md (estado actual)
│
├── REQUERIMIENTOS-FUNCIONALES.md
│   ├── → 01-epicas/MCH-XXX.md (epicas por RF)
│   ├── → 02-especificaciones/*.md (detalles tecnicos)
│   └── → orchestration/inventarios/*.yml (estado implementacion)
│
└── ARQUITECTURA-TECNICA.md
    ├── → 02-especificaciones/ARQUITECTURA-DATABASE.md
    ├── → 02-integraciones/INT-*.md
    ├── → 97-adr/ADR-*.md
    └── → orchestration/inventarios/*.yml
```

## Historial de Cambios

| Fecha | Version | Cambios |
|-------|---------|---------|
| 2026-01-10 | 1.0.0 | Creacion inicial del indice |
| 2026-01-10 | 1.1.0 | Estandarizacion SIMCO aplicada |

---

**Sistema**: SIMCO v3.7.0
**Generado por**: DOCUMENTATION-MAINTAINER
```

---

## 3. Nuevos Documentos a Crear

### 3.1 Documentos SaaS Faltantes

Basado en el analisis de template-saas, se deben crear:

| Documento | Prioridad | Ubicacion | Contenido |
|-----------|-----------|-----------|-----------|
| MCH-AUDIT-SAAS.md | P1 | docs/02-especificaciones/ | Sistema de audit logs |
| MCH-FEATURE-FLAGS-SAAS.md | P1 | docs/02-especificaciones/ | Feature flags por plan |
| MCH-RATE-LIMITING-SAAS.md | P1 | docs/02-especificaciones/ | Rate limiting por plan |
| MCH-WEBHOOKS-SAAS.md | P2 | docs/02-especificaciones/ | Webhooks outbound |

### 3.2 ADRs Pendientes

| ADR | Prioridad | Ubicacion | Decision |
|-----|-----------|-----------|----------|
| ADR-0003-offline-first.md | P1 | docs/97-adr/ | SQLite + sync queue |
| ADR-0004-rate-limiting.md | P1 | docs/97-adr/ | Redis counters |
| ADR-0005-webhook-routing.md | P2 | docs/97-adr/ | Tenant ID + queue |

---

## 4. Matriz de Cambios Consolidada

### 4.1 Cambios por Archivo

| Archivo | Agregar | Modificar | Eliminar | Lineas Estimadas |
|---------|---------|-----------|----------|------------------|
| VISION-PROYECTO.md | Frontmatter, Metadata, Referencias | Roadmap, Modelo Negocio | Footer informal | +50 lineas |
| REQUERIMIENTOS-FUNCIONALES.md | Frontmatter, Indice, CA, RF-018/019/020, Referencias | Todos los RF (metadata) | Footer informal | +300 lineas |
| ARQUITECTURA-TECNICA.md | Frontmatter, Metadata, ADRs, Referencias | BD, Integraciones | Footer informal | +80 lineas |
| _MAP.md | NUEVO COMPLETO | N/A | N/A | +100 lineas |

### 4.2 Dependencias de Cambios

```
Orden de ejecucion recomendado:

1. _MAP.md (crear primero - no tiene dependencias)
2. VISION-PROYECTO.md (base para referencias)
3. ARQUITECTURA-TECNICA.md (define stack referenciado)
4. REQUERIMIENTOS-FUNCIONALES.md (mas complejo, referencias a 1-3)
```

---

## 5. Validaciones Post-Cambio

### 5.1 Checklist de Validacion

- [ ] Frontmatter YAML valido en todos los archivos
- [ ] Metadata tabla presente en todos los archivos
- [ ] _MAP.md creado con todos los documentos
- [ ] Referencias cruzadas funcionan (links no rotos)
- [ ] Nomenclatura de IDs unica (VIS-MCH-001, RF-MCH-001, ET-ARQ-MCH-001)
- [ ] Versiones actualizadas
- [ ] Fechas de actualizacion correctas
- [ ] Criterios de aceptacion en formato Gherkin
- [ ] Links a epicas validos
- [ ] Links a inventarios validos

### 5.2 Archivos Dependientes a Validar

| Archivo Dependiente | Validar |
|---------------------|---------|
| docs/_MAP.md | Actualizar con nuevos documentos |
| docs/01-epicas/_MAP.md | Links desde RF funcionan |
| orchestration/inventarios/MASTER_INVENTORY.yml | Estados consistentes |
| orchestration/PROJECT-STATUS.md | Referencias actualizadas |

---

## 6. Proximos Pasos (FASE 3)

La siguiente fase (Planeacion) debera:

1. **Crear plan de ejecucion** con orden exacto de archivos
2. **Definir templates finales** para cada tipo de documento
3. **Estimar tiempo** por archivo
4. **Asignar prioridades** de ejecucion
5. **Definir criterios de aceptacion** de la fase de ejecucion

---

**Documento generado por**: DOCUMENTATION-MAINTAINER + REQUIREMENTS-ANALYST
**Sistema**: SIMCO v3.7.0
**Metodologia**: CAPVED (Fase A - Analisis Detallado)