SAVED RESULT VERIFIED
1. The booking works
The browser submits a unique reference. A separate request confirms the matching record was saved.
- Page / submit / saved record
- 200 / 201 / 200
- Recorded at (UTC)
← Longkeep
RECORDED SYNTHETIC TEST · SEPTEMBER 8, 2026
A real run. A visible limit.
We removed the booking's save operation, observed the failure, applied a source patch and checked recovery. Here is the result you can inspect.
This is a local test app with synthetic data. The repair is a scripted replay of an operator-authored patch. It is not autonomous AI repair or a customer success story.
FAILURE DETECTED
2. The code stops saving
The page and success message still look healthy. The booking API returns 201, but the independent read returns 404. The check fails and the local alert endpoint receives the incident.
- Page / submit / saved record
- 200 / 201 / 404
- Recorded at (UTC)
SAVED RESULT VERIFIED
3. A source patch restores it
An operator-authored patch restores the awaited write. We restart the app and rerun the same check without changing its acceptance conditions. The new booking is saved; the previous record survives.
- Page / submit / saved record
- 200 / 201 / 200
- Recorded at (UTC)
The fixture's on-screen mode remains “healthy” in all three runs. The second run fails because its source file has changed; a mode switch does not perform this repair.
THE IMPORTANT CHECK
A green message is not enough.
Every run uses a new reference. The browser action, expected response, visible result and separate saved-record read must all pass. A missing record prevents a recovery notice even when the page says it worked.
What changed in the code
Restore the persistent write before the successful response, and await its completion.
await writeFile(recordPath, JSON.stringify(record));
send(201, record);Simplified excerpt. The exact source and diff are downloadable below.
Other failures we exercised
12 browser runs covered failures, duplicate suppression and notification retries. These are controlled cases in one fixture, not a success rate for unknown apps.
| Controlled fault | Page | Check result |
|---|---|---|
| Booking API fails | 200 | Detected |
| Success UI, no saved record | 200 | Detected |
| Button does nothing | 200 | Detected |
| Session rejected | 200 | Detected |
| Success UI, no request | 200 | Detected |
Notification proof: actual HTTP requests reached a local test endpoint. Missing or rejected notifications stayed pending for retry. External customer email, chat delivery and human receipt have not been verified by this test.
Inspect the evidence
Machine-readable records include timestamps, checks, event IDs and source hashes. Screenshots contain only synthetic data.
- Source repair: 3-run report (JSON)
- Failure and notification tests (JSON)
- Exact source patch (diff)
- Faulty source / Repaired source
Your app still needs its own baseline.
We first agree a supported app, a safe synthetic booking, how to verify the saved record, an alert destination and an operating schedule. A monthly service starts only after that baseline and the written scope are accepted.
Discuss a free baseline