Shreyp087 Hack Demo Hardening
Goal
Make the actual MVP understandable and repeatable under the conditions in which it will be judged. Repair the demonstrated flow without expanding the product unnecessarily.
Evidence and rehearsal
Exercise the primary happy path from a fresh starting state. For a browser product, use the available browser controls to perform the real user actions and inspect their visible results, including the main viewport and any relevant console or network errors. For other interfaces, use their real interaction surface. Record what was tested and any unavailable tooling.
Verify seed/reset behavior and rehearse a second run. Confirm that the operator can reach the same starting state without deleting unrelated data. Check the deployment or local entry point actually used for judging, along with required permissions and access.
Choose the few failures that can realistically break this demo: dependency timeout, invalid input, permission denial, stale state, quota exhaustion or lost connectivity. Test appropriate cases in a controlled environment and inspect the user's visible outcome. Do not claim graceful recovery from reading code alone.
Prepare a useful fallback where justified, such as a labeled recording, replay or limited offline path. Explain what it proves and what it does not. Never present cached output as a new live run or disguise a failed integration with simulated success.
Review demo configuration, staged/tracked files, logs and screenshots for exposed credentials. Avoid printing secret values in reports; identify the affected location and remediation. Do not claim a narrow scan proves the whole project secret-free.
Create an approximately 90-second spoken script when no limit is supplied, adapting it to the event's actual limit. Align the problem, input, action, visible output and relevant technical proof. Rehearse at natural speed and cut content rather than rush speech. Label edits when elapsed time is part of a claim.
Constraints
- Prioritize failures that affect the demonstrated value; do not add speculative features or unrelated refactors.
- Preserve the project's chosen stack and hosting. A demo repair is not a reason to migrate platforms.
- Keep actual test results separate from proposed tests and subjective critique.
- State limitations honestly, including the difference between implemented, replayed and planned behavior.
- Use existing authorization for deployments or other external changes; preparing a demo does not itself authorize publishing.
Definition of done
The core flow has been exercised, its reset and repeat run verified, relevant failure cases tested, and any fallback visibly labeled. The operator has a concise runbook and timed script. Remaining problems are documented with impact and a practical next action; untested items are not reported as passed.