# Project.md — SOLO POR HOY AUDIOS

## 1. Descripción general

**SOLO POR HOY AUDIOS** es una aplicación web moderna, independiente (standalone), construida con **HTML, JavaScript y Bootstrap (CSS)**, sin backend ni base de datos. Todo el contenido (calendario y reproductor) funciona del lado del cliente.

La aplicación permite al usuario navegar un calendario anual y, al seleccionar una fecha, escuchar la meditación/audio correspondiente a ese día ("Solo por hoy"), cuyo archivo de audio ya existe en el mismo directorio del proyecto.

---

## 2. Objetivo funcional

1. Mostrar un **calendario estándar completo** (los 12 meses, con sus días).
2. **No mostrar el año** (la app es agnóstica al año, es un calendario "perpetuo" de referencia diaria).
3. **No mostrar los días de la semana** (no hay lunes, martes, etc., ni su cálculo).
4. **No considerar años bisiestos**: febrero se muestra siempre con **28 días** fijos.
5. Al hacer **clic/tap en un día**, se abre un **reproductor de audio** que reproduce el archivo MP3 correspondiente a esa fecha.

---

## 3. Estructura de archivos

```
/solo-por-hoy-audios
│
├── index.html
├── /css
│   └── styles.css
├── /js
│   └── app.js
├── /audios
│   ├── 01-01.mp3
│   ├── 01-02.mp3
│   ├── ...
│   ├── 12-30.mp3
│   └── 12-31.mp3
└── Project.md
```

> Los archivos de audio siguen el formato **`MM-DD.mp3`** (mes de 2 dígitos, guion, día de 2 dígitos), ubicados en la carpeta `/audios` (o en el mismo directorio raíz, según se defina en `app.js`).
> Ejemplos: `01-01.mp3` (1 de enero), `03-15.mp3` (15 de marzo), `12-25.mp3` (25 de diciembre).

---

## 4. Especificación del calendario

### 4.1 Meses y días

- Se listan los 12 meses en español: Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto, Septiembre, Octubre, Noviembre, Diciembre.
- Cantidad de días fija por mes (sin años bisiestos):

| Mes | Días |
|---|---|
| Enero | 31 |
| Febrero | 28 |
| Marzo | 31 |
| Abril | 30 |
| Mayo | 31 |
| Junio | 30 |
| Julio | 31 |
| Agosto | 31 |
| Septiembre | 30 |
| Octubre | 31 |
| Noviembre | 30 |
| Diciembre | 31 |

### 4.2 Elementos que NO deben mostrarse

- ❌ El año (ni en el encabezado ni en ningún selector).
- ❌ Los nombres de los días de la semana (no hay fila de "Lun, Mar, Mié...").
- ❌ Cualquier cálculo de día de la semana (no usar `Date.getDay()` para alinear el grid).

### 4.3 Layout sugerido

- Un selector/navegación de mes (por ejemplo, tabs, acordeón o dropdown Bootstrap) para elegir el mes activo.
- Dentro de cada mes, una **grilla simple de números de día** (1, 2, 3... hasta el máximo del mes), sin alinear por día de semana — puede ser un grid uniforme (ej. 7 columnas solo por estética, no por significado de semana) o una grilla libre (ej. `row-cols-7` de Bootstrap usada únicamente como distribución visual).
- Cada día es un botón/celda clickeable (`<button>` o `<div role="button">`), con estilo Bootstrap (`btn`, `card`, etc.).

---

## 5. Especificación del reproductor de audio

### 5.1 Activación

- Al hacer clic en un día del calendario:
  1. Se construye el nombre de archivo con el formato `MM-DD.mp3` (mes y día del botón clickeado, ambos con 2 dígitos, con cero a la izquierda si corresponde).
  2. Se abre el reproductor (modal de Bootstrap o panel embebido) cargando ese archivo.
  3. Si el archivo no existe o falla la carga, se debe mostrar un mensaje de error amigable (ej. "Audio no disponible para esta fecha").

### 5.2 Controles requeridos

El reproductor debe incluir, como mínimo:

- ▶️ **Reproducir**
- ⏸️ **Pausar**
- ⏱️ **Barra de progreso / scrubbing** (desplazamiento temporal) — permitir al usuario arrastrar para adelantar o retroceder en el audio.
- Indicador de tiempo transcurrido / tiempo total (ej. `01:23 / 04:10`).
- (Opcional recomendado) Control de volumen y botón de cerrar el reproductor.

### 5.3 Implementación técnica sugerida

- Usar el elemento nativo `<audio>` de HTML5 controlado vía JavaScript (`play()`, `pause()`, `currentTime`, eventos `timeupdate`, `loadedmetadata`).
- Se puede usar el atributo `controls` nativo del navegador **o** construir controles personalizados con Bootstrap (botones + `input type="range"` para el scrubbing), según preferencia visual.
- El reproductor puede implementarse como un **modal de Bootstrap** (`.modal`) que se abre al seleccionar el día, o como un **panel fijo** (ej. tipo "mini player" anclado abajo de la pantalla).

---

## 6. Requisitos técnicos generales

- **HTML5** semántico.
- **Bootstrap** (vía CDN) para estilos, grid y componentes (modal, botones, cards).
- **JavaScript vanilla** (sin frameworks como React/Vue) — mantener la app liviana y autocontenida.
- Responsive: debe funcionar correctamente en escritorio y en dispositivos móviles.
- No requiere backend, servidor, ni base de datos: todo corre en el navegador (rutas de audio relativas).
- Compatibilidad con los navegadores modernos actuales.

---

