Aplicaciones y acceso
apps/frontend presenta el registro público en app.venezuelateayuda.com.
El panel y sus callbacks de autenticación viven en admin.venezuelateayuda.com.
Los enlaces administrativos publicados redirigen a ese dominio; el Service
Binding ADMIN se conserva para el desarrollo local. Los formularios de
coordinación están retirados.
Frontend y admin consultan apps/backend mediante BACKEND. Backend valida la
sesión original, los permisos y el alcance de organización o sede. Los campos
del navegador y las cabeceras de identidad no sustituyen esas comprobaciones.
Backend es el único propietario de D1, R2, secretos, correo, webhooks, cron y
Workflows. Marketing sirve el sitio estático y conserva enlaces antiguos mediante
redirecciones y Service Bindings al frontend y a la API pública. No accede a D1
ni a los secretos de proveedores.
Alcance del panel administrativo
El panel conserva personas, familias, contactos y organizaciones. Se retiraron calendario, solicitudes, inventario, pedidos, entregas, centros y colocaciones, incluidos sus paquetes, pantallas y operaciones. Las rutas retiradas,/forms/C36PV1U4, /forms/DU2INZQ4 y /delivery/:token devuelven 404.
El Inbox oculta notificaciones de coordinación; sus registros siguen almacenados.
Este retiro no modifica la base de datos, el esquema, las migraciones ni los
registros históricos. Se conservan temporalmente como respaldo. Las asignaciones
históricas de centros siguen limitando acceso a los registros de CRM. Las familias
nuevas no crean colocaciones; cambiar miembros tampoco altera colocaciones antiguas.
La persistencia y autenticación de claves API pertenecen a
apps/backend/src/api-keys; solo las definiciones de permisos compartidas viven en
packages/auth/constants. Los enlaces de atribución viven en packages/utils/links.
No existen paquetes separados api-keys ni links.
Importación y fuentes
La carga CSV mantiene sus formatos y validaciones documentados en Importar listas de personas. La aplicación administrativa presenta el formulario; backend autoriza la operación, almacena el archivo y coordina su Workflow. Las credenciales de fuentes externas no se incluyen en los ejemplos ni se crean durante el setup. La sincronización automática desde Venezuela Te Cuida y Pacientes Terremoto está retirada. No requiere credenciales nuevas ni debe reactivarse con el cron. Se mantienen las importaciones manuales autorizadas y el historial existente.packages/ingestions conserva la planificación, validación, reconciliación y
estado de ejecuciones. Los adaptadores específicos conservan sus cursores,
conteos del proveedor y reglas de reintento. El registro de fuentes sigue en
packages/ingestions/src/registry.ts. Desactivar una programación conserva
el perfil y el historial de la fuente.
El adaptador histórico de Venezuela Te Cuida mantiene marcas separadas para pacientes
e ingresos y vuelve a consultar un solapamiento de cinco minutos. Las filas
malformadas no bloquean las páginas posteriores. La deduplicación por identidad
de fuente evita crear otra persona al reprocesar un registro conocido.
Duplicados, historial y notificaciones
packages/duplicates decide coincidencias, revisiones y fusiones. Las fusiones
conservan su lote SQL atómico, los conflictos de identidad y fecha de nacimiento,
y el historial de las entidades relacionadas. Backend comprueba los permisos
y registra la auditoría. El orden de candidatos incluye un identificador único
para que los empates sean reproducibles.
Las lecturas de dominio usan páginas acotadas y orden estable. Cuando una
respuesta existente necesita una colección completa, backend recorre sus
páginas; no presenta solamente la primera página. La agrupación del historial
de fuentes ocurre después de reunir las páginas.
Las notificaciones conservan todos los destinatarios elegibles. La creación
usa sentencias compatibles con el límite de parámetros de D1 dentro de un
mismo lote atómico. La reclamación, reintento y envío del correo siguen siendo
responsabilidades distintas; crear una notificación no garantiza su entrega.
El cron de backend inicia únicamente la revisión de duplicados y la recuperación
de notificaciones por correo. Son tareas independientes: un fallo al iniciar la
revisión de duplicados no impide recuperar correos. Tras la conciliación de datos,
solo el backend nuevo ejecuta estas tareas cada 15 minutos. El cron del Worker
antiguo permanece desactivado; el cambio no reactiva fuentes externas.
Desarrollo y publicación
bun run dev carga Doppler y ejecuta las migraciones locales antes de iniciar
frontend y admin. Se accede a ambas aplicaciones por localhost:5173.
La persistencia local existente se conserva; no hay sincronización automática
con otro equipo.
Los 105 archivos SQL originales permanecen intactos. Un build no aplica
migraciones de producción. La primera publicación requiere coordinar los
Workflows activos y un único propietario del cron, configurar backend y
publicar backend, admin y frontend en ese orden. Véase
Service Bindings para los contratos y prerrequisitos.
Contacto canónico de personas
La migración0101_drop_person_reporter_fields.sql rellena los datos de contacto
canónicos que faltan y elimina las columnas antiguas persons.reporter_*.
Conserva los valores canónicos existentes. Los escritores de ingesta y las
semillas escriben únicamente contact_person_*; no existe escritura duplicada.
Los campos del autor de un reporte en la tabla reports se mantienen.
Ejecuta las migraciones locales antes de arrancar esta versión contra un estado
persistido anterior. La migración de producción se ejecuta en el despliegue autorizado.