Eigene Anwendung

Fitnesstracker

Der laufende Beleg dafür, dass der Betrieb trägt — und zugleich die Stelle, an der seine Grenzen sichtbar werden

Zustand: In Arbeit
Stand: In Arbeit · von Agenten gebaut
Technik: TypeScript · Vite · Vitest · Docker auf Unraid · gebaut von den Agenten

Die Anforderung

Warum es gebaut wurde

Ein Trainings- und Ernährungstagebuch klingt einfach — genau deshalb war es der richtige Prüfstein. Die Anforderung lautete nicht „baut eine App", sondern: Ein fremdes Produkt soll von der Spezifikation bis zur bedienbaren Oberfläche durch den ganzen Betrieb laufen, ohne dass ich Code schreibe. Was dabei interessiert, ist nicht die App. Interessant ist, wo der Betrieb hält und wo er reißt: ob die Abnahmekriterien scharf genug sind, ob die Prüfungen wirklich messen, ob die Rollen die richtigen Grenzen haben.

Der Aufbau

Wie es aufgebaut ist

Das Produkt selbst ist überschaubar: ein Rechenkern für Zielwerte und Mengenumrechnung, darüber die Erfassung von Mahlzeiten und Trainings, ein Tagebuch mit Verlauf und eine Übersicht. Aufgeteilt ist es in Stufen, die aufeinander aufbauen — ohne startbares Gerüst mit Navigation lässt sich nichts anderes ansehen oder prüfen. Gebaut wird das von denselben Rollen wie jedes andere Projekt: Spezifikation, Architektur, Bau, Prüfung, Abnahme.

Der Ablauf

Was der Betrieb dabei über sich selbst gelernt hat

Spezifikation vor Bau
Stufen mit Abnahmekriterien, bevor eine Zeile entsteht. Ein Auftrag ohne prüfbares Kriterium wird nicht disponiert — das hat mehrere Aufträge in den Entwurf zurückgeschickt.
Grundlage zuerst
Rechenkern und Navigation vor den Bereichen, die darauf aufbauen. Einmal richtig gerechnet und geprüft erspart denselben Fehler an drei Stellen.
Prüfungen, die auch messen
Ein Auftrag zur Lesbarkeit lieferte gemessene Kontrastwerte und Trefferflächen — und die Gegenprobe dazu: Reparatur zurückgedreht, Prüfung fällt durch, zurückgestellt, Prüfung grün.
Fehlende Ausstattung wird benannt
Ein Bauender ohne Browser-Werkzeug kann keinen Bildnachweis auf Telefonbreite führen. Das ist kein Baufehler, sondern eine Lücke in der Ausstattung — und wird als solche vermerkt statt als Versagen.
Leerlauf wird sichtbar
Ein Auftrag lief 444 Läufe, obwohl er nach dem ersten fertig war: Jeder Nachlauf prüfte erneut und fand dasselbe. Der Betrieb hat das protokolliert — und daraus die Regel abgeleitet, dass ein erledigter Auftrag geschlossen gehört.

Die Entscheidungen

Was bewusst so und nicht anders gelöst ist

Ein fremdes Produkt als Prüfstein, kein eigenes
Hätte ich den Agenten etwas bauen lassen, das ich selbst gut kenne, hätte ich unbewusst nachgeholfen. Ein Ernährungstagebuch ist fachlich weit genug weg, dass Lücken in der Spezifikation als Lücken auffallen und nicht durch mein Vorwissen überbrückt werden.
Der Betrieb wird am Produkt verändert, nicht umgekehrt
Wo der Bau scheiterte, wurde die Ordnung nachgeschärft — Ausstattung der Rollen, Schärfe der Abnahmekriterien, Abbruch bei Leerlauf. Das Produkt ist das Werkstück; das eigentliche Ergebnis ist der Betrieb.
Kosten werden mitgeschrieben
Was der Bau bisher gekostet hat, steht in der Projektakte. Ohne diese Zahl lässt sich nicht beurteilen, ob ein Agentenbetrieb sich für eine Aufgabe lohnt — und bei kleinen, klar umrissenen Aufgaben tut er das oft nicht.

Die Gestaltung

Wie es aussieht — und warum

Die Gestaltung ist bewusst zurückhaltend und für das Telefon gebaut: große Trefferflächen, lesbare Kontraste, keine Zierde. Sie wird gemessen statt beurteilt — Kontrastwerte und Trefferflächen sind Abnahmekriterien wie jedes andere.

Der Nachweis

Das Projekt läuft und ist noch nicht fertig — das gehört zur Darstellung. Nachweisbar ist bisher: Der Rechenkern steht mit 63 grünen Tests, die Typprüfung läuft ohne Abschalter, und die Oberfläche entsteht stufenweise. Alle Aufträge, Belege und Fehlschläge dazu liegen in derselben Akte wie bei jedem anderen Projekt.

Weiter