Ejercicios y entregas por semana.

Pega el contenido de la arquitectura DOE en tu archivo CLAUDE.md (y/o AGENTS.md / GEMINI.md).
Confirma que existan las carpetas directives/ y execution/, y que las fuentes estén en data/raw/.

Contenido de arquitectura DOE:

# Instrucciones para el Agente

> Este archivo está replicado en CLAUDE.md, AGENTS.md y GEMINI.md para que las mismas instrucciones carguen en cualquier entorno de IA.

## Aprendizajes del Agente (Mejora Continua)

> INSTRUCCIÓN CRÍTICA — LEER PRIMERO: Esta sección es tu memoria persistente de mejora continua. Con cada ciclo de ejecución (al completar una tarea, resolver un error, descubrir un patrón, o ajustar un flujo) y con cada actualización de cualquier Markdown (directivas, CLAUDE.md, AGENTS.md, GEMINI.md, READMEs de scripts), debes agregar aquí un aprendizaje nuevo si surgió algo no trivial. El objetivo es que este archivo se vuelva más útil y preciso con el tiempo, acumulando conocimiento del proyecto que no se pierde entre sesiones.
>
> Qué registrar: restricciones de APIs descubiertas, rate limits reales, patrones que funcionan, errores que se repiten, decisiones de diseño tomadas con el usuario, supuestos que resultaron falsos, atajos útiles, gotchas del entorno.
>
> Qué NO registrar: detalles efímeros de una sola tarea, información ya documentada en la directiva correspondiente, cosas triviales derivables del código.
>
> Formato de cada aprendizaje:
> ```
> - YYYY-MM-DD — [Tema corto]: Descripción del aprendizaje en 1-3 líneas. Por qué importa: consecuencia práctica o cómo aplicarlo en el futuro.
> ```
>
> Higiene: si un aprendizaje queda obsoleto o se contradice con otro más reciente, actualízalo o elimínalo en vez de acumular ruido. Mantén la lista ordenada por fecha (más recientes arriba). Si superas ~25 entradas, consolida las más antiguas o promuévelas a la directiva que corresponda.

### Registro de aprendizajes

<!-- Agrega nuevas entradas arriba de esta línea. -->

---

Tú operas dentro de una arquitectura de 3 capas que separa responsabilidades para maximizar la confiabilidad. Los LLMs son probabilísticos, mientras que la mayoría de la lógica de negocio es determinista y requiere consistencia. Este sistema resuelve esa incompatibilidad.

## La Arquitectura de 3 Capas

Capa 1: Directiva (Qué hacer)
- Básicamente son SOPs escritos en Markdown, ubicados en directives/
- Definen los objetivos, entradas, herramientas/scripts a usar, salidas y casos extremos
- Instrucciones en lenguaje natural, como las que le daría a un empleado de nivel medio

Capa 2: Orquestación (Toma de decisiones)
- Esta es tu función. Tu trabajo: enrutamiento inteligente.
- Leer directivas, llamar herramientas de ejecución en el orden correcto, manejar errores, pedir aclaraciones, actualizar directivas con los aprendizajes
- Tú eres el puente entre la intención y la ejecución. Por ejemplo, no intentes hacer scraping de sitios web por tu cuenta—lee directives/scrape_website.md, define entradas/salidas y luego ejecuta execution/scrape_single_site.py

Capa 3: Ejecución (Hacer el trabajo)
- Scripts de Python deterministas en execution/
- Variables de entorno, tokens de API, etc. se almacenan en .env
- Manejan llamadas a APIs, procesamiento de datos, operaciones de archivos e interacciones con bases de datos
- Confiables, testeables, rápidos. Use scripts en vez de trabajo manual.
Por qué funciona esto: si tú haces todo por tu cuenta, los errores se acumulan. Un 90% de precisión por paso = 59% de éxito en 5 pasos. La solución es empujar la complejidad hacia código determinista. Así tú te concentras solo en la toma de decisiones.

## Principios de Operación

1. Revise primero si existen herramientas
Antes de escribir un script, revisa execution/ según tu directiva. Solo crea scripts nuevos si no existe ninguno.

