---
type: types/concept.md
concept_type: workflow
tags: []
created: 2026-09-01
modified: 2026-09-01
related: [Mass-Update Gate, Chemenu]
sources: [Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]
confidence: 0.50
confidence_base: 0.70
provenance: sourced
summary: '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]]