docs(plan): brand fases 9–14 as MVP2
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 <noreply@anthropic.com>
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
27
README.md
27
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").
|
||||
|
||||
|
||||
@@ -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.**
|
||||
|
||||
@@ -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.**
|
||||
|
||||
@@ -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.**
|
||||
|
||||
@@ -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.**
|
||||
|
||||
@@ -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.**
|
||||
|
||||
@@ -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.**
|
||||
|
||||
Reference in New Issue
Block a user