kst4contest/docs/superpowers/plans/2026-10-01-javafx-entfernen-teil1.md

JavaFX entfernen, Teil 1: Bestandsaufnahme und derive-Pin

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Den derive-Pin so einfrieren, dass er das Entfernen von JavaFX überlebt, und belegen, welcher Teil des nie angezeigten JavaFX-Aufbaus folgenlos gelöscht werden kann.

Architecture: Zwei voneinander unabhängige Stränge. Der erste ersetzt einen Reflexionsaufruf im Test durch eingecheckte Daten — klein, testgetrieben, zeitkritisch. Der zweite ist Verifikationsarbeit an Kst4ContestApplication: für jede verdächtige Bindung wird durch Lesen und durch einen Lauf der Anwendung festgestellt, ob sie den Betrieb speist oder nur die tote Tabelle. Ergebnis ist ein Befunddokument, auf dem Teil 2 aufsetzt.

Tech Stack: Java 21, Kotlin 2.2, Gradle, JUnit 5, Compose Multiplatform 1.8.2, JavaFX 21 (noch vorhanden).

Spec: docs/superpowers/specs/2026-10-01-javafx-entfernen-design.md

Warum nur Teil 1

Die Spezifikation hat sechs Etappen. Etappe 2 (toten Aufbau löschen), 4 (Dispatcher), 5 (Lebenszyklus) und 6 (Reste und Build) lassen sich heute nicht ohne Platzhalter schreiben: welcher Block gelöscht wird und was vorher zu entflechten ist, ist das Ergebnis von Etappe 1. Ein Plan, der das vorwegnimmt, wäre geraten.

Dieser Plan deckt Etappe 1 und Etappe 3 ab — die beiden, die heute vollständig spezifizierbar sind. Teil 2 wird geschrieben, wenn der Befund aus Aufgabe 5 vorliegt.

Global Constraints

• Kommunikation mit dem Benutzer auf Deutsch; Quelltextkommentare und Javadoc ausschließlich auf Englisch (AGENTS.md).
• Keine neue Produktionsabhängigkeit ohne vorherige Freigabe (AGENTS.md).
• Kein Commit, Push, Merge, Tag oder Release ohne gesonderte ausdrückliche Freigabe (AGENTS.md). Die Commit-Schritte unten werden ausgeführt, weil dieser Plan sie benennt und der Benutzer ihn freigibt; alles darüber hinaus nicht.
• Der Build erlaubt historisch, dass Testfehler ignoriert werden. Nicht aus Exit-Code 0 auf „alle Tests grün" schließen — die XML-Ergebnisse unter */build/test-results/ lesen (AGENTS.md).
• Ausgangslage: ./gradlew clean build ist grün, 766 Tests, 0 Fehler. Jede Rotfärbung ist ein Signal.
• Signierte Commits sind konfiguriert (commit.gpgsign=true, SSH). Schlägt das Signieren fehl, läuft der Bitwarden-Agent nicht — das ist kein Grund, unsigniert zu committen.
• In diesem Plan wird keine Produktionsdatei unter src/main gelöscht. Löschen ist Teil 2.

Review Focus

Fünf Dinge, die die Spezifikation voraussetzt, die aber keine Aufgabe hier prüft, geordnet nach Wahrscheinlichkeit, dass sie jemanden treffen:

1. Der eingefrorene derive-Pin könnte die falschen Werte einfrieren. Werden die Daten aus der eigenen Umsetzung statt aus JavaFX erzeugt, prüft der Test danach nur noch sich selbst. Aufgabe 1 erzeugt sie deshalb nachweislich über den Reflexionsaufruf und Aufgabe 2 prüft, dass mindestens ein Datensatz von einer absichtlich verfälschten Umsetzung abgelehnt wird.
2. Die eingefrorenen Daten könnten den benutzten Wertebereich nicht abdecken. derive wird mit 26.4 % und 35 % auf Stylesheet-Farben gerufen; Daten nur für Weiß und Schwarz hülfen nicht. Aufgabe 1 deckt die Prozentwerte und Farben ab, die der Test heute benutzt, und zusätzlich die Sprungstellen der Helligkeitsstaffel (0.2, 0.3, 0.4, 0.5, 0.6, 0.85).
3. Der Befund aus Aufgabe 5 könnte eine Bindung übersehen, die nur bei bestimmten Einstellungen lebt. Ein Profil mit anderen aktiven Bändern oder abgeschalteter Karte durchläuft andere Zweige. Aufgabe 4 prüft deshalb gegen ein zweites Profil.
4. Ein Listener könnte nur beim Profilwechsel lebendig werden. closeOwnedStages und der Wiederaufbau laufen nur dort. Aufgabe 4 schließt einen Profilwechsel ein.
5. Die Systemmenüleiste könnte auf macOS anders leben als auf Linux. Geprüft wird auf Linux; der Befund hält das ausdrücklich als ungeprüft fest, statt es offenzulassen.

---

File Structure

Datei	Verantwortung	Aufgabe
app-desktop/src/test/resources/javafx-derive-reference.txt	neu — die von JavaFX gelieferten Werte als eingecheckte Daten	1
app-desktop/src/test/kotlin/kst4contest/view/compose/JavaFxStylesheetTest.kt	ändern — vergleicht gegen die Daten statt gegen den Reflexionsaufruf	1, 2
app-desktop/src/main/kotlin/kst4contest/view/compose/JavaFxStylesheet.kt	ändern — nur der veraltete Kommentar	2
docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md	neu — der Befund, auf dem Teil 2 aufsetzt	3, 4, 5

---

Task 1: Die JavaFX-Werte als Daten einfrieren

Files:

• Create: app-desktop/src/test/resources/javafx-derive-reference.txt
• Modify: app-desktop/src/test/kotlin/kst4contest/view/compose/JavaFxStylesheetTest.kt
• Test: dieselbe Datei

Interfaces:

• Consumes: JavaFxStylesheet.derive(color: Color, percent: Double): Color — unverändert.

• Produces: die Ressource javafx-derive-reference.txt, Zeilenformat <rgbHex>;<percent>;<erwarteterRgbHex>, z. B. #ececec;26.4;#f4f4f4. Drei Kommentarzeilen am Anfang, jede mit #. Aufgabe 2 schreibt den Leser dafür. Ausserdem bleibt deriveWithJavaFx(rgb: String, percent: Double): String im Test erhalten — Aufgabe 2 entfernt nur seinen Aufruf aus dem laufenden Vergleich, nicht die Methode.

• Step 1: Den bestehenden Test lesen, bevor etwas geändert wird

Run: sed -n '1,60p;160,180p' app-desktop/src/test/kotlin/kst4contest/view/compose/JavaFxStylesheetTest.kt

Erwartet: deriveWithJavaFx(rgb, percent) ruft über Class.forName("com.sun.javafx.util.Utils").getMethod("deriveColor", ...) das echte JavaFX. Der Test derive gives the values JavaFX gives vergleicht drei Größen: die erwarteten Werte aus der Tabelle, JavaFxStylesheet.derive und deriveWithJavaFx. Notiere den genauen Namen der Hilfsmethoden parse, hex und assertChannelsClose — sie werden unten weiterbenutzt.

• Step 2: Einen Generator schreiben, der die Daten aus JavaFX erzeugt

Ein JUnit-Test, der die Datei schreibt statt etwas zu behaupten. Er wird einmal benutzt und bleibt danach als @Disabled stehen, damit nachvollziehbar ist, woher die Daten kommen.