## 7. Diseño responsive y experiencia tipo app móvil

La interfaz debe diseñarse con enfoque **mobile-first**, priorizando que la app se sienta y se vea como una **aplicación móvil moderna** (tipo app nativa), no como una página web tradicional adaptada.

### 7.1 Viewport y meta tags

- Incluir `<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">`.
- Agregar meta tags para "modo app" al agregar a pantalla de inicio (Add to Home Screen):
  - `<meta name="mobile-web-app-capable" content="yes">`
  - `<meta name="apple-mobile-web-app-capable" content="yes">`
  - `<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">`
  - `<meta name="theme-color" content="#...">` (color acorde a la paleta de la app).
- (Opcional recomendado) Agregar un `manifest.json` básico (nombre, ícono, `display: standalone`, `theme_color`, `background_color`) para permitir instalar la app como PWA, aunque no sea un requisito estricto del proyecto.

### 7.2 Layout mobile-first

- Diseñar primero para pantallas pequeñas (320–430px de ancho) y luego escalar hacia tablet/escritorio con los breakpoints de Bootstrap (`sm`, `md`, `lg`).
- Usar `container-fluid` con paddings laterales cómodos (no pegado a los bordes).
- El calendario debe adaptarse a una sola columna de mes por vez en mobile (ej. carrusel/tabs deslizables entre meses), evitando scroll horizontal no intencional.
- Los días del mes deben mostrarse en una grilla táctil (celdas grandes, mínimo **44x44px** de área de toque, según guías de accesibilidad táctil de iOS/Android).
- Evitar tablas HTML tradicionales para el grid de días; usar `div`/`button` con Flexbox o CSS Grid para mejor control responsive.

### 7.3 Look & feel "app moderna"

- Tipografía clara y grande, con buen contraste (ideal: fuente del sistema o una tipografía web moderna vía Google Fonts).
- Bordes redondeados (`border-radius` generoso), sombras suaves (`box-shadow` sutil) y espaciados amplios entre elementos, evitando la estética "web de formularios".
- Paleta de colores coherente y calmada (acorde a una app de bienestar/meditación diaria), con buen contraste en modo claro; opcionalmente soportar **modo oscuro** (`prefers-color-scheme: dark`).
- Transiciones y micro-animaciones suaves (hover/tap en los días, apertura del reproductor) usando `transition` de CSS, sin dependencias externas pesadas.
- Barra de navegación superior tipo "app bar" (fija/sticky), simple, con el título de la app y, si aplica, navegación entre meses.
- El reproductor de audio, en mobile, debe comportarse como un **mini-player estilo app nativa**: anclado en la parte inferior de la pantalla o como modal a pantalla completa (bottom sheet), con controles grandes y accesibles con el pulgar.

### 7.4 Interacción táctil

- Todos los elementos interactivos (días, botones del reproductor, barra de progreso) deben responder correctamente a eventos táctiles (`touch`), no solo a `click`/`hover` de mouse.
- Evitar el "zoom accidental" en doble tap sobre botones (usar `touch-action: manipulation` donde aplique).
- La barra de progreso (scrubbing) del audio debe ser fácilmente arrastrable con el dedo (`input type="range"` con suficiente altura táctil, o implementación custom con buen tamaño de "thumb").
- Evitar elementos con scroll horizontal accidental; todo el contenido debe fluir verticalmente en mobile.

### 7.5 Rendimiento en mobile

- Minimizar el peso de la página (Bootstrap vía CDN, sin librerías adicionales innecesarias).
- Los archivos de audio deben cargarse solo al seleccionar el día (lazy loading), no precargar todos los MP3 al iniciar la app.
- Verificar que la app cargue y sea usable en conexiones móviles estándar (3G/4G) sin bloqueos ni layouts rotos mientras cargan los recursos.

---

## 8. Criterios de aceptación

- [ ] El calendario muestra los 12 meses con la cantidad correcta de días (febrero = 28, sin bisiesto).
- [ ] No se muestra el año en ninguna parte de la interfaz.
- [ ] No se muestran nombres ni abreviaturas de días de la semana.
- [ ] Al hacer clic en un día, se abre el reproductor y carga el MP3 `MM-DD.mp3` correspondiente.
- [ ] El reproductor permite reproducir, pausar y desplazarse (scrub) dentro del audio.
- [ ] La interfaz es clara, responsive y usa componentes Bootstrap de forma consistente.
- [ ] Manejo correcto de errores si el archivo de audio no existe.
- [ ] La interfaz se ve y se siente como una app móvil moderna (bordes redondeados, espaciados amplios, mini-player anclado, buen tamaño de toque).
- [ ] Todos los elementos interactivos funcionan correctamente con eventos táctiles en dispositivos reales (no solo con mouse en escritorio).

---

## 9. Notas para Cursor

- Generar primero `index.html` con la estructura base (navbar simple con título "Solo por Hoy Audios", contenedor del calendario, modal del reproductor).
- Luego `js/app.js` con:
  - Array/objeto de meses y su cantidad de días fija.
  - Función para renderizar el calendario dinámicamente.
  - Función `formatearNombreArchivo(mes, dia)` → retorna `"MM-DD.mp3"`.
  - Lógica del reproductor de audio (play/pause/seek) enlazada al `<audio>`.
- Usar clases utilitarias de Bootstrap para minimizar CSS custom; `css/styles.css` solo para ajustes puntuales, priorizando siempre el enfoque mobile-first (estilos base para mobile, luego media queries/breakpoints para pantallas mayores).
- Probar el layout en anchos típicos de mobile (ej. 375px, 390px, 414px) antes de validar en escritorio.