From 93153cd7509b5e56694c21e34fd259540cc316e3 Mon Sep 17 00:00:00 2001 From: Oier Bravo Urtasun Date: Mon, 18 May 2026 00:42:08 +0200 Subject: [PATCH] =?UTF-8?q?docs(plan):=20brand=20fases=209=E2=80=9314=20as?= =?UTF-8?q?=20MVP2?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Stamps the six planned post-MVP fases as the MVP2 cycle (matching the `mvp2` branch name). Each plan file gets an "MVP2 · N/6" header. README status + index tables group them under an MVP2 bracket. CLAUDE.md project status reframes the planned line as MVP2 and clarifies that Fase 7+8 shipped as MVP cleanup, not MVP2. Co-Authored-By: Claude Opus 4.7 --- CLAUDE.md | 2 +- README.md | 27 ++++++++++++++------------- plan/fase-10-spec-completion.md | 2 ++ plan/fase-11-item-tags-importance.md | 2 ++ plan/fase-12-section-visibility.md | 2 ++ plan/fase-13-server-admin.md | 2 ++ plan/fase-14-pwa-hardening.md | 2 ++ plan/fase-9-polish-dark-mode.md | 2 ++ 8 files changed, 27 insertions(+), 14 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index fcf95d8..873cc23 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -6,7 +6,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co **Fase 0–5 complete. Fase 6 complete (deploy readiness: PWA injectManifest SW + manifest + iOS meta tags + placeholder icons + Kong rate-limit on invitations + dev JWT rotation + prod env template + rls-audit.sh + Justfile lighthouse/rls-audit/test-rate-limit). Production stack deployed to ambrosio (OVH VPS) at https://erosi.limonia.net (app + Supabase, external Keycloak); edge proxy now off-stack — internal Caddy fans kong/app on host port 3000, whatever external proxy fronts the host terminates TLS and forwards plain HTTP to ambrosio:3000 (originally NetBird's self-hosted Traefik, now proxy-agnostic); PWA strategy switched to generateSW to unblock the prod build (see the "injectManifest hardcoded filename" gotcha below). Fase 7 complete: 12 new Playwright tests fill the collective-flow UI gap (O-01..O-03 onboarding, I-01..I-05 invitation acceptance, MC-02..MC-05 admin-manage) — writing them surfaced + fixed three latent bugs in the product code (atomic `create_collective()` RPC, pendingInvitationToken restore after login, manage page not reloading on late $currentCollective hydration). Plus migration 013 (auth.users role/aud default trigger) — found after the first real self-registration on prod via Keycloak→GoTrue left the user with empty `role`/`aud` columns, breaking every REST call with `role "" does not exist`. Post-fase-7 prod auth hardening (2026-04-20..21, see `docs/history/fase-8-auth-logout.md`): migration 014 extends the role/aud guard to UPDATE (GoTrue's pop-ORM resends role='' right after the INSERT and clobbered the INSERT trigger's backfill); `logout()` now does RP-initiated Keycloak end-session + lands on a new public `/logged-out` route, which both actually ends the Keycloak SSO cookie (so the next login re-prompts) and closes a PKCE-verifier race that produced "PKCE code verifier not found in storage" on prod. 259 tests green: 45 pgTAP + 140 Vitest integration + 15 Vitest unit + 59 Playwright + 1 Vitest rate-limit (gated, run via `just test-rate-limit`). 3 skipped in `just test-all` (2 Realtime presence — upstream `handle_out/3` bug; 1 rate-limit — gated). Push notifications + CI Docker + final production icons deliberately out of scope. ✅** -**Planned (📋):** Fase 9 polish + dark mode (`plan/fase-9-polish-dark-mode.md`) | Fase 10 spec completion — CU-H06/H07/H08, trash restore, account hard-delete, sidebar create, list reset, lang detect (`plan/fase-10-spec-completion.md`) | Fase 11 item tags + drag-reorder (`plan/fase-11-item-tags-importance.md`, migration 021) | Fase 12 section visibility — JSONB `feature_flags` on `users`+`collectives`, `section_enabled()` SQL helper (`plan/fase-12-section-visibility.md`, migration 022) | Fase 13 server administration — `/admin` area, `server_admins` table, audit log, server-level visibility defaults, depends on Fase 12 (`plan/fase-13-server-admin.md`, migrations 023+024) | Fase 14 PWA hardening — update toast, offline polish, version chip, depends on Fase 9.3 (`plan/fase-14-pwa-hardening.md`, no migration). +**MVP2 — planned (📋):** branch `mvp2` carries the next product cycle. Six fases, all unstarted: Fase 9 polish + dark mode (`plan/fase-9-polish-dark-mode.md`) | Fase 10 spec completion — CU-H06/H07/H08, trash restore, account hard-delete, sidebar create, list reset, lang detect (`plan/fase-10-spec-completion.md`) | Fase 11 item tags + drag-reorder (`plan/fase-11-item-tags-importance.md`, migration 021) | Fase 12 section visibility — JSONB `feature_flags` on `users`+`collectives`, `section_enabled()` SQL helper (`plan/fase-12-section-visibility.md`, migration 022) | Fase 13 server administration — `/admin` area, `server_admins` table, audit log, server-level visibility defaults, depends on Fase 12 (`plan/fase-13-server-admin.md`, migrations 023+024) | Fase 14 PWA hardening — update toast, offline polish, version chip, depends on Fase 9.3 (`plan/fase-14-pwa-hardening.md`, no migration). Fase 7+8 already shipped as MVP cleanup, not MVP2. ## Documentation Map diff --git a/README.md b/README.md index 6750f32..19c4a0a 100644 --- a/README.md +++ b/README.md @@ -19,12 +19,13 @@ | Fase 6 — Deploy readiness | ✅ Completa (PWA generateSW + manifest + iconos placeholder + Kong rate-limit en invitaciones + rotación JWT dev + rotate-jwt.sh + `.env.erosi.example` + rls-audit.sh + `just lighthouse`). Rate-limit auth retirado — Keycloak brute-force nativa cubre el caso. Push notifications y iconos finales fuera de scope. | | Fase 7 — Collective-flow E2E tests | ✅ Completa (12 Playwright nuevos O-01..MC-05; 3 bugs latentes corregidos: RPC atómica `create_collective`, restore de `pendingInvitationToken` tras login, hidratación tardía de `$currentCollective` en manage; migración 013 trigger `role/aud` default). | | Fase 8 — Prod auth hardening | ✅ Completa (migración 014 extiende `role/aud` guard a UPDATE; `logout()` RP-initiated Keycloak end-session + ruta pública `/logged-out`). | -| Fase 9 — Polish + Dark Mode | 📋 Planificada | -| Fase 10 — Spec completion | 📋 Planificada | -| Fase 11 — Item tags + importance UX | 📋 Planificada | -| Fase 12 — Section visibility | 📋 Planificada | -| Fase 13 — Server administration | 📋 Planificada (depende de Fase 12) | -| Fase 14 — PWA hardening | 📋 Planificada (depende de Fase 9.3) | +| **MVP2** — Fase 9 → 14 | 📋 Planificada (rama `mvp2`) | +| ↳ Fase 9 — Polish + Dark Mode | 📋 | +| ↳ Fase 10 — Spec completion | 📋 | +| ↳ Fase 11 — Item tags + importance UX | 📋 | +| ↳ Fase 12 — Section visibility | 📋 | +| ↳ Fase 13 — Server administration | 📋 (depende de Fase 12) | +| ↳ Fase 14 — PWA hardening | 📋 (depende de Fase 9.3) | | Suite de tests (pgTAP + Vitest + Playwright) | ✅ 259 tests verdes (45 pgTAP + 140 integración + 15 unit + 59 E2E) + 1 rate-limit gated (`just test-rate-limit`). 3 skipped en `just test-all`. | --- @@ -52,14 +53,14 @@ Las fases ya cerradas (0, 1, 2a) reflejan este patrón retroactivamente: la secc | Fase 5 | [fase-5-mobile-ux.md](plan/fase-5-mobile-ux.md) | 1–2 semanas | | Fase 6 | [fase-6-deploy-prep.md](plan/fase-6-deploy-prep.md) | 3–5 días | | Fase 7 | [fase-7-collective-flow-tests.md](plan/fase-7-collective-flow-tests.md) | 1 semana | -| Fase 9 | [fase-9-polish-dark-mode.md](plan/fase-9-polish-dark-mode.md) | 1–2 semanas | -| Fase 10 | [fase-10-spec-completion.md](plan/fase-10-spec-completion.md) | 2–3 semanas | -| Fase 11 | [fase-11-item-tags-importance.md](plan/fase-11-item-tags-importance.md) | 1–2 semanas | -| Fase 12 | [fase-12-section-visibility.md](plan/fase-12-section-visibility.md) | 1 semana | -| Fase 13 | [fase-13-server-admin.md](plan/fase-13-server-admin.md) | 2–3 semanas | -| Fase 14 | [fase-14-pwa-hardening.md](plan/fase-14-pwa-hardening.md) | 3–5 días | +| **MVP2 — Fase 9** | [fase-9-polish-dark-mode.md](plan/fase-9-polish-dark-mode.md) | 1–2 semanas | +| **MVP2 — Fase 10** | [fase-10-spec-completion.md](plan/fase-10-spec-completion.md) | 2–3 semanas | +| **MVP2 — Fase 11** | [fase-11-item-tags-importance.md](plan/fase-11-item-tags-importance.md) | 1–2 semanas | +| **MVP2 — Fase 12** | [fase-12-section-visibility.md](plan/fase-12-section-visibility.md) | 1 semana | +| **MVP2 — Fase 13** | [fase-13-server-admin.md](plan/fase-13-server-admin.md) | 2–3 semanas | +| **MVP2 — Fase 14** | [fase-14-pwa-hardening.md](plan/fase-14-pwa-hardening.md) | 3–5 días | -**Total estimado MVP (Fase 0–6): 11–16 semanas. Post-MVP (Fase 7–14): 10–14 semanas adicionales.** +**Total estimado MVP (Fase 0–6): 11–16 semanas. MVP2 (Fase 9–14, rama `mvp2`): 10–14 semanas. Fase 7+8 entre MVP y MVP2 como cleanup post-launch.** Los mockups de referencia viven en [`design/`](design/) (organizados por pantalla — ver `design/slate_collective/DESIGN.md` para la dirección "Monolith Editorial"). diff --git a/plan/fase-10-spec-completion.md b/plan/fase-10-spec-completion.md index 43c37fc..1a894ad 100644 --- a/plan/fase-10-spec-completion.md +++ b/plan/fase-10-spec-completion.md @@ -1,5 +1,7 @@ ### Fase 10 — Spec completion ("cerrar la laguna del `analisis-funcional`") +**MVP2 · 2/6.** Segunda fase del ciclo MVP2 (rama `mvp2`, fases 9 → 14). + **Estado: 📋 Planificada. Cubre las 8 piezas de "completion debt" detectadas en el audit del 2026-04-22: 3 CU de gestión de colectivo (H06/H07/H08), 3 afordances de contenido ya construido (trash restore, reset-from-detail, sidebar create-collective), eliminación de cuenta, y detección automática de idioma.** **Objetivo: llevar la paridad con `analysis/analisis-funcional.md` al 100% en el eje de gestión de colectivo y ciclo de vida de usuario/contenido — todo lo que los usuarios empiezan a pedir desde el primer día de uso real.** diff --git a/plan/fase-11-item-tags-importance.md b/plan/fase-11-item-tags-importance.md index 3d62cfc..60129d0 100644 --- a/plan/fase-11-item-tags-importance.md +++ b/plan/fase-11-item-tags-importance.md @@ -1,5 +1,7 @@ ### Fase 11 — Item tags + importance UX +**MVP2 · 3/6.** Tercera fase del ciclo MVP2 (rama `mvp2`, fases 9 → 14). + **Estado: 📋 Planificada. Cierra dos huecos en la experiencia del item de compra: clasificación libre por tags (scope colectivo) y reordenación explícita por arrastrar (importance).** **Objetivo: enriquecer el item sin tocar el dominio core. La columna `sort_order` ya existe en `shopping_items` (migración 005) y el store ya escribe `update sort_order` en batch al reordenar (`apps/web/src/lib/stores/lists.ts:224`); falta el handle de drag visible en la fila de item. Los tags son nuevos — modelo + UI + filtros.** diff --git a/plan/fase-12-section-visibility.md b/plan/fase-12-section-visibility.md index 276ad15..3d08544 100644 --- a/plan/fase-12-section-visibility.md +++ b/plan/fase-12-section-visibility.md @@ -1,5 +1,7 @@ ### Fase 12 — Section visibility (feature toggles user + colectivo) +**MVP2 · 4/6.** Cuarta fase del ciclo MVP2 (rama `mvp2`, fases 9 → 14). + **Estado: 📋 Planificada. Permite a cada usuario ocultar secciones top-level que no usa, y a admins de colectivo ocultarlas para todo el colectivo. Pre-requisito para Fase 13 (server admin reusa el mismo modelo a nivel servidor).** **Objetivo: dar control granular sobre las cuatro secciones top-level actuales (Lists, Tasks, Notes, Search) sin construir un sistema de plugins. Cierra dos peticiones: usuarios que solo usan compra, y colectivos chiquitos que no necesitan tareas/notas.** diff --git a/plan/fase-13-server-admin.md b/plan/fase-13-server-admin.md index 7b859ee..3be5af0 100644 --- a/plan/fase-13-server-admin.md +++ b/plan/fase-13-server-admin.md @@ -1,5 +1,7 @@ ### Fase 13 — Server administration +**MVP2 · 5/6.** Quinta fase del ciclo MVP2 (rama `mvp2`, fases 9 → 14). + **Estado: 📋 Planificada. Mayor salto de scope hasta ahora — introduce un rol global ortogonal a los roles de colectivo, un área `/admin` nueva, RPCs con privilegios elevados, y un audit log. Requiere Fase 12 para los toggles de visibilidad a nivel servidor.** **Objetivo: dar al operador del servidor herramientas para gestionar la salud de la instancia sin tocar SQL en producción — listar y borrar colectivos huérfanos, expulsar miembros problemáticos, fijar visibilidad por defecto de secciones a nivel servidor, y dejar trazabilidad de cada acción.** diff --git a/plan/fase-14-pwa-hardening.md b/plan/fase-14-pwa-hardening.md index ae65ae9..c4d10d0 100644 --- a/plan/fase-14-pwa-hardening.md +++ b/plan/fase-14-pwa-hardening.md @@ -1,5 +1,7 @@ ### Fase 14 — PWA hardening (auto-update + offline polish + version chip) +**MVP2 · 6/6.** Última fase del ciclo MVP2 (rama `mvp2`, fases 9 → 14). + **Estado: 📋 Planificada. Pulido del PWA que Fase 6 dejó funcional pero crudo. Sin migraciones de DB. Depende de Fase 9.3 (wiring de `sync_conflicts`) para el badge de conflictos.** **Objetivo: convertir el PWA de "técnicamente instalable" a "se actualiza solo, avisa cuando estás offline, y muestra qué versión corres". Tres asks pequeños, una fase pequeña.** diff --git a/plan/fase-9-polish-dark-mode.md b/plan/fase-9-polish-dark-mode.md index d84b0a2..7e5e8a1 100644 --- a/plan/fase-9-polish-dark-mode.md +++ b/plan/fase-9-polish-dark-mode.md @@ -1,5 +1,7 @@ ### Fase 9 — Polish + Dark Mode +**MVP2 · 1/6.** Primera fase del ciclo MVP2 (rama `mvp2`, fases 9 → 14). + **Estado: 📋 Planificada. Feature flagship: dark mode. Además de los tres pulidos pendientes heredados de Fase 5/6 y el wiring de `sync_conflicts` nunca conectado.** **Objetivo: estabilizar la experiencia visual con un tema oscuro de primera clase + cerrar cuatro pulidos que se quedaron fuera del MVP sin añadir deuda técnica nueva. No se tocan features de dominio — eso queda para Fase 10.**