# Sprint 8 — Etapa 0: Versionado profesional

> **Tipo:** Infraestructura / Documentación
> **Rama:** main
> **Estimación:** 1-2 horas
> **Dependencias:** ninguna — es la primera etapa del sprint

---

## Objetivo

Establecer el ciclo profesional de versiones antes de abrir cualquier feature nueva:
1. `CHANGELOG.md` con historial completo desde v0.1.0
2. `package.json` actualizado a v0.8.0
3. `AppFooter` visible en la app con la versión actual
4. `simulador-web/CLAUDE.md` actualizado con la sección de versionado

---

## Contexto

El producto está en producción en https://inq-roi.inqualityhq.com y https://process-cost-platform.pages.dev. No existe `CHANGELOG.md`. La versión en `package.json` tiene algún valor anterior (verificar).

**`AppFooter.tsx` ya existe** en `src/components/AppFooter.tsx` con el texto:
```
InQ ROI · Powered by InQuality · v0.1.0 · Hecho desde Paraguay 🇵🇾
```
La versión está hardcodeada como `v0.1.0`. Esta etapa la hace dinámica y agrega el footer a LibraryPage (actualmente solo está en ReportPage e ImportPage).

El sprint adopta Conventional Commits a partir de esta etapa. Todos los commits de Sprint 8 deben seguir el formato especificado en `simulador-web/CLAUDE.md` (sección "Gestión de versiones y commits").

---

## Alcance estricto

### 1. Verificar versión actual en `package.json`

Leer `package.json` y reportar el valor actual de `"version"`. Luego actualizarlo a `"0.8.0"`.

### 2. Crear `src/lib/version.ts`

```typescript
// Lee la versión desde package.json en tiempo de build (Vite lo expone vía import.meta.env)
// Alternativa simple: constante string que se actualiza manualmente con cada release
export const APP_VERSION = '0.8.0'
```

Si Vite ya expone `import.meta.env.VITE_APP_VERSION` o similar, usar ese mecanismo. Si no, usar la constante string — es más simple y suficiente para el caso de uso.

### 3. Actualizar `src/components/AppFooter.tsx`

El componente **ya existe** con versión hardcodeada `v0.1.0`. Solo cambiar la versión hardcodeada por la constante de `version.ts`. Mantener el resto del texto y estilos exactamente igual.

```tsx
import { APP_VERSION } from '@/lib/version'

export function AppFooter() {
  return (
    <footer className="mt-12 py-4 border-t border-slate-100 text-center">
      <p className="text-xs text-slate-400">
        InQ ROI · Powered by InQuality · v{APP_VERSION} · Hecho desde Paraguay 🇵🇾
      </p>
    </footer>
  )
}
```

**NO cambiar** el texto, los estilos, ni el formato — solo reemplazar `v0.1.0` por `v{APP_VERSION}`.

### 4. Agregar `AppFooter` a LibraryPage

El componente ya está integrado en `ReportPage.tsx` e `ImportPage.tsx`. Falta en LibraryPage.

- `LibraryPage.tsx` — importar `AppFooter` y agregarlo antes del cierre del contenedor principal

**NO tocar** ReportPage ni ImportPage — ya tienen `<AppFooter />`.
**NO modificar** `AppHeader.tsx`.

### 5. Crear `CHANGELOG.md`

Ubicación: `simulador-web/CHANGELOG.md` (raíz del proyecto, mismo nivel que `package.json`).

