// engine/spec-templates/templates-perf-integration.ts — Performance + third-party integration templates.
// Extracted from catalog-extra.ts to keep file sizes within limits.
/** Performance optimization spec template. */
export const PERFORMANCE_OPTIMIZATION_TEMPLATE = {
    id: 'performance-optimization',
    name: 'Performance Optimization',
    category: 'performance',
    description: 'Measurable performance improvements with before/after benchmarks.',
    tags: ['performance', 'optimization', 'caching', 'benchmarks'],
    complexityScore: 'L',
    estimationBase: {
        hoursMin: 16,
        hoursMax: 60,
        notes: 'Highly variable by root cause; includes benchmarking setup',
    },
    criteria: [
        { id: 'AC-1', title: 'Baseline measurement', required: true },
        { id: 'AC-2', title: 'Optimization implementation', required: true },
        { id: 'AC-3', title: 'Cache strategy', required: false },
        { id: 'AC-4', title: 'Validation', required: true },
        { id: 'AC-5', title: 'Observability', required: false },
    ],
    variables: [
        {
            key: 'TargetArea',
            label: 'Target area',
            description: 'The specific area to optimize (e.g. API response time, DB queries)',
            example: 'API response time',
            required: true,
        },
        {
            key: 'CurrentBaseline',
            label: 'Current baseline',
            description: 'Current measured performance metric',
            example: 'P95 latency: 800ms',
            required: false,
            defaultValue: 'TBD — measure before starting',
        },
        {
            key: 'TargetGoal',
            label: 'Target goal',
            description: 'Desired performance metric after optimization',
            example: 'P95 latency: < 200ms',
            required: false,
            defaultValue: 'TBD — define after baseline measurement',
        },
    ],
    huTemplate: `# HU: Performance Optimization — {{TargetArea}}

## User Story
As a user, I want {{TargetArea}} to be faster so that the application feels responsive.

## Baseline
- Current: {{CurrentBaseline}}
- Target: {{TargetGoal}}

## Acceptance Criteria

### AC-1: Baseline measurement
- [ ] Benchmark suite established before any changes
- [ ] Metrics captured: P50, P95, P99 latency, throughput, error rate
- [ ] Benchmark results stored for comparison

### AC-2: Optimization implementation
- [ ] Root cause of performance issue identified and documented
- [ ] Optimization applied at the correct layer
- [ ] No correctness regression introduced by optimization

### AC-3: Cache strategy (if applicable)
- [ ] Cache invalidation strategy defined
- [ ] Cache hit rate monitored
- [ ] Cache warm-up procedure documented

### AC-4: Validation
- [ ] Post-optimization benchmark shows improvement vs baseline
- [ ] Target goal reached or documented with explanation if not
- [ ] Load test confirms improvement holds under concurrent traffic

### AC-5: Observability
- [ ] Performance metrics added to dashboard
- [ ] Regression alert configured (auto-detect if P95 degrades)
`,
    fichaTecnicaTemplate: `# FICHA TÉCNICA: Performance Optimization — {{TargetArea}}

## Affected Files
- (determined during root-cause analysis)
- monitoring/dashboards/{{TargetArea}}
- benchmarks/{{TargetArea}}

## Types / Entities
- \`BenchmarkResult\`: timestamp, p50, p95, p99, throughput, errorRate
- \`CacheEntry\` (if caching): key, value, ttl, hitCount

## Risks
- Optimization that breaks correctness → benchmark must include correctness tests
- Cache inconsistency → strong consistency tests required
- Performance regression after unrelated change → regression alert required

## Estimation (rough)
- Dev: 4–20 hours (highly variable by root cause)
- Review: 2–4 hours
- Difficulty: 3–4/5
`,
    progressTemplate: `# PROGRESS: Performance Optimization — {{TargetArea}}

## Status: draft

## Criteria
- [ ] AC-1: Baseline measurement
- [ ] AC-2: Optimization implementation
- [ ] AC-3: Cache strategy
- [ ] AC-4: Validation
- [ ] AC-5: Observability
`,
};
/** Third-party integration spec template. */
export const THIRD_PARTY_INTEGRATION_TEMPLATE = {
    id: 'third-party-integration',
    name: 'Third-Party Integration',
    category: 'integration',
    description: 'Integrating with an external service (payment, email, SMS, CRM, etc.).',
    tags: ['integration', 'external', 'api', 'webhook'],
    complexityScore: 'M',
    estimationBase: {
        hoursMin: 16,
        hoursMax: 40,
        notes: 'Includes webhook handling and circuit breaker setup',
    },
    criteria: [
        { id: 'AC-1', title: 'Credentials management', required: true },
        { id: 'AC-2', title: 'Core integration', required: true },
        { id: 'AC-3', title: 'Error handling', required: true },
        { id: 'AC-4', title: 'Webhooks', required: false },
        { id: 'AC-5', title: 'Observability', required: false },
        { id: 'AC-6', title: 'Testing', required: true },
    ],
    variables: [
        {
            key: 'ServiceName',
            label: 'Service name',
            description: 'Name of the external service to integrate',
            example: 'Stripe',
            required: true,
        },
        {
            key: 'IntegrationPurpose',
            label: 'Purpose',
            description: 'What the integration enables',
            example: 'payment processing',
            required: true,
        },
    ],
    huTemplate: `# HU: {{ServiceName}} Integration

## User Story
As a developer, I want to integrate {{ServiceName}} so that the platform can handle {{IntegrationPurpose}} reliably.

## Acceptance Criteria

### AC-1: Credentials management
- [ ] API keys and secrets stored in environment variables (never hardcoded)
- [ ] Separate credentials for development, staging, and production
- [ ] Credential rotation documented in runbook

### AC-2: Core integration
- [ ] {{ServiceName}} SDK or HTTP client initialized with proper config
- [ ] All calls wrapped in retry logic with exponential backoff
- [ ] Timeouts configured (no infinite waits)

### AC-3: Error handling
- [ ] {{ServiceName}} API errors mapped to internal error types
- [ ] Network failures do not crash the application
- [ ] Errors logged with enough context for debugging

### AC-4: Webhooks (if applicable)
- [ ] Webhook endpoint validates signature before processing
- [ ] Events processed idempotently (replay-safe)
- [ ] Failed event processing alerts the on-call team

### AC-5: Observability
- [ ] All outbound calls logged (method, status, latency)
- [ ] Circuit breaker implemented for high-traffic paths

### AC-6: Testing
- [ ] Unit tests mock {{ServiceName}} client
- [ ] Integration tests use sandbox/test environment
- [ ] Webhook tests replay recorded payloads
`,
    fichaTecnicaTemplate: `# FICHA TÉCNICA: {{ServiceName}} Integration

## Affected Files
- integrations/{{ServiceName}}/client
- integrations/{{ServiceName}}/webhook-handler
- integrations/{{ServiceName}}/error-mapper
- config/{{ServiceName}}-config
- tests/integrations/{{ServiceName}}

## Types / Entities
- \`{{ServiceName}}Config\`: apiKey, baseUrl, timeout, retries
- \`{{ServiceName}}Error\`: code, message, retryable
- \`WebhookEvent\`: id, type, payload, receivedAt

## Risks
- Vendor API changes without notice → pin SDK version, monitor changelogs
- Rate limits exceeded → implement request queuing
- Credentials leaked → secrets manager mandatory

## Estimation (rough)
- Dev: 8–20 hours
- Review: 2–4 hours
- Difficulty: 3/5
`,
    progressTemplate: `# PROGRESS: {{ServiceName}} Integration

## Status: draft

## Criteria
- [ ] AC-1: Credentials management
- [ ] AC-2: Core integration
- [ ] AC-3: Error handling
- [ ] AC-4: Webhooks
- [ ] AC-5: Observability
- [ ] AC-6: Testing
`,
};
//# sourceMappingURL=templates-perf-integration.js.map