Jede Zahl aus dem gelesen, was läuft

Lesen Sie Einstellungen, Zeitpläne, Logs und Lizenzunterlagen von den laufenden Systemen ab und schreiben Sie ein Quellenblatt, das zu jeder Zahl nennt, woher sie kommt.

Ein Feld ohne Quelle bleibt sichtbar leer, mit der Begründung am Bildschirm: Eine Null heißt geprüft und nichts gefunden, leer heißt noch nicht nachgesehen, und der nächste Schritt ist ein anderer. Passwörter und Access Keys zeigen Sie als Name und Ablageort. Geschäftszahlen wie Mitgliederzahlen und Umsatz bleiben aus der Ansicht, und Compliance klären Sie im selben Durchgang.

Pläne so konkret geschrieben, dass sie auf Papier scheitern können

Schreiben Sie den Plan mit den genauen Screens, den genauen Datenfeldern und der genauen Reihenfolge, damit eine falsche Annahme auffällt, solange sie noch auf Papier steht.

Beginnen Sie bei einem erprobten Build und behandeln Sie ihn als Spezifikation: Struktur, Screen-Layout und Navigation werden übernommen, geändert wird pro Kunde nur das Aussehen. Auf jedem Projekt gilt dieselbe feste Reihenfolge, und was ein Durchgang gelehrt hat, schreiben Sie einmal auf, in die Datei, die der nächste Durchgang liest.

Jeder Plan stützt sich auf Systeme, die schon gebaut sind

Bringen Sie das Fachwissen in die Lektüre mit. Systeme für Terminplanung, Buchhaltung, Medien und Estate wurden hier gebaut und betrieben, deshalb stellt der Durchgang ab dem ersten Tag die Fragen, die solche Builds entscheiden: welcher Datensatz der Master ist, wo der Write Path verläuft, was das bestehende Lizenz- und Berechtigungsmodell ohnehin erzwingt.

Die aufgezeichneten Failure Modes gehen als Randbedingungen in den neuen Plan: ein Import, der jeden Datensatz löscht, den er nicht bekommt, ein Asset-Pfad, der statt eines Fehlers eine still leere Library liefert, eine Promotion, die erst zählt, wenn der Digest übereinstimmt. Jede davon steht als Schritt im Plan, und wer das Ergebnis misst, verändert es nie.

5
Reader Agents lesen die Source Artifacts
6
parallele Build Tracks, ein gemeinsamer Contract
9
Fragen, die jede Aufgabe einem Weg zuordnen
3 von 5
Datenfiles bleiben absichtlich leer

Wie aus den Fakten ein Plan wird, gegen den sechs Tracks bauen können

Die Belege lesen 3 Schritte
01

Rule Zero: Jede Zahl mit einem Artifact belegt

Übertragen Sie jeden Container-Namen, jeden Port, jedes Image Tag, jede Domain, jede Datenbank, jede Stunde und jeden Euro aus einem Artifact, das das Repository bereits hält. Die genannten Quellen sind das Deployment Manifest, die Compose Files, die Edge Site Files, das Time Ledger, die Ausgabe des Test Reporters und die Commit History.
02

Provenance pro Datei, Fehlendes wird als Fehlendes gezeigt

Schreiben Sie ein Provenance-Dokument, das pro Datendatei festhält, woher jede Zahl kommt, und für eine Datei, die leer ausgeliefert wird, warum leer der richtige Zustand ist: kein Test-Report-Generator, keine Korrespondenz mit der Gegenseite, nie eine gestellte Rechnung. Ein Feld ohne Quelle zeigen Sie als gestalteten Empty State, mit der Begründung am Bildschirm.
03

Zwei Datenstände verglichen, jede Abweichung aufgelistet

Vergleichen Sie die Datenstände miteinander und listen Sie auf, wo sie sich widersprechen: ein veraltetes Manifest, ein DNS Record, der auf eine Box zeigt, die uns nicht mehr gehört, ein Runbook, das als nicht ausgeführt markiert ist, obwohl die Zone Files es als erledigt ausweisen. Nach einer Infrastruktur-Migration leiten Sie jeden Stack, jeden Service, jede Datenbank und jeden Drift-Eintrag neu aus den Manifests ab.
Den Contract festlegen, bevor jemand baut 3 Schritte
04

Ein Scaffold Contract, Interfaces wörtlich ausgeschrieben

Legen Sie einen gemeinsamen Scaffold Contract fest, bevor ein Build Track startet: den File Tree, den zuständigen Track pro Pfad und jedes gemeinsame TypeScript Interface, wörtlich ausgeschrieben. Schreiben Sie die Interfaces aus, statt sie zu beschreiben: Dann fällt eine falsche Signatur auf, bevor der erste Track läuft.
05

Sechs getrennte Tracks, ein Owner pro Pfad

Fahren Sie den Workflow in seiner festen Reihenfolge: Brand Capture, fünf Reader über die Source Artifacts, ein gemeinsamer Contract, sechs getrennte Build Tracks, Verification, danach vier Review-Lenses. Die Reference Implementation ist die Spezifikation: Struktur, Card Anatomy, Group Disclosure, Wrapper-Breiten und die Route Table werden übernommen, getauscht wird nur der Skin. Jeder Track besitzt seine eigenen Pfade.
06

