Nichts wird neu gebaut, weil nichts vergessen wird

Die meiste Individualsoftware wird angeboten, als hätte es nie etwas Vergleichbares gegeben, und der Kunde zahlt ein zweites Mal für Überlegungen, die vor Jahren fertig waren.

Drei Dinge gehen von einem Build zum nächsten mit, und keines davon wird für jeden Kunden neu gemacht: was eine Branche wirklich von ihrer Software braucht, wie diese Software gebaut wird, und wie die Arbeit geführt wird. Alle drei werden bewusst aktuell gehalten, aufgefrischt in einem Wartungsdurchgang im August 2026, statt dem überlassen zu bleiben, der sich gerade erinnert.

Ein einmal gelöstes Problem wird nicht zweimal gelöst. Ein Fehler beim Sign-in, an dem die eigenen Produkte mehrerer großer Hersteller bis heute hängen, wurde hier einmal diagnostiziert, und jeder Build seither erbt die Lösung, statt eine Woche daran zu verlieren. Stunden, die nicht ins Fundament gehen, landen nie auf der Rechnung.

Das Bild, das sich selbst zeichnet

Architecture Drawings altern in dem Moment, in dem sie als Bild exportiert werden. Ein von Hand gezeichnetes Bild ist am Tag danach überholt, und niemand verteidigt ein System, das er nicht sieht.

Das Diagramm im Portal entsteht aus dem, was tatsächlich deployed ist, und kann der Realität deshalb nicht widersprechen. Jede Box ist etwas, das wirklich läuft. Ein Klick darauf zeigt, wo es läuft, welche Adresse es ausliefert und welche Daten es nutzt. Die Live-Kopie und die Kandidaten-Kopie stehen beide da, und damit ist der Weg von der einen zur anderen sichtbar statt in einem Dokument beschrieben.

Der Kunde bekommt das als eigenes Portal, nicht als Screenshot in einem Bericht. Sechs Views decken ab, was deployed ist, ob es gesund läuft und was es gekostet hat. Der schwere Teil des Bildes lädt erst, wenn ihn jemand öffnet, und die Seite bleibt für alle anderen schnell.

Was nicht geprüft wurde, wird benannt und nicht leer gelassen

Ein grüner Test beweist nur, woran jemand beim Prüfen gedacht hat, und alles, was nie geprüft wurde, bleibt unsichtbar. Genau dieser unsichtbare Rest ist der Teil, den man kennen sollte. Ein grünes Licht, das nur abdeckt, woran sich jemand beim Messen erinnert hat, ist schlechter als gar kein Licht.

Die Quality View liest die Ergebnisse aus dem, was die Checks tatsächlich produziert haben, nicht aus einer Behauptung in einem Dokument, und zeigt einen Fehlschlag als Fehlschlag. Sie zeigt zwei Listen: was geprüft ist und was nicht abgedeckt ist. Die zweite entsteht, indem das Geprüfte gegen alles Vorhandene gehalten wird. Wo nichts gemessen wurde, sagt die View das und nennt den Grund, statt eine Null zu zeigen, die aussieht wie ein bestandener Test.

Ein Nachweis hält für fünf Datendateien fest, woher jede Zahl stammt. Ein wöchentlicher automatischer Check meldet eine priorisierte Verbesserung, damit die Liste kurz genug zum Lesen bleibt.

10 Tage
vom ersten Commit bis zum laufenden, abgesicherten Management-System
2
Kopien automatisch verglichen: was auf Preview liegt gegen das, was live ist
6
Views im eigenen Portal des Kunden, von was läuft bis was hat es gekostet
1
priorisierte Verbesserung aus dem wöchentlichen Check, jede Woche

Governance für das Agentic Estate

Das ganze Estate sehen 3 Schritte
01

Vergleichen Sie den Skill, nicht seine oberste Datei

Eine handgeführte Notiz, welches Repository welche Version eines Convention Skills trägt, veraltet schneller als die Skills, die sie nachhält, und ein Vergleich der obersten Datei meldet einen Skill bereitwillig als identisch, während ein Reference Leaf darunter längst auseinandergelaufen ist. Stattdessen bekommt jeder Skill, jeder Agent und jedes Command einen Fingerprint über einen rekursiven Content Hash, damit der Vergleich den Skill und alles darunter erfasst. Der Status wird berechnet statt behauptet, in vier Werten: identical, ahead, behind, diverged.
02

