Phase 5 / Ep 24: The "Doomsday Assertion Mechanism" of the Injected UI

The T-Block system is connected to the environment, and everything is going great. But what if the user goes on a business trip tomorrow to an area with no network coverage, or Google suddenly glitches and the API crashes?

If we let the current AI call it a day right here, the moment these low-probability events occur, the page might end up with a full-page white screen or get stuck in an infinite loading spinner. This is absolutely unacceptable for a top-tier system.

1. Assigning a Chaos Drill (Chaos Engineering)

We need to issue a tricky prompt to the LLM:

"To verify our frontend availability, I need you to implement a supplementary assertion at the UI level. In the current Playwright file, add a new test case: use your previous Mock setup interceptor to deliberately force the global google/sync API to return an HTTP 500 Internal Server Error—a catastrophic server-level error.

I require that in this doomsday scenario, our system's frontend can accurately catch the error and render a degraded fallback component in the exact center of the main area, containing the red-bordered text [Enable Offline Mode Immediately]! Please complete this flow."

2. Completing the Fallback Defense

The Agent will not throw an error after receiving the command. It will:

1. Set up route.fulfill({ status: 500 ... }).
2. Then, due to the ironclad rule of red-green testing, it will be forced to go back and write the React component layer.
3. It adds an ErrorBoundary and the offline fallback button architecture.
4. It won't call it quits until the test runs green.

Through this process, your project will have acquired an insane level of survivability before going online.