Know what can be restored
You will distinguish a checkpoint, Git commit and remote PR. Examples are illustrations.
Documentation checked September 30, 2026 says checkpoints track some Claude file-tool edits, not every filesystem or remote effect. Git gives durable version history, but a commit also needs deliberate content review.
Inspect existing changes
In the practice repository, first inspect status and diff:
git status --short
git diff
These are inspection commands. Read every changed file and identify changes that predate the exercise. Do not stage all files blindly.
Review the current diff without editing.
Separate the course-button change from unrelated existing changes.
List preserved content, tests actually run and remaining checks.
Do not stage, commit, push or create a PR.
Expected result names exact files and uncertainty, not a claim that everything is safe because the diff is small.
Checkpoint scope and rewind options
/rewind offers restoring code, conversation or both when tracked changes exist, plus summary options. Restoring conversation alone leaves code in place. Summarizing does not restore code.
The source excludes Bash file changes, many background-worker edits, external changes and symlink/hard-link restoration. Remote database changes, sent messages and deployments are not undone by local rewind. Do not demonstrate this by deleting a real file.
Use a disposable practice copy if exploring restore. Preserve a baseline first, inspect the selected checkpoint and afterward compare the actual file. A successful menu action is not proof every path restored.
Prepare a local commit for review
After behavior and visual checks, ask only for a proposal:
Suggest which exact practice file belongs in a commit and draft a short commit message.
Do not stage or commit yet. Exclude secrets, unrelated files and generated logs.
Illustrative proposal:
File: index.html.
Message: Add accessible course-unit toggle.
Excluded: unrelated files and local session records.
Remaining check: [state any actual unrun check].
If you choose to commit locally, stage the named file, inspect the staged diff and then commit. This exercise does not require a push, PR or merge. Do not treat a drafted message as an executed commit.
Remote work is a separate boundary
A push sends code to a remote account. A PR exposes title, body, code and comments to its repository audience. Merge can trigger deployment or other automation. Inspect destination, base branch, contents and effects before any real action.
Draft a PR summary from the verified diff for my review only.
Separate change, actual tests and remaining limitations.
Do not push, create the PR, tag people or merge.
Review the draft against source. Passing CI is useful evidence, not automatic permission to merge.
Graded practice
Easy: read a diff
Identify exactly what changed. Success: unrelated work is not swept in.
Intermediate: restore a copy
Use a disposable checkpoint test. Success: compare restored file with baseline and understand exclusions.
Challenging: prepare a commit
Propose exact files and message. Success: staged content is inspectable, with no remote effects.
Troubleshooting
Rewind did not restore shell changes: that limitation is documented; use a preserved copy or appropriate Git recovery.
Unexpected staged file: unstage the specific file after inspection, not destructive cleanup.
Wrong remote: stop before push.
PR triggers automation: inspect repository rules before comments or merges.
Need to undo a sent effect: local Git/checkpoints cannot retract it. Treat external state separately.