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.

Mit dem Code abgleichen

Das ⌗-Icon prüft die andere Frage: bilden alle Karten zusammen ab, was das Programm kann? Gesucht werden Lücken — Fähigkeiten ohne Funktion auf einer Karte.

1 Inventar    quellcode.py  Bedienstellen aus dem Code, deterministisch
2 Abdecken    6 Stimmen     deckt eine bestehende Funktion die Stelle ab?
3 Ergänzen    Code          5 von 6 sagen nein -> Vorschlag mit Fundort

Inventar. interaktionen() liest die Stellen aus, an denen ein Mensch etwas auslöst: Ereignisse im Markup und Einträge der Kontextmenüs. Zusammengefasst nach dem aufgerufenen Namen — starte('ziel') steht zwölfmal da und ist eine Fähigkeit. Ein Modell hatte die Liste anfangs frei aufgezählt: jede Runde eine andere.

Nicht im Inventar: Backend-Routen (die Verdrahtung hinter den Knöpfen), Zuweisungen, Speichern beim Verlassen, Abbrechen mit Escape.

Abdecken. Je Stelle eine Ja/Nein-Frage, mit dem Code-Umfeld, dem Rumpf der Funktion dahinter und dem vollen Text aller Karten. Nur Titel reichten nicht — der Richter musste raten und urteilte jede Runde anders.

Schwelle. Fünf von sechs Stimmen. Einstimmigkeit war 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.

Jeder Vorschlag nennt seinen Fundort als datei:zeile. Die Gegenrichtung — „diese Funktion hat keinen Code, weg damit" — ist bewusst nicht eingebaut: ein Nichtvorhandensein lässt sich nicht belegen, und die Vorschläge zielten wiederholt auf gültige Inhalte. Karten dürfen Dinge festhalten, die kein Knopf sind.

Gemessen an diesem Projekt: auf den unsynchronisierten Karten findet der Abgleich die offenen Stellen, nach dem Übernehmen dreimal hintereinander nichts mehr.

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.