Tu preocupación es completamente válida y la tomé en serio. Antes de tocar una sola línea, el architect hizo una auditoría exhaustiva de **ambos formularios** (4300+ LOC cada uno). Aquí van los hallazgos: --- **LAP-290** creado — Refactor ICG unificado. ### Lo que encontramos: SÍ hay diferencias críticas que se deben preservar El architect identificó **6 escenarios de creación** que el componente compartido DEBE manejar: | Escenario | Contexto | Auth | Acción DB | |---|---|---|---| | **A** | Público, email nuevo | Crea cuenta Supabase + auto-confirm | INSERT | | **B** | Público, email existente | signInWithPassword | INSERT | | **C** | Público, ya logueado | Usa sesión existente | INSERT | | **D** | Dashboard, crear nueva | Sesión garantizada | INSERT (force_new) | | **E** | Dashboard, editar existente | Sesión garantizada | UPDATE por ID | | **F** | Dashboard, sin params | Sesión garantizada | Busca draft → UPDATE • | ### El bug de sobreescritura que reportaste Lo encontramos: en el dashboard, cuando un usuario entra a `/dashboard/icg/nuevo` **sin** `?force_new=true`, el server busca un ICG con `status=DRAFT` del usuario y lo **sobreescribe**. Si ese draft era un ICG anterior incompleto, se pierde. ### El plan de refactor (seguro, por fases): 1. **PRIMERO** — Corregir el bug de sobreescritura (tallaje S, independiente) 2. **SEGUNDO** — Extraer tipos + loader + action compartidos en archivos server reutilizables 3. **TERCERO** — Crear `IcgRegistrationForm.svelte` con prop `mode` que bifurca: - `mode='public'` → muestra email check, password, términos/privacidad - `mode='dashboard'` → no pide email/password, usa sesión 4. **CUARTO** — QA por cada escenario (A-F) individualmente ### Lo que se PRESERVA (garantizado por diseño): - • Validación de correo con debounce solo en ruta pública - • Detección email nuevo vs existente → flujo de password distinto - • Términos/privacidad solo para usuarios nuevos - • FI sin usuario registrado → crea cuenta - • FI de usuario existente → autentica - • FI adicional desde dashboard → INSERT, nunca sobreescribe - • Edición explícita → UPDATE solo con ID específico **¿Aprobás este plan para arrancar? Sugiero empezar por el fix del bug de sobreescritura (es rápido y tiene impacto inmediato), y luego el refactor por fases.** • _Nota del sistema: este cambio NO fue validado por qa_agent/TestSprite (verificado a nivel de tool invocation, no solo texto). Verifica manualmente antes de dar por cerrado._