Architektur schlägt Hype: Warum hekima.one auf Minimalismus und lokale Daten setzt

In der gegenwärtigen Ära überladener Software-as-a-Service-Lösungen (SaaS), die oft unter einem „Modern Tooling Overkill“ leiden, stellt hekima.one eine bewusste Zäsur dar. Als „digitaler Stabschef“ konzipiert, verzichtet die Plattform auf das marktübliche Wettrüsten um immer komplexere Features und setzt stattdessen auf ein architektonisches Fundament, das durch radikale Simplizität und lokale Datenhoheit besticht. Die Entscheidung für einen minimalistischen Ansatz ist dabei kein Selbstzweck, sondern die notwendige Antwort auf die fragile Wartbarkeit und den Souveränitätsverlust moderner Cloud-Applikationen. Es geht um die Rückbesinnung auf architektonische Integrität in einer Welt, die sich zunehmend in ephemeren Tech-Hypes verliert.

Minimalismus als Überlebensstrategie: Der Tech-Stack unter dem Mikroskop

Die technische Basis von hekima.one bricht konsequent mit den Konventionen zeitgenössischer Webentwicklung. Während die Industrie auf komplexe Framework-Ökosysteme mit tausenden transitiven Abhängigkeiten setzt, basiert hekima.one auf PHP 8.2+ und MySQL — Technologien, die auf gängigem Shared Hosting ohne spezialisierte Infrastruktur-Teams stabil betrieben werden können. Diese Wahl ist ein klares Bekenntnis zur Infrastruktur-Agnostik. Das System verzichtet vollständig auf Composer- oder npm-Abhängigkeiten zur Laufzeit. Jede Komponente ist PSR-4-konform organisiert, was eine klare Separation of Concerns zwischen dem Framework-Kern, den Modulen und der LLM-Abstraktion ermöglicht, ohne die Komplexität externer Package-Manager zu importieren.

Der Request-Lifecycle ist linear und transparent gestaltet. Jeder HTTP-Request durchläuft nach der .htaccess-Umleitung die zentrale public/api.php und wird über die App::run()-Methode initialisiert. Bevor ein Controller die Anfrage verarbeitet, passiert der Request eine geschichtete Middleware-Kette: CorsMiddleware → CsrfMiddleware → AuthMiddleware → RateLimitMiddleware. Dieser Aufbau garantiert, dass Sicherheits- und Kontextprüfungen nicht über die Codebase verstreut, sondern an einem Single Point of Entry gebündelt sind. Der Router unterstützt dabei modernes URL-Matching mit Pfadparametern, wobei die Route-Definitionen dezentral in den jeweiligen Modulen über die registerRoutes-Methode erfolgen.

Das Deployment-Modell unterstreicht den Fokus auf Autarkie. Statt komplexer CI/CD-Pipelines nutzt die Architektur ein Python-basiertes Deployment-Skript, das via Paramiko/SFTP ein Single-Tenant-Deployment realisiert. Ein kritischer Sicherheitsanker ist dabei das setup.php-Skript: Es triggert nach dem Upload den MigrationRunner, ist jedoch durch einen 16-stelligen Schlüssel geschützt, der aus den ersten Zeichen des server-seitigen ENCRYPTION_KEY abgeleitet wird. Dies verhindert unautorisierte Schema-Änderungen durch Dritte.

Minimalität: Keine Abstraktion ohne konkreten Bedarf. Drei ähnliche Code-Zeilen sind besser als eine verfrühte Abstraktion. [Dunkel/2026]

Das Frontend folgt dieser Philosophie durch den Verzicht auf Build-Schritte. Vanilla ES6 Module und Alpine.js ermöglichen eine direkte DOM-Kontrolle ohne Transpiler-Overhead. Die PWA-Fähigkeit wird durch einen dedizierten Service-Worker (sw.js) sichergestellt, der eine Cache-First-Strategie für statische Assets verfolgt, während API-Requests nach dem Network-First-Prinzip behandelt werden. Um Cache-Inkonsistenzen nach Updates zu vermeiden, nutzt die Architektur eine Cache-Busting-Strategie über die Variable $v in der index.php, die bei jedem Release synchron mit dem CACHE_NAME des Service-Workers inkrementiert wird.

Besondere Aufmerksamkeit verdient das Modulsystem. Jede Erweiterung unter app/Modules/ deklariert sich über ein module.json-Manifest. Der ModuleLoader scannt diese beim Boot-Vorgang und führt eine topologische Sortierung durch, um Abhängigkeiten zwischen Modulen (z.B. das Tasks-Modul, das auf dem Projects-Modul aufbaut) korrekt aufzulösen. Diese lose Kopplung stellt sicher, dass der Kern des Systems schlank bleibt, während die funktionale Tiefe modular wachsen kann.

Die LLM-Abstraktionsschicht: Unabhängigkeit von Provider-Monopolen

Ein zentrales Risiko KI-zentrierter Architekturen ist der Vendor Lock-in. hekima.one begegnet diesem durch eine strikt provider-agnostische Abstraktionsschicht unter app/LLM/. Das Herzstück bildet das LlmProviderInterface, das die Methoden chat, streamChat und isAvailable vorschreibt. Der LlmManager fungiert als Fassade, die Provider-Konfigurationen zur Laufzeit aus der Datenbank lädt und die Verschlüsselung der API-Keys via AES-256-CBC verwaltet.

Die technische Intelligenz des Systems manifestiert sich im Task-Routing. Die Datenbank-Tabelle llm_task_routing definiert für jeden Anwendungsfall (z.B. meeting-structure oder task-generate) einen primären Provider und einen Fallback-Mechanismus. Fällt die Anthropic-API aus, schaltet das System transparent auf OpenAI oder einen lokalen Provider um.

Ein wesentliches Merkmal für die Nutzererfahrung ist die Implementierung von Server-Sent Events (SSE) für das Token-Streaming. Im Gegensatz zu Standard-REST-Antworten erlaubt SSE die inkrementelle Darstellung der KI-Antworten im Frontend, was die gefühlte Latenz drastisch minimiert. Das System protokolliert jeden Call im llm_usage_log, wobei Metriken wie Token-Verbrauch, Latenz und ein Kosten-Proxy erfasst werden, um eine präzise Telemetrie über die Provider-Effizienz zu ermöglichen.

Der Vault als Souveränitäts-Garant: Obsidian-Kompatibilität als Architektur-Kern

In hekima.one ist die relationale Datenbank nicht der ultimative Ort der Wahrheit für Wissen, sondern fungiert lediglich als performanter Index. Die „Source of Truth“ liegt im Dateisystem unter storage/vault/ in Form von Markdown-Dateien mit YAML-Frontmatter. Dieser Ansatz garantiert die volle Kompatibilität zum Obsidian-Ökosystem und stellt sicher, dass die Daten auch ohne die Applikation lesbar und portabel bleiben.

Der VaultSyncService übernimmt die komplexe Aufgabe der bidirektionalen Synchronisation. Er erkennt Änderungen über SHA-256-Hashes pro Datei. Werden Dokumente über die API editiert, schreibt der Dienst diese ins Dateisystem; manuelle Änderungen im Dateisystem werden beim nächsten Scan in den MySQL-Index (Tabellen vault_documents, tags, document_links) überführt. Für die performante Suche über Wikilinks ([[Dokumentname]]) und Inhalte nutzt die Datenbank einen FULLTEXT INDEX.

hekima verbindet ein aufgabenzentriertes Dashboard mit einem Obsidian-kompatiblen Wissens-Vault. Projekte, Aufgaben, Meetings, Journal-Einträge und Dokumente sind inhaltlich verknüpft — so entsteht nicht nur eine To-do-Liste, sondern ein lebendiger Arbeitskontext. [Dunkel/2026]

Die Architektur sieht zudem eine Cloud-Synchronisation über das CloudSyncInterface vor. Mit Adaptern für CouchDB, S3-kompatible Speicher und WebDAV (z.B. IONOS HiDrive) behält der Nutzer die volle Kontrolle über die Replikation seiner Daten. Bei Synchronisationskonflikten verfolgt das System eine „Most-Recent-Wins“-Strategie basierend auf dem updated_at-Zeitstempel, wobei ältere Versionen mit einem .conflict-Suffix archiviert werden, um Datenverlust auszuschließen.

Hybrides Relevanz-Ranking: Jenseits der binären Taskliste

Die Priorisierung in hekima.one transformiert die Aufgabenverwaltung von einer statischen Liste zu einem dynamischen Steuerungsinstrument. Der hybride Ranker in TaskRanker.php kombiniert deterministische Regeln (Schicht A) mit KI-gestützter Bewertung (Schicht B). Um die Serverlast zu begrenzen, arbeitet der Ranker mit einem 15-minütigen TTL-Cache.

Die zentrale Formel bildet die Relevanz auf einer Skala von 0 bis 100 ab: relevance = (w1·urgency + w2·impact + w3·dependency + w4·momentum − w5·staleness) · 5.

Die Architektur nutzt hierfür spezifische Gewichtungen: w1 (Urgency) = 8.0, w2 (Impact) = 6.0, w3 (Dependency) = 4.0, w4 (Momentum) = 3.0 und w5 (Staleness) = 2.0. Besonders die „Staleness“ fungiert als regulatorisches Element: Aufgaben, die länger als 14 Tage unberührt bleiben, verlieren an Relevanz, um den Fokus auf aktuelle Themen zu schärfen. Schicht B integriert Kontextsignale aus dem Daily Review und dem Journal, um den impact_score KI-gestützt nachzujustieren.

Das Dashboard visualisiert diese Daten in vier technischen Buckets:

• Jetzt fokussieren: Höchste Relevanz (Score > 65), überfällige oder aktive Tasks (strikt limitiert auf max. 5 Einträge zur Vermeidung von Decision Fatigue).
• Heute fällig: Determinierte Liste aller Aufgaben mit einem Fälligkeitsdatum (due_date) am heutigen Kalendertag.
• Diese Woche: Vorausschauende Ansicht für Aufgaben mit Fälligkeit in den nächsten 7 Tagen.
• Backlog: Alle verbleibenden Aufgaben, streng sortiert nach ihrem berechneten Relevanz-Score (begrenzt auf die Top 20).

Zukünftige Inkremente sehen eine Erweiterung um Timeboxing-Felder wie energy (Deep/Shallow/Admin) und estimate_minutes vor, um Aufgaben in dedizierte Zeitfenster zu mappen.

Das Lernprotokoll: Die Evolution des System-Prompts

Ein fundamentales Defizit herkömmlicher KI-Systeme ist das Fehlen eines langfristigen Gedächtnisses für Nutzerpräferenzen. Das learning-log-Modul in hekima.one löst dieses Problem durch einen persistenten Kontextspeicher. Es agiert als Musterdetektor, der Korrekturen des Typs „so nicht, sondern so“ erfasst und mit Konfidenzintervallen versieht.

Die technische Umsetzung erfolgt durch System-Prompt-Injection. Bei jedem LLM-Aufruf injiziert der ModuleLoader hoch-konfidente Einträge aus dem Lernprotokoll in den Kontext. Mit jeder expliziten Bestätigung einer KI-Antwort durch den Nutzer steigt die Konfidenz eines Musters. Dies führt dazu, dass das System über die Zeit spezifische fachsprachliche Nuancen, bevorzugte Formatierungen oder strukturelle Präferenzen bei der Aufgabenplanung adaptiert. Da auch Reflexionen aus dem Daily Review einfließen, entwickelt hekima.one eine Form von situativem Bewusstsein, ohne auf invasive Tracking-Methoden zurückgreifen zu müssen.

