Review Changes and Save a Recoverable Version

Review the work and the explanation

You now have a content change and a button fix. Ask Codex for a short handoff: what changed, which files changed, what it checked and what remains uncertain. Compare that account with the actual files and page.

A diff is a before-and-after view of file changes. It helps you see an unexpected form, removed notice or changed event date even when the page looks attractive. Review the scope as well as the visible result.

Review this practice project against the headline task, toggle fix, SOURCE.md and AGENTS.md.
Do not edit files in this step.
List changed files and explain the meaningful differences from the starting copy.
Look for unsupported event facts, extra services, broken links and mismatched button state.
Separate confirmed issues from questions. Summarise checks actually run and checks still needed.

Expected review: the headline and introduction match SOURCE.md, the toggle now opens and closes, the fictional date and notice remain, and no external service has been introduced. A review can find mistakes; it does not guarantee that every mistake has been found.

Use the review tools that fit your folder

The starter ZIP is an ordinary folder, not a Git repository. You can compare the current files with a separately extracted unchanged copy. Ask Codex to make that comparison without overwriting either copy.

If you already use Git, the official code-review guide explains the desktop review pane and /review. The review pane needs a project inside a Git repository. It reflects repository changes, which can include your own work and changes from other tasks. Check the selected review scope before reverting or accepting anything.

You do not have to set up Git to read this course. If you want to practise it, do so only in this fictional folder: ask Codex to check whether Git is available, explain how it would create a local repository and save a reviewed snapshot of the practice files. Do not add a remote or upload anything for this exercise. Once a local repository exists, the review pane can help inspect subsequent changes.

Know what is being saved

A local preview is not a public release. A commit does not by itself put a site online. A push can trigger a deployment when that repository is configured to do so, so understand the destination before approving it.

Recover only what you intend

Before the final exercise, keep a known working version: a separate copy of this small practice folder, or a reviewed Git commit if you are using Git. A chat transcript is not a complete file backup.

If a later change is wrong, identify the affected lines or files and preserve unrelated work. Ask for a targeted correction or restore from your known version after checking what would be lost. Do not use a broad reset to solve one unwanted sentence.