planer2/README.md

# Planer2 — Feature-Verwaltung

Verwaltet Features meiner Projekte als Cards und definiert damit die „Wahrheit" je Projekt.
Rein manuelle Pflege: Sidebar links = Projekte, Hauptbereich = Feature-Cards.

- `make dev` — Entwicklung: Backend auf 8200, Frontend auf http://localhost:5274
- `make build && make web` — Produktion: http://localhost:8200
- `make test` — Backend-Tests

## Karten prüfen

Das ⌾-Icon in der Sidebar prüft alle Karten des aktiven Projekts gegen den Stil-Katalog.
Fehlerhafte Karten öffnen sich rot markiert und zeigen unter jeder Stelle einen Vorschlag
mit ✓/✕; ✓ schreibt ihn in die Datei, die übrigen Vorschläge bleiben stehen. Unter dem
Icon steht der Fortschritt, rechts läuft ein Panel mit Problemliste.

Die Prüfung soll ein Format erzwingen, nicht Geschmack durchsetzen. Darum vier
Sperren gegen Beliebigkeit — jede einzeln nachgemessen:

```
1 Messen        struktur.py  Wortzahl, Satzzeichen, Füllwörter, Klammern, Badge
2 Umschreiben   4 Stimmen    ganze Felder neu, nicht einzelne Zeilen
3 Belegen       Code         Änderung nur mit wörtlich zitierter Katalogzeile
4 Nachmessen    struktur.py  Vorschlag, der selbst verstößt, wird abgelehnt
```

**Messen.** Was sich zählen lässt, zählt der Code. Was er wegstreichen kann, wird zum
fertigen Vorschlag. Der Rest hängt als Auftrag „Gemessen, bitte neu schreiben" am
Ausschnitt. Diese Zeilen stehen im Katalog unter `## Vom System gemessen` und sind
nicht zitierbar — sonst beruft sich das Modell auf die Füllwortliste und wendet sie
auf Wörter an, die nicht darin stehen.

**Umschreiben.** Das Modell zeigt auf keine Zeile, es schreibt das ganze Feld neu.
Adressierung war die größte Fehlerquelle: verschmolzene Zeilen, erfundene Zeilen,
Zeilen aus dem Kontextblock. Welche Zeile sich geändert hat, rechnet `_stellen` aus.
`original` ist damit immer echter Kartentext.

**Belegen.** Jede Änderung nennt die verletzte Katalogzeile, wörtlich. Der Code prüft
sie gegen den Katalog. Ohne Beleg keine Änderung. Ohne diese Sperre findet ein Modell
immer irgendetwas zu verbessern.

**Vier Stimmen, einstimmig.** Dieselbe Stelle wird viermal beurteilt, mit steigender
Temperatur. Nur was alle vier bemängeln, wird ein Vorschlag; die Formulierung kommt
aus der Fassung, die den anderen am ähnlichsten ist. Grenzfälle sehen mal so, mal so
aus — einzelne Stimmen ließen jede Runde andere Felder aufschlagen.

Gemessen an den Karten dieses Projekts, 35 Prüfstellen:

```
ohne diese Sperren   41 Vorschläge, 12 davon systematisch kaputt
mit                   4 Vorschläge, 0 kaputt
nach dem Annehmen     2 -> 1 -> 2   Ruhezustand
```

Eine Anfrage je Prüfstelle und Stimme, nicht je Karte:

```
Karte ──┬── Kartenebene    titel · badge · ziel · regeln
        ├── Funktion 1     titel · ziel · regeln · testen
        └── Funktion 2     …
```

Ein Vorschlag ersetzt seine Stelle eins zu eins. Was das bewirkt, sagt der Prüfer
nicht — es ergibt sich aus dem Vergleich:

```
eine Zeile      schreibt die Stelle um
mehrere Zeilen  ersetzen die Stelle durch alle davon; steht die alte
                wieder vorn, kommt nur etwas dazu
leer            streicht die Stelle
```

Vorschläge werden einzeln und in beliebiger Reihenfolge angenommen. Jeder muss darum
für sich allein anwendbar sein. Baut das Modell eine ganze Liste um, wird daraus ein
einziger Vorschlag für das Feld — einzelne Zeilen daraus ergäben Dubletten oder Lücken.

Jede Anfrage bekommt nur ihren Ausschnitt der Karte und nur den Katalogteil, der für sie
gilt. Die Herkunft eines Problems stammt aus dem Code, nicht aus der Modellantwort.

## Abgleich mit dem Code

Zwei weitere Prüfungen, in beide Richtungen. Beide arbeiten mit derselben
Beweislast, nur andersherum: ein Vorhandensein lässt sich zitieren, ein
Nichtvorhandensein nicht.

```
↧  Features im Code   steht hinter jeder Funktion auch Code?
↥  Code in Features   hat jede Bedienstelle auch eine Funktion?
```

