/**
 * Shared technical spec content for all sandbox scenarios.
 *
 * The same technical spec is ingested with different methodology profiles.
 * This demonstrates methodology-agnosticism: same project, different governance.
 * The spec is loaded at build time from the ido4-demo repository.
 *
 * If the demo codebase is not available, this inline content serves as the
 * deterministic fallback. It matches the format expected by spec-parser.ts:
 * ## Capability: headings with ### PREFIX-NN: task headings.
 */
export declare const TECHNICAL_SPEC_CONTENT = "# Notification Platform \u2014 Technical Spec\n\n> Technical decomposition of the notification platform API. Derived from the strategic\n> spec and grounded in the existing codebase. The auth module, event model, event bus,\n> template engine, template store, and channel registry are complete. This spec covers\n> the remaining implementation work.\n\n**Constraints:**\n- No external infrastructure dependencies \u2014 use in-memory stores\n- Must maintain existing auth API contract\n- TypeScript strict mode \u2014 all strict compiler flags enabled\n- All channel providers must implement IChannelProvider from src/channels/channel-registry.ts\n- Follow the service pattern established in src/auth/auth-service.ts\n\n**Non-goals:**\n- Frontend UI or dashboard\n- Real-time WebSocket delivery\n- Message queue infrastructure\n\n---\n\n## Capability: Notification Core\n> size: L | risk: medium\n\nThe backbone of the delivery pipeline. The event model and event bus are complete.\nThe delivery engine, retry policy, and status tracking need implementation.\nThis is the critical path \u2014 downstream tasks depend on this capability.\n\n### NCO-01: Delivery Engine Core\n> effort: L | risk: medium | type: feature | ai: assisted\n> depends_on: -\n\nComplete the delivery engine at src/notifications/delivery-engine.ts. The IDeliveryEngine\ninterface and class skeleton exist. The deliver() method must orchestrate multi-channel\ndelivery: validate incoming events, resolve target channels from the ChannelRegistry,\ndispatch to each channel provider, and handle failures through the retry policy.\n\n**Success conditions:**\n- deliver() processes a NotificationEvent and returns DeliveryResult[] per channel\n- Channel resolution uses ChannelRegistry to find supporting providers\n- Failed deliveries are passed to RetryPolicy before marking as failed\n- Delivery status events are emitted on the notification event bus\n- Error handling follows AppError/DeliveryError patterns\n\n### NCO-02: Retry Policy Implementation\n> effort: M | risk: low | type: feature | ai: full\n> depends_on: NCO-01\n\nImplement the retry policy at src/notifications/retry-policy.ts. Exponential backoff\nwith configurable parameters from RetryConfig. The execute() method wraps async\nfunctions with retry logic.\n\n**Success conditions:**\n- shouldRetry() checks attempt count and error retryability\n- getDelay() implements exponential backoff capped at maxDelayMs\n- execute() retries failed operations with computed delays\n- Non-retryable errors thrown immediately\n- DEFAULT_RETRY_CONFIG used when no custom config provided\n\n### NCO-03: Delivery Status Tracking\n> effort: M | risk: low | type: feature | ai: full\n> depends_on: NCO-01\n\nAdd delivery status persistence to the delivery engine using in-memory Map storage.\nTrack each delivery attempt with result, expose via getDeliveryStatus(), and\nupdate getStats() with accurate aggregate counts.\n\n**Success conditions:**\n- Every delivery attempt recorded with timestamp, channel, status\n- getDeliveryStatus() returns full history for a notification ID\n- getStats() returns accurate counts\n- Channel health derived from recent delivery results\n\n### NCO-04: Idempotency Guard\n> effort: S | risk: low | type: feature | ai: full\n> depends_on: NCO-01\n\nAdd idempotency checking to the delivery engine. Check idempotencyKey against\npreviously processed keys before dispatching. Return cached results for duplicates.\n\n**Success conditions:**\n- Duplicate events return cached results without re-delivery\n- First delivery proceeds normally and caches result\n- Cache is bounded with configurable max size\n\n---\n\n## Capability: Channel Providers\n> size: L | risk: low\n\nFour channel providers implementing IChannelProvider. Each has a stub class\nin src/channels/providers/. All four are parallelizable once NCO-01 is complete.\n\n### CHP-01: Email Provider\n> effort: M | risk: low | type: feature | ai: full\n> depends_on: NCO-01\n\nImplement email provider at src/channels/providers/email.ts. Format notifications\nas HTML email with subject lines. Handle bounce/rejection/timeout as DeliveryError.\n\n**Success conditions:**\n- send() formats notification as email with subject and HTML body\n- supports() returns true for email-relevant event types\n- healthCheck() returns ChannelHealth with latency\n- Permanent bounces produce non-retryable DeliveryError\n- Transient failures produce retryable DeliveryError\n\n### CHP-02: SMS Provider\n> effort: M | risk: medium | type: feature | ai: full\n> depends_on: NCO-01\n\nImplement SMS provider at src/channels/providers/sms.ts. Format as plain text\nwithin 160-character limits with truncation indicator.\n\n**Success conditions:**\n- send() formats notification within 160-character limit\n- Long messages truncated with ellipsis\n- supports() returns true for SMS-relevant types\n- healthCheck() validates connectivity\n- Per-recipient rate limiting prevents abuse\n\n### CHP-03: Push Notification Provider\n> effort: M | risk: medium | type: feature | ai: full\n> depends_on: NCO-01\n\nImplement push provider at src/channels/providers/push.ts. Format as JSON\npayload with title, body, data following FCM conventions. Respect 4KB limit.\n\n**Success conditions:**\n- send() formats as push payload with title, body, data\n- Payload respects 4KB size limit\n- supports() checks against push-enabled types\n- healthCheck() validates push service connectivity\n- Invalid device tokens produce non-retryable error\n\n### CHP-04: Webhook Provider\n> effort: M | risk: low | type: feature | ai: full\n> depends_on: NCO-01\n\nImplement webhook provider at src/channels/providers/webhook.ts. Deliver as\nHTTP POST with configurable headers. Map response codes to delivery status.\n\n**Success conditions:**\n- send() delivers as JSON POST to configured URL\n- Configurable HTTP headers for authentication\n- Timeout handling for slow endpoints\n- 2xx = delivered, 4xx = failed permanent, 5xx = failed retryable\n- supports() returns true for all event types\n\n---\n\n## Capability: Template System\n> size: M | risk: low\n\nTemplate engine and store are complete. Renderer needs implementation to\nconnect templates to the delivery pipeline with channel-specific formatting.\n\n### TMP-01: Template Renderer\n> effort: M | risk: low | type: feature | ai: assisted\n> depends_on: NCO-01\n\nComplete renderer at src/templates/renderer.ts. Retrieve template from store,\ncompile with engine, format output for target channel (HTML/text/JSON).\n\n**Success conditions:**\n- render() retrieves, compiles, and formats for channel\n- Channel-specific: HTML for email, text for SMS, JSON for push\n- Subject line rendering for email\n- Render timing tracked in RenderResult\n- Missing variables produce ValidationError\n\n### TMP-02: Template Preview API\n> effort: S | risk: low | type: feature | ai: full\n> depends_on: TMP-01\n\nImplement renderPreview() to render across all channel formats simultaneously.\nLocal rendering only \u2014 no channel providers required.\n\n**Success conditions:**\n- renderPreview() renders for all channel types\n- Returns partial record with applicable channels\n- No channel providers required\n- Includes timing per channel\n\n---\n\n## Capability: Analytics\n> size: M | risk: low\n\nDelivery analytics module at src/analytics/. Subscribes to event bus\nfor real-time tracking and metric computation.\n\n### ANL-01: Delivery Event Tracking\n> effort: M | risk: low | type: feature | ai: full\n> depends_on: NCO-01\n\nCreate analytics service subscribing to delivery events on the notification\nevent bus. Track per-channel and per-event-type delivery counts and latency.\n\n**Success conditions:**\n- Subscribes to delivery events on notification event bus\n- Tracks per-channel delivery counts\n- Tracks per-event-type counts\n- Records delivery latency\n- In-memory storage with configurable retention\n\n### ANL-02: Delivery Metrics Aggregation\n> effort: M | risk: low | type: feature | ai: full\n> depends_on: ANL-01\n\nAdd metric computation: success rates, average latency, channel health\nscores, and time-windowed metrics.\n\n**Success conditions:**\n- Computes delivery success rate per channel\n- Computes average latency per channel\n- Identifies degraded channels\n- Time-windowed metrics (hour, day)\n- Queryable interface\n\n---\n\n## Capability: API Layer\n> size: M | risk: low\n\nComplete the HTTP API. Auth routes done. Notification sending, rate\nlimiting, and template rendering endpoints need implementation.\n\n### API-01: Notification Send Endpoint\n> effort: S | risk: low | type: feature | ai: full\n> depends_on: NCO-01\n\nComplete POST /notifications/send at src/api/routes/notifications.ts.\nValidate, create event, call deliveryEngine.deliver(), return results.\n\n**Success conditions:**\n- POST /notifications/send accepts event payload\n- Body validated using event-model schemas\n- Calls deliveryEngine.deliver()\n- Returns 400 for validation, 500 for delivery failures\n- Success includes per-channel delivery status\n\n### API-02: Rate Limiting Middleware\n> effort: M | risk: low | type: infrastructure | ai: full\n> depends_on: -\n\nImplement rate limiter at src/api/middleware/rate-limiter.ts. Sliding window\nwith per-user limits and X-RateLimit-* response headers.\n\n**Success conditions:**\n- Enforces per-user request limits\n- Returns 429 with Retry-After when exceeded\n- X-RateLimit headers on every response\n- Sliding window algorithm\n- In-memory state\n\n### API-03: Template Rendering Endpoint\n> effort: S | risk: low | type: feature | ai: full\n> depends_on: TMP-01\n\nAdd POST /templates/:id/render endpoint. Accept channel and variables,\ncall renderer.render(), return rendered output with timing.\n\n**Success conditions:**\n- POST /templates/:id/render accepts channel and variables\n- Validates template exists and variables provided\n- Returns rendered output with timing\n- 400 for missing variables, 404 for unknown template\n\n---\n\n## Capability: External Integrations\n> size: M | risk: medium\n\nThird-party integration support at src/integrations/. Longest dependency\nchain: INT-02 depends on INT-01 which depends on NCO-01 + CHP-04.\n\n### INT-01: Webhook Delivery System\n> effort: L | risk: medium | type: feature | ai: assisted\n> depends_on: NCO-01, CHP-04\n\nBuild webhook delivery system at src/integrations/. Register endpoints,\ndeliver via webhook provider, retry failures, track confirmations.\n\n**Success conditions:**\n- Register webhook endpoints with URL and auth config\n- Deliver events via webhook provider\n- Retry failed deliveries with backoff\n- Track delivery confirmations per endpoint\n- Enable/disable endpoints without deletion\n\n### INT-02: Integration Registry\n> effort: M | risk: low | type: feature | ai: full\n> depends_on: INT-01\n\nCreate integration registry for third-party configs. CRUD, auth management,\nevent type filtering, health monitoring.\n\n**Success conditions:**\n- CRUD for integration configurations\n- Event type filtering per integration\n- Auth support (API key, bearer token, headers)\n- Health monitoring from delivery success\n- List integrations with health status\n";
//# sourceMappingURL=shared-technical-spec.d.ts.map