Plantilla

Formato unico para todo el catalogo. Todo el contenido en espanol. Slugs de archivos y carpetas en kebab-case estable (ingles/producto).

Regla base: solo se documenta lo que existe en el codigo (frontend achieveApex-Frontend/src y backend achieveApex-Backend/src). No se inventan campos, botones, rutas ni reglas.

Audiencia y proposito

Este catalogo es la ficha tecnica de AchieveApex para otra IA (ChatGPT, Claude, un agente) o para una persona que pregunta "que hace Apex". Se le entregan estas carpetas (o los bundles de bundles/) y debe poder responder:

• Que puede hacer Apex y para que tipo de negocio.
• Que se logra con cada funcionalidad (resultado, no solo pasos).
• Que hace distinto a Apex frente a herramientas genericas (integracion nativa entre modulos, IA, multicanal, wallet).
• Como se usa cada funcion, con nombres reales de UI.

Por eso cada ficha lleva Que se logra y cada modulo lleva Para que sirve y Que lo hace diferente. Esas secciones se escriben con hechos del codigo, no con marketing.

1. README.md de modulo

---
id: slug-del-modulo
app: slug-de-la-app
nombre: Nombre en espanol
estado: shipped | beta | partial | admin | public
permiso: can_access_xxx (o "ninguno" si es publico)
---

# Nombre en espanol

Una o dos lineas: para que existe este modulo y a quien sirve.

## Para que sirve

Casos de uso reales del modulo (3 a 6), una linea cada uno, con tipo de negocio concreto:

- Una clinica usa esto para {resultado}.
- Una agencia de marketing usa esto para {resultado}.

## Que lo hace diferente

- Puntos concretos que no tiene una herramienta generica equivalente: integracion nativa con otros modulos de Apex (asistentes IA, automatizaciones, wallet, canales), datos compartidos (contacto unico entre CRM, finanzas, eventos), o capacidades propias. Solo lo confirmado en codigo.

## Acceso

- Ruta principal: `/[orgId]/...`
- Como se llega: `Header app switcher > App > Seccion` (o `Avatar menu > Settings > ...`)
- Permiso requerido: `can_access_xxx` y permisos granulares si aplican

## Alcance tecnico

- Frontend: rutas `page.tsx` relevantes y componentes principales
- Backend: servicios Feathers clave (no listar hooks uno a uno)
- Superficies publicas: rutas sin login si existen
- Integraciones externas: Stripe, Telnyx, Meta, Recall, S3, etc.

## Funcionalidades internas

| Funcionalidad | Archivo | Resumen |
|---------------|---------|---------|
| Nombre | [slug.md](slug.html) | Una linea |

## Relaciones

- Depende de: modulos que necesita (ej. Contactos, Currencies)
- Usado por: modulos que lo consumen (ej. Automatizaciones, Nova)

## Limitaciones y notas

- Reglas de negocio no obvias, limites, estados legacy, convivencia con otros modulos.

2. Archivo de funcionalidad interna {capacidad}.md

Una funcionalidad = una accion o capacidad que el usuario puede ejecutar o configurar. Ejemplos: "Asignar conversacion", "Importar contactos desde CSV", "Convertir estimate en invoice", "Publicar sitio con dominio propio".

---
id: slug-de-la-capacidad
modulo: slug-del-modulo
app: slug-de-la-app
nombre: Nombre en espanol
tipo: accion | configuracion | vista | automatizacion | integracion | publico
---

# Nombre en espanol

Que hace en una o dos lineas.

## Que se logra

- Resultado: que obtiene el usuario o el negocio al usar esto (una linea, concreta).
- Caso de uso: ejemplo real en una o dos lineas con tipo de negocio ("Una inmobiliaria ...").
- Se combina con: otras funcionalidades de Apex con las que suele usarse (solo si aplica).

## Donde esta

- Ruta: `/[orgId]/...`
- Acceso en UI: `Seccion > Boton/Tab/Menu` (nombres reales tal como aparecen)
- Componente(s): `NombreComponente.tsx`

## Como funciona

Pasos reales del usuario. Numerados.

## Campos y opciones

| Campo | Tipo | Obligatorio | Notas |
|-------|------|-------------|-------|

(Omitir la tabla si no hay formulario.)

## Reglas y validaciones

- Condiciones, limites, estados permitidos, permisos granulares (`can_edit_all_...`), que pasa en errores.

## Backend

- Servicios: `nombre-servicio` (metodo: find/get/create/patch/remove o custom)
- Hooks relevantes solo si cambian el comportamiento visible
- Efectos: notificaciones, emails, wallet, automatizaciones disparadas, webhooks

## Relaciones

- Requiere: otras funcionalidades o modulos
- Dispara / afecta: otras funcionalidades o modulos

## Notas

- Casos borde, comportamiento legacy, features flags, diferencias mobile/web.

3. Reglas de escritura

• Que se logra / Para que sirve / Que lo hace diferente se escriben con hechos: resultados observables, tipos de negocio reales, integraciones que existen en codigo. Prohibido el marketing vacio ("potente", "revolucionario", "lleva tu negocio al siguiente nivel").
• Nombres de UI en ingles tal como aparecen entre backticks (Create Deal), explicacion en espanol.
• Rutas con [orgId] literal.
• Servicios backend con su nombre de path exacto (conversations-bulk-actions).
• No incluir SQL, nombres de columnas ni codigo. Solo comportamiento.
• Si algo no se puede confirmar en el codigo, escribir Por confirmar: y la duda. No adivinar.
• Un archivo por funcionalidad. No agrupar varias en un archivo salvo que sean variantes triviales del mismo flujo.
• Apps de un solo modulo (sites, presentations, whiteboards, support-admin): los archivos de funcionalidad van directo en la carpeta de la app y el README.md de la app sigue el formato de modulo.