# Identity Roadmap

## Objetivo general

Completar la transición desde el módulo legacy `auth` hacia `identity`, sin mezclar autenticación con autorización, tenant context, datos documentales o frontend legacy.

## Fase 1 · Backend auth runtime

Estado: prácticamente completado.

Incluye:

```txt
login
refresh rotado
logout
session
access token verifier
refresh token persistence
middlewares genéricos
```

Pendiente técnico recomendado:

```txt
- sanear typings de bcrypt/jsonwebtoken en identity
- revisar errores reales de node tsc
```

## Fase 2 · Migración backend desde `@erp/auth/api`

Estado:

```txt
catalogs          migrado
customers         migrado
customer-invoices migrado
factuges          migrado
supplier          pendiente intencionado
```

Siguiente decisión:

```txt
migrar supplier o mantenerlo legacy temporalmente
```

## Fase 3 · Frontend login

Objetivo:

Crear pantalla `/login` en Frontend ERP contra:

```http
POST /identity/auth/login
```

Debe implementar:

```txt
email/password
persistencia temporal de tokens
carga de sesión actual
logout básico
preparación para refresh automático
```

No incluir todavía:

```txt
register
forgot password
MFA
OAuth
roles/permisos
selección avanzada de empresa
```

## Fase 4 · Selección de empresa

Backend ya usa `X-Company-Id` para rutas tenant-scoped.

Pendiente:

```txt
GET /identity/companies
GET /identity/companies/current
PATCH /identity/companies/current
```

Frontend deberá:

```txt
listar empresas accesibles
permitir seleccionar empresa activa
enviar X-Company-Id en rutas tenant-scoped
```

## Fase 5 · Membership real

Actualmente `X-Company-Id` se valida sintácticamente pero no contra membership real.

Pendiente:

```txt
persistencia Company
persistencia CompanyMembership
validación accountId + companyId
bloqueo si membership disabled/invited
```

No validar membership en access token.

La validación debe ocurrir en backend por request o mediante contexto cacheado controlado.

## Fase 6 · Roles y permisos

Ya existe base conceptual:

```txt
Role
PermissionCode
PermissionDefinition
IPermissionCatalog
RolePermissionValidator
```

Pendiente:

```txt
RoleCreator
RoleUpdater
PermissionResolver
AuthorizationService
middleware authorize(permission)
endpoints /identity/roles
endpoints /identity/permissions
```

Reglas:

```txt
cada módulo declara sus propios permisos
identity no define permisos de otros módulos
Role.permissionCodes usa PermissionCode[] transversal
```

## Fase 7 · Registro y onboarding

No implementar registro público sin decisión previa.

Opciones futuras:

```txt
registro público
creación de primera empresa
invitaciones
alta interna por admin
```

Posible secuencia segura:

```txt
1. RegisterAccountUseCase
2. CreateInitialCompanyUseCase
3. CreateOwnerMembershipUseCase
4. Seed owner role
5. Emitir sesión
```

Debe evitarse:

```txt
crear cuentas sin empresa cuando el producto exige tenant
crear empresas sin owner
crear roles sin permisos válidos
```

## Fase 8 · Retirada de `modules/auth`

Solo posible cuando:

```txt
- supplier deje de usar @erp/auth/api
- frontend deje de usar @erp/auth/client
- no queden imports a @erp/auth en runtime
```

Antes de retirar:

```powershell
rg -n -F "@erp/auth" modules apps packages
rg -n -F "mockUser" modules apps packages
```

## Decisiones explícitas

No hacer:

```txt
- meter companyId en access token
- meter roles/permisos en access token
- meter companySlug en access token
- poblar companySlug desde auth middleware
- crear helpers auth por módulo
- usar getInternal("identity") desde módulos consumidores
- usar IdentityInternalDeps desde módulos consumidores
```

Sí hacer:

```txt
- usar requireIdentityTenant(params) en rutas tenant-scoped
- usar requireIdentityAuthenticated(params) en rutas solo autenticadas
- resolver datos documentales desde servicios específicos
- validar membership en backend cuando exista persistencia real
```