[perfectra1n]

Problem

A field report (HOPS Discord, 2026-08-29) showed a SnapshotPolicy emitting the NoAdoptableHistory Warning event on every reconcile — 428+ aggregated occurrences and climbing — on a completely healthy cluster. The trigger was the ordinary shared-repository lifecycle: retire app A (the deletion cascade's default Retain keeps its kopia snapshots, which the catalog scan materializes as discovered rows), then add new app B against the same ClusterRepository. B, having no history of its own yet, matched none of A's rows and was accused of a disaster-recovery identity mismatch until its first successful backup — days to a week on typical crons. The user's fix was adoption: Ignore, i.e. the warning taught them to disable the very adoption it was meant to protect.

Why removal rather than tuning

The event (from #380) existed as a CREATE-time stand-in for the update-gated identity fork guard, targeting one DR case: a recovered policy whose identity no longer matches the history it should reclaim. But kopia identity in kopiur is a pure function of Git-authored inputs (crates/api/src/identity.rs — name, namespace, spec.identity, identityDefaults incl. cluster, labels/annotations, PVC name, sourcePathOverride; no live-environment inputs). A GitOps re-apply cannot drift an identity on its own — every mismatch begins as a human manifest edit. The operator cannot distinguish that rare case from the common shared-repo case, so the standing Warning had negative net value: it trained the suppression reflex that disarms it for the rare real case too.

What replaces it (neutral facts, not judgment)

• status.adoption.lastScanMatched / lastScanUnmatched — what each adoption pass actually saw: discovered rows matching this policy's identity (counted before the own-id/retention filters) vs. not. Multi-repo policies sum across ready targets; absent = no pass has run; 0/0 = empty catalog.
• kubectl kopiur status now renders each repository's discovered-snapshot count (status.catalog.discoveredBackupCount) as a plain inventory column — no warn/fail semantics.
• Docs: the DR runbook's verification flips from "no warning events" to positively asserting adoption happened (the new counters + kubectl kopiur snapshots list --origin discovered --repository X + totalAdopted); identityDefaults/cluster docs warn that edits strand history behind the old identity and that the fork guard cannot challenge CREATEs on a rebuilt cluster; troubleshooting absorbs the deleted event message's guidance; docs/upgrade.md gets a "no action needed" note — if you set spec.adoption: Ignore solely to silence this warning, you can remove it now.

Regression guard

New e2e scenario foreign_history_policy_stays_quiet_and_adopts_nothing reproduces the report's exact shape (policy A retired with Retain → discovered rows; zero-history policy B on the same repo) and asserts through a 60s settle window: no NoAdoptableHistory event, no adoption, rows stay Discovered, and the counters record lastScanMatched: 0 / lastScanUnmatched ≥ 1.

Verification

• mise run test — green (one unrelated fake_shim ETXTBSY flake reproduced identically on a clean main worktree; passes serially and on retry)
• mise run clippy / fmt-check / complexity-check (29/29, unchanged) / gen + gen-check — all green
• e2e (KOPIUR_E2E_BINS="adoption cli"): 16/16 passed, including the new scenario (78s) and cli_doctor_and_status with the new column

Removes a user-visible event reason (NoAdoptableHistory) and its CheckIdentityConfiguration action — no schema removal, no RBAC change; the two status fields and the CRD regeneration are additive.

[greptile-apps]

Greptile Summary

The PR removes the noisy NoAdoptableHistory warning and replaces it with neutral adoption and repository inventory.

• Adds lastScanMatched and lastScanUnmatched to SnapshotPolicy adoption status and generated CRDs.
• Aggregates scan outcomes across ready repository targets while preserving adoption and retention behavior.
• Adds discovered-snapshot inventory to kubectl kopiur status.
• Updates disaster-recovery and troubleshooting documentation and adds an end-to-end regression scenario.

Confidence Score: 5/5

The PR appears safe to merge, with the removed warning consistently replaced by documented status inventory and regression coverage.

The new counters preserve the stated absent-versus-zero semantics, ignored and unavailable targets remain correctly gated, generated schemas and CLI output are aligned, and no concrete changed-code failure remains.

Important Files Changed

Filename	Overview
crates/api/src/snapshot_policy.rs	Adds optional, correctly serialized adoption scan counters and round-trip coverage for absent versus explicit-zero values.
crates/controller/src/adoption.rs	Replaces the warning predicate with pre-filter matched and unmatched candidate counts without changing candidate selection.
crates/controller/src/snapshot_policy.rs	Removes warning publication and safely aggregates and persists scan counters across participating ready targets.
crates/cli/src/cmd/status.rs	Adds repository discovered-snapshot counts to human-readable and serialized status output with focused tests.
crates/e2e/tests/adoption.rs	Adds an isolated shared-repository regression scenario covering warning absence, non-adoption, row preservation, and status counters.
deploy/crds/snapshotpolicies.yaml	Carries the additive status fields into the generated standalone CRD schema.
deploy/helm/kopiur/crds/snapshotpolicies.yaml	Keeps the Helm-packaged CRD aligned with the Rust API and standalone generated schema.
docs/scenarios/dr-with-replicated-repository.md	Updates disaster-recovery verification to use positive adoption evidence instead of warning-event absence.

_{Reviews (1): Last reviewed commit: "fix(controller): remove the NoAdoptableH..." | Re-trigger Greptile}