ingest: Private-Instance Merge Correction and Issue 30 Session 2026-09-01

Files changed:
- kb/concepts/Delete Rather Than Anonymize.md
- kb/concepts/Publish-Remote Gate.md
- kb/entities/projects/Chemenu.md
- kb/entities/tools/wikitool.md
- kb/index.md
- kb/log.md
- kb/provenance.md
- kb/sources/INDEX.md
- kb/sources/Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01.md

kb/concepts/Publish-Remote Gate.md

@@ -5,7 +5,7 @@ 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]
+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
@@ -55,6 +55,36 @@ Remote lokal konfiguriert ist.
 - 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]]
@@ -69,4 +99,8 @@ Remote lokal konfiguriert ist.
 - [[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]]