# Arbeitsweise in diesem Projekt

## Prüfen statt raten

Nichts annehmen, was sich messen lässt. Verhalten von Bibliotheken, Routen,
Headern und Konfiguration am laufenden System oder in der Dokumentation
**nachsehen**, bevor darauf gebaut wird. Was sich nicht klären lässt: **fragen**,
statt etwas zu bauen, das plausibel aussieht.

Der Grund steht in der Projektgeschichte: eine plausible Annahme, die falsch
ist, fällt Stunden später auf und kostet dann genau die Zeit, die das Nachsehen
gespart hätte. Beispiele aus diesem Repo, alle erst beim Messen aufgefallen:

- `c.req.path` trägt in Hono den Einhängepunkt mit — Löschen und `exists`
  sahen deshalb am Ziel vorbei.
- Ein Sternchen wird von Hono nicht als Parameter erfasst, `:pfad{.+}` schon,
  und der Parameter kommt bereits dekodiert.
- `createReadStream` meldet eine fehlende Datei asynchron; das `try/catch`
  darum fängt nichts.
- Ein Secure-Cookie über `localhost` funktioniert, über eine LAN-Adresse nicht
  — wer auf localhost gegenprüft, prüft die Ausnahme.

**Im Bericht steht, was gemessen wurde, nicht was erwartet wurde.** Ungeprüftes
wird als ungeprüft benannt — siehe die Docker-Abschnitte in `ROADMAP.md`.

## Wo es langgeht

`ROADMAP.md` ist der Einstieg: Zuschnitt, Stand, Reihenfolge, offene
Entscheidungen. Das Warum einer Änderung steht in der Commit-Nachricht, nicht
nur im Diff.

## Git

Alles läuft auf **`master`**, keine Feature-Branches. Gehostet auf dem eigenen
Gitea (`https://git.d4rkst3r.de/D4rkst3r/d4rk_media`); Lesen geht anonym,
Schieben über die Umgebungsvariable `GITEA_TOKEN`.

## Die eine Regel fürs Dashboard

**Jeder Knopf gibt Rückmeldung, auch der erfolgreiche.** Das ist der Fehler, an
dem der Fivemanage-Anlauf gescheitert ist: ein Knopf ohne Antwort sieht aus wie
ein kaputter Knopf, und das Ergebnis waren neunzehn gleichnamige
Organisationen. Gilt auch für die API — kaputtes JSON bekommt einen 400 mit
Text, keinen nackten 500.