rckrdmrd/michangarrito
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
928eb795e6
michangarrito/orchestration/analisis/historico/FASE-2-ANALISIS-DETALLADO-IMPLEMENTACION-2026-01-10.md
rckrdmrd 928eb795e6 [SIMCO-V38] feat: Actualizar a SIMCO v3.8.0 + cambios apps 
- HERENCIA-SIMCO.md actualizado con directivas v3.7 y v3.8
- Cambios en backend y frontend

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-10 08:53:05 -06:00

24 KiB
Raw Blame History

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

---
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)

| 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

## 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:

> 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:

### 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

---
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

| 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)

## 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:

## 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


#### 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:

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:

---

## 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

---
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

| 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)

## 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:

**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:

> 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

## 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

# 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)