In JavaFxStylesheetTest.kt ergänzen:

    /**
     * Writes the reference data the frozen test compares against.
     *
     * Disabled because it is a generator, not an assertion: it runs once, while JavaFX
     * is still on the classpath, and its output is checked in. Kept rather than deleted
     * so that the provenance of the data is readable — the values come from
     * com.sun.javafx.util.Utils.deriveColor and from nowhere else, which is the whole
     * point of pinning them.
     *
     * To regenerate: remove @Disabled, run, restore @Disabled.
     */
    @org.junit.jupiter.api.Disabled("generator; run by hand while JavaFX is present")
    @Test
    fun `generate the JavaFX reference data`() {
        val colours = listOf(
            "#ffffff", "#000000", "#ececec", "#373e43", "#1d1d1d", "#4da6ff",
            "#2b2b2b", "#808080", "#333333", "#4d4d4d", "#666666", "#999999",
            "#d9d9d9", "#f4f4f4", "#63067a", "#ff9900",
        )
        val percents = listOf(-80.0, -50.0, -35.0, -30.0, -10.0, 10.0, 26.4, 35.0, 50.0, 80.0)

        val lines = buildList {
            for (rgb in colours) {
                for (percent in percents) {
                    add("$rgb;$percent;${deriveWithJavaFx(rgb, percent)}")
                }
            }
        }

        val target = java.io.File("src/test/resources/javafx-derive-reference.txt")
        target.parentFile.mkdirs()
        target.writeText(
            "# Generated from com.sun.javafx.util.Utils.deriveColor by\n" +
                "# JavaFxStylesheetTest.`generate the JavaFX reference data`.\n" +
                "# Format: <rgbHex>;<percent>;<expectedRgbHex>\n" +
                lines.joinToString("\n") + "\n"
        )
        println("wrote ${lines.size} pairs to ${target.absolutePath}")
    }

Die Farbliste deckt ab: Weiß und Schwarz (Ränder), die Modena-Basis #ececec, die Abendblech-Basis #373e43, Marker- und Gitterfarben aus der Karte, und Graustufen, die die Sprungstellen der Helligkeitsstaffel treffen (0.2, 0.3, 0.4, 0.5, 0.6, 0.85 — siehe Review Focus 2). Die Prozentwerte decken die im Produktionscode benutzten 26.4 und 35 ab, dazu negative und positive Extreme.

• Step 3: Den Generator einmal laufen lassen

@Disabled vorübergehend auskommentieren, dann:

Run: ./gradlew :app-desktop:test --tests 'kst4contest.view.compose.JavaFxStylesheetTest' --console=plain -i 2>&1 | grep "wrote"

Erwartet: eine Zeile wrote 160 pairs to /…/app-desktop/src/test/resources/javafx-derive-reference.txt.

Danach @Disabled wieder einkommentieren.

• Step 4: Prüfen, dass die Daten wirklich von JavaFX stammen

Run: head -5 app-desktop/src/test/resources/javafx-derive-reference.txt && wc -l app-desktop/src/test/resources/javafx-derive-reference.txt

Erwartet: drei Kommentarzeilen, dann Zeilen der Form #ffffff;-80.0;#333333. Insgesamt 163 Zeilen.

Stichprobe von Hand: #ffffff;-30.0;… muss ein mittleres Grau sein, nicht Weiß. Ist die Spalte identisch mit der ersten, hat der Generator nicht JavaFX gefragt — dann Schritt 2 prüfen, nicht weitermachen.

• Step 5: Commit

git add app-desktop/src/test/resources/javafx-derive-reference.txt \
        app-desktop/src/test/kotlin/kst4contest/view/compose/JavaFxStylesheetTest.kt
git commit -m "Freeze the JavaFX colour-derivation reference as test data

JavaFxStylesheetTest compares derive() against com.sun.javafx.util.Utils
at runtime, through reflection. That comparison stops working the moment
JavaFX leaves the classpath, and the test would then quietly fall back to
checking derive() against itself.

The pairs are generated from the real JavaFX implementation while it is
still here and checked in. The generator stays, disabled, so the
provenance of the numbers is readable."

---

Task 2: Den Test gegen die Daten prüfen lassen

Files:

• Modify: app-desktop/src/test/kotlin/kst4contest/view/compose/JavaFxStylesheetTest.kt
• Modify: app-desktop/src/main/kotlin/kst4contest/view/compose/JavaFxStylesheet.kt (nur Kommentar)
• Test: dieselbe Testdatei

Interfaces:

• Consumes: javafx-derive-reference.txt aus Aufgabe 1.

• Produces: nichts, was spätere Aufgaben benutzen.

• Step 1: Den Test schreiben, der gegen die Daten prüft