Auch ein Repository, das niemand geklont hat, driftet

Ein Inventar, das nur die Checkouts auf einer Maschine kennt, sieht ein Repository nicht, das dort nicht geklont ist: Seine Drift bleibt unsichtbar, bis eine Agent Session darauf läuft. Registrierte Scopes decken deshalb den globalen User Scope ab, lokale Repositories und Repositories, die direkt von GitHub gescannt werden, nicht nur die lokale Platte. Das Scannen über GitHub kam im Juni 2026 zusammen mit der Deployment Pipeline. Verglichen wird das Estate, das existiert, nicht der Teil davon, der gerade auf dem Laptop liegt.
03

Die Abweichung an der Datei festmachen

Ein Urteil auf Repository-Ebene sagt, dass etwas nicht stimmt, aber nicht, was zu reparieren ist, und am Ende kopiert jemand einen ganzen Skill-Ordner hinüber und hofft. Die Asset Ancestry zeigt Master Skills, Subskills und Reference Leaves als Hover-Baum über drei Ebenen, mit Verbindungslinien und einem Status Chip an jedem Knoten, dazu eine Meta-Chip-Leiste mit Type, Status, Anzahl der References, verknüpften Assets und Anzahl der Scopes. Die Datei, die abweicht, wird benannt: Der Fix betrifft ein Leaf und nicht ein ganzes Verzeichnis.
Abgleichen, ohne etwas kaputt zu machen 3 Schritte
04

Ein Asset syncen, nicht das ganze Repository

Ein pauschaler Sync über das ganze Repository überschreibt die Kopie, die jemand bewusst vorangebracht hat, und kostet dann mehr als die Drift, die er behebt. Stattdessen laufen drei Operationen pro Asset: Push schickt die aktuelle Version nach außen, Pull holt eine neuere Version herein, und Adopt nimmt eine bisher nicht verwaltete Kopie ins Inventar auf. Ein abgewichener Skill wird gelöst, ohne dass etwas daneben angefasst wird, und ein Repository, das absichtlich vorne liegt, bleibt vorne, bis jemand anders entscheidet.
05

Das Backup wird vor dem Überschreiben geschrieben

Ein unbeaufsichtigter Sync ist nur etwas wert, wenn sich ein schlechter rückgängig machen lässt, und die meisten Tools schreiben zuerst die Datei und entschuldigen sich danach. Vor jedem Überschreiben wird ein Backup mit Zeitstempel geschrieben, und eine Diff-Ansicht zeigt vorher, was sich ändern wird. Genau diese Reihenfolge macht die Operation zu etwas, das ein Agent ohne Aufsicht ausführen darf, denn die vorige Version liegt schon auf der Platte, wenn der Schreibvorgang ankommt.
06

Die Sessions verwalten ihr Tooling selbst

Governance, die nur in einer Oberfläche für Menschen existiert, erreicht die Sessions nicht, die die Drift verursachen und darunter leiden. Dieselben Inventory- und Sync-Operationen liegen als drei MCP Tools bereit, harness_inventory, harness_asset und harness_sync, über einen HTTP Endpoint auf /mcp, geschützt durch denselben Microsoft Entra ID Zugang wie die Oberfläche. Eine Claude Code Session fragt, welchen Repositories der aktuelle angular-conventions Skill fehlt, und repariert sie über harness_sync, ohne das Dashboard zu öffnen.
Beobachten, was läuft 2 Schritte
07

Zeigen Sie, ob der Slot antwortet, nicht ob er deployed wurde

Eine Karte, die das letzte erfolgreiche Deployment meldet, liest sich als läuft, während der Slot steht, und sonst erfährt es nur, wer den Betreiber fragt. Seit 2026-07-31 gibt es Live Runtime Health pro Anwendung, getragen von /health- und /about-Endpoints auf jedem Slot mit den Deployment-Infos, sodass eine Karte eine echte Antwort abbildet. Sechs geroutete, deep-linkbare Views decken das Estate ab: Ein bestimmter Slot geht als Link an die Kollegin und nicht als Dashboard plus zweimal klicken.
08

Preview gegen Production, als Drift Report

