Detect and migrate duplicate FAVA thoughts safely

[timeleft--]

Parent

• https://github.com/MachineWisdomAI/WisdomLoop/issues/38

What to build

Provide an auditable, dry-run-first way to detect and migrate duplicate governed FAVA records, then use it to clean the known exact-body duplicate groups in mwai/eng/WisdomLoop. Preserve one deliberate canonical record, lifecycle truth, relationships, validation, and provenance. Never silently choose an unapproved replacement over approved current truth.

The planned mutation must be inspectable before apply, require explicit reviewed confirmation, preserve a repository recovery point, and be idempotent. This work repairs governed FAVA lineage; it does not move operational working context into FAVA and does not block the laptop pilot.

Acceptance criteria

• A read-only report identifies exact-body duplicate groups with scope, lifecycle, supersession, relationship, validation, and provenance context.
• Dry run is the default and performs no repository mutation.
• Apply requires an explicit reviewed, tamper-evident migration plan.
• Canonical selection preserves approved current truth.
• References, parentage, and supersession links are redirected safely or reported as blockers.
• Apply creates an auditable repository recovery point and documents rollback.
• Tests cover mixed statuses, linked duplicates, validation conflicts, interrupted apply, and idempotent rerun.
• The known WisdomLoop migration runs only after its exact delete/rewrite set is reviewed.
• Before/after counts and lineage validation are recorded.
• Default governed recall returns one intended current record per cleaned group.

Blocked by

• Enforce governed FAVA recall visibility and atomic supersession #72

This is independent governance cleanup and does not block MachineWisdomAI/WisdomLoop#36.

Delivered tooling and remaining real-data gate

Tooling merged in PR #95 after independent review, 841 tracked tests, independent crash/receipt/privacy probes, and green CI. Reporting and planning are read-only; synthetic apply/recovery/rollback verified exact bytes, lifecycle privacy, durable receipts, and safe reruns.

Private exact-body reports, the regenerated blocked delete/rewrite plan, and historical recovery candidates for the existing malformed records are prepared. The candidate currently remains blocked by malformed records and lineage conflicts. Earlier plan versions are explicitly superseded.

No actual governed-data recovery or migration has been applied. The exact canonical choices, recovery set, lineage edits, and a fresh executable delete/rewrite plan still require explicit owner review and authorization. Projected counts and synthetic current-record checks do not establish real after-counts or cleaned live groups; those criteria remain unchecked.