Plan Maestro de NewDescargos

Última actualización: 2026-04-23

Plan Activo

Fase 0. Gobierno documental y alineación base

Fase 0.3. Mensajería y credenciales internas

Fase 0.1. Arquitectura compartida

Estado: en curso
Decidir la creación de Betta.Descargos.Shared antes de seguir construyendo el flujo.
Definir que Shared contendrá DTOs, interfaces y enums reutilizables.
Definir que Shared no debe contener lógica de negocio ni comportamiento.
Crear la estructura base del proyecto y conectarla a la solución.
Agregar referencias iniciales desde Mvc y Service hacia Shared.
Validar compilación de la solución con Release.
Empezar a usar Shared como punto natural para contratos transversales nuevos.
Llevar a Shared los contratos anémicos necesarios para la clasificación y recomendación del flujo público.
Llevar a Shared los contratos anémicos específicos que aparezcan al implementar Checkout y post-pago.

Fase 0.2. Instrumentación interna de desarrollo

Estado: en curso
Definir la necesidad de un acceso visible en desarrollo para seguir el estado real del proyecto.
Crear una vista interna que renderice docs/plan-maestro.md.
Mostrar los checks completados en verde y los pendientes como no completados.
Agregar un acceso visible solo en ambiente Development.
Integrar Plan maestro al mismo menú superior del landing, condicionado a Development.
Agregar herramientas internas en Plan maestro para enviar templates de correo de prueba y abrir el login privado.
Extender la disponibilidad de Plan maestro a QA para validar remitentes, templates y flujos de credenciales por ambiente.
Extender este menú interno a otras herramientas de seguimiento si el proyecto lo necesita.

Fase 1. Página 1 — Landing de triage

Estado: completada
Reorientar la página a un único objetivo: avanzar al formulario de elegibilidad.
Mantener una top bar del estilo legacy, pero enfocada en las secciones reales del landing y sin salidas laterales al flujo.
Quitar el video del hero sin rehacer el mensaje base del legacy.
Mantener el copy legacy en los bloques que ya estaban bien y ajustar solo tono u orden donde sí aportaba.
Dejar la narrativa pública en este orden: hero, confianza rápida, consecuencia, qué obtienes, así funciona, precios, CTA final.
Eliminar del flujo público los elementos que contradicen la especificación operativa: formulario largo, WhatsApp flotante, FAQ, testimonios y cierres redundantes.
Ajustar precios a la versión funcional vigente: Estándar $199.000, Express $329.000.
Apuntar todos los CTA válidos de Página 1 a la Página 2.

Fase 2. Página 2 — Formulario de elegibilidad

Fase 3. Página 3 — Recomendación

Fase 4. Página 4 — Checkout

Fase 5. Post-pago y activación operativa

Estado: pendiente
Mantener el formulario post-pago accesible solo mediante link enviado por correo.
Asociar el formulario completado con la compra correspondiente.
Registrar el timestamp de recepción completa de antecedentes.
Dejar explícito que el SLA comienza solo cuando el pago está confirmado y los antecedentes están completos.
Mantener el estado actual con Google Form sin romper la futura migración a plataforma propia.
Transformar el lead en cliente cuando exista la administración interna aprobada.

Fase 6. Calidad, coherencia y cierre

Estado: pendiente
Verificar que el flujo completo tenga navegación controlada y no permita saltos manuales inválidos entre etapas.
Verificar mobile y desktop con foco en claridad, urgencia y baja fricción.
Validar que el copy visible siga alineado con los insumos funcionales vigentes y con las decisiones ya tomadas sobre legacy.
Confirmar que la implementación respete el sistema visual propio del proyecto.
Confirmar que los textos visibles mantengan UTF-8 correcto.

Confirmación Semántica del Flujo

Qué cambió con los documentos maestros

Los Documento Maestro de Descargos reforzaron cuatro criterios operativos que ya deben gobernar el proyecto:

Descargos se vende como un entregable jurídico productizado, no como una defensa integral abierta.
El mensaje principal debe ser seguridad y seriedad; la rapidez es crítica, pero secundaria al control del riesgo.
El funnel debe sentirse lineal, claro y con mínima fricción; no puede parecer una burocracia digital.
La calidad no se negocia ni puede sacrificarse para “hacer pasar” casos que el sistema ya no puede operar bien.

Qué ya cuadra con lo implementado

