# Architect — F-048

## Context

El working tree contiene trabajo funcional ya aprobado (F-029, F-030 y FIX-11..FIX-19), pero no fue consolidado. `work/current.md` seguía apuntando a BD-09 y el runtime a un identificador inexistente (`FIX-MIGRATION`). La migración 024 mezclaba el contrato de `pg.Pool` con el runner oficial `node-pg-migrate`.

## Design decision

1. Tratar F-048 como ticket de reconciliación y cierre, sin ampliar alcance de producto.
2. Mantener `node-pg-migrate` como única interfaz para migraciones ordenadas: cada `up/down` recibe `MigrationBuilder` y registra SQL mediante `pgm.sql`.
3. Validar migraciones con base PostgreSQL real mediante ciclo fresh `up`, `down` y `up`, además de revisar que no existan scripts con ejecución lateral al importarse.
4. Validar por separado:
   - backend: build, typecheck, lint/boundaries y Vitest;
   - admin: typecheck, lint/build disponibles;
   - frontend: lint/build;
   - storefront: typecheck, lint/build.
5. Corregir solamente fallos que bloqueen esos checks o la reversibilidad de migraciones.
6. Emitir evidencia reproducible en `work/artifacts/F-048/` y usar `scripts/close_feature.py F-048` como única operación que promociona el ticket a `done` y crea el commit.

## Migration invariants

- `024_product_channels_attributes` conserva `channels` limitado a `online|offline|all`, `featured`, `attributes`, columnas de pricing e índice parcial.
- `down` elimina primero objetos dependientes y permite reaplicación.
- Las migraciones posteriores deben poder cargarse por el runner sin abrir conexiones ni ejecutar trabajo en import-time.
- La migración de backoffice debe preservar hashes, separar físicamente usuarios y ser reversible dentro de las restricciones de unicidad.

## Risks and mitigations

- **Cambios heterogéneos sin commit**: no reescribirlos; validar el conjunto y conservar artefactos aprobados existentes.
- **Builds Next dependientes de red/backend**: usar sus contratos de build reales y registrar cualquier limitación ambiental explícita.
- **Base local con estado previo**: validar en una base temporal/limpia para no destruir datos de desarrollo.
- **Cierre que hace `git add -A`**: revisar `git status`, excluir artefactos basura y secretos antes del gate de seguridad.

## Acceptance mapping

- Contrato y reversibilidad de migraciones → prueba fresh up/down/up.
- Calidad de producto → comandos por cada paquete.
- Estado sincronizado → `work/current.md` y runtime apuntan a F-048.
- Consolidación → gates aprobados + `close_feature.py` + working tree limpio.