Wie es weitergeht, Ausgabe 1: nachgemessen, abgesichert, richtiggestellt

Ab heute schreibe ich alle zwei Wochen auf, was sich in der Werkstatt bewegt hat, was ich dabei gelernt habe und was als Nächstes ansteht. Die Ausgaben erscheinen hier im Werkstatt-Log, jede mit Datum, damit sich der Verlauf nachlesen lässt. Den Entwurf soll künftig ein Agent vorbereiten; veröffentlicht wird er erst, wenn ich ihn gelesen und freigegeben habe.

Was sich bewegt hat

Die Startseite zeigt ihre Knöpfe jetzt auch auf dem Handy

Öffnet man die Seite auf einem Handy mit eingeblendeten Browserleisten, bleibt ungefähr ein Ausschnitt von 390 mal 664 Pixeln sichtbar. Genau dort habe ich nachgemessen, und keiner der beiden Knöpfe der Startseite lag im Bild: Der erste begann erst bei 770 Pixeln, der zweite bei 845. Wer die Seite öffnete, sah Überschrift und Einleitung, aber keinen Weg weiter.

Engere Abstände allein hätten nur etwa 85 der nötigen 150 Pixel gebracht. Deshalb ordne ich die Blöcke auf dem Handy jetzt anders an. Zuerst kommt die Überschrift, danach die Zeile mit Abschluss, Standort und Schwerpunkt, anschließend die beiden Knöpfe und erst dann der längere Einleitungstext. Auf dem Desktop bleibt die Reihenfolge, wie sie war. Nachgemessen liegen beide Knöpfe jetzt vollständig im ersten Bildschirm.

Die Website baut ohne fremden Schlüssel

Zwei kleine Pakete mit Farben, Schriften und Grundbausteinen der Oberfläche habe ich bisher aus einer privaten Paketquelle geladen. Anfang September lief der Zugangsschlüssel dafür ab, und der Build scheiterte, ohne dass es sofort auffiel. Jetzt liegen beide Pakete als Archiv direkt im Repository der Website, und der Build kommt ohne Schlüssel aus.

Dass das wirklich stimmt, habe ich nicht aus einem grünen Build geschlossen, denn der hätte auch aus einem lokalen Zwischenspeicher bedient werden können. Stattdessen habe ich die Website in ein leeres Verzeichnis kopiert und mit einem leeren Paketspeicher installiert. Alle 678 Pakete kamen dabei frisch aus dem Netz, keines aus der privaten Quelle. Der erste echte Build beim Hoster lief anschließend ebenfalls ohne Schlüssel durch.

Ein Sachfehler in den Fünf Fragen

Auf der Seite Systeme & Projekte führen fünf Fragen durch die Projekte. Die vierte fragt, wie ich ein zweites Modell prüfen lasse, und nannte als Beispiel einen Stopp bei schlechteren Lighthouse-Werten. Beim Nachlesen fiel auf, dass dieser Mechanismus zu evolab gehört und nicht zur dual-bridge, auf die die Karte verweist. Jetzt steht dort, was die dual-bridge tatsächlich tut: Codex prüft auf einem zweiten Gerät, was Claude gebaut hat, und erst ein positives Urteil gibt den nächsten Schritt frei. Die Grenze steht gleich daneben, denn das Urteil ersetzt nicht meinen Abgleich mit dem Stand im Repository.

OpenClaw steht jetzt in der Navigation

Den zweiten Agentenhost, über den ich im letzten Beitrag geschrieben habe, findet man jetzt im Menü und im Seitenfuß, dazu mit einem Eintrag im Glossar. Er steht unter den Experimenten und nicht unter den Kernprojekten, weil OpenClaw ein fremdes Framework ist und noch nicht entschieden ist, ob es dauerhaft bleibt.

Was ich dabei gelernt habe

Eine Messung braucht eine Messbasis, die man selbst mitprüft. Bei der ersten Messung im lokalen Browser kamen für ein 390 Pixel breites Fenster plötzlich 520 Pixel heraus. Der Browser hatte für die lokale Adresse eine Vergrößerung von 75 Prozent gespeichert, und erst als ich das Pixelverhältnis mitgemessen habe, fiel die Abweichung auf. Seitdem gehört dieser Wert zu jeder Layout-Messung dazu.

Ein zweites Modell hat gefunden, was beim Bauen durchgerutscht war. Nach der Umstellung der Pakete hat Codex die Änderungen gegen meinen Auftrag gelesen und im Skript, das die Pakete künftig aktualisiert, einen Fehlerpfad gefunden: Es hätte die alten Archive gelöscht, bevor sicher war, dass die neuen Einträge geschrieben werden können. Kaputt war heute nichts, beim nächsten Update wäre es aber passiert. Das Skript prüft jetzt zuerst und löscht zuletzt.

Zudem stand ein erster Vorschlag, die Zeile mit Standort und Schwerpunkt auf dem Handy einfach auszublenden, im Widerspruch zu meiner eigenen Vorgabe. Die verlangt ausdrücklich, dass diese Zeile auf jedem Bildschirm sofort sichtbar ist. Aufgefallen ist das beim Lesen des Codes, bevor etwas umgesetzt war.

Wie es weitergeht

Die nächsten zwei Wochen gehören vor allem den Texten. Auf den Werkstattseiten stehen noch Überarbeitungen aus einer Sprachprüfung vom Juli aus, dazu einige Übergangssätze zwischen den Seiten. Für dual-bridge, evolab und living-vault fehlen noch die kurzen Kästen mit Fakten und Grenzen, die die übrigen Systemseiten schon haben. Außerdem plane ich eine feste, regelmäßige Prüfung der Website von außen.

Wie künftige Ausgaben dieser Serie entstehen sollen, zeigt das folgende Diagramm. Zunächst sammelt ein geplanter Lauf die Commits, offenen Aufgaben und Sitzungsnotizen der letzten zwei Wochen und schreibt daraus einen Entwurf. Danach kommen automatisch Screenshots der geänderten Seiten dazu, und eine Datenschutzprüfung sortiert aus, was nicht öffentlich gehört. Anschließend lese und überarbeite ich den Entwurf, und erst mit meiner Freigabe wird er veröffentlicht.

%% alt: Geplanter Ablauf einer Ausgabe: Quellen der letzten zwei Wochen, Entwurf durch einen Agenten, automatische Screenshots, Datenschutzprüfung, Redigat und Freigabe durch Dominic, Veröffentlichung im Werkstatt-Log
flowchart TD
  A[Commits, Aufgaben, Notizen] --> B[Entwurf durch Agent]
  B --> C[Screenshots]
  C --> D[Datenschutzprüfung]
  D --> E[Redigat und Freigabe]
  E --> F[Werkstatt-Log]

Was offen bleibt

Ob die Fünf Fragen Besucher tatsächlich besser durch die Seite führen, kann ich noch nicht sagen. Dafür fehlt mir eine Vergleichsmessung aus der Zeit davor, und ohne sie wäre jede Aussage darüber geraten. Auch die Automatik für diese Serie ist noch nicht gebaut: Die ersten ein, zwei Ausgaben entstehen bewusst ohne sie, damit sich zuerst das Format bewährt.