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:5274make build && make web— Produktion: http://localhost:8200make 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):
<!-- 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.