- Reservas: campos opcionales start_time/end_time (migración 011, schema natur_reservas) + toggle en el modal y detección de solapamiento por horario cuando ambas reservas los tienen definidos. Permite encajar varios eventos el mismo día. - Calendario mensual y anual ahora empiezan en lunes; vista móvil incluida. - Celdas con varios eventos el mismo día se dividen en franjas horizontales mostrando el horario; las reservas multi-día siguen ocupando la celda completa. - Modal: reset de campos vacíos (client_name, fechas, factura) para evitar que el nombre de la última reserva se filtre al crear una nueva. - Emails: las modificaciones solo disparan correo cuando cambian fechas u horas; el correo a Teneriffa pasa a formato reducido (solo fechas + propiedad) mientras que Natur sigue recibiendo el detalle completo. Mantenimiento sin cambios. - CLAUDE.md con guía operativa (schema natur_reservas, stack, convenciones). - Scripts de preview/envío de emails para pruebas. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
72 lines
2.6 KiB
Markdown
72 lines
2.6 KiB
Markdown
# CLAUDE.md — Naturcalabacera App Reservas
|
|
|
|
Guía operativa para agentes de Claude Code trabajando en este repo. Lee este archivo antes de tocar código o sugerir SQL.
|
|
|
|
---
|
|
|
|
## 1. Base de datos (Supabase) — CRÍTICO
|
|
|
|
La instancia de Supabase es **compartida** entre varios proyectos. Hay dos schemas:
|
|
|
|
- `public` → **otro proyecto, NO tocar**.
|
|
- `natur_reservas` → este proyecto.
|
|
|
|
> **Toda sentencia SQL debe cualificar el schema explícitamente**: `natur_reservas.reservations`, `natur_reservas.contracts`, etc.
|
|
> Nunca escribir `reservations` a secas en migraciones, queries ad-hoc, RLS, triggers, vistas o funciones. Aplica también al SQL Editor del dashboard.
|
|
|
|
### Ejemplo correcto
|
|
|
|
```sql
|
|
ALTER TABLE natur_reservas.reservations
|
|
ADD COLUMN IF NOT EXISTS start_time TIME;
|
|
```
|
|
|
|
### Migraciones
|
|
|
|
Viven en `supabase/migrations/NNN_*.sql`. Se aplican con `supabase db push` o pegando el SQL en el dashboard. **Antes de añadir una nueva**, revisar las anteriores y replicar la convención de cualificar con `natur_reservas.`.
|
|
|
|
---
|
|
|
|
## 2. Stack y estructura
|
|
|
|
Monorepo pnpm con workspaces:
|
|
|
|
- `apps/web` — Frontend React + TypeScript + Vite + Tailwind. Vista principal: calendario de reservas (mensual + anual).
|
|
- `apps/api` — Backend Express. Webhooks (n8n relay para correos), jobs.
|
|
- `packages/shared` — Tipos (`Reservation`, `Property`, etc.) y utilidades (`PROPERTY_CONFIG`, pricing).
|
|
|
|
Comandos raíz:
|
|
|
|
```bash
|
|
pnpm install
|
|
pnpm dev:web # frontend (http://localhost:5173)
|
|
pnpm dev:api # API
|
|
pnpm build # build web + api
|
|
pnpm lint
|
|
pnpm test # tests del paquete shared
|
|
```
|
|
|
|
---
|
|
|
|
## 3. Dominio
|
|
|
|
- 2 propiedades: **Los Dragos** (`los_dragos`) y **La Esquinita** (`la_esquinita`).
|
|
- 2 orígenes de reserva: **Teneriffa2000** (alquiler estándar) y **Naturcalabacera** (vacacional + eventos).
|
|
- Reservas Naturcalabacera pueden marcarse `is_event = true` (boda, cumpleaños, etc.) con su propio cálculo de canon (precio base por noche + extra por pax sobre `includedPersons`, tarifa por año, IGIC).
|
|
- Horarios opcionales `start_time` / `end_time` (cualquier reserva, cualquier origen): cuando ambas reservas en conflicto los tienen, el solapamiento se calcula a nivel de momento (fecha + hora), no solo de fecha. Permite encajar varios eventos el mismo día.
|
|
|
|
---
|
|
|
|
## 4. Despliegue
|
|
|
|
Gitea + Dokploy en `72.62.155.93`. URLs con `traefik.me` (HTTP). Dockerfile por app.
|
|
|
|
---
|
|
|
|
## 5. Convenciones del repo
|
|
|
|
- Sin commits sin permiso explícito del usuario.
|
|
- Calendario empieza en **lunes** (`weekStartsOn: 1`) en todas las vistas.
|
|
- Comentarios mínimos: solo cuando el "por qué" no es obvio del código.
|
|
- Idioma de interfaz: español. Identificadores en inglés.
|