first commit

This commit is contained in:
Marco Gallegos
2026-01-15 11:57:12 -06:00
commit 3a31ed31a4
4 changed files with 781 additions and 0 deletions

97
AGENTS.md Normal file
View 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
View 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 (DomMié)
Depósito fijo: $200 MXN.
Días Premium (JueSá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 12)
DB y Auth.
Invitaciones.
Tiers.
Short IDs.
Fase 2 — Motor de Agenda (Semanas 35)
Doble Capa.
Servicios Express.
Google Calendar Sync.
Fase 3 — Pagos (Semanas 67)
Depósitos dinámicos.
No-show logic.
Fase 4 — HQ Dashboard (Semanas 89)
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
View 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
View 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.