Red Queen
819fd8a6ff
- 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.
76 lines
3.9 KiB
Markdown
76 lines
3.9 KiB
Markdown
# 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.
|