ingest: Publish-Remote Gate and Issue Triage Session 2026-09-01

Files changed:
- kb/concepts/INDEX.md
- kb/concepts/Mass-Update Gate.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 - Publish-Remote Gate and Issue Triage Session 2026-09-01.md

kb/concepts/INDEX.md

@@ -2,7 +2,7 @@
 
 # kb/concepts/ - Index
 
-78 page(s). Regenerated by `wikitool index rebuild`.
+79 page(s). Regenerated by `wikitool index rebuild`.
 
 ## All
 
@@ -60,6 +60,7 @@
 | [[Personalization Plane]] | architecture | Schicht fuer Instanz-Identitaet: USER.md/SOUL.md werden als Template ausgeliefert, im Setup-Interview woertlich befuellt und vom doctor-Check auf fehlend wie unbefuellt geprueft | 2026-08-31 |
 | [[Privacy and Governance]] | workflow | Rahmenwerk zur Absicherung von Wiki-Inhalten über Datenfilterung beim Ingest, Audit-Trail-Protokollierung und umkehrbare Massenoperationen. | 2026-08-29 |
 | [[Procedural Memory]] | architecture | Langlebigste Speicherschicht für Abläufe, Muster, bewährte Vorgehensweisen und Rezepte, gewonnen aus wiederholten semantischen Beobachtungen. | 2026-08-29 |
+| [[Publish-Remote Gate]] | workflow | 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. | 2026-09-01 |
 | [[Quality and Self-Correction]] | workflow | Automatische Qualitätssicherung für Wikis mit Inhaltsbewertung, Selbstheilung und Widerspruchserkennung. | 2026-08-29 |
 | [[Quality Scoring]] | pattern | Quantitative Bewertung aller vom LLM geschriebenen Inhalte nach struktureller Qualität, Vollständigkeit der Quellenangaben, Konsistenz mit dem Wiki und Themenabdeckung. | 2026-08-29 |
 | [[RAG]] | architecture | Architekturmuster, bei dem LLMs die Generierung um Dokumente aus einer Wissensbasis anreichern. | 2026-08-29 |

kb/concepts/Mass-Update Gate.md

@@ -4,7 +4,7 @@ concept_type: workflow
 tags: [gate, safety, mass-update, confirmation]
 created: 2026-08-03
 modified: 2026-09-01
-related: [Content Quality Control, wikitool, Iteration and Cost Limits, Structural Enforcement over Documented Rule, Bulk Operations]
+related: [Content Quality Control, wikitool, Iteration and Cost Limits, Structural Enforcement over Documented Rule, Bulk Operations, Publish-Remote Gate]
 sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - LLM Improvements Codex Analysis]
 confidence: 0.88
 confidence_base: 0.88
@@ -77,6 +77,7 @@ Das Mass-Update Gate ist ein Sicherheitsmechanismus, der die Ausführung pausier
 - **wird gespiegelt durch:** [[Iteration and Cost Limits]]
 - **wendet an:** [[Structural Enforcement over Documented Rule]]
 - **grenzt ab gegen:** [[Bulk Operations]]
+- **verwandtes Gate:** [[Publish-Remote Gate]]
 
 ## Siehe auch
 
@@ -86,6 +87,7 @@ Das Mass-Update Gate ist ein Sicherheitsmechanismus, der die Ausführung pausier
 - [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
 - [[Structural Enforcement over Documented Rule]]
 - [[Bulk Operations]]
+- [[Publish-Remote Gate]]
 
 ## Fußnoten
 

kb/concepts/Publish-Remote Gate.md

@@ -0,0 +1,72 @@
+---
+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]]
+