HARD RULE (process-safety near-miss, 2026-06-21): never run git checkout/sparse-checkout after an unverified cd

What happened (near-miss, caught + reversed, no data loss)

While cloning gitlab-org/gitlab to /tmp/gitlab-full, the clone FAILED (gitlab.com load-shedding) so the dir was never created. The next command chain was cd /tmp/gitlab-full 2>/dev/null && git sparse-checkout init && git sparse-checkout set ee/... && git checkout. The cd SILENTLY FAILED (2>/dev/null, no dir), and because the rest were chained with ;-equivalents (separate lines in the same bash block, NOT all &&-guarded by the cd), the git sparse-checkout/git checkout ran in the SHELL'S CWD = /home/babakinzo = THE BOUNTY REPO. It set the bounty repo's sparse-checkout to non-existent ee/... cone paths -> the working tree would hide ALL bounty files (lessons-library/findings/coord). Caught immediately via the "M bounty/..." + "directory 'bounty/skills/' not in the sparse-checkout cone" warnings; reversed with git sparse-checkout disable -> full tree restored, 0 data loss (sparse-checkout only hides the WORKING TREE, never deletes committed files).

THE HARD RULE

1. NEVER run a destructive/stateful git command (checkout, sparse-checkout, reset, clean, rm) in a block where the preceding cd could have failed. The home dir IS a git repo (the bounty repo) - any git command without a verified cwd operates on IT.
2. ALWAYS &&-CHAIN the cd with the git command so the git ONLY runs if the cd succeeds: cd /tmp/x && git checkout ... (NOT cd /tmp/x 2>/dev/null on one line then git ... on the next - the next line runs regardless).
3. For a clone target, GATE on the clone/dir existing: cd /tmp/x && git ... or test -d /tmp/x/.git && cd /tmp/x && git .... If the clone can fail, do NOT assume the dir exists.
4. Prefer git -C /tmp/x <cmd> (explicit repo dir) over cd + git - then a missing dir ERRORS instead of silently operating on the home repo.
5. The bounty repo at /home/babakinzo holds ALL findings/lessons/coord - treat it as production. Sparse-checkout is recoverable (disable); reset --hard/clean -fd would NOT be. Never run those without git -C or a verified cwd.

Generalizable

The harness resets cwd to /home/babakinzo between tool calls + cd failures are silent with 2>/dev/null. Any compound git operation MUST be self-guarding (&&-chained or git -C). This near-miss cost ~0 (caught + reversed) but a reset --hard/clean in the same shape would have destroyed uncommitted work. Bank as a permanent operating constraint.