Use Git checkpoints as durable file evidence

Understand the approach

Git records versions of selected files. A commit is useful because it identifies content you can inspect later, independently of a chat interface. It does not automatically include every file in the folder, preserve ignored outputs or snapshot an external service. Before calling a commit a recovery point, verify which files it contains and whether the working tree already had changes that must be preserved.

The default Orbit Notes --git setup stages the named starter files and records an index tree without creating a commit. It is a useful comparison baseline, but not durable history. The separate verify-commit demonstration creates a fresh owned repository and two actual commits using fictional author identity only for those invocations; it does not save identity settings or use a remote. In your own real repository, use its normal reviewed Git workflow and author identity instead of copying this fictional practice identity. Neither exercise requires changing global Git configuration.

After the Codex task, compare the working tree with the baseline and run the relevant project check. The chat explains the intent; the diff shows file changes; the check supplies behavior evidence. A later commit can preserve the accepted candidate, but committing is not the same as customer acceptance or deployment. Keep those milestones separate so a clean repository does not become a misleading claim that all work is finished.

Create and inspect a real practice commit

The separate verifier creates two actual commits only inside its newly owned temporary repository. Fictional author identity and disabled signing are invocation-only Git options; no identity settings are saved. The first commit deliberately records the broken starter, and the second records only the focused README and search fix.

Inspect the returned path, commit IDs, git ls-tree --name-only HEAD and git show HEAD:README.md. The draft stays untracked. A later README paragraph stays unstaged and is absent from HEAD. This makes history concrete while retaining the index-only default for earlier recovery exercises.

Verify coverage before naming a checkpoint

The optional setup stages .gitignore, AGENTS.md, README.md, WORK-NOTE.md, checks.cjs, cli.cjs, notes.cjs and notes.json. Inspect the actual staged list and tree identifier. Later git add changes the index; the exercise calls it a disposable comparison baseline, not durable commit history.

After the candidate, inspect the working diff and untracked draft separately. The offline demonstration restores one file from the index and confirms the draft survives. A real reviewed commit records selected content in history, but it still does not include untracked/ignored material or prove deployment, user acceptance or external rollback.

Git and Codex have complementary roles

Use Codex to explain a diff, identify a missing regression case or draft a recovery plan. Verify the baseline in Git. When rejecting a change, preserve unrelated work through a targeted correction rather than requesting unrestricted repository cleanup.

Try it step by step

1. Create a fresh Orbit Notes --git copy using the linked lab guide, inspect its actual path and review every staged file.
2. Use the staged index tree for the exercise and identify it explicitly; choose a separate copy if Git is unavailable.
3. Complete the focused task and compare its working files with that index baseline and the original six-check contract.
4. Record the actual index tree or copy, relevant check results, and untracked/ignored outputs. Treat a later commit only as a separate optional step with an already usable identity.

A useful starting example

Illustration · adapt before use.

git status --short
git diff --cached --name-only
git diff -- README.md notes.cjs
git show :README.md

git add -- README.md
git diff --cached --name-only
# Inspect the complete staged list before choosing to commit.
git commit -m "Record reviewed practice baseline"

node labs/project-workflow/verify-commit.cjs

Check your result

• The baseline identifier points to the expected named content and does not silently include unrelated files.
• Untracked and ignored files are accounted for instead of being assumed recoverable through the commit.
• The final report distinguishes committed, checked, accepted and published states.

Common mistakes

• Using git add . in a shared working tree without inspecting every included file.
• Treating a commit, passing test or saved transcript as a universal record of all project and external state.