Hoja de ruta — Features pendientes por implementar

Una lista de trabajo genuinamente incompleto o faltante, compilada leyendo el código actual directamente (no confiando en documentación anterior — varios "huecos" documentados anteriormente resultaron estar ya arreglados para cuando se escribió esta lista, p. ej. storyViewers, getCurrentSession, terminateAllSessions, la aplicación de canStory, las pestañas de descubrimiento de RecommendationsSection, y la UI de invitar/eliminar de CollaboratorsModal). Marca los elementos a medida que se completen, y vuelve a verificar contra el código antes de asumir que un elemento sigue pendiente — esta lista se desactualizará de la misma forma que las demás.

Cada elemento incluye su impacto real y la evidencia de por qué sigue incompleto.

---

Seguridad y prevención de abuso

• No hay protección contra fuerza bruta en el login de usuarios normales. El login de administrador sí tiene un bloqueo real por intentos fallidos (MAX_FAILED_LOGIN_ATTEMPTS, admin-user.manager.js), pero la mutation login de cara al cliente (authentication.manager.js) no tiene ninguno — sin bloqueo, sin límite de tasa, sin CAPTCHA como respaldo. Impacto: Alto — un atacante puede intentar contraseñas ilimitadas contra cualquier cuenta. Arreglado: login() ahora replica el bloqueo de administrador (nuevas columnas User.failedLoginAttempts/lockedUntil + migración, límite de tasa por usuario en memoria vía rate-limiter.service.js, mensajes traducidos de bloqueo/intentos restantes en en/es — lo cual también arregló claves de traducción faltantes que el propio flujo de administrador nunca tuvo para esos mismos mensajes).
• No hay límite de tasa por IP en los endpoints sensibles de autenticación. El directive @rateLimit de GraphQL ya está conectado en el esquema (api/server.js) y funciona (respaldado por Redis en producción, con reserva en memoria en desarrollo), pero se aplica a exactamente dos campos en todo el backend (recordAdImpression/recordAdClick, ad-revenue.type.js). login, requestPhoneOtp (cuesta dinero real por SMS en cada llamada), forgotPassword, register, verifyLoginTwoFactor, y adminLogin no tienen ningún límite de tasa. Impacto: Alto para OTP (costo directo por cada llamada de abuso) y login (relleno de credenciales); Medio para registro/reseteo de contraseña (spam/enumeración). Arreglado: se agregó @rateLimit a login, register, requestPasswordReset, verifyLoginTwoFactor, requestPhoneOtp, loginWithPhone, adminLogin, adminVerify2FA. También se arregló un bug real encontrado de paso: el keyGenerator compartido en api/server.js tenía un cuerpo de bloque sin return, así que todo campo @rateLimit existente (incluyendo los dos de arriba) estaba usando undefined como clave en silencio, en vez de por IP.
• No hay middleware global de límite de tasa de peticiones. express-rate-limit es una dependencia instalada pero no está montada en ningún lugar de api/server.js — no hay ningún límite general por IP sobre el tráfico de /graphql o /admin/graphql, solo los dos campos decorados con @rateLimit de arriba. Arreglado: montado en /web/graphql y /admin/graphql (instancias de límite separadas), reutilizando el umbral ya existente RATE_LIMITS.API_GENERAL de constants/admin-security.js.
• Los valores de límite de tasa / umbral de abuso no son configurables desde la UI de administración. RATE_LIMITS es un objeto plano fijado en constants/admin-security.js, consumido directamente por rate-limiter.service.js — cambiar un umbral durante un incidente activo de abuso significa un despliegue de código, no una edición en el panel de administración. No existe ninguna query/mutation ni página de frontend para esto. Impacto: Bajo-Medio. Arreglado: rate-limiter.service.js ahora superpone anulaciones de administrador (persistidas vía el mecanismo de configuración JSON de system-settings.manager.js, que ya existía pero no estaba conectado) sobre los valores predeterminados fijos, aplicadas de inmediato en memoria sin necesidad de reiniciar; nuevo esquema adminGetRateLimits/adminUpdateRateLimit/adminResetRateLimit solo para super-admin + una nueva página de administración /system/rate-limits (RateLimitsContent.tsx) para editarlos.
• No hay lista de bloqueo de IP/dispositivo para usuarios finales (prevención de evasión de bans). Un usuario baneado puede simplemente volver a registrarse desde la misma IP/dispositivo hoy — no hay nada que lo impida. La única funcionalidad de lista de IP en el código (admin-ip-whitelist.manager.js, la página /ip-whitelist) está enfocada por completo en poner en lista blanca IPs para el acceso de login de administradores, no para bloquear cuentas de usuarios finales; el modelo User no tiene ningún campo tipo lastLoginIp/deviceFingerprint, y no existe ninguna mutation de ban por IP/dispositivo en ningún lugar. Impacto: Alto — esta es una de las necesidades de confianza y seguridad más comunes para una plataforma social/de creadores, y esta plataforma no tiene nada para ello. Arreglado: nuevas columnas User.lastLoginIp/lastLoginDeviceId (pobladas en registro e inicio de sesión en todos los caminos de creación de cuenta: email/contraseña, Firebase, Apple, OTP por teléfono) más una nueva tabla blocked_identifier + ban-evasion.manager.js, verificada en register()/login() antes de cualquier otro trabajo. Nuevo esquema adminBlockIdentifier/adminUnblockIdentifier/adminGetBlockedIdentifiers protegido por BAN_USERS, una nueva página de administración /moderation/blocklist, y la última IP/dispositivo conocidos ahora se muestran en adminGetUserDetails con una acción en línea "Bloquear IP"/"Bloquear dispositivo" directamente en la página de detalle del usuario. Hueco conocido, revelado honestamente: el bloqueo a nivel de dispositivo solo funciona si el cliente envía un deviceId (opcional) en UserRegistrationInput — el formulario de registro de apps/frontend-nextjs todavía no genera/envía uno, así que hoy el bloqueo por dispositivo está listo en el backend pero no se ejerce de extremo a extremo desde la web; el bloqueo por IP no tiene ese hueco porque la IP la deriva el servidor, no la envía el cliente, así que es totalmente efectivo hoy.
• grantVerification/removeVerification no realizan ninguna verificación real de autorización de administrador. graphql/resolvers/verification.resolver.js protege ambas mutations solo con if (!context.user) (no context.admin), y luego pasa el propio id de usuario regular de quien llama como si fuera el administrador que actúa. La verificación interna isAdmin() del manager (managers/user-managers/verification-badges.manager.js) comprueba user.accountType === 'admin' || user.is_admin === true, pero nada en el código jamás fija accountType a 'admin' y is_admin no es una columna real — así que hoy las mutations son autodestructivas (nadie puede pasar la verificación), pero el resolver en sí no tiene ninguna autorización real, y el propio comentario de una mutation hermana confirma que el camino de rechazo ya tuvo este mismo hueco arreglado. Impacto: Alto — un bug latente de verificación de privilegios que se reabriría para cualquier usuario autenticado en el momento en que se arregle la verificación interna sin arreglar también el resolver. Arreglado: se retiraron ambas mutations del esquema/resolver por completo en vez de parchear la verificación en su lugar — esta ruta nunca puede llevar un contexto de administrador real (context.admin solo se llena en /admin/graphql, ver graphql/context/index.js), y el equivalente correctamente protegido (adminVerifyUser/adminRemoveVerification) ya existe y es lo que realmente llama el panel de administración.
• Seguir/dejar de seguir/bloquear en masa tienen un límite de tamaño por llamada pero ninguna aplicación de límite de abuso diario/por hora. managers/user-managers/bulk-operations.manager.js#getBulkLimits calcula dailyFollowLimit/hourlyFollowLimit/dailyBlockLimit, etc., pero la verificación de uso está comentada (// TODO: Check current usage against limits). bulkFollowUsers/bulkUnfollowUsers/bulkBlockUsers solo limitan el tamaño del lote de una sola llamada (50 por defecto) — nada impide llamarlas cientos de veces por hora. Impacto: Alto — un vector real de spam de seguir/bloquear en masa, distinto de los huecos de límite de tasa de login/OTP de arriba. Arreglado: las tres ahora verifican el uso real (sumado desde filas de bulk_operation) contra el límite antes de hacer cualquier trabajo; getBulkOperationLimits también ahora devuelve currentUsage/remaining reales en vez del stub comentado. También se arreglaron dos bugs adyacentes: bulkUnfollowUsers/bulkBlockUsers nunca verificaban siquiera que el usuario que actúa existiera, y batch_size_exceeded no tenía traducción (mostraba la clave cruda en silencio).
• Las transferencias de billetera de plataforma de administrador (transferToUser/takeFromUser/topUp en managers/coin-managers/platform-wallet.manager.js) no registran qué administrador actuó. Cada una acepta un parámetro adminId pero nunca lo persiste — no hay columna adminId/performedBy en CoinTransaction, ni entrada de registro de auditoría. Un super-admin puede mover monedas hacia o desde el saldo de cualquier usuario sin ningún registro de quién lo hizo. Impacto: Medio-Alto — financieramente sensible y no cubierto por ningún otro sistema de registro de acciones de administrador. Arreglado: transferToUser/takeFromUser ahora estampan el administrador que actuó en CoinTransaction.relatedId; las tres (incluyendo topUp, que no tiene fila de libro contable por usuario a la cual adjuntarse) también registran vía analyticsService.trackAdminAction — el mismo mecanismo que respalda el registro de actividad de administración.

Huecos de lógica de backend (stubs reales, no solo UI faltante)