Niemand vergleicht zwei Umgebungen von Hand, also findet ein Ausfall den Unterschied. Jede Einstellung wird pro Anwendungskomponente über beide Slots verglichen, und jeder Unterschied wird als beabsichtigtes Design oder als Drift eingestuft. So hält die Liste echte Abweichungen, statt sich mit gewollten zu füllen und ignoriert zu werden. Secrets erscheinen als Name und Ort, nie als Wert. Dieselbe Liste führt ein veraltetes Manifest oder einen DNS-Eintrag, der auf eine Box zeigt, die niemandem mehr gehört.
Aus der Routinearbeit wird ein Skill 2 Schritte
09

Ein unbeaufsichtigtes Audit, das den Tracker nicht flutet

Repository-Hygiene und der Verfall auf den Seiten gehören allen, also niemandem, und ein Report, den niemand öffnet, ändert daran nichts. Ein wöchentlicher agentic Workflow, von gh-aw in eine gelockte Workflow-Datei kompiliert, sammelt über Google PageSpeed Insights die Core Web Vitals und die On-Page-SEO-Signale der Production-Seiten und legt genau ein priorisiertes Improvement Issue an. Er läuft mit reinen Leserechten auf dem Repository, einer expliziten Network Allowlist und einem gedeckelten Safe Output.
10

Die Routinearbeit wird samt ihren harten Regeln verpackt

Die Dokumentation, die ein Neuzugang liest, verfällt als Erstes, sobald eine Routinearbeit niemandem konkret gehört. Ein benannter Skill erzeugt das README eines Repositories neu, aus dem Repository selbst: was es ist, sein Deployment-Diagramm, seine Adressen pro Umgebung oder Slot, seine Datenbanken und seine Authentifizierung. Zwei harte Regeln halten ihn ehrlich: herausfinden statt erfinden, unbekannte Werte werden als TBD geschrieben, und niemals ein Secret ausgeben, sondern die git-ignorierte Datei nennen statt den Wert.

Häufige Fragen

Woher weiß das Tool, dass ein Skill abgewichen ist?
Über einen Fingerprint mit rekursivem Content Hash: Der Vergleich erfasst den Skill und jedes Reference Leaf darunter, nicht nur eine oberste Datei. Jeder registrierte Scope liest dann identical, ahead, behind oder diverged, berechnet im Moment der Abfrage statt deklariert in einer Liste, die jemand pflegen muss. Die Scopes decken den globalen User Scope ab, lokale Repositories und Repositories, die direkt von GitHub gescannt werden.
Was verhindert, dass ein Sync die Lage verschlechtert?
Drei Dinge. Die Operationen laufen pro Asset, ein einzelner abgewichener Skill wird also gelöst, ohne dass etwas daneben angefasst wird. Eine Diff-Ansicht zeigt vorher, was sich ändern wird. Und vor jedem Überschreiben wird ein Backup mit Zeitstempel geschrieben, ein schlechter Sync ist damit umkehrbar statt endgültig. Push, Pull und Adopt decken ab: eine Version nach außen schicken, eine neuere hereinholen und eine bisher nicht verwaltete Kopie ins Inventar aufnehmen.
Kann ein Agent das erledigen, ohne dass jemand ein Dashboard öffnet?
Ja, und genau darum geht es, denn die Agent Sessions verursachen die Drift und leiden darunter. Drei MCP Tools, harness_inventory, harness_asset und harness_sync, liegen über einen HTTP Endpoint auf /mcp bereit, geschützt durch denselben Microsoft Entra ID Zugang wie die Oberfläche. Eine Claude Code Session fragt, welchen Repositories der aktuelle Conventions Skill fehlt, und synct sie in derselben Konversation.
Was zeigt die Betriebsseite des Estate?
Sechs geroutete, deep-linkbare Views. Live Health pro Anwendung, getragen von /health- und /about-Endpoints auf jedem Slot, sodass eine Karte eine echte Antwort abbildet und nicht ein vergangenes Deployment. Ein klickbares Deployment-Diagramm aus den Deployment-Manifesten. Preview gegen Production als Drift Report, jeder Unterschied als beabsichtigtes Design oder als Drift eingestuft, Secrets als Name und Ort. Und eine Quality View, die die ungetesteten Surfaces als Lücken benennt.