chore(agents): add repo-sanitization sweep rule

Author: ChipWolf

home/dot_agents/AGENTS.md

@@ -27,6 +27,7 @@ These constraints are unconditional. Apply them without being asked.
 - **A generator that writes one file per category must own and prune its whole output set.** Codegen that emits `<category>.tf` / `<category>.json` from live data typically writes only the files it has content for, so deleting the last item of a category means nothing rewrites that file and the stale one survives, still declaring things that no longer exist. In an IaC round-trip that silently reverses the deletion: the config still declares the resources while their import blocks are gone, so the next plan recreates exactly what you just deleted. Track the filenames written each run and remove the ones the generator owns but did not emit. Pruning then makes an empty input destructive (zero items of every category reads as every category emptied, so every file gets deleted), so guard the entry point on the input actually being present. Verify by running the generator against a second, unrelated target whose input you did not refresh: if that target's files vanish, the guard is missing.
 - **A test suite must survive a fresh clone.** When adding tests that read committed fixtures or goldens, confirm the inputs are actually tracked (`git ls-files <fixture-path>`), then run the suite from a fresh clone or worktree before declaring it done. Broad ignore patterns (`dumps/`, `build/`, `*.json`) silently swallow fixture inputs, leaving a suite that only passes on the authoring machine where the untracked files linger; every other checkout fails with a misleading "input missing" error. If fixture inputs must stay untracked (secrets, size), the test itself must regenerate them, and that regeneration must be code, not a docstring claim.
 - **One sample isn't a measurement.** A single run, repro, or test pass doesn't characterise a noisy phenomenon. Before claiming X differs from Y (faster, more reliable, fixed, broken), gather enough samples to see variance, then report it. Applies anywhere outcomes vary: perf benchmarks, flaky tests, network calls, CI on managed infra, A/B comparisons. If you've only got one data point, mark the conclusion provisional, do not open a PR or change production on it.
+- **Sanitizing a repo means sweeping derived state with an identifier list, not grepping the obvious keyword.** When stripping org-specific or sensitive content from a repo or vault to make a template, the primary documents are the easy part: tool-generated artifacts echo the deleted content and survive a naive sweep (editor workspace/session state, plugin-generated CSS or config, embedding and search caches, cursor-position and navigation history, metadata exports, AI-agent session logs). Build an explicit identifier list from what you deleted (people, hostnames, project keys, email domains) and grep the entire remaining tree against it until clean, and separately scan every tracked config for credential fields, which live in per-plugin JSON, not in code. Two corollaries: a negated ignore pattern (`!dir/file`) marks a file someone chose to keep, so check for exceptions before bulk-removing the directory it lives in; and scrubbing the working tree does not scrub git history, so a repo whose history carried secrets must be published fresh (orphan branch or new repo) and the exposed credentials rotated regardless.
 - **Clone, don't curl.** When reading another repository's source, `git clone` first and read locally. Never `curl` GitHub API endpoints or `curl` raw file URLs to read source, even when docs don't render. (Using `WebFetch` for public documentation pages is fine.)
 - **All Python through mise.** Never invoke `python`, `pip`, `uv`, or `uvx` directly. Use `mise x -- <command>` for all Python toolchain work. Where no version is pinned, `mise x -- python` fails with `No version is set for shim: python`: pin it inline instead, as `mise x python@<version> -- python ...`. That interpreter carries no third-party libraries (`pyyaml` and friends are absent), so do not assume an import resolves; for a one-off parse, reach for a runtime that already has the parser over installing into it.
 - **Never accept a limitation without investigating.** Keep working until the problem is actually solved. Suggesting workarounds as a final answer is not acceptable.