Mapa de documentación por repo
1. Qué es esta página
Sección titulada «1. Qué es esta página»El registro de a qué audiencias documenta cada repo activo y por qué. Es la aplicación concreta del eje de audiencia de la sección 06 sobre el parque real de aplicaciones.
Qué NO es. No es el inventario de aplicaciones: ese vive en la tabla Applications de SeaTable, con su fase, su dueño, sus servidores y sus credenciales, y es el único lugar donde se mantiene (regla de separación, 06 §2). Aquí solo se registra la decisión de documentación. La columna “Qué hace” es una línea de contexto para leer la tabla, no la descripción canónica de la app — esa está en Applications.
Consecuencia práctica: si una app cambia de nombre, de dueño o de fase, esta página no se toca. Solo se actualiza cuando cambia a quién documenta.
2. La regla de asignación
Sección titulada «2. La regla de asignación»El eje y la lista cerrada de audiencias están en 06 §6.1. Lo que esta página resuelve es el juicio que hay que hacer por repo:
¿Hay alguien que usa esta app y necesita una guía? ¿En calidad de qué?
La respuesta puede ser más de una, y entonces el repo documenta a más de una audiencia. Lo que no documenta a nadie de cara al usuario son los servicios sin interfaz de uso: sincronizaciones, monitoreo, infraestructura y tooling. Nadie “usa” un workflow de CI.
Los otros dos destinos no requieren juicio: todo repo lleva internal/ (su
documentación técnica, para el equipo) y agent/ (su referencia densa para agentes,
aunque nazca vacía).
3. El mapa
Sección titulada «3. El mapa»Leyenda: ✅ documenta a esa audiencia · — no.
Equipo es docs/internal/; las tres audiencias de usuario salen de docs/public/<iface>/; Agentes es docs/agent/ más los agent: true.
3.1 Repo central
Sección titulada «3.1 Repo central»| # | Repo | Qué hace | Equipo | Colab. | Vendors | Customers | Agentes |
|---|---|---|---|---|---|---|---|
| 0 | 000-dev-ops-model |
El modelo operativo (este contenido) y la plataforma que lo publica | ✅ | — | — | — | ✅ |
3.2 Apps con documentación de usuario
Sección titulada «3.2 Apps con documentación de usuario»| # | Repo | App | Qué hace | Equipo | Colab. | Vendors | Customers | Agentes |
|---|---|---|---|---|---|---|---|---|
| 1 | app-023-vendor-portal |
Vendor Portal | Proveedores actualizan datos, suben facturas y consultan su estatus; el lado admin gestiona aprobaciones y órdenes de compra | ✅ | ✅ | ✅ | — | ✅ |
| 2 | app-030-customer-hub |
Customer Hub | Frontend autogestionado para que los clientes vean el estado de los procesos de la agencia | ✅ | — | — | ✅ | ✅ |
| 3 | app-026-epr-core-crm |
EPR Core CRM | Gestión integral del ciclo de influencer marketing: proyectos, influencers, contratos, compromisos y resultados | ✅ | ✅ | — | — | ✅ |
| 4 | app-022-prism-insights |
Prism Insights | Reportes automáticos en PowerPoint con IA a partir de los datos de Power BI; tiene pantallas comunes y módulos solo internos | ✅ | ✅ | — | ✅ | ✅ |
| 5 | app-009-people-and-culture |
People and Culture | Sincronización bidireccional entre Microsoft Entra ID y SeaTable para el ciclo de vida de usuarios y grupos | ✅ | ✅ | — | — | ✅ |
| 6 | app-012-signature-generation |
Prism Signature Generator | Genera las firmas corporativas de correo con IA | ✅ | ✅ | — | — | ✅ |
| 7 | app-028-core-identity |
Core Identity | Identidad, autenticación y autorización del ecosistema; además protege el sitio del equipo vía reverse proxy | ✅ | ✅ | ✅ | ✅ | ✅ |
Core Identity documenta a las tres. Es dueño de la documentación de acceso —qué es
este portal, cómo entro, cómo recupero mi cuenta—, que es pre-login y la misma para todos.
Su _meta.yml la mapea a la lista completa y el build la copia a los tres portales: es la
sección abierta de cada uno (06 §6.2). Es la única app de infraestructura con public/, y
la razón es esa: el acceso es su función.
3.3 Apps sin documentación de usuario
Sección titulada «3.3 Apps sin documentación de usuario»Servicios, sincronizaciones y monitoreo: no tienen interfaz de uso que documentar.
| # | Repo | App | Qué hace | Equipo | Colab. | Vendors | Customers | Agentes |
|---|---|---|---|---|---|---|---|---|
| 8 | app-032-service-status |
Service Status | Monitorea las APIs, servicios y servidores de Prism | ✅ | — | — | — | ✅ |
| 9 | app-001-automate-campaigns |
Automate Campaigns | Descarga, compara y actualiza datos de campañas desde Lefty, Talkwalker y Traackr | ✅ | — | — | — | ✅ |
| 10 | app-008-sync-database |
Sync Database | Sincroniza SeaTable con MySQL para alimentar Power BI | ✅ | — | — | — | ✅ |
| 11 | app-031-appdev |
AppDev | Sin descripción en Applications — pendiente de completar | ✅ | — | — | — | ✅ |
| 12 | app-034-infra-recovery |
Infra Recovery | Sin descripción en Applications — pendiente de completar | ✅ | — | — | — | ✅ |
3.4 Infraestructura y tooling
Sección titulada «3.4 Infraestructura y tooling»| # | Repo | Qué es | Equipo | Colab. | Vendors | Customers | Agentes |
|---|---|---|---|---|---|---|---|
| 13 | app-021-seatable-tools |
Procesos sobre la base Brand PR: transformación de URLs y traspaso de registros entre tablas | ✅ | — | — | — | ✅ |
| 14 | packages |
Paquetes compartidos (cubre las filas PCKG-001 a PCKG-007 de Applications) | ✅ | — | — | — | ✅ |
| 15 | ci-actions |
Actions de CI reutilizables; versiona los aplicativos | ✅ | — | — | — | ✅ |
| 16 | ci-workflows |
Workflows de CI reutilizables | ✅ | — | — | — | ✅ |
Resumen: 17 repos · 7 con documentación de usuario · 17 con documentación de equipo y corpus de agentes · 4 portales en total (equipo, colaboradores, proveedores, clientes).
4. Las interfaces de cada app
Sección titulada «4. Las interfaces de cada app»La audiencia se declara por interfaz, con el nombre que la interfaz tiene en el código
(06 §6.1). Este es el mapa que va en el docs/_meta.yml de cada repo:
| Repo | Interfaz | Audiencia | Estado del nombre |
|---|---|---|---|
app-023-vendor-portal |
portal |
vendors |
Confirmado en código: client/src/pages/ tiene admin/ como subárbol aparte; el resto (invoices, profile, purchase-orders, form_tax) es el lado del proveedor |
admin |
collaborators |
idem | |
app-022-prism-insights |
pantallas comunes | [collaborators, customers] |
Por confirmar el nombre real en el código |
| módulos internos | collaborators |
idem | |
app-028-core-identity |
acceso | [collaborators, vendors, customers] |
Por confirmar el nombre real en el código |
app-030-customer-hub |
interfaz única | customers |
Por confirmar |
app-026-epr-core-crm |
interfaz única | collaborators |
Por confirmar |
app-009-people-and-culture |
interfaz única | collaborators |
Por confirmar |
app-012-signature-generation |
interfaz única | collaborators |
Por confirmar |
Los nombres marcados como “por confirmar” se fijan al andamiar cada repo, leyendo su
código: la carpeta de documentación debe llamarse como la interfaz que documenta. Los tres
nombres reservados —internal, public, agent— no pueden usarse como nombre de interfaz.
5. Fuera del mapa
Sección titulada «5. Fuera del mapa»Repos que existen en Gitea y no entran a la plataforma, con el motivo. Están aquí para que su ausencia se lea como decisión y no como olvido.
| Repo | Motivo |
|---|---|
app-016-api-run-script |
App Deprecated (APP-016) |
app-010-mastercard · app-011-submitdocs · app-024-x-scrapper |
Apps en Backlog: entran cuando se activen, por su propio botón |
collect-stories |
Sin registrar en la tabla Applications |
Y dos apps registradas en Applications, en fase Production, que no tienen repo:
APP-013 Client Events y APP-027 Project Requests. Si son nativas de SeaTable, no les
corresponde repo ni documentación en la plataforma; conviene dejarlo explícito en su fila.
6. Cómo se mantiene
Sección titulada «6. Cómo se mantiene»- Una app nueva entra por el botón
Create Repode Applications (05 §6.2). Al registrarla se responde la pregunta de §2, y la respuesta queda en sudocs/_meta.ymly en esta tabla. - Un cambio de audiencia (una app que empieza a servir a clientes, por ejemplo) se hace
en el
_meta.ymlde su repo y aquí. Elsources.ymlcentral no cambia: la audiencia no es propiedad de la app en el registro de fuentes. - El gate protege lo que importa. Una interfaz sin audiencia declarada, o una audiencia fuera de la lista cerrada, detienen el build. Lo que esta página aporta y el gate no es el por qué: la justificación de cada asignación.
7. Relación con el resto de la documentación
Sección titulada «7. Relación con el resto de la documentación»| Para conocer | Dónde |
|---|---|
| El eje de audiencia, la lista cerrada y las reglas de integridad | 06 §6.1 |
| Cómo se entra a la documentación y qué está protegido | 06 §6.2 |
| Por qué el inventario no se duplica aquí | 06 §2 |
| Cómo entra una app nueva a la plataforma | 05 §6.2 |
| La mecánica del sync y del ruteo | plataforma-documentacion/architecture.md |
| El trabajo de andamiaje repo por repo | plans/20260903_APP-000-0808_plataforma-documentacion.md |
Historial de versiones
Sección titulada «Historial de versiones»| Versión | Fecha | Cambio |
|---|---|---|
| v2.0 | 2026-09-03 | Reescrita sobre el eje de audiencia (06 v2.0): las columnas de cotejo pasan de tiers (public/internal/agent) a destinos (equipo · colaboradores · proveedores · clientes · agentes). Prism Insights suma audiencia de clientes (pantallas comunes + módulos internos). Core Identity entra con documentación de usuario por ser dueño de la documentación de acceso. Nueva §4 con el mapa de interfaces por app, marcando cuáles nombres están confirmados en el código y cuáles se fijan al andamiar. |
| v1.0 | 2026-09-03 | Versión inicial. Consolida en una página el mapa de tiers de los 17 repos con documentación, que antes vivía repartido entre el plan y sources.yml. Registra los repos fuera del mapa con su motivo. |