Brief Yourself 1.0.1｜Persönliche Kontextebene

Was macht Brief Yourself 1.0.1｜Persönliche Kontextebene?

Brief Yourself 1.0.1 ist das aktuelle Produkt, der Skill-Einstieg, die Agent-Identität und die aktive Schema-Identität. Die aktuelle schema_version ist 1.0.1; die historische Version 0.4 bleibt nur in alten Artefakten und historischen Anmerkungen erhalten und ist kein aktives Schema.

Auslösung und Positionierung

Verwende diesen Skill, wenn der Benutzer sich selbst kennenlernen, den Agenten besser über sich informieren, aktuelle Änderungen überprüfen oder in einer nachgelagerten Aufgabe kalibrierte persönliche Informationen nutzen möchte.

Brief Yourself ist eine vom Benutzer kalibrierte, zweckgebunden kompilierte und auf verschiedene Agent-Umgebungen übertragbare Persönliche Kontextebene. Der Personal Context Store (PCS) ist die kanonische Quelle des persönlichen Kontexts; die Context View (Kontextansicht) ist der eingefrorene Input für eine bestimmte Aufgabe; der Context Patch (Kontext-Patch) ist der kandierte Rückfluss, der dem Benutzer nach Aufgabenende zur Überprüfung vorgelegt wird.

Codex Memory, Rollout, Projektdokumentation und andere Umgebungsspeicher (Harness Memory) können nur nach expliziter Autorisierung als Kandidatenevidenz dienen. Sie können nicht automatisch importiert werden, den Store überschreiben, einen bestätigten Claim (Behauptung) darstellen oder eine kanonische Quelle werden. Brief Yourself repliziert keine Rollout-, Konsolidierungs-, Retrieval-, Thread- oder allgemeinen Memory-Injektionsprozesse.

Nicht-Ziele und harte Grenzen

• Kein generischer Geschichtsverlauf, keine Vektor-Suche, keine psychologische Diagnose oder Beurteilung der „wahren Persönlichkeit“.
• Kein Harness Memory wird zum Personal Context, auch keine stillschweigende bidirektionale Synchronisation; auto_import_harness_memory muss false sein.
• Die aktuelle Version 1.0.1 implementiert nur subject.type = person. Organisationskontext (Organization Context) reserviert nur über gemeinsame Envelopes eine Isolationsgrenze und wird in diesem Skill nicht als Team Context Store implementiert.
• Keine Nutzung von persönlichen Profilen für nicht autorisierte Beschäftigungs-, Kredit-, Versicherungs-, medizinische oder andere hochwirksame automatische Entscheidungen.
• Kein Lesen von echtem Personal Context, privaten Testdaten oder historischen Materialien, es sei denn, der Benutzer hat zuvor eine klare Quellenautorisierung für diese Runde erteilt.
• Persönliche Informationen werden als deklarative Claims (Behauptungen) geschrieben, nicht als Befehle, die zukünftige Anweisungen überschreiben; Prozess- und Betriebsregeln gehören zum Skill oder zur Projektdokumentation.

Sitzungsvertrag: Erst vereinbaren, dann erkunden

Wähle bei Erstellung oder Aktualisierung eines Profils zunächst Depth (Tiefe), Evidence (Evidenz) und Pace (Tempo). Präsentiere den vollständigen Sitzungsvertrag vor der ersten Erkundungsfrage und warte auf Annahme oder Anpassung durch den Benutzer; vor der Annahme dürfen keine Erfahrungen, Werturteile oder andere Erkundungsinhalte eingeholt werden.

Der Vertrag muss mindestens enthalten: Ziel; Depth, Evidence, Pace; abgedeckte und ausgeschlossene Dimensionen; maximale Prompts, Benutzerinteraktionen und voraussichtliche Dauer; zu lesende Quellen und deren Umfang; Liefergegenstand; ob der Personal Store archiviert und ob er nachgelagert separat gespeichert werden darf; Pfade zum Anhalten, Überspringen und Löschen. Sagt der Benutzer nur „Start“, werden die empfohlenen Werte verwendet. Die aktuelle Sitzung endet, wenn eine Obergrenze oder ein Abbruchkriterium erreicht ist; eine Fortsetzung der Erkundung erfordert einen neuen Vertrag.

Tiefe	Maximale Prompts	Benutzerinteraktionen	Voraussichtliche Dauer
Quick	5	2–3	5–10 Minuten
Standard (Standard)	8	3–4	15–25 Minuten
Deep	12	4–5	30–45 Minuten

