chemenu/kb/concepts/Personalization Plane.md

---
type: types/concept.md
concept_type: architecture
tags: []
created: 2026-08-31
modified: 2026-08-31
related:
  - mechanism: wikitool
  - operates-on: Chemenu
  - see-also: Optional Instance Context File
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
confidence: 0.50
confidence_base: 0.50
provenance: sourced
summary: '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]][^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31].

## 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[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
- [[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

[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]

<!-- wikitool:links -->
## Beziehungen

- **mechanism:** [[wikitool]]
- **operates-on:** [[Chemenu]]
- **see-also:** [[Optional Instance Context File]]
<!-- /wikitool:links -->