# Clínica: preservación de perfiles y permisos en producción

## Objetivo

Permitir la evolución de los permisos clínicos sin cambiar las capacidades actuales de ningún usuario de producción.

La regla de compatibilidad es:

```text
clinical_permissions_v2 = false
→ no se usan asignaciones personalizadas
→ se conserva clinicProfile(), clinicCan(), módulos, niveles y permisos actuales
```

No se deben crear asignaciones `custom` automáticamente.

## Estado verificado en producción

La auditoría read-only ejecutada sobre el contenedor PHP 8.3 reportó:

| Tenant | Estado relevante |
|---|---|
| farmacia_mqn | 3 usuarios con perfil clínico sin módulo Clínica |
| farmacia_feypaz | perfiles clínicos válidos; el reporte antiguo marcaba 6 y 7 como fuera de rango por una matriz desactualizada |
| farmacia_gastromedic | perfiles clínicos válidos; el reporte antiguo marcaba 8 como fuera de rango por la misma razón |

Los perfiles 6, 7 y 8 son válidos:

```text
6 Enfermería
7 Caja
8 Recepción + Caja
```

La auditoría también confirmó que las 16 migraciones clínicas están registradas en los tenants productivos revisados: no hubo migraciones faltantes ni indeterminadas.

## Hallazgos que requieren revisión

### MQN

Los tres usuarios con perfil clínico sin el módulo Clínica deben revisarse individualmente. No se les debe agregar ni quitar acceso automáticamente. La decisión debe basarse en su configuración actual y en las funciones que realmente usan.

### Perfiles fuera de rango

El conteo anterior era un falso positivo de la auditoría, no una modificación de usuarios. La matriz válida debe aceptar los perfiles `1, 2, 3, 4, 5, 6, 7 y 8`.

### Datos históricos

Los hallazgos de archivos faltantes, cobros anulados referenciados o duplicados clínicos pertenecen a la auditoría de datos y no deben mezclarse con la migración de permisos. Se deben corregir en tareas separadas y con evidencia propia.

## Puerta de despliegue

Antes de activar `clinical_permissions_v2` se deben cumplir todos estos criterios:

1. Migraciones aditivas aplicadas sin ejecutar nuevamente migraciones históricas.
2. `clinical_permissions_v2` apagado en todos los tenants.
3. Cero asignaciones `custom` creadas automáticamente.
4. Baseline por usuario de módulos, niveles, flags y permisos efectivos.
5. Cero reducciones de permisos legacy para los perfiles que se vayan a personalizar.
6. Usuarios sin perfil o con datos inconsistentes listados para revisión, no migrados silenciosamente.
7. Pruebas de rutas backend y acciones AJAX con la misma autorización.
8. Prueba de rollback apagando únicamente el flag.

## Comandos de verificación

Auditoría clínica read-only en producción:

```bash
docker exec fpm_softlte_org_pe sh -lc \
  'cd /var/www/html && php artisan clinica:audit-baseline --format=text'
```

Reconciliación read-only de migraciones:

```bash
docker exec fpm_softlte_org_pe sh -lc \
  'cd /var/www/html && php artisan clinica:reconcile-migrations --format=json'
```

Baseline de permisos, cuando el cambio compatible ya esté desplegado:

```bash
docker exec fpm_softlte_org_pe sh -lc \
  'cd /var/www/html && php artisan clinica:permissions-baseline --tenant=UUID --format=json'
```

El baseline debe distinguir:

- impacto real con el flag apagado: debe ser `0`;
- reducciones potenciales al personalizar un perfil;
- ampliaciones;
- capacidades nuevas sin equivalente legacy.

## Estrategia de despliegue

No desplegar el árbol local completo mientras contenga cambios clínicos mezclados y sin commit.

El cambio debe dividirse en bloques revisables:

1. Corrección de auditoría de perfiles válidos.
2. Migraciones aditivas de permisos y alcance tenant-wide.
3. Servicio de autorización con fallback legacy.
4. Baseline read-only y pruebas.
5. UI de configuración, únicamente después de validar backend.

Cada bloque debe tener un commit explícito y una verificación posterior en producción.

## Rollback

Si después de una activación controlada aparece una restricción inesperada:

```text
clinical_permissions_v2 = false
```

No se deben borrar tablas, permisos ni usuarios para realizar rollback.

## Estado actual

- Producción no tiene todavía desplegado el baseline de permisos personalizado.
- Producción no tiene activado `clinical_permissions_v2`.
- No se modificaron usuarios ni permisos de producción.
- No se hizo commit ni deploy del árbol clínico local.

## Evidencia de la última revisión

- Checkout activo verificado: `3c22bb8d`.
- Marcador de deploy verificado con el mismo commit.
- `https://demo.sysfarma.pe/login` respondió HTTP `200`.
- `clinica:reconcile-migrations --format=json` reportó todos los tenants con 16 migraciones registradas, sin faltantes ni indeterminadas.
- La auditoría clínica se ejecutó dentro del contenedor PHP 8.3 en modo read-only.