API-First als Regel ausgeschrieben, Anleitung fuer die WebUI-Umsetzung

Die Regel galt seit dem Umbau auf Avalonia, stand aber nirgends: Der Ausgabeweg
ist waehlbar - Desktop, Web oder beides gleichzeitig -, und daraus folgt genau
eine harte Vorgabe: Fachlichkeit lebt in einem Core-Dienst, nie in einer Ansicht.
Ein Fenster und ein Endpunkt sind zwei Zugaenge auf denselben Dienst.

In den Grundregeln steht jetzt die Prueffrage dazu (koennte ein zweiter
Ausgabeweg dasselbe tun, ohne diese Zeile zu kopieren?), die Vorgabe, dass Dienst
und Endpunkt im selben Zug wie das Fenster entstehen, und der Daemon als
Gegenprobe: Was sich kopflos nicht bedienen laesst, haengt zu sehr am Fenster.

docs/ANLEITUNG-WebUI.md richtet sich an den Agenten, der #490 uebernimmt.
Enthaelt den gemessenen Bestand, die Reihenfolge der drei Bloecke, die Tabelle
der 24 Endpunkte mit ihren Diensten, die beiden nicht-mechanischen Stellen
(Logs als Push, Settings mit Zugangsdaten) und die Grenzen - vor allem: keine
Fachlogik anfassen, keine schreibenden Endpunkte ohne Anmeldung.

Ein Punkt darin ist Architektur und keine Geschmacksfrage: Der Core darf die
Module nicht kennen, also koennen Modul-Routen nicht im Core registriert werden.
Sie gehoeren ins Hosting-Projekt, das die Module ohnehin kennt - so wie die
Modulfenster zentral in App/Shell/ModuleViews.cs stehen und nicht im Modul.

473 Tests gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.agents/rules/grundregeln.md

@@ -36,6 +36,22 @@ Kultur: Jede Zahl-/Datumsformatierung und jedes Parsen braucht einen ausdrückli
 Tests: eigenes Projekt IBKRTrader.Tests (xUnit + NSubstitute + FluentAssertions), NUR Unit-Tests,
        alles Externe (DB/IBKR/Scraper) gemockt. DoD jeder Phase: `dotnet test` grün + Build sauber.
 
+API-First (gilt seit dem Umbau auf Avalonia, seit 2026-09-06 ausgeschrieben):
+
+Der Ausgabeweg ist wählbar – Desktop-UI, Web-UI oder beide gleichzeitig. Daraus folgt genau
+  eine harte Regel: **Fachlichkeit lebt in einem Core-Dienst, nie in einer Ansicht.** Ein Fenster
+  und ein REST-Endpunkt sind zwei Zugänge auf denselben Dienst, und beide dürfen nur formatieren.
+Prüffrage vor jedem UI-Code: Könnte ein zweiter Ausgabeweg dasselbe tun, ohne diese Zeile zu
+  kopieren? Lautet die Antwort nein, gehört die Zeile in den Core.
+Jede neue Funktion bekommt ihren Core-Dienst UND ihren Endpunkt, im selben Zug wie ihr Fenster.
+  Nicht nachträglich: Endpunkte, die später in einem Block nachgezogen werden, kosten mehr und
+  weichen ab. Vorbild ist `Core/Positions/PositionManager.cs` – ein Dienst, drei Zugänge
+  (Shell-Fenster, Daemon-Schalter, `GET /api/positions`).
+Der Daemon ist die Gegenprobe: Lässt sich eine Funktion kopflos nicht bedienen, hängt zu viel
+  am Fenster. Der Testbetrieb läuft als systemd-Dienst – dort gibt es keines.
+Schreibende Endpunkte erst mit Anmeldung. Ohne sie wäre ein Eingriff in die Bücher möglich, den
+  niemand belegen kann; solange keine steht, bleibt die REST-Schnittstelle lesend.
+
 UI-Grundmodell (Launcher-Prinzip nach Polytrader):
 
 LauncherWindow = Basis-Fenster mit einer Schaltfläche je registrierter Ansicht und dem