FunktionDashboard
Jeder Run, den ihr je gefahren habt, liegt noch offen
Zuletzt aktualisiert:
Der Workspace
Acht Ansichten, und die Standards, mit denen jeder Run beginnt
| Ansicht | Wofür sie da ist |
|---|---|
| Workspace | Project Knowledge: die Dokumente, Entscheidungen und Konventionen, nach denen dieses Projekt arbeitet, an einer lokalen Stelle statt in sechs Köpfen. Das ist es, was den zweiten Run auf denselben Standard bringt wie den ersten. |
| Runs | Jeden Run, laufend und historisch, aufgelöst über die exakte ID und Neustarts überdauernd. Der von vor sechs Wochen öffnet so bereitwillig wie der von heute Morgen. |
| Reviews | Das Trust Review je Run, und ehrlich gar nichts, solange eines aussteht. Es erfindet weder Ergebnis noch Review-ID, um die Lücke zu füllen. |
| Validation | Welche Checks freigegeben sind, welche Reality Graph selbst ausgeführt hat und welchen Exit-Code jeder zurückgab. |
| Evidence | Die geänderten Dateien, den Diff und die Belege hinter jeder Aussage des Ergebnisses. Hierhin geht ihr, wenn jemand fragt, woher ihr das wisst. |
| Roadmap | Das Live-Board. Eine Lane bewegt sich nur, wenn ein echtes aufgezeichnetes Ereignis das rechtfertigt; nichts auf diesem Bildschirm animiert, um beschäftigt auszusehen. |
| Content | Content-Governance für die Projekte, in denen sie greift. Überall sonst bleibt der Tab weg, statt euch eine leere Box zu zeigen. |
| Settings | Das Projekt, seine Route, seinen Freigabemodus und welche Agenten daran gebunden sind. |
Bei Project Knowledge lohnt das Innehalten. Standards, die in einem Wiki liegen, das niemand öffnet, sind Standards, denen der nächste Run nicht folgt. Also liegen sie neben der Arbeit: kopiert in einen lokalen, git-ignorierten Speicher, als Metadaten dargestellt, nie ausgeführt und nirgendwohin gesendet. Dateien werden abgelegt, nicht indiziert, und das ist der bewusste erste Schritt und die ehrliche Beschreibung davon.
Warum ihr dem Bildschirm trauen könnt
Das Dashboard zeigt an. Es entscheidet nicht.
run-4f2a, wie der Workspace ihn zeigt
Beispiel – illustrative Ansicht, keine echten Run-Datenrun 4f2a beobachtet · claude code
mission Validierungsfehler im Checkout, Zahlungen unberührt
changed 3 Dateien, 412 Zeilen aus Git gelesen
checks pytest -q exit 0 von Reality Graph ausgeführt
verdict BLOCKED geschützter Pfad geändert
src/payments/gateway.py
review rv-91c geöffnet 14:22, geschlossen 14:31Jeder Wert auf diesem Bildschirm wurde einmal berechnet, vom selben Resolver, den auch die CLI benutzt, und dann gerendert. Der Browser rechnet an euren Belegen nichts. Deshalb kann das Dashboard nicht vom Terminal abweichen, und deshalb ist ein Screenshot davon in einem Gespräch über das, was ausgeliefert wurde, etwas wert.
Die Review-Zusammenfassung hält einen Unterschied fest, den die meisten Werkzeuge verwischen: was deklariert und was belegt wurde. Eine Anforderung, die ihr aufgeschrieben habt, und eine, die ein ausgeführter Check bestätigt hat, sind zwei verschiedene Tatsachen, und sie stehen als zwei verschiedene da.
Bewusst so gebaut
Was dieser Workspace ist und was er bewusst nicht ist
Was ihr bekommt
- Jeden Run und jedes Review in einem lokalen Speicher, der Neustarts überdauert und über die exakte ID auflöst.
- Dieselbe kanonische Projektion, die die CLI druckt, in jeder Ansicht, ohne einen im Browser berechneten Zustand.
- Nur 127.0.0.1, eigene mitgelieferte Assets und keinen einzigen Aufruf ins Internet.
- Einen je Worktree isolierten Port, mit automatischem Ausweichen auf einen freien und der echten URL im Terminal.
- Eure Einträge als einfache lokale Dateien, auf Zuruf exportiert und vorher von Home-Pfaden und Secrets bereinigt.
Was es nicht ist
- Ein Team-Werkzeug. Ein Operator, eine Maschine, keine Konten, keine Anmeldung, kein Teilen.
- Eine zweite Meinung. Es kann kein Ergebnis erzeugen, das die CLI nicht erzeugen würde.
- Eine Voraussetzung. Startet es nicht, ist das eine Workspace-Einschränkung und euer Run läuft weiter.
- Ein gehosteter Dienst. Es gibt keinen Server zum Anmelden und nichts, was online bleiben müsste.
Wie das Ergebnis auf diesem Bildschirm berechnet wird, steht auf der Seite zum Ergebnis, und was eure Maschine nie verlässt, steht auf der Seite zum Datenweg.
Fragen, die wirklich gestellt werden
- Können Dashboard und CLI einen Run unterschiedlich darstellen?
- Nein. Beide rendern eine kanonische Projektion, und der Resolver für das Ergebnis hat im ganzen Produkt genau eine Aufrufstelle. Das JavaScript des Dashboards zeigt Zustand an, es berechnet keinen. Ein Bildschirm, der eine zweite Meinung erfinden kann, ist ein Bildschirm, den ihr nachprüfen müsst, und dann habt ihr zwei Quellen der Wahrheit statt keiner.
- Was sehe ich, während ein Run noch läuft?
- Den Run selbst, sofort. Workspace und Runs zeigen ihn in dem Moment, in dem euer Prompt ankommt, markiert als beobachtet. Reviews zeigt denselben unfertigen Run ehrlich an, solange das Trust Review aussteht: kein erfundenes Ergebnis, keine Platzhalter-ID. Beim Stop schließt genau dieser Run an Ort und Stelle ab.
- Wird irgendetwas in mein Netzwerk gestellt?
- Nichts. Es bindet 127.0.0.1 und verweigert jede andere Bind-Adresse, liefert seine eigenen Assets mit und lädt nichts aus dem Internet. Der Port ist je Worktree isoliert, zwei Projekte streiten sich also nie um einen. Ist euer bevorzugter Port belegt, nimmt es den nächsten freien und druckt die echte URL, statt abzubrechen.
- Was passiert, wenn das Dashboard nicht startet?
- Ihr arbeitet weiter. Ein Fehlstart wird als Workspace-Einschränkung festgehalten und blockiert weder die Coding-Sitzung noch den Run noch das Review. Die CLI druckt dieselben Fakten, und der Eintrag auf der Platte ist derselbe Eintrag.
Öffnet den Workspace und lest den Run von letzter Woche
Den, den ihr längst ausgeliefert habt. Genau darum geht es auf dieser Seite: Der Eintrag ist noch da, und er sagt immer noch, was passiert ist.
Weiterlesen
Schritt 7 von 9