Track last GUI-parity-audited commit in .gui-parity-checked

Records the SHA/date/outcome of each full CLI/GUI parity sweep so the
next audit knows where to start the diff from, instead of guessing or
re-walking the whole history. Documents the update workflow in CLAUDE.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012HY47S9XjHpmTDMmoL3BM5

Author: drandyhaas

.gui-parity-checked

@@ -0,0 +1 @@
+3c249aef270a57c0d6296eacc62367b53582aebf 2026-07-07 no gaps found (audited 3f17a3e..HEAD)

CLAUDE.md

@@ -95,6 +95,17 @@ same change — and vice versa. When adding a flag, grep the
 `kicad_routing_plugin/` call sites for the function you changed and wire it
 through there too.
 
+**Tracking the last-audited commit:** `.gui-parity-checked` (repo root,
+git-committed) holds the SHA of the last commit a full CLI/GUI parity audit
+covered, plus the date and outcome. To bring it up to date: `git log
+--oneline <that-sha>..HEAD` to see what's new, `git diff <that-sha>..HEAD --
+<CLI scripts> kicad_routing_plugin/` to see the engine-side vs GUI-side
+diffs, then check every new engine parameter/flag/results-data key against
+the GUI call sites (per the rule of thumb above). When the audit finds and
+fixes a gap, commit the fix first, note it in the file, then update the file
+to current `HEAD` and commit that too — so the recorded SHA always reflects
+"parity confirmed as of here," not "parity assumed."
+
 ## KiCad Parser Usage
 
 Full user-facing API docs (parser, writer, modification, config, net