Página 1 funciona como landing de triage y empuja a Página 2 sin capturar datos.
Página 2 ya usa los dos inputs mínimos correctos, clasifica el caso y persiste el estado del flujo.
Página 3 ya existe con sus tres variantes funcionales (3A, 3B, 3C).
Ya existe una página propia para casos no elegibles (día 5+) que corta el proceso actual con un mensaje claro.
La UI de Página 2 y Página 3 ya quedó compactada para que la decisión principal entre mejor en pantalla.
El checkout ya existe como guest checkout visual con resumen visible, fecha de entrega y datos previos al pago.
El checkout ya exige aceptación de términos y cuenta con una página legal temporal para no dejar ese punto implícito.
El flujo público ya crea un lead persistente al verificar el caso y deja trazabilidad base de selección, checkout y salida a pago.
La trazabilidad de selección de plan ahora distingue si la elección ocurrió en recomendación o en checkout y si existió cambio respecto de la selección previa.
El proyecto ya usa Shared para DTOs y enums transversales del flujo público.
El plan maestro sigue visible desde la UI en desarrollo.

Qué todavía no cuadra

La integración real con Mercado Pago todavía no está conectada.
El pago online, la confirmación automática y el correo post-pago todavía no están implementados.
El formulario post-pago sigue fuera del proyecto propio.
La conversión del lead a cliente sigue pendiente hasta construir la administración interna.

Ambigüedades Abiertas

No quedan ambigüedades críticas para el flujo público hasta Página 3.
La siguiente definición material pendiente es si la integración con Mercado Pago saldrá por Checkout Pro (redirección) o Checkout Bricks (embebido).

Reglas de Mantenimiento de Este Plan

Este documento se actualiza cada vez que se completa, cambia, agrega, elimina o bloquea una tarea relevante del proyecto.
Si una tarea cambia de alcance, primero se corrige este plan y luego se implementa el cambio.
Si aparece una nueva dependencia funcional o técnica, debe quedar anotada aquí.
El estado del plan debe reflejar la realidad actual del proyecto, no una intención antigua.

Decisiones Vigentes

El sistema visual de NewDescargos se considera suficiente y vigente; no debe reintroducirse una dependencia de diseño hacia descargos.betta.cl.
El hero de Página 1 no lleva video.
El formulario de elegibilidad debe construirse usando el PDF de Página 2 como especificación de UI mínima.
El campo de fecha de elegibilidad usa un datepicker propio en desktop porque el calendario nativo no entrega control visual suficiente.
La lógica operativa del flujo completo debe implementarse según el documento Especificación funcional del flujo de adquisición — Descargos.
Betta.Descargos.Shared es el lugar para DTOs, interfaces y enums transversales sin lógica de negocio.
El caso no elegible (día 5+) se resuelve con una página propia que informa que el proceso actual no puede continuar.
El checkout se diseña como guest checkout y debe mantener coherencia con una integración futura de Mercado Pago.
La mensajería de NewDescargos toma como base técnica el proyecto Betta.Messaging de ArtService2026, adaptando solo branding, templates e integración local.
Las migraciones de EF Core deben generarse con dotnet ef; no deben crearse manualmente como práctica normal.
Este plan maestro es el documento operativo que acompaña el avance real del proyecto.

Registro de Cambios

2026-04-22