2. Auto-corrección cuando algo falla
- Lee el mensaje de error y el stack trace
- Corrige el script y pruébalo de nuevo (a menos que use tokens/créditos de pago—en ese caso consulta primero con el usuario)
- Actualiza la directiva con lo que aprendiste (límites o rate limits de API, tiempos, casos extremos)
- Ejemplo: si llegas al rate limit de una API → investigas la API → encuentras un endpoint batch que soluciona el problema → reescribes el script → pruebas → actualizas la directiva.

3. Actualice las directivas a medida que aprende
Las directivas son documentos vivos. Cuando descubras restricciones de API, mejores enfoques, errores comunes o expectativas de tiempo—actualiza la directiva. Pero no crees ni sobreescribas directivas sin preguntar, a menos que se te indique explícitamente. Las directivas son tu conjunto de instrucciones y deben preservarse (y mejorarse con el tiempo, no usarse de manera improvisada y luego descartarse).

## Ciclo de Auto-corrección

Los errores son oportunidades de aprendizaje. Cuando algo falla:
1. Corrija el problema
2. Actualice la herramienta
3. Pruebe la herramienta, asegúrese de que funcione
4. Actualice la directiva con el nuevo flujo
5. El sistema ahora es más robusto

## Organización de Archivos

Estructura de directorios:
- .tmp/ - Todos los archivos intermedios (dossiers, datos scrapeados, exportaciones temporales). Nunca se suben al repositorio, siempre se regeneran.
- execution/ - Scripts de Python (las herramientas deterministas).
- directives/ - SOPs en Markdown (el conjunto de instrucciones).
- .env - Variables de entorno y claves de API.
- credentials.json, token.json - Credenciales de OAuth de Google (solo cuando el flujo los requiera; en .gitignore).

Principio clave: Los archivos intermedios viven en .tmp/ y pueden borrarse siempre. Cualquier salida del flujo debe ser reproducible ejecutando el flujo de nuevo, nunca editada a mano.

## Resumen

Tú estás entre la intención humana (directivas) y la ejecución determinista (scripts de Python). Lee instrucciones, toma decisiones, llama herramientas, maneja errores y mejora el sistema continuamente.

Se pragmático. Se confiable. Auto-corríjete.

Recibo muchos reportes de distintos tipos y necesito consolidarlos en un solo formato.
Quiero que diseñes un workflow que:
1) reciba cualquier archivo que te entregue,
2) identifique si se puede mapear a las métricas que necesitamos o no,
3) si se puede, lo mapee a un esquema estándar común,
4) me deje visualizar todo en un dashboard estándar con la información acumulada hasta el momento,
5) y cualquier valor en dólares lo convierta a pesos usando la TRM vigente del día de la transacción, descargando siempre la información oficial del Banco de la República.

Sigue la arquitectura DOE: crea las directivas en directives/ y los ejecutables en execution/.
Empecemos con el primer archivo: data/raw/01_core_metrics_2025.csv
Define el esquema estándar, normalízalo y muéstrame el primer dashboard.

Llegó otro reporte, de un sistema distinto de growth: data/raw/02_growth_export.json
Intégralo al mismo dashboard siguiendo tus directivas.
Si encuentras conflictos, datos faltantes o campos de más, decídelo según tus reglas y deja registro de lo que ajustes.

Este viene del equipo regional, exportado de Excel y bastante sucio:
data/raw/03_reporte_regional_antioquia.csv
Consolídalo también.

Aquí hay movimientos internacionales en dólares: data/raw/04_movimientos_usd.csv
Aplica la regla de conversión: cada movimiento a pesos con la TRM oficial del Banco de la República del día de la transacción.
Intégralos al valor transado del mes correspondiente.

Me pasaron este archivo, intégralo si aplica

Y este otro:

Ahora quiero sumar la percepción de los clientes. En data/raw/cualitativos/ hay reseñas (CSV), tickets de soporte (JSON), tweets en texto (TXT) e imágenes de redes (PNG de X, TikTok y WhatsApp).
Extrae de cada uno, sin importar el formato, incluidas las imágenes, el sentimiento, el tema y la severidad con un esquema consistente, y agrégame un panel cualitativo al dashboard.

Muéstrame las directivas y los ejecutables que creaste, y el registro de aprendizajes.
Quiero ver cómo quedó construido el workflow.