Plantilla de módulo

Todo módulo del manual sigue esta estructura fija de cuatro secciones. Copia esta plantilla al crear src/content/docs/modulos/<modulo>.mdx.

1. Resumen

• Qué hace el módulo y qué acciones cubre para el usuario final (tomadas del scope funcional).
• Prerrequisitos: parámetros de tenant o permisos que condicionan su disponibilidad.

2. Flujo

Diagrama Mermaid sequenceDiagram (App móvil ↔ th-core-api) con el orden real de consumo de los endpoints: qué se carga al abrir la pantalla, qué se llama antes de cada acción y qué se refresca después.

sequenceDiagram
    participant App as App móvil
    participant API as th-core-api

    App->>API: GET /me/... (carga inicial)
    API-->>App: datos
    App->>API: POST /me/... (acción del usuario)
    API-->>App: resultado

3. Endpoints

Para cada endpoint del flujo:

• Método + path y headers (si difieren de los comunes).
• Query params / request body: tabla de campos con tipo, obligatoriedad, enum si aplica y descripción — extraídos del DTO real del backend, nunca inventados.
• Response: ejemplo JSON realista + tabla de campos relevantes para la UI.
• Errores posibles específicos del endpoint (los genéricos ya están en Convenciones).

4. Lógica de cliente

Reglas de UI que el backend espera que el cliente aplique:

• Qué mostrar/ocultar/deshabilitar según campos y estados de las respuestas.
• Validaciones previas a cada acción (por ejemplo, cálculos o verificaciones que deben llamarse antes de un POST).
• Estados vacíos y casos borde (sin saldo, sin resultados, acción ya realizada).
• Tablas de enumerados con el texto sugerido para el usuario.

---

Fuente de verdad: los contratos se extraen de los controllers y DTOs de th-core-api, y la lógica de cliente del comportamiento de referencia del portal web (th-app). Verifica cada endpoint contra el código antes de publicarlo.