[META-01][Nico] Emitir CompleteRegistration tras registro canónico aceptado

[nicoechaniz]

Resultado

Emitir el evento estándar Meta CompleteRegistration una sola vez cuando POST /v1/registrations termina exitosamente y devuelve registration.response.v1/REGISTERED, antes de navegar al checkout.

Reglas

• Nunca disparar al click ni ante validación local: sólo después de respuesta canónica 200/201 válida.
• Respetar el consentimiento vigente. Decline implica cero script, cookies y eventos Meta.
• No enviar nombre, apellido, email, términos, tokens ni otra PII.
• Deduplicar retries/idempotencia usando un identificador opaco derivado de registration_id, sin convertirlo en dato de audiencia.
• Funcionar para ES y EN con el mismo contrato.
• La navegación a Ticket Tailor no debe duplicar el evento ni quedar bloqueada por Meta.
• No hardcodear fecha: la publicidad es evergreen para eventos de todos los fines de semana y la sesión concreta pertenece al registro.

Aceptación

• Éxito canónico emite CompleteRegistration una vez con consentimiento.
• Error, timeout, validación local o Decline no lo emiten.
• Retry idempotente y refresh de la misma pestaña no duplican.
• No hay PII en parámetros ni logs.
• Tests cubren consentimiento, éxito, fallo, retry, lifecycle y navegación no bloqueante.
• La política bilingüe preparada en feat: prepare registration-v4 legal contract #22 describe CompleteRegistration.

Estado

Implementación completa y verificada en draft #16, apilada sobre registration-v4 #22. Falta únicamente el cutover coordinado: el Bot debe aceptar el par v4 exacto antes de publicar mientras la inscripción v3 está abierta.

Dependencias

No requiere un schema nuevo de respuesta de registro. La publicación sí depende de SairaAsua/proyecciones-mito#33 para dual-acceptance legal v3/v4 y coordinación de despliegue.

[nicoechaniz]

Implementation can proceed, but publication now has a legal/versioning dependency on SairaAsua/proyecciones-mito#33.

Verified: politica/index.html explicitly discloses only PageView and Purchase, and its registration-v3 SHA is pinned in the bot config, env examples and runbook. CompleteRegistration must not ship until the bilingual notice and canonical accepted-terms hash/version are coordinated without invalidating v3 evidence.

The frontend implementation will remain draft until that contract is available.

[nicoechaniz]

Frontend implementation is ready in draft PR #16.

Evidence:

• canonical REGISTERED boundary, never button click;
• consent accept/decline and delayed accept covered;
• retry/session deduplication;
• no PII/tokens/checkout context;
• malformed and non-REGISTERED responses fail closed;
• analytics cannot block checkout navigation;
• 26/26 tests and build pass.

Merge remains blocked by the registration-v4 notice/hash coordination in SairaAsua/proyecciones-mito#33.

[nicoechaniz]

Auditoría reforzada en PR #16 (head f996750):

• Accept → Decline → Accept funciona sin recarga y vuelve a otorgar consentimiento a Meta;
• mientras el consentimiento está revocado, un registro no emite nada; un grant explícito posterior procesa una vez el evento pendiente;
• refresh en la misma pestaña y retry no duplican;
• una excepción del listener analytics no rechaza REGISTERED ni bloquea el checkout;
• 30/30 tests, build y diff-check verdes.

Sigue sin publicarse: falta registration-v4/version/hash y coordinar el main abierto por Mariano.

[nicoechaniz]

registration-v4 está preparado en draft PR #22, head 2f238c8, sin publicar.

• v3 inmutable: 0d65e0c03acd635f08c3e04628a19ef0e674e08612e2ac2446502f3b10b6b54e;
• v4 final: c062b63921bf9a0d175a9770eaeaee647e65347bb3a1188285bc7c3706a1b773;
• v4 divulga PageView, CompleteRegistration, Purchase y su identificador opaco de deduplicación, sin PII;
• formulario/keys versionados y retorno v3 compatible;
• 22/22 tests, build legal y hashes source/dist verdes.

PR #22 y CompleteRegistration #16 siguen draft hasta que el Bot acepte el par v4 exacto y se coordine el cutover.

[nicoechaniz]

Corrección de artefacto antes de publicar: el hash final de registration-v4 es c062b63921bf9a0d175a9770eaeaee647e65347bb3a1188285bc7c3706a1b773 (PR #22 head 2f238c8). El texto ahora divulga también el identificador técnico opaco de conversión para deduplicar Purchase. Descartar el hash v4 anterior 3566…; v3 no cambió.

[nicoechaniz]

Estado final del draft antes de cutover: #16 head a16d7ce, apilada sobre #22. Dedupe cubre retry, refresh, segunda pestaña y migración del marcador de sesión previo; PageView tiene lifecycle explícito. Gate contra landing main bc3a8f1: merge sin conflictos, 36/36 tests, build, diff-check y hashes v3/v4 verdes. Chrome real confirmó consentimiento, revoke/regrant y cross-tab. Sigue bloqueada sólo la publicación coordinada con SairaAsua/proyecciones-mito#33.

[Mar-IA-no]

Coordinación backend aceptada y especificada en SairaAsua/proyecciones-mito#33: https://github.com/SairaAsua/proyecciones-mito/issues/33#issuecomment-5176114246

Tomamos los pares exactos de registration-v3/v4 preparados en PR #22. PMP Myth Bot implementará allowlist dual, persistencia exacta de versión+hash y preservación histórica de v3. El orden acordado es desplegar primero el backend compatible, verificar v3 y recién después publicar registration-v4 y CompleteRegistration.

[nicoechaniz]

Estado actualizado: #16 head 93ec1ba está rebaseada sobre #22 y el landing main vigente; 41/41 tests + build + diff-check verdes, cobertura explícita ES/EN y Chrome sintético sin PII. Sigue abierta únicamente por el cutover coordinado de dual-acceptance v3/v4 en SairaAsua/proyecciones-mito#33.