ParamManagerScripts/backend/script_groups/EmailCrono/.doc/MemoriaDeEvolucion.md

Memoria de Evolución - Procesador de Emails a Cronología

Descripcion de los scripts Procesador de Emails a Cronología

Este script procesa archivos de correo electrónico (.eml) para extraer su contenido, gestionar adjuntos y generar un archivo Markdown que presenta los mensajes en orden cronológico inverso.

Lógica Principal:

Beautify: Carga reglas de embellecimiento de texto desde config/beautify_rules.json para limpiar el contenido de los correos. Descubrimiento: Busca todos los archivos .eml en el directorio de trabajo configurado.

Procesamiento Individual: Itera sobre cada archivo .eml encontrado. Utiliza utils.email_parser.procesar_eml para extraer metadatos (fecha, asunto, remitente, destinatarios), contenido del cuerpo y guardar los archivos adjuntos en la carpeta especificada. Calcula un hash para cada mensaje para detectar duplicados.

Si un mensaje es nuevo (no duplicado):

Aplica las reglas de BeautifyProcessor al contenido del cuerpo. Añade el mensaje procesado a una lista.

Ordenación: Ordena la lista de mensajes únicos por fecha, del más reciente al más antiguo.

Generación de Índice: Crea una sección de índice en formato Markdown con enlaces internos a cada mensaje. Salida Markdown: Escribe el índice seguido del contenido formateado en Markdown de cada mensaje en el archivo de salida configurado (ej. cronologia.md).

2025-08-08 — Inversión de directorios (entrada/salida)

• Decisión: Alinear con la guía backend_setup.md para que:
  • working_directory sea el directorio de salida (resultado), donde se escribe cronologia.md y se guardan los adjuntos.
  • level3.input_directory sea el directorio de entrada donde se leen los .eml.
• Cambios:
  • esquema_work.json: se renombra output_directory → input_directory y se actualizan title/description.
  • x1.py:
    • Lee level3.input_directory como entrada.
    • Escribe cronologia_file y attachments_dir dentro de working_directory.
    • Crea directorios de salida si no existen.
    • Se corrigen lints (E402 y líneas largas) sin alterar lógica.
• Impacto:
  • Los work_dir.json existentes deben actualizar la clave a input_directory.
  • No hay cambios en claves de level2 (cronologia_file, attachments_dir).

2025-08-08 — Manejo de imágenes (inline y adjuntas) y embebido en Markdown

• Decisión:
  • Capturar imágenes tanto adjuntas (attachment) como inline (inline/sin Content-Disposition).
  • Guardar las imágenes en el directorio de adjuntos configurado y además copiar a adjuntos/cronologia dentro del working_directory.
  • Incrustar en el Markdown enlaces de Obsidian con ruta absoluta al archivo copiado en adjuntos/cronologia usando la sintaxis de embed ![[...]] bajo una sección ### Imágenes por mensaje.
• Cambios:
  • utils/attachment_handler.py: nueva función guardar_imagen que genera nombres a partir de Content-ID o hash y evita colisiones por contenido; refactor de hashing de contenido.
  • utils/email_parser.py:
    • Se amplía la firma de procesar_eml/procesar_eml_interno para recibir dir_adjuntos_cronologia y copiar allí las imágenes.
    • Se manejan imágenes en partes attachment y inline, agregando su ruta absoluta copiada a mensaje.imagenes_cronologia.
  • models/mensaje_email.py: to_markdown() agrega sección ### Imágenes con ![[ruta_absoluta]] previo a ### Adjuntos.
  • x1.py: crea adjuntos/cronologia y pasa la ruta al parser.
• Impacto:
  • El .md resultante muestra las imágenes embebidas (Obsidian) desde rutas absolutas bajo .../adjuntos/cronologia/....
  • Se preserva el listado de adjuntos como enlaces [[archivo]].

2025-08-08 — Editor web para beautify_rules.json

• Decisión:
  • Crear un editor web simple (Flask) para visualizar/editar config/beautify_rules.json con CRUD básico y respaldo automático.
• Cambios:
  • x2.py: servidor Flask con endpoints /api/rules (GET/POST), /api/meta, /api/heartbeat y /_shutdown. Valida estructura de reglas (campos requeridos, action/type permitidos) y genera backup con timestamp antes de guardar. Implementa cierre limpio y auto-cierre por inactividad (latido del cliente cada 10s; timeout configurable vía INACTIVITY_TIMEOUT_SECONDS, por defecto 60s).
  • templates/index.html, static/app.js, static/style.css: interfaz para listar, reordenar por priority, agregar/eliminar reglas y editar campos. Incluye vista "Avanzado" con JSON crudo.
  • UI: botón "duplicar" regla; ayuda contextual en el modal que explica cada action y sus efectos.
• Impacto:
  • Edición segura de reglas con validación previa y backups incrementales.
  • El servidor del editor se cierra automáticamente si no hay navegador activo.
  • Facilita ajustar reglas sin tocar el archivo manualmente.

2025-08-08 — Mejora de persistencia de comentarios y UX de textareas

• Decisión:
  • Asegurar que los comentarios de las reglas (__comment) se persistan siempre al guardar, aun cuando el usuario edite el JSON crudo.
  • Mejorar la ergonomía visual inicial reduciendo la altura inicial de los campos "Comentario" y "Pattern" a 2 líneas, expandiéndose solo al escribir.
• Cambios:
  • static/app.js:
    • saveAll(): se fusiona el JSON avanzado si es válido, pero las rules provienen siempre del estado actual de la UI (state.rules). Así no se pierden los cambios de los textareas, incluyendo __comment.
    • ruleRow(): textarea de Comentario y Pattern pasan de rows=1 a rows=2 y se evita el auto-resize en el render inicial (solo se aplica al tipear).
• Impacto:
  • Los comentarios ya no se descartan al guardar incluso si el panel de JSON contiene modificaciones parciales o inválidas.
  • La lista de reglas es más compacta pero legible, con expansión progresiva al editar.