chemenu/kb/concepts/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-01	Mass-Update Gate Chemenu	Source - Publish-Remote Gate and Issue Triage Session 2026-09-01	0.50	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; anders als die anderen Gates gibt es keinen Freigabe-Token.

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.

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).

Verwandte Concepts

• Mass-Update Gate

Beziehungen

• gilt fuer: Chemenu
• verwandtes Gate: Mass-Update Gate

Siehe auch

• Source - Publish-Remote Gate and Issue Triage Session 2026-09-01
• Chemenu
• Mass-Update Gate