Rechazo fundado

1. Objetivo

Establecer el procedimiento que sigue la organización para rechazar fundadamente la solicitud de incorporación de un solicitante: registrar el motivo, comunicarlo y conservar evidencia de que el rechazo tuvo fundamento objetivo.

2. Alcance

Cubre desde que la organización decide no incorporar a un solicitante hasta que el expediente queda en estado rechazado y el solicitante ha sido notificado.

No cubre:

• El proceso deliberativo previo de la organización para llegar a la decisión de rechazo. Ese proceso es humano y se rige por el reglamento interno.
• La observación de antecedentes incompletos, que es un estado previo al rechazo y es materia de [[wiki/entities/dispensai/protocolos/ADM-007]].
• El rechazo por receta vencida durante el acompañamiento, que es materia de [[wiki/entities/dispensai/protocolos/ATN-005]].
• La apertura de un ticket o queja por el solicitante rechazado, que es materia de [[wiki/entities/dispensai/protocolos/CAL-002]].

3. Definiciones

Rechazo fundado. La decisión de la organización de no incorporar a un solicitante, acompañada de un motivo que puede acreditarse. El fundamento no requiere ser una causal legal tasada, pero debe ser objetivo y consistente con los estatutos y el reglamento interno.

Motivo del rechazo. El texto que describe la razón de la decisión, registrado en profiles.rejection_reason. Es el elemento central que distingue un rechazo fundado de uno arbitrario.

Notificación de rechazo. El email enviado al solicitante con el motivo del rechazo.

4. Roles y responsables

Rol	Responsabilidad
Admin	Ejecutar el cambio de estado a rejected con el motivo fundado
Admisión	Verificar que el motivo está registrado antes de dar por cerrado el caso
Comité de revisión interna	Deliberar y comunicar a Admin la decisión cuando el rechazo no es evidente
Responsable de datos	Garantizar que el expediente rechazado se trate conforme a la política de retención de la organización

5. Disparador de inicio

La organización decide no incorporar al solicitante tras revisar su expediente. La decisión puede venir del revisor directo (casos evidentes) o del Comité de revisión interna (casos complejos).

6. Requisitos previos

• El expediente existe en el sistema con approval_status en pending o pending_interview.
• La organización tiene un fundamento documentado para el rechazo.
• Admin tiene rol admin en el sistema.

7. Entradas

• Expediente del solicitante.
• Texto del motivo del rechazo.
• Decisión de la organización (del revisor o del Comité).

8. Procedimiento paso a paso

1. Formulación del motivo. Antes de operar en el sistema, Admisión o el Comité formula con claridad el motivo del rechazo. El motivo debe ser comprensible para el solicitante, objetivo y coherente con los estatutos y el reglamento interno.
2. Registro del rechazo. Admin ejecuta el cambio de approval_status a rejected en el expediente, ingresando el motivo en el campo correspondiente. El sistema escribe rejection_reason en profiles junto con el cambio de estado.
3. Registro del evento ISO. El sistema emite el evento user_rejected con el estado anterior, el estado nuevo, el motivo, el identificador del solicitante y la fuente del cambio.
4. Notificación al solicitante. El sistema envía un email al solicitante con el motivo del rechazo mediante sendAccountRejectedEmail.
5. Cierre del expediente. El expediente queda en estado rejected. No se elimina; se conserva conforme a la política de retención de la organización.

9. Puntos de control

#	Control	Qué impide
C1	Solo un admin puede cambiar approval_status a rejected	Que un socio o tercero rechace expedientes
C2	El motivo se registra en rejection_reason junto con el cambio de estado	Que el rechazo quede sin fundamento documentado en el expediente
C3	El evento ISO user_rejected incluye el motivo y el estado anterior	Que no quede rastro del momento del rechazo ni de quién lo ejecutó
C4	El email de rechazo se envía con el motivo al solicitante	Que el solicitante no sepa por qué fue rechazado

