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

---
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, Source - Private-Instance Merge Correction and Issue 30 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).

## 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[^s-private-instance-merge-correction-and-issue-30-session-2026-09-01]. 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.

## 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]]
- [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]

## Fußnoten

[^s-private-instance-merge-correction-and-issue-30-session-2026-09-01]: [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]