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.

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):

<!-- 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.