# TASK 3.2: Run Redshift-Backed Dry-Run Validation

## Summary

Validate the migrated KDS monitor specs through Redshift-backed dry runs.

This task confirms prompt compatibility with the runtime path from slice 03 and synthetic data from slice 02.

It is not the full monitor evaluation framework.

## Dependencies

- TASK 3.1 (static blocked-term validation)
- Single-Store Redshift Runtime Read Path complete
- Redshift Synthetic Data Feed complete

## Files to Create or Modify

### 1. Validation notes if needed

If any dry run cannot be completed because of insufficient synthetic data or environment availability, document the reason clearly in an appropriate notes file or task output.

Do not change monitor thresholds to force validation success.

## Required Behavior

Run dry-run execution for:

- `prep-time`
- `order-surge`
- `large-order-wave`
- `priority-flood`
- `slow-kitchen`
- `station-bottleneck`
- `forgotten-items`
- `item-recall-storm`

For each dry run, confirm:

- generated SQL references only `curated.orders` and/or `curated.order_items`,
- generated SQL does not reference `kdsdev`,
- generated SQL does not reference `store_guid` or `is_deleted`,
- generated SQL uses timestamp fields such as `created_at`, `updated_at`, `prepared_at`, `done_at`, or `recall_at`,
- result is structured,
- failures are data availability or environment issues, not prompt/schema mismatch.

## Acceptance Criteria

- [ ] Dry-run validation is attempted for all eight migrated monitors
- [ ] Dry-run SQL uses only `curated.orders` and/or `curated.order_items`
- [ ] Dry-run SQL does not reference `kdsdev`
- [ ] Dry-run SQL does not reference `store_guid`
- [ ] Dry-run SQL does not reference `is_deleted`
- [ ] Dry-run SQL uses curated timestamp fields
- [ ] Each monitor returns a structured result or clear no-data/no-anomaly outcome
- [ ] Any environment or data-availability blocker is documented
- [ ] No thresholds are changed merely to pass validation
- [ ] No runtime code is changed in this task unless a small compatibility bug is explicitly identified and documented

## Notes

- Use existing dry-run monitor execution commands from the CLI/runtime.
- A dry run after synthetic anomaly injection is useful when practical, but not required for this slice.
- Full regression scoring belongs to the future evaluation framework.