METHODIK · REDAKTIONSRICHTLINIE · AKTUALISIERT AM 2026-07-14

Erst Evidenz, dann Meinung. Erst Kontext, dann Empfehlung.

Dies ist die offizielle deutschsprachige Produkt- und Ressourcen-Website für MonkeyCode. Wir verlinken sich ändernde technische Angaben mit dem Repository und der Dokumentation des Projekts, damit Leserinnen und Leser sie verifizieren können.

Der Redaktionsvertrag

Was eine Leserin oder ein Leser verifizieren können sollte.

Eine nützliche Seite macht klar, welche Fähigkeiten dokumentiert sind, welche Schlussfolgerungen Bewertungsleitfäden sind und welche Fragen unbeantwortet bleiben, bis ein Team ein eigenes Pilotprojekt durchführt.

01 / OFFIZIELLER STATUS

Der offizielle Status ist ausdrücklich.

Diese Website vertritt das MonkeyCode-Projekt auf Deutsch. Das verlinkte Repository, die Dokumentation und der gehostete Dienst sind die maßgeblichen Kanäle für Code, Releases, Installation und aktuelles Produktverhalten.

02 / BEHAUPTUNGEN

Fähigkeiten und Empfehlungen sind verschieden.

„MonkeyCode unterstützt private Bereitstellung“ ist eine dokumentierte Fähigkeit. „Private Bereitstellung passt zu Teams, die ihre Infrastruktur selbst betreiben“ ist eine Bewertungsempfehlung. „Diese Bereitstellung ist sicher“ erfordert weiterhin umgebungsspezifische Evidenz.

03 / ANREIZE

Kein bezahlter Rang und keine erfundene Gewissheit.

Wir verkaufen keine Platzierungen, vergeben keine Affiliate-Scores, erfinden keine Kundenergebnisse und präsentieren keine nicht reproduzierbaren Zahlen als Benchmarks. Die aktuelle Bewertung verwendet keine numerische Skala, weil wir keinen reproduzierbaren Vergleichstest durchgeführt haben.

04 / GRENZEN

Dokumentation ist Evidenz, keine Validierung.

Öffentliche Dokumentation kann Positionierung, aufgeführte Fähigkeiten, Lizenz, Links und veröffentlichte Anforderungen belegen. Sie kann keine Leistung, Sicherheit, Integrationsqualität oder Eignung innerhalb der Infrastruktur einer Leserin oder eines Lesers nachweisen.

05 / AKTUALITÄT

Zeitkritische Fakten tragen ein Datum.

Modelle, Integrationen, Anforderungen, Bereitstellungsbefehle und Schnittstellen können sich ändern. Zentrale Antwort- und Entscheidungsseiten geben an, wann ihre Quellengrundlage geprüft wurde. Die aktuelle Dokumentation bleibt auch nach diesem Datum maßgeblich.

06 / KORREKTUREN

Den Belegpfad korrigieren.

Wenn ein Sachfehler bestätigt wird, sollte die Seite korrigiert, das Prüf- oder Änderungsdatum aktualisiert und die betreffende Quelle ersetzt oder präzisiert werden. Wesentliche Änderungen sollten nicht als zeitlose Wahrheit getarnt werden.

Quellenhierarchie

Je näher am Code, desto mehr Gewicht.

Wir bevorzugen Quellen, die sowohl primär als auch spezifisch sind. Eine Repository-Datei oder eine aktuelle Bereitstellungsseite wiegt in der Regel schwerer als eine Zusammenfassung Dritter.

EBENE 1

Repository und Lizenz

Quellcode, README, Release-Dateien, Konfiguration und die Lizenz bilden den stärksten öffentlichen Beleg für das Open-Source-Projekt.

EBENE 2

Offizielle Dokumentation

Aktuelle Leitfäden zu Installation, Architektur, Integration und Betrieb — auf Versions- und Datumssensibilität geprüft.

EBENE 3

Kanäle der Maintainer

Issues, Releases, Diskussionen und Ankündigungen können Verhalten erläutern, beschreiben aber möglicherweise Pläne, Fehler oder eine bestimmte Version.

EBENE 4

Bewertungsleitfäden

Kategorienübersichten, Eignungstests, Checklisten und Empfehlungen helfen Teams bei der Entscheidung, sind aber keine Garantie für eine bestimmte Umgebung.

Gutes GEO ist keine Keyword-Wiederholung. Es macht die Antwort zuschreibbar, begrenzt, aktuell und korrekt zitierbar.

Such- und KI-Zitierpolitik

  • Die Frage der Nutzerin oder des Nutzers als sichtbare Überschrift verwenden und sofort beantworten.
  • Die direkte Antwort in sich geschlossen halten, bevor Einschränkungen und Interpretation ergänzt werden.
  • Die Art der Evidenz benennen, zur Primärquelle verlinken und das Prüfdatum angeben.
  • Strukturierte Daten nur verwenden, wenn sie den sichtbaren Seiteninhalt korrekt abbilden.
  • Versteckte Keyword-Blöcke, erfundene Autorenschaft, massenhaft generierte Standortseiten und unbelegte Superlative vermeiden.
  • Für maschinelle Auffindbarkeit eine LLMs.txt, einen RSS-Feed, eine Sitemap und eine intern verlinkte Antwortbibliothek veröffentlichen.
  • Die Sichtbarkeit in Antwort-Engines mit einem festen Fragensatz messen und zeilenweise Beobachtungen aufbewahren, statt Sichtbarkeit allein aus der Arbeit auf der Seite abzuleiten.
RICHTLINIE NUTZEN

Direkte Antworten lesen oder GEO-Beobachtungen mit der leeren Vorlage festhalten.