mirror of
https://github.com/marcogll/AnchorOS.git
synced 2026-03-15 13: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