trading-system-docs/tolaria/DUPLICATE_RESOLUTION_PLAN.md
Red Queen 819fd8a6ff tolaria: Mission 002 B1 Foundation & Backup docs (10 files)
- BACKUP_ARCHITECTURE, STORAGE_MAP, RECOVERY_RUNBOOK
- TRANSFORMATION_BASELINE, DUPLICATE_RESOLUTION_PLAN
- CANONICAL_KNOWLEDGE_PRINCIPLE, SEARCH_ARCHITECTURE_PROPOSAL
- KNOWLEDGE_GRAPH_PRINCIPLE, FORGEJO_TOLARIA_SYNC_PRINCIPLE
- HOST_CONTAINER_DISCOVERY

Fresh Checker PASS (deleg_a19028bc). No productive vault mutation.
2026-08-25 05:21:29 +00:00

3.9 KiB

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.