Konzept: Informationsportal aus dem Recherche-Vault

1. Ausgangslage

Das Vault research ist ein forensisches Recherche-Repository mit 193 Notizen (~1,3 MB), 100 % YAML-Frontmatter, 1.683 Wikilinks und 176 hierarchischen Tags. Es dokumentiert die mutmaßlich orchestrierte Anti-Windkraft-Kampagne in Wadersloh und ihre vertikale Transmissionskette bis hin zu Vernunftkraft e.V., AfD-Mandatsträgern und fossiler Lobby.

Das Vault ist bereits portal-ready:

konsistenter typ-Diskriminator (person | organisation | quelle | narrativ | feldnotiz)
kontrollierte status-Lifecycle-Vokabel (identifiziert → kartiert → ausgewertet → verifiziert)
hierarchische Tag-Namespaces (thema/*, org/*, ort/*, person/*, rolle/*, quelle/*)
zentrale MOC in Home.md
Pflege-Tooling unter tools (vault_audit, vault_normalize, vault_status)
vorab exportierter Mermaid-Graph network.mmd

2. Ziele & Nicht-Ziele

Ziele

Öffentlich navigierbares Informationsportal als Single-Source-of-Truth zur Recherche.
Interaktive Graph-Ansicht der Vault-Verlinkungen (Personen ↔ Organisationen ↔ Quellen ↔ Narrative).
Volltextsuche über alle Dossiers inkl. Filter nach typ, status, tags, ort.
Strukturierte Entity-Listen (Personen-, Organisations-, Quellen-, Narrativ-Verzeichnisse) mit sortierbaren Tabellen.
Timeline-Ansicht generiert aus Chronologie.md und datum-Frontmatter der Quellen.
Backlinks auf jeder Detailseite (wer verlinkt diese Notiz?).
Statisches Deployment (kein Server, kein DB) – CI-getriggert aus dem Markdown-Repo.
Quellentransparenz: jede Aussage führt sichtbar zu Primärquellen (Drucksachen, Niederschriften, HR-Auszüge).

Nicht-Ziele (v1)

Keine User-Accounts, keine Kommentare, keine UGC.
Keine WYSIWYG-Redaktion im Browser – Pflege bleibt in Obsidian.
Keine Hosting-Plattform für Originaldokumente (PDFs verbleiben in working_data/ bzw. werden extern verlinkt).

3. Rechtliche & ethische Vorab-Klärung (blocker für Go-Live)

Da das Portal namentlich identifizierte Privatpersonen in einem politisch aufgeladenen Kontext nennt, müssen vor Veröffentlichung geklärt werden:

Thema	Fragestellung	Maßnahme
DSGVO / KUG	Zulässigkeit der Nennung von Privatpersonen ohne Mandatsträger-Status	Juristische Stellungnahme einholen; Dossiers in zwei Klassen splitten (Person des öffentlichen Lebens vs. private Akteure)
Persönlichkeitsrecht	Verdachtsberichterstattung / Tatsachenbehauptung vs. Meinungsäußerung	Pressekodex-konforme Formulierung, jede Tatsachenbehauptung nur mit Primärquelle
Impressum / V.i.S.d.P.	TMG/MStV-Pflicht	Impressum + Datenschutzerklärung verpflichtend
Gegendarstellung	Anspruch der Genannten	Kontakt-/Korrektur-Workflow definieren
Vault-internes vs. Veröffentlichtes	Welche Notizen sind interne Arbeitsstände?	Frontmatter-Flag `publish: true/false` einführen, default `false`

Empfehlung: v1 nur Notizen mit status: verifiziert und publish: true veröffentlichen (Whitelist-Prinzip).

4. Technologie-Empfehlung

Hauptempfehlung: Quartz 4 (https://quartz.jzhao.xyz)

Begründung:

Speziell für Obsidian-Vaults gebaut: native [[Wikilinks]], Backlinks, Tags, Aliases, Frontmatter.
Eingebauter interaktiver Graph-View (D3-basiert, lokal + global) – erfüllt Kernanforderung out-of-the-box.
Volltextsuche (FlexSearch) clientseitig.
Statisches HTML, deploybar auf GitHub Pages / Netlify / Cloudflare Pages.
TypeScript/Preact-Komponenten – erweiterbar (Custom Layouts für typ-spezifische Ansichten).
Aktiv gewartet, große Community.

Alternativen (geprüft, aber nachgelagert)

Tool	Pro	Contra
Astro Starlight + `remark-wiki-link`	Sehr flexibel, top Performance	Graph-View muss selbst gebaut werden
Hugo + `obsidian-export`	Schnellster Build	Wikilinks/Graph nicht nativ
Eleventy + Custom-Plugins	Maximal kontrollierbar	Hoher Eigenbau-Aufwand
Obsidian Publish (offiziell)	Null Aufwand, originalgetreu	$$$, kein Custom-Branding, kein erweiterter Graph
Foam / Dendron	Vault-nah	Schwächere Web-Layer als Quartz

Entscheidung empfohlen: Quartz 4 als Basis, ggf. Astro als Fallback falls Custom-Layouts (Entity-Tabellen, Timeline) zu eng werden.

5. Informations-Architektur

/                           Landing (Stand der Recherche, Schlüsselbefunde aus Home.md)
/graph                      Interaktive Graph-Ansicht (vollständig)
/personen                   Tabelle: Name · Rolle · Status · Tags · Letzte Änderung
/personen/<slug>            Person-Dossier + Backlinks + Mini-Graph (Ego-Network)
/organisationen             Tabelle gefiltert nach Rolle (Dachverband, Landesverband, BI, …)
/organisationen/<slug>      Org-Dossier
/quellen                    Tabelle: Datum · Art · Drucksache · Status · URL
/quellen/<slug>             Quellen-Dossier
/narrative                  Liste der 10 Narrative-Debunks
/narrative/<slug>           Narrativ-Seite mit Quellenliste
/timeline                   Chronologie 2000–2026 (Vis-Timeline / Tiki-Toki-Stil)
/feldnotizen                Chronologisch sortierte Sitzungs-/Termin-Notizen
/offene-fragen              Aus Offene Fragen.md
/tags                       Tag-Cloud / Tag-Index
/tags/<tag>                 Notizen mit diesem Tag
/suche                      Volltextsuche (oder im Header)
/impressum, /datenschutz, /korrekturen

Routing-Regel: Slug = slugify(filename); Aliase aus Frontmatter aliases: werden Redirects.

6. Graph-View – Spezifikation

Datenquelle

Build-Step parst alle Markdown-Dateien und erzeugt graph.json:

{
  "nodes": [
    {"id": "personen/Christian Blex", "label": "Christian Blex",
     "typ": "person", "rolle": "lobbyist", "status": "verifiziert",
     "tags": ["org/afd", "ort/liesborn"]}
  ],
  "links": [
    {"source": "personen/Christian Blex",
     "target": "organisationen/Vernunftkraft", "weight": 1}
  ]
}

Visualisierung

Bibliothek: D3-force (Quartz-default) oder Cytoscape.js falls erweiterte Layouts (Cluster, Hierarchie) nötig.
Knotenfarben nach typ: Person · Organisation · Quelle · Narrativ · Feldnotiz.
Knotengröße nach Backlink-Count (Wichtigkeit).
Kantenstärke nach Anzahl Links zwischen zwei Notizen.
Filter-Panel:
- Toggle pro typ
- Toggle pro status
- Tag-Multi-Select
- Volltext-Highlight (“Christian Blex” → Knoten leuchtet)
Interaktion:
- Hover → Tooltip mit Frontmatter-Auszug
- Click → Sidebar mit Notiz-Preview + “Notiz öffnen”-Link
- Doppelklick → Ego-Network (nur Nachbarschaft Tiefe 1–2)
Layout-Algorithmen: force-directed (default), circular by typ, dagre (hierarchisch nach Vertikale Transmissionskette).
Performance: bei 200 Knoten unkritisch; WebGL-Renderer (sigma.js) optional ab >1000 Knoten.

Mini-Graph auf jeder Detailseite

Ego-Network Tiefe 1 (alle direkten Nachbarn) – Quartz liefert das nativ.

7. Daten-Pipeline

flowchart LR
    A[research/ Vault] -->|git push| B[CI Build]
    B --> C[vault_audit.py<br/>Validierung]
    C --> D{publish:true<br/>+ status:verifiziert?}
    D -->|ja| E[Markdown-Whitelist]
    D -->|nein| F[Skip]
    E --> G[Quartz Build<br/>+ graph.json gen]
    G --> H[Static Site /public]
    H --> I[Deploy: Pages/Netlify]

Pre-Build Checks (CI fail bei Verstoß):

Frontmatter-Schema (existierendes vault_audit.py erweitern).
Broken Wikilinks → Warning.
Fehlende quelle:-Referenz in Tatsachenbehauptungen → Warning.
Lint: keine Notiz ohne typ, status, tags.

8. Frontmatter-Erweiterungen (minimal-invasiv)

Neue optionale Felder (default sicher):

publish: false              # Whitelist-Flag, default nicht veröffentlichen
sichtbarkeit: intern        # intern | öffentlich | redaktion
letzte_pruefung: 2026-04-20 # für "Stand:"-Anzeige im Portal
quellenstand: belegt        # belegt | indizien | hypothese

Migration via vault_normalize.py – setzt publish: false überall, dann manuell auf true heben.

9. Phasenplan

Phase 0 – Vorbereitung (rechtlich + redaktionell, blockierend)

Juristische Prüfung der Veröffentlichungs-Zulässigkeit pro Personentyp.
Redaktionsstatut + Korrektur-/Gegendarstellungs-Workflow.
Impressum/Datenschutz-Texte.
Whitelist-Entscheid: welche ~30–50 Notizen gehen in v1.

Phase 1 – Technisches Setup

Neues Verzeichnis portal im Workspace anlegen.
Quartz 4 initialisieren, content/ als Symlink/Copy von research/ (gefiltert).
CI-Pipeline (GitHub Actions): Lint → Build → Deploy.
Domain + Hosting (z. B. Cloudflare Pages, Subdomain recherche.<projekt>.de).

Phase 2 – Inhaltliche Aufbereitung

vault_normalize.py um publish/sichtbarkeit erweitern.
Whitelist-Notizen redaktionell durchgehen (Tonalität, belegfeste Formulierung).
Home.md als Landing-Page adaptieren.
Narrative-Seiten als publikumsfreundliche Erklärstücke aufbereiten.

Phase 3 – Custom-Komponenten

Entity-Tabellen (Personen, Organisationen, Quellen) – Quartz-Layout-Override.
Timeline-Komponente (vis-timeline) gespeist aus datum-Frontmatter.
Erweiterter Graph-View mit typ-Filter und Layout-Switch.
Ego-Graph auf Detailseiten.

Phase 4 – Soft-Launch

Internes Review mit 3–5 Lesern aus dem Recherche-Umfeld.
Lade-Performance-Audit (Lighthouse > 90).
Accessibility-Check (WCAG AA, Tastatur-Navigation des Graphen).
Ankündigung an Genannte mit Mandat (Pressekodex-Routine).

Phase 5 – Go-Live + Pflege

Veröffentlichung.
Monitoring: Crash-/404-Logs, Suchanfragen.
Pflegerhythmus: Vault-Edit → Commit → Auto-Deploy.
Quartalsweises Vault-Audit (status-Lifecycle, broken Links).

10. Risiken & Mitigationen

Risiko	Wahrscheinlichkeit	Impact	Mitigation
Abmahnung / Unterlassung	mittel	hoch	Phase 0, Whitelist, Quellenpflicht, V.i.S.d.P., Korrektur-Workflow
SLAPP / Klagen	niedrig–mittel	hoch	Versicherung (Medienhaftpflicht), Trägerverein/Org als Herausgeber
Doxing-Vorwurf	mittel	mittel	Keine privaten Adressen, keine Familienangehörigen ohne Mandat
Vandalismus an Domain/CMS	niedrig	mittel	Statisches Hosting, kein Backend, MFA für Repo
Vault-Schema-Drift	mittel	niedrig	CI-Lint via `vault_audit.py`
Performance bei Wachstum	niedrig	niedrig	Pre-rendered, Graph nur on-demand laden

11. Aufwandsschätzung (grob, ohne Phase 0)

Phase	Aufwand
Phase 1 Setup	2–3 PT
Phase 2 Whitelist + Redaktion	5–10 PT
Phase 3 Custom-Komponenten	4–6 PT
Phase 4 Review/Polish	2–3 PT
Summe v1	13–22 PT

12. Offene Entscheidungen für den Auftraggeber

Trägerschaft / Herausgeber des Portals (Privatperson, Verein, BI-Initiative)?
Domain-Name und Branding-Linie (sachlich-investigativ vs. aktivistisch)?
Veröffentlichungs-Schwelle: nur verifiziert oder auch ausgewertet?
Personen-Politik: Privatpersonen nur mit ökonomischem Bezug, oder auch reine Sympathisanten?
Sprache: nur Deutsch oder auch englische Kurzfassung der Schlüsselbefunde?
Bevorzugte Hosting-Plattform (GitHub Pages / Cloudflare / Netlify / eigener Webserver)?
Trennung Portal-Repo vom Recherche-Repo (Public-Mirror) oder Monorepo mit Branch-Filter?

Nächster konkreter Schritt: Auftraggeber entscheidet über Punkte 1–7 in §12; danach Beginn Phase 0 + parallel technischer Prototyp (Quartz-Default mit allen Notizen lokal, ohne Deploy) zur Anschauung.

Klüngelakte

Explorer

portal_konzept