# DUPLICATE RESOLUTION PLAN — Tolaria (Mission 002)

Datum: 2026-08-25 · Red Queen · Status: **NUR PLAN — KEINE AUSFÜHRUNG**

> ⚠️ Die 19 bekannten Duplikat-Paare werden **NICHT** gelöscht, verschoben,
> überschrieben, gemerged oder umbenannt. Dieser Plan bereitet die spätere
> **B3-Phase** vor. Keine produktive Wissensdatei wird für diese Planung verändert.

---

## Methode (EVIDENCE)
- Alle 84 Vault-Dateien aus Baseline `TOLARIA-BACKUP-20260825-051420` gelesen.
- Duplikat-Gruppe = gleicher Basename an 2 Orten:
  - **ROOT** = `/app/vault/<name>.md`
  - **SYSTEM-DOCS** = `/app/vault/notes/trading/system-docs/<name>.md`
- Pro Paar: Zeilen, Wörter, SHA-256 + Frontmatter/Zeitstempel verglichen.

## Befund-Übersicht (EVIDENCE)

| # | Datei | Root | System-Docs | Neuere/Größere | Unterschied |
|---|---|---|---|---|---|
| 1 | README.md | 610w | 551w | ROOT | Root ausführlicher |
| 2 | infrastructure-handbook.md | 248w | 254w | SD | SD minimal größer |
| 3 | modul-03-market-data.md | 620w | 626w | SD | fast identisch |
| 4 | modul-04-market-regime.md | 929w | 935w | SD | fast identisch |
| 5 | modul-05-strategy-engine.md | 968w | 974w | SD | fast identisch |
| 6 | modul-06-signal-ranking.md | 1084w | 1090w | SD | fast identisch |
| 7 | modul-07-risk-manager.md | 747w | 753w | SD | fast identisch |
| 8 | modul-08-portfolio-manager.md | 1136w | 1142w | SD | fast identisch |
| 9 | modul-09-execution-service.md | 971w | 662w | ROOT | **ROOT deutlich größer** |
| 10 | modul-10-trade-journal.md | 481w | 487w | SD | fast identisch |
| 11 | modul-11-analytics.md | 467w | 473w | SD | fast identisch |
| 12 | modul-12-backtesting.md | 689w | 695w | SD | fast identisch |
| 13 | modul-13-optimization.md | 763w | 769w | SD | fast identisch |
| 14 | modul-14-notification.md | 820w | 826w | SD | fast identisch |
| 15 | modul-15-m09-design.md | 2236w | 2242w | SD | fast identisch |
| 16 | modul-15-m09-impl.md | 655w | 661w | SD | fast identisch |
| 17 | modul-15-monitoring.md | 958w | 964w | SD | fast identisch |
| 18 | ports-reference.md | 450w | 456w | SD | fast identisch |
| 19 | trend-pullback-v1.1-spec.md | 663w | 669w | SD | fast identisch |

> **Mehrheit (18/19):** Root-Version ist **nicht** größer — die System-Docs-Version
> ist marginal ausführlicher (Zeilenzahl), aber die Versionen sind **inhaltlich
> nahezu identisch** (Diff = wenige Zeilen, evtl. nur Umbruch/Format).
> **Ausnahme modul-09:** Root (971w) deutlich größer als SD (662w) → enthält mehr Inhalt.
>
> **Hinweis aus Mission 001:** Root = Trading-System-Namensgebung, aktuellerer Stand;
> system-docs = älterer organisierter Snapshot mit Frontmatter. Kein echter inhaltlicher
> Widerspruch, sondern unterschiedliche Entwicklungsstände.

---

## Regel für B3 (noch NICHT ausgeführt)
Für jedes Paar wird **vor** einer Entscheidung bestimmt:
- **CANONICAL CANDIDATE** (zu behaltender, vollständigster Stand)
- **SECONDARY CANDIDATE** (abzulegen/zu referenzieren)
- **CONTENT DIFFERENCES** (konkreter Zeilen-/Wort-Diff)
- **METADATA DIFFERENCES** (Frontmatter, created, title)
- **NEWER VERSION** (Git/Zeit-Erkennung)
- **UNIQUE INFO A/B** (was nur je eine Version enthält)
- **PROPOSED ACTION** (merge, behalten, verweisen)
- **RISK** (Verlust von unique Info / Broken Links)
- **REQUIRES HUMAN REVIEW?** (ja/nein)

> **Kein automatisches Merge.** Jedes Paar wird einzeln human-reviewt, bevor B3
> produktiv wird. Ziel: **CANONICAL KNOWLEDGE OBJECT** (aktuellster korrekter Inhalt
> + nützliche Metadaten + Beziehungen + Provenance), nicht einfach "neuere Datei".

---

## Kanonikalisierungs-Regeln (Designziel, dokumentiert in CANONICAL_KNOWLEDGE_PRINCIPLE)
1. Nicht "neuere Datei behalten" — sondern **vollständigsten + korrektesten Inhalt**.
2. Nützliche **Metadaten** (Frontmatter, title, tags, created) übernehmen.
3. **Beziehungen** (Wikilinks) erhalten/aktualisieren.
4. **Provenance** (Herkunft, Quelle, git-HEAD) dokumentieren.
5. Jede Änderung gegen **Transformation Baseline** prüfbar.