Formato: [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

```markdown
# Changelog

All notable changes to InQ ROI will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [0.8.0] - 2026-07-07
### Added
- CHANGELOG.md con historial de versiones
- AppFooter con versión visible en todas las páginas
- Conventional Commits adoptados como estándar de commits

## [0.7.0] - 2026-07-07
### Added
- Multi-tenancy: tabla `organizations`, 4 roles de plataforma (platform_admin, member, client_editor, client_viewer)
- Edge Functions `invite-user` y `revoke-user` para gestión de acceso
- Panel de administración `/admin` con gestión de Organizations y Users
- Login email/password y página `/reset-password` para flujo de invitación
- Back button contextual en workspace (muestra nombre del cliente via JOIN en getById)
- Política RLS `simulations_update` para que client_editor pueda guardar simulaciones

### Fixed
- Race condition en AuthContext: `isProfileLoaded` como guard antes de renderizar contenido rol-dependiente
- `syncProfileFromDB` ahora lee `platform_role` y `org_id` desde DB (no inferido por dominio de email)
- `normalizeGroupLabel()`: limpia artículos iniciales de labels de grupos con datos corruptos

## [0.6.0] - 2026-06-24
### Added
- Logo InQuality en header de PDFs (isotipo, páginas 2+, fallback a texto)
- Panel de análisis de sensibilidad en tab ROI: sliders de volumen e inversión, recálculo en tiempo real
- Doble línea en CumulativeSavingsChart (base gris dashed + ajustada naranja con área sombreada)
- `whitespace-nowrap` en MetricCell de columna Eficiencia

### Fixed
- `ProfileSheet.getAccessToken()` leía clave inexistente (`'supabase.auth.token'`); el guardado de perfil nunca llegaba a Supabase desde Sprint 4. Fix: calcular `sb-${projectRef}-auth-token`

## [0.5.0] - 2026-06-23
### Added
- Fix crítico: workspace loading — race condition auth/processId resuelto con `isProfileLoaded`
- Controles de zoom BPMN: fit-viewport con centering correcto, botones zoom-in/zoom-out/fit
- Heatmap con gradiente continuo de 4 stops + toggle percentile/min-max persistido
- "Ver procesos por recurso" en catálogo de recursos
- Campo "empresa" en perfil de usuario
- Columna "Eficiencia de automatización" en ComparisonTable (+ columna "Ahorro esperado")

### Fixed
- Flakiness en botón "Guardar cambios": debounce + Web Locks en process-store
- Specs E2E migradas de Dexie a Supabase

## [0.4.0] - 2026-06-18
### Added
- Autenticación Google Workspace OAuth + Supabase
- Migración completa IndexedDB (Dexie) → PostgreSQL (Supabase)
- Row Level Security con `is_platform_admin()` y políticas granulares
- Catálogo global de recursos (sin processId)
- Identidad en UI: avatar/dropdown AppHeader, "Actualizado por" en proceso
- ResourceCatalogPage + ResourceFormSheet
- Fix Web Locks API deadlock (processLock)
- Fix `.maybeSingle()` en simulation-repo
- Fix `formatCostPerHour()` precisión dinámica
- Fix Google OAuth `prompt: 'select_account'`
- Catálogo con contexto de proceso (banner + query param fromProcess)

## [0.3.0] - 2026-05-27
### Added
- Biblioteca de procesos con grupos/tags/búsqueda (Dexie v4)
- Indicador de simulación desactualizada ("Hay cambios sin simular")
- Zoom BPMN fit-viewport
- Recursos TO-BE en escenario automatizado (motor + UI + reporte + PDF)
- Branding InQ ROI en todas las páginas (AppHeader + favicon + logos)
- Kit de socialización del equipo: guía de usuario, guía de pre-venta, presentación PPTX

## [0.2.0] - 2026-05-20
### Added
- Modelo de recursos `utilizationMinutes + units` (migración Dexie v3)
- ActivityPanel con cálculo de costo en tiempo real
- Reporte web con filas expandibles de desglose de recursos
- Edición inline de proceso/cliente
- Tabla de recursos en PDF (página condicional)

## [0.1.5] - 2026-05-18
### Added
- Identidad visual completa: paleta naranja InQ #F59845, gradiente → magenta #ED3E8F
- PDFs de clase profesional: 3 documentos (Actual, Automatizado, ROI)
- Badge ⚡ en canvas BPMN para actividades automatizables
- ROI con 5 KPIs
- Sistema de componentes establecido

## [0.1.0] - 2026-05-01
### Added
- MVP: importar BPMN 2.0, parametrizar actividades, simular costos, exportar PDF
- Motor de simulación AS-IS / TO-BE (Modelo A)
- Heatmap de costos en canvas BPMN
- Reporte web básico con tabla de actividades y gráfico de barras
```

**Nota sobre las fechas:** usar las fechas de cierre formal de sprint documentadas en `STRATEGIC_DIRECTION.md`. Si alguna fecha no está documentada, usar la fecha más cercana disponible (commits de git son referencia).

### 6. Actualizar `simulador-web/CLAUDE.md`

La sección "Gestión de versiones y commits" ya está en `CLAUDE.md` (fue agregada en el cierre de Sprint 7). Verificar que el contenido sea correcto y consistente con lo que se implementa en esta etapa. Si la sección no existe, crearla.

Verificar específicamente que diga:
- `Sprint 7 = v0.7.x (MVP multi-tenant). Sprint 8 arranca en v0.8.0.`
- El formato de Conventional Commits está documentado con los scopes correctos

**Si la sección ya existe y es correcta, NO modificar `CLAUDE.md`** — no tocar lo que ya está bien.

---

## Criterios de validación

### Funcionales
- [ ] `package.json` tiene `"version": "0.8.0"`
- [ ] `src/lib/version.ts` exporta `APP_VERSION = '0.8.0'`
- [ ] `AppFooter` renderiza `InQ ROI v0.8.0 · Powered by InQuality`
- [ ] Footer visible en LibraryPage (validación visual)
- [ ] Footer visible en ReportPage (validación visual)
- [ ] `CHANGELOG.md` existe con historial desde v0.1.0 hasta v0.8.0

### Técnicos
- [ ] Build sin errores TypeScript (`npm run build`)
- [ ] Tests sin regresiones (`npm run test`)
- [ ] No hay cambios en archivos fuera del scope listado

---

## Restricciones explícitas

- **NO** modificar `AppHeader.tsx` — la versión va en el footer solamente
- **NO** agregar modal de "novedades" ni changelog interactivo en la UI
- **NO** usar `import.meta.glob` ni mecanismos complejos para leer el version — la constante simple es suficiente
- **NO** agregar dependencias nuevas — todo con lo que ya existe en el stack
- **NO** crear README.md ni documentación adicional — solo los archivos listados

---

## Archivos autorizados a modificar/crear

```
simulador-web/
├── package.json                          ← actualizar "version" a "0.8.0"
├── CHANGELOG.md                          ← crear
├── src/
│   ├── lib/
│   │   └── version.ts                    ← crear
│   └── components/
│       └── AppFooter.tsx                 ← actualizar (solo versión dinámica)
└── src/features/library/LibraryPage.tsx  ← agregar <AppFooter /> al final
```

**No hay otros archivos para tocar en esta etapa.** ReportPage e ImportPage ya tienen `<AppFooter />` y no se modifican.

---

## Commit esperado

```
chore(version): v0.8.0 — CHANGELOG, AppFooter, version.ts
```

Seguido de:

```
docs(changelog): etapa 0 sprint 8
```

(Si se hacen en un solo commit, usar el primer mensaje.)

---

## Reporte esperado

Al finalizar, reportar:
1. Valor previo de `"version"` en `package.json`
2. Si el layout global existe (y si AppFooter se puso ahí en lugar de en las páginas)
3. Lista exacta de archivos modificados con diff resumen
4. Resultado de `npm run build` y `npm run test`
5. Screenshot o descripción del footer visible en la app (para validación visual del director)
