ANÁLISIS DE ARCHIVOS COMUNES - BOT DE DISCORD Y TELEGRAM
========================================================

Fecha de análisis: 8 de febrero de 2026

## 1. ARCHIVOS UTILIZADOS POR AMBOS BOTS (DISCORD Y TELEGRAM)

### Configuración y Base de Datos:
├── config/config.php - Configuración central (tokens, DB, URLs)
├── includes/db.php - Conexión a base de datos compartida
├── includes/logger.php - Sistema de logging personalizado
├── includes/session_check.php - Validación de sesiones y CSRF
├── includes/activity_logger.php - Registro de actividad de usuarios
└── includes/auth.php - Funciones de autenticación

### Sistema de Traducción:
├── includes/Translate.php - Clase de LibreTranslate
├── src/Translate.php - Clase principal de traducción
├── translate_message.php - Endpoint de procesamiento de traducciones
├── process_translation_queue.php - Worker de traducción en background
├── src/TranslationWorker.php - Worker individual de traducción
├── src/TranslationCache.php - Sistema de caché de traducciones
└── src/TranslationWorkerPool.php - Pool de workers de traducción

### Helpers y Utilidades Compartidas:
├── common/helpers/schedule_helpers.php - Funciones de programación recurrente
├── common/helpers/sender_factory.php - Factory para crear senders específicos
├── common/helpers/converter_factory.php - Factory para conversores HTML
├── common/helpers/url_helper.php - Utilidades de URLs y seguridad
├── common/helpers/emojis.php - Manejo de emojis
├── includes/schedule_helpers.php - Helper alternativo de programación
├── includes/translation_helper.php - Helper de traducción frontend
├── includes/message_handler.php - Manejador central de mensajes
├── includes/error_handler.php - Manejo centralizado de errores
└── includes/tren_handler.php - Handler específico de trenes

### Templates y Componentes UI:
├── templates/header.php - Cabecera HTML común
├── templates/footer.php - Footer HTML común
├── templates/admin/ - Templates de administración compartidos

### Procesamiento y Colas:
├── process_queue.php - Procesador principal de colas de mensajes
├── includes/message_handler.php - Manejo de creación/actualización de mensajes
└── includes/scheduled_messages_table_body.php - Componente de tabla compartido

## 2. ARCHIVOS COMUNES PARA ENVÍO DE MENSAJES DESDE create_message.php

### Flujo Principal de Envío:
1. create_message.php (formulario) → 
2. includes/message_handler.php (procesamiento) → 
3. process_queue.php (ejecución) → 
4. [DiscordSender|TelegramSender] (envío específico)

### Archivos Involucrados en el Envío:

#### create_message.php:
├── Incluye: session_check.php, db.php
├── Template: templates/header.php, footer.php
├── Acción: POST a includes/message_handler.php
└── JavaScript: Manejo de Summernote, validación, selección de destinatarios

#### includes/message_handler.php:
├── Incluye: session_check.php, db.php, activity_logger.php, schedule_helpers.php
├── Procesa: Creación/actualización de mensajes en DB
├── Programa: Envíos inmediatos, diferidos, recurrentes
├── Dispara: process_queue.php para envíos inmediatos
└── Registra: Actividad en activity_log

#### process_queue.php:
├── Incluye: db.php, SenderFactory, ConverterFactory
├── Consulta: Mensajes pendientes en schedules
├── Crea: Sender apropiado via SenderFactory
├── Convierte: HTML via ConverterFactory
└── Ejecuta: Envío through platform-specific sender

#### Senders Específicos:
├── discord/DiscordSender.php - Envío a Discord API
├── src/DiscordSender.php - Versión alternativa Discord
├── src/TelegramSender.php - Envío a Telegram Bot API
└── telegram/TelegramSender.php - Versión alternativa Telegram

#### Conversores de Contenido:
├── discord/converters/HtmlToDiscordMarkdownConverter.php
├── src/HtmlToDiscordMarkdownConverter.php
└── src/HtmlToTelegramHtmlConverter.php

#### Tablas de Base de Datos Compartidas:
├── recipients - Destinatarios (con campo 'platform' para distinguir)
├── messages - Contenido de mensajes (compartido)
├── schedules - Programación de envíos (compartido)
├── sent_messages - Registro de mensajes enviados
├── translation_queue - Cola de traducciones
├── recurrent_messages - Plantillas de mensajes recurrentes
└── supported_languages - Configuración de idiomas

## 3. ARQUITECTURA DE COMPONENTES COMPARTIDOS

### Patrón Factory:
```php
// Creación de sender específico
$sender = SenderFactory::create($platform, $pdo);
$converter = ConverterFactory::create($platform);
```

### Flujo de Datos Compartido:
1. Usuario selecciona plataforma en create_message.php
2. message_handler.php guarda en DB con plataforma indicada
3. process_queue.php lee plataforma de DB
4. SenderFactory crea sender apropiado
5. ConverterFactory crea conversor apropiado
6. Se envía mensaje a plataforma específica

### Configuración Compartida:
├── Database: Misma conexión para ambas plataformas
├── Translation: Mismo servicio de traducción
├── Templates: Mismo sistema de plantillas recurrentes
├── Gallery: Misma galería de imágenes
├── Scheduling: Mismo sistema de programación
└── Activity: Mismo sistema de registro de actividad

## 4. DIFERENCIACIÓN POR PLATAFORMA

### En Base de Datos:
├── Campo 'platform' en tabla recipients ('discord' | 'telegram')
├── Platform-specific tokens en config.php
├── IDs de plataforma en platform_id
└── Chat modes específicos por plataforma

### En Código:
├── Directorios separados: /discord/ y /telegram/
├── Senders específicos por plataforma
├── Conversores específicos por formato
├── Webhooks específicos por plataforma
└── Commands específicos por plataforma

## 5. BENEFICIOS DE ESTA ARQUITECTURA

✅ Reutilización máxima de código entre plataformas
✅ Mantenimiento centralizado de lógica común
✅ Base de datos unificada para reporting
✅ Sistema de traducción compartido
✅ Interfaz web unificada para administración
✅ Sistema de programación compartido
✅ Logging centralizado
✅ Sistema de plantillas compartido

## 6. PATRONES DE DISEÑO IMPLEMENTADOS

🏗️ Factory Pattern - Para senders y converters
🏗️ Strategy Pattern - Para manejo de plataformas
🏗️ Singleton Pattern - Para conexión DB
🏗️ Observer Pattern - Para logging
🏗️ Template Method - Para flujo de envío

Esta arquitectura permite añadir nuevas plataformas fácilmente mediante la creación
de nuevos senders y converters, mientras se mantiene toda la lógica de negocio
compartida entre ambas plataformas actuales.