docs: Triage aller 42 Fehlerberichte (Empfehlungen + Cluster-Matrix)

Automatische Triage (ein Subagent pro Ticket): pro Ticket Ursache, Empfehlung,
Fix-Ebene, betroffene Dateien, Aufwand, Konfidenz + Überschneidungs-Matrix nach
Cluster und offene Rückfragen an die Züchterin. Grundlage für die gebündelte
Implementierung nach Cluster.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/ticket-triage.md

@@ -0,0 +1,457 @@
+# Ticket-Triage — Fehlerberichte (42)
+
+_Automatische Triage (ein Subagent pro Ticket). Stand: 2026-06-22. Quelle: `GET /feedback`. Phase 1 = Empfehlungen; Implementierung erfolgt gebündelt nach Cluster (Phase 2)._
+
+## Überblick
+
+- **Tickets:** 42
+- **Kategorie:** data-parents: 24, genetics: 10, other: 2, app-logic: 2, dedup: 2, gender: 1, photo: 1
+- **Fix-Ebene:** import-logic: 20, import-data: 12, genetics-engine: 9, frontend: 1
+- **Aufwand:** M: 31, S: 10, L: 1
+- **Konfidenz:** high: 40, medium: 2
+
+## Cluster / Überschneidungs-Matrix
+
+| Cluster (overlapKey) | Tickets | Fix-Ebene | # |
+|---|---|---|---|
+| `missing-parents` | #8, #9, #11, #13, #27, #29, #30, #31, #35 | import-data, import-logic | 9 |
+| `wrong-parents` | #12, #15, #16, #21, #22, #23, #26, #36 | import-data, import-logic | 8 |
+| `dedup-duplicate` | #18, #25 | import-logic | 2 |
+| `gender-unknown` | #1, #2 | import-data | 2 |
+| `genetics-farbschlag` | #3, #24 | genetics-engine, import-logic | 2 |
+| `genetics-notation-uw` | #32, #34 | genetics-engine | 2 |
+| `litter-expected-colors` | #40, #41 | genetics-engine | 2 |
+| `non-resident-display` | #17, #20 | import-logic | 2 |
+| `chart-position-wrong-parents` | #28 | import-logic | 1 |
+| `genetics-elocus-e-dash` | #42 | genetics-engine | 1 |
+| `genetics-inheritance` | #38 | genetics-engine | 1 |
+| `genetics-unknown-allele-wildcard` | #39 | genetics-engine | 1 |
+| `genetics-wildcard-expansion` | #37 | genetics-engine | 1 |
+| `given-away-receiver-missing` | #4 | import-data | 1 |
+| `missing-parents-founder` | #10 | frontend | 1 |
+| `origin-label` | #19 | import-data | 1 |
+| `photo-mismatch` | #14 | import-logic | 1 |
+| `wrong-parents-chart-position` | #7 | import-data | 1 |
+| `wrong-parents-external-breeder` | #5 | import-logic | 1 |
+| `wrong-parents-gender-swap` | #33 | import-logic | 1 |
+| `wrong-parents-stammbaum-vance` | #6 | import-data | 1 |
+
+## Offene Rückfragen an die Züchterin
+
+- **#1 Cherry Berry's Quqquluuruu (e9c6d0bd-bcd0-58aa-a01f-3ff32f731f33):** Ist das Geschlecht von „Cherry Berry's Quqquluuruu" bekannt (vermutlich weiblich)? Falls ja, sollte es in den Quelldaten/Import-Auflösung gesetzt werden — aus den Stammbaum-Zellen ist es nicht ableitbar.
+- **#3 (ohne Namen), gerbilId 6864eaef-..., Genotyp aa c[chm]c[chm] dd ee[-] gg Pp Spsp:** Soll-Farbschlag fuer aa c[chm]c[chm] dd ee[-] gg bestaetigen: laut Schwester-Ticket 3deab547 zu demselben Tier "Dilute-CP-Polarfuchs". Stimmt das als erwartete Ausgabe?
+- **#4 Arya Stark von den Kleinen Chaoten (b4f59085-5d0d-51b0-9c94-bddf622b5935):** Abgabedatum an Clan of Black Forest und ob Arya dort verstorben ist (DOD 31.12.2024 stammt aus dem Stammbaum).
+- **#6 Sunny von PZ Karl (5c4982a5-d92d-568a-a9bf-0b39b990c72f):** Hat Sunny von PZ Karl bekannte Eltern oder ist sie wurzellos zugekauft? Falls Eltern bekannt sind, bitte korrekte Namen nennen.
+- **#7 Sunny von PZ Karl (5c4982a5-d92d-568a-a9bf-0b39b990c72f):** Sind Sunnys echte Eltern bekannt, oder unbekannt (Fremdzukauf von PZ Karl)? Falls unbekannt, Eltern komplett entfernen statt zu korrigieren.
+- **#8 Melly von Privat (5b928c39-aa57-57b8-ac50-219b1316850c); Wurf "Hazel of Helianthus + Herakles II of sweet little mouse" (9390031f-c922-50bf-9660-1b0d525d9eb4):** Gibt es zwei verschiedene "Herakles II of sweet little mouse"? Das bekannte Tier ist *16.12.2013, der Wurf von Melly aber 30.09.2013 - welches Geburtsdatum (Tier oder Wurf) stimmt?
+- **#10 Hiro of Golden Lights (bbfdf289-91bf-52a8-abf3-2cb718a6ac0d):** Sind Hiros Eltern tatsächlich bekannt? Falls ja, bitte Namen nennen - sonst gilt er korrekt als Gründertier ohne Vorfahren.
+- **#14 Odelia von den Kleinen Chaoten (3609e642-73e4-579e-87f1-da0332b1d037):** Welches der 3 Fotos (sortOrder 0/1/2) zeigt Odelia tatsaechlich? Noetig, um das korrekte Profilfoto festzulegen und die falschen zu entfernen.
+- **#19 Hagrid Rubeus of Black Forest:** Lautet der korrekte Zuchtname generell Clan of Black Forest und gilt das fuer alle Tiere mit Suffix of Black Forest?
+- **#21 Danielle von den Kleinen Chaoten (d45a36a8-9347-54e5-bfba-3648487ae527), Wurf acd30ec1-f71f-583b-b5ae-f85c40b782c6:** Wer sind Danielles echte Eltern (Vater + Mutter mit Name)? Aktuell ist Roswitha als Mutter eingetragen (falsch) und kein Vater. Im Quell-Stammbaum standen "Roswitha" und "Ella" als Elternpositionen.
+- **#22 Danielle von den Kleinen Chaoten (d45a36a8-9347-54e5-bfba-3648487ae527):** Bestätigen: Sind Danielles Eltern Louis (Vater) und Roswitha (Mutter), oder ist auch die Mutter eine andere (vgl. parallele Meldung 'Falsche Mutter')? Existiert ein eigenes Stammbaum-Quellblatt für Louis?
+- **#24 Tier 6864eaef (ohne Namen, w, *13.11.2023, Quelle "Stammbaum von Picus Son.xlsx"):** Welcher Farbschlag/Genotyp ist korrekt? Nutzerin sagt "Dilute CP-Polarfuchs", Quelldatei "Dilute CP-Blaufuchs", gespeicherter Genotyp aa cchm dd ee gg (das wäre engine-seitig "Zobel Schecke", nicht CP-* da CP A- voraussetzt).
+- **#25 Namenloses Männchen, DOB 2024-02-15, Vater Inochi gen. Picu (IDs 5b5af108… und 13944d01…):** Bestätigen, dass beide Einträge wirklich dasselbe Tier sind (namenlos, Mutter in beiden Diagrammen unbekannt). Falls ja: sollen die zwei rekonstruierten Würfe (Picus Son vs Alberto Kids) ebenfalls zu einem Wurf zusammengeführt werden?
+- **#26 Gaida von den Kleinen Chaoten (Wurf dd830a45 „Nisha + Zaibunissa"):** Bestätigen: korrekter Vater = Zenon von Elea (cd2ee35e, male, geb. 2019-10-06)? Und sind Nisha und Zenon Vollgeschwister (gemeinsamer Wurf), damit die Geschwisterverpaarung korrekt markiert wird?
+- **#27 Belica gen. Emi von den Kleinen Chaoten (e94dac93-ad99-52a3-9cbe-b5ccf2cd5375):** Bestätigung: Existiert "Hanau von den Kleinen Chaoten" als eigener Stammbaum/eigenes Tier (mit Geburtsdatum/Genotyp)? Falls nein, muss ein Mutter-Datensatz neu angelegt werden, nicht nur ein Link gesetzt.
+- **#29 Catelyn Stark von den Kleinen Chaoten, Wurf 521df803:** Wurfname nennt Katara weiblich, Chart-Position deutet auf Eddard Stark of Sunset Glow maennlich. Korrekten Vater bestaetigen.
+- **#39 Wurf von Mamta Mini v.d. Kleinen Chaoten + Gold v.d. Kleinen Chaoten (98bfdf92-f0aa-546f-8eb1-972b3aff71ea):** Welche Semantik soll "-"/unbekanntes Allel in der erwarteten-Farbschlag-Berechnung haben: konservativ als sichtbares dominantes Allel annehmen (kein Dilute, keine unbekannten Farbschlaege) oder rezessive Outcomes nur als "moeglich" anzeigen?
+- **#41 Wurf 98bfdf92 (Vater Mamta Mini da911047 × Mutter Gold e489b704):** Was bedeutet das "[-]" in "Ee[-]" beim Vater Mamta Mini genau – ein unbekanntes drittes Allel, oder soll der E-Locus schlicht "Ee" sein? Davon hängt ab, ob die Korrektur in der Engine (Wildcard-Regel) oder in den Quelldaten/Import erfolgt.
+
+## Details nach Cluster
+
+### Cluster `missing-parents` (9)
+
+#### #8 — Melly von Privat: Vater im Stammbaum unbekannt, obwohl Wurfname "+ Herakles II" nennt
+- **Tier/Wurf:** Melly von Privat (5b928c39-aa57-57b8-ac50-219b1316850c); Wurf "Hazel of Helianthus + Herakles II of sweet little mouse" (9390031f-c922-50bf-9660-1b0d525d9eb4)  ·  Kontext: stammbaum  ·  Ticket `bee684ed`
+- **Meldung:** Eltern sind unbekannt
+- **Ursache:** Mellys virtueller Wurf (Datum 30.09.2013) hat motherId=Hazel of Helianthus (gueltig), aber fatherId=null. Der Wurfname nennt als Vater "Herakles II of sweet little mouse", doch das einzige gleichnamige Tier in der DB ist *16.12.2013 geboren - also NACH dem Wurf, parent_age_plausible schlaegt fehl, der Vater ist nicht zuordenbar. Zusaetzlicher Logik-Mangel in merge_and_resolve.py: die virtuelle Litter wird (Zeile 1652/1663) sofort mit einer synthetischen FatherId generate_guid("stammbaum-animal-{name}") vorbelegt; weil FatherId damit gesetzt ist, ueberspringt die echte Namens-/Alters-Aufloesung _resolve_name (Zeile 2748, nur bei "not FatherId"), und die synthetische ID zeigt auf kein reales Gerbil, also liefert die API fatherId=null. Die Alters-Verwerfungs-Erklaerung (Zeile 2825/2844) greift nie, daher steht in der Provenance KEIN Discard/Grund - der Vater verschwindet kommentarlos und die Nutzerin sieht nur "unbekannt".
+- **Empfehlung:** Zwei Hebel: (1) Datenseite - Herakles II of sweet little mouse hat ein unplausibles DOB (16.12.2013 vs. Wurf 30.09.2013). Ueber Import-Aufloesung/Quelldaten pruefen, ob zwei verschiedene "Herakles II" existieren bzw. das Geburtsdatum korrigieren; sonst bleibt der Vater zu Recht offen. (2) Logik/Transparenz in merge_and_resolve.py - die virtuelle Litter NICHT mit synthetischer FatherId/MotherId vorbelegen (Zeile 1652/1663), sondern leer lassen, damit _resolve_name (Zeile 2748) greift; bei nicht aufloesbarem benanntem Elternteil einen Provenance-Discard auf Kind und Litter setzen (z.B. 'Vater Herakles II (*16.12.2013) verworfen - unplausibles Alter; kein Ersatz'), damit die App erklaert, warum der Elternteil unbekannt ist, statt ihn kommentarlos wegzulassen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py:1648-1664 (virtuelle Litter FatherId/MotherId Vorbelegung); tools/import/merge_and_resolve.py:2748-2758 (_resolve_name nur bei not FatherId); tools/import/merge_and_resolve.py:2818-2844 (parent-age sanity + Discard-Erklaerung); Gerbil Herakles II of sweet little mouse (cba75d0e-c985-5322-b25c-40733305cb37, DOB 2013-12-16) Quelldaten/DOB; Litter 9390031f-c922-50bf-9660-1b0d525d9eb4 (fatherId=null, Name nennt Vater)
+- **Rückfrage:** Gibt es zwei verschiedene "Herakles II of sweet little mouse"? Das bekannte Tier ist *16.12.2013, der Wurf von Melly aber 30.09.2013 - welches Geburtsdatum (Tier oder Wurf) stimmt?
+
+#### #9 — Eltern von Beatrice (Q-Wurf) fehlen, obwohl sie in der Wurf-Notiz "Eltern: Dante + Malina" stehen
+- **Tier/Wurf:** Beatrice von den kleinen Chaoten (cefb6e97-95ca-51ba-976a-02492c6a46de), Litter Q-Wurf eb8047f2-c234-512b-b719-fe6ac6610d9c  ·  Kontext: stammbaum  ·  Ticket `aa530d1b`
+- **Meldung:** Eltern fehlen
+- **Ursache:** Q-Wurf (Quelle: Wurfchronik Teil 1_page_0016.md) hat fatherId/motherId=null; Eltern stehen nur im Freitext notes="Eltern: Dante + Malina". Schon das Quell-md-JSON liefert FatherName/MotherName=null. Der Parent-Resolver (_resolve_name ab Z.2700) loest Eltern nur aus strukturierten _father_name/_mother_name bzw. scoped IDs auf, parst notes nie. Passende Gerbils existieren (Dante *2010-05-08 exakt; Malina of minor diabolus *2010-03-22, Teilname). 46 Wuerfe haben "Eltern:"-Notiz mit beiden Eltern null.
+- **Empfehlung:** "Eltern: X + Y"-Notizen strukturiert auswerten: in merge_and_resolve.py vor dem Parent-Resolver _father_name/_mother_name aus dem notes-Pattern befuellen, wenn FatherName/MotherName/IDs fehlen (Regex Eltern:\s*(.+?)\s*\+\s*(.+?)(?:;|$)). Dann greift der bestehende _resolve_name automatisch (Gender-Rollen + Altersplausibilitaet). Fuer Teilnamen wie "Malina" Call-Name-/Praefix-Match nutzen; "Dante" matcht exakt. Behebt zugleich ~46 weitere Stammbaum-Tickets gleicher Ursache.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (Parent-Resolver _resolve_name ~Z.2700-2758; raw-litter Aufbau ~Z.1310-1316 und ~Z.1766-1786); Quelldatei Wurfchronik Teil 1_page_0016.md (notes statt FatherName/MotherName); Litter eb8047f2-c234-512b-b719-fe6ac6610d9c
+
+#### #11 — Silver: Vater (Taro) fehlt im Stammbaum, Mutter Beatrice ohne Vorfahren
+- **Tier/Wurf:** Silver von den kleinen Chaoten (52ab2bd9-...), F2-Wurf (581fb310-...)  ·  Kontext: stammbaum  ·  Ticket `671f8b5d`
+- **Meldung:** Vater ist bekannt! Auch von der Mutter fehlt der Stammbaum
+- **Ursache:** F2-Wurf (Silvers Wurf) hat fatherId=null. Quelle page_0023 nennt eindeutig "Taro" als Vater; Taro existiert als gerbil eabcf39c-... auf page_0021/U1-Wurf (geb. 2012-09-01, altersplausibel zum Wurf 2013-03-20). Resolver verwirft diesen seitenuebergreifenden FatherId in merge_and_resolve.py:2685 (nicht in valid_gerbil_ids, da Taro/page_0021 im aktuellen Datensatz nicht geladen ist - DB hat nur 20 Tiere), und der Namens-Fallback :2748 greift nicht, weil das Wurfchronik-Litter-JSON kein FatherName/MotherName liefert -> _father_name=None. Gleiche Luecke bei Mutter Beatrice: ihr Wurf Q-Wurf (eb8047f2-...) hat father/mother=null, Eltern "Dante + Malina" stehen nur in litter.Notes, nie strukturiert -> Stammbaum der Mutter bleibt leer.
+- **Empfehlung:** Zweigleisig: (1) import-data: Taro/page_0021 mit-ingesten und re-ingest, dann kann F2-Wurf wieder verlinkt werden. (2) import-logic in merge_and_resolve.py: bevor ein cross-page FatherId/MotherId bei :2685 auf null gesetzt wird, den Namen des referenzierten Gerbils nachschlagen und in _father_name/_mother_name ablegen, damit der Namens-Resolver :2748 ihn nach vollstaendigem Ingest wiederfindet. Zusaetzlich "Eltern: X + Y" aus litter.Notes (z.B. Q-Wurf) in _father_name/_mother_name parsen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** C:/Users/gulum/dev/GerbilManager/tools/import/merge_and_resolve.py:2685 (FK-Cleanup verwirft cross-page FatherId); C:/Users/gulum/dev/GerbilManager/tools/import/merge_and_resolve.py:2748 (_resolve_name Namens-Fallback); C:/Users/gulum/dev/GerbilManager/tools/import/merge_and_resolve.py:1766-1786 (FatherName/MotherName-Mapping fuer Wurfchronik-Litter); Quelldaten: Wurfchronik Teil 1_page_0021.md (Taro) + page_0023.md (F2-Wurf); litter 581fb310-9664-5acd-b2cb-6c3cc8ea15d6 (F2-Wurf, fatherId=null); litter eb8047f2-c234-512b-b719-fe6ac6610d9c (Q-Wurf, father/mother=null)
+
+#### #13 — Cooky vom Zooladen OBI: falsche Eltern statt unbekannt
+- **Tier/Wurf:** Cooky vom Zooladen OBI 13448dc5-2bad-5a30-b63e-8d787874b566  ·  Kontext: stammbaum  ·  Ticket `b46d5807`
+- **Meldung:** Eltern sind unbekannt!!
+- **Ursache:** Cooky ist ein Zooladentier und damit ein Gruendertier mit echt unbekannter Abstammung. Der positionsbasierte Eltern-Resolver extract.py _reconstruct_parents hat ihr ueber Nachbarbloecke in Stammbaum von Vance.xlsx trotzdem einen Wurf zugewiesen: litterId 695098a4, motherId Qamikaze Queen, fatherId null, Wurfname fabriziert Jack Jr. parentMethod chart-position, confidence medium, reine Positions-Heuristik ohne Origin-Check.
+- **Empfehlung:** Externe Herkunfts-Tiere als Gruendertiere behandeln. In _reconstruct_parents bzw merge_and_resolve Namensmarker fuer externe Herkunft erkennen wie vom Zooladen, OBI, von Privat, auslaendische Zuchten und fuer solche Tiere keine chart-position parentRefs erzeugen bzw den rekonstruierten Wurf verwerfen. Kurzfristig Eltern-Link fuer diese gerbilId via conflict-decisions.json entfernen und neu ingesten.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/extract.py _reconstruct_parents; tools/import/merge_and_resolve.py Eltern-Resolver; tools/import/conflict-decisions.json; Gerbil 13448dc5-2bad-5a30-b63e-8d787874b566; Litter 695098a4-17e0-5e8b-a281-0adebb206237
+
+#### #27 — Belica gen. Emi: Mutter nicht verknüpft, Name als "Hana" statt "Hanau" erfasst
+- **Tier/Wurf:** Belica gen. Emi von den Kleinen Chaoten (e94dac93-ad99-52a3-9cbe-b5ccf2cd5375)  ·  Kontext: stammbaum  ·  Ticket `ce404b2d`
+- **Meldung:** Die Mutter ist bekannt und heißt "Hanau von den Kleinen Chaoten"
+- **Ursache:** Belicas Wurf (2b4bd250-...) hat motherId=null; der Muttername steckt nur im Wurf-Titel als "Hana von den Kleinen Chaoten" (laut Nutzerin korrekt "Hanau"). Der Name wurde aus dem Stammbaum-xlsx erfasst, aber _resolve_name fand kein passendes Gerbil (weder "Hana von den Kleinen Chaoten" noch "Hanau..." existiert als Datensatz), daher blieb der Mutter-Link leer. Vermutlich Lesefehler des Namens (Hana vs. Hanau) plus fehlender Mutter-Datensatz.
+- **Empfehlung:** Im Quell-Stammbaum (Goldfuchs Sp (Pikachu) Kids / Watarus Kids) den Mutternamen auf "Hanau von den Kleinen Chaoten" korrigieren bzw. einen Namens-Alias/conflict-decision setzen, sodass ein Mutter-Datensatz existiert/angelegt wird und _resolve_name den Wurf-Mutter-Link befüllt. Danach extract + merge_and_resolve neu laufen lassen und POST /import/ingest-resolved.
+- **Fix-Ebene:** import-data · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (_resolve_name / Eltern-Resolver ~Z.2754); Quelldatei Stammbaum von Goldfuchs Sp (Pikachu) Kids.xlsx / Watarus Kids.xlsx; Litter 2b4bd250-3fa1-59c8-9f4c-9db0ff05ccd1 (motherId=null); Gerbil e94dac93-ad99-52a3-9cbe-b5ccf2cd5375
+- **Rückfrage:** Bestätigung: Existiert "Hanau von den Kleinen Chaoten" als eigener Stammbaum/eigenes Tier (mit Geburtsdatum/Genotyp)? Falls nein, muss ein Mutter-Datensatz neu angelegt werden, nicht nur ein Link gesetzt.
+
+#### #29 — Catelyn Stark: Eltern im Stammbaum nicht angezeigt
+- **Tier/Wurf:** Catelyn Stark von den Kleinen Chaoten, Wurf 521df803  ·  Kontext: stammbaum  ·  Ticket `7bbc045c`
+- **Meldung:** Die Eltern sind bekannt!
+- **Ursache:** Wurf 521df803 hat fatherId und motherId null in der DB; build.ts zeigt Eltern aus litter.fatherId und litter.motherId, daher leer. Chart-Position lieferte als Elternpaar zwei Weibchen, Katara geboren 2014-02-24 und Milena geboren 2014-03-19. assign_parent_roles in merge_and_resolve.py Zeile 640 kann mit zwei Weibchen keine Vaterrolle fuellen. Laut Provenance wurde der Vater-Kandidat Eddard Stark of Sunset Glow, maennlich geboren 2012-06-20, als falsches Geschlecht fuer die Mutterrolle verworfen, die roleGuess war vertauscht.
+- **Empfehlung:** Eltern manuell setzen: Vater Eddard Stark of Sunset Glow Id 438d2c9e, Mutter Milena Id 72076dbe, beide existieren und altersplausibel. Per manual-import Override auf litter 521df803, dann neu ingesten. Mittelfristig die roleGuess der Chart-Position-Eltern im Import korrigieren. Bei der Nutzerin den tatsaechlichen Vater rueckfragen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py; tools/import/extract.py; Litter 521df803-d67c-5ed6-a8a1-9ce530e938ff; gerbil-manager-web/src/pedigree/build.ts
+- **Rückfrage:** Wurfname nennt Katara weiblich, Chart-Position deutet auf Eddard Stark of Sunset Glow maennlich. Korrekten Vater bestaetigen.
+
+#### #30 — Theodores Vater BlackFire wird im Stammbaum nicht verknüpft (fehlt)
+- **Tier/Wurf:** Theodore von den Kleinen Chaoten (529a57a7-...); Wurf c5893a98-...; Vater BlackFire von den Kleinen Chaoten (60dfb117-...)  ·  Kontext: stammbaum  ·  Ticket `1a51dc7a`
+- **Meldung:** Seine Eltern sind bekannt! Sein Vater ist BlackFire von den Kleinen Chaoten
+- **Ursache:** Der Vater existiert (Gerbil 60dfb117-..., "BlackFire von den Kleinen Chaoten", männlich), ist aber im Wurf c5893a98-... NICHT verknüpft: fatherId=null. Der Wurftitel führt "BlackFire v.d. Kleinen Chaoten", das Tier heißt aber "BlackFire VON DEN Kleinen Chaoten". normalize_name() (merge_and_resolve.py:115) reduziert auf alphanumerisch -> "blackfirevdkleinenchaoten" != "blackfirevondenkleinenchaoten". Dadurch findet der Namens-Fallback _resolve_name() (Z.2700/2748) keinen Treffer; der synthetische Platzhalter-FatherId (generate_guid stammbaum-animal-<normname>) steht nicht in gerbil_id_map und wird als ungueltiger FK auf null gesetzt (Z.2685). Mutter Katara wurde separat ueber Theodores parentRefs/chart-position aufgeloest, daher fehlt nur der Vater.
+- **Empfehlung:** In merge_and_resolve.py den Namensabgleich fuer Abkuerzungsvarianten reparieren: entweder normalize_name() um "v.d."->"von den" (und "v."->"von") erweitern, ODER _resolve_name() zusaetzlich ueber get_call_name() (Rufname "BlackFire") matchen lassen -> dann greift der Vater-Fallback und verknuepft 60dfb117-... Anschliessend Import neu erzeugen + POST /import/ingest-resolved. Schneller Daten-Workaround: fatherId des Wurfs c5893a98-... per Aufloesung auf 60dfb117-... setzen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py: normalize_name (Z.115), _resolve_name (Z.2700), FK-Cleanup (Z.2685), Namens-Fallback (Z.2748); Wurf c5893a98-61c1-5c3d-88d6-1d232e0be09d (fatherId=null); Gerbil 60dfb117-9f93-5151-8205-12b250982170 (BlackFire von den Kleinen Chaoten)
+
+#### #31 — Jamies Vater fehlt im Stammbaum (sollte Danny von Privatzucht Maintal sein)
+- **Tier/Wurf:** Jamie von den kleinen Chaoten (8ddf3717), Wurf 353796eb  ·  Kontext: stammbaum  ·  Ticket `864f0c55`
+- **Meldung:** Jamies Vater ist bekannt und heißt " Danny von Privatzucht Maintal"
+- **Ursache:** Jamies Wurf 353796eb hat fatherId=null. Jamies parentRefs stammen nur aus der Chart-Position der Stammbaum-xlsx und sind fehlerhaft: Jana (weiblich) als father, Chap of little Angels (DOB 03.06.2011, nach Jamies DOB 27.12.2010) als mother. Der Resolver verwarf Chap korrekt (parent_age_plausible) und liess den Vater leer. Die Wurfchronik kennt den echten Vater: Litter G vom 25.10.2010 mit sire Danny Privatzucht Maintal und dam Jana little longnoses, wurde aber wegen Datumsdifferenz nicht mit Jamies Pedigree-Wurf gemerged. Danny existiert daher nicht als Tier in der DB.
+- **Empfehlung:** Den fehlenden Vater Danny von Privatzucht Maintal als Tier anlegen und als fatherId des Wurfs setzen, oder Jamie an die Wurfchronik-Litter G mit Mutter Jana und Vater Danny binden. Mechanisch: Litter-Merge zwischen Pedigree-Wurf und Wurfchronik-G durch toleranteres Datums-Matching ermoeglichen. Die falschen chart-position parentRefs duerfen die korrekte Wurfchronik-Angabe nicht ueberschreiben.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py; tools/import/output/litters.json id=sheet1-G-25.10.2010; tools/import/output/animals.json Jamie parentRefs; Wurf 353796eb-a46b-588a-bf4a-258633aab791
+
+#### #35 — Zacs Mutter "Dorie of Black Forest" fehlt – Import hat zwei Väter erkannt
+- **Tier/Wurf:** Zac gen. Action von den Kleinen Chaoten (0bd5bc9b-d22f-5c65-a47f-bf71d201a0f8)  ·  Kontext: gerbil-detail  ·  Ticket `81a3126b`
+- **Meldung:** Zacs Mutter ist bekannt, aber fehlt hier. Seine Mutter ist "Dorie of Black Forest"
+- **Ursache:** Zacs Wurf (0640c277-...) hat fatherId=Vance (männl.), motherId=null. Die Chart-Positions-Erkennung las zwei MÄNNLICHE Eltern aus (Vance + "Zadar from Zeko i ptica", beide gender=male) und verwarf Zadar mit Grund "ein Wurf hat nur einen Vater und eine Mutter", statt das Geschlecht zur Disambiguierung zu nutzen. Die korrekte Mutter Dorie of Black Forest (3e850d05-..., female) existiert in der DB und stammt sogar aus der Quelldatei "Stammbaum von Zac (Vance.Dorie).xlsx", wurde aber nie als Mutter zugeordnet. Mutter blieb leer.
+- **Empfehlung:** Im Eltern-Resolver (merge_and_resolve.py / extract chart-position): bei zwei erkannten Eltern nicht blind einen verwerfen, sondern per Geschlecht zuordnen (männl.=Vater, weibl.=Mutter); bei zwei gleichgeschlechtlichen Kandidaten den anderen Slot frei halten und den korrekten gegengeschlechtlichen Kandidaten suchen. Konkret Dorie of Black Forest (female) als Mutter setzen und Zadar verwerfen statt Dorie. Schnellfix über Import-Auflösung/conflict-decisions.json: motherId=3e850d05-186e-5645-a331-67afb4a29549. Der Dateiname "Vance.Dorie" ist ein verwertbares Signal fuer das Elternpaar.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (Eltern-Resolver + Gender-Plausibilitaet); tools/import/extract.py (chart-position parent detection); Litter 0640c277-9fe8-508e-a92d-371bb4589d1d (motherId=null); Quelldatei 'Stammbaum von Zac (Vance.Dorie).xlsx'; Dorie of Black Forest 3e850d05-186e-5645-a331-67afb4a29549
+
+### Cluster `wrong-parents` (8)
+
+#### #12 — Tonys Vater fehlt/falsch – sollte Sammy von den Kleinen Chaoten sein
+- **Tier/Wurf:** Tony v.d. Kleinen Chaoten (e8293778-bd46-5fcb-8b92-6b745a53e325), Wurf 1e2dc103-5f91-520f-b7d3-4a594bf02665  ·  Kontext: stammbaum  ·  Ticket `e09bf10e`
+- **Meldung:** Vater ist bekannt und heißt "Sammy von den Kleinen Chaoten"
+- **Ursache:** Tonys virtueller Wurf (1e2dc103) wurde nur aus dem Stammbaum-Diagramm (Stammbaum von Vance.xlsx, parentMethod=chart-position) rekonstruiert: motherId korrekt = Qamikaze Queen ("Queenie", 9b4f7023), aber fatherId ist NULL und der Wurfname trägt fälschlich "Jack Jr. v.d. kleinen Chaoten" aus der Chart-Positions-Heuristik. Die Wurfchronik Teil 2 page 0006 (aus der Tonys eigener Datensatz gemergt wurde) nennt den L7-Wurf 16.09.2015 explizit "Parents Sammy + Queenie". Der Wurfchronik-Vater Sammy wurde nicht an den pedigree-rekonstruierten Wurf gekoppelt.
+- **Empfehlung:** fatherId des Wurfs 1e2dc103 auf "Sammy von den Kleinen Chaoten" (b8c57891-b1a3-53a2-8daa-6809c2b898b9, male, *2012-10-30, Alter plausibel) setzen und den falschen "Jack Jr."-Namensteil entfernen. Generell: chart-position-rekonstruierte Würfe gegen die Wurfchronik-Wurfeinträge (Eltern-Namen) abgleichen und den Wurfchronik-Vater verwenden, wenn DOB/Mutter übereinstimmen. Quelle: Wurfchronik Teil 2_page_0006.md, L7-Wurf 16.09.2015.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (Eltern-/Vater-Auflösung Z.2700-2790; Litter-Vater aus Wurfchronik vs. chart-position); Wurf 1e2dc103-5f91-520f-b7d3-4a594bf02665; Quelle Wurfchronik Teil 2_page_0006.md (L7-Wurf); Stammbaum von Vance.xlsx
+
+#### #15 — Odelia falsche Eltern
+- **Tier/Wurf:** Odelia von den Kleinen Chaoten  ·  Kontext: gerbil-detail  ·  Ticket `38c26381`
+- **Meldung:** Falsche Eltern!! Bitte überprüfen!
+- **Ursache:** Odelia doppelt belegt. Wurfchronik (Teil 1 Seite 49, O6-Wurf) nennt Cash als Vater und Elena als Mutter, geboren 21.06.2015. Merge wies stattdessen die chart-position Litter aus Stammbaum von Vance.xlsx zu, mit Chap of little Angels und Julietta gen Becky (beide geboren 2011). Provenance zeigt: Cash wurde faelschlich als Mutter-Kandidat geprueft und als falsches Geschlecht verworfen, dann Fallback auf die falschen Eltern.
+- **Empfehlung:** Wurfchronik-Eltern Cash und Elena per conflict-decisions.json setzen und in merge_and_resolve.py Wurfchronik-Litter Vorrang vor chart-position geben. Danach re-ingest.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py; tools/import/conflict-decisions.json; Gerbil 3609e642-73e4-579e-87f1-da0332b1d037
+
+#### #16 — Arya Stark: falsche Mutter (Enya statt Sansa), Vater fehlt — Geschwisterverpaarung Vance × Sansa nicht erkannt
+- **Tier/Wurf:** Arya Stark von den Kleinen Chaoten (b4f59085-5d0d-51b0-9c94-bddf622b5935), Wurf de516d3a-d1fb-546c-b83f-253b400ac993  ·  Kontext: stammbaum  ·  Ticket `32de49fe`
+- **Meldung:** Eltern bekannt, falsche Mutter. Arya Stark stammt aus einer Geschwisterverpaarung ab und ihre Eltern sind " Sansa Stark von den Kleinen Chaoten" ( Mutter) und " Vance von den Kleinen Chaoten" (Vater).
+- **Ursache:** Aryas Wurf hat motherId=Enya (2b22b29e, *2017-11-01, Großmutter) und fatherId=null. Korrekt: Mutter=Sansa Stark (39b4ec37), Vater=Vance (f31eb1f9). Vance (male) und Sansa (female) teilen denselben Wurf 3aa0d64c (gleiche Eltern Robb Stark + Enya) → echte Geschwisterverpaarung. Ursache: pick_parent_ref (merge_and_resolve.py:679) filtert Chart-Positions-Kandidaten per HARTEM Gender-Filter, BEVOR die Rollen-Zuordnung (assign_parent_roles) greift. Provenance zeigt: Vance im Mutter-Slot als "falsches Geschlecht" verworfen, Sansa als "nur einen Vater und eine Mutter" verworfen; als Fallback wurde die falsch-gegenderte aber passende Großmutter Enya als Mutter behalten, Vater blieb leer. Der Namens-Swap bei merge_and_resolve.py:2742 fängt das nicht, weil die Verwerfung schon früher in pick_parent_ref passiert.
+- **Empfehlung:** Import-Auflösung korrigieren: Aryas Wurf de516d3a auf fatherId=Vance (f31eb1f9) und motherId=Sansa Stark (39b4ec37) setzen; Sibling-Pairing-Erkennung greift dann (gleicher litterId der Eltern). Kurzfristig per conflict-decisions.json/Quelldaten-Auflösung. Eigentlicher Fix: pick_parent_ref soll Kandidaten nicht per hartem Gender-Filter verwerfen, sondern (wie _resolve_name) Gender nur als Präferenz nutzen und die endgültige Vater/Mutter-Rolle assign_parent_roles überlassen — sonst gehen reversierte/Geschwisterverpaarungs-Kandidaten verloren und ein falscher Fallback (Enya) bleibt stehen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py:679 (pick_parent_ref harter Gender-Filter); tools/import/merge_and_resolve.py:2700-2809 (Namens-Swap + assign_parent_roles); Wurf de516d3a-d1fb-546c-b83f-253b400ac993 (motherId=Enya, fatherId=null); Arya b4f59085 provenance/history
+
+#### #21 — Danielle: falsche Mutter (Roswitha) im Stammbaum, Vater fehlt
+- **Tier/Wurf:** Danielle von den Kleinen Chaoten (d45a36a8-9347-54e5-bfba-3648487ae527), Wurf acd30ec1-f71f-583b-b5ae-f85c40b782c6  ·  Kontext: stammbaum  ·  Ticket `4692fd5c`
+- **Meldung:** Falsche Mutter! Vater rund Mutter sind bekannt
+- **Ursache:** Chart-Position-Parsing in "Stammbaum von Picus Son.xlsx" hat Danielles Eltern falsch erkannt: die weibliche "Roswitha" landete im Vater-Slot, "Ella" im Mutter-Slot (Wurfname "Wurf von Roswitha + Ella"). Die Reversal-Vorabkorrektur (merge_and_resolve.py:2742) tauscht nur, wenn der Mutter-Name ein bekannter MAENNLICHER Gerbil ist; "Ella" wurde zu keinem altersplausiblen Gerbil aufgeloest, also kein Tausch. _resolve_name (Z.2700) mappte "Roswitha" auf die echte weibliche Roswitha; "Ella" fand kein Match -> MotherId blieb null. assign_parent_roles (Z.640/2792) wies dann den einzigen aufgeloesten weiblichen Elternteil der Mutterrolle zu -> motherId=Roswitha, fatherId=null. parentConfidence=medium.
+- **Empfehlung:** Echte Eltern bei der Nutzerin erfragen (sie kennt Vater + Mutter). Da conflict-decisions.json bisher kein Eltern-Feld hat, einen Parent-Override einfuehren (z.B. {name,dob,fatherName,motherName}) und im Eltern-Resolver (merge_and_resolve.py Z.2736-2809) VOR der Rollen-Normalisierung anwenden; danach extract -> merge_and_resolve -> POST /import/ingest-resolved neu fahren. Zusaetzlich Heuristik haerten: assign_parent_roles sollte einen einzelnen weiblichen Vater-Slot-Treffer ohne zweiten plausiblen Elternteil nicht automatisch zur Mutter machen.
+- **Fix-Ebene:** import-data · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** C:/Users/gulum/dev/GerbilManager/tools/import/merge_and_resolve.py (Z.640 assign_parent_roles, Z.2700 _resolve_name, Z.2736-2809 Eltern-Resolver/Rollen-Normalisierung, Z.1646-1665 virtuelle Wuerfe); C:/Users/gulum/dev/GerbilManager/tools/import/conflict-decisions.json (kein Parent-Override-Feld); Wurf acd30ec1-f71f-583b-b5ae-f85c40b782c6 (motherId=Roswitha, fatherId=null); Gerbil d45a36a8 Danielle
+- **Rückfrage:** Wer sind Danielles echte Eltern (Vater + Mutter mit Name)? Aktuell ist Roswitha als Mutter eingetragen (falsch) und kein Vater. Im Quell-Stammbaum standen "Roswitha" und "Ella" als Elternpositionen.
+
+#### #22 — Danielles Vater fehlt — sollte "Louis von den Kleinen Chaoten" sein
+- **Tier/Wurf:** Danielle von den Kleinen Chaoten (d45a36a8-9347-54e5-bfba-3648487ae527)  ·  Kontext: stammbaum  ·  Ticket `f77aa4a6`
+- **Meldung:** Papa ist bekannt, er heißt Louis von den Kleinen Chaoten
+- **Ursache:** Danielles Wurf (acd30ec1) hat fatherId=null und motherId=Roswitha. Die Eltern wurden per chart-position aus "Stammbaum von Picus Son.xlsx" geraten; der Vater-Slot ging dabei verloren. Der echte Vater "Louis" existiert nicht als importiertes Tier (kein Gerbil-Record); seine Existenz ist nur indirekt aus den Vertragsdateien zu Roswithas Würfen ablesbar (wiederkehrendes Paarungs-Kürzel "Louis.Roswitha" in den Vertragsnamen). Zudem ist die angezeigte Mutter fraglich (separate Meldung 4692fd5c): Wurfname "Wurf von Roswitha + Ella" verrät eine falsch gelesene Stammbaum-Position.
+- **Empfehlung:** Import-Auflösung/Quelldaten korrigieren: "Louis von den Kleinen Chaoten" als Tier anlegen und als fatherId von Danielles Wurf (acd30ec1) setzen, Mutter prüfen. Da Louis nur im Vertrags-Kürzel "Louis.Roswitha" vorkommt, sollte merge_and_resolve.py Paarungs-Kürzel aus Vertragsdateinamen als Eltern-Hinweis auswerten, oder den Link per conflict-decisions.json/Quell-xlsx manuell pflegen. chart-position-Eltern mit parentConfidence=medium aus Picus-Son.xlsx sind hier unzuverlässig.
+- **Fix-Ebene:** import-data · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (pick_parent_ref / chart-position-Eltern); tools/import/extract.py (Eltern-Position im Stammbaum); Litter acd30ec1-f71f-583b-b5ae-f85c40b782c6 (fatherId=null); Gerbil d45a36a8 (Danielle); Vertragsdateien '...(Louis.Roswitha)...docx'
+- **Rückfrage:** Bestätigen: Sind Danielles Eltern Louis (Vater) und Roswitha (Mutter), oder ist auch die Mutter eine andere (vgl. parallele Meldung 'Falsche Mutter')? Existiert ein eigenes Stammbaum-Quellblatt für Louis?
+
+#### #23 — Yuki: falscher Vater (Benjiro) und fehlende Mutter — korrekt sind Camaro & Izumi
+- **Tier/Wurf:** Yuki von den Kleinen Chaoten (55fba1b1-f59e-5117-92bf-85e950c953f9)  ·  Kontext: stammbaum  ·  Ticket `4493fd8a`
+- **Meldung:** Falscher Papa, beide Eltern (Camaro & Izumi) sind bekannt
+- **Ursache:** Yukis Wurf (3480f62f-...) wurde per chart-position aus "Stammbaum von CP-Fuchs" rekonstruiert und falsch verdrahtet: Wurfname "Benjiro + Louis", fatherId=Benjiro (*2015), motherId=null. Provenance zeigt die Fehlsuche: Mutter-Kandidat "Makoto" wegen falschem Geschlecht verworfen, dann "Louis" als 2. Elternteil verworfen, sodass nur Benjiro uebrig blieb. Die laut Nutzerin korrekten Eltern existieren beide in der DB und sind altersplausibel: Camaro = "Chevrolet Camaro of Topolino" (*2018-04-10, Vater) und "Izumi von den Kleinen Chaoten" (2cb68a8f-..., female, *2018-02-07, Mutter). Die Chart-Heuristik hat fuer Yuki die falschen Eltern-Boxen gegriffen.
+- **Empfehlung:** Eltern-Link fuer Yukis Wurf korrigieren: fatherId auf Chevrolet Camaro of Topolino (10.04.2018), motherId auf Izumi von den Kleinen Chaoten (2cb68a8f-205e-5f08-8bf0-2e2d9048fe0c). Als Import-Override fixieren (conflict-decisions.json / Quell-Chart pruefen, warum Benjiro+Louis statt Camaro+Izumi gelesen wurden), dann merge_and_resolve.py neu laufen lassen und re-ingesten. Zusaetzlich pruefen, ob die chart-position-Heuristik bei diesem Chart systematisch danebengreift (parentConfidence=medium).
+- **Fix-Ebene:** import-data · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/extract.py (chart-position Eltern-Erkennung); tools/import/merge_and_resolve.py (Eltern-Resolver/Override); Litter 3480f62f-e7e9-52e5-8655-2b04293e7924 (fatherId/motherId); Gerbil 55fba1b1-f59e-5117-92bf-85e950c953f9 (provenance)
+
+#### #26 — Gaida: falsche Eltern (zwei Weibchen erkannt) – Vater Zenon fehlt, Geschwisterverpaarung verloren
+- **Tier/Wurf:** Gaida von den Kleinen Chaoten (Wurf dd830a45 „Nisha + Zaibunissa")  ·  Kontext: stammbaum  ·  Ticket `ba63325a`
+- **Meldung:** Eltern sind bekannt, es sind die falschen. Die Eltern stammen aus einem Wurf von Nisha und Zenon. Gaida stammt aus einer Geschwisterverpaarung ab
+- **Ursache:** Die Chart-Position-Extraktion in „Stammbaum von Goldfuchs Sp (Pikachu) Kids.xlsx" lieferte für Gaida zwei FALSCHE Eltern-Boxen, beide weiblich: Nisha of Black Forest (roleGuess=father!) und Zaibunissa (roleGuess=mother). Der echte Vater Zenon von Elea (male) ist zwar in derselben Datei, wurde aber NICHT als Gaidas Eltern-Box erkannt. Der Resolver verwarf folgerichtig die zweite weibliche „Mutter" Zaibunissa (nur 1 Vater/1 Mutter), behielt Nisha als Mutter und ließ fatherId=null. Da Zenon nie als parentRef vorliegt, kann keine Resolver-Logik ihn ergänzen → Geschwisterverpaarung (Nisha+Zenon) geht verloren. Reines Quelldaten-/Extraktionsproblem für dieses Chart.
+- **Empfehlung:** Eltern des Wurfs dd830a45 korrigieren auf Mutter=Nisha of Black Forest (06dc519d) und Vater=Zenon von Elea (cd2ee35e); Zaibunissa als Eltern-Link entfernen. Umsetzen über Import-Auflösung/conflict-decisions (parentRefs für externalRef stammbaum-gaidakleinenchaoten-02082022 überschreiben) bzw. Quelldaten-Override, dann merge_and_resolve + re-ingest. Wenn Nisha & Zenon dieselbe litterId/DOB teilen, greift danach die Geschwisterverpaarungs-Erkennung automatisch.
+- **Fix-Ebene:** import-data · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/output/animals.json (externalRef stammbaum-gaidakleinenchaoten-02082022 parentRefs); Stammbaum von Goldfuchs Sp (Pikachu) Kids.xlsx; tools/import/merge_and_resolve.py (pick_parent_ref/assign_parent_roles); Litter dd830a45-7c66-55ed-a3d8-044654879363; conflict-decisions.json
+- **Rückfrage:** Bestätigen: korrekter Vater = Zenon von Elea (cd2ee35e, male, geb. 2019-10-06)? Und sind Nisha und Zenon Vollgeschwister (gemeinsamer Wurf), damit die Geschwisterverpaarung korrekt markiert wird?
+
+#### #36 — Falsches Muttertier bei "Gold v.d. Kleinen Chaoten" (Gaida statt Chelsea)
+- **Tier/Wurf:** Gold v.d. Kleinen Chaoten (e489b704), Wurf b9f39548  ·  Kontext: gerbil-detail  ·  Ticket `2cd5c28f`
+- **Meldung:** Muttertier stimmt nicht! Es sollte Chelsea von den Kleinen Chaoten sein!
+- **Ursache:** Golds Wurf (b9f39548) hat Vater=Trogir, Mutter=Gaida von den Kleinen Chaoten. Die Mutter wurde per chart-position-Heuristik aus "Stammbaum von Goldfuchs Sp (Pikachu) Kids.xlsx" zugeordnet (parentConfidence=medium) und dabei falsch gewählt. Korrekt ist Chelsea (id 2b757106): Der Abgabevertrag "Platin (Trogir.Chelsea)-Sarah Gaul.docx" (Namensschema Vater.Mutter) belegt die Verpaarung Trogir x Chelsea; sowohl Trogirs als auch Chelseas Provenance referenzieren diesen Vertrag. Die Nutzeraussage ist damit gut gestützt.
+- **Empfehlung:** Manuelle Eltern-Korrektur in tools/import/conflict-decisions.json eintragen (Mechanik existiert bereits, vgl. Kazuya/Naho-Einträge mit Feldern father/mother, Match per name+dob): für "Gold v.d. Kleinen Chaoten", dob 03.08.2023 mother="Chelsea von den Kleinen Chaoten" (father=Trogir bleibt). Anschließend merge_and_resolve.py neu laufen lassen und POST /import/ingest-resolved. Voraussetzung: der Resolver muss eltern-Overrides aus conflict-decisions auch bei chart-position-Würfen anwenden — prüfen, dass der mother-Override greift (ggf. wie bei Kazuya/Naho-Pfad).
+- **Fix-Ebene:** import-data · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** tools/import/conflict-decisions.json; tools/import/merge_and_resolve.py (Eltern-Resolver / Override-Anwendung); Wurf b9f39548 motherId 04358c1f (Gaida) -> 2b757106 (Chelsea); Quelldatei: Stammbaum von Goldfuchs Sp (Pikachu) Kids.xlsx
+
+### Cluster `dedup-duplicate` (2)
+
+#### #18 — Hagrid Rubeus: Eltern fehlen, weil das Tier als Dublette doppelt existiert (Eltern hängen am DOB-Duplikat)
+- **Tier/Wurf:** Hagrid Rubeus of Black Forest (73759a6a-9ad2-5ce5-becb-8d9fc8b5af43)  ·  Kontext: stammbaum  ·  Ticket `d7189414`
+- **Meldung:** Elterntiere sind bekannt und sind Snickers of Black Forest (Vater) & Milka of Lennylengo (Mutter).
+- **Ursache:** Es gibt zwei resolved Hagrid-Tiere: das im Ticket geöffnete 73759a6a (ExternalRef stammbaum-hagridrubeusblackforest, kein DOB, litterId=null) ist eine leere Dublette aus den DOB-losen Stammbaum-Erwähnungen; das echte 7ee7ca29 (stammbaum-...-18072019, DOB 2019-07-18) hat litterId=800ef8dc mit Vater=Snickers of Black Forest, Mutter=Milka of LennyLengo. Die Dedup-Partition in merge_and_resolve.py (are_compatible/Sub-Group-Bildung um Zeile 2260-2414) führt die DOB-losen Datensätze NICHT mit dem DOB-/parentRefs-tragenden Datensatz zusammen, daher bleibt das angezeigte Tier ohne Wurf/Eltern.
+- **Empfehlung:** In der Dedup-Partition (merge_and_resolve.py, are_compatible bzw. Sub-Group-Schritt ~Z.2404-2414) namens-/clan-gleiche Datensätze ohne DOB und ohne parentRefs in den DOB-/eltern-tragenden Datensatz mergen, statt eine eigene Sub-Group zu bilden. Dann erbt 73759a6a litterId 800ef8dc (Snickers+Milka) und die Dublette 7ee7ca29 verschwindet. Danach merge_and_resolve.py neu laufen lassen + POST /import/ingest-resolved.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (are_compatible ~Z.2260; Sub-Group-Partition ~Z.2404-2414); Gerbil 73759a6a-9ad2-5ce5-becb-8d9fc8b5af43 (leere Dublette); Gerbil 7ee7ca29-b998-5193-95b0-14ce21e025ca (echtes Tier mit Eltern); Litter 800ef8dc-dd99-56c2-ac58-15acc6fe81c0 (Snickers+Milka)
+
+#### #25 — Namenlose Stammbaum-Maus doppelt: gleiches Tier aus zwei Diagrammen wird nie zusammengeführt
+- **Tier/Wurf:** Namenloses Männchen, DOB 2024-02-15, Vater Inochi gen. Picu (IDs 5b5af108… und 13944d01…)  ·  Kontext: gerbil-detail  ·  Ticket `f618dcc3`
+- **Meldung:** Diese Maus existiert nur einmal, ist aber zweimal aufgeführt
+- **Ursache:** Zwei namenlose Männchen mit gleichem DOB, Genotyp und Vater (Inochi gen. Picu) sind dasselbe Tier aus zwei Stammbaum-Dateien. dedup() in extract.py behandelt namenlose Tiere (leerer norm_name) als Orphans mit Unique-Key und führt sie nie zusammen; der Parent-Merge verlangt zwei bekannte Eltern, beide Mütter sind aber namenlos.
+- **Empfehlung:** dedup() so erweitern, dass namenlose Tiere mit gleichem DOB zusammengeführt werden, wenn ein bekannter Elternteil (Vater) und kompatibler Genotyp übereinstimmen; groups_parents_match auf „ein bekannter Elternteil genügt" lockern. Danach Import neu generieren und POST /import/ingest-resolved.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/extract.py:616-700 (dedup, Orphan-Key Z.624-628; groups_parents_match Z.663-670); tools/import/merge_and_resolve.py (Re-Resolve nach Merge); Gerbils 5b5af108-1205-5e57-b418-17e106f3e0da und 13944d01-7e09-5815-a827-2bd6a94d62a5; Litters 48bb7715… / 6430018f… (beide virtuell, Vater Inochi gen. Picu)
+- **Rückfrage:** Bestätigen, dass beide Einträge wirklich dasselbe Tier sind (namenlos, Mutter in beiden Diagrammen unbekannt). Falls ja: sollen die zwei rekonstruierten Würfe (Picus Son vs Alberto Kids) ebenfalls zu einem Wurf zusammengeführt werden?
+
+### Cluster `gender-unknown` (2)
+
+#### #1 — Stammbaum: Weibchen-Icon fehlt, stattdessen Fragezeichen (gender=unknown)
+- **Tier/Wurf:** Cherry Berry's Quqquluuruu (e9c6d0bd-bcd0-58aa-a01f-3ff32f731f33)  ·  Kontext: stammbaum  ·  Ticket `94892100`
+- **Meldung:** Icon für Weibchen fehlt, da ist ein Fragezeichen
+- **Ursache:** Das Tier hat gender="unknown" (Provenance: aus 4 Datensätzen der Fire-Kids-Stammbäume zusammengeführt, alle als reine Namens-Vorfahren). Solche tiefen Vorfahren werden in extract.py aus „X & Y"-Namenszellen (Zeile 294-296: gender=None) bzw. aus Eltern-Refs erzeugt — diese Zellen tragen KEINE Box-Füllfarbe, die cell_fill_sex (xlsx_util.py) bräuchte, um das Geschlecht abzuleiten. merge_and_resolve.py setzt gender=None, wenn kein Quelldatensatz ein Geschlecht beisteuert. Im Frontend rendert SexIcon (StammbaumPage.tsx:680-681) bei gender!=male/female ein „?".
+- **Empfehlung:** Primär import-data: Geschlecht ist aus den Quelldateien für dieses Tier nicht ableitbar (nur Namenszelle ohne Füllfarbe) — falls der Züchterin bekannt (weiblich), per Auflösung/Quelldaten ergänzen. Sekundär Frontend-Politur: SexIcon bei unknown ein neutrales Symbol statt „?" zeigen bzw. mit Tooltip „Geschlecht unbekannt", damit es nicht wie ein Bug wirkt. Hinweis: cell_fill_sex kennt nur male/female (gefüllt/leer) — es gibt keinen sauberen „unknown"-Pfad; unknown entsteht nur, wenn gar keine Füll-Info vorliegt.
+- **Fix-Ebene:** import-data · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** tools/import/extract.py:294-296 (Namenszelle gender=None); tools/import/merge_and_resolve.py:760 (gender=None bei fehlenden Quellen); tools/import/xlsx_util.py:81-118 (cell_fill_sex, nur male/female); gerbil-manager-web/src/pages/StammbaumPage.tsx:680-686 (SexIcon zeigt ?)
+- **Rückfrage:** Ist das Geschlecht von „Cherry Berry's Quqquluuruu" bekannt (vermutlich weiblich)? Falls ja, sollte es in den Quelldaten/Import-Auflösung gesetzt werden — aus den Stammbaum-Zellen ist es nicht ableitbar.
+
+#### #2 — Stich von Privatzucht Giessen: Mutter fehlt wegen falschem Geschlecht von Mozart of Lennylengo
+- **Tier/Wurf:** Stich von Privatzucht Giessen badbf810, Wurf cb046259, Mutter Mozart of Lennylengo c8c58add  ·  Kontext: stammbaum  ·  Ticket `f92a9650`
+- **Meldung:** Mutter ist bekannt, bitte überprüfen
+- **Ursache:** Wurf cb046259 hat Vater Carlos (male) und Mutter-Kandidat Mozart of Lennylengo (c8c58add), der in der DB aber gender=male ist (Boxfarbe in Stammbaum von Fire Kids.xlsx als maennlich gelesen). assign_parent_roles sieht zwei Maennchen, behaelt Carlos als Vater und verwirft Mozart (ein Wurf hat nur einen Vater und eine Mutter), motherId bleibt null. Der Wurf-Name nennt Mozart weiterhin als Mutter, weil das Label vor dem Drop gesetzt wurde.
+- **Empfehlung:** Geschlecht von Mozart of Lennylengo (c8c58add-5689-59b3-a855-2087b45d6210) auf female korrigieren via conflict-decisions.json/Import-Aufloesung, dann re-ingest. Der Eltern-Resolver ordnet Mozart dann als Mutter des Wurfs cb046259 zu und Stich erhaelt seine bekannte Mutter. Gehoert zum Cluster Gender-aus-Boxfarbe.
+- **Fix-Ebene:** import-data · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** tools/import/extract.py; tools/import/merge_and_resolve.py assign_parent_roles; conflict-decisions.json; Gerbil c8c58add-5689-59b3-a855-2087b45d6210 Mozart of Lennylengo; Litter cb046259-4ebd-5341-a11a-d7374ceac3da
+
+### Cluster `genetics-farbschlag` (2)
+
+#### #3 — Berechneter Farbschlag falsch: aa-Colourpoint mit dd/Fuchs wird fälschlich als "Zobel Schecke" ausgegeben
+- **Tier/Wurf:** (ohne Namen), gerbilId 6864eaef-..., Genotyp aa c[chm]c[chm] dd ee[-] gg Pp Spsp  ·  Kontext: gerbil-detail  ·  Ticket `efa2b232`
+- **Meldung:** Berechnete Farbe ist falsch, wie kommt er auf Zobel Schecke?
+- **Ursache:** colourpointName() in gerbil-manager-web/src/genetics/catalog.ts wertet im aa-Colourpoint-Zweig nur A/C/G aus und ignoriert D und E komplett: aa + cchm/cchm + gg ergibt hart "Zobel" (mit Sp dann "Zobel Schecke"). Bei diesem Tier ist aber dd (dilute) und ee[-] (Fuchs). Zusätzlich setzt locusToken() das unbekannte E-Allel per Fallback auf das dominanteste 'E', wodurch der Fuchs-Charakter (e) maskiert wird (Zobel verlangt D + E). eFamily() würde ee[-] dagegen als 'Fuchs' werten - die beiden Stellen sind inkonsistent. Ergebnis: dd/Fuchs-Colourpoint kollabiert auf das volle Zobel.
+- **Empfehlung:** colourpointName() reparieren, sodass der aa-Colourpoint-Zweig D und E berücksichtigt (statt fixem Marder/Siam/Zobel): Basis-Farbschlag analog zum A--Zweig über baseColourFor(C:=['C','C']) bestimmen und CP-/Dilute-Präfixe konsistent ableiten (hier dd + Fuchs Richtung CP-Polarfuchs/Dilute, vgl. Schwester-Ticket 3deab547 "Dilute-CP-Polarfuchs"). Zusätzlich locusToken()-Fallback für unbekanntes E mit eFamily() konsistent machen (ee[-] als Fuchs behandeln, nicht auf 'E' hochstufen).
+- **Fix-Ebene:** genetics-engine · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/catalog.ts (colourpointName aa-Zweig, locusToken E-Fallback); gerbil-manager-web/src/genetics/phenotype.ts; gerbil-manager-web/src/pages/GerbilDetailPage.tsx (Anzeige); Backend-Spiegelung der genotypeToFarbschlag-Denormalisierung pruefen
+- **Rückfrage:** Soll-Farbschlag fuer aa c[chm]c[chm] dd ee[-] gg bestaetigen: laut Schwester-Ticket 3deab547 zu demselben Tier "Dilute-CP-Polarfuchs". Stimmt das als erwartete Ausgabe?
+
+#### #24 — Falscher Farbschlag "Blau" statt CP-/Dilute-Blaufuchs — greedy Substring-Match im Import
+- **Tier/Wurf:** Tier 6864eaef (ohne Namen, w, *13.11.2023, Quelle "Stammbaum von Picus Son.xlsx")  ·  Kontext: gerbil-detail  ·  Ticket `3deab547`
+- **Meldung:** Diese Rennmaus trägt die Farbe Dilute- CP-Polarfuchs und nicht blau!
+- **Ursache:** Quelldatei nennt Farbschlag "Dilute CP-Blaufuchs" (Genotyp aa c[chm]c[chm] dd ee[-] gg Pp Spsp). resolve_color_and_genotype in merge_and_resolve.py findet keinen Exakt-Treffer und fällt auf greedy Substring-Matching zurück (Z.431-434): der kurze Seed "Blau" (sortOrder 10) ist Teilstring von "...blaufuchs" und wird VOR "CP-Blaufuchs"/"Dilute CP-Blaufuchs" getroffen, daher ColorVarietyId=0011 (Blau). Genotyp wurde korrekt übernommen, nur der gespeicherte Farbschlag ist falsch. Zusatzbefund: Genotyp ist aa (nicht A-), daher liefert die Engine für aa cchm/cchm gg+Sp "Zobel Schecke"; CP-/Blaufuchs-Namen setzen A- voraus — Quell-Label und Genotyp sind intern inkonsistent (Nutzerangabe "CP-Polarfuchs" weicht zudem von Quell-Label "CP-Blaufuchs" ab).
+- **Empfehlung:** resolve_color_and_genotype-Matcher fixen: Exakt-Treffer erzwingen und den Substring-Fallback durch Längsten-Treffer (längster passender Seed-Name) ersetzen statt erstem Treffer; ggf. "Dilute CP-Blaufuchs"/"CP-Blaufuchs" als clean_color_name-Alias ergänzen. Danach Import neu generieren + POST /import/ingest-resolved. Da Genotyp aa keine CP-/Blaufuchs-Farbe ergibt (Engine: Zobel Schecke) und die Nutzerin "Polarfuchs" statt "Blaufuchs" nennt, vor finalem Fix beim korrekten Farbschlag/Genotyp rückfragen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (resolve_color_and_genotype Z.421-452; Substring-Fallback Z.431-434; clean_color_name Z.~395-419); gerbil-manager-web/src/genetics/catalog.ts (colourpointName/farbschlagFor); Tier 6864eaef-cc3e-5f08-a510-b037cc963b66 (ColorVarietyId 0011=Blau)
+- **Rückfrage:** Welcher Farbschlag/Genotyp ist korrekt? Nutzerin sagt "Dilute CP-Polarfuchs", Quelldatei "Dilute CP-Blaufuchs", gespeicherter Genotyp aa cchm dd ee gg (das wäre engine-seitig "Zobel Schecke", nicht CP-* da CP A- voraussetzt).
+
+### Cluster `genetics-notation-uw` (2)
+
+#### #32 — Vance: Genotyp mit "Uwuw[d]" wird im Frontend nicht geparst → "Unbekannter Farbschlag" statt Kohlfuchs
+- **Tier/Wurf:** Vance von den Kleinen Chaoten (f31eb1f9-0113-5da8-ac14-9ebfb24a6af9)  ·  Kontext: gerbil-detail  ·  Ticket `473dc345`
+- **Meldung:** Da steht dass er einen unbekannten Farbschlag hat bei der Errechnung, aber er ist ein Kohlfuchs,hell
+- **Ursache:** Genotyp ist "aa Cc[chm] D- ee Uwuw[d] PP spsp". Das Frontend-normalizeToken (genotype.ts) ersetzt nur Uw->G und uw->g, lässt die Annotation "[d]" am Underwhite-Token stehen -> "Gg[d]". splitToken kann "[d]" nicht parsen und wirft; describeGenotype (GerbilDetailPage.tsx:41-42) fängt das ab und zeigt de.genetics.unknownFarbschlag. Die Python-Importseite (genotype.py:52-55) behandelt dagegen explizit uw[d]->g, also fehlende Parität. Nach Strippen von [d] ergibt der Genotyp aa C D(?->wild D) e G P -> exakt die Kohlfuchs/Kohlfuchs,hell-Token; die Nutzerin hat recht.
+- **Empfehlung:** In gerbil-manager-web/src/genetics/genotype.ts in normalizeToken die Annotation am Underwhite-Token entfernen, analog zu genotype.py: vor den Uw/uw-Ersetzungen z.B. t = t.replace(/uw\[d\]/g, 'g') bzw. die G/Uw-Klammerannotation generell strippen (/[Uu]w\[[a-z]+\]/ -> g/G). Damit parst "Uwuw[d]" zu "Gg" und der Farbschlag wird korrekt als Kohlfuchs (bzw. Kohlfuchs, hell) aufgelöst. Test in genetics.test.ts ergänzen. Daten selbst sind korrekt, kein Re-Import nötig (nur Anzeige/Engine).
+- **Fix-Ebene:** genetics-engine · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/genotype.ts (normalizeToken); gerbil-manager-web/src/pages/GerbilDetailPage.tsx (describeGenotype catch->unknownFarbschlag); tools/import/genotype.py:52-55 (Referenz: uw[d]->g, Parität); gerbil-manager-web/src/genetics/__tests__/genetics.test.ts (Test ergänzen)
+
+#### #34 — Genotyp zeigt internationales "uw" statt G-Locus (Vance)
+- **Tier/Wurf:** Vance von den Kleinen Chaoten (f31eb1f9-0113-5da8-ac14-9ebfb24a6af9)  ·  Kontext: gerbil-detail  ·  Ticket `5151ab20`
+- **Meldung:** Hier steht der internationale Gencode uw, es soll aber G - Locus stehen
+- **Ursache:** Gespeicherter Genotyp = "aa Cc[chm] D- ee Uwuw[d] PP spsp". Frontend zeigt ihn via displayGenotypeSafe->fromDisplayString. normalizeToken (genotype.ts) wandelt zwar Uw/uw->G/g, strippt aber den Klammer-Modifier [d] nicht (nur c[chm], c[h], e[f], [-] werden behandelt). "Uwuw[d]" wird zu "Gg[d]", splitToken scheitert am "[d]" und wirft -> displayGenotypeSafe faellt in den Fallback-Zweig, der das ROH-Token unveraendert ausgibt -> Nutzerin sieht weiterhin "Uwuw[d]" (uw). Die Uw->G-Konvertierung ist also gewollt (Test GEN-3a), greift aber bei der [d]-getaggten Echtdaten-Variante nicht. tools/import/genotype.py (_rewrite_uw) behandelt uw[d] bereits, das Frontend nicht.
+- **Empfehlung:** In gerbil-manager-web/src/genetics/genotype.ts normalizeToken den [d]-Modifier am Underwhite-Allel entfernen (z.B. t = t.replace(/uw\[d\]/g, 'uw') vor der Uw/uw-Ersetzung), sodass "Uwuw[d]" -> "Gg" wird (analog _rewrite_uw in genotype.py). Test mit Uwuw[d]/uw[d]uw[d] in genetics.test.ts (Block GEN-3a) ergaenzen. Reine Anzeige-Logik, kein Re-Ingest noetig.
+- **Fix-Ebene:** genetics-engine · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/genotype.ts (normalizeToken); gerbil-manager-web/src/genetics/__tests__/genetics.test.ts (GEN-3a); gerbil-manager-web/src/pages/GerbilDetailPage.tsx (displayGenotypeSafe-Anzeigepfad)
+
+### Cluster `litter-expected-colors` (2)
+
+#### #40 — Erwartete Farbschläge/Gencodes im Wurf falsch: Probeverpaarung erzeugt unmögliche Allele aus Eltern-Unbekannten
+- **Tier/Wurf:** Wurf 98bfdf92 (Mamta Mini x Gold v.d. Kleinen Chaoten)  ·  Kontext: litter-detail  ·  Ticket `1e7b66e6`
+- **Meldung:** Erwarte Farbschläge bzw deren Gencodes sind falsch
+- **Ursache:** Eltern tragen Unbekannte: Mamta Mini "AA CC D- Ee[-] Gg PP spsp", Gold "Aa CC D- Ee Gg pp spsp". Die Punnett-Engine (punnett.ts parentAlleleWeights) expandiert ein unbekanntes Allel "?" UNIFORM über den ganzen Locus-Allelsatz. So entstehen Gameten mit Allelen, die die Eltern nicht belegt tragen: D? -> d-Gameten -> dd (Dilute); E? (aus Ee[-]) -> ef/e -> efe/efef (Schimmel); Mischkombinationen -> "Unbekannter Farbschlag". Inkonsistent zur Phänotyp-Anzeige (catalog/phenotype.ts), die "?" als Wildtyp/dominanteste Lesart auflöst.
+- **Empfehlung:** parentAlleleWeights so ändern, dass "?" konsistent mit der Phänotyp-Logik behandelt wird: nicht uniform über alle Allele streuen, sondern als Wildtyp-Lesart führen bzw. unbekannte Loci als "unbestimmt" markieren statt rezessive Allele zu erfinden. Dann keine d-/ef-/e-Gameten aus D?/E?, womit Dilute, efef und "Unbekannter Farbschlag" aus dieser Verpaarung wegfallen. Löst Sibling-Tickets 3e643ef1 und 3c46d0b4 (gleicher Wurf) mit.
+- **Fix-Ebene:** genetics-engine · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/punnett.ts (parentAlleleWeights - uniforme Wildcard-Expansion); gerbil-manager-web/src/genetics/breed.ts; gerbil-manager-web/src/genetics/phenotype.ts + catalog.ts (Wildtyp-Lesart von '?' als Referenz); Eltern-Genotypen ggf. import-data: da911047 'Ee[-]'/'D-', e489b704 'D-'
+
+#### #41 — Wurf Mamta Mini × Gold: Schimmel/efef-Farbschläge fälschlich als erwartet angezeigt
+- **Tier/Wurf:** Wurf 98bfdf92 (Vater Mamta Mini da911047 × Mutter Gold e489b704)  ·  Kontext: litter-detail  ·  Ticket `3c46d0b4`
+- **Meldung:** Bei dieser Verpaarung können keine e[f]e[f] Rennmaus Farbschläge fallen!
+- **Ursache:** Vater-Genotyp ist "Ee[-]" → E-Locus parst zu [E, ?] (genotype.ts normalizeToken Zeile 194 macht e[-] zum Wildcard). parentAlleleWeights (punnett.ts:37-40) expandiert den Wildcard UNIFORM über alle E-Allele {E, ef, e}, schleust also das ef-(Schimmel)-Allel ein, das der Genotyp gar nicht belegt. Dadurch erscheinen Orange-/Silberschimmel (Eef/eef) und „Unbekannter Farbschlag" in den erwarteten Farben — von der Nutzerin als efef gelesen. ECHTES efef fällt aber NICHT: Simulation mit den realen Eltern-Genotypen ergibt 0 efef-Outcomes, weil die Mutter "Ee" (kein ef) niemals ef beisteuern kann. Engine ist bei efef also korrekt; das Problem sind die durch die Wildcard-Expansion erzeugten Schimmel-/Dilute-/Unbekannt-Phantomfarben.
+- **Empfehlung:** Wildcard-Expansion am E-Locus eingrenzen: das von der Züchterin gemeinte "[-]" (drittes/unbekanntes E-Allel) sollte nicht automatisch ef einschließen, da ef sichtbar (Schimmel) und nicht versteckt vererbbar ist. Entweder (a) Wildcard nur über phänotypisch kompatible/rezessive Allele expandieren (hier {E, e}, nicht ef), oder (b) den Import-Genotyp "Ee[-]" korrigieren (E-Locus hat nur 2 Allele pro Tier; "Ee[-]" als 3. Symbol ist eine Quelldaten-Notations-Eigenheit → über Import-Auflösung auf "Ee" o.ä. setzen). Zusätzlich erwartete-Farben-Liste filtern/aggregieren, sodass winzige (<1%) Wildcard-Artefakte und „Unbekannter Farbschlag" nicht prominent als „erwartet" gezeigt werden.
+- **Fix-Ebene:** genetics-engine · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/punnett.ts (parentAlleleWeights Wildcard-Expansion); gerbil-manager-web/src/genetics/genotype.ts (normalizeToken e[-]→Wildcard, Z.194); gerbil-manager-web/src/pages/WurfDetailPage.tsx (expected via breed()); Genotyp Vater Mamta Mini da911047 = 'AA CC D- Ee[-] Gg PP spsp'; tools/import/genotype.py (Quelldaten-Genotyp-Notation)
+- **Rückfrage:** Was bedeutet das "[-]" in "Ee[-]" beim Vater Mamta Mini genau – ein unbekanntes drittes Allel, oder soll der E-Locus schlicht "Ee" sein? Davon hängt ab, ob die Korrektur in der Engine (Wildcard-Regel) oder in den Quelldaten/Import erfolgt.
+
+### Cluster `non-resident-display` (2)
+
+#### #17 — Externer Ahne Hagrid (Black Forest) faelschlich als Bestandstier mit Wuerfen angezeigt
+- **Tier/Wurf:** Hagrid Rubeus of Black Forest  ·  Kontext: gerbil-detail  ·  Ticket `dfaae8fb`
+- **Meldung:** Es sollte kein Wurf angezeigt werden, da das Tier nie in meiner Zucht war! Es sollen nur Würde angezeigt werden, wo Tiere in meiner Zucht eingesetzt wurden
+- **Ursache:** Hagrid ist ein externer Ahne (Kennel Black Forest), wird aber mit isResident=true gefuehrt. Die Residency-Propagation in merge_and_resolve.py Z.1526-1536 vererbt Bestands-Status von residenten Kindern auf deren Eltern per Name+DOB-Match und schliesst externe Zuchten nicht aus. Zudem zeigt GerbilDetailPage.tsx den Wuerfe-Abschnitt (parentLitters, Z.81-82 + 432-455) ungated an. 2 Stammbaum-Virtual-Litters mit Hagrid als Vater existieren.
+- **Empfehlung:** import-logic Fix in merge_and_resolve.py um Z.1532-1536: bei der Residency-Propagation Kandidaten ausschliessen, deren eigene zucht nicht is_clan_zucht ist, danach Re-Ingest. Zusaetzlich im Frontend GerbilDetailPage.tsx den Wuerfe-Abschnitt fuer nicht-residente Tiere ausblenden.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py Z.1526-1536; gerbil-manager-web/src/pages/GerbilDetailPage.tsx Z.81-82 und Z.432-455; DB Gerbil 73759a6a-9ad2-5ce5-becb-8d9fc8b5af43
+
+#### #20 — Externer Vorfahre (Hagrid) als Bestandstier markiert; Charakter-Bereich wird angezeigt
+- **Tier/Wurf:** Hagrid Rubeus of Black Forest (73759a6a-9ad2-5ce5-becb-8d9fc8b5af43)  ·  Kontext: gerbil-detail  ·  Ticket `b3908b69`
+- **Meldung:** Charakter und Eigenschaften sollten nicht angezeigt werden, da ich dieses Tier nie hatte. Es ist nie in meiner Zucht gewesen und ist lediglich ein Vorfahre von meinem Tier!
+- **Ursache:** Zwei Ursachen. (1) Daten/Logik: Hagrid ist trotz originBreeder "Black Forest" als isResident=true / status="Breeding" gespeichert. Die Residenz-Propagation in merge_and_resolve.py:1526-1536 markiert Eltern resident gewordener Tiere ebenfalls als resident und promotet so extern gezuechtete Vorfahren faelschlich zu Bestandstieren. (2) Frontend: Der Charakter-Bereich in GerbilDetailPage.tsx (section ab Zeile 360) wird unbedingt gerendert und ist NICHT auf g.isResident gegated, obwohl der Code-Kommentar (Zeile 71) selbst sagt, Charakter sei v.a. fuer Bestandstiere relevant.
+- **Empfehlung:** (1) Propagation in merge_and_resolve.py:1526-1536 einschraenken: extern gezuechtete Vorfahren (zucht/originBreeder != Klein-Chaoten, z.B. "Black Forest") nicht zu isResident promoten - nur fehlende/clan-eigene Zucht propagieren. Danach Re-Ingest -> Hagrid wird isResident=false / status="GivenAway" + Extern-Badge. (2) Charakter-Section in GerbilDetailPage.tsx auf g.isResident !== false gaten (analog zum bestehenden Extern-Badge bei Zeile 195). Beide noetig: ohne (1) bleibt Hagrid resident; ohne (2) wuerde der Bereich auch bei korrektem isResident=false weiter angezeigt.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py:1521-1536 (Residenz-Propagation); tools/import/merge_and_resolve.py:2142 (IsResident-Zuweisung); gerbil-manager-web/src/pages/GerbilDetailPage.tsx:360-430 (Charakter-Section ungegated)
+
+### Cluster `chart-position-wrong-parents` (1)
+
+#### #28 — Zadar (Import aus Kroatien) bekommt fälschlich Lilo als Mutter – Eltern sollten unbekannt sein
+- **Tier/Wurf:** Zadar from Zeko i ptica, Croatia (4b6e40cc-dce9-5212-93aa-b7c5c90fa676); virtueller Wurf aacf1656-a697-5739-aedd-21d6a20b8a6f  ·  Kontext: stammbaum  ·  Ticket `684f5b7d`
+- **Meldung:** Eltern sind unbekannt!
+- **Ursache:** Zadar ist ein extern zugekauftes Tier (Zuchtname "from Zeko i ptica, Croatia") mit echten, unbekannten Eltern. Der Eltern-Resolver hat ihn per chart-position-Heuristik (parentMethod=chart-position, confidence=medium) in einen virtuellen Wurf gehängt und Lilo of LennyLengo (405aee40, *04.11.2018) als Mutter gesetzt – obwohl der Wurfname "Lilo + Ken'ichi" lautet (Eltern einer anderen/Geschwister-Gruppe im selben Diagramm). Lilo ist nur ~5 Monate vor Zadars Geburt (12.04.2019); parent_age_plausible fängt das nicht, da es nur 0<ld-pd<=6 Jahre prüft (kein Mindest-Reifealter). Frontend zeigt dadurch eine widersprüchliche/teils leere Elternangabe.
+- **Empfehlung:** In conflict-decisions.json / Import-Auflösung den Eltern-Link für Zadar entfernen (Eltern = unbekannt, extern zugekauft). Generell merge_and_resolve.py: (a) chart-position-Eltern für extern benannte Tiere ("from/of <fremde Zucht>") nicht aus Positions-Nachbarschaft ableiten; (b) parent_age_plausible um ein Mindest-Reifealter (~70-84 Tage) erweitern, damit ~5-Monate-alte Tiere nicht als Eltern durchgehen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (pick_parent_ref, parent_age_plausible, MAX_PARENT_AGE_DAYS=6*366, chart-position/virtuelle Wurf-Logik); tools/import/conflict-decisions.json; gerbil 4b6e40cc-dce9-5212-93aa-b7c5c90fa676; litter aacf1656-a697-5739-aedd-21d6a20b8a6f
+
+### Cluster `genetics-elocus-e-dash` (1)
+
+#### #42 — E-Locus "e-" (ee[-]) statt ee: sichtbarer Fuchs wird falsch/unbekannt berechnet
+- **Tier/Wurf:** (ohne Namen) 33a7c1f9 — Genotyp Aa CC D- ee[-] Gg Pp spsp, soll Algierfuchs sein  ·  Kontext: gerbil-detail  ·  Ticket `b034ddd2`
+- **Meldung:** Gencode stimmt nicht! e- gibt es nicht, es gibt nur E- & ee[-]. Bei e- musst du eine Fehlermeldung herausgeben, dass der Gencode falsch ist. Bei dieser Rennmaus handelt es sich um einen Algierfuchs
+- **Ursache:** Der gespeicherte E-Locus-Token ist "ee[-]" (aus dem Quell-xlsx übernommen). normalizeToken in genotype.ts parst ihn als [e, ?] (ein Fuchs-Allel + ein Unbekannt). Fuchs (e) ist rezessiv, ein sichtbarer Fuchs MUSS also ee sein — "e-"/"e[-]" ist genetisch unmöglich. Bei der Farbberechnung ersetzt resolvedPair() (catalog.ts) das Wildcard ? am E-Locus durch das dominanteste Allel E (alleles[0]) -> [e,E] -> exprimiert E (volle Extension) -> kein Fuchs. Folge: Algierfuchs (E:'e') matcht nicht, Farbschlag wird falsch bzw. "Unbekannter Farbschlag", und die ungültige Notation e[-] bleibt sichtbar.
+- **Empfehlung:** E-Locus-Sonderregel: ein einzeln bekanntes Fuchs-Allel e mit unbekanntem Partner ([e,?]) zu ee auflösen (rezessiver Phänotyp impliziert Homozygotie), statt ? per resolvedPair zum dominanten E zu machen. Konkret in normalizeToken (genotype.ts) "ee[-]"/"e[-]" am E-Locus zu ee normalisieren; analog tools/import/genotype.py, damit der gespeicherte Genotyp ee statt ee[-] enthält, danach re-ingest. Optional: bei echtem unauflösbarem e- eine Validierungswarnung "ungültiger E-Locus" im UI (Nutzerinwunsch). Erwartet: Aa CC D- ee Gg Pp spsp -> Algierfuchs.
+- **Fix-Ebene:** genetics-engine · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/genotype.ts (normalizeToken: ee[-]->ee); gerbil-manager-web/src/genetics/catalog.ts (resolvedPair Wildcard-Fallback am E-Locus); tools/import/genotype.py (E-Locus-Parsing)
+
+### Cluster `genetics-inheritance` (1)
+
+#### #38 — Gencode nutzt keine Vererbungslogik: erzwungenes E-Allel bleibt unbekannt (Ee[-] statt Ee)
+- **Tier/Wurf:** Mamta Mini v.d. Kleinen Chaoten (da911047); Vater Geely (b71c0fda), Mutter Gaida (04358c1f)  ·  Kontext: gerbil-detail  ·  Ticket `1a508c04`
+- **Meldung:** Gencode stimmt nicht! Er braucht das Verständnis der Vererbung! Wenn sein Vater namens Geely ee gg trägt, kann er auch nur e und ganz seine Nachkommen vererben.sodass Mamta Mini Ee und Gg tragen muss als Agouti
+- **Ursache:** Mamta Minis Genotyp "AA CC D- Ee[-] Gg PP spsp" wurde verbatim aus dem Stammbaum-xlsx übernommen (provenance: "Genotyp aus xlsx"). Am E-Locus steht E + unbekannt (Ee[-]). Vater Geely kann am E-Locus nur e weitergeben (Anzeige ee[-] = Fuchs, plus gg homozygot), also ist das zweite E-Allel zwingend e und müsste als Ee aufgelöst werden, nicht Ee[-]. G-Locus (Gg) ist bereits korrekt. Weder Import noch App leiten erzwungene Allele aus den Eltern ab oder validieren dagegen: breed.ts/punnett.ts machen nur Vorwärts-Prognosen (Probeverpaarung); es gibt keine Rück-Inferenz gespeicherter Genotypen gegen Elterngenotypen.
+- **Empfehlung:** Eltern-basierte Allel-Inferenz/Validierung ergänzen: pro Locus prüfen, ob ein Elternteil homozygot ist und ein Kind-Allel erzwingt; unbekannte Allele ([-]/?) entsprechend auflösen (hier Ee[-] -> Ee). In der Genetics-Engine als Funktion (resolveFromParents/validateAgainstParents) implementieren und in der Tier-Akte anzeigen (aufgelöstes Allel + Hinweis-Chip). Optional schon im Import (genotype.py/merge_and_resolve) anwenden, um gespeicherte Genotypen zu vervollständigen.
+- **Fix-Ebene:** genetics-engine · **Aufwand:** L · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/breed.ts; gerbil-manager-web/src/genetics/punnett.ts; gerbil-manager-web/src/genetics/genotype.ts; gerbil-manager-web/src/genetics/warnings.ts; tools/import/genotype.py; tools/import/merge_and_resolve.py; Tier-Akte (gerbil-detail) Genotyp-Anzeige
+
+### Cluster `genetics-unknown-allele-wildcard` (1)
+
+#### #39 — Wurf zeigt Dilute- und "unbekannte" Farbschlaege, die aus dieser Verpaarung nicht fallen koennen
+- **Tier/Wurf:** Wurf von Mamta Mini v.d. Kleinen Chaoten + Gold v.d. Kleinen Chaoten (98bfdf92-f0aa-546f-8eb1-972b3aff71ea)  ·  Kontext: litter-detail  ·  Ticket `3e643ef1`
+- **Meldung:** Unbekannter Farbschläge können nie fallen! Auch keine Dilute Farbschläge können bei dieser Verpaarung fallen
+- **Ursache:** Beide Eltern haben am D-Locus ein unbekanntes Allel (Vater "AA CC D- Ee[-] Gg PP spsp", Mutter "Aa CC D- Ee Gg pp spsp"; Genotypen direkt aus dem Stammbaum-xlsx). Die Genetik-Engine (punnett.ts -> parentAlleleWeights) expandiert ein unbekanntes Allel "?"/"-" UNIFORM ueber die GESAMTE Allel-Menge des Locus inkl. der rezessiven Allele. Dadurch traegt jeder "D-"-Elternteil mit 1/4 ein d-Gamet bei -> es fallen dd-(Dilute-)Nachkommen UND Nachkommen mit "?"-Allelen, die in catalog.farbschlagFor als "Unbekannter Farbschlag" enden. Beides erscheint faelschlich als erwarteter Farbschlag, obwohl die Eltern phaenotypisch nicht-dilute sind.
+- **Empfehlung:** Wildcard-Semantik in punnett.ts ueberarbeiten: ein unbekanntes Allel neben einem dominanten sichtbaren Allel darf nicht als gleichberechtigte 50%-Quelle fuer rezessive Phaenotypen wirken. Optionen: (a) "Unbekannter Farbschlag"-Outcomes nicht als erwarteten Farbschlag listen, sondern als Restanteil/Hinweis kennzeichnen; (b) rezessive Phaenotypen aus unbekanntem Allel nur als "moeglich" markieren statt mit fixer Wahrscheinlichkeit, oder das unbekannte Allel konservativ als sichtbares dominantes Allel annehmen (D- = vermutlich DD, kein Dilute). Mit der Nutzerin klaeren, welche "-"-Semantik gewuenscht ist (sichtbarer Phaenotyp dominiert -> kein Dilute, keine unbekannten Farbschlaege).
+- **Fix-Ebene:** genetics-engine · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/punnett.ts (parentAlleleWeights Wildcard-Expansion ueber alle Allele); gerbil-manager-web/src/genetics/breed.ts (offspring/byFarbschlag Aggregation, unknownFarbschlag-Flag); gerbil-manager-web/src/genetics/catalog.ts (farbschlagFor -> Unbekannter Farbschlag); Eltern-Genotypen: Mamta Mini da911047 (D-), Gold e489b704 (D-)
+- **Rückfrage:** Welche Semantik soll "-"/unbekanntes Allel in der erwarteten-Farbschlag-Berechnung haben: konservativ als sichtbares dominantes Allel annehmen (kein Dilute, keine unbekannten Farbschlaege) oder rezessive Outcomes nur als "moeglich" anzeigen?
+
+### Cluster `genetics-wildcard-expansion` (1)
+
+#### #37 — Erwartete Farbschläge im Wurf falsch: Wildcard-Allel expandiert über dominante Allele, erzeugt unmögliche Morphe
+- **Tier/Wurf:** Wurf Geely x Gaida (d9620c58); Eltern Geely b71c0fda (A- C- D- ee[-] gg Pp spsp) + Gaida 04358c1f (A- CC D- Ee GG Pp spsp)  ·  Kontext: litter-detail  ·  Ticket `c8ce27e2`
+- **Meldung:** Erwarte Farbschläge stimmen erneut nicht!
+- **Ursache:** Beide Eltern tragen Wildcard-Allele aus der Züchter-Notation (Geely: e?, C?, D?, A?; Gaida: A?, D?). parentAlleleWeights() in punnett.ts expandiert jedes ? UNIFORM über den GESAMTEN Allelsatz des Locus, inkl. des dominanten Allels. Genetisch unzulässig: das unbekannte Partner-Allel kann nie dominanter sein als das sichtbar ausgeprägte (sonst wäre der Phänotyp ein anderer). Bei Geely (e? = Fuchs, lt. MEMORY nur e oder ef) erhält das versteckte dominante E fälschlich 1/3 Gewicht, sodass die Berechnung nicht-Fuchs-/Dilute-/Unbekannter-Farbschlag-Nachkommen liefert (Agouti 38%, Gold 13%, Blau, diverse Dilute, 0,5% Unbekannt), die in dieser Verpaarung nicht fallen können.
+- **Empfehlung:** Wildcard-Expansion dominanz-beschränken: in parentAlleleWeights() (gerbil-manager-web/src/genetics/punnett.ts) das ? nur über Allele mit Dominanzrang &lt;= dem bekannten Partner-Allel des Paares expandieren (verstecktes Allel kann nie dominanter sein als das ausgeprägte), statt uniform über LOCI[locus].alleles. Bei vollständig unbekanntem Locus (?,?) weiter voller Satz. Damit verschwinden die unmöglichen dominanteren Morphe sowie die Dilute-/Unbekannt-Artefakte. Gleiche Ursache deckt die Schwester-Tickets 3e643ef1, 1e7b66e6, 3c46d0b4, 473dc345 ab; gemeinsam testen.
+- **Fix-Ebene:** genetics-engine · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/genetics/punnett.ts (parentAlleleWeights); gerbil-manager-web/src/pages/WurfDetailPage.tsx (breed-Aufruf); gerbil-manager-web/src/genetics/__tests__
+
+### Cluster `given-away-receiver-missing` (1)
+
+#### #4 — Arya Stark: Abgabe an Clan of Black Forest fehlt
+- **Tier/Wurf:** Arya Stark von den Kleinen Chaoten (b4f59085-5d0d-51b0-9c94-bddf622b5935)  ·  Kontext: gerbil-detail  ·  Ticket `e9790985`
+- **Meldung:** Arya Stark wurde an die Zucht Clan of Black Forest abgegeben und sollte nicht mehr bei meiner Zucht angezeigt werden
+- **Ursache:** Die Abgabe an Clan of Black Forest ist nirgends erfasst. Kein Vertrag fuer Arya vorhanden (GET /contracts leer), daher konnte enrich_from_contracts keinen Abnehmer/GivenAway setzen. Quelle (Stammbaum) lieferte nur Sterbedatum 31.12.2024, status wurde Deceased, receiverContactId bleibt null. Arya ist korrekt isResident=true und originBreeder=Zucht der kleinen Chaoten. Da kein Abnehmer existiert und status=Deceased ist (GerbilDetailPage.tsx Z.332-333 blendet Abnehmer bei Deceased aus), fehlt jeder Hinweis auf die Abgabe.
+- **Empfehlung:** Datenkorrektur: Kontakt Clan of Black Forest als receiverContactId setzen und Abgabe via goHomeDate/Status abbilden. Quelle hat nur DOD, daher Abgabe-Info per Import-Aufloesung (conflict-decisions.json) oder manuellem Edit ergaenzen. Achtung: bei status=Deceased zeigt die Detailseite den Abnehmer nicht (Z.332-333); ggf. Feld auch bei Deceased rendern. isResident bleibt true (kein Hagrid-Fall).
+- **Fix-Ebene:** import-data · **Aufwand:** S · **Konfidenz:** medium
+- **Betroffen:** tools/import/merge_and_resolve.py enrich_from_contracts; conflict-decisions.json / Quelldaten; gerbil-manager-web/src/pages/GerbilDetailPage.tsx Z.332-333
+- **Rückfrage:** Abgabedatum an Clan of Black Forest und ob Arya dort verstorben ist (DOD 31.12.2024 stammt aus dem Stammbaum).
+
+### Cluster `missing-parents-founder` (1)
+
+#### #10 — "Stammbaum fehlt" bei Hiro of Golden Lights (Fremd-/Gründertier ohne erfasste Eltern)
+- **Tier/Wurf:** Hiro of Golden Lights (bbfdf289-91bf-52a8-abf3-2cb718a6ac0d)  ·  Kontext: stammbaum  ·  Ticket `f3ad5ec9`
+- **Meldung:** Stammbaum fehlt
+- **Ursache:** Hiro ist ein extern zugekauftes Gründertier (Zucht "Golden Lights"): litterId=null und parentRefs=[] in beiden Quell-Stammbäumen (Stammbaum von Vance.xlsx, Stammbaum von Yurikas und Pintos Sohn.xlsx). Er erscheint selbst als Elternteil mehrerer Tiere, aber seine eigenen Eltern wurden in den Quelldaten nie erfasst. In build.ts (Zeile 52: if(!gerbil.litterId) liefert keine parents) rendert die Stammbaum-Ansicht daher nur einen einzelnen Knoten ohne Hinweistext, was die Nutzerin als "Stammbaum fehlt" wahrnimmt. Daten sind korrekt; es fehlt nur die UX-Kommunikation.
+- **Empfehlung:** Kein Datenfehler. Frontend: Wenn das Probanden-Tier keine litterId/keine Eltern hat, statt einer leer wirkenden Einzelknoten-Ansicht einen klaren Hinweis zeigen, z.B. "Keine Vorfahren bekannt - Fremd-/Gründertier (Herkunft: {originBreeder})". Text in de.ts. Optional bei gesetzter originContactId/originBreeder als "Gründertier" markieren. Falls die Nutzerin Hiros Eltern tatsächlich kennt, wäre das separate Datenpflege.
+- **Fix-Ebene:** frontend · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** gerbil-manager-web/src/pedigree/build.ts (Zeile 52); gerbil-manager-web/src/pages/StammbaumPage.tsx; gerbil-manager-web/src/strings/de.ts; tools/import/output/animals.json (Hiro: parentRefs=[])
+- **Rückfrage:** Sind Hiros Eltern tatsächlich bekannt? Falls ja, bitte Namen nennen - sonst gilt er korrekt als Gründertier ohne Vorfahren.
+
+### Cluster `origin-label` (1)
+
+#### #19 — Herkunft/Zuchtname wird als Black Forest statt Clan of Black Forest angezeigt
+- **Tier/Wurf:** Hagrid Rubeus of Black Forest  ·  Kontext: gerbil-detail  ·  Ticket `b1629f97`
+- **Meldung:** Herkunft sollte heißen: " Clan of Black Forest"
+- **Ursache:** Der Zuchtname wird beim Import aus dem Tiernamen-Suffix abgeleitet. norm_zucht (merge_and_resolve.py:136) verwirft das Fuellwort of, daher heisst der Zuechter-Kontakt 2f08f4ef und originBreeder Black Forest statt Clan of Black Forest. ZUCHT_ALIASES blackforestgv zu Black Forest (Zeile 170) zementiert das. Genetik/Dedup korrekt.</rootCause>
+<parameter name="entity">Hagrid Rubeus of Black Forest (73759a6a-9ad2-5ce5-becb-8d9fc8b5af43)
+- **Empfehlung:** In ZUCHT_ALIASES (merge_and_resolve.py:170) den Wert Black Forest zu Clan of Black Forest aendern oder den Kontakt 2f08f4ef via conflict-decisions.json umbenennen, dann Import neu generieren plus POST /import/ingest-resolved.
+- **Fix-Ebene:** import-data · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py:170; tools/import/merge_and_resolve.py:136; tools/import/extract.py:114; Kontakt 2f08f4ef-bfce-5323-aaa6-f1eedfb4c0f7; Gerbil.originBreeder; tools/import/conflict-decisions.json
+- **Rückfrage:** Lautet der korrekte Zuchtname generell Clan of Black Forest und gilt das fuer alle Tiere mit Suffix of Black Forest?
+
+### Cluster `photo-mismatch` (1)
+
+#### #14 — Odelia: falsches Profilfoto durch fragile Foto-Zuordnungsheuristik
+- **Tier/Wurf:** Odelia von den Kleinen Chaoten (3609e642-73e4-579e-87f1-da0332b1d037)  ·  Kontext: gerbil-detail  ·  Ticket `d99563fa`
+- **Meldung:** Falsches Foto
+- **Ursache:** Odelia ist aus 4 Datensaetzen ueber mehrere Stammbaum-XLSX gemergt und hat 3 Fotos akkumuliert. _attach_photos ordnet Fotos rein heuristisch zu (Generation aus Spalte + minimaler Zeilenabstand), ohne zu pruefen, ob ein Bild wirklich zu Odelia gehoert; wo sie nur Vorfahre ist, wird leicht das Foto eines Nachbartiers uebernommen.
+- **Empfehlung:** In _attach_photos (extract.py 339-408) die Zuordnung verschaerfen: Foto nur uebernehmen, wenn Spalten- UND Zeilenabstand zur Namenszelle unter einem Schwellwert liegen (sonst verwerfen), und left/right-Style pro Foto statt global pro Sheet bewerten. Bei mehrfach gemergten Tieren Fotos aus Quellen bevorzugen, in denen das Tier Proband ist. Kurzfristig als import-data korrigierbar: falsche Foto-Zuordnung fuer Odelia entfernen / Profilfoto explizit setzen. Vorher Quellcharts pruefen, welches der 3 Fotos Odelia zeigt.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** medium
+- **Betroffen:** tools/import/extract.py (_attach_photos, 339-408); resolved_import.json (photos[] fuer gerbil 3609e642); tools/import/merge_and_resolve.py (Foto-Sammlung beim Merge)
+- **Rückfrage:** Welches der 3 Fotos (sortOrder 0/1/2) zeigt Odelia tatsaechlich? Noetig, um das korrekte Profilfoto festzulegen und die falschen zu entfernen.
+
+### Cluster `wrong-parents-chart-position` (1)
+
+#### #7 — Falscher Vater bei "Sunny von PZ Karl" durch positionsbasierte Eltern-Rekonstruktion
+- **Tier/Wurf:** Sunny von PZ Karl (5c4982a5-d92d-568a-a9bf-0b39b990c72f)  ·  Kontext: stammbaum  ·  Ticket `8fe0e93e`
+- **Meldung:** Falscher Papa!
+- **Ursache:** Sunny (DOB 2014-04-10, originBreeder "PZ Karl") wurde als Fremdtier in "Stammbaum von Vance.xlsx" gefunden; ihre Eltern stammen NICHT aus Quelldaten, sondern wurden von _reconstruct_parents (extract.py:309-336) rein positionell geraten (method=chart-position, confidence=medium): Vater = naechster Block oberhalb, Mutter = naechster unterhalb in der naechsten Generationsspalte. Dadurch wurde faelschlich "Hiro of Golden Lights" (bbfdf289) als Vater und "Melly von Privat" (5b928c39) als Mutter angehaengt; der virtuelle Wurf 8f1bb1d2 traegt Wurf-Datum = Sunnys DOB. Da Sunny extern (PZ Karl) zugekauft ist, sind ihre echten Eltern gar nicht im Chart, die Bracketing-Heuristik liefert komplett fremde Tiere.
+- **Empfehlung:** Geratene Eltern dieser Verpaarung (virtueller Wurf 8f1bb1d2 / Sunny) verwerfen. Kurzfristig: in der Import-Aufloesung (conflict-decisions.json) die chart-position-Eltern fuer Sunny entfernen / auf unbekannt setzen, dann re-ingest. Mittelfristig: _reconstruct_parents soll medium-confidence chart-position-Eltern unterdruecken, wenn das Tier ein Fremdtier am Chart-Rand ist (originBreeder gesetzt). Schwester-Ticket 0ba551a3 (Falsche Mutter, selbe Sunny/Wurf) gehoert zur selben Verpaarung und wird mit erledigt.
+- **Fix-Ebene:** import-data · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/extract.py (_reconstruct_parents); tools/import/merge_and_resolve.py (conflict-decisions); Litter 8f1bb1d2-8bbb-587c-af99-d81758c38397; Gerbil 5c4982a5-d92d-568a-a9bf-0b39b990c72f
+- **Rückfrage:** Sind Sunnys echte Eltern bekannt, oder unbekannt (Fremdzukauf von PZ Karl)? Falls unbekannt, Eltern komplett entfernen statt zu korrigieren.
+
+### Cluster `wrong-parents-external-breeder` (1)
+
+#### #5 — Bill von Privat: erfundene Eltern statt "unbekannt" (Fremdtier bekommt Stammbaum-Position-Eltern)
+- **Tier/Wurf:** Bill von Privat (a948d47c-c731-51e9-9ddf-9bcb4f55fc3b); virtueller Wurf 7b772ce1-7a3c-5729-acf3-641f5dbf2718  ·  Kontext: stammbaum  ·  Ticket `50b17699`
+- **Meldung:** Eltern sind unbekannt!
+- **Ursache:** Bill ist ein Fremdtier (zucht="Privat", originBreeder="Privat") und damit ein Blatt in den Stammbäumen der Züchterin; seine Abstammung ist ihr unbekannt. Trotzdem weist extract._reconstruct_parents (Z.309-336) ihm per chart-position Eltern zu: Hazel of Helianthus mit roleGuess "father", Herakles II als "mother". Daraus baut merge_and_resolve einen virtuellen Wurf mit motherId=Hazel. Die Daten sind erkennbar falsch: Hazel ist weiblich/2010 (als Vater geraten); Herakles II ist am 16.12.2013 NACH Bill (01.08.2013) geboren. _reconstruct_parents hat keinen Guard für Tiere fremder Zuchten.
+- **Empfehlung:** In extract._reconstruct_parents Tiere fremder Zuchten als Blätter behandeln und KEINE chart-position-Eltern vergeben, wenn zucht/breeder nicht die Heimzucht ("Kleine Chaoten") ist (is_home_cattery aus extract.py:144 negiert nutzen; "Privat"/"of Helianthus" etc.). Nach Re-Import den fälschlich erzeugten virtuellen Wurf 7b772ce1 entfernen und Bills litterId auf null setzen. Alternativ kurzfristig via conflict-decisions.json die Eltern-Links von Bill verwerfen.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/extract.py (_reconstruct_parents ~Z.309-336, is_home_cattery ~Z.144); tools/import/merge_and_resolve.py (virtuelle Wurf-Rekonstruktion aus parentRefs); DB Wurf 7b772ce1-7a3c-5729-acf3-641f5dbf2718; DB Tier a948d47c-c731-51e9-9ddf-9bcb4f55fc3b
+
+### Cluster `wrong-parents-gender-swap` (1)
+
+#### #33 — Vance: Mutter fehlt (sollte Enya von den Kleinen Chaoten sein)
+- **Tier/Wurf:** Vance von den Kleinen Chaoten (f31eb1f9-0113-5da8-ac14-9ebfb24a6af9)  ·  Kontext: gerbil-detail  ·  Ticket `46c635ba`
+- **Meldung:** Muttertier fehlt, ist aber bekannt, es sollte Enya von den Kleinen Chaoten sein
+- **Ursache:** Vances Wurf 9a335cec hat fatherId=Brandon Stark (male), motherId=null. Laut Provenance erkannte der Import per Chart-Position einen Kandidaten "Enya von den Kleinen Chaoten" (2b22b29e, female, *01.11.2017), verwarf ihn aber für die VATERrolle wegen "falsches Geschlecht" und ordnete ihn NICHT der Mutterrolle zu. Die Mutterrolle wurde stattdessen mit "Stich von Privatzucht Gießen" (male) befüllt und danach verworfen ("ein Wurf hat nur einen Vater und eine Mutter") → Mutter blieb leer. pick_parent_ref wählt Vater- und Mutterrolle unabhängig und droppt geschlechts-falsche Kandidaten (Penalty 3), nutzt aber einen verworfenen, geschlechtlich passenden Kandidaten (Enya, female) nicht als Fallback für die leere Mutterrolle.
+- **Empfehlung:** In tools/import/merge_and_resolve.py die Rollenzuweisung gender-getrieben statt positions-getrieben machen: einen wegen "falsches Geschlecht für die Vaterrolle" verworfenen weiblichen Kandidaten (hier Enya, female) in die leere Mutterrolle übernehmen, statt die Position als Vater hart zu verwerfen. Konkret: vor/zusammen mit assign_parent_roles die beiden chart-position Refs nach tatsächlichem Geschlecht auf father/mother verteilen (Swap statt Drop). Danach Mutter von Vances Wurf = Enya (2b22b29e); anschließend extract→merge→POST /import/ingest-resolved.
+- **Fix-Ebene:** import-logic · **Aufwand:** M · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py: pick_parent_ref / assign_parent_roles / explain_pick_rejections (Z. ~640-760, 1573-1590); Litter 9a335cec-7bf0-598d-b2ee-29f41197744b (motherId=null); Gerbil Enya von den Kleinen Chaoten 2b22b29e-905e-5ccd-aeee-44eee0b825b2 (female)
+
+### Cluster `wrong-parents-stammbaum-vance` (1)
+
+#### #6 — Sunny von PZ Karl: falsche Mutter (und Vater) aus Stammbaum-Position abgeleitet
+- **Tier/Wurf:** Sunny von PZ Karl (5c4982a5-d92d-568a-a9bf-0b39b990c72f)  ·  Kontext: stammbaum  ·  Ticket `0ba551a3`
+- **Meldung:** Falsche Mutter
+- **Ursache:** Sunny ist ein extern zugekauftes Tier (originBreeder "PZ Karl", Privatzucht) ohne in den Charts hinterlegte Eltern. Der Import hat ihr per chart-position-Heuristik (parentMethod=chart-position, parentConfidence=medium) den virtuellen Wurf 8f1bb1d2 mit Vater=Hiro of Golden Lights + Mutter=Melly von Privat zugeordnet — zwei unverwandte Linien, die in "Stammbaum von Vance.xlsx" nur raeumlich ueber/neben Sunny standen. parent_age_plausible greift nicht (Melly 30.09.2013 vs Wurf 10.04.2014 = ~192 Tage, formal plausibel), daher wird die Fehlzuordnung nicht verworfen. Schwestertickets: 8fe0e93e (Falscher Papa, selbes Tier), bee684ed (Melly Eltern unbekannt), f3ad5ec9 (Hiro Stammbaum fehlt).
+- **Empfehlung:** Den virtuellen Wurf 8f1bb1d2 fuer Sunny als Fehlattribution aufloesen: in der Import-Aufloesung (conflict-decisions.json) die chart-position-Eltern (Hiro + Melly) fuer Sunny verwerfen, sodass Sunny als extern zugekauft (PZ Karl) ohne Eltern dargestellt wird. Generell: chart-position-Eltern fuer Tiere mit externem originBreeder ("von PZ ...", "von Privat") nicht automatisch als virtuellen Wurf setzen. Danach merge_and_resolve.py neu laufen + POST /import/ingest-resolved.
+- **Fix-Ebene:** import-data · **Aufwand:** S · **Konfidenz:** high
+- **Betroffen:** tools/import/merge_and_resolve.py (pick_parent_ref/assign_parent_roles/virtueller Wurf); Wurf 8f1bb1d2-8bbb-587c-af99-d81758c38397; Gerbil 5c4982a5 (Sunny von PZ Karl); Quelldatei Stammbaum von Vance.xlsx; conflict-decisions.json
+- **Rückfrage:** Hat Sunny von PZ Karl bekannte Eltern oder ist sie wurzellos zugekauft? Falls Eltern bekannt sind, bitte korrekte Namen nennen.