chemenu/kb/concepts/Personalization Plane.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	architecture		2026-08-31	2026-08-31	mechanism wikitool operates-on Chemenu see-also Optional Instance Context File	Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31	0.50	0.50	sourced	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

Personalization Plane

Typ: Architecture

Definition

Die Personalization Plane ist die Schicht eines verteilbaren Agenten-Stacks, die festhält, wer eine Instanz bedient und wie sie klingt - in USER.md und SOUL.md im Repo-Wurzelverzeichnis. Sie löst einen Zielkonflikt, der bei jeder verteilbaren Software mit persönlicher Konfiguration auftritt: die beiden Dateien sind Betriebsvoraussetzung und werden in jeder Sitzung gelesen, ihr Inhalt gehört aber genau einer Person und darf nicht in jede exportierte Kopie.

Die Auflösung ist nicht „ausliefern oder nicht", sondern eine Dreiteilung: die Distribution trägt USER.md.template und SOUL.md.template, die Installation befüllt sie im Interview, und ein Health-Check prüft beides. In Chemenu eingeführt mit Stack-Version 1.1.0.

Kernpunkte

• Template statt Inhalt. Ausgeliefert werden nur die .template-Dateien. Dass die befüllten Fassungen nicht mitgehen, ist keine zusätzliche Regel, sondern Folge der bestehenden Root-Allowlist in dist_cmd.py: kopiert wird, was dort namentlich steht.
• Sentinel statt Existenzprüfung. Jedes Template trägt eine Zeile mit dem Token wikitool:template-unfilled. Damit lässt sich „umbenannt" von „ausgefüllt" unterscheiden - eine reine Existenzprüfung würde eine Datei durchwinken, die vorhanden ist und nichts beantwortet.
• Interview statt Ableitung. Der Installationsschritt befragt den Nutzer entlang der Template-Abschnitte und schreibt die Antworten wörtlich mit. Zwei Angaben darf ein Agent nicht raten: den Persona-Namen und die Themen, die bewusst draußen bleiben.
• Keine neue Autorität. USER.md ist Kontext über den Nutzer, keine Instruktionsquelle; SOUL.md bestimmt nur Ton und Stimme und verliert gegen AGENTS.md, die Contracts, Gates und Schemas. Eine Nutzeraussage ist keine Quelle und wandert nie ohne den normalen Quelle/Provenance/Confidence-Prozess nach kb/.
• Durchsetzung über den Health-Check. wikitool doctor meldet personalization: FAIL bei fehlender Datei und bei einer, die noch den Sentinel trägt.
• Persona als Instanz-Eigenschaft. Die Persona von Chemenu heißt Thoth, passend zur ägyptischen Namensgebung des Stacks selbst. Der Name ist eine Nutzerentscheidung, keine Vorgabe des Stacks: das Template schlägt keinen vor.

Beispiele

• Chemenu - erste Instanz mit befüllter Personalization Plane, Persona Thoth
• wikitool - liefert die Templates über dist export aus und prüft sie über doctor
• AGENTS.md - Abschnitt „Personalization"; die Kontrollebene behält den Vorrang
• CLAUDE.md - importiert beide Dateien, damit sie unter Claude Code überhaupt geladen werden

Wann zu verwenden

Wenn eine Datei gleichzeitig Betriebsvoraussetzung und persönlicher Inhalt ist. Das Muster verlangt drei Dinge, die zusammengehören: ein ausgeliefertes Template, einen Installationsschritt, der es befüllt, und einen mechanischen Check, der beide Fehlerfälle trennt. Fehlt der Check, ist der Installationsschritt eine Bitte; fehlt das Template, muss die Installation die Struktur raten.

Der Ansatz ist zugleich das Gegenmodell zu einer Instanz-Aktion als Migration: eine offene Personalization ist keine Korpus-Änderung und gehört nicht in die Kette aus KB Migration, sondern in den Health-Check.

Wann NICHT zu verwenden

• Für Angaben, die eine Maschine ermitteln kann. Autor-Identität kommt aus git config, nicht aus einem Interview.
• Für Regeln. Wer Normatives in SOUL.md schreibt, erzeugt die zweite Kopie, die Invariante 8 verbietet; Regeln stehen in AGENTS.md und den Contracts.
• Für Wissen. Was der Nutzer im Interview sagt, ist Kontext, keine belegte Aussage - es begründet keinen Eintrag in kb/.
• Für harness-spezifische Dateien. Eine Instanz, die ein bestimmtes Harness nicht benutzt, braucht dessen Konfiguration nicht, und ein FAIL dafür wäre falsch.
• Für Angaben, deren Fehlen nur Zeit kostet. Wo ein FAIL unangemessen wäre, weil die Datei eine Sitzung beschleunigt statt sie zu ermöglichen, greift das schwächere Muster Optional Instance Context File¹ .

Verwandte Concepts

• KB Migration - Abgrenzung: dort Korpus-Form, hier Instanz-Zustand
• Optional Instance Context File - dasselbe Muster ohne Pflicht: dort meldet der Health-Check nur, hier scheitert er¹
• KB Stack Versioning - die Plane kam mit 1.1.0, ohne Kompatibilitätsbruch

Beziehungen

Siehe auch

• Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31

Fußnoten

Beziehungen

• mechanism: wikitool
• operates-on: Chemenu
• see-also: Optional Instance Context File

---

1. Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31 ↩︎