10. Criterios de decisión

Rechazo procedente: el expediente presenta una o más causales objetivas de rechazo definidas en el reglamento interno de la organización, y el motivo puede formularse con claridad.

Rechazos que requieren Comité: cuando la causal no es evidente, cuando el expediente presenta inconsistencias o cuando el solicitante podría impugnar la decisión. En esos casos el Comité de revisión interna delibera antes de ejecutar el rechazo.

11. Excepciones y escalamiento

• El solicitante impugna el rechazo. La organización acredita el motivo con el rejection_reason registrado y el evento user_rejected. Si hay un ticket abierto, se gestiona conforme a [[wiki/entities/dispensai/protocolos/CAL-002]].
• El solicitante solicita conocer el motivo. El motivo está en rejection_reason y fue comunicado por email. La organización puede reenviar la comunicación.
• El rechazo se ejecuta sin motivo por error. Admin puede corregir el estado y el rejection_reason inmediatamente. El evento ISO ya emitido no se revierte, pero puede complementarse con un evento user_status_changed que documente la corrección.
• El solicitante presenta una nueva solicitud tras el rechazo. La organización evalúa si las causales persisten. El expediente anterior queda como antecedente.

12. Registros generados

Registro	Contenido
profiles.approval_status	Valor rejected
profiles.rejection_reason	Texto del motivo del rechazo
Evento ISO user_rejected	Estado anterior, estado nuevo, motivo, user_id, fuente, fecha
Email de rechazo	Enviado al solicitante con el motivo
Registro en audit_logs	Best-effort; ver brecha B3 en §17

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Rechazos con motivo registrado	Expedientes con rejection_reason no nulo ÷ total de expedientes con approval_status = 'rejected'	100 %	profiles
Rechazos con email enviado	Emails de rechazo enviados ÷ total de rechazos	100 %	Log de notificaciones
Latencia de comunicación	Fecha del email − fecha del cambio de estado	≤ 1 día hábil	Expediente vs. log de emails

14. Riesgos y controles

Riesgo	Control	Tipo
Rechazo sin motivo documentado	Registro de rejection_reason junto con el cambio de estado (C2)	Preventivo
Rechazo arbitrario impugnable	Motivo objetivo y coherente con reglamento; Comité para casos complejos	Preventivo
Solicitante sin notificación	Email automático con el motivo (C4)	Preventivo
Pérdida del rastro del rechazo	Evento ISO user_rejected (C3)	Detectivo
Acceso no autorizado al expediente rechazado	RLS de Supabase limita el acceso al expediente por rol	Preventivo

15. Normativa y referencias

Norma	Referencia	Qué cubre en este protocolo
Ley 20.500	Incorporación de asociados	La organización puede no admitir a quien no cumple los requisitos; el rechazo debe ser coherente con los estatutos
Ley 21.719	Art. 13	Si el tratamiento de datos fue de base contractual (en proceso de incorporación), el rechazo implica que el contrato no se formalizó; los datos siguen bajo el deber de confidencialidad y la política de retención
ISO 9001:2015	§8.2	Los requisitos del servicio se revisan antes de aceptar; si no se cumplen, no se acepta
ISO 9001:2015	§8.7	Las salidas no conformes se controlan y se documentan; el rechazo es la salida no conforme del proceso de admisión

El cumplimiento de estas normas no está certificado por ninguna autoridad. Este protocolo declara qué controles ejecuta la organización, no que un tercero los haya auditado.

16. Anexos y formularios vinculados

• Observación de antecedentes incompletos ([[wiki/entities/dispensai/protocolos/ADM-007]])
• Aprobación para acompañamiento interno ([[wiki/entities/dispensai/protocolos/ADM-009]])
• Apertura de ticket o queja ([[wiki/entities/dispensai/protocolos/CAL-002]])

17. Implementación en el sistema

