# Experiment: Ack Before Alert in Batch
Date: 2026-06-24
Phase: 24 — Climate Resilience Verification

## 1. Hypothesis
If I upload a sync batch containing an alert acknowledgment before the corresponding
alert event, I expect the batch processor to record **CONFLICT** with reason
`ALERT_NOT_YET_SYNCED`, because clinical sync enforces temporal ordering dependencies.

## 2. Baseline
- Test: `ClinicalSyncBatchTests.Processor_ConflictOnAckBeforeAlert`
- Batch contains: `SyncedAlertAcknowledgment` only (no matching `SyncedAlertEvent`)
- Client alert id: newly generated Guid

## 3. Break
```bash
dotnet test VigilCareClinicalAPI.Tests \
  --filter "FullyQualifiedName~ClinicalSyncBatchTests.Processor_ConflictOnAckBeforeAlert"
```

Batch payload (wrong order):
```csharp
new ClinicalSyncBatchRequest(batchRef, gatewayId, siteId, capturedAt,
    observations: [],
    alertEvents: [],
    alertAcknowledgments: [new SyncedAlertAcknowledgment(..., clientAlertId, "RN-Smith", ...)],
    alertResolutions: []);
```

## 4. Observe
- Batch uploaded successfully (HTTP 201)
- After `ProcessBatchAsync`: batch status = **CONFLICT**
- Conflicts collection contains single entry with `ConflictReason: ALERT_NOT_YET_SYNCED`
- Test result: **Passed** (309 ms)
- No alert row created from premature ack

## 5. Fix / Outcome
- Bug found? **no** — conflict is the correct server-authoritative response
- Fix applied: no fix needed — reorder and re-upload in a new batch (see plan Step 3 for full reorder test)

## 6. Verify
(Conflict assertions captured in `2026-06-24-ack-before-alert-fixed.json`)