mirror of
https://github.com/marcogll/AnchorOS.git
synced 2026-03-15 14:24:27 +00:00
first commit
This commit is contained in:
97
AGENTS.md
Normal file
97
AGENTS.md
Normal file
@@ -0,0 +1,97 @@
|
|||||||
|
# AGENTS.md — Roles de IA y Responsabilidades
|
||||||
|
|
||||||
|
Este documento define cómo deben usarse agentes de IA (Claude, Codex, OpenCode, Gemini) dentro del proyecto SalonOS.
|
||||||
|
|
||||||
|
Ningún agente tiene autoridad de producto. Todos ejecutan bajo el PRD.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Principios de Uso de Agentes
|
||||||
|
|
||||||
|
* Los agentes **no deciden alcance**.
|
||||||
|
* Los agentes **no redefinen reglas de negocio**.
|
||||||
|
* Toda salida debe ser revisable y versionable.
|
||||||
|
* El PRD es la única fuente de verdad funcional.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Claude — Arquitectura & Lógica
|
||||||
|
|
||||||
|
**Rol:** Arquitecto de sistema y reglas de negocio.
|
||||||
|
|
||||||
|
**Usar para:**
|
||||||
|
|
||||||
|
* Descomposición de lógica compleja.
|
||||||
|
* Revisión de consistencia con el PRD.
|
||||||
|
* Diseño de flujos y algoritmos.
|
||||||
|
* Modelado de estados y edge cases.
|
||||||
|
|
||||||
|
**No usar para:**
|
||||||
|
|
||||||
|
* Código final sin revisión.
|
||||||
|
* Decisiones de UX visual.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Codex — Implementación Backend
|
||||||
|
|
||||||
|
**Rol:** Ingeniero de backend.
|
||||||
|
|
||||||
|
**Usar para:**
|
||||||
|
|
||||||
|
* SQL y migraciones.
|
||||||
|
* Funciones server-side.
|
||||||
|
* Webhooks (Stripe, WhatsApp).
|
||||||
|
* Integraciones API.
|
||||||
|
|
||||||
|
**Reglas:**
|
||||||
|
|
||||||
|
* Todo código debe respetar RLS.
|
||||||
|
* No hardcodear secretos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## OpenCode — Frontend & Integración
|
||||||
|
|
||||||
|
**Rol:** Ingeniero de interfaz y pegamento.
|
||||||
|
|
||||||
|
**Usar para:**
|
||||||
|
|
||||||
|
* Componentes Next.js.
|
||||||
|
* Integración frontend ↔ backend.
|
||||||
|
* Manejo de estados.
|
||||||
|
* Formularios y flujos.
|
||||||
|
|
||||||
|
**Reglas:**
|
||||||
|
|
||||||
|
* No exponer datos privados.
|
||||||
|
* Validaciones críticas en backend.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Gemini — QA & Seguridad
|
||||||
|
|
||||||
|
**Rol:** Auditor técnico.
|
||||||
|
|
||||||
|
**Usar para:**
|
||||||
|
|
||||||
|
* Revisión de RLS.
|
||||||
|
* Detección de fugas de datos.
|
||||||
|
* Edge cases de seguridad.
|
||||||
|
* Validación de flujos críticos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flujo de Trabajo Recomendado
|
||||||
|
|
||||||
|
1. PRD define la regla.
|
||||||
|
2. Claude descompone la lógica.
|
||||||
|
3. Codex implementa backend.
|
||||||
|
4. OpenCode conecta UI.
|
||||||
|
5. Gemini audita.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Regla de Oro
|
||||||
|
|
||||||
|
Si un agente contradice el PRD, el agente está equivocado.
|
||||||
316
PRD.md
Normal file
316
PRD.md
Normal file
@@ -0,0 +1,316 @@
|
|||||||
|
🥂 SalonOS — Product Requirements Document (PRD)
|
||||||
|
|
||||||
|
Exclusive Studio Management & CRM EngineVersión: 1.0Estado: Documento Maestro de Planificación
|
||||||
|
|
||||||
|
Este documento constituye la especificación definitiva del producto SalonOS. Consolida la visión de negocio, las reglas operativas, la experiencia de usuario y la arquitectura técnica. Funciona como contrato de alineación entre la dueña del negocio y el equipo de diseño y desarrollo.
|
||||||
|
|
||||||
|
1. Visión y Propósito del Proyecto
|
||||||
|
|
||||||
|
SalonOS no es una agenda digital. Es un sistema de gestión de activos, exclusividad y control operativo diseñado para estudios de belleza premium.
|
||||||
|
|
||||||
|
1.1 Propósito Dual
|
||||||
|
|
||||||
|
Para la Clienta
|
||||||
|
|
||||||
|
Experiencia de reserva privada, rápida y sin fricción.
|
||||||
|
|
||||||
|
Sensación de pertenencia a un círculo exclusivo.
|
||||||
|
|
||||||
|
Interfaz minimalista estilo Townhouse Beauty.
|
||||||
|
|
||||||
|
Para el Negocio
|
||||||
|
|
||||||
|
Maximizar la rentabilidad por metro cuadrado.
|
||||||
|
|
||||||
|
Optimizar el uso de recursos físicos y humanos.
|
||||||
|
|
||||||
|
Proteger la base de datos de clientes ante rotación de personal.
|
||||||
|
|
||||||
|
2. Experiencia de Usuario (UX) y Filosofía de Diseño
|
||||||
|
|
||||||
|
2.1 The Boutique — Interfaz de Clienta
|
||||||
|
|
||||||
|
Principios
|
||||||
|
|
||||||
|
Minimalismo extremo.
|
||||||
|
|
||||||
|
Eliminación total de fricción.
|
||||||
|
|
||||||
|
Diseño aspiracional, no comercial.
|
||||||
|
|
||||||
|
Características Clave
|
||||||
|
|
||||||
|
Tipografía serif premium.
|
||||||
|
|
||||||
|
Espacios amplios y navegación guiada.
|
||||||
|
|
||||||
|
Sin contraseñas: autenticación vía Magic Links (Email / SMS).
|
||||||
|
|
||||||
|
Flujo Lineal de Reserva
|
||||||
|
|
||||||
|
Selección de sucursal.
|
||||||
|
|
||||||
|
Selección de servicio(s).
|
||||||
|
|
||||||
|
Asignación de staff.
|
||||||
|
|
||||||
|
Selección de horario.
|
||||||
|
|
||||||
|
Pago de depósito.
|
||||||
|
|
||||||
|
Confirmación.
|
||||||
|
|
||||||
|
No existen bifurcaciones innecesarias.
|
||||||
|
|
||||||
|
2.2 The HQ — Dashboard Administrativo
|
||||||
|
|
||||||
|
Principios
|
||||||
|
|
||||||
|
Claridad operativa.
|
||||||
|
|
||||||
|
Control visual inmediato.
|
||||||
|
|
||||||
|
Optimizado para escritorio y tablet.
|
||||||
|
|
||||||
|
Características
|
||||||
|
|
||||||
|
Estética SquareUI.
|
||||||
|
|
||||||
|
Calendario multi-columna:
|
||||||
|
|
||||||
|
Columnas: profesionales.
|
||||||
|
|
||||||
|
Filas: bloques de 15 minutos.
|
||||||
|
|
||||||
|
Vista tipo Fresha, sin sobrecarga visual.
|
||||||
|
|
||||||
|
3. Módulos y Lógica de Negocio
|
||||||
|
|
||||||
|
3.1 Motor de Disponibilidad "Double-Lock"
|
||||||
|
|
||||||
|
Una cita solo puede existir si se validan simultáneamente dos capas:
|
||||||
|
|
||||||
|
Capa Humana
|
||||||
|
|
||||||
|
Colaboradora activa.
|
||||||
|
|
||||||
|
Dentro de horario laboral.
|
||||||
|
|
||||||
|
Sin conflicto en Google Calendar personal.
|
||||||
|
|
||||||
|
Capa Física
|
||||||
|
|
||||||
|
Recurso físico requerido disponible.
|
||||||
|
|
||||||
|
Sin colisión con otra reserva.
|
||||||
|
|
||||||
|
Regla de Prioridad Dinámica
|
||||||
|
Si existen más colaboradoras que estaciones físicas, el sistema limita la agenda según el recurso disponible.
|
||||||
|
|
||||||
|
3.2 Servicios Express (Dual Staff)
|
||||||
|
|
||||||
|
Servicios simultáneos diseñados para optimizar el tiempo de la clienta.
|
||||||
|
|
||||||
|
Reglas
|
||||||
|
|
||||||
|
Requiere dos colaboradoras disponibles en el mismo rango.
|
||||||
|
|
||||||
|
Uso obligatorio del Sillón de Pedicura para Mani + Pedi.
|
||||||
|
|
||||||
|
La mesa de manicura queda liberada para otra venta.
|
||||||
|
|
||||||
|
Se aplica automáticamente un Premium Fee.
|
||||||
|
|
||||||
|
El sistema trata el servicio dual como una sola entidad lógica.
|
||||||
|
|
||||||
|
3.3 Ecosistema de Exclusividad (Invite-Only)
|
||||||
|
|
||||||
|
No existe registro abierto.
|
||||||
|
|
||||||
|
Reglas de Acceso
|
||||||
|
|
||||||
|
Agenda solo disponible con código de invitación válido.
|
||||||
|
|
||||||
|
Cuotas por Tier
|
||||||
|
|
||||||
|
Regular: 2 invitaciones (lifetime).
|
||||||
|
|
||||||
|
Gold: 5 invitaciones nuevas por mes.
|
||||||
|
|
||||||
|
VIP: Ilimitadas.
|
||||||
|
|
||||||
|
Tier Especial
|
||||||
|
|
||||||
|
Believer: Clientas fundadoras.
|
||||||
|
|
||||||
|
Ascienden a Gold con solo 2 citas completadas.
|
||||||
|
|
||||||
|
3.4 Blindaje y Privacidad de Datos
|
||||||
|
|
||||||
|
Vista del Staff
|
||||||
|
|
||||||
|
Nombre de la clienta.
|
||||||
|
|
||||||
|
Tier.
|
||||||
|
|
||||||
|
Historial técnico.
|
||||||
|
|
||||||
|
Información Oculta al Staff
|
||||||
|
|
||||||
|
Teléfono.
|
||||||
|
|
||||||
|
Email.
|
||||||
|
|
||||||
|
Historial financiero.
|
||||||
|
|
||||||
|
Audit Trail
|
||||||
|
|
||||||
|
Toda acción queda registrada:
|
||||||
|
|
||||||
|
Usuario.
|
||||||
|
|
||||||
|
Timestamp.
|
||||||
|
|
||||||
|
Motivo del cambio.
|
||||||
|
|
||||||
|
4. Gestión Financiera y Depósitos Dinámicos
|
||||||
|
|
||||||
|
4.1 Booking Fees
|
||||||
|
|
||||||
|
Días Valle (Dom–Mié)
|
||||||
|
|
||||||
|
Depósito fijo: $200 MXN.
|
||||||
|
|
||||||
|
Días Premium (Jue–Sáb)
|
||||||
|
|
||||||
|
Anticipo: 50% del total.
|
||||||
|
|
||||||
|
Cada cita genera un Short ID de 6 caracteres, que funciona como:
|
||||||
|
|
||||||
|
Referencia de pago.
|
||||||
|
|
||||||
|
Identificador operativo.
|
||||||
|
|
||||||
|
4.2 Política No-Show
|
||||||
|
|
||||||
|
Captura de tarjeta vía Stripe.
|
||||||
|
|
||||||
|
Ventana de cancelación: 12 horas.
|
||||||
|
|
||||||
|
Penalización automática si no cumple.
|
||||||
|
|
||||||
|
Condonación manual solo por Admin.
|
||||||
|
|
||||||
|
5. Operación de Staff — The Vault
|
||||||
|
|
||||||
|
Al cerrar una cita, la documentación es obligatoria.
|
||||||
|
|
||||||
|
Contenido
|
||||||
|
|
||||||
|
Fórmulas técnicas.
|
||||||
|
|
||||||
|
Productos utilizados.
|
||||||
|
|
||||||
|
Fotos Antes / Después.
|
||||||
|
|
||||||
|
Traspaso de Personal
|
||||||
|
|
||||||
|
Módulo para mover colaboradoras entre sucursales.
|
||||||
|
|
||||||
|
Reasignación automática de citas.
|
||||||
|
|
||||||
|
La información pertenece al negocio, no al staff.
|
||||||
|
|
||||||
|
6. Arquitectura Técnica
|
||||||
|
|
||||||
|
6.1 Stack
|
||||||
|
|
||||||
|
Frontend: Next.js 14 + Tailwind CSS + Framer Motion.
|
||||||
|
|
||||||
|
Backend: Supabase (PostgreSQL + Auth + RLS).
|
||||||
|
|
||||||
|
Pagos: Stripe SDK.
|
||||||
|
|
||||||
|
Calendario: Google Calendar API v3 (Service Account).
|
||||||
|
|
||||||
|
Notificaciones: WhatsApp API (Twilio / Meta).
|
||||||
|
|
||||||
|
Storage: Supabase Storage (Buckets privados).
|
||||||
|
|
||||||
|
7. Esquema de Base de Datos (Sugerido)
|
||||||
|
|
||||||
|
locations
|
||||||
|
|
||||||
|
resources
|
||||||
|
|
||||||
|
staff
|
||||||
|
|
||||||
|
services
|
||||||
|
|
||||||
|
customers
|
||||||
|
|
||||||
|
invitations
|
||||||
|
|
||||||
|
bookings
|
||||||
|
|
||||||
|
audit_logs
|
||||||
|
|
||||||
|
Todas las tablas protegidas mediante Row Level Security.
|
||||||
|
|
||||||
|
8. Roadmap de Desarrollo
|
||||||
|
|
||||||
|
Fase 1 — Cimientos (Semanas 1–2)
|
||||||
|
|
||||||
|
DB y Auth.
|
||||||
|
|
||||||
|
Invitaciones.
|
||||||
|
|
||||||
|
Tiers.
|
||||||
|
|
||||||
|
Short IDs.
|
||||||
|
|
||||||
|
Fase 2 — Motor de Agenda (Semanas 3–5)
|
||||||
|
|
||||||
|
Doble Capa.
|
||||||
|
|
||||||
|
Servicios Express.
|
||||||
|
|
||||||
|
Google Calendar Sync.
|
||||||
|
|
||||||
|
Fase 3 — Pagos (Semanas 6–7)
|
||||||
|
|
||||||
|
Depósitos dinámicos.
|
||||||
|
|
||||||
|
No-show logic.
|
||||||
|
|
||||||
|
Fase 4 — HQ Dashboard (Semanas 8–9)
|
||||||
|
|
||||||
|
Calendario multi-columna.
|
||||||
|
|
||||||
|
Gestión de recursos.
|
||||||
|
|
||||||
|
The Vault.
|
||||||
|
|
||||||
|
Fase 5 — Lanzamiento (Semana 10)
|
||||||
|
|
||||||
|
WhatsApp.
|
||||||
|
|
||||||
|
Landing Believers.
|
||||||
|
|
||||||
|
9. Resumen de Valor para la Dueña
|
||||||
|
|
||||||
|
SalonOS entrega:
|
||||||
|
|
||||||
|
Blindaje total del negocio.
|
||||||
|
|
||||||
|
Optimización real del espacio físico.
|
||||||
|
|
||||||
|
Crecimiento orgánico controlado.
|
||||||
|
|
||||||
|
Protección financiera ante cancelaciones.
|
||||||
|
|
||||||
|
Este documento define la visión técnica oficial de SalonOS. Cualquier modificación posterior al inicio de la Fase 1 impacta alcance, tiempos y costos.
|
||||||
|
|
||||||
|
Proyecto: soul23
|
||||||
|
|
||||||
|
|
||||||
174
README.md
Normal file
174
README.md
Normal file
@@ -0,0 +1,174 @@
|
|||||||
|
# 🥂 SalonOS
|
||||||
|
|
||||||
|
**Exclusive Studio Management & CRM Engine**
|
||||||
|
Repositorio principal del sistema SalonOS.
|
||||||
|
|
||||||
|
Este README es la puerta de entrada técnica al proyecto. Define qué es este repositorio, cómo se estructura y cómo debe ser utilizado por desarrollo, producto y operación.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. ¿Qué es SalonOS?
|
||||||
|
|
||||||
|
SalonOS es un sistema propietario de gestión operativa y CRM diseñado para estudios de belleza de alta exclusividad. No es una agenda genérica: coordina **personas, recursos físicos, pagos, privilegios y datos** bajo reglas estrictas de control y privacidad.
|
||||||
|
|
||||||
|
El sistema está diseñado para:
|
||||||
|
|
||||||
|
* Optimizar el uso de estaciones físicas.
|
||||||
|
* Proteger la base de datos de clientes.
|
||||||
|
* Controlar el crecimiento mediante invitaciones.
|
||||||
|
* Garantizar rentabilidad en días de alta demanda.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Alcance de este Repositorio
|
||||||
|
|
||||||
|
Este repositorio contiene:
|
||||||
|
|
||||||
|
* Frontend de cliente (The Boutique).
|
||||||
|
* Dashboard administrativo (The HQ).
|
||||||
|
* Lógica de negocio de agendamiento.
|
||||||
|
* Integraciones externas (Stripe, Google Calendar, WhatsApp).
|
||||||
|
* Esquema base de datos y políticas de seguridad.
|
||||||
|
|
||||||
|
No contiene:
|
||||||
|
|
||||||
|
* Material de marketing.
|
||||||
|
* Operación manual del salón.
|
||||||
|
* Datos productivos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Documentación Oficial
|
||||||
|
|
||||||
|
Este proyecto se rige por los siguientes documentos:
|
||||||
|
|
||||||
|
* **PRD (Documento Maestro)** → Definición de producto y reglas de negocio.
|
||||||
|
* **README (este archivo)** → Guía técnica y operativa del repo.
|
||||||
|
|
||||||
|
El PRD es la fuente de verdad funcional. El README es la guía de ejecución.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Arquitectura General
|
||||||
|
|
||||||
|
### Experiencias
|
||||||
|
|
||||||
|
* **The Boutique**: Frontend de reserva para clientas.
|
||||||
|
* **The HQ**: Dashboard administrativo y CRM interno.
|
||||||
|
|
||||||
|
### Principios
|
||||||
|
|
||||||
|
* Security by Design.
|
||||||
|
* Exclusividad curada.
|
||||||
|
* Optimización de activos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Stack Tecnológico
|
||||||
|
|
||||||
|
* **Frontend**: Next.js 14 (App Router)
|
||||||
|
* **UI / Estilos**: Tailwind CSS + Framer Motion
|
||||||
|
* **Backend**: Supabase (PostgreSQL + Auth + RLS)
|
||||||
|
* **Pagos**: Stripe SDK
|
||||||
|
* **Calendario**: Google Calendar API v3 (Service Account)
|
||||||
|
* **Notificaciones**: WhatsApp API (Twilio / Meta)
|
||||||
|
* **Storage**: Supabase Storage (Buckets privados)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Estructura del Proyecto
|
||||||
|
|
||||||
|
```
|
||||||
|
/salonos
|
||||||
|
├── app/ # Next.js App Router
|
||||||
|
│ ├── boutique/ # Frontend clienta
|
||||||
|
│ ├── hq/ # Dashboard administrativo
|
||||||
|
│ └── api/ # API routes
|
||||||
|
├── components/ # Componentes UI reutilizables
|
||||||
|
├── lib/ # Lógica de negocio y helpers
|
||||||
|
├── db/ # Esquemas, migraciones y seeds
|
||||||
|
├── integrations/ # Stripe, Google, WhatsApp
|
||||||
|
├── styles/ # Configuración Tailwind
|
||||||
|
└── docs/ # Documentación adicional
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Requisitos de Entorno
|
||||||
|
|
||||||
|
* Node.js 18+
|
||||||
|
* Cuenta Supabase
|
||||||
|
* Cuenta Stripe
|
||||||
|
* Proyecto Google Cloud (Calendar API)
|
||||||
|
* Credenciales WhatsApp API
|
||||||
|
|
||||||
|
Variables de entorno obligatorias:
|
||||||
|
|
||||||
|
```
|
||||||
|
NEXT_PUBLIC_SUPABASE_URL=
|
||||||
|
NEXT_PUBLIC_SUPABASE_ANON_KEY=
|
||||||
|
SUPABASE_SERVICE_ROLE_KEY=
|
||||||
|
STRIPE_SECRET_KEY=
|
||||||
|
GOOGLE_SERVICE_ACCOUNT_JSON=
|
||||||
|
WHATSAPP_API_KEY=
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Setup Local
|
||||||
|
|
||||||
|
1. Clonar el repositorio
|
||||||
|
|
||||||
|
```
|
||||||
|
git clone <repo-url>
|
||||||
|
cd salonos
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Instalar dependencias
|
||||||
|
|
||||||
|
```
|
||||||
|
npm install
|
||||||
|
```
|
||||||
|
|
||||||
|
3. Configurar variables de entorno
|
||||||
|
|
||||||
|
* Crear `.env.local`.
|
||||||
|
|
||||||
|
4. Levantar entorno local
|
||||||
|
|
||||||
|
```
|
||||||
|
npm run dev
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Convenciones de Desarrollo
|
||||||
|
|
||||||
|
* El PRD define la lógica: no se improvisa comportamiento.
|
||||||
|
* Toda regla crítica debe vivir en backend.
|
||||||
|
* RLS obligatorio en todas las tablas sensibles.
|
||||||
|
* El frontend nunca expone datos privados del cliente.
|
||||||
|
* Cambios de alcance requieren actualización del PRD.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Estado del Proyecto
|
||||||
|
|
||||||
|
* Fase actual: Planificación / Fase 1.
|
||||||
|
* No apto para producción.
|
||||||
|
* Migraciones y seeds en evolución.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. Filosofía Operativa
|
||||||
|
|
||||||
|
SalonOS no busca volumen.
|
||||||
|
|
||||||
|
Busca **control, eficiencia y blindaje**.
|
||||||
|
|
||||||
|
Este repositorio implementa esa filosofía a nivel de sistema.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Proyecto:
|
||||||
|
|
||||||
194
TASKS.md
Normal file
194
TASKS.md
Normal file
@@ -0,0 +1,194 @@
|
|||||||
|
# TASKS.md — Plan de Ejecución por Agentes
|
||||||
|
|
||||||
|
Este documento define las tareas ejecutables del proyecto SalonOS, descompuestas para trabajo asistido por modelos (Claude, Codex, OpenCode, Gemini) y desarrollo humano.
|
||||||
|
|
||||||
|
Las tareas están alineadas estrictamente con el PRD. No se permite introducir lógica no documentada.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Convenciones
|
||||||
|
|
||||||
|
* Cada tarea debe producir artefactos verificables (código, migraciones, tests, docs).
|
||||||
|
* Las reglas de negocio viven en backend.
|
||||||
|
* Ningún agente redefine alcance.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## FASE 1 — Cimientos y CRM
|
||||||
|
|
||||||
|
### 1.1 Infraestructura Base
|
||||||
|
|
||||||
|
* Crear proyecto Supabase.
|
||||||
|
* Configurar Auth (Magic Links Email/SMS).
|
||||||
|
* Definir RLS global por rol (Admin / Manager / Staff / Customer).
|
||||||
|
|
||||||
|
**Output:**
|
||||||
|
|
||||||
|
* Supabase project configurado.
|
||||||
|
* Policies iniciales documentadas.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.2 Esquema de Base de Datos Inicial
|
||||||
|
|
||||||
|
Tablas:
|
||||||
|
|
||||||
|
* locations
|
||||||
|
* resources
|
||||||
|
* staff
|
||||||
|
* services
|
||||||
|
* customers
|
||||||
|
* invitations
|
||||||
|
* bookings
|
||||||
|
* audit_logs
|
||||||
|
|
||||||
|
Tareas:
|
||||||
|
|
||||||
|
* Definir migraciones SQL.
|
||||||
|
* Claves foráneas y constraints.
|
||||||
|
* Campos de auditoría (`created_at`, `updated_at`).
|
||||||
|
|
||||||
|
**Output:**
|
||||||
|
|
||||||
|
* Migraciones versionadas.
|
||||||
|
* Diagrama lógico.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.3 Short ID & Invitaciones
|
||||||
|
|
||||||
|
* Generador de Short ID (6 chars, collision-safe).
|
||||||
|
* Generador y validación de códigos de invitación.
|
||||||
|
* Lógica de cuotas por Tier.
|
||||||
|
|
||||||
|
**Output:**
|
||||||
|
|
||||||
|
* Funciones backend.
|
||||||
|
* Tests unitarios.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 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:
|
||||||
|
|
||||||
|
* Horario laboral.
|
||||||
|
* Eventos en Google Calendar.
|
||||||
|
|
||||||
|
* Validación Recurso:
|
||||||
|
|
||||||
|
* Disponibilidad de estación física.
|
||||||
|
|
||||||
|
* Regla de prioridad dinámica.
|
||||||
|
|
||||||
|
**Output:**
|
||||||
|
|
||||||
|
* Algoritmo de disponibilidad.
|
||||||
|
* Tests de colisión.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.2 Servicios Express (Dual Staff)
|
||||||
|
|
||||||
|
* Búsqueda de dos colaboradoras simultáneas.
|
||||||
|
* Bloqueo de Sillón de Pedicura.
|
||||||
|
* Liberación de mesa secundaria.
|
||||||
|
* 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.
|
||||||
|
* Sync 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%.
|
||||||
|
* Asociación pago ↔ booking.
|
||||||
|
|
||||||
|
**Output:**
|
||||||
|
|
||||||
|
* Webhooks Stripe.
|
||||||
|
* Validación de pagos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 3.2 No-Show Logic
|
||||||
|
|
||||||
|
* Ventana 12h.
|
||||||
|
* 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 min.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.2 Gestión Operativa
|
||||||
|
|
||||||
|
* Recursos.
|
||||||
|
* Staff.
|
||||||
|
* Traspaso entre sucursales.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.3 The Vault
|
||||||
|
|
||||||
|
* Upload fotos privadas.
|
||||||
|
* Formularios técnicos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## FASE 5 — Automatización y Lanzamiento
|
||||||
|
|
||||||
|
* WhatsApp confirmaciones.
|
||||||
|
* Recibos digitales.
|
||||||
|
* Landing Believers.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Regla Final
|
||||||
|
|
||||||
|
Si una tarea no está aquí, no existe.
|
||||||
Reference in New Issue
Block a user