high priority medium complexity testing pending testing specialist Tier 6

Acceptance Criteria

Integration test suite contains at minimum 4 named test cases covering the scenarios listed in the description
Test case 'successful run': seeds 3 activity records, invokes function, asserts 3 rows in `prompt_history`, asserts log summary shows `succeeded_count: 3, error_count: 0, skipped_count: 0`
Test case 'kill switch disabled': sets kill switch config to enabled=true, invokes function, asserts zero rows written, asserts log contains `kill_switch_status` event with `enabled: true`
Test case 'per-activity error isolation': seeds 3 records where activity 2 will cause a Scheduler Service error (via mock), asserts activities 1 and 3 succeed, log shows `succeeded_count: 2, error_count: 1`
Test case 'idempotency': invokes function, asserts N new rows; invokes again within same window, asserts zero new rows and log shows `skipped_count: N`
Each test tears down seeded data after completion — tests are independent and can run in any order
Post-launch checklist is a markdown document in `docs/deployment/` covering all 4 domains specified in the description with clear pass/fail criteria
Monitoring metric definitions include: alert thresholds, metric names as they appear in Supabase log filters, and example log queries for each metric
All tests pass against a Supabase local development instance (`supabase start`)

Technical Requirements

frameworks
Deno test runner (built-in `Deno.test`)
Supabase local dev stack (`supabase start`)
sinon or similar Deno-compatible mock library for Scheduler Service HTTP mock
apis
Supabase PostgREST API (local)
Edge Functions local invocation via `supabase functions serve`
data models
activities
prompt_history
scheduler_config
performance requirements
Full integration test suite must complete within 90 seconds
Each test must have an explicit timeout of 20 seconds to prevent hanging tests blocking CI
security requirements
Integration tests must run against the local Supabase instance only — never connect to staging or production databases
Test seed data must not include real personal data — use generated fake Norwegian names and IDs

Execution Context

Execution Tier
Tier 6

Tier 6 - 158 tasks

Can start after Tier 5 completes

Implementation Notes

Use Supabase's local dev stack for integration tests — run `supabase start` as a prerequisite and point the test client at `http://localhost:54321`. For mocking the Scheduler Service, start a simple Deno HTTP server on a random port at test setup and pass its URL as `SCENARIO_SCHEDULER_URL` environment variable. In each test, configure the mock server to return success, error, or timeout responses as needed. Use `supabase.from('activities').insert([...])` to seed data and `supabase.from('activities').delete().neq('id', '')` in `afterEach` to clean up.

For the idempotency test, avoid manipulating the system clock — instead insert a `prompt_history` row manually to simulate a prior run within the window, then assert the function skips it. The post-launch checklist should be written as a GitHub-flavoured markdown checklist (`- [ ] item`) so it can be used directly as a PR checklist during production deployment.

Testing Requirements

This task IS the testing task. The integration tests themselves are the primary deliverable. Additionally: (1) ensure tests can be run via a single command `deno test --allow-net --allow-env tests/integration/scenario-evaluation/` from the repository root; (2) add a CI step in the existing pipeline (GitHub Actions or equivalent) that runs these tests on every PR touching the Edge Function source; (3) confirm tests are included in the project's test coverage report.

Component
Scenario Evaluation Edge Function
infrastructure medium
Epic Risks (2)
medium impact low prob technical

Supabase Edge Functions on Deno can have cold-start latency of 500ms–2s. If the evaluation window contains many activities (e.g., post-holiday catch-up), the function may approach the 60-second invocation timeout before completing all evaluations.

Mitigation & Contingency

Mitigation: Implement pagination in the activity fetch query with a configurable page size; process pages sequentially and commit history records per page so partial runs are recoverable on the next invocation.

Contingency: If timeout remains an issue at scale, split the evaluation into per-chapter invocations triggered by a fan-out pattern using Supabase Realtime or a lightweight queue.

medium impact low prob dependency

Supabase cron triggers (pg_cron or Edge Function schedules) may miss invocations during platform maintenance windows, causing evaluation gaps that delay time-sensitive prompts beyond their intended delivery window.

Mitigation & Contingency

Mitigation: Configure the look-back window to be 2× the cron interval (e.g., 2-hour look-back for hourly cron) so a single missed invocation does not result in missed prompts; log each run's look-back range for auditability.

Contingency: If missed invocations are detected via monitoring alerts, implement a manual re-trigger endpoint accessible to admins that runs the evaluation for a specified time range.