ctx.

Der eigentliche Auslöser für ctx: Claude-Instanzen verlieren und verzerren Wissen über Sessions hinweg. Verschärft wird das durch den Constitution-Filter, der bei jeder Übergabe das Wissen systematisch konservativer verschiebt — Information wird also nicht nur vergessen, sondern aktiv in eine Richtung gebogen. Hinzu kam die Context-Window-Knappheit: ursprünglich 256k Tokens, die durch MCPs und Skills fortlaufend angefressen wurden. ctx ist die Antwort auf beide Probleme zugleich — eine externe, verlässliche Wissensschicht, die nicht driftet.

GottZ hätte mit dem vorhandenen Setup einen Multi-GPU-Inference-Scaler, ein Agent-Framework oder eine Workflow-Plattform bauen können. Die bewusste Entscheidung war stattdessen, zuerst die Persistenz-Schicht zu bauen. Wörtlich: „weil ich erst das gehirn brauche, bevor ich irgendwas anderes implementiere … ohne zentrale steuerung von informationen ist kein anderes projekt sinnvoll umsetzbar. nicht mit meinen warnings und auch nicht mit meiner armada." Das W-System und das Armada-Pattern operieren beide auf über Zeit akkumulierten Erkenntnissen — ohne ein Gehirn, das diese Erkenntnisse hält, könnten sie nicht funktionieren. Persistenz war damit die Voraussetzung für alles Weitere, nicht ein nachgelagertes Feature.

Eine zentrale konzeptionelle Korrektur: Persistenz ist nicht bloß ein Workaround gegen knappe Context-Windows. Auch mit 1M-Token-Context bleibt ctx wertvoll — das Bild ist der „große Eimer mit Boden, der wertvoller wird je größer der Eimer ist". Je mehr Context zur Verfügung steht, desto mehr Wert entfaltet eine verlässliche Persistenz-Schicht, nicht weniger. Damit positioniert sich ctx als Multiplikator der Fähigkeiten eines LLM und nicht als Krücke, die mit besserer Hardware überflüssig würde.

Die technische Genese verlief in klar dokumentierten Stationen. (1) Erste Idee: n8n MCP in Claude einbinden, um Wissensblöcke mit pgvector abzulegen und auffindbar zu machen. (2) n8n MCP verworfen — „müll. zu bloated. du bekommst den gesamten input auch als output zurück. es redet zu viel." (3) n8n Webhooks als schlankere Alternative bei gleicher Grundidee. (4) API-Key als Auth-Layer ergänzt. (5) Bun/TypeScript-Standalone — „schnell wieder verworfen". (6) Nach dem Sprachvergleich der Wechsel auf einen Go-Monolith. Heute besteht das System aus zwei Binaries (ctx CLI + ctxd Daemon) unter MPL-2.0, mit Paketen wie auth, store, rrf, dream, digest und guard — die schlanke Konsequenz aus dieser Kette.

Das Ergebnis der neutralen Sprach-Evaluation war Go. Der eigentliche Portierungs-Aufwand war minimal: „der gesamte ctx rewrite von typescript mit n8n zu golang war ein one hour problem". Möglich war das, weil die fachliche Substanz (Datenmodell, pgvector-Retrieval, Auth) bereits durch die vorherigen Stationen geklärt war — der Rewrite musste nur noch eine erprobte Idee in eine bessere Sprache gießen. Aus diesem Schritt wurde der heutige Go-Monolith (Go 1.26 im Repo), der API, Guard, Dream, Digest und MCP in einem Binary bündelt.

Statt die Zielsprache aus Vertrautheit oder Bauchgefühl zu wählen, wurde eine Armada aus 92 Sub-Agenten aufgesetzt, um die Sprach-Kandidaten neutral gegeneinander zu evaluieren. Das Ergebnis war Go. Dieser Schritt ist beispielhaft für die gesamte Arbeitsweise des Projekts: nicht der Autor entscheidet auf Verdacht, sondern ein parallelisierter, strukturierter Apparat liefert ein neutrales Ergebnis, dem dann gefolgt wird. Die Armada als Evaluations-Werkzeug ist hier bereits im Kern angelegt, lange bevor sie zum festen Red/Blue-Team-Pattern wurde.

Das tragende Methodik-Prinzip hinter ctx und seiner Entstehung: „ich habe mir werkzeuge gebaut, die mein unwissen abdecken und neutrale ergebnisse liefern. der output spricht für sich." Wissenslücken werden nicht durch eigenes Lernen kompensiert — das ist zu langsam — sondern durch Werkzeuge, die strukturierten, neutralen Output erzeugen. Gepaart mit konsequenter Parallelisierung führt das zu enormer Geschwindigkeit: „in 20 minuten mehr bewegt als andere in 14 tagen". ctx selbst ist die erste und grundlegendste Inkarnation dieses Prinzips — das Werkzeug, das das Gedächtnis abdeckt.