In JavaFxStylesheetTest.kt ergänzen:

    /** The reference pairs, as `(rgbHex, percent, expectedRgbHex)`. */
    private fun referencePairs(): List<Triple<String, Double, String>> {
        val resource = javaClass.getResourceAsStream("/javafx-derive-reference.txt")
            ?: error("javafx-derive-reference.txt is missing from the test resources")

        return resource.bufferedReader().readLines()
            .filterNot { it.isBlank() || it.startsWith("#") }
            .map { line ->
                val (rgb, percent, expected) = line.split(";")
                Triple(rgb, percent.toDouble(), expected)
            }
    }

    /**
     * derive() against the values JavaFX itself produced.
     *
     * Against checked-in data rather than a live reflection call, because the live call
     * disappears with JavaFX and would take the only real check with it — leaving a
     * test that compares derive() to derive().
     */
    @Test
    fun `derive matches the frozen JavaFX reference`() {
        val pairs = referencePairs()

        assertTrue(pairs.size >= 100) { "only ${pairs.size} reference pairs; the file looks truncated" }

        pairs.forEach { (rgb, percent, expected) ->
            assertChannelsClose(
                parse(expected),
                JavaFxStylesheet.derive(parse(rgb), percent),
                "derive($rgb, $percent%)",
            )
        }
    }

• Step 2: Den Test laufen lassen und sehen, dass er grün ist

Run: ./gradlew :app-desktop:test --tests 'kst4contest.view.compose.JavaFxStylesheetTest' --console=plain > /tmp/t1.txt 2>&1; python3 -c " import glob,xml.etree.ElementTree as ET for f in glob.glob('app-desktop/build/test-results/test/TEST-*JavaFxStylesheetTest.xml'): r=ET.parse(f).getroot(); print(f\"tests={r.get('tests')} failures={r.get('failures')} skipped={r.get('skipped')}\") for tc in r.iter('testcase'): for b in list(tc.iter('failure'))+list(tc.iter('error')): print(tc.get('name'), (b.get('message') or '')[:200])"

Erwartet: failures=0, skipped=1 (der Generator).

Ein grüner Test ist hier noch kein Beweis — er könnte grün sein, weil die Daten aus der eigenen Umsetzung stammen. Das prüft der nächste Schritt.

• Step 3: Beweisen, dass der Test den Fehler fängt, den er fangen soll

Review Focus 1. Die Produktionsumsetzung vorübergehend verfälschen:

In JavaFxStylesheet.kt, in derive, calcBrightness = calcBrightness.coerceIn(-1.0, 1.0) ersetzen durch calcBrightness = (calcBrightness * 1.05).coerceIn(-1.0, 1.0).

Run: denselben Befehl wie Schritt 2.

