// engine/spec-templates/templates-industry-saas.ts — SaaS industry templates.
// AC-04: Templates by industry — SaaS vertical (multi-tenant, billing, RBAC).
/** SaaS multi-tenant template. */
export const SAAS_MULTI_TENANT_TEMPLATE = {
    id: 'saas-multi-tenant',
    name: 'Arquitectura multi-tenant',
    category: 'industry',
    subcategory: 'saas',
    description: 'Aislamiento de datos por tenant, subdominios y configuracion por tenant.',
    tags: ['saas', 'multi-tenant', 'isolation', 'tenancy'],
    complexityScore: 'XL',
    estimationBase: {
        hoursMin: 80,
        hoursMax: 160,
        notes: 'Arquitectura fundamental que impacta todas las capas',
    },
    criteria: [
        { id: 'AC-1', title: 'Aislamiento de datos', required: true },
        { id: 'AC-2', title: 'Resolucion de tenant', required: true },
        { id: 'AC-3', title: 'Configuracion por tenant', required: true },
        { id: 'AC-4', title: 'Onboarding de tenant', required: true },
        { id: 'AC-5', title: 'Limites por tenant', required: true },
        { id: 'AC-6', title: 'Operaciones cross-tenant', required: false },
    ],
    variables: [
        {
            key: 'PlatformName',
            label: 'Nombre de la plataforma',
            description: 'Nombre de la plataforma SaaS',
            example: 'CloudApp',
            required: true,
        },
    ],
    huTemplate: `# HU: Multi-Tenant — {{PlatformName}}

## Historia de Usuario
Como operador de {{PlatformName}}, quiero que cada tenant tenga sus datos aislados y su configuracion independiente para ofrecer un servicio seguro y personalizable.

## Criterios de Aceptacion

### AC-1: Aislamiento de datos
- [ ] Los datos de cada tenant son inaccesibles para otros tenants
- [ ] Las consultas a base de datos filtran por tenant automaticamente
- [ ] No existe ruta de acceso que permita cross-tenant sin autorizacion explicita
- [ ] Las pruebas verifican que el aislamiento funciona correctamente

### AC-2: Resolucion de tenant
- [ ] El tenant se resuelve desde subdominio, header o token segun la estrategia elegida
- [ ] La resolucion es transparente para el codigo de negocio
- [ ] Solicitudes sin tenant valido son rechazadas con error claro

### AC-3: Configuracion por tenant
- [ ] Cada tenant puede personalizar branding (logo, colores, nombre)
- [ ] Las configuraciones de funcionalidad son independientes por tenant
- [ ] Los valores por defecto se heredan de la configuracion global

### AC-4: Onboarding de tenant
- [ ] El alta de un nuevo tenant es automatizada (no requiere intervencion manual)
- [ ] Se provisionan los recursos necesarios (schema/namespace/bucket)
- [ ] El administrador del tenant recibe credenciales de acceso

### AC-5: Limites por tenant
- [ ] Cada tenant tiene limites de uso configurables (usuarios, storage, API calls)
- [ ] Se notifica al tenant cuando se acerca a sus limites
- [ ] Exceder limites bloquea operaciones nuevas (no las existentes)

### AC-6: Operaciones cross-tenant (solo para superadmin)
- [ ] El superadmin puede consultar metricas agregadas de todos los tenants
- [ ] Las operaciones de mantenimiento pueden ejecutarse por tenant o globalmente
`,
    fichaTecnicaTemplate: `# FICHA TÉCNICA: Multi-Tenant — {{PlatformName}}

## Archivos Afectados
- tenancy/resolver
- tenancy/isolation-middleware
- tenancy/config-manager
- tenancy/onboarding
- tenancy/limits

## Tipos / Entidades
- \`Tenant\`: id, name, slug, config, limits, createdAt
- \`TenantConfig\`: branding, features, defaults
- \`TenantLimit\`: type, maxValue, currentValue

## Riesgos
- Fuga de datos entre tenants → filtrado automatico + tests de aislamiento
- Onboarding lento → provisionamiento asincronico con status tracking
- Limites no respetados → middleware de verificacion en cada request

## Estimacion
- Dev: 80–160 horas
- Review: 16–32 horas
- Dificultad: 5/5
`,
    progressTemplate: `# PROGRESS: Multi-Tenant — {{PlatformName}}

## Estado: borrador

## Criterios
- [ ] AC-1: Aislamiento de datos
- [ ] AC-2: Resolucion de tenant
- [ ] AC-3: Configuracion por tenant
- [ ] AC-4: Onboarding de tenant
- [ ] AC-5: Limites por tenant
- [ ] AC-6: Operaciones cross-tenant
`,
};
/** SaaS billing and subscriptions template. */
export const SAAS_BILLING_TEMPLATE = {
    id: 'saas-billing',
    name: 'Facturacion y suscripciones',
    category: 'industry',
    subcategory: 'saas',
    description: 'Planes de suscripcion, upgrades, facturacion PDF y webhooks de pago.',
    tags: ['saas', 'billing', 'subscriptions', 'invoices', 'payments'],
    complexityScore: 'L',
    estimationBase: {
        hoursMin: 40,
        hoursMax: 80,
        notes: 'Incluye integracion con pasarela de pago y generacion de facturas',
    },
    criteria: [
        { id: 'AC-1', title: 'Planes de suscripcion', required: true },
        { id: 'AC-2', title: 'Upgrades y downgrades', required: true },
        { id: 'AC-3', title: 'Facturacion', required: true },
        { id: 'AC-4', title: 'Webhooks de pago', required: true },
        { id: 'AC-5', title: 'Periodo de prueba', required: false },
        { id: 'AC-6', title: 'Metricas de revenue', required: false },
    ],
    variables: [
        {
            key: 'PlatformName',
            label: 'Nombre de la plataforma',
            description: 'Nombre de la plataforma SaaS',
            example: 'CloudApp',
            required: true,
        },
    ],
    huTemplate: `# HU: Facturacion y Suscripciones — {{PlatformName}}

## Historia de Usuario
Como usuario de {{PlatformName}}, quiero gestionar mi suscripcion y recibir facturas para mantener mi cuenta al dia.

## Criterios de Aceptacion

### AC-1: Planes de suscripcion
- [ ] El sistema define planes con nombre, precio, ciclo de facturacion y features incluidas
- [ ] Los planes son configurables sin despliegue (admin dashboard o config)
- [ ] Se soportan planes mensuales y anuales como minimo
- [ ] Los precios soportan multiples monedas

### AC-2: Upgrades y downgrades
- [ ] El usuario puede cambiar de plan en cualquier momento
- [ ] Los upgrades se aplican inmediatamente con prorrateo
- [ ] Los downgrades se aplican al final del periodo de facturacion actual
- [ ] Se notifica al usuario del impacto del cambio antes de confirmar

### AC-3: Facturacion
- [ ] Se genera factura automatica en cada ciclo de facturacion
- [ ] La factura es descargable en PDF con datos fiscales
- [ ] El historial de facturas es accesible para el usuario
- [ ] Los pagos fallidos generan reintentos con notificacion al usuario

### AC-4: Webhooks de pago
- [ ] Los eventos de pago del proveedor se reciben y procesan via webhook
- [ ] Los webhooks validan firma/autenticidad antes de procesar
- [ ] El procesamiento es idempotente (replay-safe)
- [ ] Los eventos fallidos se reintentan con backoff

### AC-5: Periodo de prueba
- [ ] Los nuevos usuarios pueden acceder a un periodo de prueba configurable
- [ ] Se notifica antes del fin del trial con opcion de convertir
- [ ] Al expirar el trial, se limita el acceso sin perder datos

### AC-6: Metricas de revenue
- [ ] MRR (Monthly Recurring Revenue) calculado automaticamente
- [ ] Churn rate visible en dashboard de admin
- [ ] Cohort analysis por mes de registro
`,
    fichaTecnicaTemplate: `# FICHA TÉCNICA: Facturacion — {{PlatformName}}

## Archivos Afectados
- billing/plans
- billing/subscriptions
- billing/invoices
- billing/webhook-handler
- billing/trial

## Tipos / Entidades
- \`Plan\`: id, name, price, currency, interval, features[]
- \`Subscription\`: userId, planId, status, startedAt, expiresAt
- \`Invoice\`: id, subscriptionId, amount, currency, paidAt, pdfUrl

## Riesgos
- Doble cobro → idempotencia en webhook processing
- Factura incorrecta → validacion cruzada con proveedor
- Trial abuse → limitar a un trial por usuario/email

## Estimacion
- Dev: 40–80 horas
- Review: 8–16 horas
- Dificultad: 4/5
`,
    progressTemplate: `# PROGRESS: Facturacion — {{PlatformName}}

## Estado: borrador

## Criterios
- [ ] AC-1: Planes de suscripcion
- [ ] AC-2: Upgrades y downgrades
- [ ] AC-3: Facturacion
- [ ] AC-4: Webhooks de pago
- [ ] AC-5: Periodo de prueba
- [ ] AC-6: Metricas de revenue
`,
};
/** SaaS RBAC template. */
export const SAAS_ROLES_TEMPLATE = {
    id: 'saas-roles',
    name: 'Control de acceso basado en roles (RBAC)',
    category: 'industry',
    subcategory: 'saas',
    description: 'Permisos granulares, herencia de roles y auditoria de acceso.',
    tags: ['saas', 'rbac', 'permissions', 'roles', 'access-control'],
    complexityScore: 'M',
    estimationBase: {
        hoursMin: 24,
        hoursMax: 48,
        notes: 'Incluye herencia de roles y auditoria de acceso',
    },
    criteria: [
        { id: 'AC-1', title: 'Definicion de roles', required: true },
        { id: 'AC-2', title: 'Permisos granulares', required: true },
        { id: 'AC-3', title: 'Herencia de roles', required: false },
        { id: 'AC-4', title: 'Asignacion de roles', required: true },
        { id: 'AC-5', title: 'Verificacion de permisos', required: true },
        { id: 'AC-6', title: 'Auditoria de acceso', required: true },
    ],
    variables: [
        {
            key: 'PlatformName',
            label: 'Nombre de la plataforma',
            description: 'Nombre de la plataforma SaaS',
            example: 'CloudApp',
            required: true,
        },
    ],
    huTemplate: `# HU: RBAC — {{PlatformName}}

## Historia de Usuario
Como administrador de {{PlatformName}}, quiero asignar roles y permisos a los usuarios para controlar que acciones puede realizar cada uno.

## Criterios de Aceptacion

### AC-1: Definicion de roles
- [ ] Los roles se definen con nombre, descripcion y conjunto de permisos
- [ ] Existen roles predefinidos (admin, editor, viewer) configurables
- [ ] Se pueden crear roles personalizados
- [ ] Los roles se gestionan por tenant (no globales)

### AC-2: Permisos granulares
- [ ] Los permisos se definen como pares recurso:accion (e.g. "users:create")
- [ ] Se soportan wildcards (e.g. "users:*" para todas las acciones sobre usuarios)
- [ ] Los permisos nuevos se agregan sin redeploy (configuracion)

### AC-3: Herencia de roles
- [ ] Un rol puede heredar permisos de otro rol padre
- [ ] La herencia es transitiva (admin hereda de editor que hereda de viewer)
- [ ] Los permisos heredados pueden ser revocados explicitamente

### AC-4: Asignacion de roles
- [ ] Los administradores pueden asignar/revocar roles a usuarios
- [ ] Un usuario puede tener multiples roles (los permisos se combinan)
- [ ] Los cambios de rol se aplican inmediatamente (sin requerir re-login)

### AC-5: Verificacion de permisos
- [ ] Toda ruta/accion verifica permisos antes de ejecutar
- [ ] La verificacion es eficiente (cache en memoria, no DB por request)
- [ ] Los permisos denegados retornan 403 con mensaje claro

### AC-6: Auditoria de acceso
- [ ] Los cambios de roles y permisos se registran con timestamp y actor
- [ ] Los accesos denegados se registran para analisis de seguridad
- [ ] El registro de auditoria es consultable por admin
`,
    fichaTecnicaTemplate: `# FICHA TÉCNICA: RBAC — {{PlatformName}}

## Archivos Afectados
- rbac/roles
- rbac/permissions
- rbac/assignment
- rbac/middleware (permission check)
- rbac/audit-log

## Tipos / Entidades
- \`Role\`: id, name, permissions[], parentRoleId
- \`Permission\`: resource, action, granted
- \`RoleAssignment\`: userId, roleId, assignedBy, assignedAt

## Riesgos
- Escalacion de privilegios → tests de aislamiento de permisos
- Cache de permisos desactualizado → invalidacion al cambiar roles
- Herencia circular → validacion al definir roles padre

## Estimacion
- Dev: 24–48 horas
- Review: 4–8 horas
- Dificultad: 3/5
`,
    progressTemplate: `# PROGRESS: RBAC — {{PlatformName}}

## Estado: borrador

## Criterios
- [ ] AC-1: Definicion de roles
- [ ] AC-2: Permisos granulares
- [ ] AC-3: Herencia de roles
- [ ] AC-4: Asignacion de roles
- [ ] AC-5: Verificacion de permisos
- [ ] AC-6: Auditoria de acceso
`,
};
//# sourceMappingURL=templates-industry-saas.js.map