Why kubeconfigs accumulate cruft over time

A kubeconfig grows by accretion — `kubectl config set-context` and cluster-onboarding scripts add entries but rarely remove them, so a file that started as one cluster's config after a year of switching jobs, teams, or projects can end up carrying credentials and endpoints for clusters that were decommissioned long ago. None of that is obviously visible just by looking at the file; every context, cluster, and user entry looks equally "current" until someone actually checks which ones are still in active use, which is the exact gap this tool closes by making it a checklist rather than a manual audit.

Why orphaned clusters and users are worth flagging on their own

A cluster or user entry with no context pointing to it is invisible to `kubectl` — you can't select it, and it does nothing — but it still sits in the file carrying whatever credentials or certificate data it holds. That's true regardless of which contexts you're trying to keep, which is why this tool flags orphaned entries as a separate finding rather than only trimming based on selected contexts: an orphan is dead weight (and a stale credential worth rotating or discarding) even in a file where every context you actually want is otherwise kept untouched.