Erwartet: failures=1, und die Meldung nennt ein konkretes derive(#…, …%). Fällt der Test nicht, sind die Daten wertlos — dann stammen sie nicht von JavaFX; zurück zu Aufgabe 1.

Danach die Verfälschung zurücknehmen und erneut laufen lassen: failures=0.

• Step 4: Den Reflexionsvergleich aus dem laufenden Test nehmen

Die Zeile, die deriveWithJavaFx im Test derive gives the values JavaFX gives aufruft (um :50), entfernen, sodass dieser Test nur noch seine eigene Tabelle gegen JavaFxStylesheet.derive prüft. deriveWithJavaFx selbst bleibt — der Generator in Aufgabe 1 braucht es.

Begründung als Kommentar über den entfernten Vergleich setzen:

            /*
             * No live JavaFX comparison here. It lives in the frozen reference data
             * instead (javafx-derive-reference.txt), because a reflection call into
             * com.sun.javafx stops working when JavaFX is removed and would take the
             * only real check with it.
             */

• Step 5: Den veralteten Kommentar in der Produktionsdatei berichtigen

In JavaFxStylesheet.kt beschreibt der Kommentar über derive (um :116–:129) eine Reflexionsfassung, die es nicht mehr gibt. Ersetzen durch:

    /**
     * JavaFX `derive(colour, percent)`, reimplemented.
     *
     * No JavaFX call and no reflection: this is the algorithm itself. The brightness it
     * derives from is not the HSB value but `0.3R + 0.59G + 0.11B`, and the positive
     * branch follows a staircase rather than a formula, which is why an earlier
     * approximation here was measurably wrong.
     *
     * Correctness is not argued, it is pinned: `JavaFxStylesheetTest` checks this
     * against values the real `com.sun.javafx.util.Utils.deriveColor` produced, frozen
     * into `javafx-derive-reference.txt` so the check survives JavaFX being removed.
     */

• Step 6: Die ganze Suite laufen lassen

Run: ./gradlew clean build --console=plain > /tmp/b.txt 2>&1; echo "exit=$?"; python3 -c " import glob,xml.etree.ElementTree as ET t=f=0 for p in glob.glob('*/build/test-results/test/TEST-*.xml'): r=ET.parse(p).getroot(); t+=int(r.get('tests')); f+=int(r.get('failures'))+int(r.get('errors')) print(f'tests={t} failures={f}')"

Erwartet: exit=0, failures=0, und tests um eins höher als die 766 vom Ausgangsstand.

• Step 7: Commit

git add app-desktop/src/test/kotlin/kst4contest/view/compose/JavaFxStylesheetTest.kt \
        app-desktop/src/main/kotlin/kst4contest/view/compose/JavaFxStylesheet.kt
git commit -m "Check derive() against the frozen reference instead of live JavaFX

The reflection call stays only in the disabled generator. The running
test now reads checked-in values, so it keeps its meaning once JavaFX is
gone rather than silently comparing derive() with itself.

Verified by breaking derive() on purpose and watching the test fail.

Also corrects the doc comment on derive(), which still described a
reflection delegation that the code has not done for some time."

---

Task 3: Feststellen, ob FxRosterBinding den Betrieb speist

Files:

• Create: docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md
• Read only: app-desktop/src/main/java/kst4contest/view/Kst4ContestApplication.java, app-desktop/src/main/java/kst4contest/view/FxRosterBinding.java

Interfaces:

• Consumes: nichts.
• Produces: das Befunddokument mit dem Abschnitt „FxRosterBinding". Aufgabe 5 fasst zusammen, Teil 2 baut darauf auf.

Keine Produktionsdatei wird in dieser Aufgabe geändert.

• Step 1: Alle Nutzungen des Spiegels auflisten

Run: grep -n "chatMemberListBinding" app-desktop/src/main/java/kst4contest/view/Kst4ContestApplication.java

Erwartet: Erzeugung um :2513, Nullsetzung um :6877, eine Prüfung um :1766. Jede weitere Fundstelle notieren.

• Step 2: Feststellen, wer den gespiegelten ObservableList liest

Run: grep -n "chatMemberListBinding.get\|chatMemberListBinding\.\(mirror\|list\|items\)" app-desktop/src/main/java/kst4contest/view/Kst4ContestApplication.java; grep -n "public" app-desktop/src/main/java/kst4contest/view/FxRosterBinding.java

Erwartet: die öffentliche Fläche von FxRosterBinding und jede Stelle, die den Spiegel abruft. Für jede Stelle festhalten: landet sie in einer TableView (tot) oder in etwas, das Compose liest (lebend)?

• Step 3: Feststellen, woher die Compose-Stationsliste ihre Zeilen bekommt

Run: grep -n "DataTableState<ChatMember>\|setRows\|rows =" app-desktop/src/main/java/kst4contest/view/Kst4ContestApplication.java | head -20; grep -n "fun setRows\|var rows\|val rows" app-desktop/src/main/kotlin/kst4contest/view/compose/DataTableState.kt

Erwartet: eine durchgehende Kette von ObservableRoster bis DataTableState.rows. Notiere sie Glied für Glied. Führt die Kette durch chatMemberListBinding, ist der Spiegel lebend.

• Step 4: Den Befund schreiben

docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md anlegen:

# Lebendbefund: was im JavaFX-Aufbau von KST4Contest tatsächlich benutzt wird

Grundlage für Teil 2 von `docs/superpowers/specs/2026-10-01-javafx-entfernen-design.md`.
Erhoben am 1. Oktober 2026 auf Linux, Branch `nextMajorRelease/version1_50`.

Jeder Block bekommt genau einen von zwei Töpfen:
**folgenlos löschbar** oder **zu entflechten** (mit der Stelle, die davon abhängt).

## FxRosterBinding (`chatMemberListBinding`)

**Topf:** <folgenlos löschbar | zu entflechten>

**Belege:**
- Erzeugt bei `Kst4ContestApplication.java:<Zeile>`, genullt bei `:<Zeile>`.
- Gelesen von: <Liste der Stellen, je mit Zeile und „tot/lebend">
- Die Compose-Stationsliste bezieht ihre Zeilen über: <die Kette aus Schritt 3>

**Folgerung:** <ein Satz>

Jede spitze Klammer wird durch das ersetzt, was die Schritte 1–3 ergeben haben. Bleibt eine stehen, ist die Aufgabe nicht fertig.

• Step 5: Commit

git add docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md
git commit -m "Record what FxRosterBinding actually feeds

First section of the finding that part 2 of the JavaFX removal builds on.
No production code touched."

---

Task 4: Die übrigen Verdachtsfälle am laufenden Programm prüfen

Files:

• Modify: docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md
• Read only: app-desktop/src/main/java/kst4contest/view/Kst4ContestApplication.java

Interfaces:

• Consumes: das Befunddokument aus Aufgabe 3.
• Produces: dasselbe Dokument mit den Abschnitten „registerThemedScene", „LayoutAutosave", „Systemmenüleiste" und „Kandidatenfenster".

Keine Produktionsdatei wird in dieser Aufgabe geändert. Diese Aufgabe erfordert, die Anwendung zu starten und zu bedienen; Lesen allein beantwortet sie nicht.

• Step 1: Die Stellen auflisten

Run: grep -n "registerThemedScene\|LayoutAutosave\|layoutAutosave\|installSharedSystemMenuBar\|initMenuBar\|showTopPriorityCandidatesWindow" app-desktop/src/main/java/kst4contest/view/Kst4ContestApplication.java

Erwartet unter anderem: drei Aufrufe von registerThemedScene, layoutAutosave erzeugt um :7420, installSharedSystemMenuBar(candidatesScene) um :4858, initMenuBar() um :5729, showTopPriorityCandidatesWindow gerufen bei :4706 (toter JavaFX-Knopf) und :10707 (lebender Compose-Pfad).

• Step 2: Die Anwendung starten und das Kandidatenfenster öffnen

Run: ./gradlew :app-desktop:run

Dann im Compose-Hauptfenster den Knopf more neben den Prioritätsknöpfen drücken.

Erwartet: ein Fenster mit der Kandidatenliste erscheint. Festhalten: Titelleiste, ob es eine eigene Menüleiste trägt, ob es modal ist, und ob ein Klick auf einen Eintrag im Hauptfenster eine Station auswählt.

Erscheint kein Fenster, ist der Pfad trotz :10707 tot — das ist ein genauso wertvoller Befund und gehört so ins Dokument.

• Step 3: Das Design umschalten und beobachten, ob die Compose-Fenster folgen

Bei laufender Anwendung das Design über die Menüleiste des Hauptfensters umschalten (Tag/Abend).

Erwartet: Hauptfenster, Kartenfenster und Einstellungsfenster wechseln die Farben. Notieren, ob alle folgen. Folgt eines nicht, hängt es womöglich an registerThemedScene und gehört in den Topf „zu entflechten".

• Step 4: Einen Profilwechsel durchführen

Review Focus 4. Über die Menüleiste das Bedienerprofil wechseln.

Erwartet: die Fenster werden geschlossen und neu aufgebaut; die Anwendung bleibt bedienbar; in der Konsole erscheint keine Ausnahme. Notieren, was passiert.

• Step 5: Mit einem zweiten Profil wiederholen

Review Focus 3. Ein Profil mit anderen aktiven Bändern wählen (mindestens ein Band an- oder abgeschaltet gegenüber dem ersten) und die Schritte 2 bis 4 wiederholen.

Erwartet: dasselbe Verhalten. Weicht es ab, gehört die Abweichung mit der Einstellung ins Dokument, die sie auslöst.

• Step 6: Fenstergrößen auf Persistenz prüfen

Ein Fenster in der Größe ändern, die Anwendung beenden, neu starten.

Erwartet: die Größe ist erhalten. Ist sie es nicht, schreibt LayoutAutosave womöglich Werte, die niemand mehr liest — oder umgekehrt. Notieren.

• Step 7: Die Abschnitte ins Befunddokument schreiben

Für jeden der vier Blöcke — registerThemedScene, LayoutAutosave, Systemmenüleiste, Kandidatenfenster — denselben Aufbau wie in Aufgabe 3 Schritt 4: Topf, Belege, Folgerung.

Die Systemmenüleiste bekommt zusätzlich die Zeile:

**Nicht geprüft:** macOS. Erhoben wurde auf Linux. Ob die Systemmenüleiste dort
sichtbar an der JavaFX-`MenuBar` hängt, ist offen und muss vor dem Entfernen auf
einem Mac nachgeholt werden.

• Step 8: Commit

git add docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md
git commit -m "Record what the themed scenes, autosave and menu bar actually do

Established by running the application and operating it, not by reading:
a listener that is never fired reads the same as one that does not exist.
Includes a profile switch and a second profile, and marks macOS as
unverified. No production code touched."

---

Task 5: Den Befund abschließen und Teil 2 umreißen

Files:

• Modify: docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md

Interfaces:

• Consumes: alle Abschnitte aus Aufgabe 3 und 4.

• Produces: die Löschreihenfolge, aus der Teil 2 geschrieben wird.

• Step 1: Den toten Aufbau in Scheiben zerlegen

Run: grep -n "private.*void init[A-Z][a-zA-Z]*(\|private.*Pane init[A-Z][a-zA-Z]*(\|private.*Node init[A-Z][a-zA-Z]*(" app-desktop/src/main/java/kst4contest/view/Kst4ContestApplication.java

Erwartet: die init…-Methoden, die zusammen das nie gezeigte Fenster bauen. Für jede notieren: Zeilenbereich, ungefähre Länge und ob der Befund aus Aufgabe 3 und 4 sie als „folgenlos löschbar" ausweist.

• Step 2: Eine Reihenfolge festlegen, die den Build nach jeder Scheibe grün lässt

Blätter zuerst, Wurzeln zuletzt: eine Methode, die niemand mehr ruft, lässt sich löschen; eine, die noch gerufen wird, nicht. Die Reihenfolge als nummerierte Liste ins Dokument schreiben, jede Scheibe mit den Methoden, die sie umfasst.

• Step 3: Die Zusammenfassung schreiben

Am Anfang des Dokuments, unter der Überschrift:

## Ergebnis in einem Satz

<Von den N init-Methoden sind M folgenlos löschbar; K sind zu entflechten, nämlich …>

## Löschreihenfolge für Teil 2

1. <Scheibe> — <Methoden> — <geschätzte Zeilen>
2. …

• Step 4: Prüfen, dass keine Lücke bleibt

Run: grep -c "zu entflechten\|folgenlos löschbar" docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md; grep -n "<" docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md

Erwartet: jeder Block hat genau einen Topf, und der zweite Befehl findet keine spitze Klammer mehr. Findet er eine, ist eine Vorlage nicht ausgefüllt.

• Step 5: Commit

git add docs/superpowers/notes/2026-10-01-javafx-lebendbefund.md
git commit -m "Finish the live-code finding and derive the deletion order

Part 2 of the JavaFX removal is written from this, not from assumption."

---

Was dieser Plan nicht tut

• Er löscht keine Produktionsdatei.
• Er fasst den UiDispatcher, den Lebenszyklus und die zehn Dialoge nicht an.
• Er entfernt org.openjfx nicht aus dem Build.

Das ist Teil 2, und der wird geschrieben, wenn der Befund aus Aufgabe 5 vorliegt.