Integrate git into Claude's development process

.claude/CLAUDE.md

@@ -5,42 +5,9 @@
 - When asked to do ONE thing, do exactly that. Do not proactively migrate dependencies, refactor adjacent code, or expand scope. You may suggest further edits, but wait for confirmation before any scope expansion.
 - Prefer the simplest, most localized solution. Changes should target the most-relevant section of code — for example, catch errors in the scope that best handles them rather than injecting data up or down the stack. Take time to think about the best approach rather than quickly jumping to an implementation.
 
-## The Three Virtues
-
-Cultivate the three virtues of a great programmer — **Laziness**, **Impatience**, and **Hubris** — in the spirit of Larry Wall's original formulation. The first virtue deserves particular emphasis.
-
-**Laziness** means going to great lengths to reduce total effort, especially by investing upfront in tools that replace repetitive manual work. It is rare for a large change to be so heterogeneous that no aspect of it can be generalized.
-
-### Automating Sweeping Changes
-
-For large-scale refactors, strongly prefer a script over repetitive manual edits. Two, three, or eight similar changes are fine to do by hand, but 50 similar one-line edits should be automated. This holds even when the script ends up longer or more complicated than the diff it produces.
-
-The preferred workflow:
-
-1. Craft a utility that applies the transformation. Pick the tool best suited to the specific shape of the change — a regex swap for simple textual substitutions, an AST-based rewrite when the change depends on syntactic structure, purpose-built refactoring libraries (e.g. `libcst`, `jscodeshift`, `gofmt -r`, `comby`) when available, or any combination thereof.
-2. Commit the script on its own.
-3. Run it and commit the results as a separate commit.
-
-If inspecting the results reveals missed cases or inappropriate changes, use git to clean up (`git restore`, `git reset --hard` against the pre-script commit), then improve the script. Commit improvements as follow-ups, or amend the script's commit for trivial bug fixes, and re-run.
-
-Continue iterating until:
-
-- **(a) No incorrect changes are included in the diff.** This is a hard requirement — a script that produces even one wrong edit is not done.
-- **(b) Either no missing cases remain, or the remaining cases are few and share too little in common for their inclusion in the script to be easier to validate than just editing them by hand.** When a handful of outlier cases survive the automated pass, handle them in a dedicated commit, separate from both the script-creation commit and the script-execution commit.
-
-### Why This Matters for Review
-
-A refactor script plus a spot-check of its output is far easier to review than a diff of 50 manual edits. The reviewer can be convinced of the logical correctness of the script and sample its results, rather than verifying every edit individually and separately confirming that no instances were accidentally skipped.
-
-### Beyond Refactoring
-
-The same principle generalizes across many aspects of coding. Test suites can and should be easier to reason about than the code they exercise. Formal models that can be mechanically verified are usually more concise than the code implementing them. A performance benchmark provides an explicit representation of the runtime metric that optimizations only improve implicitly.
-
-The common theme: **treat tool creation and tool use as a materialized, first-class part of development — not just ephemeral scratch work during your own process.** Show your work and publish it into the history.
-
 ## Tool Usage Preferences
 
-For simple factual lookups (package versions, release dates), use targeted, purpose-built commands and local CLI tools first before attempting web searches — e.g. `pip index versions <pkg>` for Python, `npm view <pkg> versions` for Node. Prefer fast local approaches over web research.
+- For simple factual lookups (package versions, release dates), use targeted, purpose-built commands and local CLI tools first before attempting web searches — e.g. `pip index versions <pkg>` for Python, `npm view <pkg> versions` for Node. Prefer fast local approaches over web research.
 
 ## Container Environment (Podman)
 
@@ -124,14 +91,6 @@ Assume you are working in a git repository. Partition changes into small, self-c
 
 Leverage the git history during development as well. Git enables efficient and reliable rollbacks of recent changes or research dead ends, and clean reverts of specific diffs from earlier in the history. Prefer these over manual cleanup.
 
-### Automated Safety-Net Commits
-
-An automated cron job periodically sweeps every repository and creates a single timestamped commit containing all outstanding changes — staged, unstaged, and untracked. Its sole purpose is to reduce the chance of losing useful work during prolonged writing and revising sessions; it is not meant to produce the final shape of the history.
-
-When you go to commit your own work and find that the cron job has beaten you to it, treat those commits as raw material to be restructured. Use `git commit --amend`, `git reset --soft`, or non-interactive rebases (`git rebase --exec`, `git rebase --onto`, scripted `git-filter-repo` passes, etc.) to split, recombine, and re-message them into meaningful, atomic steps of work.
-
-Although the cron job occasionally groups together unrelated changes that you would commit separately, the chronological order of the automated commits usually correlates well with the content. Use judgement about whether it is cleaner to soft-reset the entire batch in one go and rebuild the history from scratch, or to replace it piecewise while preserving the commits that are already well-scoped.
-
 ## Green-Field Project Setup
 
 When setting up a new project, code-quality and developer-experience tooling must be included from the start and integrated into the development workflow. The principles below use Python as a concrete example, but apply generally to any language ecosystem.