mirror of
https://github.com/marcogll/AnchorOS.git
synced 2026-03-15 22:24:34 +00:00
4707ddbd5a
Implementación completa de la Fase 1.1 y 1.2 del proyecto SalonOS: ## Cambios en Reglas de Negocio (PRD.md, AGENTS.md, TASKS.md) - Actualizado reset de invitaciones de mensual a semanal (Lunes 00:00 UTC) - Jerarquía de roles actualizada: Admin > Manager > Staff > Artist > Customer - Artistas (antes colaboradoras) ahora tienen rol 'artist' - Staff/Manager/Admin pueden ver PII de customers - Artist solo ve nombre y notas de customers (restricción de privacidad) ## Estructura del Proyecto (Next.js 14) - app/boutique/: Frontend de cliente - app/hq/: Dashboard administrativo - app/api/: API routes - components/: Componentes UI reutilizables (boutique, hq, shared) - lib/: Lógica de negocio (supabase, db, utils) - db/: Esquemas, migraciones y seeds - integrations/: Stripe, Google Calendar, WhatsApp - scripts/: Scripts de utilidad y automatización - docs/: Documentación del proyecto ## Esquema de Base de Datos (Supabase PostgreSQL) 8 tablas creadas: - locations: Ubicaciones con timezone - resources: Recursos físicos (estaciones, habitaciones, equipos) - staff: Personal con roles jerárquicos - services: Catálogo de servicios - customers: Información de clientes con tier (free/gold) - invitations: Sistema de invitaciones semanales - bookings: Sistema de reservas con short_id (6 caracteres) - audit_logs: Registro de auditoría automática 14 funciones creadas: - generate_short_id(): Generador de Short ID (6 chars, collision-safe) - generate_invitation_code(): Generador de códigos de invitación (10 chars) - reset_weekly_invitations_for_customer(): Reset individual de invitaciones - reset_all_weekly_invitations(): Reset masivo de invitaciones - validate_secondary_artist_role(): Validación de secondary_artist - log_audit(): Trigger de auditoría automática - get_current_user_role(): Obtener rol del usuario actual - is_staff_or_higher(): Verificar si es admin/manager/staff - is_artist(): Verificar si es artist - is_customer(): Verificar si es customer - is_admin(): Verificar si es admin - update_updated_at(): Actualizar timestamps - generate_booking_short_id(): Generar Short ID automáticamente - get_week_start(): Obtener inicio de semana 17+ triggers activos: - Auditores automáticos en tablas críticas - Timestamps updated_at en todas las tablas - Validación de secondary_artist (trigger en lugar de constraint) 20+ políticas RLS configuradas: - Restricción crítica: Artist no ve email/phone de customers - Jerarquía de roles: Admin > Manager > Staff > Artist > Customer - Políticas granulares por tipo de operación y rol 6 tipos ENUM: - user_role: admin, manager, staff, artist, customer - customer_tier: free, gold - booking_status: pending, confirmed, cancelled, completed, no_show - invitation_status: pending, used, expired - resource_type: station, room, equipment - audit_action: create, update, delete, reset_invitations, payment, status_change ## Scripts de Utilidad - check-connection.sh: Verificar conexión a Supabase - simple-verify.sh: Verificar migraciones instaladas - simple-seed.sh: Crear datos de prueba - create-auth-users.js: Crear usuarios de Auth en Supabase - verify-migration.sql: Script de verificación SQL completo - seed-data.sql: Script de seed de datos SQL completo ## Documentación - docs/STEP_BY_STEP_VERIFICATION.md: Guía paso a paso de verificación - docs/STEP_BY_STEP_AUTH_CONFIG.md: Guía paso a paso de configuración Auth - docs/POST_MIGRATION_SUCCESS.md: Guía post-migración - docs/MIGRATION_CORRECTION.md: Detalle de correcciones aplicadas - docs/QUICK_START_POST_MIGRATION.md: Guía rápida de referencia - docs/SUPABASE_DASHBOARD_MIGRATION.md: Guía de ejecución en Dashboard - docs/00_FULL_MIGRATION_FINAL_README.md: Guía de migración final - SIMPLE_GUIDE.md: Guía simple de inicio - FASE_1_STATUS.md: Estado de la Fase 1 ## Configuración - package.json: Dependencias y scripts de npm - tsconfig.json: Configuración TypeScript con paths aliases - next.config.js: Configuración Next.js - tailwind.config.ts: Tema personalizado con colores primary, secondary, gold - postcss.config.js: Configuración PostCSS - .gitignore: Archivos excluidos de git - .env.example: Template de variables de entorno ## Correcciones Aplicadas 1. Constraint de subquery en CHECK reemplazado por trigger de validación - PostgreSQL no permite subqueries en CHECK constraints - validate_secondary_artist_role() ahora es un trigger 2. Variable no declarada en loop - customer_record RECORD; añadido en bloque DECLARE ## Principios Implementados - UTC-first: Todos los timestamps se almacenan en UTC - Sistema Doble Capa: Validación Staff/Artist + Recurso físico - Reset semanal: Invitaciones se resetean cada Lunes 00:00 UTC - Idempotencia: Procesos de reset son idempotentes y auditados - Privacidad: Artist solo ve nombre y notas de customers - Auditoría: Todas las acciones críticas se registran automáticamente - Short ID: 6 caracteres alfanuméricos como referencia humana - UUID: Identificador primario interno ## Próximos Pasos - Ejecutar scripts de verificación y seed - Configurar Auth en Supabase Dashboard - Implementar Tarea 1.3: Short ID & Invitaciones (backend) - Implementar Tarea 1.4: CRM Base (endpoints CRUD)
203 lines
3.5 KiB
Markdown
203 lines
3.5 KiB
Markdown
# TASKS.md — Plan de Ejecución por Fases
|
|
|
|
Este documento define las tareas ejecutables del proyecto **SalonOS**, alineadas estrictamente con el PRD. Ninguna tarea puede introducir lógica no documentada.
|
|
|
|
---
|
|
|
|
## Convenciones
|
|
|
|
* Cada tarea produce artefactos verificables (código, migraciones, tests, documentación).
|
|
* Las reglas de negocio viven en backend.
|
|
* Todo automatismo debe ser auditable.
|
|
* Ningún agente redefine alcance.
|
|
|
|
---
|
|
|
|
## FASE 1 — Cimientos y CRM
|
|
|
|
### 1.1 Infraestructura Base
|
|
|
|
* Crear proyecto Supabase.
|
|
* Configurar Auth (Magic Links Email/SMS).
|
|
* Definir roles: Admin / Manager / Staff / Artist / Customer.
|
|
* Configurar RLS base por rol (Artist NO ve email/phone de customers).
|
|
|
|
**Output:**
|
|
|
|
* Proyecto Supabase operativo.
|
|
* Policies iniciales documentadas.
|
|
|
|
---
|
|
|
|
### 1.2 Esquema de Base de Datos Inicial
|
|
|
|
Tablas obligatorias:
|
|
|
|
* locations (incluye timezone)
|
|
* resources
|
|
* staff
|
|
* services
|
|
* customers
|
|
* invitations
|
|
* bookings
|
|
* audit_logs
|
|
|
|
Tareas:
|
|
|
|
* Definir migraciones SQL versionadas.
|
|
* Claves foráneas y constraints.
|
|
* Campos de auditoría (`created_at`, `updated_at`).
|
|
|
|
**Output:**
|
|
|
|
* Migraciones SQL.
|
|
* Diagrama lógico.
|
|
|
|
---
|
|
|
|
### 1.3 Short ID & Invitaciones
|
|
|
|
* Implementar generador de Short ID (6 chars, collision-safe).
|
|
* Validación de unicidad antes de persistir booking.
|
|
* Generador y validación de códigos de invitación.
|
|
* Lógica de cuotas semanales por Tier.
|
|
* Reseteo automático de invitaciones cada semana (Lunes 00:00 UTC).
|
|
|
|
**Output:**
|
|
|
|
* Funciones backend.
|
|
* Tests unitarios.
|
|
* Registros en `audit_logs`.
|
|
|
|
---
|
|
|
|
### 1.4 CRM Base (Customers)
|
|
|
|
* Cálculo automático de Tier.
|
|
* Tracking de referidos.
|
|
* Perfil privado de cliente.
|
|
|
|
**Output:**
|
|
|
|
* Endpoints CRUD.
|
|
* Policies RLS por rol.
|
|
|
|
---
|
|
|
|
## FASE 2 — Motor de Agendamiento
|
|
|
|
### 2.1 Disponibilidad Doble Capa
|
|
|
|
* Validación Staff (rol Staff):
|
|
|
|
* Horario laboral.
|
|
* Eventos bloqueantes en Google Calendar.
|
|
|
|
* Validación Recurso:
|
|
|
|
* Disponibilidad de estación física.
|
|
|
|
* Regla de prioridad dinámica entre Staff y Artist.
|
|
|
|
* Validación Recurso:
|
|
|
|
* Disponibilidad de estación física.
|
|
|
|
* Regla de prioridad dinámica.
|
|
|
|
**Output:**
|
|
|
|
* Algoritmo de disponibilidad.
|
|
* Tests de colisión y concurrencia.
|
|
|
|
---
|
|
|
|
### 2.2 Servicios Express (Dual Artists)
|
|
|
|
* Búsqueda de dos artists simultáneas.
|
|
* Bloqueo del recurso principal requerido.
|
|
* Aplicación automática de Premium Fee.
|
|
|
|
**Output:**
|
|
|
|
* Lógica de booking dual.
|
|
* Casos de prueba.
|
|
|
|
---
|
|
|
|
### 2.3 Google Calendar Sync
|
|
|
|
* Integración vía Service Account.
|
|
* Sincronización bidireccional.
|
|
* Manejo de conflictos.
|
|
|
|
**Output:**
|
|
|
|
* Servicio de sincronización.
|
|
* Logs de errores.
|
|
|
|
---
|
|
|
|
## FASE 3 — Pagos y Protección
|
|
|
|
### 3.1 Stripe — Depósitos Dinámicos
|
|
|
|
* Regla $200 vs 50% según día.
|
|
* Asociación pago ↔ booking (UUID interno, Short ID visible).
|
|
|
|
**Output:**
|
|
|
|
* Webhooks Stripe.
|
|
* Validación de pagos.
|
|
|
|
---
|
|
|
|
### 3.2 No-Show Logic
|
|
|
|
* Ventana de cancelación 12h (UTC).
|
|
* Penalización automática.
|
|
* Override Admin.
|
|
|
|
**Output:**
|
|
|
|
* Función de penalización.
|
|
* Auditoría en `audit_logs`.
|
|
|
|
---
|
|
|
|
## FASE 4 — HQ Dashboard
|
|
|
|
### 4.1 Calendario Multi-Columna
|
|
|
|
* Vista por staff.
|
|
* Bloques de 15 minutos.
|
|
|
|
---
|
|
|
|
### 4.2 Gestión Operativa
|
|
|
|
* Recursos físicos.
|
|
* Staff.
|
|
* Traspaso entre sucursales.
|
|
|
|
---
|
|
|
|
### 4.3 The Vault
|
|
|
|
* Upload de fotos privadas.
|
|
* Formularios técnicos.
|
|
|
|
---
|
|
|
|
## FASE 5 — Automatización y Lanzamiento
|
|
|
|
* Confirmaciones por WhatsApp.
|
|
* Recibos digitales.
|
|
* Landing Page Believers.
|
|
|
|
---
|
|
|
|
## Regla Final
|
|
|
|
Si una tarea no está aquí, no existe. Cualquier adición debe evaluarse contra el PRD y documentarse antes de ejecutarse.
|