**↧ Features im Code.** Je Funktion sechs unabhängige Versuche, die Codestelle zu
finden. Jeder Fund wird gegen die Datei geschlagen. Gemeldet wird erst, wenn keine
einzige Stimme etwas findet — auch ein misslungenes Zitat gilt als Widerspruch, denn
ein verschriebener Backtick darf keine Löschempfehlung auslösen. Unter vier
brauchbaren Stimmen wird gar nicht erst angeklagt.

**↥ Code in Features.** Die Liste der Bedienstellen kommt aus dem Code, nicht aus
dem Modell: `quellcode.interaktionen()` liest Ereignisse im Markup, Kontextmenü-
Einträge und Fenster-Lauscher. Zusammengefasst nach dem aufgerufenen Namen —
`starte('ziel')` steht zwölfmal da und ist eine Fähigkeit. Je Stelle eine Ja/Nein-
Frage mit Code-Umfeld, Funktionsrumpf und dem vollen Text aller Karten; gemeldet ab
fünf von sechs Nein-Stimmen.

Nicht im Inventar: Backend-Routen (jede hängt an einem Knopf, der schon dasteht),
Zuweisungen, Speichern beim Verlassen, Abbrechen mit Escape.

**Warum diese Schwellen.** Einstimmigkeit war für ↥ zu scharf: dieselbe Frage kippt
auch bei Temperatur 0 gelegentlich, und ein Ausreißer löschte klare Funde.
Eindeutige Stellen antworten 6:0 oder 0:6, Grenzfälle etwa 3:3. Für ↧ gilt das
Gegenteil — dort ist die Anklage destruktiv, also blockiert schon eine
widersprechende Stimme.

Nachgemessen an diesem Projekt: auf gepflegten Karten melden beide nichts. Eine
untergeschobene Funktion ohne Code fällt ↧ in jedem Lauf auf. Fehlende Funktionen
findet ↥, nach dem Übernehmen ist es still.

Der Katalog liegt in `backend/stil/` — eine Datei je Feld, alphabetisch zusammengesetzt
(`allgemein` landet dadurch vorn). Das Präfix entscheidet, wer sie zu sehen bekommt:

```
allgemein.md      beide Prüfer
feature-*.md      nur die Kartenebene:  titel, badge, ziel, regeln
funktion-*.md     nur die Funktionen:   titel, ziel, regeln, testen
```

Eine neue Datei wird ohne Codeänderung mitgelesen. Ist der Ordner leer, bricht die
Prüfung ab statt ohne Vorgaben zu prüfen.

Zugang über `.env` (Vorlage: `.env.example`) — `MINIMAX_API_KEY`, `MINIMAX_MODELL`,
`MINIMAX_URL`, dazu `PRUEFUNG_PARALLEL` (gleichzeitig laufende Anfragen, Standard 10).
Fehlt einer der Zugangswerte, bricht die Prüfung mit sichtbarer Meldung ab;
es wird nie still auf ein anderes Modell ausgewichen. Ergebnisse liegen nur im
Serverspeicher und überleben keinen Neustart.

## Datenablage

Markdown-Dateien unter `daten/<projekt>/<feature>.md` — Projekt = Ordner, die Datei ist
die Wahrheit. Der Editor bearbeitet immer den rohen Text; geparst wird nur für die Anzeige.

Format (Marker allein auf einer Zeile; `<!-- funktion -->` ist wiederholbar; `<!-- ziel -->`,
`<!-- regeln -->` und `<!-- testen -->` nach einer Funktion gehören zu ihr — `ziel`/`regeln`
vor der ersten Funktion gehören zur Karte; regeln/testen: je eine `- `-Zeile pro Eintrag;
`<!-- regel -->`-Blöcke aus dem Alt-Format werden zu Zeilen zusammengeführt;
Trennzeilen aus `---` sind Optik):

```markdown
<!-- titel -->
Login
<!-- art -->
kern
<!-- ziel -->
Kurzer Satz, was das Ziel ist.
<!-- funktion -->
Anmeldung mit E-Mail
<!-- regeln -->
- Passwort nie loggen
<!-- testen -->
- Formular öffnen
- Daten eingeben
<!-- funktion -->
Abmeldung
```

Der Kompaktmodus zeigt Ziel und Funktionstitel, der Vollmodus alles — umgeschaltet per
mittlerer Maustaste auf die Karte oder das Augen-Icon. Bearbeitet wird nur im Vollmodus:
Klick auf den Text, Verlassen speichert, Escape verwirft; Anlegen und Entfernen laufen
über das Kontextmenü (Rechtsklick) mit Bestätigung im Modal. Jedes Speichern setzt die
Datei neu zusammen, Titeländerungen benennen sie passend um.

Text vor dem ersten Marker, Inhalt unbekannter Marker und verwaiste regeln/testen-Blöcke
(auch Alt-Marker `flow`) werden nicht angezeigt, aber beim Speichern erhalten.

Hinweis: Sektionen werden im Frontend als Markdown gerendert (`marked`, ohne Sanitizing) —
die Daten sind lokal und selbst geschrieben.