• Todo el sistema de restricción de cuentas no tiene capa de persistencia. restrictUser/unrestrictUser/addRestriction/removeRestriction/getUserRestrictions/getRestrictionStats/cleanupExpiredRestrictions tienen todos // TODO: store/deactivate/get restriction details in database y no hacen nada o devuelven un objeto mockRestrictions/estadísticas en cero fabricado; checkRateLimit usa un mockCurrentUsage = { hourly: 5, daily: 25 } fijo sin importar el uso real. getRestrictedUsers (admin) siempre devuelve []. Archivo: managers/user-managers/restrictions-limits.manager.js. Impacto: Alto — toda la herramienta de moderación/soft-ban "restringir usuario" no registra nada, no envía notificaciones, y las verificaciones de límite de tasa son falsas. Arreglado: nueva tabla account_restriction (con ese nombre para no chocar con el modelo UserRestriction ya existente y real — la función social "Restringir" entre usuarios) respalda cada método de verdad; checkRateLimit ahora cuenta filas reales de las tablas de posts/comentarios/mensajes/follows/likes en vez de un mock fijo. También se arreglaron varios bugs descubiertos al conectar esto: la verificación interna de admin comprobaba User.accountType==='admin' (el mismo patrón muerto ya retirado de grantVerification/removeVerification, reemplazado por una búsqueda real en AdminUser); la forma de retorno de getUserRestrictions nunca pudo haber serializado contra su propio tipo de esquema [UserRestriction!]!; getRestrictedUsers estaba conectado permanentemente al método de manager equivocado (un objeto de estadísticas, no una lista de usuarios) y la verificación user.isAdmin de su resolver nunca podía ser verdadera en esa ruta — reemplazado por queries/mutations propiamente admin-prefijadas (adminGetRestrictedUsers, adminGetRestrictionStats, adminRestrictUser, adminUnrestrictUser, adminAddUserRestriction, adminRemoveUserRestriction) protegidas por una verificación real del permiso BAN_USERS; y dos discordancias silenciosas de nombres de acción (post vs posting_disabled, post vs posts_per_hour) que un valor de respaldo || 10/|| 50 había estado ocultando. No se construyó UI de panel de administración nueva para las nuevas mutations en esta pasada — un admin ya puede invocarlas hoy, pero todavía no hay ninguna página de /moderation conectada a ellas.
• Menciones/Tags: "quién me mencionó", "a quién mencioné", y la aprobación de etiquetas nunca tocan datos reales. getUsersMentionedBy/getUsersIMentioned/getTaggedInPosts (mentions-tags.manager.js) siempre devuelven arreglos vacíos simulados sin importar el input — la consulta real contra PostMention/MessageMention (comentada en el código) nunca se escribió; approveTag/rejectTag/getTagPermissions/updateTagPermissions nunca persisten (solo hacen log a consola). El frontend (Configuración → Historial de menciones, MentionHistoryPage.tsx) está completamente conectado y las llama correctamente; simplemente siempre renderiza vacío. Impacto: Medio-Alto — una funcionalidad real, visible, siempre rota, más un flujo de aprobación de etiquetas pendientes que sería un no-op silencioso si se construyera. Corregido: getUsersMentionedBy/getUsersIMentioned ahora ejecutan consultas reales contra PostMention (tags/menciones en captions de posts) y MessageMention (@menciones en chat - nuevo data-access-services/message/message-mention.access-service.js, ese modelo ya existía pero no tenía todavía un access-service de lectura), combinadas y deduplicadas a una entrada por mencionador/mencionado, de más reciente a más antiguo - coincidiendo con la forma [User!]! del schema que el resolver ya esperaba pero el mock viejo nunca producía. getTaggedInPosts ahora ejecuta una consulta real de PostMention con la forma de los tipos TaggedPostsResponse/TaggedPost del schema. Al investigar approveTag/rejectTag se descubrió que nunca fueron realmente alcanzables (ningún campo del schema los declara - graphql/types/user-features.type.js solo declaraba updateTagPermissions) y están completamente superados por un flujo ya real, con nombres distintos, approvePostTag/rejectPostTag (post.manager.js, graphql/types/tag-review.type.js) construido para exactamente la misma funcionalidad de revisión de etiquetas - así que en vez de resucitar stubs duplicados y muertos, se eliminaron (junto con el también muerto y duplicado mentions-tags.manager.js#canTagUser - una copia distinta e inalcanzable del canTagUser real ya corregido en content-tag.manager.js, ver el ítem de comprobaciones de bloqueo/privacidad arriba), junto con sus wrappers inalcanzables en la fachada managers/user-managers/index.js. getTagPermissions/updateTagPermissions ahora leen/escriben a través de la misma configuración de privacidad real ya persistida (who_can_tag/require_approval_for_tags en User.settings.privacy, vía privacy-settings.manager.js) que ya aplica cada ruta de código real de creación de etiquetas/menciones, en vez de un objeto paralelo que nunca se guardaba en ningún lado; también se corrigió el resolver de updateTagPermissions, que antes tragaba un error del manager en un objeto {success:false, message} aunque el tipo de retorno TagPermissions! del schema no tiene esa forma (ahora lanza el error, como cualquier otra mutación del archivo). De paso, se corrigió el mismo bug de desplazamiento de argumentos encontrado repetidamente en este pase en getMentionTagStats: el resolver ignoraba por completo el argumento timeframe del schema y llamaba al manager con 2 argumentos posicionales cuando la firma real necesita 3; getMentionTagStats en sí ahora se respalda con conteos reales de ambas tablas de menciones (antes ceros fijos), dejando topMentioners/topTaggers como un arreglo vacío honesto ya que ordenarlos necesita una consulta agregada de agrupación que no existe en ningún lugar de este código y este campo no tiene ningún llamador de frontend hoy que justifique construirla especulativamente. No se necesitó UI de frontend nueva: MentionHistoryPage.tsx ya consume usersMentionedBy/usersIMentioned directamente (confirmado real según la propia nota del roadmap arriba) y ahora renderiza datos reales en vez de listas siempre vacías; taggedInPosts/tagPermissions/updateTagPermissions/getMentionTagStats siguen sin un consumidor de frontend, pero la investigación encontró que esto es intencional, no un hueco - TagsScreenPage.tsx (pestañas Etiquetado/Pendiente) y TagsAndMentionsPage.tsx (controles de privacidad de etiquetas/menciones) ya implementan completamente las funcionalidades equivalentes de cara al usuario a través de un par distinto y ya correcto de campos de GraphQL (taggedPosts/pendingTagReviews+approvePostTag/rejectPostTag, y privacySettings+updatePrivacySettings/updateExtendedPrivacySettings, respectivamente) - corregir estos campos igual importa para un futuro cliente de iOS/Android o cualquier otro llamador que los alcance directamente, según la regla de completitud del schema de este proyecto. Se añadieron nuevos archivos de operación .graphql para las seis queries/mutations corregidas (Web/Profile/{UsersMentionedByInline,UsersIMentioned,TagPermissionsInline,UpdateTagPermissionsInline,TaggedInPostsInline,GetMentionTagStatsInline}.graphql, dos de las cuales ya existían) y se recompiló apollo-web.
• El conteo de conexiones mutuas está fijado en 0. advanced-social.manager.js#getMutualConnectionsCount es un // TODO: Implement efficient mutual connections counting … return 0 de una línea, que alimenta networkMetrics.mutualConnectionsCount y el mapeo de sugerencias de contactos (mutualConnections en ContactSuggestion también está fijado por separado en 0, en contact-import.manager.js). Impacto: Medio — un número visible que siempre es cero donde sea que se muestren las conexiones mutuas. Arreglado: getMutualConnectionsCount ahora usa un nuevo user-follow.access-service.js#countReciprocalFollows (conteo real de follows recíprocos); el hardcode de ContactSuggestion.mutualConnections en realidad ya se había movido a graphql/resolvers/user-contact-import.resolver.js para cuando se arregló esto (ya no en contact-import.manager.js — la nota del roadmap estaba desactualizada) y ahora usa el ya existente y ya real getMutualFollowing(viewerId, targetId). También se encontraron y arreglaron dos lugares más con el mismo hardcode a 0 en la zona, ambos en search-discovery.manager.js (getPopularUserSuggestions, getNewUserSuggestions) — arreglados reutilizando el propio _computeSearchRelations de ese archivo, la misma consulta agrupada que searchUsers ya usaba. Un tercer lugar sospechoso (search-discovery.manager.js:1147, referenciado por un comentario como todavía roto) resultó ya estar correcto: searchUsers sobrescribe ese valor fijo por defecto con el valor real calculado inmediatamente después, así que solo quedó como un comentario desactualizado para futuros lectores, no un bug real en producción.
• Los niveles de privacidad de ubicación no funcionan. user-location.manager.js#canSeeLocation tiene tres comentarios // TODO y siempre return true después de la verificación del propio usuario; setLocationPrivacy escribe un valor privacy_level en una columna que no existe en el modelo UserLocation, así que Sequelize lo descarta en silencio — un no-op. El único control de privacidad de ubicación real y aplicado hoy es el booleano simple isPublic. Impacto: Medio. Corregido: nueva columna UserLocation.privacyLevel (public/friends/private, la migración establece public por defecto en las filas existentes para preservar el comportamiento real actual, ya que la verificación anterior siempre devolvía true); canSeeLocation ahora sí evalúa el valor (private → false, friends → delega en el close-friends.manager.js#isCloseFriend real, public/por defecto → true); se corrigió setLocationPrivacy para escribir el atributo camelCase privacyLevel en lugar del snake_case que se descartaba en silencio. Se expusieron en el schema la nueva query canSeeLocation(userId) y la mutación setLocationPrivacy(privacyLevel) (antes ninguna existía en el tipo orientado al cliente). Implementado de punta a punta: la página ya existente de apps/frontend-nextjs en Configuración → Compartir ubicación (LocationSharingPage.tsx) ahora tiene un control real de público/amigos cercanos/privado conectado a la nueva mutación, con textos i18n en en.json y es.json.
• getDataPortabilityInfo devuelve una forma completamente equivocada, y la salida de exportación de datos en CSV/XML es de calidad de relleno incluso donde es alcanzable. getDataPortabilityInfo reenvía a getDataExportStatus, que no tiene ninguna de las claves canExport/exportFormats/retentionPeriod/lastExport que el esquema declara no-nulas, así que consultarlo lanza un error. Por separado, DataExportRequestInput no tiene ningún campo format — no hay forma de solicitar CSV/XML vía GraphQL — y hasta el propio convertToCSV/convertToXML del manager (data-export.manager.js) solo emiten un resumen de conteo de 2-3 líneas, no los datos exportados reales, a diferencia del camino JSON que sí es completamente real. Impacto: Bajo-Medio. Corregido: getDataPortabilityInfo ahora es un método real de data-export.manager.js que devuelve la forma real de DataPortabilityInfo (canExport en false mientras hay una exportación pendiente/procesándose, exportFormats: ['json','csv','xml'], un retentionPeriod de 30 días acorde con la ventana expiresAt ya existente, lastExport a partir de la fila ready más reciente vía un nuevo método findLatestCompletedByUserId en el access-service). Se añadió DataExportRequestInput.format (y el correspondiente DataExportStatus.format) al schema (backend y los dos espejos schema.web.graphqls/schema.admin.graphqls) y se conectó a requestDataExport, con validación real (validation.invalid_export_format) que rechaza cualquier valor fuera de json/csv/xml. convertToCSV/convertToXML ahora emiten los datos reales fila por fila (perfil/posts/comentarios/mensajes/seguidores/seguidos) con el escapado correspondiente, en lugar de un resumen de conteo de 2-3 líneas. Implementado de punta a punta: la página ya existente Configuración → Descargar tu información (DownloadDataPage.tsx) ahora tiene un selector de formato real conectado a la mutación de solicitud y muestra la información de portabilidad en vivo, con textos i18n en en.json y es.json.
• Un par de interruptores de notificaciones de seguridad muerto y roto convive con uno que sí funciona. enableSecurityNotifications/disableSecurityNotifications/getSecurityNotificationSettings nunca persisten (TODO: Update user security notification settings, siempre devuelve valores predeterminados) mientras una implementación separada y real (getSecurityNotificationPrefs/updateSecurityNotificationPrefs) existe en el mismo archivo y es la que realmente está conectada a la UI. Ambos pares están expuestos vía GraphQL. Archivo: managers/user-managers/security-alerts.manager.js. Impacto: Medio — llamar al par muerto devuelve success: true pero no hace nada en silencio. Corregido: se retiraron por completo enableSecurityNotifications/disableSecurityNotifications/getSecurityNotificationSettings (métodos del manager, mutaciones GraphQL, espejo del schema) en lugar de parchearlos - el mismo precedente que el retiro anterior de grantVerification/removeVerification, ya que ya existía un equivalente real y conectado a la UI que funcionaba correctamente. Se encontró un bug más serio al rastrear al único llamador real del par muerto: el código real de envío de alertas (sendSecurityNotification, usado por cada llamada a createSecurityAlert) evaluaba la configuración falsa y fija del stub muerto, no las preferencias reales de getSecurityNotificationPrefs — es decir, desactivar tipos de notificación en la UI nunca suprimió nada en realidad, para ningún usuario, nunca. Se corrigió reconectando sendSecurityNotification para verificar la preferencia real por tipo (vía un nuevo mapa ALERT_TYPE_TO_NOTIFICATION_PREF) antes de enviar; los tipos de alerta sin una preferencia correspondiente (phone_change, eventos de API key) no tienen interruptor que verificar y siempre se envían, y el envío por SMS ya no depende de la bandera sms del stub antiguo (que siempre era false, es decir que nunca se había enviado ningún SMS de seguridad) — ahora se envía siempre que el usuario tenga un teléfono verificado.
• getDeviceStats fabrica su respuesta. Devuelve números fijos (totalDevices: 3, activeDevices: 2, cadenas de ubicación falsas) sin importar los dispositivos reales del usuario — no es solo "sin UI" (ver abajo), el propio backend nunca consulta datos reales de dispositivos. Archivo: managers/user-managers/sessions-devices.manager.js. Impacto: Medio — cualquier widget de "tus dispositivos" en una página de seguridad construido contra esto mostraría datos falsos desde el primer día. Corregido: ahora deriva cada número del historial real de user_session del usuario mediante un nuevo UserSessionAccessService.getAllForStats. Los dispositivos se agrupan por la tupla deviceType/deviceName/browser/os (no existe una columna dedicada de id de dispositivo); totalDevices/activeDevices/deviceTypes/platforms/browsers provienen de esa agrupación, locations de la geolocalización real de las sesiones, y suspiciousActivity.newDevices/newLocations de comparar la ventana solicitada contra el historial de sesiones del usuario anterior a ella — un dispositivo/ubicación sin sesión previa se considera "nuevo". failedLogins se reporta honestamente como 0 en lugar de un número fabricado, ya que (como ya se documentaba en getLoginHistory) todavía no existe un registro de intentos de inicio de sesión — solo los inicios de sesión exitosos crean una fila de sesión. También se corrigió el resolver (user-sessions.resolver.js): descartaba en silencio el propio argumento timeframe del schema y pasaba context en la posición del parámetro options del manager, por lo que el context real del manager siempre era {} — la misma clase de bug de desplazamiento de argumentos documentada más abajo para userStats. Ninguna página del frontend consume todavía este campo (getDeviceStats(timeframe: String): JSON! no tiene llamadores en frontend-nextjs/frontend-admin), así que no se construyó UI en este pase — este ítem trataba específicamente sobre la fabricación en el backend.
• reviewVerificationRequest (una mutation expuesta en el esquema) es un stub fijo que opera sobre el usuario equivocado. Nunca busca la solicitud real; usa mockRequest = { userId: 'user_123', ... }, así que aprobar/rechazar cualquier requestId real en realidad opera sobre un user_123 inexistente. Existe una alternativa que sí funciona para el panel de administración real (adminVerifyUser/adminRejectVerificationRequest), así que esta mutation específica es redundante-pero-rota en vez de ser el único camino. Archivo: managers/user-managers/verification-badges.manager.js. Impacto: Medio (expuesta en el esquema, se comportaría mal en silencio para cualquier invocador). Corregido: se retiró por completo (schema, resolver, método del manager) en lugar de parchearse - resultó tener la misma causa raíz que las ya retiradas grantVerification/removeVerification: estaba protegida solo por context.user.isAdmin, que nunca puede ser verdadero en esta ruta orientada al cliente web (context.admin solo se popula en /admin/graphql), así que estaba doblemente rota (inalcanzable y operando sobre un usuario simulado aunque fuera alcanzable). adminVerifyUser/adminRejectVerificationRequest ya cubren el camino real y funcional de revisión de administrador. Al investigar esto, se encontró y corrigió un segundo bug, más urgente, en el mismo archivo: verificationRequest(requestId) — la query que un usuario normal necesita para consultar el estado de su propia solicitud enviada — también estaba permanentemente rota, ya que su getVerificationRequestById de respaldo era un stub fijo que siempre devolvía null. A diferencia de la mutation, esta no tenía un reemplazo funcional y no existe una tabla de solicitudes separada (una "solicitud" es simplemente el estado pendiente en la propia fila de User, igual que ya usa el getVerificationRequest(userId) que sí funciona) — se corrigió buscando al usuario directamente, ya que requestId y userId son el mismo id en este esquema.
• reportConversation nunca persiste el reporte. Construye un objeto de reporte con // TODO: Create report in content_reports table / Save to database and notify moderators y simplemente lo devuelve — los moderadores nunca lo ven. Esta es una mutation en vivo, expuesta en el esquema, de confianza y seguridad que parece tener éxito pero no hace nada. Archivo: managers/message-managers/conversation.manager.js. Impacto: Alto. Corregido: ahora pasa por el mismo pipeline real de content_report que ya usan los reportes de posts/comentarios/mensajes/usuarios (managers/admin-managers/content-report.manager.js#createReport → ContentReportAccessService) — persistencia real, la verificación de duplicados ya existente ("ya reportaste esto") y la alerta administrativa para reportes urgentes ya existente, todo gratis. Se necesitaron dos extensiones del schema, ya que content_report.reported_user_id/content_type son columnas reales, no-nulas y respaldadas por un enum que antes no contemplaban conversaciones: tanto el enum ContentType como el tipo ReportsByType de las estadísticas de admin ganaron un valor/campo conversation (reflejado en schema.web.graphqls/schema.admin.graphqls y en la lista permitida de content-report.validator.js), de modo que un reporte de conversación persistido realmente pueda listarse/filtrarse/contarse a través de la UI de reportes de admin ya existente, en lugar de quedar en la tabla sin que nadie lo vea. Dado que reported_user_id es singular pero una conversación puede tener varios participantes, el reporte apunta al otro participante en una conversación directa (1:1), o al creador del grupo en caso contrario. La razón 'inappropriate', específica de esta mutation (parte de su contrato de entrada ya existente), no tiene equivalente en el enum compartido ReportReason - en lugar de ampliar ese enum (y cada consumidor de ReportsByReason/codegen que dependa de él) por el sinónimo de un solo tipo de contenido, se mapea al bucket 'other' ya existente al persistir, mientras que la respuesta de la mutation sigue devolviendo la redacción original de quien la invocó.
• refundMessagePurchase no tiene ninguna verificación de propiedad/admin. Cualquier usuario autenticado puede pasar un purchaseId arbitrario y el manager reembolsa monedas del vendedor de vuelta al comprador sin ninguna verificación de que quien llama es el comprador, el vendedor, o un administrador (// TODO: Add admin check está literalmente en el resolver). Actualmente inalcanzable desde ambos frontends (ver abajo), pero es una mutation en vivo, invocable, y financieramente sensible hoy. Archivo: graphql/resolvers/message-purchase.resolver.js, managers/message-managers/message-purchase.manager.js. Impacto: Alto. Corregido: la "verificación de admin" que pedía el TODO nunca podría haber funcionado realmente en esta ruta - context.admin solo se popula en /admin/graphql, y esta mutation vive en el schema de cliente - exactamente el mismo bug ya corregido una vez para las compras de publicaciones exclusivas (refundPostPurchase/adminRefundPostPurchase), así que se aplicó aquí el mismo remedio de dos caminos: refundMessagePurchase ahora está limitada al autoservicio del comprador con una ventana de reembolso de 24h (message_purchase.not_owner/refund_window_expired), y un nuevo par adminRefundMessagePurchase/adminGetMessagePurchases en el schema de admin (protegido por una verificación real del permiso MODERATE_CONTENT) le da a los moderadores un camino sin límite de tiempo más un listado sobre el cual actuar. También se corrigió un bug real y separado encontrado al tocar este archivo: cada clave de error message_purchase.* referenciada por este manager (not_found, already_refunded, message_not_paid, cannot_purchase_own_message, invalid_amount, already_purchased, access_denied) había estado cayendo en silencio a la cadena de la clave cruda, ya que no existía ninguna traducción errors.message_purchase en absoluto - se agregó texto real en inglés y español para el conjunto completo. Implementado de punta a punta: la página ya existente del panel de admin /moderation/refunds (construida para reembolsos de compras de publicaciones) ahora tiene una pestaña de compras de Publicaciones/Mensajes, respaldada por un nuevo campo MessagePurchase.seller agregado para paridad de visualización comprador/vendedor con PostPurchase.
• userStats/getUserStats nunca devuelve los campos relativos al espectador que declara el esquema. UserStats.isFollowing/isFollower/isCloseFriend/isBlocked/isBlockedBy/hasPendingRequest siempre son null: el resolver llama al manager con (userId, viewerId, context) pero el wrapper delegador solo acepta (userId, context), así que viewerId sobrescribe a context y se descarta en silencio — lo que significa que el contexto real de la petición (idioma, etc.) también se pierde para los mensajes de error de esta llamada. Archivo: managers/user-managers/index.js (wrapper) / managers/user-managers/statistics.manager.js (nunca establece los campos de todos modos). Impacto: Medio-Alto — cualquier vista de "estadísticas" de perfil que dependa del estado de seguir/bloquear/close-friend de esta query siempre está equivocada. Corregido: el wrapper ahora acepta (userId, viewerId, context) correspondiendo con la llamada real del resolver, y getUserStats reutiliza el ya-correcto getRelationshipStatus(viewerId, userId, context) (el mismo método que respalda RelationshipStatus) para poblar los seis campos de verdad, en lugar de dejarlos sin establecer. Semántica: isFollowing/isFollower son relativos al espectador ("¿el espectador sigue a este usuario?" / "¿este usuario sigue de vuelta al espectador?"), y los campos permanecen en null (su significado real y nulificable en el esquema de "no aplica") para una petición anónima o al ver tus propias estadísticas, en lugar de fabricar false. Se actualizó el único otro llamador interno de este método del manager (getAccountAnalytics, auto-análisis sin un espectador separado) para pasar null explícitamente, de modo que siga obteniendo el resultado correcto de "no aplica" en lugar de tratar accidentalmente su propio objeto context como un id de espectador verdadero.
• canTagUser/canMentionUser se saltan por completo las verificaciones de bloqueo y privacidad. Ambos protegen el flujo real de creación de etiquetas/menciones pero solo verifican "el usuario existe / la cuenta está activa" — los pasos de "verificar si quien etiqueta está bloqueado" y "verificar configuración de privacidad" son // TODO y nunca se ejecutan. Archivos: managers/post-managers/content-tag.manager.js, managers/post-managers/post-mention.manager.js. Impacto: Medio — un usuario puede bloquear a alguien y esa persona todavía puede etiquetarlo/mencionarlo en publicaciones. Corregido: resultó que ambos TODO pedían algo que ya existía y ya era correcto - privacy-settings.manager.js#canPerformAction tiene casos reales y funcionales para 'tag_user'/'mention_user' (verificación de bloqueo + la configuración de privacidad who_can_tag/who_can_mention), ya usados en otro lugar (p. ej. la privacidad de invitaciones a grupos en conversation.manager.js), simplemente nunca se había conectado a estos dos stubs. Ambos ahora delegan directamente a él - no se necesitó lógica nueva, solo conectar una primitiva ya existente y ya probada.
• La eliminación de cuenta nunca se propaga a los datos relacionados. deleteAccount/deleteAccountImmediately anonimizan la fila User pero dejan publicaciones, comentarios, mensajes, medios, y relaciones de seguimiento completamente intactos y atribuibles (// TODO: Delete or anonymize related data). Archivo: managers/user-managers/account-management.manager.js. Impacto: Alto — un hueco real de cumplimiento RGPD, no solo algo deseable. Corregido: ambos métodos ahora llaman a un nuevo _cascadeDeleteUserData(userId) justo después de anonimizar la fila User. Los posts, comentarios y mensajes (todos modelos paranoid: true) se eliminan de forma suave - se establece deleted_at, la fila en sí se conserva, siguiendo el mismo enfoque de "anonimizar/ocultar en vez de borrar por completo" ya usado para la propia fila User (conservada por integridad referencial) - mediante tres nuevos métodos de acceso masivos (post.access-service.js#deleteAllByUser, message.access-service.js#deleteAllBySender, y el ya existente pero nunca usado comment.access-service.js#deleteByUser). Las filas puras de relación/metadatos sin valor de auditoría independiente - me gusta/reacciones, relaciones de seguimiento (en ambas direcciones), membresía de conversaciones, publicaciones guardadas y notificaciones - se eliminan por completo mediante métodos masivos nuevos/extendidos en sus respectivos servicios de acceso. Toda la cascada se ejecuta dentro de una única sequelize.transaction() para que un fallo a mitad de camino revierta limpiamente en lugar de dejar unas tablas limpias y otras no (esta es una transacción separada de la propia actualización de anonimización de la fila User, ya que user.access-service.js#update se usa en demasiados lugares como para retroadaptarle soporte de transacciones de forma segura solo para este llamador).
• La desactivación de cuenta no oculta el contenido, y las acciones de contacto legado no notifican ni registran auditoría. Desactivar una cuenta deja sus publicaciones/comentarios completamente visibles (// TODO: Hide user content without deleting); addLegacyContact/removeLegacyContact nunca envían la notificación requerida ni registran la acción del admin. Archivos: managers/user-managers/account-management.manager.js, managers/user-managers/memorialized-accounts.manager.js. Impacto: Medio. Corregido: la visibilidad del contenido ahora se verifica en vivo a partir de User.accountStatus en el momento de la consulta - el filtro canView() del feed, los joins de creador de getTrendingPosts()/getByType() (ambos ya tenían un join con isPrivate: false) y de getByHashtag() (que antes no tenía ningún filtro de visibilidad de creador) ahora también excluyen accountStatus: 'deactivated', y profile.manager.js#getProfile ahora rechaza ver el perfil desactivado de otro usuario (los propietarios sí pueden ver el suyo propio). Como todo esto es en tiempo de consulta, el // TODO: Restore user content visibility correspondiente de reactivateAccount no necesitó ningún código en absoluto - al volver a poner accountStatus fuera de 'deactivated' ya se hace todo visible de nuevo, así que ese TODO se convirtió en un comentario explicativo en lugar de lógica nueva. addLegacyContact/removeLegacyContact ahora envían una notificación real al contacto legado (best-effort, siguiendo la forma ya establecida de notificationAccessService.create en el código base) y registran auditoría vía analyticsService.trackAdminAction a través de un nuevo helper _auditAction (mismo patrón que platform-wallet.manager.js/restrictions-limits.manager.js). Al conectar esto, se encontró que todo el namespace de traducción memorialized.* de errores/éxitos faltaba tanto en en.json como en es.json - cada mensaje de memorialized-accounts.manager.js (solicitudes de conmemoración, revisión, contactos legados) había estado cayendo en silencio a la cadena de la clave cruda; se agregó el conjunto completo de texto real en inglés y español.
• La supresión de notificaciones en horas de silencio usa la hora local del servidor, no la zona horaria propia del usuario. Archivo: managers/user-managers/notification-settings.manager.js#isInQuietHours. Impacto: Bajo-Medio. Corregido: isInQuietHours ahora toma la User.timezone del usuario (una cadena IANA, p. ej. America/New_York - una columna que ya existía pero que esta verificación nunca leía) y evalúa la ventana de horas de silencio en esa zona horaria mediante un nuevo helper getCurrentTimeInTimezone (Intl.DateTimeFormat con la opción timeZone - sin necesidad de una dependencia nueva), recurriendo a la hora local del servidor solo cuando el usuario no tiene zona horaria configurada o es una cadena no reconocida. shouldReceiveNotification (el único llamador real) ahora obtiene la fila del usuario y pasa user.timezone.
• Las estadísticas de búsqueda / el reporte de resultados de búsqueda son no-ops silenciosos. getSearchStats siempre devuelve { totalSearches: 0, recentSearches: [] }; reportSearchResult siempre devuelve { success: true } sin persistir nada. Ambos están expuestos en GraphQL pero no tienen ningún invocador en el frontend hoy. Impacto: Bajo. Corregido: resultó que getSearchStats ya tenía una fuente de datos real y funcional justo al lado - la función "Búsquedas recientes" (search-history.manager.js, respaldada por la tabla real user_search_history) ya registra cada búsqueda vía recordSearch, simplemente nunca alimentaba a getSearchStats. Ahora devuelve un totalSearches real (nuevo UserSearchHistoryAccessService#countSince, acotado por el argumento timeframe de la query, 30 días por defecto) y recentSearches reales. También se corrigió el mismo bug de desplazamiento de argumentos encontrado repetidamente en este pase: el resolver llamaba al manager como (userId, {timeframe}, context) pero el wrapper delegador solo aceptaba (userId, context). reportSearchResult ahora persiste a través del mismo pipeline real de content_report que usa reportConversation (un resultado de búsqueda ES un usuario, así que contentType: 'user'/contentId: resultId - con verificación de duplicados y alerta administrativa para reportes urgentes incluidas, con validación real de la razón en lugar del no-op anterior que aceptaba cualquier cosa).
• POST /upload sustituye en silencio una foto de stock pública aleatoria cuando S3 falla, y aun así devuelve HTTP 200. El manejador de subida de api/server.js: ante cualquier error de S3 (credenciales incorrectas, falla de red, o S3 deshabilitado) el bloque catch responde con { url: 'https://picsum.photos/400/400?random=...' } — una foto aleatoria sin relación de un servicio externo — en vez de un error, incluso en la ruta de adjuntos multimedia messages/user-.... Un cliente no tiene forma de distinguir una subida real de una sustitución silenciosa. Impacto: Alto — un problema silencioso de integridad de datos en una ruta de la que los clientes reales dependen para adjuntos de mensajes/multimedia. Corregido: la lógica de decisión se extrajo a un módulo puro y sin dependencia de Express (api/upload-response.util.js - server.js en sí arranca Apollo/conexiones a la BD al hacer require y no se puede probar unitariamente de forma directa) con tres desenlaces reales en vez de uno falso: una subida realmente exitosa devuelve la URL real de S3; que el almacenamiento esté deshabilitado intencionalmente (DISABLE_S3, dev/test) ahora devuelve la URL simulada ya determinística que el propio servicio de almacenamiento ya generaba, en vez de llamar a una API externa de fotos de stock en cada subida; y cualquier fallo real (credenciales incorrectas, falla de red, o el almacenamiento devolviendo una forma inesperada estando habilitado) ahora devuelve un 502 real con el mensaje de error real, nunca una foto sustituida con un 200 falso. Se verificó que el frontend no necesitaba ningún cambio: los dos puntos de subida de ChatView.tsx ya hacían if (!res.ok) throw new Error('Upload failed') - ya estaban preparados para manejar un fallo real correctamente, simplemente nunca habían recibido uno hasta ahora.
• payment-customer.manager.js tiene varios métodos financieros fabricados, y deleteCustomer nunca elimina al cliente en Stripe. getCustomerStats siempre devuelve ceros (// TODO: Get actual stats from payment provider and database), getBalance solo repite el campo local de la BD (// TODO: Get actual balance from payment provider), syncWithProvider es un no-op, y deleteCustomer solo elimina la fila local (// TODO: Delete customer from payment provider (Stripe)), dejando un cliente de Stripe huérfano para siempre. Todavía no está expuesto vía ningún resolver de GraphQL, pero el manager es infraestructura interna en vivo (usada por payment-method.manager.js/coin-purchase.manager.js vía getOrCreateCustomer). Impacto: Medio — reportará mal en silencio en el momento en que cualquiera de estos métodos se conecte a un resolver. Corregido: deleteCustomer ahora elimina de verdad al cliente en Stripe (services/stripe#customersStripe.deleteCustomer) antes de borrar la fila local, trata el código de error resource_missing de Stripe como "ya no existe" (un éxito benigno, no un fallo), y aborta sin tocar la fila local cuando Stripe falla por cualquier otro motivo - se acabaron tanto los clientes huérfanos en Stripe como las filas locales huérfanas. syncWithProvider ahora consulta de verdad al cliente vivo en Stripe (customersStripe.getCustomer) y reconcilia el email local si divergió, degradándose con gracia (devuelve el registro local sin cambios) si Stripe no responde. getCustomerStats ahora calcula números reales a partir del propio libro de transacciones de la app vía PaymentTransactionAccessService (extendido con una nueva consulta agregada getStats(userId) - conteos de transacciones totales/completadas/fallidas, monto completado, primera/última fecha completada) y conteos reales de métodos de pago vía PaymentMethodAccessService#getByUser; active_subscriptions se deja honestamente en 0 porque todavía no existe una fuente de datos alcanzable de "suscripciones activas por cliente de pago" (las suscripciones a creadores se rastrean por par suscriptor/creador, no por PaymentCustomer). getBalance se revisó y se dejó tal cual: repetir el campo local de la BD es correcto hoy, ya que este saldo de crédito emitido por la app no tiene un equivalente del lado de Stripe con el cual sincronizarse. Se añadieron las claves de traducción faltantes errors.payment_customer.* (not_found/create_failed/provider_delete_failed) y errors.validation.{customer_id_required,provider_customer_id_required} a en.json/es.json - cada ruta de error de este manager caía en silencio a la clave cruda como texto. No se construyó UI de frontend en este pase: este manager sigue sin exposición vía resolver de GraphQL, exactamente igual que antes - la corrección se limita a hacer confiables a sus llamadores internos existentes (payment-method.manager.js, coin-purchase.manager.js). También se actualizó tests/unit-test/payments-subscriptions.unit.test.js (la suite de este repo deliberadamente diseñada para ejercitar managers reales, que había fijado a propósito el comportamiento roto anterior según su propio comentario de cabecera) para verificar el comportamiento nuevo y correcto en vez de los bugs anteriores.
• Varios managers agregados recientemente lanzan cadenas de error fijas y sin traducir en vez de usar el servicio de i18n del backend — mezclando idiomas según el manager. note.manager.js, story-highlight.manager.js, y subscription-bundle.manager.js todos hacen throw new Error('...') con texto en español fijo (sin claves correspondientes en translations/en.json); message-translation.manager.js hace lo contrario con texto en inglés fijo. Todos los demás managers del código pasan por t.error('key', context) contra translations/{en,es}.json. Resultado: un usuario en idioma inglés recibe texto de error en español crudo de Notas/Story Highlights/Paquetes de suscripción, y viceversa para errores de traducción de mensajes. Impacto: Medio — una regresión real de i18n en funcionalidades recién lanzadas, exactamente la clase de hueco que el CLAUDE.md de este proyecto marca como "no terminado." Corregido: los cuatro managers ahora pasan por t.error('key', context) como cualquier otro manager. Se añadieron los nuevos namespaces errors.note.* (empty/too_long), errors.story_highlight.* (title_required/title_too_long/not_found/not_owner) y errors.subscription_bundle.* (name_required/not_found/not_owner/has_active_buyers/not_available/cannot_purchase_own) a en.json/es.json; la comprobación "no eres participante" de message-translation.manager.js#setSetting ahora reutiliza la clave ya existente errors.conversation.not_participant (mismo texto en inglés, ahora realmente traducible) en vez de un literal fijo. Propagar context requirió añadir un parámetro context a varios métodos de manager que antes no lo aceptaban (note.manager.js#createNote, story-highlight.manager.js#createHighlight/updateHighlight/deleteHighlight, subscription-bundle.manager.js#createBundle/updateBundle/deleteBundle, message-translation.manager.js#setSetting) y actualizar sus resolvers (note.resolver.js, story-highlight.resolver.js, subscription-bundle.resolver.js, message-translation.resolver.js) para pasarlo - deleteHighlight/deleteBundle ya recibían un argumento context desde sus resolvers que el método del manager descartaba en silencio (una instancia más de la clase de bug de desplazamiento de argumentos recurrente en este pase). Los mensajes con límite de caracteres ({max} en títulos de notas/highlights) ahora usan la misma convención de interpolación t.error(key, context).replace('{max}', N) ya establecida por validators/password-policy.validator.js. Se actualizaron las aserciones de los tests unitarios existentes en untested-managers.unit.test.js, payments-subscriptions.unit.test.js, message-translation-manager.unit.test.js y resolvers/message-translation.resolver.test.js en consecuencia - el mock global de Jest para translation.service de este repo (tests/setup.js) devuelve la clave cruda sin modificar, así que los tests de todos los demás managers ya afirman sobre la clave con puntos en sí (p. ej. 'story_highlight.not_owner') en vez de prosa traducida, y estos tests ahora siguen la misma convención.
• Elementos menores de backend que vale la pena revisar juntos: deleteFeedback (user-feedback.manager.js) está documentado como "propietario o admin" pero no tiene ningún bypass real de admin (// TODO: Check if user is admin) — solo el propietario puede eliminar su propio feedback hoy; el comentario de documentación de la clase de payment-method.manager.js anuncia detectFraudulentCard/detectSuspiciousActivity/getMostUsedMethod/getFailureRate/getUsageHistory/bulkDeleteMethods/exportPaymentMethods, ninguno de los cuales existe realmente en la clase. Impacto: Bajo individualmente. Corregido: deleteFeedback ahora tiene un bypass de admin real, reutilizando exactamente el mismo primitivo de permisos que graphql/resolvers/admin/user-feedback-admin.resolver.js ya usa para el resto de mutaciones de triage de feedback - adminUserManager.hasPermission(admin.adminId, 'MANAGE_FEEDBACK') contra context.admin - en vez de la comprobación heredada al estilo user.accountType === 'admin' usada (y ella misma marcada "TODO: Implement proper admin role checking") en otras partes de este código. deleteFeedback no tenía ninguna exposición GraphQL antes de este pase (igual que payment-customer.manager.js antes de la corrección anterior), así que el bypass era inalcanzable e imposible de probar de punta a punta; se conectó con una nueva mutación deleteMyFeedback solo para el propietario (siguiendo el mismo patrón que upvoteFeedback/downvoteFeedback) y una nueva mutación adminDeleteFeedback (siguiendo el mismo patrón que adminUpdateFeedbackStatus/adminRespondToFeedback, protegida por el mismo helper requireFeedbackPermission), ambas reflejadas en schema.web.graphqls/schema.admin.graphqls más nuevos archivos de operación .graphql bajo packages/graphql/operations/{Web,Admin} y con apollo-web/apollo-admin recompilados. Se extendió la página existente de triage de Feedback en el panel de administración (apps/frontend-admin/src/app/feedback/FeedbackContent.tsx) con una acción de eliminar + modal de confirmación, siguiendo el mismo patrón de eliminar-con-confirmación ya usado en la página de lista de bloqueo de moderación. Al tocar este manager, se encontró que todo el namespace de traducción de errores user_feedback.* (además de validation.feedback_id_required/admin_id_required/query_required) faltaba en en.json/es.json - cada ruta de error en user-feedback.manager.js caía en silencio a la clave cruda como texto; se añadió el conjunto completo. Por separado, se recortó el comentario de documentación de la clase de payment-method.manager.js a los ~15 métodos que realmente existen en la clase, eliminando los ~25 ficticios (detectFraudulentCard, bulkDeleteMethods, etc.) que podrían inducir a un futuro lector a pensar que podía llamarlos - no se construyó ningún método nuevo, ya que ninguna de esas capacidades fue solicitada ni es necesaria para ningún llamador real hoy.

Backend listo, sin interfaz de frontend

Un cruce de cada campo Query/Mutation en el esquema web compartido contra el uso real en apps/frontend-nextjs/src reveló un conjunto grande de funcionalidades con un backend completo y real y cero UI. Agrupadas por área:

• La llamada de voz 1:1 es unidireccional — sin ninguna UI de llamada entrante. AnswerCall/DeclineCall/JoinCall/LeaveCall y la suscripción CallIncoming tienen documentos de operación listos, y ChatView.tsx incluso importa CallIncomingDocument — pero nunca se suscribe realmente a ella. Solo el lado de quien llama (StartCall/EndCall) funciona; quien recibe no tiene ninguna UI de timbrar/aceptar/rechazar. Impacto: Alto. Corregido: al investigar esto apareció un segundo bug, más grande, detrás - VoiceCallModal.tsx (la UI "funcional" del lado de quien llama) nunca se unía realmente a la sala de LiveKit que creaba el backend; abría un RTCPeerConnection crudo solo con servidores STUN, registraba en consola el token/wsUrl/roomName reales que LiveKit necesita, y nunca los usaba, así que nunca se intercambiaba audio real ni siquiera en una llamada saliente. Se reescribió para usar livekit-client (ya es una dependencia, ya probada y funcionando para transmisiones en vivo en LiveRoomPage.tsx) en ambas direcciones: conectarse a la sala, publicar una pista de audio local, suscribirse a la pista remota, silenciar de verdad vía localParticipant.setMicrophoneEnabled, y reportar la calidad de conexión de verdad vía RoomEvent.ConnectionQualityChanged (antes una etiqueta fija "Excellent"/solo en español sin ningún t()). Se añadió un nuevo IncomingCallContext.tsx de alcance global (montado una sola vez en Providers.tsx, el mismo patrón que el ya existente NotificationsRealtimeContext.tsx) que se suscribe a callIncoming para el usuario actual sin importar en qué página esté, muestra un banner de timbrado con el nombre/avatar de quien llama, y conecta AnswerCall/DeclineCall - responder abre el mismo VoiceCallModal (ahora real). Se eliminó el import no usado de CallIncomingDocument en ChatView.tsx ahora que la suscripción vive en el provider global. Se añadió un nuevo namespace de i18n calls.* a en.json/es.json (el modal viejo tenía varias cadenas fijas solo en español, sin ninguna traducción, sin importar el idioma). Tests nuevos: VoiceCallModal.test.tsx (conexión/publicación en LiveKit, fallo de permiso de micrófono, silenciar, mapeo de calidad de conexión, finalizar llamada) e IncomingCallContext.test.tsx (banner de timbrado, fallback de nombre, ramas de responder/rechazar), ambos con livekit-client simulado. JoinCall/LeaveCall (unirse/salir de una llamada grupal) siguen sin conectarse a ninguna UI - las llamadas grupales no tienen ningún punto de entrada en el frontend hoy, lo cual en realidad es el hueco separado de "gestión de conversaciones" listado más abajo, no parte de esta corrección de llamadas 1:1.
• El sistema de "solicitud para hablar" de salas de audio en vivo (estilo Clubhouse) no tiene ninguna UI. requestToSpeak/approveSpeakerRequest/denySpeakerRequest/cancelSpeakerRequest/promoteToSpeaker/demoteToViewer/joinAsViewer/pendingSpeakerRequests/mySpeakerRequests están todos completos en el backend (call-managers/speaker-request.manager.js) con documentos de operación listos; ningún componente hace referencia a ninguno. Impacto: Medio-Alto. Abordado parcialmente - se encontraron y corrigieron bugs reales del backend, la UI deliberadamente no se construyó en este pase (ver abajo). Al investigar se descubrió que este backend no estaba realmente "completo" como se afirmaba - tres bugs reales significaban que la funcionalidad no podría haber funcionado ni con una UI delante. (1) requestToSpeak/approveSpeakerRequest/denySpeakerRequest/getPendingRequestsForCall verificaban participant.status === 'JOINED' para significar "es un speaker", pero call.manager.js#joinAsViewer también pone status: 'JOINED' en una fila de espectador normal (la distinción real speaker/espectador es role: CALLER/RECEIVER vs PARTICIPANT, según la propia definición de getCallParticipants en el mismo archivo) - así que la propia llamada requestToSpeak de cualquier espectador real fallaba de inmediato con "You are already a speaker", y cualquier participante (incluido el propio solicitante) podía aprobar/rechazar/ver cualquier solicitud, no solo el host/los speakers. (2) approveSpeakerRequest llamaba a callManager.promoteToSpeaker(request.callId, request.userId, context) - un bug de desplazamiento de argumentos (la firma real es (callId, userId, promotedBy, context)) - así que la propia comprobación interna de la promoción call.callerId !== promotedBy comparaba el id real de quien llama contra un objeto de contexto y siempre lanzaba, tragado en silencio por un bloque catch: una solicitud "aprobada" nunca promovía realmente a nadie en la sala real de LiveKit. (3) promoteToSpeaker/demoteToViewer solo permitían al creador original de la llamada, contradiciendo la propia regla que approveSpeakerRequest declara ("Only the call host or speakers can approve requests") - corregido para permitir también a un speaker existente (role CALLER/RECEIVER), en consistencia con el resto del modelo de autorización. Los tres corregidos en call.manager.js/speaker-request.manager.js, con tests nuevos que cubren la autorización real basada en roles y la corrección del argumento de promoción. La UI NO se construyó en este pase: requestToSpeak solo es alcanzable para alguien que se unió a una llamada vía joinAsViewer (el único camino que crea una fila con role: 'PARTICIPANT') - y joinAsViewer en sí no tiene ningún llamador en ningún lugar de este código, porque no existe ningún concepto de "sala de audio" en el frontend todavía (sin flujo de creación/descubrimiento de salas, sin forma de unirse a una llamada en curso de la que no fuiste uno de los participantes originales de startCall - el único punto de entrada de llamadas de ChatView.tsx es una llamada 1:1 con receiverId). Publicar hoy un botón "Levantar la mano" siempre lanzaría "You are already a speaker" para cualquier usuario real, ya que nadie puede alcanzar el estado de espectador - sería una UI conectada a una mutación real pero de todas formas inalcanzable de punta a punta, la misma clase de problema que este pase sigue encontrando y se niega a maquillar. Construir el prerrequisito real (UI de creación/descubrimiento de salas/unirse como espectador) es una funcionalidad materialmente más grande y separada, más cercana en alcance a la sección "Funcionalidades de consumidor que no existen hoy" que a conectar campos de backend ya alcanzables.
• Mensajes de DM pagos/bloqueados: el lado de "desbloquear" funciona, el lado de "bloquear" no existe en el compositor. purchaseMessage está conectado en ChatView.tsx, pero el compositor de mensajes fija cada mensaje saliente a isLocked: false, unlockPrice: null (useChatMessages.ts) — así que ningún mensaje puede llegar a ser comprable realmente. LockMessage, GetMyMessagePurchases, HasMessageAccess, GetMyCreatorEarnings están todos definidos y sin usar. Impacto: Alto — toda una funcionalidad de monetización de DM pagos es inalcanzable para los creadores. Investigado - este ítem ya estaba desactualizado cuando se escribió (la propia introducción del roadmap advierte que algunas entradas terminan estando ya corregidas). Los campos isLocked/unlockPrice que nombra son campos GraphQL de Message muertos, nunca respaldados por datos (no existe ninguna columna correspondiente - las columnas reales del modelo son isPaid/coinPrice, expuestas como Message.isPaid/Message.price) - el código de useChatMessages.ts citado es solo un relleno de forma de caché de Apollo para campos que un payload de la suscripción messageAdded no selecciona, no el camino real de envío, y ya pone por defecto correctamente los campos reales (isPaid: false, price: null) también, sobrescritos por el payload real de la suscripción vía un spread posterior. La UI real para "bloquear un mensaje" ya existe y está completamente conectada: el flujo "Fijar precio" de ChatView.tsx/MessageInputArea.tsx (showPaidMediaModal, pendingPaidPrice, cuatro puntos de entrada distintos en los menús de adjuntar/acciones rápidas) envía isPaid/price directamente en el MessageCreateInput de sendMessage, validado y persistido en el servidor (message.resolver.js), y protegido en lectura vía el resolver del campo Message.mediaUrls que llama a messagePurchaseManager.verifyAccess - no tiene relación con la mutación separada LockMessage que el roadmap marcó como sin usar (esa existe para bloquear un mensaje ya enviado después del hecho, un caso de uso distinto y legítimamente todavía sin usar). Al verificar esto, se encontró un bug real y separado en ese camino lockMessage sin usar, que vale la pena corregir de todos modos por ser un agujero de seguridad activo: el propio comentario de documentación del resolver afirma "Only message sender can lock messages", pero nada lo aplicaba - cualquier usuario autenticado podía llamar a lockMessage sobre cualquier mensaje, incluido uno que no envió, volviendo pago retroactivamente el mensaje de otra persona detrás de un precio arbitrario. Corregido pasando el id de quien llama y verificando message.senderId, reutilizando la clave errors.message.not_sender ya existente (no se necesitó ninguna traducción nueva). myMessagePurchases/hasMessageAccess/myCreatorEarnings siguen sin usarse por ninguna página del frontend - se rastrean junto con el hueco más amplio de dashboard financiero de abajo, en vez de duplicarlo aquí.
• La eliminación de comentarios está completamente ausente de la app web. deleteComment(commentId, actAsUserId): Boolean! tiene un resolver/manager real pero cero referencias en ningún lugar de apps/frontend-nextjs, apps/frontend-admin, o los paquetes de operaciones — los usuarios aparentemente no pueden eliminar sus propios comentarios desde la UI web. Impacto: Alto para una app social. Corregido: se añadió una acción "Eliminar" junto a "Responder" tanto en comentarios de nivel superior como en respuestas dentro de PostModal.tsx (la lista de comentarios compartida que usa el modal de post, la vista solo-comentarios, y cualquier punto de entrada que lo renderiza), visible cuando quien llama es el propio autor del comentario o el dueño del post - reflejando la autorización real ya aplicada en el servidor en post-comment.manager.js#deleteComment. Confirmar pasa por un diálogo de confirmación compartido Modal (reutilizado de @/components/ui/Modal, el mismo primitivo que PostOptionsMenu.tsx ya usa para eliminar posts) antes de llamar a la nueva mutación DeleteCommentInline y volver a consultar la lista de comentarios. Se añadió un nuevo archivo de operación .graphql (Web/Posts/DeleteCommentInline.graphql) y se recompiló apollo-web. Se añadieron nuevas claves de i18n post.delete_comment* a en.json/es.json.
• La gestión de conversaciones está en gran parte sin construir en la UI de chat: leaveConversation, archiveConversation/unarchiveConversation, pinConversation/unpinConversation, unblockConversation, clearConversationHistory, updateParticipantRole, transferAdmin, además de scheduleMessage/cancelScheduledMessage/editScheduledMessage (mensajes programados/autodestructibles) — todos tienen documentos de operación reales, ninguno referenciado en ningún componente. Impacto: Medio — archivar/fijar/salir/roles/programación son expectativas comunes de app de chat, listas en el backend y ausentes. Corregido: las nueve conectadas en ConversationDetailsPanel.tsx (el panel lateral compartido de detalles/ajustes del chat), reutilizando datos que la query GetConversation ya obtenía (isPinned/isArchived/isBlocked ya se seleccionaban en ConversationParticipant para el toggle de silenciar - solo nunca se leían para nada más). Se añadió: toggles de Fijar/Archivar junto al toggle de Silenciar ya existente; Bloquear ahora cambia a una acción real de Desbloquear una vez que me.isBlocked; una nueva acción destructiva "Borrar historial del chat" con su propio diálogo de confirmación; una acción "Salir del grupo" (solo conversaciones de grupo, oculta para el último administrador restante - reflejando la misma protección que leaveConversation ya aplica en el servidor); botones "Hacer administrador"/"Quitar como administrador" por miembro junto al control de quitar-miembro ya existente (visibles para los mismos administradores/creador de grupo con canManageMembers); una acción "Transferir propiedad" solo para el creador por cada administrador, con su propia confirmación; y un panel autocontenido de "Mensajes programados" (compositor de texto + <input type="datetime-local">, lista con Editar/Cancelar por elemento) construido alrededor de las operaciones ya existentes GetScheduledMessages/ScheduleMessage/CancelScheduledMessage/EditScheduledMessage, deliberadamente mantenido independiente del flujo de envío del compositor principal en vez de enhebrar un nuevo modo a través de la ya extensa superficie de props de MessageInputArea.tsx. Se añadieron nuevas claves de i18n messages.*/members.* a en.json/es.json.
• No hay verificación en vivo de disponibilidad de usuario/correo al registrarse, a pesar de que isUsernameAvailable/isEmailAvailable están completamente implementadas — OnboardingPage.tsx no tiene ninguna llamada de validación en tiempo real, así que un nombre de usuario ya tomado presumiblemente solo se descubre después de enviar. Lo mismo para las queries de validación en tiempo real más amplias validateUserData/validateProfileContent/validateFieldRealtime — ninguna se llama desde ningún formulario de edición de perfil. Impacto: Medio (pulido de UX de registro/edición de perfil, listo en el backend). Corregido — y la afirmación original del roadmap sobre dónde estaba el problema era incorrecta. El formulario de registro real es Login.tsx (OnboardingPage.tsx es un asistente posterior al registro sin campos de usuario/correo), y ya tenía una UI de validación en vivo con debounce completamente construida, conectada a validateUsername/validateEmail (vía ValidateUsernameInline/ValidateEmailInline) — con chips de sugerencias incluidos. Simplemente fallaba silenciosamente en cada llamada: el esquema de GraphQL declara ValidationResult { valid: Boolean!, message, suggestions }, pero managers/user-managers/index.js's validateUsername/validateEmail/validateFieldRealtime devolvían la otra forma ({available, message} de isUsernameAvailable/isEmailAvailable) directamente — el campo no-nulo valid nunca estaba presente, así que GraphQL fallaba en cada petición y la UI ya construida nunca funcionó. Corregido añadiendo métodos propios validateUsername/validateEmail en validation.manager.js que mapean {available} → {valid}, con la fachada en index.js reducida a una delegación simple (siguiendo la convención de manager/fachada de este código base). También se conectó la query de validación en tiempo real más amplia validateProfileContent — confirmada como genuinamente sin uso, tal como se afirmaba — al campo de biografía en EditProfilePage.tsx, y se añadió la misma verificación en vivo de validateUsername con debounce (con chips de sugerencias, replicando Login.tsx) al campo de nombre de usuario de esa página, ya que antes solo mostraba un error de nombre de usuario ya en uso después de un guardado fallido. Nuevos documentos de operación: ValidateFieldRealtimeInline.graphql, ValidateProfileContentInline.graphql. Nuevas pruebas en validation-manager.unit.test.js que cubren el mapeo {available}→{valid} para ambos campos.
• No hay panel de billetera de monedas / propinas / historial de compras. myTransactionStats, myPurchaseHistory, coinPurchaseStats, mySentTips, contentTips, contentTipTotal, recentTips están todos listos en el backend sin ningún documento de operación en ningún lugar. Enviar propinas funciona (TipModal.tsx); no hay ninguna vista de "mis propinas enviadas/recibidas" o "historial de compras". Impacto: Medio. Corregido — varios de los campos mencionados ya tenían vistas reales, los huecos reales eran más específicos. CoinTransactionsPage.tsx (una vista real de "historial de compras", en /coins/transactions) y TipsPage.tsx (una vista real de "propinas recibidas" con estadísticas y mejores supporters, en /settings/tips) ya existían — myPurchaseHistory en sí es un duplicado exacto de myCoinPurchases (ya en uso, misma llamada al manager, mismos argumentos), así que no necesitaba nueva UI. Los huecos reales: mySentTips no tenía ningún consumidor en ningún lugar, así que se añadió un selector de pestañas Recibidas/Enviadas a TipsPage.tsx — la pestaña Enviadas lista las propinas que este usuario envió a otros creadores, con sus propios totales extraídos de los campos totalSent/totalSentAmount de myTipStats (antes no seleccionados). myTransactionStats y coinPurchaseStats no tenían ningún consumidor en ningún lugar, así que se añadió un encabezado de estadísticas de billetera a CoinTransactionsPage.tsx (saldo actual, total de monedas compradas, total gastado, total de transacciones). contentTips/contentTipTotal y recentTips se dejaron deliberadamente sin construir: los dos primeros son desgloses de propinas por contenido específico (por ejemplo, "quién dio propina a este mensaje de chat específico"), que no encajan en la forma de un panel de billetera personal y no tienen ninguna superficie de UI por mensaje existente a la cual adjuntar un total sin un cambio materialmente separado al renderizador de burbujas de mensaje; recentTips no toma ningún argumento de usuario/autenticación (un feed de propinas recientes de toda la plataforma, sin autenticación) sin ninguna página de feed de actividad pública comparable en ningún lugar de la app para alojarlo. Nuevos documentos de operación: MySentTipsInline.graphql, MyTransactionStatsInline.graphql, CoinPurchaseStatsInline.graphql; se extendió MyTipStatsInline.graphql con los campos del lado enviado. Nuevas pruebas: TipsPage.test.tsx, CoinTransactionsPage.test.tsx.
• Un panel de seguridad completo no tiene ningún consumidor de frontend en ninguna de las dos apps: securityStats, sessionDetails, getSecurityAlertsStats, terminateSession/terminateOtherSessions (distintos de revokeSession/revokeAllOtherSessions, que sí están conectados) no se usan. Impacto: Medio. Corregido — y el panel de seguridad en sí ya existía. SecurityAlertsPage.tsx (tarjeta de puntuación, lista de alertas, registro de eventos persistido) y SessionsSettingsPage.tsx (sesiones activas, revocar/revocar-todas-las-demás, detalle expandible por sesión, historial de inicios de sesión) ya eran páginas reales y construidas — la premisa de este punto ("sin consumidor de frontend") era incorrecta para el panel en su conjunto, solo cierta para los cuatro campos específicos que mencionaba. De esos: securityStats (conteos reales derivados del registro de auditoría persistido security_event — inicios de sesión totales, intentos fallidos, actividad sospechosa, intentos bloqueados, dispositivos vistos) no tenía ningún consumidor, así que se añadió una cuadrícula de "Actividad de la cuenta" a SecurityAlertsPage.tsx. getSecurityAlertsStats (un desglose por severidad de las alertas de este usuario) no tenía ningún consumidor, así que se añadieron chips de conteo alta/crítica junto a la insignia de no leídas ya existente en esa misma página. sessionDetails y terminateSession/terminateOtherSessions se dejaron deliberadamente sin construir: sessionDetails(sessionId) devuelve exactamente la misma forma UserSession que activeSessions ya devuelve, y la fila expandible "Ver detalles" que ya existe en SessionsSettingsPage.tsx ya muestra IP/primera vez vista/expiración directamente desde la lista que ya obtuvo — una segunda consulta para datos que ya se tienen agregaría una ida y vuelta de red sin información nueva. terminateSession/terminateOtherSessions son, a nivel de resolver, alias literales que llaman exactamente a los mismos métodos del manager que revokeSession/revokeAllOtherSessions (ya conectados, user-sessions.resolver.js) — mutaciones duplicadas de verdad, no una capacidad faltante. Nuevos documentos de operación: SecurityStatsInline.graphql, SecurityAlertsStatsInline.graphql. Nuevas pruebas: SecurityAlertsPage.test.tsx.
• Las acciones de analítica/moderación de transmisiones en vivo están inactivas: liveStreamStats, liveStreamViewers, banLiveViewer/unbanLiveViewer, cancelLiveStream/deleteLiveStream — LiveRoomPage ya tiene funcionalidad en vivo sustancial, estas específicas simplemente no se llaman. Impacto: Medio. Corregido. Las seis quedaron conectadas en LiveRoomPage.tsx. La insignia de conteo de espectadores (arriba a la derecha), visible solo para el propietario, ahora es un botón que abre un nuevo panel de "Espectadores y estadísticas": un resumen de liveStreamStats (pico de espectadores, vistas totales, reacciones, comentarios, compartidos, tiempo promedio de vista) junto con una lista de liveStreamViewers, cada fila con un control de expulsar/readmitir. La moderación por comentario ganó un botón banLiveViewer junto a la acción de Premiar ya existente (se revela al pasar el cursor, solo para el propietario, oculto en los comentarios del propio propietario) — unbanLiveViewer es alcanzable desde esa misma fila en la lista de espectadores una vez que se emitió una expulsión en esta sesión (el esquema no tiene ninguna query de "¿este usuario está expulsado actualmente?" de la cual obtener ese estado al cargar la página de nuevo, así que el interruptor se inicializa a partir de la acción recién tomada, no se fabrica como un estado persistente). cancelLiveStream (para una transmisión aún programada) obtuvo un nuevo botón "Cancelar" junto a "Comenzar transmisión" en la superposición previa al directo. deleteLiveStream obtuvo un nuevo botón "Eliminar esta transmisión" en la superposición posterior al final, solo para el propietario. Nuevos documentos de operación: LiveStreamViewersInline.graphql, LiveStreamStatsInline.graphql, BanLiveViewerInline.graphql, UnbanLiveViewerInline.graphql, CancelLiveStreamInline.graphql, DeleteLiveStreamInline.graphql. Se añadieron dos íconos pequeños (Ban, BarChart3) al set de íconos derivado de lucide del proyecto, que no tenía ninguno de los dos. Aún no existe un archivo de pruebas para LiveRoomPage.tsx (más de 1000 líneas, ya requiere un mockeo pesado de livekit-client/MediaRecorder/suscripciones solo para renderizarlo, la misma clase de configuración que ya requirió VoiceCallModal.test.tsx) — escribir uno queda diferido a la pasada final de pruebas junto con los demás archivos sin pruebas que esta sesión tocó (PostModal.tsx, ConversationDetailsPanel.tsx), de forma consistente con cómo se manejaron esos.
• Compartir ubicación en vivo no tiene UI de "actualizar" o "detener". updateLiveLocation/stopLiveLocation están completamente implementados (message.resolver.js/messageManager) — compartir estático de una sola vez e iniciar un compartir en vivo funcionan, pero no hay ningún invocador para actualizar o detener explícitamente un compartir en vivo en curso. Impacto: Medio. Corregido — y "el compartir estático funciona" también era incorrecto, un bug más grave que la UI de actualizar/detener que faltaba según este punto. shareLocation(input: LocationInput!): Message! nunca aceptaba un argumento conversationId en absoluto — la acción "Compartir ubicación" ya existente en ChatView.tsx la llamaba solo con {latitude, longitude}, y el resolver pasaba eso directamente al manager, que requiere conversationId para crear el mensaje (conversation_id es una columna no-nula). Cada clic en "Compartir ubicación" fallaba del lado del servidor, no funcionaba como se afirmaba. Corregido añadiendo conversationId: ID! a la firma de la mutación (esquema + resolver + el documento de operación ShareLocation) y pasándolo desde el id de conversación ya conocido en ChatView.tsx. Al corregir esto, se encontraron y corrigieron dos huecos de autorización relacionados en la misma ruta de código: shareLocation nunca verificaba que el remitente fuera realmente participante de la conversación destino (cualquier usuario autenticado podía inyectar un mensaje de ubicación en una conversación arbitraria de la que no forma parte), y updateLiveLocation nunca verificaba que quien llamaba fuera el dueño del mensaje que se actualizaba (cualquier usuario autenticado podía redirigir el compartir de ubicación en vivo activo de otra persona a coordenadas falsas) — ambos corregidos con las mismas verificaciones de participante/propiedad que este código base usa en otros lugares. Con shareLocation ya alcanzable, se construyó la mitad "en vivo": una nueva acción del compositor "Compartir ubicación en vivo" (locationType: 'live') que inicia un bucle navigator.geolocation.watchPosition que llama a updateLiveLocation en cada cambio de posición, y un botón "Dejar de compartir" en la burbuja del propio mensaje de ubicación en vivo activo del remitente que llama a stopLiveLocation. Nuevas pruebas en message-manager.unit.test.js (la verificación de participante de shareLocation, expiración estática/en vivo, la verificación de propiedad + expiración de updateLiveLocation) y en resolvers/message.resolver.test.js (paso de argumentos para ambas mutaciones); MessageBubble.test.tsx extendido con el nuevo botón de Dejar de compartir (visible solo para el remitente, solo mientras está en vivo y no ha expirado).
• Elementos más pequeños sin usar pero listos: usersWhoReacted/messageThread/pollResults (votar en encuestas funciona, ver resultados/reacciones no); deleteNotification/deleteAllNotifications (marcar como leído funciona, eliminar no — se confirmó que NotificationsPage.tsx no tiene ninguna funcionalidad de eliminar/descartar/"borrar todo" a pesar de que ambas mutations están completamente implementadas); queries mutualFollowers/mutualFollowing; bulkFollowUsers/bulkMuteUsers; myReports/contentReports (enviar funciona, ver tu propio historial de reportes no); verificationBadgeInfo; productReviewSummary/deleteProductReview; updatePostPromotion/promotionById. Impacto: Bajo individualmente, vale la pena revisarlos juntos. Mayormente corregido - se conectó UI real para las piezas genuinamente faltantes, varias resultaron ser redundantes. deleteNotification/deleteAllNotifications: NotificationsPage.tsx obtuvo un botón "Borrar todo" en el encabezado (con diálogo de confirmación) y un botón de eliminar por fila que se revela al pasar el cursor. mutualFollowers: PublicProfilePage.tsx obtuvo una línea "Seguido por alice, bob y otros" debajo de la biografía (diseños móvil y de escritorio) - solo se muestran los nombres realmente devueltos, sin fabricar un conteo "+N otros" ya que el campo no tiene un total. bulkFollowUsers/bulkMuteUsers: la ya existente BulkFollowerActionsPage.tsx (desseguir/bloquear/quitar seguidores/procesar solicitudes en masa) obtuvo "Seguir de vuelta" en la pestaña de seguidores y "Silenciar" en la de seguidos - la misma infraestructura de selección masiva, solo dos acciones más. usersWhoReacted: cada chip de reacción en MessageBubble.tsx ahora obtiene de forma diferida y muestra quién reaccionó como un tooltip al pasar el cursor, sin cambiar el comportamiento existente de clic para alternar la propia reacción. myReports: nueva página /settings/my-reports (añadida a la navegación de configuración bajo "Tus reportes") que lista los reportes de contenido enviados por el usuario con motivo, tipo de contenido, estado y notas de revisión una vez resueltos. verificationBadgeInfo: la insignia de verificación en PublicProfilePage.tsx (instancias móvil, de escritorio compacta y de encabezado de escritorio) ahora está envuelta en un botón que obtiene de forma diferida la información de la insignia al pasar el cursor/hacer clic y la muestra como tooltip. deleteProductReview: las filas de pedidos de ShopManagePage.tsx antes solo ocultaban "Dejar una reseña" una vez reseñado, sin forma de ver o eliminar lo enviado - ahora muestra la reseña (estrellas + comentario) con un botón de eliminar. updatePostPromotion: los nombres de campaña en MyPromotionsPage.tsx ahora son editables en línea (ícono de lápiz → renombrar) - el único campo que UpdatePostPromotionInput realmente expone además del blob JSON sin estructura targetAudience, que se dejó tal cual en lugar de construir una UI para un campo no tipado. Tres campos resultaron ser duplicados genuinos de datos ya entregados en otro lugar, sin necesitar nueva UI (el mismo patrón de "afirmación obsoleta" que varios ítems anteriores de esta sesión): pollResults duplica Message.poll (ya seleccionado en cada mensaje y ya la fuente de los porcentajes/conteos de votos renderizados en línea en MessageBubble.tsx); productReviewSummary duplica Product.averageRating/Product.reviewCount (ya usado en PurchaseProductModal.tsx); promotionById duplica myPromotions + promotionStats (el flujo ya existente de lista + expandir-para-ver-estadísticas de MyPromotionsPage.tsx ya devuelve los mismos datos). Tres se dejaron deliberadamente sin construir: mutualFollowing no tiene un espacio de UI comparativamente estándar como sí lo tiene la convención "Seguido por" de mutualFollowers; messageThread (una vista completa de hilo de respuestas) es una funcionalidad materialmente más grande que el resto de este lote; contentReports (ver todos los reportes sobre un contenido, no solo los propios) expondría quién más reportó qué entre usuarios, una preocupación exclusiva de moderación que no pertenece a una superficie normal orientada al usuario. Nuevos documentos de operación: MutualFollowersForProfile.graphql, BulkFollowUsersAction.graphql, BulkMuteUsersAction.graphql, MyReports.graphql, VerificationBadgeInfoInline.graphql, MyProductReviewInline.graphql, DeleteProductReviewInline.graphql, UpdatePostPromotionInline.graphql. Nuevo ícono añadido al set derivado de lucide del proyecto (Flag). Nuevas pruebas: NotificationsPage.test.tsx, MyReportsPage.test.tsx, MessageBubble.test.tsx extendido con cobertura del tooltip de reacciones; la cobertura de pruebas de BulkFollowerActionsPage.tsx/ShopManagePage.tsx/MyPromotionsPage.tsx/PublicProfilePage.tsx queda diferida a la pasada final de pruebas dado su tamaño (todos archivos grandes ya existentes sin archivo de pruebas previo).

Huecos solo de frontend (UI muerta o permanentemente deshabilitada)

• CoinsModal.tsx es código de demostración falso, no un flujo de compra real. Lista de paquetes fija, lee un campo balance que no existe en el tipo de usuario real, y su manejador de "compra" es await new Promise(resolve => setTimeout(resolve, 1500)) seguido de alert('Purchase successful! (Demo)') — cero llamadas GraphQL. Solo referenciado desde una historia de Storybook hoy, no desde ninguna página real (el flujo real es GetCoinsModal.tsx/GetCoinsPage.tsx/CoinExpressCheckout.tsx). Impacto: Bajo, pero vale la pena eliminarlo para que nadie lo conecte accidentalmente pensando que es real. Corregido. Se confirmó mediante grep que su única referencia real era el barrel coins/index.ts (que existía únicamente para reexportarlo) y su historia de Storybook - se eliminaron tanto CoinsModal.tsx como coins/index.ts, y se quitó la historia Wallet de CoinsModals.stories.tsx (las historias GetCoins/Insufficient de los modales reales quedan intactas).
• Un botón de "Apodos" en los detalles de conversación está permanentemente deshabilitado sin ninguna funcionalidad de respaldo (sin campo de esquema, sin método de manager para apodos por conversación) — solo disabled title="Coming soon". Archivo: ConversationDetailsPanel.tsx. Impacto: Bajo, pero es un callejón sin salida visible y descubrible para los usuarios. Corregido - se construyó la versión real y mínima de la funcionalidad en lugar de simplemente eliminar el botón muerto. Se añadió un apodo de visualización por conversación, autoasignado: una nueva columna nullable nickname en conversation_participant (migración + modelo), un campo nickname: String en el tipo GraphQL ConversationParticipant, y una nueva mutación updateMyNickname(conversationId, nickname) (null/vacío lo restablece al nombre real) - replicando las acciones de participante autoalcanzadas ya existentes (pinConversation/muteConversation) tanto para la verificación de membresía del manager como para su forma de autorización. Se eligió un apodo autoasignado "visible para todos en este chat" (como un apodo de servidor de Discord) en lugar de un apodo por espectador ("el nombre que le doy a esta otra persona"), ya que este último necesita un modelo de datos materialmente diferente (una tabla de tres vías espectador/objetivo/conversación, no una columna en la tabla existente de una fila por participante) para un ítem de impacto bajo. El botón ahora abre un editor real (prellenado con el valor actual) en lugar de estar permanentemente disabled, y la propia fila muestra el apodo activo en línea una vez establecido. Nuevos documentos de operación: se añadió UpdateMyNickname a ConversationParticipants.graphql, se añadió nickname a las selecciones de participantes de GetConversationParticipants y GetConversation. Nuevas pruebas: conversation-manager.unit.test.js (verificación de participante, validación de longitud, recorte, limpieza vía null, limpieza vía cadena en blanco) y resolvers/conversation.resolver.test.js (guardia de autenticación + delegación) - ConversationDetailsPanel.tsx en sí aún no tiene archivo de pruebas (hueco preexistente, diferido a la pasada final de pruebas junto con los demás archivos grandes sin pruebas que se tocaron en esta sesión).
• El CardElement de Stripe se renderiza en blanco sobre blanco e ilegible en modo claro, en ambos flujos de pago que lo usan. StripeCheckout.tsx (compra de monedas) y el AddCardForm de PaymentMethodsPage.tsx (agregar una tarjeta guardada) fijan ambos color: '#ffffff'/iconColor: '#ffffff' para el input de tarjeta, mientras el contenedor circundante es bg-white en modo claro. ThemeContext soporta un tema claro real resuelto (incluso vía prefers-color-scheme del sistema operativo), así que cualquier usuario en modo claro que escriba un número de tarjeta ve texto invisible mientras ingresa sus datos de pago. Impacto: Alto — bloquea/oscurece los flujos de compra de monedas y agregar tarjeta, dos rutas centrales de monetización, para cualquier usuario en modo claro. Corregido - y se encontró una tercera instancia que el roadmap no mencionaba. Un grep de todos los usos de CardElement encontró el AddCardForm de PaymentsPage.tsx (el flujo de "agregar tarjeta" propio de la página /payments, distinto del de configuración) con el mismo #ffffff fijo. Las tres ahora leen useTheme() y eligen #111827 (gris oscuro legible) en modo claro vs #ffffff en modo oscuro, tanto para color como para iconColor. También se eliminó un console.log('CardElement onChange: ...') suelto que quedaba en StripeCheckout.tsx al tocar ese bloque (la limpieza más amplia de console.logs se rastrea por separado más abajo). Nuevas pruebas: StripeCheckout.test.tsx y PaymentMethodsPage.test.tsx ambas extendidas con un par claro/oscuro que verifica que el stub de CardElement realmente recibe el color correcto según el tema (el stub ahora expone el options.style.base.color/iconColor que recibió vía atributos data-*, así que esto es una aserción real, no solo "no falla"). PaymentsPage.tsx no tiene ningún archivo de pruebas (hueco preexistente) - diferido a la pasada final de pruebas.
• StripeCheckout.tsx incluye 14 console.log de depuración sin proteger en el formulario de pago de producción, incluyendo un volcado completo de las variables GraphQL de compra ("Sending variables to GraphQL", un bloque "=== Purchase Debug Info ===" con packageId/paymentMethodId/customCoins) y un log de validación que se dispara en cada render dentro de la expresión disabled del botón de envío. Impacto: Medio — consola de producción ruidosa y una filtración menor del id del método de pago hacia las devtools en una superficie de pago. Corregido. Se eliminaron todos: los 3 logs del efecto de auto-selección de método de pago, los 7 logs del bloque "Purchase Debug Info" más el volcado separado "Sending variables to GraphQL" (8 en total), y el log "Button disabled validation" por render del botón de envío - este último estaba envuelto en una IIFE únicamente para tener un lugar donde poner el console.log antes de returnar el booleano real, así que la prop disabled del botón se simplificó de vuelta a una expresión simple una vez eliminado el log, en lugar de dejar una IIFE innecesaria envolviendo un solo booleano.
• ProfilePage.tsx y PublicProfilePage.tsx fijan cadenas de UI fuera de t() — en idiomas opuestos entre sí. El menú de configuración, el selector de tema, y las etiquetas de FollowListModal de ProfilePage.tsx ('Privacy', 'Profile visitors', 'Remove', 'Unfollow', 'Load more', 'No users to show', etc.) están en inglés fijo; PublicProfilePage.tsx fija las mismas props de FollowListModal en español fijo ("Eliminar", "Cargar más", "No hay usuarios para mostrar"). Ninguno de los dos pasa nunca por t(), así que ninguna de estas cadenas existe en en.json/es.json (los dos archivos de idioma por lo demás coinciden perfectamente 1 a 1, 2.628/2.628 claves). Resultado: un usuario en idioma español que ve su propio perfil ve texto de menú en inglés; un usuario en idioma inglés que ve el perfil de otra persona ve texto de lista de seguidores en español. Impacto: Medio — un bug visible que rompe el idioma en dos de las páginas más visitadas, y una instancia directa de que la regla de este proyecto de "enviar cadenas en ambos idiomas" se saltó porque las cadenas nunca se hicieron traducibles en primer lugar. Corregido en la raíz, no solo en los dos puntos de llamada. FollowListModal.tsx en sí era la fuente real de la división de "idiomas opuestos": los valores predeterminados de sus propias props removeLabel/unfollowLabel/emptyLabel eran español fijo ('Eliminar', 'Dejar de seguir', 'No hay usuarios para mostrar') aunque el componente ya importa useTranslation y lo usa para otras cadenas en el mismo archivo - así que cualquier invocador que olvidara sobrescribirlas (o uno futuro que nunca supiera que debía hacerlo) obtendría español en silencio sin importar el idioma real de la app. Se cambiaron las props a verdaderamente opcionales y se les dieron valores de reserva reales respaldados por t() (reutilizando claves existentes: common.remove, profile.unfollow, profile.followers/profile.following para el título) calculados dentro del componente, no como literales de parámetro por defecto de JS. También se encontró y eliminó una prop completamente muerta mientras se estaba ahí: loadMoreLabel se pasaba por ambos invocadores y por las props del componente pero nunca se renderizaba en ningún lugar - el mecanismo real de "cargar más" es un div centinela de IntersectionObserver, no un botón cliqueable con texto. Luego se corrigieron ambos puntos de llamada para que dejaran de fijar un solo idioma: los ítems del menú de configuración, las opciones del selector de tema, y las props de FollowListModal de ProfilePage.tsx ahora pasan todos por t() (reutilizando en su mayoría claves ya existentes usadas en otras partes de la app - navigation.notifications/.coins/.payments/.settings, settings.privacy/.profile_viewers, theme.system_default/.light/.dark, top_fans.title); las props de FollowListModal de PublicProfilePage.tsx hacen lo mismo en lugar de fijar español. Nuevas claves añadidas a en.json/es.json: profile.saved_posts, profile.no_users_to_show. Nueva prueba: FollowListModal.test.tsx (verifica que el valor de reserva realmente traducido se renderiza cuando no se pasa una prop de sobrescritura - no el español fijo anterior - y que las sobrescrituras explícitas siguen funcionando). ProfilePage.tsx/PublicProfilePage.tsx aún no tienen sus propios archivos de pruebas (hueco preexistente) - diferido a la pasada final de pruebas.
• _freshcheck9_Security.tsx es un duplicado obsoleto y completamente huérfano de SecuritySettingsPage.tsx. 606 líneas, sin ninguna referencia en ningún lugar (confirmado por grep), y una instantánea más antigua a la que le falta la UI de selección de método de 2FA por SMS/correo que sí tiene la página real. Archivo: apps/frontend-nextjs/src/page-components/settings/_freshcheck9_Security.tsx. Impacto: Bajo — sin efecto en tiempo de ejecución, solo desorden de código muerto que vale la pena eliminar. Corregido. Se reconfirmaron cero referencias (grep) y el tamaño exacto de 606 líneas antes de eliminarlo; tsc --noEmit limpio después.
• El logout de AuthContext está tipado como síncrono (() => void) pero en realidad es async, esperando una mutation y clearStore(). Cada punto de llamada actual hace await logout() así que funciona hoy, pero la interfaz no promete un Promise, así que un futuro invocador que olvide el await no recibe ninguna advertencia del compilador aunque saltárselo generaría una condición de carrera entre la redirección y la revocación de sesión del lado del servidor. Archivo: contexts/AuthContext.tsx. Impacto: Bajo. Corregido - y el mismo error de tipado existía en dos hermanos declarados justo al lado. logoutAccount(userId: string) => void y logoutAll() => void tienen exactamente el mismo bug: ambas implementaciones son async (revocan una sesión del lado del servidor antes de limpiar el almacenamiento local), pero la interfaz no prometía que ninguna devolviera algo esperable. Las tres se corrigieron a => Promise<void> (login/switchAccount, revisados junto a ellas, son genuinamente síncronas y se dejaron sin cambios). tsc --noEmit quedó limpio después sin necesitar cambios en ningún punto de llamada, confirmando la propia afirmación del roadmap de que cada invocador real ya las espera - solo el tipo mentía. No se añadió ninguna prueba nueva: es una corrección solo de tipos sin cambio de comportamiento, y AuthContext.test.tsx ya ejerce logoutAccount/logoutAll con await en los cuerpos de sus propias pruebas async.

Features de cara al usuario que hoy no existen en absoluto

No son bugs, no están a medio construir — son capacidades comunes en plataformas comparables que no tienen ningún modelo de backend, ningún campo de esquema, ni ninguna UI en ningún lugar de este código. Confirmadas como ausentes buscando sus nombres obvios en graphql/types, database/models, y los dos árboles src de frontend, sin ningún resultado.

• Sistema de tickets de soporte. La única vía de "contactar soporte" hoy es el formulario genérico de feedback (submitFeedback); no hay ningún modelo dedicado de ticket de soporte, ninguna capacidad de hilo/respuesta, ningún seguimiento de estado de ticket distinto del panel de triage de feedback. Impacto: Medio.
  • Corregido: Se construyó un sistema completo de tickets de soporte, distinto de UserFeedback, con capacidad real de hilo/respuesta. Backend: tablas support_ticket/support_ticket_message + modelos Sequelize, support-ticket.manager.js (crear/responder/cerrar para usuarios; listar/responder/actualizar-estado para administradores, protegido por un nuevo permiso de administrador MANAGE_SUPPORT_TICKETS), tipos/resolvers de GraphQL reflejados tanto en schema.web.graphqls como en schema.admin.graphqls, además de archivos de operaciones dedicados en packages/graphql/operations/Web/Support/** (para que un futuro cliente iOS/Android los reciba gratis) y packages/graphql/operations/Admin/Support/**. Frontend web: nueva página /settings/support (crear ticket, ver hilo, responder, cerrar), accesible desde el menú de configuración. Frontend admin: nueva página de triage /support (filtros de estado/categoría, vista de hilo, respuesta, actualización de estado), protegida por MANAGE_SUPPORT_TICKETS tanto en la navegación como en la ruta misma, siguiendo el patrón ya existente del panel de feedback. Se agregó i18n en ambos idiomas en frontend-nextjs y frontend-admin. Se escribieron pruebas (aún no ejecutadas — pospuestas a la pasada final de pruebas) para el manager, los resolvers y ambas superficies de frontend.
• Borradores de publicaciones. No hay forma de empezar a redactar una publicación y guardarla sin publicar para después — ni del lado del cliente, ni del servidor. La creación de publicaciones es solo publicar-inmediatamente. Impacto: Medio — una expectativa muy estándar de creación de contenido.
  • Corregido: El modelo ya tenía los campos isPublished/scheduledAt (de la programación de publicaciones), pero PostCreateInput.isPublished era un no-op muerto — post.validator.js verificaba/escribía el campo mal escrito input.is_published mientras que el esquema y todos los llamadores usan isPublished en camelCase, así que un cliente nunca podía realmente crear una publicación sin publicar. Se corrigió el error de mayúsculas/minúsculas (tanto en validateCreateInput como en validateUpdateInput), y se relajó la regla de "texto o medios requeridos" específicamente para un borrador (isPublished:false, sin scheduledAt) para poder guardar un borrador vacío. Se agregaron la query myDrafts y la mutación publishDraft (post.manager.js#getDrafts/#publishDraft, siguiendo el mismo patrón que las publicaciones programadas) — editar el contenido de un borrador y eliminarlo reutilizan las mutaciones existentes updatePost/deletePost, que ya funcionaban con cualquier publicación sin importar su estado de publicación. De paso, se encontró y corrigió un error real de privacidad que esta función habría heredado de otro modo: getPost() nunca verificaba isPublished, así que cualquier publicación sin publicar (un borrador, o una publicación aún programada) con la visibilidad por defecto public era completamente legible por ID por cualquier usuario autenticado, no solo su dueño — ahora las publicaciones sin publicar son exclusivas de su dueño sin importar la visibility. Frontend: CreatePostModal obtuvo un botón "Guardar borrador" junto a Compartir/Programar (omite los requisitos de texto/medios/precio, y nunca dispara el crossposting ni el panel de impulso/promoción), y una nueva página /settings/drafts (listar, publicar, editar, eliminar) que reutiliza el patrón de UI de la página de publicaciones programadas.
• Encuestas en publicaciones/historias. Los tipos Poll/PollOption existen, pero solo dentro de message.type.js (encuestas de chat) — no hay ningún sticker/adjunto de encuesta para publicaciones o historias, una función de engagement común en plataformas comparables. Impacto: Bajo-Medio.
  • Corregido: Se reutilizaron los tipos GraphQL Poll/PollOption/PollInput ya existentes de las encuestas de chat (se agregó un campo expiresAt opcional a Poll, inofensivo para las encuestas de chat que nunca expiran) en lugar de construir tipos paralelos. Backend: la definición de una encuesta (pregunta + 2-10 opciones) vive como JSONB en la propia fila de Post (post.poll) - funciona tanto para publicaciones como para historias sin ningún trabajo de esquema adicional, ya que una historia es solo una fila de Post con type:'story'. Los votos se registran en una nueva tabla post_poll_vote, reflejando la tabla poll_vote de las encuestas de chat (access-service dedicado post-poll.access-service.js, un voto por usuario, volver a votar sobrescribe el anterior). Nueva mutación votePostPoll (siguiendo el patrón de myDrafts) y un resolver de campo Post.poll que refleja Message.poll. Tanto PostCreateInput como StoryCreateInput obtuvieron un campo poll; una encuesta cuenta como contenido de la publicación/historia por sí sola (se relajó la regla de "texto o medios requeridos" en el validador cuando hay una encuesta presente, el mismo trato que los medios). Las encuestas son inmutables una vez creadas (sin ruta de edición - la gente ya podría haber votado). Al construir esto, se encontró y corrigió un error real de privacidad en getPost(): nunca verificaba isPublished, así que cualquier publicación sin publicar (un borrador, o una publicación aún programada) con la visibilidad por defecto public era completamente legible por ID por cualquier usuario autenticado, no solo su dueño - corregido junto con esta función ya que afecta directamente al contenido de borradores/publicaciones programadas con una encuesta. Frontend: un componente reutilizable PostPoll.tsx (barra de porcentaje, marca de verificación, bloqueado una vez votado, reflejando la UI de la encuesta de chat ya existente en MessageBubble.tsx) conectado en PostCard.tsx (feed), PostModal.tsx (detalle/permalink, móvil + escritorio), y StoryViewer.tsx (sticker de historia). CreatePostModal.tsx obtuvo un panel de composición de encuestas (pregunta + hasta 4 opciones) junto a sus paneles existentes de precio/programación - una encuesta funciona para una publicación nueva pero no se ofrece al editar (por la inmutabilidad). CreateStoryModal.tsx obtuvo la misma UI de encuestas y ya no requiere una foto/video cuando se configura una encuesta.
• Código QR para compartir perfil. No hay ningún campo qrCode ni generador en ningún lugar para el perfil propio de un usuario — común para promocionar una cuenta fuera de línea o en enlaces de biografía en otros lugares. Impacto: Bajo.
  • Corregido: Esta afirmación estaba desactualizada — la función ya existe y funciona de extremo a extremo, simplemente no estaba reflejada en este roadmap. components/ProfileQRCode.tsx genera un código QR real y estilizado completamente del lado del cliente (el paquete npm qr-code-styling, importado dinámicamente para que nunca se ejecute durante SSR) que codifica el enlace compartible del perfil, con el logo de Closegram incrustado en el centro y la corrección de errores forzada a 'H' para que el logo no rompa el escaneo. components/ShareProfileModal.tsx lo envuelve con acciones de Compartir/Copiar enlace/Descargar más un enlace a la página de enlaces en biografía del perfil, y ya está conectado tanto en ProfilePage.tsx (perfil propio) como en PublicProfilePage.tsx (al ver el de otra persona) mediante sus botones "Compartir perfil". No se necesita ninguna intervención del backend - el QR simplemente codifica ${window.location.origin}/${username}, calculado al instante, así que tampoco hay nada que compartir aquí con iOS/Android (un generador de QR nativo es la elección natural en esas plataformas). Inicialmente se empezó a construir un campo GraphQL redundante del lado del servidor User.qrCodeDataUrl (reutilizando el paquete npm qrcode ya usado por la configuración de 2FA) antes de descubrir la implementación de frontend ya funcional - se revirtió ese trabajo de backend ya que habría sido código muerto que ningún cliente necesitaba. Se agregó lo único que realmente faltaba: un archivo de pruebas para ShareProfileModal.tsx (ShareProfileModal.test.tsx) que cubre la acción de copiar enlace, la navegación a la página de enlaces en biografía, y el comportamiento de cierre al hacer clic en el fondo.
• Versionado de los Términos de Servicio / re-aceptación forzada. User.is_terms_conditions_accepted es un booleano simple que se fija una sola vez al registrarse — no tiene ningún número de versión asociado, así que no hay ningún mecanismo para forzar a los usuarios existentes a re-aceptar términos actualizados cuando cambian. Impacto: Medio-Alto para una plataforma que vende contenido íntimo/adulto pago — este es un hueco real de exposición legal, no solo algo deseable.
  • Corregido: El hueco era en realidad peor de lo descrito - isTermsConditionsAccepted nunca se fijaba ni se verificaba en ningún lugar del código (ni siquiera una vez al registrarse); simplemente se quedaba en su valor por defecto false para siempre, código muerto. Se construyó un mecanismo real y versionado: constants/environment.js#CURRENT_TERMS_VERSION (configurable por variable de entorno, por defecto '1.0') es la única fuente de verdad de "qué versión está vigente ahora mismo" - se sube el número y toda cuenta cuya versión guardada no coincida, incluyendo toda cuenta preexistente (versión guardada null), necesita re-aceptar. User.termsAcceptedVersion/termsAcceptedAt son la caché rápida de "estado actual"; una nueva tabla user_terms_acceptance, de solo inserción, es el rastro de auditoría legal (quién aceptó qué versión, cuándo, desde qué IP) - necesario para una defensa legal real en una plataforma que vende contenido adulto pago. Nuevo terms-acceptance.manager.js (getTermsStatus/acceptTerms/acceptCurrentVersionAtSignup), una query termsStatus + mutación acceptTerms, y campos User.termsAcceptedVersion/termsAcceptedAt (exclusivos del propio usuario, con el mismo control de acceso que otros campos sensibles de User). El registro ahora acepta automáticamente la versión actual (el formulario de registro ya muestra el aviso implícito "al continuar, aceptas nuestros Términos..."), así que una cuenta recién creada empieza al día en lugar de toparse de inmediato con su propia puerta de re-aceptación. Frontend: TermsGate.tsx, envuelto alrededor de cada pantalla autenticada por ProtectedRoute.tsx (la misma cobertura que la puerta de onboarding ya existente) - mientras needsAcceptance sea verdadero, muestra un modal de pantalla completa que no se puede cerrar sin aceptar. De paso, en authentication.manager.js, también se encontró y eliminó un error real y no relacionado directamente adyacente a este trabajo: un bloque del programa de referidos copiado por error en login() (en vez de solo en register()) que referenciaba una variable referralCode no declarada, lanzando un ReferenceError en cada inicio de sesión - silenciado por su propio try/catch, así que nunca se manifestaba, pero tampoco hacía nada.
• Flujo de retiro de contenido por DMCA/copyright. Solo existe la moderación de contenido genérica (reportes de usuarios → revisión de admin); no hay ningún flujo legal dedicado de retiro con un proceso formal de aviso y contra-notificación, que es materialmente distinto de la moderación de contenido rutinaria para cualquier plataforma que aloja medios generados por usuarios. Impacto: Medio-Alto — exposición legal/de cumplimiento para una plataforma de contenido generado por usuarios.
  • Corregido: Se construyó un flujo real de aviso y contra-notificación conforme a 17 U.S.C. 512, deliberadamente separado del flujo rutinario "esto viola las normas" de content-report.manager.js en lugar de sobrecargarlo. Backend: nuevas tablas dmca_takedown_request (nombre/correo del denunciante, descripción de la obra, las dos declaraciones juradas que exige 512(c)(3), una firma escrita, ciclo de vida de estado) y dmca_counter_notice (la declaración jurada de la parte acusada, el consentimiento de jurisdicción según 512(g)(3)(D), firma), con un rastro de auditoría completo - nada se sobrescribe jamás, cada revisión queda registrada. dmca.manager.js resuelve al propietario del contenido acusado del lado del servidor a partir de la publicación/comentario reportado (nunca confía en un id de propietario proporcionado por el cliente, lo cual permitiría a un denunciante desviar un retiro hacia la cuenta equivocada), y reutiliza los primitivos ya existentes y funcionales content-moderation.manager.js#removeContent/#restoreContent para el retiro/restauración real - sin ningún mecanismo paralelo de ocultamiento de contenido. Cualquiera puede presentar un aviso (no se requiere cuenta, siguiendo la práctica real de DMCA); una contranotificación solo puede presentarla el propietario real del contenido, y solo mientras el contenido esté efectivamente retirado como resultado de ese aviso específico. Un nuevo permiso de administrador MANAGE_DMCA_REQUESTS protege la cola de revisión. Frontend: una opción "Reportar infracción de derechos de autor" en el menú de opciones de la publicación (DmcaTakedownModal.tsx, deliberadamente más riguroso que el flujo genérico ya existente de "Reportar publicación" - recopila el nombre legal/correo y ambas declaraciones juradas), una nueva página /settings/dmca (avisos presentados por ti, avisos presentados contra tu contenido con un formulario de contranotificación en línea), y una cola de revisión /dmca en el panel de administración (aprobar/rechazar un retiro, aceptar/rechazar una contranotificación, vista completa del detalle legal). Nuevos archivos de operaciones .graphql en packages/graphql/operations/Web/Dmca/** y Admin/Dmca/** para que un futuro cliente iOS/Android reciba el mismo contrato.

Panel de administración — herramientas faltantes

Verificado mediante una auditoría completa de apps/frontend-admin (todas las rutas, la navegación, y el catálogo de permisos) cruzada con el esquema de administración del backend — cada elemento de abajo se confirmó como faltante revisando directamente los tipos/resolvers reales de GraphQL, no asumido. Varios casi-aciertos explícitamente no están listados porque ya existen: ban/suspensión masiva de usuarios, eliminación masiva de contenido (adminBulkRemoveContent), revisión masiva de reportes (adminBulkReviewReports), actualización masiva de permisos de admin (BulkPermissionsModal), alternado de permisos por admin (PermissionsModal), una exportación de analíticas genérica bajo demanda (adminExportAnalytics, csv/json), lista blanca de IP de administradores para login, y un feed de actividad pequeño y sin filtros en el dashboard.

• La transmisión/anuncio a todos los usuarios es código muerto, no solo UI faltante. admin-managers/index.js#sendBroadcastMessage delega a adminNotificationManager.sendBroadcastMessage(...), pero AdminNotificationManager solo define realmente broadcastToAdmins (notifica a otros administradores, no a usuarios finales) — el método delegado no existe, así que esto lanzaría un error si algo alguna vez lo llamara. Ningún tipo/resolver de GraphQL lo expone, y no hay ninguna página de frontend. Impacto: Alto — soporte/operaciones no tiene forma de enviar un aviso de interrupción o actualización de política a los usuarios o a un segmento. Corregido. Se implementó el método real sendBroadcastMessage(message, adminId, options, context) en AdminNotificationManager, así que la fachada ya existente en admin-managers/index.js ahora realmente funciona en lugar de lanzar un error. La entrega reutiliza el modelo Notification por usuario ya existente en lugar de inventar un mecanismo paralelo - notificationType:'system' ya existía sin usar en el enum NotificationType, y la rama de renderizado por defecto de NotificationsPage.tsx ya muestra el texto de message correctamente para una notificación sin actor, así que no se necesitó ningún cambio en el frontend de consumo. Una nueva tabla admin_broadcast es el rastro de auditoría (quién envió qué, a qué segmento, a cuántos se alcanzó) - primero se crea una fila fresca de AdminBroadcast, luego el mensaje se distribuye como una fila de Notification por cada usuario objetivo mediante un nuevo bulkCreate. La segmentación admite all (todos los usuarios activos), verified (solo usuarios verificados), o una lista custom de ids de usuario (user.access-service.js#getActiveUserIds, limitado a 100 mil como válvula de seguridad). Un nuevo permiso de administrador MANAGE_BROADCASTS protege tanto la acción de envío como la consulta de historial. Frontend de administración: nueva página /broadcasts (formulario de composición con una confirmación de dos pasos "¿estás seguro?" antes de un envío masivo irreversible, más una tabla de historial paginada). Nuevos archivos de operaciones .graphql en packages/graphql/operations/Admin/Broadcasts/**.
• No hay una página de registro de auditoría de administración dedicada y filtrable. El backend ya soporta esto bien (adminGetActivityLog(adminId, action, startDate, endDate, limit, offset), además de exportAuditTrail/getActivityByType/getSystemActivity), pero el frontend solo renderiza un widget fijo de "últimas 20 entradas" en el dashboard — sin filtro por admin, acción, o rango de fechas, sin paginación, sin UI de exportación, a pesar de que el resolver acepta todo eso. Impacto: Medio-Alto — exactamente lo que un líder de operaciones necesita al auditar las acciones de otro administrador ("quién baneó a este usuario / quién cambió esa configuración de payout"). Corregido. adminGetActivityLog no tenía ningún permiso dedicado (cualquier administrador autenticado podía llamarlo); se añadió un nuevo permiso VIEW_AUDIT_LOG al catálogo y se protegió el resolver con él, junto con el alcance existente de propio-vs-super_admin. Nueva página /audit-log en el admin: filtros por administrador (menú desplegable, solo super_admin, poblado desde adminUsers), acción en texto libre (con debounce), y rango de fechas inicio/fin, todo conectado a los argumentos ya existentes del resolver — además de paginación real usando el total del resolver, un modal de detalles con el JSON crudo details de cada entrada, y una exportación CSV del lado del cliente de la página actual. Nueva operación .graphql AdminGetActivityLogFullInline (la consulta inline existente del dashboard solo seleccionaba 20 filas fijas sin filtros/campos de paginación, así que se dejó tal cual para el widget y se añadió una consulta completa nueva para la página).
• No hay gestión de sesión/dispositivo de administrador para OTROS administradores. Cada query/mutation de sesión (adminActiveSessions, adminRevokeSession, adminRevokeAllSessions) está fijada al propio admin.adminId de quien llama desde el contexto JWT — no existe ningún argumento targetAdminId en ningún lugar. Si se sospecha que una cuenta de administrador está comprometida, la única forma de matar sus sesiones hoy es eliminar por completo la cuenta (deleteAdmin). Impacto: Alto. Corregido. Se añadió un argumento opcional targetAdminId a las tres, con valor por defecto el propio llamante (sin cambio de comportamiento) y una protección de solo-super_admin para actuar sobre cualquier otro — el mismo patrón propio-vs-super_admin ya usado por adminGetActivityLog/adminIPWhitelist. De paso, se corrigió un bug real preexistente: adminRevokeSession nunca verificaba que una sesión realmente perteneciera a su administrador objetivo, así que cualquier administrador autenticado que obtuviera el sessionId de otro administrador ya podía revocarlo — el resolver ahora busca la sesión primero y rechaza si no coincide. Nueva tarjeta de "Sesiones activas" en la página de detalle de cada administrador (/admins/[id], ya protegida solo para super_admin) que lista dispositivo/IP/última actividad con revocación por sesión y un "cerrar sesión en todos lados" con confirmación, reutilizando exactamente las mismas queries/mutations (y el mismo patrón de UI) que la sección "Mis sesiones" ya existente en la página de cuenta propia del administrador.
• No hay feature flags / interruptores de emergencia generales. system-settings.manager.js ya define getFeatureFlags, setFeatureFlag, enableMaintenanceMode, disableMaintenanceMode, isMaintenanceMode — nada de esto está conectado a ningún tipo/resolver de GraphQL ni página de frontend. Los únicos interruptores reales que existen son estrechos: payoutsEnabledGlobally y isActive por paquete de monedas. Impacto: Alto — una válvula de seguridad estándar de respuesta a incidentes (p. ej. deshabilitar compras de monedas o transmisiones en vivo en toda la plataforma sin un despliegue) que esta plataforma no tiene. Corregido — y resultó que esos métodos no solo estaban desconectados, sino que no funcionaban en absoluto: llamaban a getSetting/setSetting, que consultan una forma genérica de key/value que no existe en el modelo real SystemSetting (la misma clase de código muerto que tenía payoutsEnabledGlobally antes de obtener su propia columna tipada). Se reconstruyeron getFeatureFlags/setFeatureFlag/isFeatureEnabled/enableFeature/disableFeature/isMaintenanceMode/enableMaintenanceMode/disableMaintenanceMode sobre 5 columnas tipadas nuevas en SystemSetting (maintenanceMode, maintenanceMessage, coinPurchasesEnabled, liveStreamingEnabled, newRegistrationsEnabled), el mismo patrón que ya usaba payoutsEnabledGlobally. Un nuevo permiso de administrador MANAGE_SYSTEM_SETTINGS protege una nueva superficie GraphQL adminGetFeatureFlags/adminSetFeatureFlag/adminSetMaintenanceMode. Cada bandera se hace cumplir donde importa, no solo se muestra: coin-purchase.manager.js (los 4 puntos de entrada de compra), live-stream.manager.js#createLiveStream, y authentication.manager.js#register ahora verifican su bandera antes de hacer cualquier trabajo. El modo de mantenimiento es la válvula de seguridad de toda la plataforma específicamente: un nuevo middleware de Express delante de /web/graphql (solo el endpoint de consumo — /admin/graphql sigue siendo accesible para que el personal pueda desactivarlo de nuevo) devuelve un 503 con el mensaje configurado mientras está activo, y falla de forma abierta si la propia consulta de configuración falla, para que un fallo de la base de datos nunca pueda tumbar la API. Nueva página de administración /system/feature-flags con interruptores de aplicación instantánea (cada interruptor llama a su mutación de inmediato, acorde al caso de uso "activarlo durante un incidente") y un paso de confirmación antes de activar el modo de mantenimiento específicamente, ya que bloquea toda la plataforma.
• No hay gestión del catálogo de roles/permisos de administrador. El catálogo de 13 permisos está fijado en admin-user.manager.js#getAdminPermissions, y los roles válidos están fijados a ['moderator', 'admin', 'super_admin']. La UI de administración solo puede alternar las claves fijas existentes por administrador — no hay forma de definir un nuevo permiso, crear un rol/preset personalizado, o gestionar categorías. Impacto: Medio — importará una vez que el equipo quiera roles más estrechos (p. ej. "auditor solo de pagos"). Corregido — deliberadamente no dejando que los administradores inventen nuevas cadenas de permiso: cada control de acceso real en este código es hasPermission(adminId, 'CADENA_LITERAL') incrustado en ~75 puntos de llamada revisados en el código a lo largo de cada resolver de admin, así que una clave de permiso definida en la base de datos se vería real (activable, listada) sin hacer cumplir nada en ningún lado — una falsa sensación de seguridad de manual. En su lugar se construyó exactamente lo que pide el propio ejemplo del roadmap: preajustes de rol definidos por el administrador — conjuntos con nombre y reutilizables de las claves del catálogo existente (nueva tabla/manager/superficie de GraphQL admin_role_preset, solo super_admin, del mismo nivel que adminActivate/adminDelete/adminUpdateRoleAndPermissions), de forma que "auditor solo de pagos" = {MANAGE_PAYOUTS: true, VIEW_ANALYTICS: true} se puede crear una vez y aplicar a cualquier cuenta de administrador en una sola acción desde un nuevo menú desplegable "Aplicar un preajuste" dentro del PermissionsModal por administrador ya existente. Cada escritura de preajuste valida sus claves contra el catálogo real (admin-user.manager.js#getPermissionKeys(), extraído de getAdminPermissions para que ambos compartan una única fuente de verdad) y rechaza cualquier clave desconocida. Nueva página de gestión /admins/role-presets. De paso, se corrigió un bug real que este mismo catálogo había acumulado durante la sesión: 7 claves de permiso agregadas por ítems anteriores del roadmap (MANAGE_APP_VERSIONS, MANAGE_FEEDBACK, MANAGE_SUPPORT_TICKETS, MANAGE_DMCA_REQUESTS, MANAGE_BROADCASTS, VIEW_AUDIT_LOG, MANAGE_SYSTEM_SETTINGS) y la categoría system nunca recibieron etiquetas en en.json/es.json, así que activar cualquiera de ellas en PermissionsModal mostraba una clave sin traducir como permissionLabels.VIEW_AUDIT_LOG en lugar de una etiqueta real — ahora está completo.
• No hay exportación de datos contextual desde las vistas de lista filtradas de administración. Soporte/finanzas/legal necesitan "exportar los usuarios que acabo de filtrar" o "exportar esta lista de payouts pendientes", no un generador de reportes desconectado. Usuarios, Pagos/Cashouts, y Contenido Marcado no tienen ninguna funcionalidad de exportación ligada a sus filtros/selección reales — el único exportador real (adminExportAnalytics) es una herramienta independiente sin relación con el estado en vivo de ninguna tabla. Impacto: Medio. Corregido. Deliberadamente no replicando la maquinaria de archivo-servidor/URL-de-descarga de adminExportAnalytics para 3 tipos de lista más (desproporcionado para "reformatear estas filas como CSV", y ninguna de las 3 queries siquiera devuelve un total de filas necesario para juzgar la completitud de la exportación como sí hacen esos reportes enlatados). En su lugar, cada una de las 3 páginas obtuvo un botón "Exportar CSV" que vuelve a ejecutar su propia query paginada existente con los filtros actuales intactos, con un límite alto de filas, y construye el CSV del lado del cliente (nuevo helper compartido lib/csv.ts, promovido de una copia que ya vivía en línea en la página de audit-log desde el ítem #59 del roadmap). Ninguno de los 3 resolvers subyacentes (adminGetUsers/adminGetCashouts/adminGetFlaggedContent) limitaba limit antes — un cliente ya podía pedir una respuesta sin límite antes de este cambio — así que se agregó un límite del lado del servidor MAX_EXPORT_LIMIT = 5000 (replicando el patrón ya existente en link-tracking.manager.js/search-history.manager.js) a los tres sin importar lo que el cliente envíe; el botón de exportación muestra un aviso de "mostrando las primeras 5,000 — reduce tus filtros" si se alcanza el límite, en lugar de truncar en silencio. La exportación usa el permiso de visualización ya existente de cada página (VIEW_USERS/MANAGE_PAYOUTS/MODERATE_CONTENT), no EXPORT_DATA — EXPORT_DATA está clasificado como un permiso de analítica/insights, y proteger la exportación con él por separado permitiría que un administrador vea una tabla filtrada pero no pueda exportar exactamente lo que está viendo, contradiciendo el propósito. De paso, se agregó el campo user.email faltante a la query de cashouts, ya que el correo existe en CoinCashout.user pero la vista de cashouts de administración nunca lo seleccionaba.
• No hay búsqueda global de administración entre usuarios/publicaciones/transacciones/reportes. La paleta de comandos (Cmd+K) parece que debería hacer esto pero solo filtra la lista estática de elementos de navegación — no tiene ningún conocimiento de datos de entidades en vivo. La búsqueda está completamente aislada por página hoy. Impacto: Medio. Corregido. Se mantuvo la CommandPalette de Cmd+K existente como único punto de entrada en lugar de construir una página de búsqueda separada — al escribir 2 o más caracteres ahora también se dispara, con debounce (300ms), una query adminGlobalSearch(query) junto al filtro estático de elementos de navegación (sin cambios), renderizando secciones agrupadas de Usuarios/Cashouts/Publicaciones/Reportes debajo. El nuevo GlobalSearchManager distribuye la query a una consulta ligera por categoría, cada una limitada a 5 resultados y cada una protegida de forma independiente con el permiso existente de esa categoría (VIEW_USERS, MANAGE_PAYOUTS, MODERATE_CONTENT dos veces, para publicaciones y reportes) — a quien le falte un permiso simplemente recibe un arreglo vacío para esa categoría en lugar de que falle toda la búsqueda, siguiendo el mismo patrón con el que ya se ocultan condicionalmente los elementos de navegación en otras partes. La búsqueda de publicaciones reutiliza el índice GIN to_tsvector('english', text) que la tabla Post ya tenía (nuevo postAccessService.searchByText(), plainto_tsquery mediante un parámetro seguro replacements, nunca interpolado en el string) en lugar de agregar un índice nuevo. Los resultados de usuarios y cashouts son clicables hacia sus páginas de detalle ya existentes (/users/{id}, /payments/users/{userId}); los resultados de publicaciones y reportes se muestran solo como información, ya que esta aplicación realmente no tiene ninguna ruta de detalle de administración por publicación o por reporte a la cual enlazar hoy (adminGetReports en particular resultó no tener ninguna página de frontend en absoluto) — un enlace inventado sería peor que ninguno.
• No hay búsqueda de texto completo de contenido del lado de administración. adminGetFlaggedContent (la única query de navegación de contenido) toma contentType, status, limit, offset, orderBy — sin parámetro de texto libre, y no existe ningún resolver de búsqueda separado. Confianza y seguridad solo puede navegar lo que ya ha sido reportado, no buscar proactivamente en el texto de publicaciones una palabra clave/insulto/enlace de estafa. Impacto: Medio. Corregido. Nueva query adminSearchContent(query, limit, offset), protegida con el mismo permiso MODERATE_CONTENT que adminGetFlaggedContent, respaldada por un hermano paginado de la búsqueda de texto completo que este mismo ítem de la sección del roadmap (#64, búsqueda global) ya agregó (postAccessService.searchByTextPaginated(), Post.findAndCountAll sobre el índice GIN to_tsvector('english', text) ya existente, distinct: true para un conteo preciso junto con el include de user). Limitado deliberadamente a publicaciones: Post.text es la única columna de contenido con un índice de texto completo hoy, y agregar uno equivalente para comentarios/mensajes es un esfuerzo separado y mayor al que pide este ítem — un filtro contentType habría implicado una cobertura más amplia de la que realmente existe, así que se omitió en lugar de enviarse como un filtro que en silencio no hace nada para nada que no sea POST. Nuevo panel colapsable "Buscar contenido" en la página /moderation/flagged ya existente (la misma página donde está el panel "Contenido en tendencia", no una ruta separada), con entrada de texto libre con debounce (300ms), cada resultado renderizado con la misma miniatura/texto de vista previa usada en el resto de esta página y reutilizando exactamente los mismos modales y mutaciones de Marcar/Eliminar que ya usa la tabla principal de contenido marcado — un moderador puede actuar sobre una publicación encontrada proactivamente exactamente igual que sobre una reportada, sin necesidad de una plomería de acciones separada.
• No hay reportes programados/automatizados (p. ej. un resumen semanal de ingresos por correo). Todos los reportes son bajo demanda únicamente (adminExportAnalytics); el único cron job relevante (analytics-snapshot.service.js) solo escribe filas internas de almacén de datos, nunca envía correo. Impacto: Bajo-Medio. Corregido. Nueva página de administración "Suscripciones de reportes" de autoservicio (protegida con EXPORT_DATA, el mismo permiso que ya verifica adminExportAnalytics - un resumen recurrente no es más que una exportación programada): un administrador elige uno de los 5 tipos de reporte existentes (USERS/CONTENT/ENGAGEMENT/REVENUE/MODERATION, el mismo vocabulario que ya usa adminExportAnalytics) y una cadencia (DAILY/WEEKLY/MONTHLY), opcionalmente con correos de destinatarios adicionales (limitado a 5, validados) - si se deja en blanco, se envía por defecto al AdminUser.email propio del administrador. Nueva tabla admin_report_subscription con CRUD completo (adminGetReportSubscriptions/adminCreateReportSubscription/adminUpdateReportSubscription/adminDeleteReportSubscription), limitado a las propias suscripciones de quien llama (sin anulación de super_admin - a diferencia de sesiones/permisos, el resumen personal de otro administrador no tiene ninguna razón legítima para que alguien más lo toque). Nuevo cron job services/report-digest.service.js (siguiendo exactamente el mismo patrón node-cron + start() ya usado por analytics-snapshot.service.js/admin-session-cleanup.service.js) corre una vez al día a las 08:00, calcula qué frecuencias corresponden hoy (DAILY siempre, WEEKLY solo los lunes, MONTHLY solo el día 1), y delega en report-digest.manager.js, que reutiliza exactamente los mismos métodos de admin-dashboard.manager.js que adminExportAnalytics ya usa - resumidos a un puñado de cifras principales (p. ej. ingresos totales + tasa de crecimiento) en lugar de un volcado crudo por día, ya que un correo de resumen necesita verse de un vistazo, no un CSV. El nuevo emailService.sendReportDigest() sigue el mismo patrón bilingüe de plantilla que el resto de correos transaccionales de la app (sendPurchaseReceipt/sendCreatorEarningsPaid). Que una suscripción falle al enviarse (consulta de analítica fallida, dirección inválida) se registra y se omite en lugar de abortar toda la ejecución. De paso, se corrigió un bug real preexistente: la clave de error validation.invalid_report_type de adminExportAnalytics nunca se había agregado a en.json/es.json, así que ese error mostraba en silencio la clave cruda en lugar de un mensaje real antes de esta corrección.
• La nueva función Family Center (supervisión de tiempo de pantalla padre/hijo) no tiene ninguna superficie de administración. Las queries/mutations de graphql/types/family-supervision.type.js (mySupervisionAsParent/mySupervisionAsChild/childUsageStats/requestFamilySupervision/respondToFamilySupervision/endFamilySupervision/setChildTimeLimit) son todas solo para usuarios autenticados — sin equivalentes con prefijo admin, sin resolver de admin, sin método de manager para listar/inspeccionar/forzar el fin de un vínculo de supervisión. Un grep de "family" en apps/frontend-admin/src no arroja nada relacionado. Esta es una función nueva (modelo/migración/manager/resolver todos agregados en los últimos 30 commits) que involucra cuentas de menores, sin ninguna vía de administración para investigar una disputa o desvincular por una necesidad legal/de seguridad. Impacto: Alto. Corregido. Nueva query adminGetFamilySupervisions(status, limit, offset) que lista todos los vínculos de supervisión de toda la plataforma (no limitados a quien llama, a diferencia de los findByParent/findByChild ya existentes), y una nueva mutación adminForceEndFamilySupervision(linkId, reason) que puede finalizar un vínculo sin importar su estado o si quien llama es parte de él - a diferencia del endFamilySupervision de cara al usuario, que sí lo exige. Ambos reutilizan el mismo tipo/tabla/access-service FamilySupervision ya existente en lugar de construir un modelo paralelo. Nuevo permiso dedicado MANAGE_FAMILY_SUPERVISION (no una clave más amplia ya existente como VIEW_USERS, ya que esta es específicamente una superficie de seguridad de menores) protege ambos. Forzar el fin de un vínculo active notifica tanto al padre/madre como al hijo/a con el motivo indicado por el administrador (un vínculo pending o ya declined/ended no tiene nada que notificar a nadie, y forzar el fin de un vínculo ya finalizado/rechazado es una operación sin efecto, igual que el propio método de cara al usuario); endedByUserId se deja en null ya que esa columna es una FK hacia User y ningún usuario (padre/madre o hijo/a) fue realmente quien lo finalizó. Nueva página de administración /family-center: una lista filtrable (por estado) que muestra los nombres de usuario/correos de ambas partes y una acción de forzar el fin con un modal de confirmación de motivo obligatorio, reutilizando el mismo componente ReasonModal que ya usa cualquier otro flujo de acción de moderación.
• No hay control de administración para congelar/descongelar la cuenta de payout de un usuario, a pesar de que la mutation ya existe. adminSetPayoutAccountDisabled(userId, disabled, reason) (graphql/types/admin/payout-admin.type.js, resuelto en admin/payout-admin.resolver.js, respaldado por PayoutAccount.adminDisabled) no tiene ninguna referencia en ningún lugar de apps/frontend-admin/src. La única página de pagos por usuario (app/payments/users/[userId]/page.tsx) muestra 8 StatCards de ingresos de solo lectura y nada sobre el estado de la cuenta de payout. Un administrador que revisa un cashout sospechoso no tiene forma de congelar realmente la cuenta de payout de ese usuario. Impacto: Alto. Corregido. La mutación ni siquiera tenía forma de leer primero el estado actual - no existía ninguna query adminGetPayoutAccount(userId), así que un control de frontend no habría tenido nada que mostrar antes del primer clic. Se agregó esa query (con la misma protección MANAGE_PAYOUTS, respaldada por el userPayoutAccountAccessService.findByUser() ya existente - sin necesidad de una nueva capa de datos) junto con una nueva tarjeta "Cuenta de pagos" en la página de pagos por usuario: proveedor/estado/pagos habilitados/últimos 4 dígitos del banco de un vistazo, una insignia Activa/Congelada, y un botón Congelar/Descongelar detrás de un modal de confirmación con motivo obligatorio (el mismo ReasonModal que ya usa cualquier otra acción de moderación). Un usuario sin ninguna cuenta de pagos (el caso común) recibe un mensaje explícito de "no ha configurado una" en lugar de una sección vacía. De paso, se separó el contenido en línea de payments/users/[userId]/page.tsx en su propio UserRevenueContent.tsx (siguiendo la misma convención que ya sigue cualquier otra página de administración) para que la nueva tarjeta sea comprobable con pruebas unitarias y page.tsx se mantenga como un envoltorio delgado - una lección aprendida de la forma difícil antes en este mismo esfuerzo (roadmap #63) cuando una exportación con nombre directamente dentro de un page.tsx rompió la generación de tipos de rutas de Next.js.
• No hay ninguna herramienta de administración para buscar, inspeccionar, o reembolsar una transacción de compra de monedas cruda (Stripe/PayPal/IAP). moderation/refunds/page.tsx está explícitamente limitada a adminGetPostPurchases/adminRefundPostPurchase — solo desbloqueos de publicaciones exclusivas. No existe ninguna query adminGetPurchases/adminGetCoinPurchases/adminGetTransactions en el esquema de administración, a pesar de que coin-purchase.manager.js tiene una superficie completa de refundPurchase/approveRefund/rejectRefund. Commits recientes agregaron un proveedor de compras de PayPal completamente nuevo (services/paypal/*, una migración de PaymentCustomer por proveedor) sin ninguna visibilidad de administración que lo acompañe sobre la mezcla de proveedores o la búsqueda por transacción para una disputa/contracargo de una simple recarga de monedas. Impacto: Alto. Corregido - y de paso se encontró un agujero de seguridad real y en producción. approveRefund/rejectRefund resultaron ser solo comentarios de docblock de la clase, no métodos reales - refundPurchase(purchaseId, context) es el único camino de reembolso que realmente existe, y es solo una reversión del libro contable de monedas (nunca llamaba a Stripe/PayPal para emitir un reembolso real del lado del procesador - ninguno de los dos servicios expone todavía una llamada de reembolso, así que un administrador todavía tiene que hacer esa parte con el proveedor a mano). Mucho más grave: la mutación de esquema de cliente refundCoinPurchase(purchaseId) a la que este método estaba conectado no tenía ninguna verificación de autorización de ningún tipo - ni siquiera if (!user) - a diferencia de cualquier otra mutation hermana en ese mismo archivo de resolver. Cualquier persona que llamara, autenticada o no, podía reembolsar cualquier compra de monedas completada de cualquier usuario por id, revirtiendo en silencio su saldo de monedas; la prueba de integración que la ejercitaba incluso lo demostraba (un token de usuario común, éxito). Esa mutation ha sido eliminada del esquema por completo en lugar de parcheada, ya que nada en apps/frontend-nextjs/apps/frontend-admin/packages/graphql/operations la llamaba jamás. Su reemplazo, adminRefundCoinPurchase(purchaseId, reason!), es exclusivo de administradores detrás de un nuevo permiso dedicado MANAGE_TRANSACTIONS (los ya existentes MANAGE_PAYOUTS/MODERATE_CONTENT son ambos un ajuste semánticamente incorrecto - uno trata de pagar a creadores, el otro de contenido, ninguno de reembolsos de compras) y graba reason + el id del administrador que actúa en el metadata JSONB de la compra como rastro de auditoría (no existe ninguna columna dedicada de motivo de reembolso en CoinPurchase). El nuevo adminGetCoinPurchases(status, platform, userId, limit, offset) lista cada compra de toda la plataforma con su PaymentTransaction incluida (así que la mezcla de proveedores - stripe/paypal - y el id de cargo externo son visibles por fila, no solo la columna interna platform web/ios/android) - exactamente la brecha de visibilidad de "mezcla de proveedores" que señalaba el roadmap. Frontend: se agregó una tercera pestaña "Compras de monedas" al RefundsContent.tsx ya con pestañas existente (ya construido para extenderse así desde las pestañas de publicaciones/mensajes) - una columna Proveedor reemplaza a "Vendedor" (no hay vendedor en una recarga de la plataforma) más una columna extra de "Monto pagado" en dinero real, y la acción de reembolso solo aparece para compras completed (a diferencia de las compras de publicaciones/mensajes, una compra de monedas puede estar pending/failed, y el manager rechazaría un intento de reembolso sobre cualquiera de las dos).
• No hay visibilidad de administración sobre las sesiones/dispositivos activos de un usuario regular para investigar fraude o robo de cuenta (distinto del hueco ya listado sobre administradores gestionando las sesiones de otros administradores — esto es sobre investigar la cuenta de un usuario). UserModerationInfo (el tipo que respalda adminGetUserDetails) no tiene ningún campo de sesión/dispositivo/IP, y sessions.type.js solo expone datos de sesión al propio dueño de la sesión. Impacto: Medio. Corregido. Nueva query adminGetUserSessions(userId) (VIEW_USERS, la misma protección de adminGetUserDetails) más las mutations adminRevokeUserSession(sessionId, userId, reason)/adminRevokeAllUserSessions(userId, reason) (SUSPEND_USERS - revocar es una acción correctiva, un nivel por encima de una simple lectura). Las tres reutilizan sessions-devices.manager.js tal cual ya existía - cada método ahí ya tomaba un argumento userId explícito en lugar de fijar a quien llama, así que no se necesitaron nuevos métodos de manager, solo alcanzabilidad en el esquema de administración y una verificación de permiso; revokeSession/terminateAllSessions ganaron un parámetro reason opcional (con el mismo valor por defecto que el flujo de autoservicio) para que una revocación iniciada por un administrador grabe un motivo real en revoke_reason en lugar del genérico 'user_logout'. De paso, se corrigió un bug real en el mismo método que se reutiliza: la transformación de filas de getActiveSessions() guardaba el sistema operativo bajo la clave platform - un campo al que UserSession.os nunca resuelve, ya que el esquema no declara platform en absoluto - y nunca establecía userId/expiresAt (en silencio null ya que ningún llamador existente los había seleccionado todavía, aunque userId es no-nulo en el esquema). Este bug ya era visible para el usuario: Configuración → Seguridad → Sesiones activas ha estado mostrando un sistema operativo en blanco en la línea de navegador/SO de cada sesión. Frontend: una nueva sección colapsable "Sesiones" en la página de detalle de administración por usuario (carga diferida al expandir, siguiendo el mismo patrón de divulgación de Tendencias/Buscar contenido ya usado en otras partes del panel de administración) lista dispositivo/SO/navegador/IP/ubicación/última actividad con una revocación por sesión y una acción masiva "Cerrar sesión en todos los dispositivos" (que solo aparece cuando hay más de una sesión) - reutilizando las cadenas de i18n security.* (sessionsTitle, forceLogout, actionTitles.force_logout, etc.) que llevaban sin usarse en ambos archivos de idioma, aparentemente preescritas justo para esta función.
• No hay control de administración sobre el umbral de detección de auto-moderación NSFW, ni una vista de estadísticas para ello. admin-managers/nsfw-detection.manager.js tiene métodos funcionales getThreshold()/setThreshold(threshold)/getDetectionStats(), pero content-moderation.resolver.js nunca importa el manager en absoluto — lee las puntuaciones persistidas directamente de la BD en su lugar. Los tres métodos no se llaman en ningún lugar fuera de su propio archivo; la sensibilidad de auto-marcado es efectivamente fija y no ajustable desde el panel de administración. Impacto: Medio. Corregido - y esos tres métodos resultaron estar mucho más rotos que simplemente desconectados. getThreshold()/setThreshold() leían/escribían una propiedad de instancia en memoria (defaultThreshold = 0.7) sin ninguna persistencia - se perdía en cada reinicio, y de todas formas era irrelevante, ya que la decisión REAL de auto-marcado (autoModerate(), llamada desde el camino de detección realmente funcional analyzePostMedia()) nunca la leía: tenía sus propias tres bandas de puntuación fijas (0.9/0.7/0.5) completamente independientes del umbral "configurable". Conectar setThreshold() tal cual habría sido puramente cosmético. getDetectionStats() llamaba a un método getAll() que no existe ni en PostNsfwScoreAccessService ni en NsfwCommentScoreAccessService - un TypeError garantizado en cada llamada, nunca ejercitado por ninguna prueba - y su propia lógica de reduce leía un campo nsfw_score que ningún modelo declara (la columna real es confidence). Corrección real: el umbral ahora vive en una nueva columna nsfw_detection_threshold en SystemSetting (la misma fila singleton y access-service que ya usa el trabajo de feature flags/interruptores de emergencia), y los tres niveles de autoModerate() ahora escalan a partir de UN solo valor definido por el administrador - el umbral es el límite de "ocultar directamente", con los niveles de advertencia/marcado situados 0.2/0.4 por debajo (limitados a ≥0), preservando el espaciado original en el valor por defecto de 0.7 mientras hace que el punto de anclaje sea genuinamente ajustable. getDetectionStats() ahora llama a un nuevo getStats() en cada access service que calcula agregados reales a nivel de BD (COUNT/AVG vía Sequelize.fn) sobre las columnas reales isNsfw/confidence, en lugar de traer miles de filas a memoria a través de un método que nunca existió. Nuevos adminGetNsfwThreshold/adminSetNsfwThreshold/adminGetNsfwDetectionStats (MODERATE_CONTENT - el mismo permiso que protege cualquier otra superficie real de moderación de contenido, no MANAGE_SYSTEM_SETTINGS, ya que esto ajusta el comportamiento de moderación, no una bandera a nivel de sistema). Nueva página de administración /moderation/nsfw-detection: un campo de umbral con validación en línea, y una vista de estadísticas desglosada por publicaciones/comentarios más un porcentaje general marcado.
• Un puñado de queries de administración muertas/duplicadas, vale la pena una pasada de limpieza: adminGetPayoutProfile y adminGetContentModerationHistory no se usan — las páginas que parecen necesitarlas obtienen los mismos datos vía campos anidados (CoinCashout.payoutProfile, ContentDetails.moderationHistory) en su lugar; adminGetModerationStats duplica a adminGetContentModerationStats/adminGetModerationQueueStats, que sí usa el dashboard. Impacto: Bajo. Corregido. Se confirmó que las tres afirmaciones seguían siendo ciertas (cero referencias en apps/frontend-admin/src o packages/graphql/operations) antes de tocar nada. Se eliminaron los campos de query adminGetPayoutProfile y adminGetContentModerationHistory de payout-admin.type.js/content-moderation.type.js y sus resolvers, y también se eliminó adminGetModerationStats (su handler llamaba al mismo contentModerationManager.getContentStats() que ya usa el adminGetContentModerationStats que sí se conserva, así que el método del manager subyacente se queda — solo se va la superficie de query duplicada sin argumentos). payoutAdminManager.getPayoutProfile() tenía exactamente un solo llamador (el resolver recién eliminado), así que se borró por completo en lugar de dejarlo como código muerto huérfano, junto con su import ahora sin uso de userPayoutProfileAccessService; contentModerationManager.getModerationHistory() y getContentStats() se quedan, ya que ambos siguen siendo llamados desde otros lugares (content-report.manager.js, la fachada de admin-managers, y el resolver de campo adminGetContentModerationStats/ContentDetails.moderationHistory que sobrevive). Se reflejaron las tres eliminaciones en schema.admin.graphqls; PayoutProfile y ContentModerationStats permanecen en el esquema ya que ambos tipos siguen siendo devueltos por otros campos que sí se usan. Ningún archivo .graphql de operaciones hacía referencia a las tres queries muertas, así que no había nada que eliminar ahí. Se reconstruyeron apollo-admin/apollo-web sin errores.

Huecos de documentación

Encontrados al cruzar apps/docs contra el estado actual del código que describe.

• Cada enlace de "ver código fuente" y "Editar esta página" en todo el sitio de documentación apunta a la rama dev, que está 513 commits y ~19 días detrás de main (editUrl de docusaurus.config.js). Concretamente, apps/backend/graphql/resolvers/webauthn.resolver.js y admin-passkey.service.js no existen en dev en absoluto, y el coin-purchase.manager.js de dev no tiene purchaseCoinsWithSavedPaypal. Cada enlace de clic-a-código-fuente en los docs de features apunta a una instantánea materialmente desactualizada. Impacto: Medio. Corregido. dev ya se puso al día con main (el desfase concreto que medía este ítem ya no se reproduce - tanto webauthn.resolver.js como admin-passkey.service.js ahora también existen en main), pero volver a apuntar editUrl a dev específicamente solo habría tapado el problema de fondo: main, no dev, es la rama real de destino de PRs/estable de este repo, así que es contra la que un enlace de "Editar esta página" debería abrir un PR - un enlace fijado permanentemente a la rama que en ese momento vaya más adelantada simplemente volverá a desactualizarse la próxima vez que dev diverja. Se cambió el editUrl de docusaurus.config.js de edit/dev/apps/docs/docs/ a edit/main/apps/docs/docs/. Fuente única de verdad (sin editUrl duplicado en otro lugar de apps/docs, confirmado vía grep); las URLs de dev incrustadas en el directorio build/ son un artefacto de compilación local desactualizado (ignorado por git, se regenera en el próximo docusaurus build), no un problema de archivo fuente.
• technical/ios.md contradice directamente a features/authentication.md y a esta misma hoja de ruta sobre qué tan completa está la autenticación en iOS. La tabla de funciones de technical/ios.md afirma Auth | ✅ 100% | Phone OTP, Apple Sign In, Google Sign In, mientras que features/authentication.md y la sección de paridad iOS/Android de abajo afirman correctamente ambas que el login con OTP por teléfono todavía no está conectado en iOS. technical/ios.md parece haberse quedado fuera de la pasada de reconciliación de documentación que atravesó el resto de apps/docs. Impacto: Medio — activamente engañoso en un documento que un lector trataría como fuente de verdad sobre el estado. Corregido - y resultó que era features/authentication.md (y la propia sección de paridad de esta hoja de ruta) la que lo tenía al revés, no technical/ios.md. Se leyó el código fuente real de iOS antes de asumir que cualquiera de los dos documentos tenía razón: el OTP por teléfono está completamente conectado de punta a punta en apps/ios (el botón de Teléfono de WelcomeView → modo teléfono de LoginView → RequestPhoneOtpUseCase → VerifyCodeView → loginWithPhone, todo el camino a través de AuthRepository/AuthService hasta las mutaciones GraphQL reales, sin ningún stub o TODO en ese camino) - y lo mismo con el registro de token de dispositivo para push (PushNotificationManager → DeviceTokenService.registerDeviceToken() → la mutación real). apps/docs/docs/technical/features/authentication.md (la referencia técnica detallada, un nivel más profundo que los dos documentos que discrepaban) ya tenía esto correcto, marcando ambas cosas como iOS only/conectadas - simplemente no se había contrastado contra el features/authentication.md de nivel superior más simple, que era el que en realidad necesitaba corrección. Se corrigieron las dos afirmaciones falsas de "apps/ios todavía no implementó/conectó esto" en features/authentication.md (OTP por teléfono, registro de token de dispositivo) y se eliminó la línea ahora falsa de la sección de paridad de abajo. technical/ios.md sí tenía un problema real y distinto, eso sí: su propia sección de "TODOs conocidos" listaba "flujo de recuperación de contraseña" como una brecha crítica de Auth, pero ForgotPasswordView.swift es real y alcanzable desde LoginView/PasswordView - no es una brecha en absoluto. Se corrigió esa lista a las dos brechas de Auth que sí se verificaron como reales: renovación de token (AuthService.refreshToken() es un stub TODO literal) y eliminación de cuenta (el AuthRepository.deleteAccount() conectado al backend existe, pero nada en la UI lo dispara - el camino de eliminación del lado de Settings pasa por un ProfileRepository.deleteAccount() distinto y stubbed que simplemente lanza ProfileError.featureNotSupported), y se ajustó la fila de Auth de 100% a 95% para que coincida. No se modificó ningún código fuente de apps/ios (fuera de alcance según CLAUDE.md) - esto fue exclusivamente una corrección de precisión documental.
• features/recent-updates.md es un único changelog sin fecha de "este ciclo" que se reescribe por completo en vez de agregarse incrementalmente, sin anclas de fecha calendario y sin ninguna otra página de changelog en toda la documentación. Una vez que llegue el próximo ciclo y lo sobrescriba, no queda ningún registro duradero de qué se lanzó y cuándo. Impacto: Bajo-Medio. Corregido. Se convirtió la página a un formato fechado y de solo-anexado: una nueva introducción declara la convención explícitamente (cada ciclo obtiene su propia sección ## AAAA-MM-DD — Título, la más reciente primero; un ciclo nuevo se agrega como una nueva sección arriba de la anterior, que nunca se reescribe ni se elimina), y el contenido del ciclo existente se envolvió en ## 2026-07-21 — Reconciliación completa de la documentación de funciones contra el código (fecha derivada de las marcas de tiempo de migración ya incrustadas en su contenido - 20260721*/20260722* - y confirmada contra la fecha del commit de creación del archivo), con cada encabezado interior degradado un nivel (##→###, ###→####) para que anide correctamente bajo la nueva sección fechada. Los dos enlaces de ancla internos a la sección de Despliegue siguen resolviendo correctamente (el texto/slug del encabezado no cambió, solo se degradó).
• La documentación nunca menciona el comando raíz npm run test:all ni su requisito de TZ=UTC, a pesar de que CLAUDE.md y payments-subscriptions.unit.test.js marcan ambos que las pruebas de backend asumen una zona horaria de contenedor en UTC. technical/testing.md solo documenta npm test por workspace. Alguien que siga solo la documentación pública (no CLAUDE.md) podría encontrar fallos de prueba locales espurios sin ninguna explicación. Impacto: Medio. Corregido. Se agregó una nueva sección "Comandos a nivel de raíz" a technical/testing.md (justo después de la tabla de resumen por paquete, antes de los análisis detallados paquete por paquete) que documenta los cinco scripts de prueba raíz del package.json (test, test:frontend, test:backend, test:all, test:log) verificados contra sus definiciones reales, más una subsección dedicada "El requisito de TZ=UTC" que explica el porqué (pruebas con temporizadores falsos que dependen de límites de fecha, asumiendo un contenedor en UTC, según payments-subscriptions.unit.test.js) y señala el Stop hook (run-tests-on-stop.sh) como el ejemplo existente de cómo hacerlo correctamente.
• WEBAUTHN_RP_ID/WEBAUTHN_ORIGIN/WEBAUTHN_RP_NAME se mencionan en dos docs de features como cubiertos en "configuración de entorno", pero ninguno de los docs de primeros pasos los documenta realmente, a pesar de que las passkeys están completamente lanzadas tanto del lado de usuario como de administrador, y admin/features/admin-accounts.md advierte explícitamente que un WEBAUTHN_ORIGIN mal configurado lanza Unexpected registration response origin. Impacto: Medio — un modo de fallo real y documentado sin instrucciones de configuración correspondientes en ningún lugar. Corregido. Se agregó una nueva sección "Passkeys (WebAuthn)" a getting-started/environment-setup.md (justo después de JWT, siguiendo la agrupación por categoría auth de env-catalog.js) que documenta las tres variables, sus valores por defecto (localhost/FRONTEND_URL/APP_NAME), la relación compartida-no-separada con admin, y ambos modos de fallo documentados - basado en el bloque de comentarios preciso que ya existía en apps/backend/.env.example (al que esta nueva sección ahora remite para un ejemplo real de producción) y enlazado de forma cruzada con el detalle específico de admin en admin-accounts.md. Se redirigieron los enlaces "configuración de entorno" ahora colgantes de los dos docs de features (technical/features/authentication.md) hacia el ancla de la nueva sección en vez del documento sin ancla.
• El sitio de documentación todavía usa el favicon/logo de stock de Docusaurus y las ilustraciones de relleno undraw_docusaurus_* sin usar, a pesar de que el título del sitio dice correctamente "Closegram Docs." Impacto: Bajo. Corregido. Se reemplazó static/img/logo.svg (el logo de la barra de navegación, que era literalmente la mascota dinosaurio de stock de Docusaurus) por una marca SVG creada a mano - una insignia de cuadrado redondeado con el gradiente de marca real de la app (morado --ifm-color-primary, #8b4ef0→#6d28d9, igual que en src/css/custom.css) con un monograma "C" en blanco. Se regeneraron favicon.ico y docusaurus-social-card.jpg a partir de esa misma marca usando sharp (ya presente en los node_modules compartidos del monorepo, usado por el pipeline de imágenes del backend) - el favicon es un contenedor PNG-en-ICO moderno (soportado por todos los navegadores principales), y la tarjeta social es un JPEG de 1200×675 con la marca más un logotipo "Closegram Docs" sobre el gradiente de marca, reemplazando las versiones de stock de Docusaurus de ambos. Se eliminaron por completo los tres archivos undraw_docusaurus_*.svg sin usar y docusaurus.png (se confirmó que no tenían ninguna referencia en ningún lugar fuera de esta entrada de la hoja de ruta - HomepageFeatures/index.js ya renderiza tarjetas solo de texto sin ninguna prop de imagen, así que eran puro peso muerto, ni siquiera estaban conectados a nada). Verificado con un npm run build -w docs completo (ambos locales en/es) - sin errores nuevos ni advertencias de enlaces rotos.

Paridad iOS/Android (backend listo, cliente nativo sin conectar — ver los docs de features enlazados para el detalle, no repetido aquí)

Estos ya tienen su propio checklist con evidencia por elemento; listados aquí solo para que esta lista sea un panorama completo en un solo lugar:

• Responder/rechazar una llamada entrante, historial de llamadas, e interfaz de espectador/solicitud de palabra en llamadas grupales — solo web; ya completamente conectado en iOS. Ver Llamadas.
• Flujo de compra nativa en la app (StoreKit 2 / Play Billing → redeem*CoinPurchase) — backend + GraphQL listos. Ver Monedas.

Pendiente de una decisión de producto/negocio (no iniciado — necesita una decisión antes que tiempo de ingeniería)

• Verificación de identidad automatizada/de terceros. Hoy es 100% revisión manual de administrador. Necesita una decisión de proveedor (Persona, Onfido, Stripe Identity, o similar) antes de poder empezar la implementación — implicaciones de costo y cumplimiento, no solo código.
• Generación de documentos fiscales para payouts (formularios estilo 1099 para creadores). Necesita una decisión sobre qué jurisdicciones/umbrales soportar y si construirlo internamente o integrar un proveedor (p. ej. Stripe Tax, Track1099).
• Comisiones recurrentes / leaderboards de referidos. Hoy los referidos solo pagan un bono único al referidor. Un modelo de comisión recurrente necesita una fórmula/tope de pago decidido antes de poder construirse.

Capítulos futuros más grandes (explícitamente fuera de alcance hasta que tengan su propio esfuerzo dedicado)

• Conexión de la app nativa apps/ios. Hay una cantidad grande y creciente de contrato de backend esperando sin usar: Family Center, Control de versiones de la app, 2FA por SMS/correo, tokens de dispositivo, OTP por teléfono, ubicación en vivo, las funciones de llamadas de arriba, compras nativas, y más — todo ya expuesto a través de packages/graphql/operations/Web/**, así que la próxima ejecución de codegen de apollo-swift lo recoge automáticamente. Según CLAUDE.md, apps/ios en sí no debe tocarse hasta que esto se convierta en su propia tarea dedicada.
• App de Android. Todavía no existe como cliente en absoluto — no hay apps/android, ni paquete de codegen para Android. El mismo contrato compartido packages/graphql/operations/Web/** que respalda a apollo-web/apollo-swift necesitaría un objetivo de codegen para Android (p. ej. Apollo Kotlin) agregado cuando esto comience.