Handlungsfelder¶

Die Schulentwicklungs- und Bezirksentwicklungs-Sichten enden mit einer Liste empfohlener Handlungsfelder — kurze, priorisierte Hinweise mit konkreten Impulsen für Schulleitung bzw. Schulaufsicht. Diese Empfehlungen sind landesspezifischer Inhalt und werden bewusst außerhalb der TBA-Spec gepflegt.

Zielgruppe dieser Seite

Diese Seite richtet sich an Frontend-Teams in Ländern, die den Handlungsfeld-Katalog auf ihre eigenen Schwellen, Texte und Impulse anpassen wollen. Sie ist bewusst etwas technischer als die übrigen Komponenten-Seiten.

Warum nicht in der Spec?¶

Die TBA-Spec beschreibt den Datenvertrag zwischen Backend und Frontend (Kompetenzstufen, Aggregationen, Items …). Handlungsfelder sind kein Datenpunkt in diesem Sinne, sondern eine fachliche Interpretation der Daten:

Welche Schwelle gilt als „Mindeststandard-Lücke"?
Welche Impulse gibt das Land seiner Schulaufsicht an die Hand?
Welche Tonalität hat die Empfehlung („wir prüfen" vs. „wir entscheiden")?

Diese Entscheidungen liegen bei jedem Land selbst. Das Frontend pflegt sie deshalb in einer eigenen Konfigurationsschicht — nicht im Backend, nicht im API-Vertrag.

Ausblick

Wenn ein Land den Katalog später an einer zentralen Stelle pflegen oder über eine API ausliefern möchte, ist das technisch problemlos nachrüstbar. Die buildHandlungsfelder(metrics)-Schnittstelle bleibt dabei gleich; nur die Quelle der Regeln ändert sich. Diese Variante ist aktuell nicht Teil des Refactors.

Architektur¶

Das Zusammenspiel ist bewusst einfach:

Komponente (z.B. SchoolDevelopment)
   │
   │  1. Liest API-Daten (Spec-konform via generierten Service)
   │  2. Berechnet typisierten Metriken-Snapshot
   ▼
buildHandlungsfelder(metrics)   ← landesspezifischer Katalog
   │
   │  3. Wertet Trigger aus, baut Handlungsfeld-Objekte
   ▼
Handlungsfeld[]   (sortiert nach Priorität)
   │
   ▼
Komponente rendert Liste (Titel, Beschreibung, Impulse, Prio-Badge)

Wichtig: Die UI-Komponente kennt keine konkreten Handlungsfelder. Sie liefert nur einen Snapshot der bereits berechneten Kennzahlen und rendert das Ergebnis. Wer Texte oder Schwellen anpassen will, muss die Komponente nicht anfassen.

Wo liegt was?¶

Alle Dateien liegen unter src/app/shared/handlungsfelder/:

Datei	Zweck
`types.ts`	Gemeinsame Typen: `Handlungsfeld`, `HandlungsfeldPrio` und Helper (`sortByPrio`, `prioLabel`, `prioClass`).
`school-development.catalog.ts`	Katalog für die Schulleitungs-Sicht (Schulentwicklung). Exportiert `SchoolDevelopmentMetrics` und `buildHandlungsfelder(metrics)`.
`district-development.catalog.ts`	Katalog für die Schulaufsichts-Sicht (Bezirksentwicklung). Exportiert `DistrictDevelopmentMetrics` und `buildHandlungsfelder(metrics)`.

Die Aufrufer:

Schulleitung: src/app/school-manager/school-development/school-development.ts
Schulaufsicht: src/app/school-supervision/district-development/district-development.ts

So sieht ein Trigger aus¶

Beispiel aus district-development.catalog.ts — der intuitivste Trigger ist die Mindeststandard-Lücke zum Land:

// Block 1: Mindeststandard-Lücke zum Land
const mindest = metrics.mindeststandard;
const mindestDiff = mindest.bezirk - mindest.land;
if (mindestDiff <= -5) {
  items.push({
    id: 'b1-mindeststandard',
    prio: 'high',
    titel: 'Mindeststandard-Lücke zum Landesmittel schließen',
    beschreibung: `Im Bezirk erreichen ${mindest.bezirk} % den Mindeststandard, im Land sind es ${mindest.land} %. Das entspricht einer Lücke von ${Math.abs(mindestDiff)} Prozentpunkten und betrifft strukturell den ganzen Bezirk.`,
    impulse: [
      'Bezirksweite Fachkonferenz zum Mindeststandard mit Vertretungen aller Schulämter einberufen.',
      'Fortbildungs-Schwerpunkt „Diagnostik & Förderung im unteren Leistungsbereich" über das Kompetenzteam ausschreiben.',
      'Schulen mit besonders hohem Förderbedarf identifizieren und in einem Schul-Cluster begleiten.',
    ],
  });
}

Jeder Trigger ist ein eigenständiger if-Block mit derselben Struktur: Bedingung prüfen → Handlungsfeld-Objekt zusammenbauen → in die Liste pushen. Reihenfolge im Code ist egal — am Ende sortiert sortByPrio(items) nach high → medium → low.

Trigger anpassen¶

Drei typische Aufgaben:

Schwelle ändern¶

Beispiel: Ein Land möchte die Mindeststandard-Lücke schon ab −3 Pp als Handlungsfeld auswerfen statt erst ab −5 Pp.

