# 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.