// engine/spec-templates/templates-data-security.ts — Data migration + security feature templates.
// Extracted from catalog-extra.ts to keep file sizes within limits.
/** Data migration spec template. */
export const DATA_MIGRATION_TEMPLATE = {
    id: 'data-migration',
    name: 'Data Migration',
    category: 'data',
    description: 'Safe, reversible database or data migration with rollback support.',
    tags: ['migration', 'database', 'schema', 'data'],
    complexityScore: 'M',
    estimationBase: {
        hoursMin: 16,
        hoursMax: 40,
        notes: 'Includes rollback strategy and zero-downtime approach',
    },
    criteria: [
        { id: 'AC-1', title: 'Migration script', required: true },
        { id: 'AC-2', title: 'Data safety', required: true },
        { id: 'AC-3', title: 'Zero-downtime strategy', required: false },
        { id: 'AC-4', title: 'Rollback', required: true },
        { id: 'AC-5', title: 'Observability', required: false },
    ],
    variables: [
        {
            key: 'MigrationName',
            label: 'Migration name',
            description: 'Short descriptive name for this migration',
            example: 'Add email_verified column to users',
            required: true,
        },
    ],
    huTemplate: `# HU: Data Migration — {{MigrationName}}

## User Story
As a developer, I want to apply the migration "{{MigrationName}}" safely so that production data is not at risk.

## Acceptance Criteria

### AC-1: Migration script
- [ ] Migration has an "up" (apply) and "down" (rollback) operation
- [ ] Script is idempotent (safe to run multiple times)
- [ ] Each step is transactional where supported by the database

### AC-2: Data safety
- [ ] Pre-migration backup documented in runbook
- [ ] No destructive operation without a confirmed backup
- [ ] Migration tested on a staging copy of production data

### AC-3: Zero-downtime strategy
- [ ] Migration can be applied while the application is running
- [ ] Backward-compatible schema changes first (expand), then cleanup (contract)
- [ ] Feature flag used if application code needs to switch behavior

### AC-4: Rollback
- [ ] Rollback procedure documented and tested
- [ ] Rollback does not cause data loss
- [ ] Time to rollback < 15 minutes

### AC-5: Observability
- [ ] Migration duration logged
- [ ] Row counts before/after logged for verification
- [ ] Anomalies (unexpected row counts) trigger alerts
`,
    fichaTecnicaTemplate: `# FICHA TÉCNICA: Data Migration — {{MigrationName}}

## Affected Files
- migrations/{{MigrationName}}/up
- migrations/{{MigrationName}}/down
- runbooks/{{MigrationName}}-rollback

## Types / Entities
- Migration metadata: id, name, appliedAt, duration, rolledBack

## Risks
- Data loss on rollback → mandatory backup before apply
- Long-running migration → table locks in production
- Missing idempotency → partial application leaves DB in bad state

## Estimation (rough)
- Dev: 4–12 hours
- Review: 2–4 hours
- Difficulty: 3/5
`,
    progressTemplate: `# PROGRESS: Data Migration — {{MigrationName}}

## Status: draft

## Criteria
- [ ] AC-1: Migration script
- [ ] AC-2: Data safety
- [ ] AC-3: Zero-downtime strategy
- [ ] AC-4: Rollback
- [ ] AC-5: Observability
`,
};
/** Security feature spec template. */
export const SECURITY_FEATURE_TEMPLATE = {
    id: 'security-feature',
    name: 'Security Feature',
    category: 'security',
    description: 'Security hardening: rate limiting, input sanitization, audit logging, etc.',
    tags: ['security', 'hardening', 'audit', 'rate-limiting'],
    complexityScore: 'M',
    estimationBase: {
        hoursMin: 16,
        hoursMax: 32,
        notes: 'Includes penetration test checklist and monitoring setup',
    },
    criteria: [
        { id: 'AC-1', title: 'Implementation', required: true },
        { id: 'AC-2', title: 'Bypass prevention', required: true },
        { id: 'AC-3', title: 'Observability', required: false },
        { id: 'AC-4', title: 'Testing', required: true },
        { id: 'AC-5', title: 'Documentation', required: false },
    ],
    variables: [
        {
            key: 'FeatureName',
            label: 'Security feature name',
            description: 'Name of the security feature being implemented',
            example: 'Rate Limiting',
            required: true,
        },
        {
            key: 'ProtectedResource',
            label: 'Protected resource or area',
            description: 'What is being protected by this feature',
            example: 'authentication endpoints',
            required: true,
        },
    ],
    huTemplate: `# HU: Security Feature — {{FeatureName}}

## User Story
As a security engineer, I want {{FeatureName}} applied to {{ProtectedResource}} so that attack vectors are reduced.

## Acceptance Criteria

### AC-1: Implementation
- [ ] {{FeatureName}} implemented at the correct layer (edge, gateway, application)
- [ ] Configuration externalized (not hardcoded)
- [ ] Enabled in production, configurable in development

### AC-2: Bypass prevention
- [ ] Cannot be bypassed by manipulating headers or query parameters
- [ ] Handles IPv4, IPv6, and forwarded IP headers correctly
- [ ] Works behind reverse proxies and CDNs

### AC-3: Observability
- [ ] Blocked/throttled requests logged with reason
- [ ] Metrics exported: blocked count, block rate, top blocked IPs
- [ ] Alert triggers when block rate exceeds threshold

### AC-4: Testing
- [ ] Unit tests cover allowed and blocked cases
- [ ] Integration tests simulate attack patterns
- [ ] Penetration test checklist updated

### AC-5: Documentation
- [ ] Security runbook updated with new feature
- [ ] Limits and thresholds documented with rationale
- [ ] On-call playbook updated for incident response
`,
    fichaTecnicaTemplate: `# FICHA TÉCNICA: Security Feature — {{FeatureName}}

## Affected Files
- middleware/{{FeatureName}}
- config/security-config
- monitoring/security-alerts
- runbooks/security-incident

## Types / Entities
- \`{{FeatureName}}Config\`: thresholds, enabled, dryRun
- \`SecurityEvent\`: type, resource, ip, timestamp, blocked

## Risks
- False positives blocking legitimate users → dry-run mode first
- Missing coverage for all entry points → security audit required
- Misconfiguration under proxy → test in staging with proxy enabled

## Estimation (rough)
- Dev: 4–12 hours
- Review: 2–4 hours
- Difficulty: 3/5
`,
    progressTemplate: `# PROGRESS: Security Feature — {{FeatureName}}

## Status: draft

## Criteria
- [ ] AC-1: Implementation
- [ ] AC-2: Bypass prevention
- [ ] AC-3: Observability
- [ ] AC-4: Testing
- [ ] AC-5: Documentation
`,
};
//# sourceMappingURL=templates-data-security.js.map