40 lines
2.5 KiB
Markdown
40 lines
2.5 KiB
Markdown
# 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.
|