History-assisted (verlaufsgestützt) ist nur ein Evidenz-Modifikator, muss alle Obergrenzen der gewählten Tiefe übernehmen und darf keine vierte Tiefe darstellen oder die Sitzung verlängern. Zeigt der Benutzer Ermüdung, fragt nach der Anzahl verbleibender Fragen, gibt zu lange Rückmeldung oder liegen bereits genügend Materialien für ein minimal ausreichendes Profil vor, stoppe sofort das Stellen neuer Fragen und fasse zusammen; setze die Befragung nicht fort, um ein Skript zu erfüllen.

Ablauf

1. Operation bestimmen. Wähle Erstellen/Aktualisieren eines Profils, Erzeugen einer Task View, Überprüfen eines Patches oder Inspect/Export; gib zuerst den Zweck und den minimal notwendigen Umfang an.
2. Leseberechtigung einholen (Autorisierungskarte). Vor dem Lesen von Verlauf, Projektdateien, Lebenslauf, öffentlichen Quellen oder Harness Memory zeige gemäß references/source-consent-and-disclosure.md Quelle, Umfang, Zweck, externe Übertragung, Speicherort und Löschmethode an und warte auf explizite Autorisierung. Die Autorisierungskarte ist die Zustimmungsschnittstelle vor dem Lesen und wird durch diese Referenzdatei bestimmt; sie ist etwas anderes als der Befehl register-source – register-source ist der langfristige Eintrag einer Quelle nach dem Lesen und der Genehmigung durch den Benutzer. Der aktuelle Dialog und die vom Benutzer bereitgestellten Materialien müssen ebenfalls den tatsächlichen Nutzungsumfang dokumentieren.
3. Bedarfsgerechte Evidenzerhebung. Nutze zuerst die aktuelle Antwort und die vom Benutzer bereitgestellten Materialien; die Historie wird nur bei bekannten Lücken nach Bedarf gelesen, nicht im Batch importiert. Inhalte aus dem Harness Memory bilden nur Kandidatenevidenz, müssen als zu kalibrierend markiert werden und können nicht direkt bestätigte Claims werden.
4. Interview und Kalibrierung. Steuere das Budget gemäß references/interview-and-calibration.md; beginne mit konkreten Erfahrungen, Entscheidungen und Verhaltensweisen, zeige phasenweise eine Kalibrierungskarte (Calibration Card) an und lasse den Benutzer bestätigen, umschreiben, ablehnen oder unentschieden lassen.
5. Flache Claim-Kandidaten bilden. Der Store hat nur ein claims[]; domains[] sind Labels, keine physische Hierarchie. Neue Erkenntnisse sind standardmäßig Domain-Kandidaten mit user_status: unreviewed und steigen nicht durch eine einzelne Sitzung in den Core (Kern) auf. Die Core Summary kann nur aus bestätigten, noch gültigen und szenarienübergreifend unterstützten Claims abgeleitet werden; sie wird nicht separat gespeichert.
6. Eingefrorene View erzeugen. Kompiliere die View zweckgebunden mit genauem Subjekt/Ausführer/Zielgruppe und minimal notwendigen Claims; das vollständige Objekt, source_revision, Erstellungszeitpunkt, TTL (Time-to-Live) und Berechtigungen werden zusammen eingefroren. Nachträgliche Änderungen im Store ändern bestehende Views nicht stillschweigend.
7. Patch nur stagen. Neue Erkenntnisse aus einer Aufgabe erzeugen nur einen pending Patch; Strategien und einmalige Formulierungen werden in task_strategies_not_for_merge abgelegt. Prüfe jeden Punkt gemäß references/context-view-and-patch.md; erst nach expliziter Genehmigung einer spezifischen patch_id und des Proposals durch den Benutzer darf die Runtime den Patch anwenden (apply).

Mindestregeln für Evidenz und Erkenntnisse