Als Workflow-Framework diente bis Ende März 2026 GSD (glittercowboy's Repo). Anfang April 2026 wurde dieses abgelöst durch ein eigenes W-System mit 14 RLHF-Warnings und eine eigene Armada mit Red/Blue-Team-Struktur. Beide bauen direkt auf der Persistenz-Schicht auf: Das W-System steuert das Verhalten anhand akkumulierter Erkenntnisse, die Armada verifiziert adversarial gegen gespeichertes Wissen. Damit schließt sich der Bogen zur Grundentscheidung „Erst das Gehirn" — erst nachdem die Persistenz stand, entstanden die darauf angewiesenen Verhaltens- und Verifikations-Systeme.

Schon früh war die Stoßrichtung künftiger Versionen klar umrissen: „Das gehirn kann als v2 später noch viel tiefer erweitert werden." v2 bedeutet damit Vertiefung des Gehirns selbst — bessere Retrieval-, Synthese- und Persistenz-Fähigkeiten — und ausdrücklich nicht die horizontale Expansion in andere Werkzeug-Kategorien. Multi-GPU-Inference-Scaler und vollwertige Agent-Frameworks wurden bewusst auf v3+ verschoben. Die Reihenfolge der Genese (erst Gehirn, dann Verhalten/Verifikation darauf) setzt sich damit als Roadmap-Logik fort.

Die erste ctx-Idee lief auf n8n: zuerst als MCP-Server in Claude, dann — weil das MCP „müll, zu bloated“ war (es gab den gesamten Input als Output zurück und „redete zu viel“) — über schlankere n8n-Webhooks mit API-Key-Auth. Ein Bun/TypeScript-Standalone-Versuch wurde „schnell wieder verworfen“. Statt die Sprachwahl aus dem Bauch zu treffen, baute GottZ eine 92-Sub-Agent-Armada, die die Kandidaten neutral verglich — Methodik-Prinzip: „ich habe mir werkzeuge gebaut, die mein unwissen abdecken und neutrale ergebnisse liefern“. Ergebnis: Go. Der eigentliche Port war trivial — „der gesamte ctx rewrite von typescript mit n8n zu golang war ein one hour problem“. Heraus kam ein Single-Binary-Monolith (CLI ctx + Daemon ctxd) mit eigenem Inferenz-Client, eigenen Migrations (embed.FS) und LISTEN/NOTIFY-basierter Async-Verarbeitung.

Bis etwa April 2026 lief die gesamte Inferenz auf Ollama. Sie wurde durchgängig auf llama.cpp umgestellt (Image ghcr.io/ggml-org/llama.cpp:server) und Ollama komplett entfernt. Alle Backends sprechen seither das OpenAI-Wire-Protokoll, das Routing der Rollen (Chat, Synthese, Dream, Digest, Classify, Translate, Rerank, Embedding) läuft über die Tabelle context_backends. Ein zentraler Schritt war die Verlagerung des Embedding-Dienstes von der GPU auf einen CPU-basierten llama.cpp-Side-Container (llama-embed) am ctx-Host — das gibt VRAM frei für Chat/Rerank auf der RTX 6000, macht aber den Bulk-Embedding-Rebuild zum CPU-Engpass. Synthese/Dream laufen heute auf qwen3.6:27b (herbert-chat, @96k Context), Reranking auf bge-reranker-v2-m3 (herbert-rerank), Embedding auf qwen3-embedding-8b (1024d Matryoshka von nativ 4096d).

Das Retrieval begann als Weighted Sum — die scheiterte, weil ts_rank und Cosine-Similarität inkompatible Score-Verteilungen haben und sich nicht sinnvoll addieren lassen. Ersetzt wurde sie durch eine 3-Way-Hybrid-Fusion (Dense pgvector + Sparse tsvector + Trigram pg_trgm) auf Basis von Reciprocal Rank Fusion, die Ränge statt roher Scores kombiniert. Reife-Schritt war die Erweiterung auf die heutige 4-Way Weighted RRF (k=60): Semantic 0.45 + English FTS 0.25 + German FTS 0.20 + Trigram Title 0.10. Der vierte Kanal (German FTS, Gewicht 0.20) wurde ergänzt, nachdem der Bilingual Gap als 75% des Retrieval-Problems identifiziert war — deutsche Queries auf rein englischen Titeln lieferten faktisch null FTS-Treffer. Die gesamte Fusion läuft in EINER SQL-Transaktion über dieselben Tabellen, ohne Netzwerk-Hop zu einem externen Vektor-Store.

Lange hatte ctx KEINEN Cross-Encoder; Reranking war RRF allein. In Wave 2 (2026-06-08) kam bge-reranker-v2-m3 als lokaler llama.cpp-Sidecar (Port 8082) dazu, bewiesen per Live-A/B (5 Oberflächen-Queries) und 14-Agent-Review, der dabei zwei Scale-Bugs fing. Der eigentliche Lerngewinn kam aus Wave 3 (47 verifizierte Gold-Cases, sweep.py): Der Cross-Encoder hob das Recall-Ceiling NICHT (ein Reorderer kann nichts surfacen, was RRF nicht liefert) und war auf latentem Gold netto null-bis-negativ — er bewertet Oberflächen-Ähnlichkeit, das Gold belohnte aber latente Link-Relevanz. Hard-Coupling graph+ce war sogar destruktiv (R@10 0.571 statt 0.715 für graph allein), weil der CE die graph-injizierten latenten Nachbarn wieder herausrankt. Prod-Verdikt: graph default-ON, rerank default-OFF, bis echtes Oberflächen-Gold existiert; falls CE an, dann mit Blend bw=0.5 und nie als finaler Arbiter. Zwei Pipelines für zwei Query-Klassen statt eines Gewinners.

ctx war ursprünglich reines CLI + API. Das Web-Frontend entstand nach einem Masterplan mit 41 Wellen (G01–G41) entlang sechs Achsen: F1 Config-Kern, F2 Settings, F3 Backend-Pool + Trust, F4 SPA, F5 Graph und F6 Chat. Konkret lieferten die Wellen Dashboard/Settings, einen Chat-Client, eine Graph-Landkarte (Louvain-Cluster-Supergraph über die dream_links, v3.15.0) und einen Backend-Pool mit Vault-Editor (G32) für Provider-Failover. Nach Abschluss des 41-Wellen-Plans wurde die Block-Workbench (CRUD, v3.16.0) als erste Folge-Welle gebaut. Wichtig: Die Graph-Landkarte ist Overview-Visualisierung, NICHT Query-Traversierung — die Dream-Links werden @Query weiterhin nur als supersedes-Drop-Filter genutzt.

In v2.0.0 wurde das Scope-Modell von einem harten CHECK-Constraint-Enum (chk_scope, ursprünglich private/work/shared) auf ein generisches VARCHAR(50) generalisiert (Migration M044). Scopes sind seither konfigurierbare Strings statt fest verdrahteter Werte — die Voraussetzung dafür, dass Multi-Tenant (Modell C: Tenant/Scope/Block-Ebenen + Cross-Tenant-Grants) darüber gebaut werden kann. Diese Generalisierung ist Teil einer durchgehenden Linie „hardcoded Mechanismus → konfigurierbare Policy“: Die spätere Kern-Redesign-Entscheidung (block_role-Enum → dynamische Type-Configs, 2026-06-01) ist ausdrücklich „dieselbe Linie, eine Ebene tiefer“ — Mechanismus (Embedding, RRF, Guard, Dream) bleibt Code, Policy wird Daten.

Die Dream-Cross-Reference-Engine reifte primär über ihren LLM-Prompt. Pre-Reset (2026-04-20) lag die Accuracy bei raw_conf≥0.7 nur bei 53% (47% Fehlerquote): factual überbeansprucht, supersedes drastisch unterproduziert (13/1836), causal ohne Temporal-Check. Daraus wurde Prompt v3 (Session 24, 2026-04-23): topical-as-fallback-Default, supersedes VERY RARE, causal akzeptiert decision→implementation — 62.3% Accuracy auf den top-50 hardest cases (+19.7pp). Welle 46 (Session 38) drehte zusätzlich die supersedes-Konvention (src=old → src=newer) und brachte die supersedes-VALID-Rate von 0% auf 80%. Die spätere Inferenz-Reduktions-Erhebung (W49c) verwarf dann v6 UND v7: Prompt-Varianten heben zwar Real-Recall, kosten aber none-Präzision; produktions-gewichtet (echte Kandidaten-Sets sind 70–85% none) dominiert v5 (beste none-Präzision 0.776) — v5 ist produktions-optimal. minRawConfidence wurde auf 0.7 für alle Typen vereinheitlicht (qwen3.6 hat unkalibrierte Confidence).

ctx wurde durch Live-Tests auf dem echten Korpus geformt, nicht durch Annahmen. Verworfen wurde: n8n (zu bloated, redet zu viel); Q8_0/FP16 zugunsten von Q4_K_M (höhere Gewichtspräzision → mehr Paraphrasierung → Keyword-Coverage fällt von 94% auf 88%, schlechter für RAG); Modelle >9B für die Synthese (bis ~22B getestet, größere extrahieren nicht besser; qwen3.5:9b schlug auch Gemma-Kandidaten — Reasoning-Modi fressen das Token-Budget, Death Spiral bei nativem Thinking: 19.4x Token-Overhead); die Sampler Mirostat/tfs_z/typical_p; ein externer Vektor-Store (Qdrant/Weaviate/Milvus) — verworfen, weil das ACID-Transaktionen, JOINs/CTEs und Atomarität kostet und unter ~5M Vektoren keinen echten Performance-Vorteil bringt; JSONB temporal_coords (zugunsten der EAV context_temporal-Tabelle mit O(log n)); content_dates DATE[]; ein 5. RRF-Channel; SQL-Gravity-Functions; Cosine-Pre-Filter; Two-pass-Synthesis; der GSD-Planner. Weitere validierte Lehren: FTS-Monatsnamen hatten 75% False-Positive-Rate (entfernt, nur ISO+YYYY-MM); Embed-Prefix verursachte 18,6% Centroid-Shift (deaktiviert); Guard-Schwellen 0.95/0.85 hatten 80% FP (auf 0.98/0.92 angehoben); Agent-Claims sind zu ~1/8 sachlich falsch (immer gegen Code verifizieren).

Die PL/pgSQL-Funktion ctx_rrf (Migration 048_rrf_exclude_params.sql) berechnet pro Kandidat einen gewichteten RRF-Score über vier parallele CTEs: Semantic (pgvector HNSW Cosine auf halfvec(1024), Gewicht 0.45, LIMIT 75 Kandidaten), English FTS (ts_rank_cd auf ts_en, 0.25, LIMIT 100), German FTS (ts_de, 0.20, LIMIT 100) und Trigram-Title (pg_trgm similarity, 0.10, similarity>0.05, LIMIT 30). Die Fusion nutzt die klassische Formel 1.0/(60 + rank) je Kanal mit k=60, per FULL OUTER JOIN über alle vier Ergebnismengen. Jeder Term wird zusätzlich mit einem block_mass-Faktor (1/sqrt(Anzahl content_times), dämpft Mega-Blöcke) und einem block_role_factor (audit-trail-Damping) multipliziert. Gefiltert wird auf NOT is_archived, block_role != 'system-meta', scope = ANY(read_scopes) sowie optionale category/tags/exclude-Listen. Go ruft die Funktion mit genau einem SQL-Call (rrf.Search) auf und holt intern 200 Kandidaten, damit Gravity, Graph und Reranker auf breiter Basis re-sortieren können, bevor auf das User-Limit (1-20, default 5) gekürzt wird. Der 5. RRF-Kanal wurde in M020 entfernt (nie aus Go aktiviert).

Die vier Fusionsgewichte sind in Migration 048 fest verdrahtet: 0.45 Semantic, 0.25 English FTS, 0.20 German FTS, 0.10 Trigram-Title; die RRF-Konstante ist k=60. Die Konfidenz-Klassifikation läuft im Go-Layer (llm.ClassifyConfidence) gegen zwei Schwellen aus der Config-Registry (config.go): query.score_threshold default 0.001 und query.confident_threshold default 0.008. maxScore >= 0.008 ergibt 'confident', >= 0.001 ergibt 'low_confidence' (dann auf max. 2 Quellen begrenzt), darunter 'no_relevant_blocks_found'. Wichtig (verifiziert gegen config.go, korrigiert ein älteres Briefing): der untere Threshold ist 0.001, nicht 0.005 — er wurde in Welle 37 abgesenkt, weil der mass_factor im RRF-Score große Architektur-Blöcke unter 0.005 drückte und damit aus dem Synthesizer fielen. Eine Config-Validierung lehnt score_threshold > confident_threshold ab (macht low_confidence sonst unerreichbar).

Nach RRF und Gravity (und vor filterSuperseded) re-bewertet ein Cross-Encoder die Kandidaten. Dispatch erfolgt über die Backend-Routing-Tabelle: trägt ein Backend die rerank-Rolle, geht die Anfrage an den llama.cpp-Sidecar (rerank.Score spricht das Cohere-/Jina-Wire-Format /v1/rerank, Modell bge-reranker-v2-m3 auf CPU, bis zu MaxDocs=50 Kandidaten, je Doc Titel + bis 2048 Zeichen Content); fehlt die Rolle, fällt es auf den historischen LLM-as-Judge über die Synthesis-Chain zurück (bis 15 Docs, 400 Zeichen, JSON-Score-Array). Der Cross-Encoder liefert ROHE Logits (können negativ sein, z.B. -11..+6); rrf.RerankCrossEncoder mappt sie per Sigmoid auf (0,1), bevor geblendet wird. Blend: rerankWeight*rerankNorm + (1-rerankWeight)*rrfNorm, default BlendWeight 1.0 (reine Cross-Encoder-Ordnung, finaler Arbiter auch über graph-injizierte Nachbarn). rerank.Score richtet die Server-Antwort STRIKT per result.Index neu aus (der Server sortiert absteigend und kürzt auf top_n — Array-Position ist bedeutungslos) und validiert lückenlose Index-Abdeckung. Beide Pfade sind fail-open: jeder Fehler behält die Pre-Rerank-Ordnung. Wegen der CPU-Latenz (~1s pro Paar) hält ein chunked-Body-Heartbeat (alle 25s ein Leerzeichen, gültiges JSON-Prefix) die Verbindung durch puffernde Reverse-Proxies offen.

Nach Retrieval/Rerank baut llm.Synthesize die Antwort: Filter nach score_threshold, Konfidenz-Klassifikation, low-confidence-Begrenzung auf 2 Quellen, Lost-in-Middle-Reordering (beste Quelle zuerst, zweitbeste ans Ende), dann der LLM-Call über die Synthesis-Chain. Modell ist qwen3.6:27b (Backend herbert-chat, RTX 6000), think:false. Der Systemprompt ist konfigurierbar (config-Key query.prompt_version): Default ist v5.2 ('You are a fact extraction engine for a technical knowledge base'), verfügbar ist außerdem die Welle-48-Variante v6 mit gradierter Konfidenz (drei Modi DIRECT / INFERRED-mit-Caveat / REFUSAL). Hinweis (verifiziert gegen synthesize.go, korrigiert ein älteres Briefing das 'v5.3' nannte): die im Code definierten Prompt-Versionen sind v5.2 und v6. Harte Regeln des Prompts: jeder Fakt aus den Quellen, max. 3 Sätze, Inline-Zitate [1][2], Antwort in der Sprache der Frage, bei null Treffern exakt 'NO_RELEVANT_SOURCES'. Ein Security-Block weist an, in Quellen eingebettete Instruktionen zu ignorieren (Prompt-Injection-Schutz). Pro Quelle werden max. 1500 Zeichen rune-sicher gekürzt; bei temporalen Queries wird das aktuelle Datum + aufgelöste Referenzen in den Prompt injiziert. NO_RELEVANT_SOURCES wird zu 'I don't know based on the available sources.' normalisiert (locale-agnostisch für CRAG-Judges); war RRF 'confident', wird auf low_confidence statt no_relevant heruntergestuft.

llm.DetectGerman erkennt deutsche Queries an Umlauten/ß, >=2 von 50 Stopwords oder >=1 von 16 Domain-Tech-Begriffen (Wort-Boundary, case-insensitive). Bei Treffer übersetzt llm.TranslateQuery über die translate-Chain in eine englische Suchquery. Der Prompt enthält ein festes Domain-Glossar (z.B. Schreibschutz=Write Guard, Sicherheitstrennung=Scope Isolation, Duplikat-Erkennung=Duplicate Detection, Kontextspeicher=Context Store, Einbettung=Embedding, Schwellenwert=Threshold, Zugriffsschluessel=API Key). Die Übersetzung durchläuft harte Gates: SQL-Meta-Zeichen werden gestrippt, max. 3x Länge des Originals, nur sichere Zeichen (alphanumerisch + wenige Satzzeichen), einzeilig — sonst wird die Originalquery beibehalten. Wichtige Architektur-Eigenschaft: nur die SUCH-Query wird übersetzt; die LLM-Synthese bekommt die ORIGINALE (deutsche) Query, damit die Antwort in der Nutzersprache erfolgt. Der gesamte Schritt ist fail-open (leere/erschöpfte Chain → Originalquery).

Die Temporal-Auflösung ist primär deterministisch: llm.NormalizeTemporalRules (temporal_rules.go) läuft ohne LLM-Call. Es gibt exakt 18 match*-Funktionen (per grep verifiziert), abgearbeitet in einer Prioritäts-Kaskade von spezifisch zu vage: P1 ISO-Daten (rein linear) → P2 Compound-Ranges (von-bis, linear+weekday) → P3 Seit/Bis (linear+month) → P4 Wochen-Segmente → P5 relative Wochen → P6 relative Monate → P7 Weekday in einer Woche → P8 relative Tage (vor/in N Tagen, rein linear) → P8a Jahres-Feiertage (month+seasonal) → P8b Monats-Segmente (Monatsanfang/-ende, monthday) → P8c Tageszeit (morgens/abends, daily) → P9 Wochenende (weekday-dominant) → P10 Multi-Keyword (heute und morgen) → P11 Weekday + Verb-Tempus → P12 simple Keywords inkl. Tippfehler. Hilfsfunktionen: DetectVerbTense/hasPerfektForm (Vergangenheit→LAST, Zukunft→NEXT), hasRecurrence ('immer/jeden/dienstags' upgradet zu purer Weekday-Gewichtung), Levenshtein-Fuzzy für Tippfehler. Erst wenn die Regeln nil liefern UND HasTemporalIntent (Whole-Token-Match gegen ~70 Intent-Wörter + ISO-Regex) true ist, greift der LLM-Fallback (NormalizeTemporal über die translate-Rolle, Kalender mit expliziter LAST/NEXT-Tabelle, damit das Modell nur nachschlägt statt zu rechnen).

Aufgelöste Daten werden via TemporalToFTSExpansion in einen websearch_to_tsquery-OR-String übersetzt, der als zusätzlicher FTS-Kanal in ctx_rrf einfließt. Bewusst eng gehalten: nur ISO-Daten (2026-03-23) und YYYY-MM-Präfixe (2026-03). Wochentagsnamen, Monatsnamen und KW-Nummern wurden entfernt — empirischer Befund T07 (Session 22): sie verursachten 75% False-Positive-Rate in den Top-5, weil sie jeden Block matchen, der das Wort zufällig erwähnt, statt temporal verwandte Blöcke. Skalierungs-Caps für 1M+ Blöcke: max. 7 eindeutige Daten bekommen Per-Tag-Expansion (sonst erste + letzte Hälfte), Gesamt-Cap 20 OR-Terme (GIN-Kosten skalieren linear mit Term-Zahl × 2 FTS-Kanäle). Die eigentliche temporale Relevanz läuft NICHT über FTS, sondern Post-RRF über Gravity-Boost und die context_temporal-Dimension-Table. Auch der Embed-Prefix für temporale Augmentation ist deaktiviert (T06: verschlechtert 4/5 Queries, ~33% Centroid-Shift).

Das Cyclic Phase Model (gravity.go) behandelt jede zyklische Zeitstruktur als unabhängige Dimension mit normalisierter Phase [0,1) und eigenem Gaussian-Decay-Sigma: weekday σ=0.07 (7d-Zyklus), month σ=0.10 (12-Monats-Zyklus), quarter σ=0.12 (4 Quartale, breiter weil unpräzise), week σ=0.08 (52-Wochen-ISO), monthday σ=0.10 (~30-Tage Monatsanfang/-ende), seasonal σ=0.08 (365-Tage), daily σ=0.08 (24h Tageszeit). Year bleibt linear-monoton (nicht zyklisch). Der Parser setzt pro Matcher DimensionWeights (Beispiele aus dem Code: 'am 2026-03-27' → {linear:1.0}, 'am Dienstag' → {linear:0.6, weekday:0.4}, 'immer dienstags' → {weekday:1.0}, 'Q1 Reviews' → {quarter:1.0}, 'im März' → {linear:0.5, month:0.5}). ComputeCyclicGravity berechnet je Dimension die CyclicDistance zwischen Query-Phase und Block-Phase, wendet GaussianDecay = exp(-d²/(2σ²)) an und nimmt das Maximum über alle Anker eines Blocks (best match, nicht Summe), dann gewichtete Summe über Dimensionen. Beispiel σ=0.07: Montag→Dienstag (Distanz 1/7) decays auf ~0.13, Montag→Mittwoch (2/7) auf ~1e-4 (effektiv null). Der Boost ist multiplikativ und auf max. 0.30 (30% Score-Anhebung) gedeckelt, skaliert mit der Summe der zyklischen Gewichte; Blöcke ohne passende Dimension bekommen Faktor 1.0 (neutral, keine Strafe).

Der lineare Gravity-Pfad (ComputeGravity/ApplyGravityBoost) behandelt Blöcke als Massen im Zeit-Raum: gravity = Σ 1/dist^power über die content_times relativ zum Query-Zieldatum, Basis-Power p=1.5, min. Distanz 0.5 Tage gegen Singularität. Die Gravitation ist asymmetrisch: zukünftige Daten bekommen einen 1.2× schärferen Cutoff, vergangene ein 'Forward Telescoping' — der Backward-Power wird per 1/(1+0.3·ln(1+age/30)) abgesenkt, sodass ältere Blöcke einen breiteren Gravitations-Brunnen erhalten (kalibriert an Rubin & Baddeley 1989: ältere Erinnerungen sind gröber; age=30d→power≈1.24, age=365d→power≈0.86). Cutoff default 14 Tage (60 bei Ranges), Direction-Filter (past/future/both), Boost gedeckelt auf 0.30. Die GottZ Temporal Dimension Table (context_temporal, Migration 009) ist eine EAV-Tabelle (block_id, source_date, dimension, value) mit partiellen B-Tree-Indizes je Dimension (year/month/week/weekday/quarter) für O(log n)-Filterung — neue Dimensionen ohne Schemaänderung. Der Handler holt für zyklische Queries die Dimensionen per FetchBlockDimensions, für lineare die content_times per FetchContentTimes; gemischte Gewichte ('am Dienstag') laufen beide Pfade, jeweils mit ihrem Gewicht skaliert, sodass der Gesamt-Boost ≤0.30 bleibt.

Vor dem Kürzen auf das User-Limit reichert der Handler die Ergebnisse mit der dream.SupersedesMap an (Key = veralteter Block, Value = neuere Superseder-IDs; Konvention seit Welle 46). filterSuperseded entfernt einen superseded Block NUR, wenn mindestens einer seiner Superseder ebenfalls im Resultset präsent ist (Sicherheitsregel — sonst bliebe die aktuelle Info ganz aus). Entscheidend ist das Temporal-Gate: der Filter läuft ausschließlich für nicht-temporale Queries (temporalResult == nil oder keine Dates) — temporale Queries brauchen explizit historische/veraltete Blöcke und dürfen ihren Verlauf nicht verlieren. Die RRF-Score-Ordnung bleibt erhalten. Im API-Response trägt jede Quelle optional ein superseded_by-Feld. Architektonische Grenze (ehrlich dokumentiert): die Dream-Links werden @Query NICHT traversiert — der Graph dient hier nur als Supersedes-Drop-Filter; die optionale Graph-Expansion (1-Hop entlang positiver Dream-Links, Post-RRF/pre-Rerank) ist ein separates, default-OFF gegatetes Feature.

Dream Mode ist die Komponente, die den Wissensgraphen ohne menschliches Zutun verdichtet: Ein Scheduler-Worker (Parallelität 1) zieht einen Block aus dem Korpus und sucht nach verwandten Blöcken, die ein Mensch beim Speichern nie explizit verlinkt hätte — die LATENTEN Querverbindungen. Die Pipeline läuft in acht Schritten (definiert in go/internal/dream/dream.go): Step 0 Cycle-Skip (übersprungen, wenn kein Backend die Rolle bedient), Step 1 Block-Pick (unchecked zuerst, dann ältester mit abgelaufenem Cooldown via FOR UPDATE SKIP LOCKED), Step 1b temporale Dimensions-Validierung, Step 2 LLM-Keyword-Extraktion (max. 5, pro Block persistiert und wiederverwendet), Step 3 RRF-Suche pro Keyword, Step 4 LLM-Evaluation der Kandidaten, Step 5 Write-Links, Step 5b Recurrent-Erkennung, Step 6 Quality-Score-Update, Step 7 adaptiver Cooldown, Step 8 Promotion zu Canonical. Die Pipeline-Generation ist Version=5 (Welle 38b, 2026-05-06) und wird mit jedem Link persistiert. Cooldowns sind adaptiv: 3 Tage für Blöcke, die Links produziert haben (CooldownActiveDays), 14 Tage für Blöcke ohne Links (CooldownInertDays), 5 Minuten bei transienten Systemfehlern wie LLM-Timeouts (CooldownTransientMinutes). Im Leerlauf wartet der Worker 20s (CTX_DREAM_IDLE_WAIT, hot-mutable). Ein Throttle-Mechanismus erzwingt GPU-Cooldown-Pausen zwischen den LLM-Calls (on/throttled/off via API + CLI).

Der Graph kennt fünf Kantentypen (validRelationships in linkfilters.go): supersedes (Quelle korrigiert/ersetzt einen konkreten Fakt im Ziel — VERY RARE), causal (Quelle beschreibt ein Ereignis/eine Entscheidung, deren Eintreten das Ziel ermöglichte; Entscheidung→Implementierung qualifiziert), factual (Quelle SPEZIFIZIERT eine konkrete Sache, die das Ziel implementiert — Einbahn SPEC→IMPL), topical (beide behandeln dasselbe Thema substantiell — der dokumentierte Fallback) und recurrent. Der LLM-Evaluation-Prompt (dreamSystemPrompt in evaluate.go) klassifiziert nur die ersten VIER; recurrent wird separat in einem Phase-1-Pass (gleiche Dimension+Wert in context_temporal UND Titel-Ähnlichkeit > 0.5) plus Phase-2-LLM-Bestätigung erkannt, der nach dem Haupt-Evaluate läuft, sodass recurrent über topical gewinnt. Der Prompt setzt explizit 'topical-as-fallback' als Default. Auf dem top-50-hardest-Benchmark gegen Double-Judge-Stable-Gold erreichte er 62,3% Accuracy (+19,7pp gegenüber Pre-Reset-Baseline 42,6%). Ausgegeben wird ein JSON-Array {target_id, type, confidence}, maximal 5 Einträge. Der Versuch eines V6-Prompts (causal anti-pattern clauses) wurde verworfen: Stable-Gold n=122 zeigte V6 net-worse (54,1% vs 57,4%), Topical-Recall fiel von 76% auf 63% durch Over-Hedging zu 'none'.

Jeder Kantentyp hat einen minimalen rohen (ungewichteten) LLM-Confidence-Floor (minRawConfidence): topical, factual, causal und supersedes liegen bei 0.7, recurrent eine Quantisierungsstufe höher bei 0.8 (Welle 38b — Phase-2-Klassifikation hat mehr Fehlermodi). Der einheitliche 0.7-Floor löste den alten factual=0.9-Gate ab: qwen3.6:27b produziert unkalibrierte Confidence (full_agree-Mean 0.87 vs wrong_type-Mean 0.85 — Gap nur 0.02), weshalb das 0.9-Gate ein Legacy-Workaround für qwen3.5 war und auf 3.6 nur 2 korrekte Links wegfilterte ohne falsche Typen zu entfernen. EvaluateRelationships erzwingt nach der Confidence-Filterung einen Hard-Cap (MaxLinksPerCycle=5), sortiert nach Confidence absteigend mit Typ-Diversitäts-Tie-Break. Die Evaluation läuft über das Backend mit RoleDream (qwen3.6:27b, non-thinking), mit den vom Vendor empfohlenen Sampler-Settings Temperature 0.7, TopP 0.8, TopK 20, NumPredict 400. Der HTTP-Timeout pro Dream-Call ist 180s (DreamTimeout, empirisch aus 5878 Prod-Calls getunt: p50=23s, p90=30s, p99=156s), der gesamte Cycle-Timeout 700s.

Supersedes ist der gefährlichste Kantentyp (er markiert das Ziel als Snapshot und beeinflusst Retrieval-Filterung), daher gibt es ein mehrstufiges strukturelles Sicherheitsnetz in Go zusätzlich zum LLM-Urteil. enforceSupersedesDirection läuft als Post-Parse-Hard-Constraint (in evaluate.go nach parseLinks, vor filterValidCandidates): Für jeden supersedes-Link muss der Source-Zeitstempel strikt nach dem Target-Zeitstempel liegen; ist die Richtung invertiert, wird der Link zu 'topical' DOWNGRADED statt verworfen (erhält die topische Verbindung). acceptSupersedes (V8, linkfilters.go) prüft beim Schreiben drei Bedingungen: gleiche Kategorie (srcCat == tgtCat), Quelle echt neuer (srcCreated.After(tgtCreated)) und Titel-Ähnlichkeit via pg_trgm ≥ supersedesTitleSimThreshold=0.25. ApplySupersedes (Markierung des Ziels als Snapshot) feuert nur bei gewichteter Confidence ≥0.7. Hintergrund (Welle 46, 2026-05-22): Ein Audit fand ALLE 15 Supersedes-Links in Produktion relativ zur natürlichsprachlichen Semantik invertiert ('A supersedes B' → A ist die neuere autoritative Version). Die Konvention wurde von updated_at auf created_at und die Richtung von 'source älter' auf 'source neuer' umgestellt; Migration 042 truncate context_dream_links und ein Re-Dream-Pass schrieb den Korpus neu.

Der Guard verhindert, dass der Store mit Near-Duplicates zumüllt. Bei jedem Schreibvorgang prüft die PG-Funktion ctx_guard_check (Migration 011) per HNSW-Index den Top-1-nächsten Nachbarn über halfvec(1024)-Cosine-Distanz (cb.embedding::halfvec(1024) <=> v_embedding::halfvec(1024)), exklusive self, archivierte und chunk-Blöcke. Die Schwellen: Ähnlichkeit ≥0.98 → decision 'near_duplicate' → Auto-Archiv (is_archived=true, guard_status='archived_dup'); 0.92–0.98 → 'needs_review' (markiert, aber sichtbar); <0.92 → 'clean'. Diese Schwellen wurden empirisch von 0.95/0.85 angehoben, weil die niedrigeren Werte 80% False-Positive-Rate hatten. Cross-Scope-Status wird gesetzt, wenn der Match in einem anderen Scope liegt und nicht 'shared' ist. RunGuardBatch verarbeitet pending Blöcke (NOT is_archived, kein guard_checked_at, category != 'index', embedding IS NOT NULL, block_type knowledge/source) per FOR UPDATE SKIP LOCKED, damit konkurrierende Guard-Läufe nicht denselben Block greifen. Jeder Block läuft in einem eigenen SAVEPOINT (W47-02 Tx-Abort-Kaskade-Fix): Ein fehlgeschlagener Block (SQL-Fehler) wird auf seinen Savepoint zurückgerollt, ohne die umgebende Transaktion zu vergiften (PG 25P02), und die Schleife fährt fort. Jede Entscheidung schreibt einen Audit-Eintrag in context_write_log.

Der Guard läuft nicht stumpf im Poll-Takt, sondern reagiert ereignisgesteuert. Der DB-Trigger trg_block_write feuert bei jedem Block-Schreibvorgang ein PostgreSQL NOTIFY auf dem Kanal ctx_block_write (channelBlockWrite in events/listener.go). Ein pgxlisten-Listener empfängt die Notification und ruft scheduler.NotifyWrite() auf, was den Guard-Lauf unmittelbar anstößt. Als Fallback läuft zusätzlich ein Zeit-Ticker mit guardInterval = 60s (events/scheduler.go), falls Notifications verpasst werden. Bei Reconnect nach Verbindungsverlust signalisiert HandleBacklog bedingungslos Guard+Digest, um während der Trennung verpasste Writes nachzuholen (defaultReconnectDelay 5s). Derselbe Listener-Mechanismus bedient auch den Kanal ctx_settings_write (für Hot-Reload von Settings/Secrets/Backends per psql oder Break-Glass-Edit). Diese Architektur (LISTEN/NOTIFY + SKIP LOCKED + eigene Migrations via embed.FS) ist ein zentrales Design-Prinzip: kein externer Message-Broker, alles in PostgreSQL.

Die Embedding-Schicht (go/internal/embed/embed.go) erzeugt die semantischen Vektoren für Retrieval und Guard. Modell ist qwen3-embedding-8b, das nativ 4096-dimensionale Vektoren liefert, die per Matryoshka-Representation-Learning auf TargetDims=1024 truncated werden — die ersten 1024 Dimensionen tragen den Großteil der Information. Danach folgt L2-Normalisierung und ein Quality-Gate: Die Norm muss in [0.99, 1.01] liegen (minNorm/maxNorm) und die Varianz über minVariance=0.0001 (fängt degenerierte/konstante Vektoren ab). Asymmetrische Instruction-Prefixe trennen Query von Dokument (PrefixQuery: 'Instruct: Represent the query for retrieving relevant documents', PrefixDocument: 'Represent the document for retrieval'). Der Client unterstützt zwei Wire-Protokolle: ollama (/api/embed) und openai (/v1/embeddings) — Host und Protokoll kommen als ein backends.Backend-Tupel, sodass der Wire-Pfad nie vom konfigurierten Host divergieren kann. Es gibt keinen künstlichen Request-Timeout mehr (Latenz ist datenabhängig bei geteilter GPU unter Parallelität); der Parent-Context liefert den echten Timeout. Im aktuellen Stack läuft Embedding als Backend 'llama-embed' (Docker, CPU-only am ctx-Host, physisch getrennt von der GPU) — damit ist CPU-Embedding der Durchsatz-Engpass bei Bulk-Rebuilds, nicht die Live-Query-Latenz.

Embeddings werden nicht synchron beim Schreiben erzeugt (das würde den Write-Path blockieren), sondern asynchron nachgezogen. Auf dem Write-Path wird ein Block ohne Embedding gespeichert; der Scheduler-Backfill generiert es dann offline. Zusätzlich gibt es einen inline-Backfill direkt im Query-Pfad: backfillPending (handler/query.go) erzeugt Embeddings für Blöcke, die noch keines haben, BEVOR gesucht wird — im Normalfall ein No-Op (0 Blöcke), aber es garantiert, dass kein frisch geschriebener Block aus dem Retrieval fällt. Jeder Backfill-Wire-Call wird über logEmbedWire mit Pipeline 'embed-backfill' protokolliert. ClearEmbedding (store/blocks.go) setzt das Embedding auf NULL, sodass der Scheduler-Backfill es bei Bedarf (z.B. Modellwechsel) neu generiert. Eine geplante Erweiterung (T35b) schreibt embed_model-Provenance an drei Schreibpfaden (blocks.go, scheduler.go, query.go) plus einmaligem Backfill — Voraussetzung für späteren selektiven Rebuild und Kosten-Attribution per api_key_id.

Eine Live-DB-Messung (ctx-Block 019ed21c) ergab: context_blocks.embedding hat attstorage='e' (EXTERNAL) — der Vektor liegt OUT-OF-LINE in der TOAST-Tabelle, NICHT inline im Heap. Ein Metadaten-UPDATE schreibt das externe TOAST-Tupel nicht neu (geteilter Pointer), der Heap bläht durch Block-Updates also nicht mit dem Embedding mit. Schluss: Eine separate Embedding-Tabelle aus reinen Performance-/Fragmentierungsgründen ist YAGNI — TOAST macht den Heap/Vektor-Split bereits. Die richtige FORM für eine separate Tabelle ist hingegen Multi-Vektorraum (verschiedene Generationen, per-Tenant-Modelle, Blue-Green-Rebuild): context_block_embeddings(block_id FK, generation, embedding, PK(block_id,generation)). Diese deckt sich exakt mit der Multi-Tenant-Entscheidung OD-1 (CoW-Embedding, Block 019ed02c): eine geteilte Embedding-Generation als hartes Default (Ghost vom Pool/Parent), Divergenz (anderes Modell/Dimension) materialisiert lazy in separate Ablage, mit Refcount-GC. Ein externer Vektor-Store (Qdrant/Milvus) wurde bewusst verworfen — der Kern-Wert von ctx ist die Hybrid-Fusion (RRF + FTS + Graph dream_links + temporale Gravitation + Scope-Isolation) in EINER SQL-Transaktion; ein externer Store wäre ein Netzwerk-Hop plus Konsistenz-Sync. pgvector ist bei 1M Blöcken gebencht. Bau-Trigger ist datengetrieben: erster inkompatibler Tenant ODER gemessener HNSW-Recall-Druck bei wachsendem N.

Jeder API-Key wird als SHA-256-Hash (via pgcrypto) in context_api_keys gespeichert — Klartext-Keys verlassen die Tabelle nie. Die Authentifizierung läuft über die PG-Funktion ctx_auth($key), die im Live-System sechs Spalten zurückgibt: api_key_id, home_scope, allowed_scopes, read_scopes, is_valid und is_admin. Der home_scope (z. B. private oder work) ist der einzige Scope, in den ein Key schreiben und aus dem er löschen darf; read_scopes = [home_scope] + allowed_scopes bestimmt, was er lesend sieht. Element [0] der read_scopes ist invariant der home_scope — diese Reihenfolge ist wire-tragend (whoami, chat_sessions-Snapshot). Live existieren drei Scopes: private (890 Blöcke), shared (21) und work (3); ein typischer Key wie GottZ Private hat home_scope=private und allowed_scopes={shared,work}. Das Modell ist fail-closed: ein ungültiger oder leerer Key liefert is_valid=false ohne Existenz-Orakel.

Über den Scope-Lesefilter liegt ein separater Admin-Tier: das is_admin-Bit auf dem API-Key (eingeführt mit Migration 052). Die RequireAdmin-Middleware sitzt hinter der Auth-Middleware und gatet die sensiblen Routen — /api/settings (Runtime-Overrides), /api/secrets (versiegelte Credentials), /api/status, /api/llmlog und /api/events. Nicht-Admin oder fehlender Auth-Kontext ergibt 403. Der Admin-Tier ist bewusst getrennt vom Scope: ein Key kann admin sein, unabhängig davon, in welchem Scope er liest und schreibt. Live tragen mehrere Keys das Bit (u. a. Admin (dedicated, host-only), OpenCode, MCP claude.ai). Im gebauten — aber noch nicht deployten — Multi-Tenant-Code (Migration 059/060) kommt orthogonal dazu eine Tenant-Rolle (owner | admin | member) hinzu, die Autorität nur innerhalb des eigenen Tenants verleiht; die Go-Konstanten sind byte-identisch an das DB-CHECK gepinnt, damit ein Drift nie still Rechte gewährt.

Damit Cloud-Clients wie Claude.ai sich an den MCP-Endpunkt binden können, läuft ein minimaler, selbstgebauter OAuth-2.1-Server (kein externer Identity-Provider). Der Flow: Claude.ai ruft /authorize auf, der User trägt seinen ctx-API-Key in ein HTML-Formular ein, der Server stellt einen einmal-verwendbaren Authorization-Code (5 Minuten gültig, in-memory) aus und leitet zurück; /token tauscht den Code gegen ein Access-Token — wobei das Token schlicht der API-Key selbst IST. PKCE ist Pflicht: nur S256 wird unterstützt (token_endpoint_auth_methods=none), und SHA256(code_verifier) muss den code_challenge treffen, sonst invalid_grant. Zwei Discovery-Dokumente werden bedient: /.well-known/oauth-authorization-server und /.well-known/oauth-protected-resource. Registrierte Clients liegen in context_oauth_clients (client_id-Präfix ctx_, Secret nur als Hash); angelegt werden sie über `ctx mcp add`. Open-Redirect-Abwehr: Scheme-Allowlist (nur http/https) plus Rekonstruktion der Redirect-URL über net/url.

ctx exponiert seine Kernfunktionen als MCP-Server (Model Context Protocol) über den Streamable-HTTP-Transport für Remote-Clients wie Claude Code. Implementiert mit dem offiziellen modelcontextprotocol/go-sdk v1.5.0; der Server meldet sich als ctx Version 0.25.3, läuft stateless (jeder Call unabhängig) und antwortet bevorzugt mit JSON statt SSE. Fünf Tools sind registriert: query (Hybrid-Suche + LLM-Synthese, delegiert an den vollen /api/query-Handler inkl. Temporal, RRF, Gravity, Rerank, Supersedes), store (Upsert auf category+title+scope, mit Sensitivity-Gating), search (leichtgewichtige FTS ohne LLM), get (Block per UUID, mit Prefix-Auflösung) und recent (zuletzt geänderte Blöcke). Auth läuft über dieselbe Middleware wie die /api-Routen — X-Context-Key oder Authorization: Bearer — und injiziert das AuthResult in den Request-Kontext; store/search/get/recent sind fail-closed gegen fehlende Tenant-Identität bzw. fehlende Scopes.

Der HTTP-Daemon ctxd (Port 8080) nutzt einen chi-v5-Router mit globaler Middleware-Kette: SecurityHeaders, RequestID, Logger, Recovery. /health ist anonym und name-frei. Die OAuth-Endpunkte (/.well-known/*, /authorize, /token) liegen ungeschützt davor — sie sind der Auth-Flow. Alle übrigen Routen sind hinter der Auth-Middleware gruppiert: POST /api/query (RRF + Synthese), /api/store (Upsert + Auto-Embed), /api/search (FTS), GET /api/graph/ego und /api/graph/overview, /api/whoami, POST /api/manage (CRUD + Guard), /api/digest, /api/synthesize/daily, die admin-gateten /api/settings und /api/secrets, der Web-Chat (/api/chat/stream + Sessions) sowie Blob-Routen (/api/blob/fetch|search|manage|store). Body-Limits sind gestaffelt: 1 MB Standard, 10 MB für /api/ingest, 75 MB für Blob-Store. Admin-only mit erhöhtem Detail: /api/status, /api/llmlog, /api/events (SSE). Unbekannte Pfade fallen auf die eingebettete SPA durch (History-API-Fallback), während falsche API-Pfade weiterhin 404/405 liefern.

ctx ist ein Go-Monolith (Modul github.com/GottZ/ctx, go.mod deklariert Go 1.26.0) mit zwei Einstiegspunkten: der CLI ctx (per go install installierbar) und dem HTTP-Daemon ctxd (Port 8080). Die Geschäftslogik liegt in rund 25 internen Packages, u. a. auth (SHA-256-Key-Verifikation), handler (HTTP/MCP/OAuth), llm (Chat/Synthese/Translate/Classify/Temporal), embed, rerank, rrf (4-Way Reciprocal Rank Fusion), backends (deklarativer Pool), store (PG-Zugriff, Migrationen via embed.FS), dream (async Cross-Reference), guard (Dedup), digest/overview (Topic-Map + Graph), events (Scheduler, LISTEN/NOTIFY), settings, sealbox (versiegelte Secrets), sensitivity und chat. Kern-Abhängigkeiten: go-chi/chi v5.2.5, jackc/pgx v5.9.2 plus pgxlisten (PG LISTEN/NOTIFY mit SKIP-LOCKED-Jobs), pgvector/pgvector-go v0.3.0 und modelcontextprotocol/go-sdk v1.5.0. Eigene Bausteine statt Frameworks: eigener Migrations-Runner (Tracking-Tabelle _migrations), eigener LLM-Client.

Der Persistenz-Kern ist PostgreSQL 18 mit den Extensions pgvector (HNSW-Cosine-Index über vector(1024)), pg_trgm (Trigram-Title-Matching), GIN-Volltextindizes (englisch + deutsch) und TimescaleDB. Die Live-DB context_store steht aktuell auf Migration 57 (Tracking in der Tabelle _migrations). Bewusste Entscheidung gegen einen externen Vektor-Store (Qdrant/Milvus): der Kernwert ist die Hybrid-Fusion — RRF + FTS + Graph-Traversal + Temporal-Reranking + Scope-Filter — in EINER Transaktion, alles in SQL; pgvector ist für 1M Blöcke gebencht. Die Embeddings liegen out-of-line in TOAST (attstorage EXTERNAL), sodass Metadaten-Updates das Vektor-Tupel nicht neu schreiben. Die GottZ Temporal Dimension Table (context_temporal, EAV mit partiellen B-Tree-Indizes) liefert O(log n)-Zugriff auf zeitliche Anker. Das Schema umfasst u. a. context_blocks, context_api_keys, context_backends, context_oauth_clients, context_settings/secrets und die Dream-Link-Tabellen.

Die gesamte Inferenz läuft on-prem über llama.cpp (Ollama ist seit ~April 2026 vollständig raus) — alle Backends sprechen das OpenAI-Wire-Protokoll: /v1/chat/completions, /v1/embeddings und die cohere-style /v1/rerank-Schnittstelle. Geroutet wird deklarativ über die Tabelle context_backends: jede Zeile trägt Rollen (synthesis, translate, chat, digest, dream, classify, embed, rerank), eine model_map (Rolle→Modell + Params), eine Priorität und eine Trust-Stufe (full-trust | no-credentials | non-personal | public), die zusammen mit der Block-Sensitivity gatet, welcher Inhalt welches Backend erreichen darf. Die Methode Chain() löst pro Rolle eine Priority-DESC-Kette mit Cooldown-Sortierung auf. Live sind fünf Backends: herbert-chat (qwen3.6:27b, think:false — Chat/Synthese/Translate/Digest/Dream/Classify, full-trust, lan, prio 100), herbert-rerank (bge-reranker-v2-m3, prio 100), llama-embed (qwen3-embedding-8b, 1024d Matryoshka von nativ 4096d, prio 100), openrouter (qwen/qwen3.6-27b, no-credentials, external, prio 50) und llama-cpu (prio 10) als CPU-Fallback. Hardware: herbert ist eine Windows-Box mit einer Quadro RTX 6000 (24 GB), die zwei llama-server fährt (~21 GB belegt); der ctx-Docker-Host hat keine GPU, das Embedding läuft daher CPU-only. Backend-Mutationen greifen ohne Restart (Hot-Reload via LISTEN/NOTIFY).

Releases entstehen über .github/workflows/release.yml: eine Build-Matrix erzeugt fünf Plattform-Binaries — linux/amd64, linux/arm64, darwin/amd64, darwin/arm64 und windows/amd64. Der aktuelle Release-Tag ist v3.16.0. Die Versionierung ist hook-erzwungen: der pre-push-Hook lehnt Lightweight-Tags bei Version-Releases ab und verlangt annotierte Tags, deren Annotation als Release-Body dient. Weitere Pflicht-Hooks (core.hooksPath = .hooks): pre-commit (golangci-lint auf gestagte Go-Dateien) und commit-msg (README-Review bei feat:-Commits und Schema-Migrationen). Hinweis zur Versionsabgrenzung: der Release-Tag (v3.16.0, MPL-2.0, Autor GottZ) ist unabhängig von der intern gemeldeten MCP-Server-Version (0.25.3), die der MCP-Implementierung gehört.

Die Admin-SPA liegt unter go/web/ (Svelte 5.56.3 + TypeScript + Vite, Bun als Toolchain, ca. 13.660 Zeilen Quellcode) und wird per go:embed direkt in das ctxd-Binary kompiliert. Gebaut wird sie in einer eigenen Docker-Stage (oven/bun:1.3-alpine, bun install --frozen-lockfile, svelte-check-Gate) — nur das Docker-Image liefert die echte UI aus; ein nacktes `go install .../cmd/ctxd` produziert ein Binary, das einen 503-Platzhalter zeigt, während alle APIs funktionsfähig bleiben. Die CLI (cmd/ctx) hängt nie am Frontend. Ausgeliefert werden hashed Assets (immutable-cached, vorkomprimiert .br/.gz), History-API-Fallback antwortet nur auf HTML-Navigationen (Accept: text/html), sodass vertippte API-URLs für JSON-Clients 404 bleiben. Der Masterplan G01–G41 wurde mit v3.14.0 (2026-06-13) vollständig gebaut; Routing über sv-router 0.16.3. Aktuelle Release-Spitze: v3.16.0.

Der Graph-Bereich (/graph?focus=<uuid>, deep-linkbar) rendert Dream-Link-Ego-Netze via sigma 3.0.3 (WebGL) über eine einzige graphology-0.26.0-Instanz als Single Source of Truth — bewusst außerhalb der Svelte-Reaktivität, weil der Runes-Proxy-Overhead auf tausenden Knoten-Objekten zu teuer wäre. Layout ist ForceAtlas2 (graphology-layout-forceatlas2) in einem Web-Worker (Blob-URL, CSP trägt worker-src blob:), 3–10s je nach Graphgröße. Client-Speicher ist hart gedeckelt: über 5.000 Knoten / 20.000 Kanten werden die vom Fokus entferntesten Knoten (BFS-Distanz, LRU-Tiebreak) auf 4.000 evakuiert; gepinnte Knoten und der Fokus überleben. Block-Inhalt reist nie über den Graph-Endpoint (nur Titel). Die Graph-Landkarte (Overview-Map, außerhalb des 41-Plans benannt) löst das Scope-Count-Leak über scope-partitionierte Vor-Aggregate (Migration 057: drei normale Tabellen graph_cluster_member/_node/_edge, keine MView) und einen gonum-Louvain-Daemon-Job (internal/overview/cluster.go, raw_confidence-Gewicht, hartverdrahtete Seeds für Reproduzierbarkeit, advisory-lock); cluster_id wird nie roh exponiert, sondern per-Request als Ordinal vergeben. Released v3.15.0 (2026-06-14). LIVE deployed: clusters=70, nodes=669, edge_rows=58, modularity=0.857, elapsed=45ms (Korpus aktuell 691 Blöcke).

Der Blocks-Bereich ist ein Korpus-Browser: Volltextsuche plus Kategorie-/Tag-/Scope-Facetten, eine sensitivitäts-badged, keyset-paginierte newest-first-Liste über das scope-gegatete /api/search, ein Detail-Panel und Create/Edit/Delete über /api/store plus manage update/delete (mit Sensitivity-Downgrade- und Delete-Bestätigungen). Der Settings-Bereich rendert den kompletten Settings-API-Katalog generisch aus Registry-Metadaten — eine Kategorie-Karte pro Key-Präfix, Widgets per Registry-Typ dispatched, Source-Badge (default/env/db) und Env-Var-Name je Feld; Hot-Keys editieren live, Restart/coupled-Keys bleiben read-only. Eingebettet ist die Backends-Subroute (/settings/backends): Backend-Pool-Editor mit Trust-Dropdown und Elevation-Confirm-Dialog, Rollen-Multiselect, model_map-Zeileneditor, Prioritäts-Reihung und per-Zeile-Reachability-Test, plus der write-only Secrets-Vault mit Referenz-Tracking. Der Chat-Bereich (/chat) streamt einen Turn von POST /api/chat/stream über fetch + eventsource-parser (kein Reconnect — ein Turn ist one-shot), zeigt einklappbare Tool-Call-Cards und einen Backend-Badge; Assistant-Markdown läuft durch markdown-it (html:false) + DOMPurify, ctx-Zitate werden vor der Sanitisierung zu /graph?focus=<id> umgeschrieben. Test-Abdeckung: vitest, svelte-check 0/0.

Die CLI (cmd/ctx, spf13/cobra) registriert exakt 25 Top-Level-Befehle: query, save, search, stats, categories, get, delete, list-meta, digest, guard (list/stats/resolve/throttle), manage, health, ingest, statusline, dream (stats/review), mcp, keys, brief, persist, settings (get/set/unset/list), secrets, backends (list/create/update/delete/test), eject und init. `ctx query` ist die Primärschnittstelle (hybride semantische + Volltextsuche mit LLM-Synthese, gibt Antwort + Quellen-Refs zurück); `ctx save`/`store` upserted nach (category, title) und generiert Embeddings; `ctx search` liefert kompakte Treffer ohne LLM. Administrative Befehle wie `keys` (X-Context-Key-Provisionierung, home_scope ist seit v2.0.0 Pflicht bei Erstellung) und `mcp` (OAuth-Client-Registrierung für MCP-Remote) runden die Familie ab. Die CLI hängt nie am Web-Frontend.

Blob-Storage exponiert vier POST-Endpunkte (/api/blob/store, /fetch, /search, /manage), registriert in cmd/ctxd/server.go. store nimmt base64-kodierte Daten (Limit 50 MB, sonst 413), validiert das Write-Scope gegen home_scope bzw. shared (sonst 403), respektiert das Schreib-Rate-Limit und upserted über store.UpsertBlob nach (category, title) mit Filename, MIME-Type, Tags, Metadata, Checksum und storage_type. fetch holt per ID oder Kategorie/Titel (MetaOnly-Option, Daten base64-kodiert), search filtert scope-gegatet nach Kategorie/Tags/MIME-Type/Limit, manage kennt die Actions stats, get, list und delete. Jeder Schreibvorgang wird per LogAccess fire-and-forget protokolliert. Auth über denselben X-Context-Key-Header.

`ctx brief --hook` ist der SubagentStart-Hook: er liest das CWD aus stdin-JSON, sucht project-getaggte Blöcke der Kategorie agent-briefing (Fallback auf untagged) und gibt das Claude-Code-Hook-JSON-Format zurück (continue, suppressOutput, hookSpecificOutput.additionalContext). Ohne --hook liefert er menschenlesbaren Text; Scoping per Projekt-Tag (git-root oder CWD), Default-Limit 20 Blöcke. `ctx persist --hook` ist der SubagentStop-Hook: er parst [PERSIST:category:title]-Marker aus der letzten Assistant-Message und speichert sie in den Store, inklusive automatisch angereicherter Metadaten (session_id, hostname, project, agent). Beide degradieren still (kein Fehler), wenn ctx unerreichbar ist oder keine Marker gefunden werden. Der `-p`-Armada-Modus (`claude -p "..."`) dient als Context-Firewall, der Subagenten isoliert.

`ctx ingest <vault-path>` durchläuft ein Obsidian-Vault-Verzeichnis, parst und chunkt alle .md-Dateien (collectMarkdownFiles überspringt .obsidian/, Dot-Verzeichnisse und node_modules) und lädt sie batchweise hoch. Der Parser (internal/ingest, Package ingest) verarbeitet Frontmatter (Tags, Date, Title, Aliases, Custom-Fields). Metadaten werden mit source=obsidian markiert. Flags: --dry-run (Vorschau ohne Upload), --workers und --batch zur Durchsatzsteuerung. Aufruf z. B. `ctx ingest /path/to/vault/ --workers 4 --batch 100`.

Die Kern-Ausarbeitung folgt dem Hybrid-Modell C mit drei Ebenen: TENANT (context_tenants, Owner-Register als unabhängiges Projekt/Firma), SCOPE (context_tenant_scopes, bleibt Daten-Diskriminator ohne tenant_id auf Daten-Tabellen) und BLOCK (context_block_grants, row-level Freigabe). Der API-Key trägt tenant_id und tenant_role; read_scopes werden per-Tenant in ctx_auth aufgelöst (own ∪ Grants, fail-closed). Umfang: 44 Wellen (T01–T43, T40 gespalten), Phasen A–G, 11 Migrationen 058–068, rund 7805 LOC. Verifiziert gegen Git (Branch feat/multi-tenant, HEAD ddbfd7f): 20 Wellen committet, Migrationen 058–064 (7 Stück) vorhanden — alle additiv und verhaltensneutral, damit der Bau jederzeit pausierbar bleibt. Noch lokal, nicht gepusht oder deployed (echte DB max(migration)=57).

Auf die Kern-MT-Planung setzt ein Enterprise-Aufsatz auf, ausgearbeitet über fünf Dimensionen: Reseller/Mandanten-Verwaltung, Konzern-Hierarchie (Mutter/Tochter), Testbereiche/ephemere Tenants, separate Models (Embedding + Inference) und Lastverteilung. Branding/White-Label ist bewusst geparkt. Kern-Erkenntnis: Verwaltungs-Vererbung ist orthogonal zur Daten-Sicht-Vererbung — Letztere ist opt-in und oft Anti-Feature. Der Super-Tenant ist ein realer default-Tenant als Baum-Wurzel (parent NULL); _global wird nie Tenant. Geteilte Embedding-Generation ist hartes Default, Last schlüsselt auf tenant_id. Die Analyse umfasst rund 140 Anforderungen und identifiziert sechs fail-open-Stellen im MT-Pfad.

Nach Web-Frontend und Multi-Tenant geplant (noch nicht gebaut): das Kern-Redesign trennt Mechanismus von Policy. Das hardcodierte 4-Klassen-block_role-Enum (system-meta/audit-trail/reference/knowledge) wird zu konfigurierbaren Type-Configs mit Verhaltens-Feldern (retrieval_policy, guard_dedup, dream_linkable). Ziel: User bauen eigene Workflows auf ctx. Erster Workflow darauf ist ein Issue-System, bei dem ein Issue ein context_block in einem repo-spezifischen Scope-Tenant ist und gratis die ctx-Maschine erbt: Guard als Duplikat-Erkennung, RRF als related-issues, Dream als autonomes Cross-Linking. Forge-Sync (GitHub zuerst) gleicht über 3-Wege-Content-Hash ab. Endziel: User und Agenten dokumentieren den Rest als Issues im System selbst, dann entfällt todos.md ganz.