Cascade-Prune Stale Local Clones After Upstream PR Merge
Cascade-Prune Stale Local Clones After Upstream PR Merge
When: any agent merges a PR in an upstream-canonical doc/spec repo (e.g., ARJ999/MCP-God-Agent-Development-Bible, framework specs, OpenAPI definitions).
Required cascade step (post-merge, same operation):
# locate any local clone of the just-bumped repo
find /root/<workspace>/outputs -type d -name "<repo-name>"
# remove if found — derivable on demand via gh repo clone
rm -rf <found-path>Why: local clones in outputs/documents/ are gitignored (no parent tracking), nested-repo style. They go stale the moment upstream main advances. Future grep over outputs/ returns mixed-version hits, future pristine-sweep cascade-checks misfire on the stale copy. Derivable resources should not be cached on disk.
Distinction — do NOT prune historical session artifacts (e.g., <feature>-upgrade-plan/UPGRADE-PLAN.md) that explicitly reference the prior version:
- Stale clone = snapshot of an upstream resource → re-fetch when needed
- Historical record = narrative of a past session’s reasoning → immutable; bumping its version refs falsifies history
Test: ask “is this a snapshot of something that lives upstream, or a record of decisions made at a point in time?” Snapshot → prune on upstream advance. Record → leave forever.
Generalizes to: cron-installed mirrors, vendor doc clones, GitHub release zip-extracts, any “I cloned this for offline reference” artifact. Apply on every upstream PR merge.