Datei src/app/shared/handlungsfelder/district-development.catalog.ts öffnen.
Den entsprechenden Trigger suchen (b1-mindeststandard).
Die Bedingung anpassen: if (mindestDiff <= -3) statt if (mindestDiff <= -5).
Optional auch den Text in beschreibung an den neuen Schwellenwert anpassen.

Keine weiteren Änderungen nötig — die Komponente ruft den Katalog beim nächsten Rendern automatisch mit dem neuen Schwellenwert auf.

Text / Impulse anpassen¶

titel, beschreibung und impulse sind reine Strings im Katalog. Anpassen, fertig. Die Beschreibung darf Template-Literale nutzen, um aktuelle Zahlen aus dem Metriken-Snapshot einzubinden (siehe Beispiel oben).

Trigger hinzufügen oder entfernen¶

Entfernen: Den entsprechenden if-Block aus buildHandlungsfelder löschen. Keine weiteren Stellen müssen angepasst werden.

Hinzufügen: Einen neuen if-Block einfügen, der dieselbe Struktur folgt:

if (/* deine Bedingung über metrics.* */) {
  items.push({
    id: 'eindeutige-id',          // muss schul-/bezirksweit eindeutig sein
    prio: 'medium',                // 'high' | 'medium' | 'low'
    titel: 'Kurze Überschrift',
    beschreibung: `Erklärungstext mit konkreten Zahlen aus metrics.`,
    bereich: 'Domäne',             // optional, z.B. für fachliche Hinweise
    impulse: [
      'Konkreter Handlungsimpuls 1.',
      'Konkreter Handlungsimpuls 2.',
    ],
  });
}

Die id ist nur intern und dient der Stabilität (*ngFor trackBy o. ä.). Die Priorität steuert die Sortierung und die Farbe der Prio-Badge.

Metriken erweitern¶

Wenn ein neuer Trigger eine Kennzahl braucht, die noch nicht im Metriken-Snapshot enthalten ist, sind zwei Stellen anzupassen — die Komponente liefert die Kennzahl, der Katalog deklariert sie im Interface.

Schritt 1: Metrics-Interface erweitern¶

Im jeweiligen Katalog-File das Interface ergänzen. Beispiel: Wir wollen den Gender-Gap (Δ Jungen − Mädchen, in Prozentpunkten) als Trigger nutzen.

export interface DistrictDevelopmentMetrics {
  // … bisherige Felder …
  genderGapPp: number;   // neu: Δ Jungen − Mädchen in Prozentpunkten
}

Schritt 2: Computed in der Komponente ergänzen¶

In district-development.ts das handlungsfelderMetrics-Computed um den neuen Wert erweitern:

private readonly handlungsfelderMetrics = computed<DistrictDevelopmentMetrics>(() => ({
  mindeststandard: this.mindeststandard(),
  risiko: this.risiko(),
  spitze: this.spitze(),
  sesGradientSpread: this.sesGradientSpread(),
  authorityRows: this.authorityRows(),
  standardRows: this.standardRows(),
  competenceDomainHotspots: this.competenceDomainHotspots(),
  genderGapPp: this.genderGapPp(),   // neu
}));

Den genderGapPp-Computed selbst gibt es entweder bereits (dann nur einbinden) oder er muss neu berechnet werden — idealerweise nach demselben Muster wie die übrigen computed()-Werte in der Komponente.

Schritt 3: Trigger im Katalog ergänzen¶

Jetzt steht metrics.genderGapPp im Katalog zur Verfügung und kann in einem neuen if-Block ausgewertet werden.

Verfügbare Metriken im Überblick¶

Schulentwicklung (`SchoolDevelopmentMetrics`)¶

Feld	Bedeutung
`risiko` / `spitze`	Anteil unter Mindeststandard bzw. im oberen Leistungsbereich, jeweils Schule / Vergleichsschule / Land (Prozent, gerundet).
`sesGradientSpread`	Spannweite A → E in Prozentpunkten, Schule und Vergleichsschule.
`classDistributions`	Pro Klasse Anteil Förderbedarf und oberer Leistungsbereich.
`competenceMastery`	Teilkompetenz-Profil mit Status (`school` / `class` / `ok`) und Δ Vergleichsschule.

Bezirksentwicklung (`DistrictDevelopmentMetrics`)¶

Feld	Bedeutung
`mindeststandard` / `risiko` / `spitze`	Anteile Bezirk vs. Land.
`sesGradientSpread`	Spannweite A → E in Prozentpunkten, Bezirk und Land.
`authorityRows`	Pro Schulamt Anteil Mindeststandard und Δ zum Bezirksmittel.
`standardRows`	Kompetenzstandards mit Status (`low` / `mid` / `ok`) und Δ Land.
`competenceDomainHotspots`	Domänen mit ≥ 2 auffällig schwachen Teilkompetenzen (Δ Land ≤ −8 Pp).

Die genauen Typen stehen in den jeweiligen Katalog-Files.

Was bleibt unverändert?¶

API-Aufrufe der Komponenten — der Katalog wertet nur aus, er ruft nichts ab.
Spec-Konformität — der Refactor ist rein frontendseitig.
UI-Darstellung — Karten, Badges und Impulse werden wie bisher gerendert.