{
  "_readme": "Lista blanca de usos APROBADOS de withTenantRepositoryExplicit()/withTenantDataSourceExplicit() — el escape explicito del contexto ambiental (ver tenancy/tenant-connection-registry.ts). No son ofensas pendientes de convertir: son excepciones de diseno permanentes (ej. auth resuelve el tenant, no puede depender de un contexto que el mismo produce). 'LISTO' = ofensas en cero Y bypasses reales exactamente iguales a esta lista. Agregar una entrada nueva, o subir el count de una existente, requiere aprobacion explicita del usuario en el diff — igual que un ofensor nuevo. Formato: archivo -> { count, justificacion }.",
  "approved": {
    "auth/auth.service.ts": {
      "count": 1,
      "justificacion": "AuthService resuelve el tenant (login) o lo recibe ya resuelto por un JWT valido (el resto de sus metodos) — nunca puede depender del contexto ambiental de TenantContextStorage, que en login todavia no existe y que mientras no exista el TenantGuard no puebla nadie. UN solo punto de entrada textual, y el UNICO archivo con el bypass (verificado con grep de withTenant.*Explicit en todo src/): el helper privado withTenantRepo(), usado por los 7 metodos publicos (login, refreshToken, getProfile, listUsers, listTiendas, updateTiendaPrintConfig, setUserActive) y por ensureTiendaActivaPorId()/createUser()/updateUser(), que lo anidan (dos adquisiciones del MISMO tenant ya cacheado cuando necesitan Usuario y Tienda en la misma operacion — seguro por diseno, documentado en TenantConnectionRegistry). Bajo de 2 a 1 respecto de la primera estimacion: la version inicial usaba un segundo helper que exponia la conexion completa y llamaba el metodo de repositorio directo sobre ella para poder tocar dos entidades — textualmente indistinguible para el escaner de la version peligrosa de ese mismo metodo, aunque fuera sobre una conexion ya resuelta por bypass. Eliminado en favor de anidar el unico helper de un repositorio, que ademas es mas simple. JwtStrategy NO usa este bypass (ni ningun otro): valida solo la firma del JWT y arma req.user de los claims, cero acceso a datos — una version anterior lo llamaba en cada request via validateUser() (eliminado), revertido por costo (duplicaba conexiones por request, ponia el acquireTimeout de tenant en el camino de autenticacion) y por diseno (un segundo punto de escape del contexto ambiental, fuera de auth.service.ts). Identidad/membresia/auditoria (plano de control) nunca se inyectan en auth/ — pasan por IdentityService, ya en la lista blanca de control-plane/."
    },
    "control-plane-admin/tenant-schema-check.service.ts": {
      "count": 2,
      "justificacion": "Panel de administracion de tenants: quien lo usa es un admin de PLATAFORMA (PlatformAdminGuard, rolPlataforma=admin_plataforma) inspeccionando un tenant EXPLICITO, elegido por id desde una lista de todos los tenants — nunca hay un 'tenant actual' en el sentido de TenantContextStorage, exactamente la misma situacion estructural que justifica el bypass de auth (login/refresh resolviendo un tenant que su propio contexto todavia no puede darle). Los 2 puntos de entrada textuales son getPendingMigrations() (compara `migrations` del tenant contra el codigo fuente real, via listSourceMigrationClassNames() — nunca una lista escrita a mano) y getColumnDeviations() (compara ds.entityMetadatas contra information_schema.columns del tenant, para detectar conflictos de tipo/tamaño en columnas EXISTENTES — las tablas/columnas faltantes las cubre el primer chequeo, nunca se duplican como 'desviacion'). Ninguno de los dos escribe en el tenant: ambos son de solo lectura, la escritura real (aplicar migraciones) es un paso posterior, todavia no implementado en esta ronda. tenants-admin.service.ts (el otro archivo de este modulo) NO tiene bypass ni ofensa: nunca inyecta Tenant/SchemaDeviation directo, pasa por TenantRecordsService (control-plane/, ya en la lista blanca) — mismo patron que auth/ con IdentityService."
    },
    "control-plane-admin/tenants-admin.service.ts": {
      "count": 1,
      "justificacion": "provisionarPrimerAcceso() crea el usuario local en la base de un tenant EXPLICITO (elegido por id, admin de plataforma via PlatformAdminGuard) para poder emitirle su primer login — exactamente la misma situacion estructural que justifica el bypass de tenant-schema-check.service.ts en este mismo modulo: no hay 'tenant actual' en el sentido de TenantContextStorage, es una operacion de plataforma sobre un tenant elegido explicitamente por id. allowOnboarding:true a proposito: este paso corre tipicamente ANTES de 'Activar' (alguien tiene que poder loguearse para terminar de verificar/reconciliar el tenant antes de darlo por activo). UN solo punto de entrada textual: el unico withTenantRepositoryExplicit() de este archivo, para Usuario. Nunca habilita 'suspendido' (mismo limite duro de TenantConnectionRegistry.createDataSource())."
    },
    "taller-parametros/taller-parametros.service.ts": {
      "count": 1,
      "justificacion": "AuthService resuelve tenantId desde el JWT sin TenantGuard (mismo motivo que su bypass existente para Tienda/Usuario) y necesita leer/escribir taller_parametros para /auth/tiendas*. control-plane-admin inspecciona tenants antes de Activar (mismo motivo que provisionarPrimerAcceso), con allowOnboarding:true, para el checklist operativo. Un único método privado (conRepositoriosExplicitos) concentra la única llamada a withTenantDataSourceExplicit del archivo -- toda la superficie explícita del servicio pasa por ahí."
    }
  }
}