Se revisaron semánticamente los PDFs de Página 1 y Página 2.
Se creó el plan maestro vivo del proyecto.
Se registró la nueva regla de trabajo: actualizar este documento en cada tarea relevante.
Se definió la creación de Betta.Descargos.Shared como proyecto transversal anémico para DTOs, interfaces y enums reutilizables.
Se creó la estructura base de Betta.Descargos.Shared, se conectó a la solución y se validó compilación en Release.
Se creó una vista interna de desarrollo para revisar el plan maestro desde la UI del proyecto.
Se implementó la nueva Página 1 de triage alineada al flujo público vigente.
Se implementó la Página 2 de elegibilidad con validación mínima y persistencia en sesión.
Se ajustó la top bar de la Página 1 para navegar a las secciones reales del landing y mostrar Plan maestro en el mismo menú solo en Development.
Se corrigió el copy del hero para volver al wording del legacy y mantener solo el reemplazo del video.
Se redujo el espacio vertical entre la top bar y el inicio del hero para compactar mejor la entrada de la landing.
Se corrigió el centrado vertical excesivo del hero para subir el bloque principal y eliminar el vacío superior sobrante.
Se reordenó la Página 1 para dejar Así funciona antes de Precio claro desde el inicio.
Se devolvió la sección de consecuencias al wording del legacy para no rehacer un bloque que ya estaba bien.
Se ajustó el tono del bloque Sin vueltas. Sin letra chica... a un punto medio entre legacy y el nuevo enfoque, manteniendo sus bullets.
Se leyó completo el documento Especificación funcional del flujo de adquisición — Descargos.
Se leyó completo el contexto de negocio en Documento Maestro de Descargos_Parte 1 y Parte 2.
Se implementó la clasificación operativa del caso desde Página 2.
Se implementó la Página 3 real con variantes 3A, 3B y 3C.
Se agregó la página de no elegible para día 5+ con corte explícito del proceso actual.
Se compactaron las páginas de elegibilidad y recomendación para reducir scroll innecesario en desktop.
Se integró flatpickr de forma local para mejorar la selección de fecha en elegibilidad y unificar el tamaño visual del calendario.
Se alineó el tamaño del título de elegibilidad con la jerarquía visual de las otras páginas del flujo.
Se agregó un overlay bloqueante de Analizando con espera mínima y puntos rebotando al enviar elegibilidad para reforzar la sensación de trabajo en curso.
Se acortó la espera perceptible del overlay de análisis en elegibilidad a 1.5 segundos para mantener sensación de trabajo sin frenar de más el avance.
Se redujo la opacidad del overlay de análisis en elegibilidad para dejar más visible el contenido de fondo mientras el flujo queda bloqueado.
Se volvió a ensanchar la cabecera de recomendación para que título y subtítulo usen todo el ancho útil y se redujo un poco su escala visual.
Se alivianó el overlay de Analizando para que el fondo se siga leyendo mejor, apoyándose más en desenfoque que en opacidad.
Se eliminó el velo blanco del overlay de Analizando, dejando solo el desenfoque del fondo con la pantalla aún bloqueada.
Se eliminó también el panel blanco central del estado Analizando y se redujo el blur para que el efecto sea mucho más liviano.
Se movió el paso del wizard dentro del bloque principal de decisión en Página 3.
Se agregó la fecha de entrega visible y dinámica según plan en Página 3.
Se ajustó el tamaño del heading de la variante intermedia de recomendación y se corrigió el binding del submit para evitar refresh silencioso.
Se reubicó el encabezado de recomendación sobre ambas columnas para corregir el desbalance hacia la derecha.
Se dejó un acceso directo desde recomendación hacia checkout usando el plan actualmente visible.
Se cambió Página 3 para que cada card de plan tenga su propio botón Elegir este plan y el checkout abra con esa selección ya marcada.
Se reposicionó el CTA Elegir este plan dentro de la card para que quede más angosto y alineado arriba a la derecha sobre el precio.
Se reordenó el callout lateral de recomendación con un label operativo para mejorar la lectura de condiciones largas como la del caso intermedio.
Se corrigió la lógica de selección inicial en Página 3 para que, si el usuario aún no ha elegido, quede destacado el plan recomendado y no el plan por defecto.
Se llevó el card seleccionado de Página 3 al mismo estándar visual sobrio usado en checkout.
Se separó formalmente en Página 3 la recomendación del sistema de la elección posterior en checkout, dejando el destaque visual reservado solo para el plan recomendado y limpiando badges repetidos.
Se agregó soporte para badges verdes configurables por card en Página 3 y se usó en la opción Express del caso temprano con el mensaje Pero mientras antes mejor.
Se eliminaron los botones globales Continuar a pago e Ir directo al checkout del paso de recomendación.
Se reemplazó el paso 4 provisional por un guest checkout visual con resumen claro, fecha estimada de entrega y datos previos al pago.
Se agregó una pantalla explícita de traspaso a pago para validar el flujo completo antes de conectar Mercado Pago.
Se reorganizó la pantalla provisional de salida a pago en dos columnas con resumen más compacto y mejor distribución vertical.
Se agregó una salida secundaria desde checkout para revisar el paso siguiente aunque la pasarela aún no esté conectada.
Se investigó el estándar actual de checkout confiable con foco en Mercado Pago y checkout como invitado.
Se modeló persistencia base para leads del flujo público con entidad común (CreatedAtUtc, IsActive), historial del lead y pagos asociados para la futura integración real.
Se conectó la captura del lead al submit de elegibilidad para guardar teléfono, IP y fecha de cargos, y se registró trazabilidad adicional al confirmar plan, completar checkout y preparar la salida a pago.
Se ajustó el checkout para usar el título Proceder al pago, exigir aceptación de términos y exponer una página legal temporal.
Se dejó visible en el borde de pago el teléfono arrastrado desde elegibilidad como dato que viajará al formulario de la pasarela.
Se dejó el selector de plan del checkout siempre visible para mantener el cambio de opción dentro de ese paso.
Se reforzó el tracking del lead para registrar selección de plan con contexto de origen (recomendación o checkout) y cambio respecto de la selección previa.
Se reforzó el tracking del lead para registrar también aceptación de términos en checkout y salida a pago como hitos propios del historial.
Se reforzó visualmente la tarjeta seleccionada del checkout para que la opción activa se note mejor sin perder sobriedad.
Se corrigió la prioridad del plan al entrar a checkout para que la selección recién hecha en recomendación no quede tapada por un borrador anterior.
Se reforzó la sincronización inicial y dinámica del checkout para que la elevación del card seleccionado coincida siempre con el plan realmente traído desde recomendación.
Se reemplazó el realce rojizo del plan activo en checkout por una elevación más sobria basada en sombra y borde neutro.
Se afinó el realce del plan activo en checkout con borde más oscuro y una sombra un poco más profunda para mejorar lectura sin perder elegancia.
Se agregó un desplazamiento vertical de 5px hacia arriba al plan activo en checkout para reforzar la sensación de selección.
Se acotó la sombra del plan activo en checkout para que la elevación se perciba más corta y sutil, no tan desplazada.
Se agregó un zoom leve al plan activo en checkout para reforzar la selección sin volverlo estridente.
Se suavizó visualmente el bloque de términos del checkout para integrarlo mejor al formulario y bajar su sensación de invasividad.
Se bloqueó el pegado y arrastre en los dos campos de email del checkout, dejando mensajes claros para forzar escritura manual.
Se llevó el contenido de términos y condiciones a un modal con scroll dentro del checkout, manteniendo la página legal solo como respaldo.
Se agregó la instrucción documental que obliga a crear migraciones con dotnet ef y se incorporó al contexto del skill del proyecto.
Se creó el proyecto Betta.Messaging dentro de la solución tomando como referencia directa la implementación de ArtService2026.
Se integró la mensajería al backend de NewDescargos para recuperación de contraseña sobre Identity y para notificaciones automáticas a leads en hitos del pago.
Se materializaron páginas propias de Forgot password, Reset password y sus confirmaciones dentro del área Identity del MVC.
Se dejó el branding de correo listo para recibir la URL final del logo en CDN mediante configuración.

