# Correcciones Recientes - Enero 2026 **Fecha de actualización: Enero 18, 2026** --- ## 📋 Resumen Este documento documenta las correcciones técnicas recientes implementadas en AnchorOS para resolver problemas críticos que afectaban el sistema de booking y disponibilidad. --- ## 🗓️ Corrección 1: Desfase del Calendario ### Problema El componente `DatePicker` del sistema de booking mostraba los días desalineados con sus días de la semana correspondientes. **Síntoma:** - Enero 1, 2026 aparecía como **Lunes** en lugar de **Jueves** (día correcto) - Todos los días del mes se desplazaban incorrectamente - La grid del calendario no calculaba el offset del primer día ### Causa Raíz El componente `DatePicker` generaba los días del mes usando `eachDayOfInterval()` pero no calculaba el desplazamiento (offset) necesario para alinearlos con los encabezados de días de la semana. ```typescript // ❌ CÓDIGO INCORRECTO ANTERIOR const days = eachDayOfInterval({ start: startOfMonth(currentMonth), end: endOfMonth(currentMonth) }) // Los días se colocaban directamente sin padding // 1 2 3 4 5 6 7 8 ... (sin importar el día de la semana) ``` ### Solución Implementada 1. **Calcular el offset** del primer día del mes usando `getDay()`: ```typescript const firstDayOfMonth = startOfMonth(currentMonth) const dayOfWeek = firstDayOfMonth.getDay() // 0=Domingo, 1=Lunes, ..., 6=Sábado ``` 2. **Ajustar para semana que empieza en Lunes**: ```typescript // Si getDay() = 0 (Domingo), offset = 6 // Si getDay() = 1-6 (Lunes-Sábado), offset = getDay() - 1 const offset = dayOfWeek === 0 ? 6 : dayOfWeek - 1 ``` 3. **Agregar celdas vacías** al inicio de la grid: ```typescript const paddingDays = Array.from({ length: offset }, (_, i) => ({ day: null, key: `padding-${i}` })) const calendarDays = days.map((date, i) => ({ day: date, key: `day-${i}` })) const allDays = [...paddingDays, ...calendarDays] ``` ### Ejemplo Visual **Antes (INCORRECTO):** ``` L M X J V S D 1 2 3 4 5 6 7 <-- 1 de enero en Lunes (ERROR) 8 9 10 11 12 13 14 ``` **Después (CORRECTO):** ``` L M X J V S D _ _ _ 1 2 3 4 <-- 1 de enero en Jueves (CORRECTO) 5 6 7 8 9 10 11 ``` ### Archivos Modificados - `components/booking/date-picker.tsx` - Cálculo de offset y padding cells ### Commit - `dbac763` - fix: Correct calendar day offset in DatePicker component --- ## ⏰ Corrección 2: Horarios Disponibles Solo Muestran 22:00-23:00 ### Problema El sistema de disponibilidad (`/api/availability/time-slots`) solo devolvía horarios de 22:00 a 23:00 como disponibles, en lugar de los horarios normales del salón (10:00-19:00). **Síntoma:** - Al seleccionar un servicio y fecha, solo aparecían slots de 22:00 y 23:00 - Los horarios de negocio configurados no se respetaban - Los clientes no podían reservar en horarios normales del día ### Causas Raíz 1. **Horarios Incorrectos en Base de Datos:** - Los `business_hours` de las ubicaciones estaban configurados con horas incorrectas - Probablemente tenían 22:00-23:00 en lugar de 10:00-19:00 2. **Conversión de Timezone Defectuosa:** - La función `get_detailed_availability` usaba concatenación de strings para construir timestamps - Esto causaba problemas de conversión de timezone - Los timestamps no se construían correctamente con AT TIME ZONE ### Soluciones Implementadas #### Migración 1: Corregir Horarios por Defecto ```sql UPDATE locations SET business_hours = '{ "monday": {"open": "10:00", "close": "19:00", "is_closed": false}, "tuesday": {"open": "10:00", "close": "19:00", "is_closed": false}, "wednesday": {"open": "10:00", "close": "19:00", "is_closed": false}, "thursday": {"open": "10:00", "close": "19:00", "is_closed": false}, "friday": {"open": "10:00", "close": "19:00", "is_closed": false}, "saturday": {"open": "10:00", "close": "18:00", "is_closed": false}, "sunday": {"is_closed": true} }'::jsonb WHERE business_hours IS NULL OR business_hours = '{}'::jsonb; ``` #### Migración 2: Mejorar Función de Disponibilidad ```sql -- Usar make_timestamp() en lugar de concatenación de strings v_slot_start := make_timestamp( EXTRACT(YEAR FROM p_date)::INTEGER, EXTRACT(MONTH FROM p_date)::INTEGER, EXTRACT(DAY FROM p_date)::INTEGER, EXTRACT(HOUR FROM v_start_time)::INTEGER, EXTRACT(MINUTE FROM v_start_time)::INTEGER, 0 )::TIMESTAMPTZ AT TIME ZONE v_location_timezone; v_slot_end := make_timestamp( EXTRACT(YEAR FROM p_date)::INTEGER, EXTRACT(MONTH FROM p_date)::INTEGER, EXTRACT(DAY FROM p_date)::INTEGER, EXTRACT(HOUR FROM v_end_time)::INTEGER, EXTRACT(MINUTE FROM v_end_time)::INTEGER, 0 )::TIMESTAMPTZ AT TIME ZONE v_location_timezone; ``` ### Archivos Nuevos/Modificados - `supabase/migrations/20260118080000_fix_business_hours_default.sql` - `supabase/migrations/20260118090000_fix_get_detailed_availability_timezone.sql` ### Commits - `35d5cd0` - fix: Correct calendar offset and fix business hours showing only 22:00-23:00 --- ## 📄 Corrección 3: Página de Test Links ### Nueva Funcionalidad Se creó una página centralizada `/testlinks` con directorio completo de todas las páginas y API endpoints del proyecto. ### Características 1. **Páginas del Proyecto (21 páginas implementadas):** - `anchor23.mx` - Frontend institucional (8 páginas) - `booking.anchor23.mx` - The Boutique (7 páginas) - `aperture.anchor23.mx` - Dashboard administrativo (3 páginas) - Otros: kiosk, hq, enrollment 2. **API Endpoints (40+ endpoints implementados):** - APIs Públicas (services, locations, customers, availability, bookings) - Kiosk APIs (authenticate, resources, bookings, walkin) - Aperture APIs (dashboard, stats, calendar, staff, resources, payroll, POS) - FASE 5 - Clientes y Fidelización (clients, loyalty) - FASE 6 - Pagos y Protección (webhooks, cron, check-in, finance) 3. **Features de la Página:** - Indicadores de método HTTP (GET, POST, PUT, DELETE) con colores - Badges para identificar FASE 5 y FASE 6 - Grid layout responsive con efectos hover - Diseño con gradientes y cards modernos - Información sobre parámetros dinámicos (LOCATION_ID, CRON_SECRET) ### Archivos Nuevos - `app/testlinks/page.tsx` - 287 líneas de HTML/TypeScript renderizado ### Commits - `09180ff` - feat: Add testlinks page and update README with directory --- ## 📊 Impacto del Proyecto ### Progreso Global - **FASE 3**: 70% → 100% ✅ COMPLETADA - **FASE 5**: 0% → 100% ✅ COMPLETADA - **FASE 6**: 0% → 100% ✅ COMPLETADA ### APIs Nuevas Implementadas - **FASE 5**: 7 APIs para clientes y lealtad - **FASE 6**: 9 APIs para pagos y finanzas ### Migraciones Nuevas - 20260118050000 - Clients & Loyalty System - 20260118060000 - Stripe Webhooks & No-Show Logic - 20260118070000 - Financial Reporting & Expenses - 20260118080000 - Fix Business Hours Default - 20260118090000 - Fix Get Detailed Availability Timezone --- ## 🚀 Cómo Aplicar los Cambios ### Para Desarrolladores ```bash # Aplicar migraciones SQL supabase db push # Verificar migraciones aplicadas supabase migration list ``` ### Para Producción ```bash # Las migraciones se aplican automáticamente al: # 1. Reiniciar el servidor de desarrollo # 2. Desplegar a producción (ver docs/DEPLOYMENT_README.md) ``` --- ## ✅ Validación ### Validación de Calendario - ✅ Enero 1, 2026 ahora muestra correctamente como Jueves - ✅ Enero 18, 2026 (Domingo) se muestra correctamente como Domingo - ✅ Todos los meses se alinean correctamente con sus días de la semana ### Validación de Horarios - ✅ Slots de disponibilidad ahora muestran horarios normales (10:00-19:00) - ✅ Lunes a Viernes: 10:00-19:00 - ✅ Sábado: 10:00-18:00 - ✅ Domingo: Cerrado (sin slots) ### Validación de Test Links - ✅ Página `/testlinks` accesible y funcional - ✅ Todos los enlaces a páginas funcionan correctamente - ✅ Todos los enlaces a APIs documentados - ✅ Badges de fase identifican FASE 5 y FASE 6 --- ## 📝 Notas Importantes 1. **Backward Compatibility:** - Los cambios son backward-compatible con datos existentes - Las migraciones no borran datos existentes 2. **Testing:** - Probar el calendario con fechas de diferentes meses y años - Probar la disponibilidad con diferentes servicios y ubicaciones - Verificar que los horarios coinciden con los configurados en business_hours 3. **Documentation:** - Actualizar `docs/API.md` con información de las nuevas APIs - Actualizar `docs/APERATURE_SPECS.md` con especificaciones técnicas - Actualizar `README.md` con progreso del proyecto --- ## 🔗 Referencias - **TASKS.md** - Plan de ejecución por fases y estado actual - **README.md** - Guía técnica y operativa del repositorio - **docs/API.md** - Documentación completa de APIs y endpoints - **docs/APERATURE_SPECS.md** - Especificaciones técnicas de Aperture --- **Última actualización:** Enero 18, 2026 **Versión:** 1.0.0