# Instalaciones CRM — PerfectPool · Indicaciones del proyecto

> Proyecto hermano de **Control CRM - PerfectPool**. Reutiliza su **estética** y su
> **metodología**. Este archivo es el punto de partida: léelo (o pásalo a tu Claude Code)
> antes de trabajar.

---

## 1. Qué es

Sistema web para **Órdenes de Trabajo (OT)** de instalaciones, **orientado al técnico**:
cada técnico inicia sesión y ve/gestiona las **instalaciones agendadas a su nombre**.

- **Subdominio:** https://instalaciones.perfectcrm.cl
- **Empezamos por:** las Órdenes de Trabajo (OT) — agendamiento y visibilidad por técnico.

### Flujo objetivo
1. El técnico inicia sesión y ve **sus visitas/instalaciones asignadas** (leídas del CRM vTiger).
2. Pulsa **"Crear OT"** sobre una visita.
3. Llena la OT: puede dejarla en **borrador** y retomarla, o completarla; **sube fotos**
   (reutilizando la programación de logística que ya se conecta al CRM y sube fotos).
4. Al completar, se **genera el PDF** de la OT (basado en las plantillas de `legacy/ot_pdf/`).
5. El PDF se **sube al CRM** (adjunto a la visita/pedido).
6. Se **envía por correo** al **vendedor** asignado al pedido, con **copia al técnico**.

> Detalle técnico e integraciones en `docs/ARCHITECTURE.md`.

### Piezas que revisaremos primero (en `legacy/`)
- **Programación de logística**: se conecta al CRM y **toma/sube fotos** → reutilizamos su mecanismo.
- **PDF de OT**: definen el **modelo de datos** de la Orden de Trabajo.

---

## 2. Mismo esquema que Control CRM

| Aspecto | Definición |
|--------|------------|
| **Organización GitHub** | `perfectpoolprojects` |
| **Repositorio** | `instalaciones-crm-perfectpool` (privado) |
| **Despliegue** | GitHub es la fuente de verdad → el servidor **clona** y actualiza con `git pull` (deploy key SSH de solo lectura). |
| **Docroot** | El subdominio apunta a la carpeta `web/` del repo. |
| **Secretos** | Nunca al repo. `config.php`/`conexion.php` locales, creados desde `.example` y en `.gitignore`. |
| **Stack** | PHP + MySQL (como el CRM vTiger 7.4 y el módulo de asignaciones). |

> Ver en Control CRM: `docs/DESPLIEGUE_SERVIDOR.md` y `docs/COMO_SUBIR_A_GITHUB.md` — el
> procedimiento es idéntico cambiando el nombre del repo y el subdominio.

---

## 3. Metodología (igual que Control CRM)

- **`docs/` como fuente de verdad**: `ROADMAP.md`, `SPRINTS.md`, `ARCHITECTURE.md`,
  `DECISIONS.md`, `TECHNICAL_DEBT.md`, y `HANDOFF_<fecha>.md` al cierre de sesión.
- **Sprints pequeños** (un eje por sprint, ~2–4 días); cada uno cierra algo usable.
- **Git flow**: `main` (estable) · `develop` (integración) · `feature/*` (trabajo diario).
- **Commits**: `feat: · fix: · refactor: · docs: · test: · chore:`.
- **Prefijo de IDs** en `SPRINTS.md`: `INST-001`, `INST-101`, …
- (Opcional) **graphify** para ahorro de tokens cuando haya código suficiente.

---

## 4. Estética compartida (idéntica a Control CRM)

Reusar el sistema visual del módulo de asignaciones. Copiar
`web/modules/asignaciones/assets/styles.css` de Control CRM como base, o replicar estos tokens:

```
--bg:#f4f7fb; --surface:#ffffff; --ink:#0f2c3f; --muted:#5b7384; --line:#e3ebf2;
--brand:#0a8ec7; --brand-dark:#066a96; --brand-soft:#e6f4fb;
--ok:#1a9d6b; --dev:#c98a00; --pend:#8a93a3; --danger:#d6455b;
```

Patrones: cabecera con degradado azul PerfectPool, pestañas, `.card`, tablas, `.pill` de
estado, botones `.btn/.btn-primary`. Login central y layout compartido (`inc/layout.php`).

---

## 5. Estructura del repositorio (misma convención)

```
.
├── docs/                # ROADMAP, SPRINTS, ARCHITECTURE, DECISIONS, TECHNICAL_DEBT, HANDOFF
├── web/                 # Interfaz (docroot del subdominio)
│   ├── index.php        # Launcher/entrada (login del técnico)
│   ├── assets/styles.css
│   └── modules/ot/      # Módulo Órdenes de Trabajo
├── scripts/             # Cron / utilidades del servidor
├── inventory/           # Inventario de lo que se vaya migrando
└── legacy/              # Staging del material a revisar (IGNORADO por git)
```

---

## 6. Punto de partida: alimentar con archivos

Comenzamos cargando material a `legacy/` para revisarlo (igual que en asignaciones). Tres tipos:

1. **Planillas / datos** (Excel, CSV): OT actuales, técnicos, clientes, agenda.
2. **Código legacy PHP**: cualquier programación existente de instalaciones/OT.
3. **Documentos / manuales** (PDF, imágenes): procedimientos de instalación.

Flujo por cada bloque: **subir a `legacy/` → revisar → registrar en `inventory/` →
diseñar/migrar limpio a `web/` o `scripts/`**.

> ⚠️ Si el material trae credenciales o datos personales sensibles, avísame: se saca antes
> de versionar. `legacy/` va en `.gitignore` por defecto.

---

## 7. Modelo de datos inicial (tentativo, a validar con los datos reales)

**Orden de Trabajo (OT)** — campos candidatos:
`id`, `n_ot`, `tecnico` (correo/id), `cliente`, `direccion`, `comuna/zona`,
`tipo_instalacion`, `fecha_agendada`, `estado` (agendada / en curso / completada / reprogramada),
`observaciones`, `fecha_creacion`.

**Técnico** — `id`, `nombre`, `correo`, `activo`. (Reutilizable con la lógica de usuarios/roles
de Control CRM; a futuro, permisos ver/editar por sección.)

---

## 8. Primeros pasos concretos

1. Crear el repo `instalaciones-crm-perfectpool` (privado) en `perfectpoolprojects`.
2. Scaffold: `docs/`, `web/` (con `styles.css` y login base), `.gitignore` (incluye `legacy/`,
   secretos, `**/inc/config.php`), `inventory/`.
3. Subir el **primer lote de archivos** a `legacy/` y revisarlos juntos.
4. Definir el Sprint 1 en `ROADMAP.md`/`SPRINTS.md` (probable: "Listado de OT por técnico").

---

## 9. Cómo usar Claude en este proyecto

- **Retomar:** "Lee `docs/SPRINTS.md` y el último `HANDOFF`, y sigamos desde ahí."
- **Cerrar sesión:** "Actualiza `SPRINTS.md` y crea el `HANDOFF` de hoy."
- **Planear:** "Propón el próximo sprint en `ROADMAP.md` con su checklist y su Issue."