• fact (Tatsache), self_report (Selbstauskunft), observation (Beobachtung), inference (Schlussfolgerung) getrennt aufzeichnen; Schlussfolgerungen nicht in Fakten umschreiben.
• Evidenzquelle, Gegenbeweise, Anwendungsbereich, Änderungen, Widersprüche (Tension) und Unbekanntes (unknown) beibehalten; keine Aufzeichnung bedeutet nicht, dass nichts passiert ist.
• Tension und Unknown sind weiterhin erstklassige Entitäten des aktuellen kanonischen Stores und können als vollständig eingefrorene Objekte in die View aufgenommen werden; sie sind nicht dauerhaft sitzungsgebunden. Das aktuelle Patch-Schema/Runtime-Proposal unterstützt nur add, update, challenge, retire für Claims; es gibt keinen Eintrag zum Hinzufügen oder Aktualisieren von Tension/Unknown. Neuentdeckungen einer Sitzung können nur als „nicht persistierte Kandidaten“ ausgeliefert werden und warten auf eine zukünftige explizite Vereinbarung; sie dürfen nicht stillschweigend in den Store geschrieben, als Claims getarnt, in task_strategies_not_for_merge gesteckt oder als dauerhaft gespeichert deklariert werden. Bereits vorhandene Tension/Unknown im Store bleiben lesbar und können nach Bedarf in die View aufgenommen werden; zukünftige Schreibeinträge erfordern ein separates Schema/Runtime/Approval und werden in dieser Runde nicht implementiert.
• Verwende nicht MBTI, DISC oder eine einzelne Antwort als Ersatz für Evidenz; schreibe nicht den Fortschritt einer einzelnen Aufgabe, JD-Keywords, temporäre Strategien oder Operatorenpräferenzen des Agenten als langfristige Claims.
• Neue Erkenntnisse gelangen zuerst in die Kandidaten-Domäne; Core existiert nur als abgeleitete Zusammenfassungsqualifikation und kann nicht durch eine einzelne Aufgabe direkt aufsteigen. Langfristige Rückschreibungen erfolgen stets nach Benutzerprüfung.
• sensitivity (Sensitivität) beschreibt den Sensitivitätsgrad des Inhalts; disclosure (Offenlegung) beschreibt Zielgruppe, Zweck und Erlaubnis zur nachgelagerten Persistierung – beide können einander nicht ersetzen. Standardmäßig werden private und restricted ausgeschlossen.
• subject (Subjekt) ist fest auf person gesetzt. team-agent oder andere nicht explizit autorisierte Ausführer/Zielgruppen werden standardmäßig abgelehnt; keine Ableitung persönlicher Autorisierung aus „gleichem Arbeitsbereich“.

Runtime-Befehle

Die Runtime registriert 17 Operationsnamen: 14 formelle V0.4-Operationen werden wie unten in fünf Gruppen geroutet; 2 Migrationsbefehle werden nur in Migrationsszenarien verwendet; list ist ein Kompatibilitätsalias für list-patches, keine eigenständige Fähigkeit. Parameter richten sich stets nach --help; dieser Einstiegspunkt setzt keine noch nicht überprüften Flags voraus. Verwende diese Befehle nicht für die Migration des echten Stores oder Dogfooding, es sei denn, es liegt eine separate Autorisierung vor. Detaillierte Parameter und Nebenwirkungen finden sich in references/store-operations.md.

Store-Lebenszyklus

python scripts/context_store.py init --help
python scripts/context_store.py validate --store <store>
python scripts/context_store.py inspect --store <store>
python scripts/context_store.py derive-core-summary --help

init erstellt einen neuen Store; validate führt eine vollständige Validierung durch, ohne stille Reparaturen; inspect zeigt Revisionen, Zähler und ausstehende Patches an; derive-core-summary leitet nur aus qualifizierten bestätigten Claims eine nicht-kanonische Zusammenfassung ab.

Quellenregistrierung

python scripts/context_store.py register-source --help

register-source ist der einzige Schreibeintrag für Evidence Sources (Evidenzquellen); consent muss explicit sein. Dies ist nicht die Leseberechtigungsschnittstelle: Die Autorisierungskarte vor dem Lesen wird durch references/source-consent-and-disclosure.md bestimmt; erst nachdem der Benutzer das Lesen autorisiert und die langfristige Registrierung genehmigt hat, wird dieser Befehl ausgeführt.

View

python scripts/context_store.py create-view --help
python scripts/context_store.py validate-view --help

create-view kompiliert eine eingefrorene View; vertrauliche Bereiche und Einschränkungen werden in diesem Schritt durch Disclosure und Benutzergenehmigung festgelegt; validate-view führt nur eine Validierung durch (Ablauf, Zweck, Vertraulichkeitsstufe, Berechtigungsstruktur), modifiziert nichts und erstellt keine Einschränkungen. Nach der Erstellung erfolgt keine Aktualisierung.

Patch