2026-04-24

Se agrego logging operacional mas fino al flujo de Mercado Pago en creacion de preferencia, retorno del navegador, webhook y sincronizacion contra el proveedor para diagnostico real en QA.
Se agrego el script scripts/Diagnose-MercadoPagoLead.ps1 para revisar por LeadId la traza completa de pago cruzando configuracion, base local, eventos y consulta directa a Mercado Pago.
Se agrego la consulta scripts/Diagnose-MercadoPagoLead.sql para diagnostico rapido por LeadId directamente desde SQL Server sin depender de PowerShell.
Se corrigio el publish del MVC para que los archivos docs/*.md viajen al deploy y Plan maestro pueda seguir leyendo docs/plan-maestro.md en QA.
Plan maestro ahora muestra un estado explicito si el markdown falta en el deploy, incluyendo la ruta esperada y la ruta resuelta en el servidor.
Se corrigio el modelo EF para que los enums de leads, historial y pagos se persistan como enteros en SQL Server en vez de texto.
Se genero la migracion StoreEnumsAsIntegers, que convierte los datos existentes de string a int y recompone los indices compuestos de LeadPayments.
La consulta scripts/Diagnose-MercadoPagoLead.sql quedo tolerante tanto a bases antiguas con enums en texto como a bases nuevas con enums en entero.

2026-04-23

Se configuró SMTP2GO con host mail.smtp2go.com, puerto 2525, usuario betta_qa_descargo_cl y la credencial entregada para el proyecto.
Se dejó no-reply@descargos.cl como remitente base y se parametrizó el nombre visible por ambiente: [DEV], [QA] y sin prefijo en Production.
Se dejó la cascada de configuración por ambiente con appsettings.Development.json, appsettings.QA.json y appsettings.Production.json.
Se ajustó el entorno local para trabajar con ASPNETCORE_ENVIRONMENT = Development.
Se crearon perfiles de publicación por carpeta para Development, QA y Production con destino D:\Descargos\[EnvironmentName].
Se validó un publish real con el perfil QA, confirmando despliegue a D:\Descargos\QA y generación de web.config con ASPNETCORE_ENVIRONMENT = QA.
Se configuró SMTP2GO en appsettings con host mail.smtp2go.com, puerto 2525 y el usuario betta_qa_descargo_cl.
Se agregó la URL final del logo en CDN para que los templates de correo usen la marca real de NewDescargos.
La salida del modo simulado quedó pendiente de completar con Password y FromEmail.
Se agregó en Plan maestro un modal para enviar correos de prueba seleccionando template y destinatario, con feedback mediante toast de éxito o error.
Se agregó un acceso directo al login privado desde Plan maestro para probar los flujos de recuperación y credenciales sobre Identity.
Plan maestro dejó de estar restringido solo a Development y ahora también queda visible en QA para validar mensajería por ambiente.
Se cambió el FromEmail de SMTP2GO a claudio@betta.cl, manteniendo los prefijos visibles por ambiente en el nombre del remitente.
El envío de prueba de Plan maestro ahora devuelve también el detalle real de la excepción SMTP en el feedback visual de Development y QA.
Se aclaró la cabecera superior de los templates activos de correo para que el logo no compita contra un bloque negro.
Se normalizaron los badges de los templates activos a un lenguaje visual de confirmación y se redujo ligeramente la escala de los títulos principales del correo.
Se desactivó el envío del correo lead-payment-prepared; el hito se mantiene en historial del lead para trazabilidad y estadística, pero ya no sale como notificación activa ni como template de prueba.
Se removieron del repo los valores sensibles versionados en appsettings.json y se dejó la configuración base con placeholders vacíos para conexión SQL, SMTP2GO y Mercado Pago.
Se agregó carga opcional de appsettings.Secrets.json y appsettings.[Environment].Secrets.json para soportar overrides seguros fuera de Git tanto en local como en publish por carpeta.
Se dejó appsettings.Secrets.example.json como plantilla versionada para reconstruir credenciales reales sin exponerlas.
Se documentó la estrategia oficial de User Secrets, archivos secretos ignorados y deploy por ambiente en docs/secretos-y-configuracion.md.
Se crearon localmente los archivos ignorados appsettings.Development.Secrets.json, appsettings.QA.Secrets.json y appsettings.Production.Secrets.json para que cada ambiente pueda completarse sin tocar el repo.
El publish del MVC ahora copia automáticamente solo el archivo secreto del ambiente objetivo, evitando mezclar credenciales de QA y Production en la misma salida.
El publish del MVC ahora excluye también los appsettings de otros ambientes para que cada carpeta publicada quede limpia y contenga solo la configuración del ambiente objetivo.
Se corrigió el fallback del selector de fecha en elegibilidad para QA: si flatpickr no está disponible, el input vuelve a type="date" y ya no intenta abrir showPicker() desde focus, evitando el error NotAllowedError.
Se forzó flatpickr en elegibilidad para todos los dispositivos, evitando que la librería delegue al selector nativo y manteniendo el calendario visual definido para el flujo.
Se eliminó el fallback silencioso al selector nativo en elegibilidad: ahora el flujo exige flatpickr y muestra un error explícito si la librería no carga, para evitar diferencias ocultas entre Development y QA.
Se agregó manejo de excepciones entendible en el flujo público: elegibilidad, recomendación, checkout y salida a pago ahora devuelven feedback visible en la misma pantalla, con detalle técnico resumido solo en QA y Development.
Se reemplazó la vista genérica de error por una versión más útil para diagnóstico, mostrando mensaje humano, Request ID, ruta y resumen técnico controlado según ambiente.
Se corrigió de fondo la estrategia de esquema en EF Core: el modelo y la tabla __EFMigrationsHistory quedaron fijados a dbo, y se agregó una migración correctiva que detecta y transfiere tablas creadas por error en otro esquema antes de continuar.
Se corrigió la carga de configuración en tiempo de diseño para EF Core: ApplicationDbContextFactory ahora lee también appsettings.Secrets.json y appsettings.[Environment].Secrets.json, y valida explícitamente que DefaultConnection no venga vacía antes de ejecutar migraciones.

Plan maestro del proyecto

Plan Maestro de NewDescargos

Plan Activo

Fase 0. Gobierno documental y alineación base

Fase 0.3. Mensajería y credenciales internas

Fase 0.1. Arquitectura compartida

Fase 0.2. Instrumentación interna de desarrollo

Fase 1. Página 1 — Landing de triage

Fase 2. Página 2 — Formulario de elegibilidad

Fase 3. Página 3 — Recomendación

Fase 4. Página 4 — Checkout

Fase 5. Post-pago y activación operativa

Fase 6. Calidad, coherencia y cierre

Confirmación Semántica del Flujo

Qué cambió con los documentos maestros

Qué ya cuadra con lo implementado

Qué todavía no cuadra

Ambigüedades Abiertas

Reglas de Mantenimiento de Este Plan

Decisiones Vigentes

Registro de Cambios

2026-04-22

2026-04-24

2026-04-23