[J3rmed]

Qué cambia

Flyway pasa a ser la única forma de cambiar el esquema (ADR-0006). Es el primer habilitador del Sprint 2: HU-002, 003, 004, 006 y 009 cambian el esquema, y sin migraciones esos cambios chocarían en un solo schema.sql.

• Migraciones: docs/database/schema.sql y rls.sql se mueven a src/main/resources/db/migration/ como V1__esquema_inicial.sql y V2__rls.sql. El DDL no cambia. A partir de ahora, ningún cambio de esquema edita V1 ni V2: cada cambio es una migración nueva (V3, V4…).
• Hibernate solo valida: ddl-auto=validate en todos los perfiles. Antes, las pruebas usaban create-drop, así que los triggers, los exclude y los check del esquema nunca actuaban en ellas. Ahora sí.
• Bases anteriores a Flyway: Supabase y las bases locales ya tienen el esquema pero no la tabla de historial. Con baseline-on-migrate y baseline-version: 0, Flyway las marca como anteriores a V1 y les vuelve a aplicar V1 y V2. Como los dos scripts son idempotentes, solo crean lo que falte.
• RLS en flyway_schema_history: Supabase expone public por el Data API, así que esta tabla también necesita RLS. Va en el callback afterMigrate__rls_historial_flyway.sql y no en V2, porque Flyway tiene la tabla bloqueada mientras migra y V2 se quedaba esperando para siempre.
• Workflow database.yml: aplica las migraciones en orden, comprueba que V1 y V2 sigan siendo idempotentes y falla si alguna tabla de public queda sin RLS.
• Documentación: ADR-0006 nuevo; ADR-0002 y 0005 marcados como reemplazados en este punto; README, runbook y la guía de docs/database actualizados.

Pruebas

mvn clean verify en local con JDK 21: 619 unitarias y 64 de integración en verde, y JaCoCo cumple el umbral.

• DatabaseMigrationsIT (nueva) comprueba tres cosas sobre una base vacía: que se migra desde V1, que existen las reglas que solo viven en la base de datos (trigger de reservas y exclude de recursos) y que ninguna tabla de public queda sin RLS.
• CloudProfileContextIT ahora simula la primera migración en Supabase: aplica V1 y V2 a mano, arranca el perfil cloud y comprueba que el historial queda en 0 BASELINE, 1 SQL, 2 SQL.

Al revisar y desplegar

• No arrancar la app en local con un .env que apunte a Supabase. Aplicaría a la base compartida las migraciones de la rama antes de la revisión. Para desarrollar en local está docker compose up -d db.
• Tras el primer despliegue en Render, verificar en Supabase con las consultas del runbook (docs/operations/runbook.md, paso 5): el historial con 0 BASELINE, 1 SQL, 2 SQL, y ninguna tabla sin RLS.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud