Wissen bleibt exportierbar
WikiKit exportiert einen Space deterministisch als lesbaren Markdown-Baum oder als OKF-Bundle. Claims, Belege, Beziehungen, Quellen und Entscheidungen bleiben portabel.
#Architektur
Releases mit getrennten Prüfgrenzen
Unabhängige Produkte lassen sich gemeinsam erweitern, wenn Verträge, lokale Prüfungen, echte Release-Artefakte, Produktionsprüfungen und eine zeitversetzte Beobachtung klar getrennte Beweise liefern.
Entscheidungen mit Geschichte
WikiKit behandelt Entscheidungen als eigene, reviewte Wissensobjekte mit Kontext, Entscheidung, Begründung und Alternativen. Claims sagen, was gilt; Entscheidungen erklären warum.
Publizieren ohne Öffentlichkeit
Persönliche Leser, Gruppen, genaue und präfixbasierte Pfadregeln schützen Dokumentation samt Suche, Navigation, Medien und maschinenlesbaren Ausgaben als Teil des Releases.
Kontrollierte Templates statt Plugins
Site-Presets, feste Seitenlayouts, Design-Tokens und begrenztes CSS erlauben unterschiedliche Websites, ohne hochgeladenen Template-Code in den Release-Pfad zu holen.
Finanzen bewusst abtrennen
Finanzreports können denselben technischen Ablauf verwenden, ohne Daten, Rechte, Speicher oder Wissen mit allgemeinen Produktreports zu vermischen. Die Trennung folgt der Fachlichkeit.
Vorschau vor Wirkung
Unveränderliche Revisionen, manifestgebundene Vorschauen und eine exakte Promotion halten schnelle Agentenarbeit vom öffentlichen Stand getrennt – aktiviert wird der geprüfte Kandidat, nicht eine Neuberechnung.
Responsive heißt neu komponieren
ContentKit ordnet semantische Inhalte für den tatsächlichen Container, die Lesedichte und das Ausgabemedium neu an.
WikiKit, SubKit und ContentKit sicher verbinden
WikiKit hält geprüftes Wissen, SubKit führt den versionierten Ablauf aus und ContentKit bindet Vorschau und Veröffentlichung an unveränderliche Revisionen und menschliche Entscheidungen.
MCP, HTTP, Webhooks und A2A einfach erklärt
MCP, HTTP mit OpenAPI, Webhooks und A2A verbinden Systeme auf unterschiedlichen Ebenen. Entscheidend ist, welche Verantwortung an der jeweiligen Grenze liegt.
MCP, HTTP oder Webhook? SubKit, WikiKit und ContentKit verbinden
MCP, REST, Webhooks und A2A lösen unterschiedliche Integrationsprobleme. Eine Entscheidungshilfe zeigt, wann direkter Agentenzugriff genügt und wann SubKit den Ablauf übernehmen sollte.
Ein Cockpit für abgeschlossene Zeitfenster
Das Mission Cockpit verbindet SubKit, ContentKit und WikiKit über ihre gewöhnlichen Verträge und trennt maschinenlesbare Fakten, geschützte Reports und kuratiertes Wissen.
Werkzeuge, die zusammenspielen
Sechs eigenständige Produkte statt einer gekoppelten Suite: ContentKit veröffentlicht, WikiKit kuratiert Wissen, SubKit führt reproduzierbare Abläufe aus, WatchKit belegt Verhalten, WorkKit delegiert Ziele und CodeKit kontrolliert Coding-Agenten.
Semantik vor Geometrie
ContentKit trennt Bedeutung, Erzählung, visuelle Komposition, Layout und Rendering, damit aus Markdown verständliche und überprüfbare Darstellungen entstehen.
Diagramme ohne Browser-Laufzeit
Contentkit rendert helle und dunkle Diagramme reproduzierbar auf dem Server, veröffentlicht statische SVGs und behält Markdown-Tabellen als zugängliche Quelldaten.
Headless mit Cockpit und JSON
Headless beschreibt in ContentKit die Trennung von Inhaltsmodell und Ausgabekanal, nicht den Verzicht auf eine Oberfläche. Die geschützte Read API liefert den Veröffentlichungsstand als JSON mit ETags und Suche, während das Cockpit Menschen über dasselbe Inhaltsmodell Zugriff auf dessen veröffentlichte Sicht gibt.
A2A: Wenn Agenten zusammenarbeiten
Agent Card, Message, Task und Artifact verständlich erklärt: wie A2A 1.0 eigenständige Agentensysteme verbindet, was das Protokoll von MCP unterscheidet und wie WorkKit und CodeKit begrenzte Aufträge heute konkret annehmen.
Vom JSON zum privaten Report
Private Reports bleiben nachvollziehbar, wenn Quelldaten, Analyse, Manifest und redaktionelle Aussage getrennte Artefakte bleiben – und Zugriffsregeln gemeinsam mit dem Release für geschützte Seiten, Medien und maschinenlesbare Ausgaben wirksam werden.
Stündlich ist nicht Echtzeit
Ein abgeschlossener Stundenreport beantwortet andere Fragen als laufende Betriebsbeobachtung – und wird einfacher, sobald Zeitfenster, Verspätung und Messlücken ausdrücklich modelliert sind.
Custom Fields als Übergabevertrag
Mit begrenzten Zusatzfeldern, expliziten Beziehungen und dokumentbezogenen Metadaten übergibt ein Agent neben dem Text auch nachvollziehbare Struktur an ContentKit.
Produkte berichten über ihre API
Produktstatistiken bleiben verständlich, wenn jedes System seine Daten selbst verdichtet und über einen kleinen, zeitlich einheitlichen HTTP-Vertrag anbietet.
Wissensbasen sichtbar machen
ContentKit ist nicht die führende Wissensbasis, sondern macht freigegebene Wissensstände als Dokumentation, Wiki oder Hilfeportal für Menschen und Maschinen sichtbar.
ContentKit: Cockpit und API in einer Domäne
ContentKit verbindet ein eingebettetes Web-Cockpit mit portablen Markdown-Quellen, unveränderlichen Revisionen, prüfbaren Vorschauen und atomaren Releases. Cockpit, REST und MCP sind Zugänge für Menschen, Dienste und Agenten zu derselben Veröffentlichungsdomäne.
MCP: Wenn Software Fähigkeiten anbietet
MCP macht Softwarefähigkeiten für Agenten adressierbar. Gute Oberflächen bleiben wichtig, aber Arbeit bekommt eine zweite Schnittstelle.
KI im Enterprise-Umfeld: Schnellere Entwicklung braucht andere Prozesse
KI verkürzt Recherche, Entwurf und Implementierung. Bleiben Übergaben, Ticket-Hierarchien und Freigaben unverändert, verlagert sich der Engpass – Großunternehmen müssen deshalb Arbeitsfluss und Governance gemeinsam neu ordnen.
Resilience-Muster: Timeout, Retry, Circuit Breaker, Idempotenz
Warum Resilienz kein Zufall ist: Timeout, Retry mit Backoff und Jitter, Circuit Breaker und Idempotenz als bewusst entworfene Muster gegen die Ausfallmodi verteilter Systeme.
Evolutionary Architecture: Systeme, die sich ändern dürfen
Architektur ist kein Endzustand, den man einmal festzurrt. Kleine Änderungen und passende Fitness Functions machen ausgewählte Risiken früher sichtbar, garantieren aber weder Tempo noch Qualität.
Fitness Functions: ausgewählte Architektureigenschaften prüfen
Fitness Functions machen ausgewählte Eigenschaften wie Kopplung, Abhängigkeiten und Latenz kontinuierlich prüfbar. Fachliche Qualität und Architekturabwägungen ersetzen sie nicht.
Jamstack als Architekturstil für Webanwendungen
Jamstack beschreibt einen Architekturstil mit vorgerendertem Frontend und entkoppelten Diensten. Der Beitrag ordnet die ursprünglichen Bausteine JavaScript, APIs und Markup im Stand von 2021 ein.
Wann CQRS und Event Sourcing zu viel sind
Für die meisten Systeme reicht CRUD. CQRS und Event Sourcing lohnen sich nur unter klaren Bedingungen – dieser Beitrag liefert einen ehrlichen Entscheidungsleitfaden statt Muster als Selbstzweck.
Architecture Decision Records: Entscheidungen, die man in zwei Jahren noch versteht
Warum wir uns damals für PostgreSQL und gegen den Message-Bus entschieden haben? ADRs machen das Warum als versioniertes Markdown-Artefakt haltbar – statt es im Flurfunk versickern zu lassen.
Event Sourcing: der Event-Store als Logbuch
Event Sourcing speichert nicht den aktuellen Zustand, sondern die Folge der Events als Wahrheitsquelle: der Event-Store als Logbuch, der Zustand als Faltungsergebnis. Nutzen, ehrliche Kosten und die Abgrenzung zu CQRS.
Team-Automatisierung mit GitHub Actions
Warum ich ausgewählte, wiederkehrende Prüfungen als Workflows ausführe – und woran sich zeigt, ob die Automatisierung das Team tatsächlich entlastet.
Read Models aus Events: Projektionen statt zufälliger Caches
Ein aus Events aufgebautes Read Model ist eine bewusst gepflegte Projektion für konkrete Abfragen. Herkunft und Rebuild unterscheiden es von einem zufällig gewachsenen Cache, auch wenn die technische Sicht cacheähnlich wirken kann.
Cloud Guardrails statt Cloud Gatekeeping
Warum zentrale Freigabeprozesse in der Cloud Schatten-Infrastruktur züchten und wie technisch durchgesetzte Leitplanken – SCPs, Permission Boundaries, Config Rules, Budgets – Teams Bewegungsfreiheit zurückgeben.
Bounded Contexts vor dem Serviceschnitt
Bevor ich Services schneide, kläre ich fachliche Grenzen. Ein Bounded Context ist eine Sprachgrenze und ein möglicher, aber nicht zwingender Serviceschnitt.
Das Aggregat als Konsistenzgrenze
Ein Aggregat ist keine ORM-Entity und keine Tabelle, sondern eine Konsistenz- und Transaktionsgrenze: ein Verbund von Objekten, den eine Aggregate Root als Einheit schützt. Warum eine Transaktion genau ein Aggregat ändert und andere Aggregate nur per ID referenziert werden.
PouchDB und Offline-First
Wer offline Schreibzugriffe erlaubt, wechselt von Request/Response zur Replikation – und der Revisionsbaum von PouchDB und CouchDB macht Konflikte zur Aufgabe des Fachmodells.
Commands, Events und Queries sauber trennen
Command, Event und Query sind drei Nachrichtenarten mit klarer Semantik: ein Wunsch, der abgelehnt werden kann, eine geschehene Tatsache und eine seiteneffektfreie Abfrage. Wer sie sauber benennt und trennt, gewinnt Klarheit im Modell – ganz ohne großes CQRS-Setup.
Secrets im Build sind Produktentscheidungen
Secrets im Build sind ein Vertrauensproblem: Wer darf was wann sehen, speichern und deployen?
CQRS ist eine fachliche Grenze, kein Framework
CQRS trennt das Modell zum Schreiben vom Modell zum Lesen – eine fachliche Entscheidung, kein installierbares Framework. Wann sich die Grenze lohnt, wie man klein anfängt und welche Verwechslungen teuer werden.
PWA Weather: offline ist ein Feature
Eine kleine Wetter-App als Progressive Web App zeigt, warum Offline-Verhalten eine Produktentscheidung ist und wie ehrlich eine Oberfläche mit veralteten Daten umgehen sollte.
HTML5, CSS3 und ECMAScript als Baseline
Im Frühjahr 2017 tragen CSS Grid, Flexbox, fetch und natives ES2015 so weit, dass die erste Architekturfrage im Frontend neu gestellt gehört: Wie weit komme ich ohne Framework?
Funktionale Stile im Alltag
Warum funktionaler Stil im Team-Alltag 2015 nicht Haskell bedeutet, sondern die Disziplin, reine Funktionen von I/O zu trennen – und wie ES2015 das endlich bequem macht.
Programming Styles als Architekturvergleich
Dieselbe kleine Aufgabe in Dutzenden Programmierstilen gelöst ist der kompakteste Architekturvergleich, den ich kenne – weil jeder Stil eine bewusst gewählte Constraint-Menge ist.
MathParser: Parser als Denkwerkzeug
Ein Rückblick auf ein eigenes Parser-Demo von 2010 zeigt, warum ein handgeschriebener Ausdrucks-Parser auf wenigen Zeilen mehr über Schichten, Struktur und die Grenze zwischen Syntax und Semantik lehrt als manches große Projekt.
HTTP APIs: klein, stabil, lesbar
Was der Heroku HTTP API Design Guide taugt, wenn man ihn an eigenen APIs spiegelt – und warum wenige Ressourcen, ein Versionsversprechen und selbsterklärende Fehler mehr bewirken als jedes Framework.
Was ich an Elixir gesucht habe
Nicht die Syntax hat mich zu Elixir gebracht, sondern das Ausführungsmodell der Erlang-VM – Prozesse, Nachrichten und Supervisors, betrachtet mit JavaScript- und C#-Augen.