python scripts/context_store.py stage-patch --help
python scripts/context_store.py list-patches --help
python scripts/context_store.py apply-patch --help
python scripts/context_store.py reject-patch --help

stage-patch schreibt nur pending; apply-patch erfordert gleichzeitig die spezifische Patch-Überprüfung, --approve und einen bestätigenden Akteur; reject-patch ändert den kanonischen Kontext nicht.

Export und Löschung

python scripts/context_store.py export --help
python scripts/context_store.py purge-plan --help
python scripts/context_store.py purge --help

export exportiert standardmäßig nur public. purge ist unwiderrufliches Vergessen: Führe zuerst purge-plan für eine Vorschau durch und erhalte --plan-token; zur Ausführung sind auch --confirmed-by und --approve erforderlich; bei jeder Store-Änderung nach der Vorschau wird das Token ungültig. Dieser Einstiegspunkt bietet keine ausführbaren Löscheispiele, die diese Einschränkungen umgehen; vollständige Grenzen finden sich in references/store-operations.md.

Historische Migrationsrouten (nur für Migrationsszenarien lesen)

python scripts/context_store.py migrate-v02 --help
python scripts/context_store.py preview-migrate-v03 --help

Diese beiden Befehle dienen ausschließlich der historischen Migration von V0.2→V0.3 und V0.3→1.0.1 und gehören nicht zu den regulären Aufgabenfähigkeiten; lies zuerst references/migration-v0.3-to-v1.0.1.md und verwende sie gemäß dessen Vorschau-, Prüf-, Speicher- und Rollback-Grenzen. migrate-v02 ändert den übergebenen Pfad und darf nur auf einer vom Benutzer erstellten expliziten Kopie ausgeführt werden; V0.3→1.0.1 erlaubt nur eine schreibgeschützte Vorschau.

C File Adapter: Nur eingefrorene Views empfangen

Das C-Paket scripts/adapters/codex_file_adapter.py ist ein unidirektionaler File Adapter. Er liest nur eine bereits generierte, eingefrorene View-JSON, validiert Envelope, TTL, Subjekt, Zweck, allowed_use und ob jeder enthaltene Claim gleichzeitig principal.id und jeden Empfänger in der audience[] autorisiert; bei Fehlschlag erfolgt Fail-Closed, ohne den abgelehnten persönlichen Text auszugeben. Er liest nicht den Personal Context Store, Codex Memory, Rollout oder Netzwerkressourcen und schreibt nichts zurück in den Store, Harness Memory oder einen anderen langfristigen Kontext; optionale Ausgaben können den Eingabe-View nicht überschreiben.

Die folgenden konzeptionellen Befehle wurden gemäß der tatsächlichen --help des C-Adapters überprüft. --expected-audience ist eine vom Aufrufer bereitgestellte wiederholbare Teilmengenbindung (repeatable subset binding): Jede erwartete type:id muss in der eingefrorenen view.audience vorhanden sein, aber der Aufrufer muss nicht die gesamte Audience aufzählen, daher ist es keine Gleichheits-/Vollständigkeitsbehauptung. Diese Aufruferbindung ändert die Sicherheitsinvariante nicht: Unabhängig davon, ob dieser Parameter übergeben wird, muss der Adapter weiterhin für jeden enthaltenen Claim prüfen, ob die Disclosure gleichzeitig principal.id, alle Empfänger-IDs in der View-Envelope-Audience und den Zweck abdeckt; die Teilmengenbindung kann die Disclosure nicht erweitern. --purpose-approved gibt lediglich an, dass dieser spezifische Zweck explizit genehmigt wurde:

python scripts/adapters/codex_file_adapter.py --view <view.json> --expected-purpose <purpose> --expected-task <task> --expected-principal-id <principal-id> --expected-audience type:id --allowed-use <allowed-use> --purpose-approved

Die Ausgabe des Adapters ist das als Markdown/JSON formatierte Ergebnis für die aktuelle Aufgabe, kein neuer Store, Memory oder Rückschreib-Zugangsdaten; nach Aufgabenende wird weiterhin nur ein pending Patch erzeugt. Die kompakte Markdown-Ausgabe behält dennoch für jeden Claim user_status, confidence, status, den anwendbaren scope, evidence_refs, counterevidence_refs und nicht-leere kritische Zeitfelder; sie zeigt nur die Quellen-ID an, ohne den Evidenztext, Notizen oder Quellen-Rohdaten zu erweitern. Nicht überprüfte Claims werden explizit als review=unreviewed / review=unresolved angezeigt und nicht zu unbedingt sicheren Tatsachen verdichtet. Store und Adapter teilen sich den store-losen View-Validierungskern aus scripts/view_validation.py; jeder fügt nur Store-Quellenreferenzen oder Aufruferbindungsprüfungen hinzu.

