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

Epica: MCH-XXX
API Spec: Backend Inventory
Database: Database Inventory


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

Crear plan de ejecucion con orden exacto de archivos
Definir templates finales para cada tipo de documento
Estimar tiempo por archivo
Asignar prioridades de ejecucion
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)

24 KiB Raw Permalink Blame History