Sistema LPDI · Plan técnico

Transferencia y baja de entidades — plan de construcción

Startup + ICG · flujo voluntario (T) y flujo de cierre de cuenta (C) · con las 5 decisiones cerradas.

Objetivo: transferir la propiedad de una entidad con aceptación expresa, ventana de aceptación de 10 días (recordatorios día 3/6/10), lista de sucesión (Startup: founders confirmados → resto; ICG: contacto → correo nuevo), manejo de la carrera recuperación-vs-confirmación dentro de los 30 días de gracia, y caída a anonimización cuando nadie acepta. Toda acción con doble confirmación y explicación previa del procedimiento.

✓ Decisiones cerradas (base del plan)

Sucesión Startup: founders confirmados primero (por orden de incorporación), luego resto. Top-3 sucesores reordenables: confirmados siempre; un correo nuevo nunca sobre un confirmado; si hay ≥3 confirmados, los 3 son confirmados.
Sucesión ICG: el contacto actual queda como primero por defecto pero no obligatorio, más un correo nuevo opcional.
Aceptación: 10 días en todos los casos, no reversible al aceptar. Si nadie acepta, el propietario sigue siendo dueño y puede reiniciar desde cero.
Cierre de cuenta: sucesión secuencial (hasta 3 flujos de 10 días). Se espera hasta el día 30 antes de anonimizar, aunque la cadena se agote antes (respeta la recuperación).
Onboarding del receptor: entra como miembro (Startup) / administrador (ICG); pantalla de bienvenida con su estatus + un solo CTA a completar el perfil.

W Olas de construcción

OlaTareasDepende de
01 · Schema entity_transfers + helpers de sucesión—
12 · Crear transferencia  |  3 · Aceptar / rechazar / cancelarOla 0
24 · Correos + inventario  |  5 · Cron (expiración + avance de sucesión)Ola 1
36 · UI «Eliminar / Transferir»  |  7 · Selector en cierre de cuenta  |  8 · Página pública aceptarOla 1, 2
49 · Recuperación ↔ cancelación  |  10 · ICG: contacto cierra cuentaOla 1, 3
511 · Caso C → anonimización + onboarding  |  12 · E2EOla 3, 4

12 Tareas (con criterios de verificación)

Ola 0

1 · Schema entity_transfers + helpers de sucesión

Tabla de transferencias (estado, rank de sucesión, token, deadline) + RLS + función build_startup_succession.

Ola 1

2 · RPC crear transferencia

Valida propiedad, aplica las reglas de sucesión (máx 3, confirmados siempre, máx 1 nuevo) y crea las filas pending.

Ola 1

3 · RPC aceptar / rechazar / cancelar

Aceptar cambia registered_by, coloca al receptor (miembro/administrador), limpia contacto ICG. No reversible.

Ola 2

4 · Correos + inventario oficial

5 correos: invitación, recordatorio (3/6/10), confirmada, caída, «ICG sin contacto».

Ola 2

5 · Cron — expiración + avance de sucesión

Vence pending, activa el siguiente rank, envía recordatorios; autenticado e idempotente.

Ola 3

6 · UI «Eliminar / Transferir» entidad (Flujo T)

Botón renombrado + modal de sub-flujo + panel de pendientes con cancelar. Sigue el DS de modales.

Ola 3

7 · Selector de destino en cierre de cuenta (Flujo C)

Por entidad: lista de sucesión reordenable (top-3) o eliminar; conserva el bloque «sin contacto» del ICG.

Ola 3

8 · Página pública «Aceptar transferencia»

Muestra entidad + estatus; login o creación de cuenta con TYC/PDP; bienvenida con CTA único.

Ola 4

9 · Enganche recuperación ↔ cancelación

Recuperar cuenta cancela transfers pending y devuelve la entidad; si ya estaba aceptada, no se revierte.

Ola 4

10 · ICG — el contacto cierra su cuenta

Limpia el contacto de inmediato, notifica al propietario con CTA a la FID; sin re-vínculo automático.

Ola 5

11 · Caso C → anonimización + onboarding

Si nadie aceptó al día 30: borra cuenta, cierra entidad, notifica a todos y anonimiza (Fase 2).

Ola 5

12 · E2E — flujos T y C, ambas entidades

Pruebas de flujo completo, incluida la carrera y el caso de anonimización.