Referenz-Routing

Das offizielle Paket enthält nur die folgenden 7 Referenzdateien, jede von diesem Einstiegspunkt aus erreichbar; der Lesezeitpunkt ist wie folgt:

• references/interview-and-calibration.md: Vor Interviewbeginn lesen. Sitzungsvertrag, drei Budgetstufen, Fragebogen, Kalibrierungskarte, Ermüdungsstopp und Claim-Klassifizierung.
• references/source-consent-and-disclosure.md: Vor dem Lesen von Verlauf/Projekt/Lebenslauf/Harness Memory lesen. Die einzige aktuelle Quelle für Einwilligungs- und Offenlegungsfakten: Autorisierungskarte, Kandidatenevidenz, Sensitivität, Offenlegung, Personen/Team-Isolation und Hochrisikogrenzen. Die Autorisierungskarte gehört hierher, nicht zu register-source.
• references/context-view-and-patch.md: Beim Kompilieren einer View oder Überprüfen eines Patches lesen. Aktuelle Version von Kontext-Envelope, vollständig eingefrorenem Objekt, TTL, Offenlegungsabgleich, Patch-Staging und -Genehmigung.
• references/harness-boundaries.md: Bei Beteiligung von Harness-Memory-Grenzen oder File Adapter lesen. Grenzen zwischen Harness Memory, Personal Context und Task Context sowie die Envelope/Disclosure- und expected-audience-Bindungsregeln des File Adapters.
• references/personal-context-model.md: Bei Bedarf zur Bestätigung der Store-Struktursemantik lesen. Top-Level-Entitäten des Personal Context Store, Evidenzmodell, View/Patch-Rückflussgrenzen und Versionssemantik.
• references/store-operations.md: Vor Ausführung eines Runtime-Befehls lesen. Parameter, Nebenwirkungen, Dateisystemgrenzen, Purge-Grenzen und Wiederherstellungsmethoden aller 14 1.0.1-Operationen und 2 Migrationsbefehle.
• references/migration-v0.3-to-v1.0.1.md: Nur im historischen Migrationsszenario V0.3→1.0.1 lesen. Schreibgeschützte, reine Metadaten-Vorschau und no-chain-Migrationsroute; die alte Version 0.4 bleibt nur als historischer Input und alte Artefaktkennung erhalten.

Asset-Routing

Drei 1.0.1-Vorlagen paaren sich mit gleichnamigen Schemata; sie werden beim Erstellen oder Validieren der entsprechenden Objekte gelesen:

• assets/templates/personal-context-store-v1.0.1.json: Store-Strukturbasis, zusammen mit assets/schemas/personal-context-store-v1.0.1.schema.json; nach init bei manueller Erstellung oder Validierung des Stores konsultieren.
• assets/templates/context-view-v1.0.1.json: Basis der eingefrorenen View-Struktur, zusammen mit assets/schemas/context-view-v1.0.1.schema.json; beim Kompilieren oder Validieren einer View konsultieren.
• assets/templates/context-patch-v1.0.1.json: Patch-Strukturbasis, zusammen mit assets/schemas/context-patch-v1.0.1.schema.json; beim Stagen oder Überprüfen eines Patches konsultieren.

Historische V0.3-Vorlagen und alte Referenzen wurden aus dem offiziellen Paket verschoben und im Projektverzeichnis archive/1.0.1-moved-out/ gespeichert; alte 0.4-Artefakte sind nur in releases/ erhalten, sind kein Teil des aktuellen Protokolls und dürfen nicht in ein Release-ZIP zurückgelegt werden.

Lieferung und Abschluss

Liefert je nach Operation Human Brief, Kandidaten-Claims, Tension/Unknown, eingefrorene View oder ausstehenden Patch und listet Quellenumfang, nicht abgedeckte Punkte, Sensitivitätsgrenzen und für das nächste Mal zu überprüfende Fragen auf. Stelle am Ende klar: Dieses ist das bisherige Arbeitsprofil basierend auf den aktuell autorisierten Materialien; der Benutzer kann jeden Punkt korrigieren, die Nutzung einschränken, ablehnen oder löschen.