Lunes: montar el repo y mirar los datos

## Lunes, 11:00. Los extractos ya están en la carpeta

Ya sabes qué vas a hacer y por qué importa. Ahora toca mirar los datos de verdad. Rosalía te ha dejado en la carpeta compartida tres ficheros CSV, y antes de calcular nada con ellos hay una regla que se aprende pronto y se agradece siempre: no te fíes de lo que crees que hay dentro de un fichero hasta que lo abras y lo mires. Un extracto puede traer más filas de las que esperas, columnas en un tipo raro, o la misma magnitud escrita de mil formas. El lunes de un proyecto es para eso: para dibujar el mapa del terreno antes de empezar a construir.

Estos son los tres ficheros, y conviene entender qué representa cada uno porque van a cruzarse toda la semana. El maestro de clientes tiene una fila por punto de suministro (por CUPS): su tarifa contratada, la potencia, la provincia, la fecha de alta y si respondió a una campaña anterior. Las lecturas horarias son el oro y el problema a la vez: una fila por cada hora de cada cliente, con los kWh que consumió esa hora. Y el catálogo de tarifas tiene una fila por tarifa, con su nombre y su tipo. Fíjate en la asimetría: del maestro hay una fila por cliente, pero de las lecturas hay cientos por cliente. Esa diferencia de granularidad es la primera cosa que tienes que entender hoy.

## La idea que ordena toda la semana: de muchas lecturas a una fila por cliente

K-Means agrupa clientes, no horas sueltas. Y los datos que tienes no son clientes: son lecturas, cientos por cliente. Si metieras las lecturas tal cual al algoritmo, estarías agrupando "momentos de consumo" (la hora de las 3 de la mañana de un cliente con la de las 8 de la tarde de otro), que no significa nada. El trabajo central del preprocesado de este caso —y lo que harás mañana— es resumir todas las lecturas de un cliente en una sola fila que capture su patrón: cuánto consume, en qué franjas, cuánto pico tiene su curva. Hoy no se agrega todavía; hoy se entiende qué forma hay que construir y por qué una fila por cliente.

## El esqueleto del proyecto

Antes de cargar un solo CSV, monta la estructura del repositorio que vas a ir llenando toda la semana. No es burocracia: un proyecto ordenado desde el primer día es la diferencia entre algo que puedes subir a GitHub y enseñar, y una carpeta con quince scripts sueltos que no entiende nadie. La estructura estándar de un proyecto de datos separa el código (src/), las consultas (sql/), los datos (datos/) y los dos ficheros que explican el proyecto (README.md y requirements.txt).

1segmentos-luzclara/
2├── README.md            ← el one-pager: hallazgos + recomendación (viernes)
3├── requirements.txt     ← pandas, numpy, scikit-learn, matplotlib, duckdb
4├── datos/               ← los CSV del caso (clientes, lecturas, tarifas)
5├── sql/                 ← consultas de agregación (lunes y jueves)
6└── src/
7    ├── 01_explorar.py   ← carga y primer vistazo (HOY)
8    ├── 02_features.py   ← limpieza + agregación a features por cliente (martes)
9    ├── 03_segmentar.py  ← K-Means + codo + silueta, k=4 (miércoles)
10    ├── 04_evaluar.py    ← sin escalar vs Pipeline con escalado, el insight (jueves)
11    └── 05_perfiles.py   ← asignación cliente→segmento y fichas (viernes)

Lo que escribes hoy es src/01_explorar.py: carga los tres CSV, mira su forma y empieza a oler la suciedad. No limpies nada todavía (eso es mañana). Hoy solo quieres saber qué hay y hacerte una idea del tamaño del problema.