El protocolo está implementado en la mutación del estado, el registro del motivo y la notificación al solicitante. Lo que no garantiza el sistema es que el motivo siempre esté presente, ni que el rastro del evento sea íntegro.

Elemento del protocolo	Dónde vive
Cambio de estado a rejected (paso 2)	app/actions/users.ts — función central de actualización; profiles.approval_status CHECK incluye 'rejected', supabase/migrations/20240101000000_baseline_schema.sql:44
Registro del motivo (paso 2, C2)	app/actions/users.ts:295-296 — escribe rejection_reason cuando status === 'rejected'; limpia el campo en cualquier otro estado
Evento ISO user_rejected (paso 3, C3)	app/actions/users.ts — logISOSystemEvent("user_rejected", "profiles", userId, user.id, { old_status, new_status, rejection_reason, source })
Notificación al solicitante (paso 4, C4)	app/actions/notifications.ts:102 — sendAccountRejectedEmail(userId, email, fullName, rejectionReason)
Registro de auditoría (paso 5)	app/actions/users.ts — void logAudit(...) fire-and-forget
Panel de admin (pasos 1-2)	app/admin/usuarios/[id]/page.tsx

Brechas conocidas:

1. rejection_reason no tiene restricción NOT NULL en la base de datos. La columna está definida como text nullable en supabase/migrations/20240101000000_baseline_schema.sql:45. El código asigna el valor cuando status === 'rejected', pero si se pasa un rejectionReason nulo o vacío, el campo queda nulo. No existe un CHECK de base de datos que exija rejection_reason IS NOT NULL WHERE approval_status = 'rejected'. El control C2 depende del código y del operador, no de la base de datos.
2. El evento ISO user_rejected es best-effort. El bloque logISOSystemEvent está dentro de try/catch; si falla, se registra en el log de la aplicación (log.error) pero el rechazo ya está firme y no se revierte. El control C3 no tiene garantía de integridad.
3. El rastro en audit_logs es fire-and-forget. logAudit se invoca con void; si falla, el rechazo ocurrió y no queda registro en la cadena de auditoría. Consistente con el precedente documentado en .claude/rules/dispensai.md: logAudit nunca lanza, y un tenant sin audit_logs pierde la evidencia sin ruido.
4. No se verifica que el email de rechazo fue entregado. sendAccountRejectedEmail es una llamada fire-and-forget no verificada en el flujo principal. Si el email falla, el expediente queda en rejected sin que el solicitante haya sido notificado.

Lo que ejecuta la organización fuera del sistema: la deliberación sobre el fundamento del rechazo es un proceso humano —revisión del expediente, consulta al Comité si corresponde, formulación del motivo— que ocurre antes de operar en el sistema. No es un defecto del software; es un paso que este protocolo reconoce como tal.

Brecha observada en auditoría 2026-08-31

• 📡 Evento user_rejected declarado pero no emitido — verificado por ausencia de call-sites en lib/ y app/ de dispensai/. El evento aparece definido en el type union de lib/iso-event-logger.ts pero ningún archivo de acciones lo invoca. Acción correctora: emitir el evento en la server action correspondiente, o quitar la declaración si el control se ejerce por otro medio.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-28	Versión inicial. Redactada desde la corrida de evidencia 2026-08-28-ADM-resto. Cuatro brechas declaradas.	Admisión
1.1	2026-08-29	Verificación de evidencia completada. rejection_reason nullable confirmado (20240101000000_baseline_schema.sql:45). sendAccountRejectedEmail confirmado en try/catch fire-and-forget (users.ts:490-494). logAudit fire-and-forget confirmado (invocado con void). Evento ISO best-effort confirmado. Cuatro brechas declaradas sin cambios; todas son reales. Protocolo ascendido a Vigente.	Admisión
1.0+audit-2026-08-31	2026-08-31	Detectados gaps en auditoría: user_rejected. §17 actualizada para documentar la brecha con evidencia de código. Estado documental sin cambio.	Auditoría automática