Contexto

Signage arrastraba dos sistemas de portal para clientes externos:

1. El vivo: ClientProject con su enlace público /client/<token> en signage/views.py — usado, deployado en PROD.
2. El muerto: ClientShareLink + PortalChangeLog (share links con niveles de permiso, cola de aprobaciones, auditoría) — nunca tuvo interfaz (0 referencias en JS/templates) y nunca tuvo datos (0 filas en ambas tablas tras auditoría en PROD).

El portal muerto comprendía:

• 22 endpoints API repartidos en 3 módulos: share_links.py (6 endpoints), portal.py (12 endpoints), approvals.py (4 endpoints).
• ~1.030 líneas de código en total.
• 2 modelos Django: ClientShareLink (link compartible UUID), PortalChangeLog (auditoría + cola de aprobación).
• 2 admin classes para gestión manual.
• Tests dedicados que solo ejercitaban estos endpoints (retirados junto con la feature).

Decisión

Retirado entero el 14 de agosto de 2026 (v1.66.18) — decisión de Edu tras task #226, punto 6.

Justificación:

• ✅ Cero datos: Auditoría verificó 0 filas en PROD antes de cortar.
• ✅ Cero interfaz: Ningún componente JS/template referenciaba el portal muerto.
• ✅ Arquitectura más clara: Un único portal (ClientProject) en lugar de dos.
• ✅ Menor carga de mantenimiento, auditoría y seguridad.
• 🔮 Reversible: Si en el futuro se necesitan niveles de permiso + cola de aprobaciones para el portal vivo, se construirá sobre ClientProject.

Detalles de Implementación

Migración signage 0016

La migración depende explícitamente de core 0031 porque:

• Las migraciones core 0017, 0019 y 0022 crean políticas RLS sobre estas tablas por SQL crudo.
• En BD fresca, el DROP debe ir después de la limpieza de policies de core.
• La política dependía de organization_id — se tumba antes del DROP COLUMN (error DependentObjectsStillExist cazado en desarrollo).

Orden correcto:

1. Core 0031 + policies cleanup.
2. Signage 0016 → DROP de tablas ClientShareLink y PortalChangeLog.

Archivos Modificados

Eliminados:

• signage/api/approvals.py (239 líneas)
• signage/api/portal.py (552 líneas)
• signage/api/share_links.py (~6 endpoints)
• signage/models_portal.py (eliminado, era módulo dedicado)

Modificados:

• signage/api/__init__.py — quita imports de los 3 routers eliminados.
• signage/admin.py — quita 2 @admin.register classes.
• context/agents/dev-signage.md — actualiza ficha (documenta la retira).
• Bump versión: config/settings/base.py, README.md, CHANGELOG.md, RELEASE_NOTES.md → v1.66.18.

Impacto en Usuario

Ninguno visible — el portal muerto nunca llegó a producción. Los clientes externos que usaban ClientProject no ven cambio.

Aprendizajes

Este cambio ilustra auditoría preventiva: antes de retira, se verificó la carga de datos real. Sin datos + sin interfaz = seguro retira. Patrón aplicable a otras features expertas o obsoletas en el grafo de Signage.

Véase también

• [[concept—saas—multi-tenancy]] — RLS e isolation del portal cliente en multi-tenancy
• [[incident—20260609—audit-suprema-signage]] — auditoría que provocó esta decisión (hallazgos R3 en portal)
• [[decision—20260403—multi-tenancy-rls]] — decisión arquitectónica de RLS que afecta a las políticas eliminadas