torben/chemenu

Fork 0

Files

T

torben 18ae28f918

CI / verify (push) Failing after 32s

Details

Release / release (push) Successful in 38s

Details

Chemenu 2.1.0 - deterministischer Wissenskompiler

Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.

2026-09-01 16:26:14 +02:00

5.6 KiB

Raw Blame History

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type

concept_type

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¹.

Beziehungen

umgesetzt von: wikitool
verwendet von: Chemenu
verwandt mit: Optional Instance Context File

Siehe auch

Fußnoten

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

5.6 KiB Raw Blame History