Shreyp087 Demo resilience
Read the official demo and recording rules. Identify the exact core journey, target device, network, dependencies, account state, and time limit. Distinguish a live demo from a recording requirement.
Make the start state reproducible. Use permitted sample data, a clear reset action, known prerequisites, and a bounded completion time. Prevent one rehearsal from consuming or corrupting the next rehearsal's state.
Exercise the actual path under the most plausible disruptions: network loss, slow dependency, rate limit, missing permission, invalid input, and failed hardware connection. Choose the relevant cases rather than building a general chaos platform. Time the path on the target environment.
Provide a transparent recovery path: retry with a bound, locally cached permitted data, a deterministic replay of a recorded successful run, or a clearly marked simulation. Preserve the same interface where helpful. Every fallback must identify its mode and what the live system has and has not demonstrated. A replay is evidence of a prior run, not a live run.
Record a short fallback video if event rules allow it; include real measured timing or disclose cuts that change perceived latency. Check that required URLs open without the presenter's account and that secrets or personal data are absent from captures.
Produce a run sheet with setup, steps, expected visible outcomes, timing, reset, failure cue, fallback action, and mode labels. Rehearse uninterrupted with a person unfamiliar with the build if possible. Mark each check as observed, failed, or untested. Freeze features based on the deadline and recovery risk, not a fixed universal schedule.