Aus einer einfachen E-Mail wird ein dokumentiertes Work Item

Holen Sie die Anfrage mit Microsoft 365 Mail Intelligence direkt in der Repository-Session aus dem Postfach, prüfen Sie sie gegen die bestehende Codebase und schreiben Sie sie als dokumentiertes Work Item auf. Ein Batch mit fünf Punkten vom 4. August 2026 ging als ein Commit auf eine Preview-Adresse, die die Production Container gegen getrennte Testdaten fährt, und wurde promoted, sobald die Anfragenden zugestimmt hatten.
Über die Codebase hinaus 2 Schritte
07

Dieselben Reader laufen über Material, das kein Code ist

Lassen Sie denselben Durchgang über Dokumentenordner und Mediensammlungen laufen. Vier Medienprodukte wurden hier in ein Repository zusammengeführt: Ein History-Dokument hielt die exakten Source Commits und die Provenance pro Pfad fest, rekonstruierte die Timeline für diese Pfade und schrieb den Failure Mode am Asset Root auf: Ein falscher Asset-Pfad liefert eine still leere Library. Jede Sammlung endet mit demselben Urteil pro Element, mit der Begründung daneben.
08

Zeitaufzeichnungen und Test-Output sind ebenfalls Artifacts

Rekonstruieren Sie das Engagement aus dem Time Ledger: Geld und Assets im Detail pro Phase, Stunden-Panels pro Repository, deklarierte und abgeleitete Stunden gegeneinander abgeglichen. Eine Zahl ohne aufgezeichnete Session dahinter bleibt aus der Ansicht. Die Qualitätsfakten nehmen Sie aus der Ausgabe des Test Reporters pro Anwendung und leiten ungetestete Surfaces als Lücken ab.
Baseline und Compliance 2 Schritte
09

Eine Beobachtungswoche, danach ein Weg pro Aufgabe

Lassen Sie alle, die Büroarbeit machen, eine Woche lang ihre wiederkehrenden Aufgaben aufzeichnen, Teilzeitkräfte, Assistenz, Buchhaltung und Versand eingeschlossen, denn wer eine Aufgabe erledigt, kennt ihre Dauer. Bewerten Sie jede Aufgabe nach Minuten pro Durchlauf, Durchläufen pro Monat, Nacharbeit und sechs Eignungskriterien und gehen Sie danach den Entscheidungspfad aus neun Fragen der Reihe nach durch: Der erste Treffer gewinnt.
10

DSGVO und EU AI Act im selben Durchgang geklärt

Prüfen Sie die Systeme, die bereits in Production laufen, gegen DSGVO und den EU AI Act: Ordnen Sie die Risikoklasse zu und benennen Sie, wo personenbezogene Daten verarbeitet werden. Die Prüfung deckt außerdem ein Betriebskonzept mit Hosting in der EU ab, den praktischen Unterschied zwischen Team- und Enterprise-Lizenzbedingungen, die Datenschutzbedingungen pro angebundenem Service und eine Freigabekarte, die benennt, wer was freigibt.

Häufige Fragen

Was übergibt ein Fact-Gathering-Durchgang konkret?
Drei Dinge. Einen Scaffold Contract, der den File Tree, den zuständigen Track pro Pfad und jedes gemeinsame Interface wörtlich festlegt, damit sechs Tracks parallel bauen. Eine Provenance-Aufzeichnung, die zu jeder Zahl das Artifact nennt. Und eine Drift-Liste, die aufführt, wo zwei Datenstände sich widersprechen, etwa ein veraltetes Manifest oder ein DNS Record, der auf eine Box zeigt, die uns nicht mehr gehört.
Was passiert mit einer Zahl, die keine Quelle hat?
Sie erscheint als gestalteter Empty State, mit der Begründung am Bildschirm, und das Provenance-Dokument hält fest, warum leer richtig ist. Bei einem Build wurden drei von fünf Datenfiles absichtlich leer ausgeliefert: Es gab keinen Test-Report-Generator, keine Korrespondenz mit der Gegenseite und nie eine gestellte Rechnung.
Funktioniert das nur auf einer Codebase?
Dieselben Reader laufen über Media Libraries, Dokumentenordner sowie Zeit- und Abrechnungsdaten. Ein zusammengeführtes Medien-Repository trägt die Provenance pro Pfad und die exakten Source Commits, und eine Billing Journey rekonstruiert ein Engagement aus dem Time Ledger, damit deklarierte und abgeleitete Stunden übereinstimmen. Eine Zahl ohne aufgezeichnete Session dahinter taucht nie auf.
Ist die Prüfung nach DSGVO und EU AI Act ein eigenes Projekt?
Sie läuft im selben Durchgang, bevor AI an Unternehmensdaten kommt. Geprüft werden die Systeme, die bereits in Production laufen, die Risikoklasse wird zugeordnet und die Stellen benannt, an denen personenbezogene Daten verarbeitet werden. Aufgaben mit personenbezogenen Daten werden markiert und geprüft. Heraus kommen Checklisten pro Stakeholder-Rolle und Onboarding-Material, damit auch Menschen außerhalb der IT damit arbeiten können.