Security by Design: Verteidigung ohne Bloatware

Die Sicherheitsarchitektur folgt dem Prinzip der Angriffsflächenminimierung und ist direkt in den Kern der PDO-basierten Datenbank-Abstraktion integriert. Anstatt sich auf komplexe Security-Frameworks zu verlassen, setzt hekima.one auf bewährte, tief im Code verwurzelte Mechanismen.

Die Authentifizierung nutzt Argon2id für das Passwort-Hashing. Ein technisches Distinktionsmerkmal ist die Behandlung von Session-Tokens: In der Datenbank werden ausschließlich SHA-256-Hashes der Tokens gespeichert. Ein potenzieller Datenbank-Leak ist somit wertlos für einen Angreifer, da die tatsächlichen Tokens niemals persistiert werden. Alle kryptografischen Vergleiche, insbesondere bei API-Keys und Session-Hashes, nutzen hash_equals(), um Timing-Attacken (Seitenkanalangriffe) auszuschließen.

Der Schutz gegen CSRF wird ohne klassische Cookies realisiert. Durch die Forderung nach dem X-Requested-With-Header und einem JSON-Content-Type für alle zustandsändernden Requests werden Standard-Exploits neutralisiert. Die Verzeichnisstruktur trennt zudem konsequent zwischen dem Document-Root (public/) und der App-Logik. Eine mehrstufige .htaccess-Strategie blockiert den Zugriff auf sensible Verzeichnisse wie config/ oder storage/ auf Serverebene.

Kritische Audit-Punkte der Sicherheitsarchitektur:

• API-Key-Management: Verschlüsselung ruhender Keys mit AES-256-CBC; der ENCRYPTION_KEY verbleibt ausschließlich in der Systemumgebung.
• Key-Rotation: Erzwungene Erneuerung externer Provider-Schlüssel alle 90 Tage über das Admin-Panel.
• Rate-Limiting: Datenbankbasierte Begrenzung (Tabelle rate_limits) pro IP und Aktion (Login: max. 5 Versuche/15 Min; LLM: max. 60 Calls/Stunde).
• SQL-Injection-Prävention: Konsequente Nutzung von Prepared Statements; die Database-Klasse erlaubt keine Ausführung von Roh-Strings mit Nutzer-Input.
• Pfad-Traversal-Schutz: Sanitisierung aller Vault-Operationen via basename() und Whitelisting erlaubter Dateiendungen.

Fazit: Synthese und Ausblick

hekima.one demonstriert eindrucksvoll, dass technischer Minimalismus und architektonische Integrität die wirksamsten Strategien gegen modernen Software-Bloat sind. Durch die Kombination bewährter Technologien wie PHP und MySQL mit hochmodernen Konzepten wie LLM-Abstraktion, SSE-Streaming und einem Obsidian-kompatiblen Vault entsteht ein System, das Wartbarkeit mit funktionaler Exzellenz verbindet. Es ist ein Gegenentwurf zum zentralisierten SaaS-Modell — ein Werkzeug für Anwender, die keine Kompromisse bei der Datensouveränität eingehen wollen.

Die modulare Architektur ermöglicht eine kontinuierliche Evolution, ohne den Kern des Systems zu destabilisieren. Mit der zunehmenden Leistungsfähigkeit lokaler KI-Modelle wird die provider-agnostische Struktur von hekima.one zum entscheidenden strategischen Vorteil.

Abschluss-Frage: Wird die zunehmende Verfügbarkeit performanter lokaler LLMs (via Ollama oder vLLM) dazu führen, dass zentralisierte SaaS-Modelle für das Wissensmanagement langfristig durch autarke Single-Tenant-Architekturen wie hekima.one verdrängt werden, um das Risiko des Vendor Lock-ins final zu eliminieren?

© 2026 Olaf Dunkel. Eigenständige Analyse diverser Quellen; KI-Unterstützung rein sprachlich, inhaltliche Verantwortung beim Autor.