chemenu/kb/concepts/workflows/Publish-Remote Gate.md

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type	concept_type	tags	created	modified	related	sources	confidence	confidence_base	provenance	summary
types/concept.md	workflow		2026-09-01	2026-09-02	see-also Mass-Update Gate operates-on Chemenu see-also MCP-Leseserver	Source - Publish-Remote Gate and Issue Triage Session 2026-09-01 Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01 Source - MCP Read Server Implementation Session 2026-09-02	0.70	0.70	sourced	Drittes, im Code durchgesetztes Gate: publish bricht mit Exit 42 ab, wenn die aufgeloeste Push-URL nicht in einer optionalen, gitignoreten Allowlist steht; doctor benennt seit 2026-09-02 den Gate-Zustand statt nur die Dateiexistenz

Publish-Remote Gate

Typ: Workflow

Definition

Ein im Code durchgesetztes Gate, das einen Schreibvorgang (hier: publish) auf ein deklariertes, per Datei zugelassenes Ziel beschränkt. Der Vorgang bricht ab, wenn das aufgelöste Push-Ziel nicht in der Allowlist steht - unabhängig davon, unter welchem Namen der Remote lokal konfiguriert ist.

Kernpunkte

• Geprüft wird die aufgelöste URL, nicht der Remote-Name. Ein namensbasiertes Gate würde ein publish durchlassen, dessen origin zwischenzeitlich auf ein anderes Ziel umgebogen wurde - genau der Fall, den das Gate abfangen soll.
• Kein Freigabe-Token, anders als vergleichbare Gates. Ein Gate, dessen Frage per Änderungssatz beantwortbar ist ("ist diese konkrete Änderung richtig?"), kann sich mit einem Token lösen, den ein Mensch einmalig ausstellt. Ein Gate, dessen Frage eine stehende Eigenschaft des Checkouts ist ("gehört dieser Inhalt grundsätzlich in dieses Ziel?"), sollte keinen Token haben - der einzige Weg daran vorbei ist ein bewusster Edit der Konfigurationsdatei durch den Menschen, nie ein automatisierter Bypass.
• Die Allowlist-Datei ist per Checkout, nicht Teil des versionierten Inhalts. Sie beschreibt, wohin dieser Checkout schreiben darf - eine committete Kopie würde jedem Klon dieselbe Erlaubnis unterschieben, unabhängig davon, ob sie für ihn zutrifft.
• Fehlende Datei bedeutet unbeschränkt, kaputte Datei bedeutet Fehler. Diese Unterscheidung ist wichtig: Ein Checkout ohne Beschränkungsbedarf soll nicht gezwungen sein, eine leere Konfigurationsdatei zu pflegen; eine beschädigte Datei darf aber nicht wie eine abwesende behandelt werden, sonst wird eine defekte Sicherung zu einer stillschweigend abgeschalteten.
• doctor benennt seit 2026-09-02 den Gate-Zustand, nicht nur, ob die Datei existiert. Vorher meldete der Check nur die Anwesenheit von .wikitool-remotes.json; ob das gleichbedeutend mit "scharf" ist, musste der Leser selbst schließen. Alle drei Ausgaben beginnen jetzt mit Gate armed: bzw. Gate not armed: - der Ein-Remote-Fall ohne Allowlist bleibt OK (er hat nichts zu schützen), sagt aber ausdrücklich, dass jedes Push-Ziel durchkommt.¹

Wann zu verwenden

• Ein Checkout kann an mehr als ein Remote-Ziel schreiben, und ein Schreibvorgang an das falsche Ziel ist teuer oder nicht rückgängig zu machen (z. B. weil das Ziel öffentlich ist).
• Die Menge der zulässigen Ziele ist eine stabile Eigenschaft des Checkouts, keine Einzelfallentscheidung pro Vorgang.

Wann NICHT zu verwenden

• Wenn nur ein Remote existiert und kein Risiko einer Zielverwechslung besteht - dort ist die Allowlist reine Formalität ohne Schutzwirkung.
• Für Entscheidungen, die tatsächlich pro Änderungssatz getroffen werden sollen (dafür ist ein Token-basiertes Gate wie das Mass-Update-Gate das richtige Muster).

Was das Gate nicht abdeckt: Inhalt, der über einen Merge hereinkommt

Das Gate schützt den Push, nicht den Merge. Ein Setup, bei dem eine private Instanz Maschinerie von einem öffentlichen Upstream per git merge upstream/main zieht, hat ein eigenes, empirisch geprüftes Problem: Ein einfacher Merge übernimmt Upstream-Änderungen an bereits gelöschten Inhaltsseiten nicht sauber.

Gemessen an einem Wegwerf-Repo-Paar, bei dem der Upstream nach der einmaligen Löschung des Demo-Korpus eine Seite ändert, eine neue anlegt und eine dritte löscht:

• Eine geänderte Seite erzeugt einen modify/delete-Konflikt und lässt die Upstream-Fassung im Arbeitsbaum liegen - ein naives Auflösen mit git add -A holt sie zurück.
• Eine neu angelegte Seite wird stillschweigend übernommen, ohne Konflikt und ohne Meldung.
• Eine beidseitig gelöschte Seite verursacht nichts - der einzige Fall, der ohne Weiteres funktioniert.

Ein naheliegender Fix (.gitattributes mit merge=ours für die betroffenen Verzeichnisse) wurde ebenfalls gemessen und verworfen: Der Treiber wirkt nur bei Inhaltskonflikten auf beidseitig vorhandenen Dateien, nicht bei modify/delete-Paaren oder Neuanlagen.

Die funktionierende Prozedur hält den Merge mit --no-commit offen, erzwingt die Inhaltsverzeichnisse zurück auf den Stand vor dem Merge, solange HEAD noch dorthin zeigt, und prüft danach explizit (git diff --name-only $BEFORE HEAD -- kb raw muss leer sein) - eine Kontrolle, die nicht stillschweigend übersprungen werden kann, anders als eine bloße Behauptung im Text² . Details, ein getestetes Skript und zwei Architekturvorschläge (das Verfahren als wikitool-Kommando bauen, oder den Demo-Korpus grundsätzlich von dem Branch fernhalten, von dem private Instanzen ihre Maschinerie ziehen) stehen in Gitea-Issue #30.

Beziehungen

Siehe auch

• Source - Publish-Remote Gate and Issue Triage Session 2026-09-01
• Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01

Fußnoten

Beziehungen

• see-also: Mass-Update Gate
• operates-on: Chemenu
• see-also: MCP-Leseserver

---

1. Source - MCP Read Server Implementation Session 2026-09-02 ↩︎

2. Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01 ↩︎