Function retention_group_key 

pub fn retention_group_key(b: &Snapshot, policy_is_multi: bool) -> String

Pure. The retention bucket a Snapshot belongs to.

One bucket per distinct backup source, so GFS keeps keepDaily days of each PVC rather than keepDaily snapshots across all of them. Empty for an un-fanned Snapshot, which is what makes a single-source policy one bucket and therefore unchanged.

Multi-repo fan-out (#368): while the policy is CURRENTLY multi-repo (policy_is_multi), the key also carries the child’s mint-time repository pin (spec.repository, normalized at mint), so GFS keeps keepDaily days per (source, repository) — the N repositories are independent captures and must retain independently. The repo component comes from the SPEC pin ONLY (never status.resolved — a status-derived key would flap with backfills), and applies ONLY while the policy is multi-repo:

• single-repo policy (including after a multi→single edit): source-only buckets, byte-identical to today. Old pinned children merge back into the flat buckets — a documented TRANSIENT GFS mixing (the surviving repo’s rows and the removed repo’s leftovers compete in one bucket) that self-resolves as the removed repo’s rows age out of every keep window.
• multi-repo policy: (source, pin) buckets. Rows with NO pin (pre-feature children minted before the single→multi edit) land in the “”-repo bucket and age out; the policy reconciler’s spec-pin backfill converges them into their real buckets first, so the “”-bucket is a shrinking transition set, not a steady state.