Kontext-Sets und Pins

Wenn ein Agent start_session aufruft, bekommt er nicht die ganze Wissensbasis, sondern den von dir kuratierten Startkontext. Der Bereich Agents → Context ist der Kontext-Builder dafür: Hier legst du genau fest, was der Agent zu Beginn sieht — welche Notizen immer geladen werden (Pins), welche wiederverwendbaren Bündel an einen Scope angehängt sind (Kontext-Sets) und welche Gedächtniskategorien stummgeschaltet sind. Tag-Pins und die Stummschaltung des Gedächtnisses sind file-first: Sie leben im Frontmatter der Notizen und überstehen ein erneutes Klonen des Repositorys. Kontext-Sets und Space-übergreifende Pins liegen in der Metadaten-Datenbank (ein bewusst in Kauf genommener Vorbehalt: Weder ein erneutes Klonen auf einen sauberen Host noch der Modus none bewahren sie).

Always-load-Pins

Ein Pin ist eine manuelle „Immer laden“-Markierung (Mitgliedschaft im Tag always-load, keine Reihenfolge). Pins wirken entlang zweier Achsen:

Persönlich — Notizen in deiner persönlichen Domäne landen in profile.alwaysLoad und werden bei jeder Session geladen.
Projekt — Notizen im Teilbaum eines markierten Projekts landen in project.alwaysLoad und werden geladen, wenn der Agent in diesem Projekt arbeitet (der project-Hinweis).

Ein Pin ist daran gebunden, wo die Notiz liegt: Eine Notiz in der persönlichen Domäne wird ins Profil gepinnt, eine Notiz im Teilbaum eines Projekts ins Projektbündel. Der Builder zeigt genau das, was der Agent tatsächlich laden wird — die Kuratierung auf dem Server und in der Vorschau läuft über denselben Code.

Kontext-Sets — Space-übergreifende Bündel

Der Tag always-load bindet einen Pin an einen einzelnen Space. Kontext-Sets heben diese Grenze auf: Ein Kontext-Set ist eine benannte, wiederverwendbare Sammlung von Notiz-Referenzen, die du an einen anderen Scope anhängen kannst.

Ein typisches Szenario: Du stellst aus Notizen im geteilten Space conventions ein Set „Frontend-Konventionen“ zusammen und hängen es an Projekte in einem anderen Space an. Jede Session dieser Projekte bekommt diese Notizen, und du pflegst das Set an einer einzigen Stelle — die Änderung wirkt überall.

Es gibt auch eine leichtere Variante — den Space-übergreifenden losen Pin: eine einzelne Notiz, direkt aus einem anderen Space in einen Scope gepinnt, ohne Set als Hülle. Der Tag always-load bleibt für Pins innerhalb desselben Space; Sets und lose Pins sind für den Space-übergreifenden Fall da. Alles koexistiert, dedupliziert wird über die Notiz-ID.

Besitz ≥ Anhängen

Ein Set lebt in seinem Heimat-Space, und die Mitgliedschaft dort gewährt Sichtbarkeit und Bearbeitungsrecht. Ein persönliches Set lässt sich nur an deine persönliche Domäne anhängen; ein geteiltes Set (aus einem geteilten Space) an deine persönliche Domäne oder an ein beliebiges Projekt. Ein persönliches Set an ein Projekt zu hängen, geht nicht — es würde den Kontext nur für dich laden.

Reihenfolge = Ladepriorität

Die Reihenfolge von Pins und Sets in der Liste bestimmst du selbst (Drag-and-drop), sie ist nicht abgeleitet. Sie legt die Priorität fest: Was weiter oben steht, wird zuerst geladen und als Letztes gekürzt, wenn du an das Token-Budget stößt. Pins und Sets teilen sich eine gemeinsame Rangliste (du kannst ein Set über einen Pin ziehen). Die gesamte Ladereihenfolge lautet Pins → Sets → Gedächtnis (Spezifisches wiegt schwerer als Allgemeines), danach wird der Überschuss auf das Budget des Scopes gekürzt.

Gedächtnis stummschalten (mute)

Das Agentengedächtnis wird standardmäßig in den Kontext geladen. Erzeugt eine Kategorie nur Rauschen, schalte sie gezielt stumm (mute). Die Stummschaltung entfernt dieses Gedächtnis aus allen Kanälen, über die es den Agenten von selbst erreicht, ohne ausdrückliche Anfrage:

aus dem persönlichen Profil, das direkt bei start_session geladen wird;
aus dem Zusammenbau des recall-Bündels;
aus dem Kategorien-Wörterbuch in start_session(project).knownValues.

Search sieht stummgeschaltetes Gedächtnis mit Absicht

search filtert stummgeschaltetes Gedächtnis nicht heraus: Es indexiert das Gedächtnis gerade für die Deduplizierung nach dem Prinzip „vor dem Schreiben suchen“. Sonst fände der Agent eine stummgeschaltete Kategorie nicht und würde ein Duplikat neu anlegen. Die Stummschaltung bringt den Auto-Kontext zum Schweigen, sie löscht nichts: Explizite Suche und Audit sehen weiterhin alles. Die Umkehrung ist Unmute auf derselben Achse.

Ein einziges Token-Budget

Über den Abschnitten des Builders sitzt eine einzige Ladeanzeige, die exakt dem Budget des aktuellen Scopes entspricht. Eine persönliche Antwort hat ein Budget (zuerst Pins, dann Gedächtnis); eine Projektantwort hat ihr eigenes Budget, in dem zuerst die Projekt-Pins kommen und der persönliche Hintergrund in den Rest passt. Das Geladene bleibt immer ≤ dem Budget, und das Kürzen ist Element für Element sichtbar. Das Projektgedächtnis wird nicht sofort geladen, sondern auf Anfrage nachgezogen; wird ein bestimmter Projektfakt immer gebraucht, pinn die Notiz.

Weiter

Retrieval-Audit — der Zwilling des Builders zur Laufzeit: was der Agent tatsächlich abruft.
Agentengedächtnis — wie das Gedächtnis aufgebaut ist, das du stummschaltest.
Agenten-Regeln — die andere Hälfte der Aufgabe: dafür sorgen, dass start_session überhaupt aufgerufen wird.
Intent-Tools — start_session und die übrigen Tools.