Funcionalidades

Catalogo de producto de AchieveApex. Cada app tiene su carpeta. Cada modulo tiene la suya. Cada funcionalidad interna es un archivo dentro de la carpeta del modulo.

Para que existe

Es la ficha tecnica de Apex para otra IA (ChatGPT, Claude, un agente) o para quien pregunte "que hace Apex". Empezar por FICHA-TECNICA.md. Para entregarlo a una IA usar los archivos de bundles/:

Tras editar fichas, desde achieveApex-Frontend corre node public/ai-docs/absolutize-links.mjs. Convierte los enlaces a URLs absolutas (https://www.achieveapex.com/ai-docs/...), regenera los bundles y valida que existan. No editar bundles/ a mano.

Acceso publico para IA: https://www.achieveapex.com/llms.html y https://www.achieveapex.com/ai-docs/FICHA-TECNICA.html. Cada ficha publicada es un .html estatico generado por node public/ai-docs/build-html.mjs. No enviar a una IA enlaces .md ni .txt. Google no indexa estas paginas (googlebot: noindex); ChatGPT y Claude si pueden abrir el HTML.

Nombre

Usamos funcionalidades y no modulos ni docs porque:

• Un modulo es el contenedor (Conversaciones, Invoices, Sites).
• Lo que vamos a describir dentro son las funcionalidades internas de ese modulo.
• src/app/(docs) es el sitio publico de API. Este arbol es el inventario de producto orientado a IA.

Ruta canonica:

achieveApex-Frontend/public/ai-docs/

Estructura

funcionalidades/
  README.md                 ← este indice
  FICHA-TECNICA.md          ← vision del producto para una IA: que es, que lo hace distinto, limites
  PLANTILLA.md              ← formato de README de modulo y de ficha
  build-bundles.mjs         ← genera bundles/
  bundles/                  ← concatenados por app y completo (generados, no editar)
  {app}/
    README.md               ← lista de modulos de la app
    {modulo}/
      README.md             ← para que sirve, que lo hace diferente, acceso, alcance, tabla de fichas
      {funcionalidad}.md    ← una por capacidad: que se logra, donde esta, pasos, campos, reglas, backend

Apps de un solo modulo (sites, presentations, whiteboards, support-admin) no anidan otra carpeta: las fichas van directo en la carpeta de la app.

Convencion de slugs

Carpetas en kebab-case, estables, alineadas al producto (no a traducciones de UI):

No renombrar slugs al traducir titulos. El titulo en espanol vive dentro del README.md del modulo.

Mantenimiento

Cada funcionalidad nueva se revisa con el skill funcionalidades-catalog:

• Si es una capacidad de producto (app, modulo o funcion interna usable), se agrega aqui.
• Si es bugfix, refactor, hook, cron o migracion sin UX nueva, no se agrega.

Estado de este arbol

• Inventario de apps y modulos: listo (15 apps, 89 modulos).
• Funcionalidades internas: documentadas (822 fichas). Cada ficha se escribio leyendo el codigo real de frontend y backend; lo no confirmable esta marcado como Por confirmar: (151 dudas concretas en 132 archivos).
• Capa de valor: cada ficha tiene Que se logra (resultado, caso de uso, con que se combina) y cada modulo tiene Para que sirve y Que lo hace diferente, escritos con hechos del codigo y sin marketing.
• Calidad: cada ficha sigue PLANTILLA.md. Esta prohibido el texto plantilla generico (pasos como "abre la seccion correspondiente"); si una ficha no puede describir pasos reales, no se crea.

Apps