# Quizgeist

Quizgeist ist eine eigenständige Moodle-Aktivität für Live-Runden und
schulinterne Quiz-Inhalte. Seit Version 1.1 besteht die Distribution aus einem
kostenlosen Basisplugin und fünf optionalen Moodle-Subplugins. Das Basisplugin
ist ohne Lizenzdatei vollständig für den Kernkreislauf
**erstellen → live spielen → auswerten** nutzbar.

## Funktionsumfang

Das Basisplugin enthält den Moodle-nativen Frageneditor mit Quiz,
Richtig/Falsch, Kurzantwort, Umfrage, Wortwolke und Inhaltsfolie, klassische
Live-Sessions samt Reconnect und Podium, Vorlagen, lokale Medien, den
vollständigen Kahoot-Import, Sessionbericht und CSV-Export. Es gibt keine
Limits für Teilnehmer, Fragen oder Nutzungszeit, keine Wasserzeichen und keine
Online-Aktivierung.

Sechs optionale Addons erweitern ausschließlich Fähigkeiten:

| Verzeichnis / Komponente | Produktname | Fähigkeiten |
|---|---|---|
| `addon/qtypes` / `quizgeistaddon_qtypes` | Fragetypen Plus | Puzzle, Slider, Skala, Pin, Bild aufdecken, Brainstorming, offene Frage |
| `addon/modes` / `quizgeistaddon_modes` | Spielmodi & Motivation | Team, Genauigkeit, Sicherheit, Saisonmotive und Geistopia |
| `addon/selfstudy` / `quizgeistaddon_selfstudy` | Selbstlernen & Üben | Zuweisungen, Fristen, Erinnerungen, Lernkarten, Übungstest und Wochenziele |
| `addon/reports` / `quizgeistaddon_reports` | Berichte Pro | kombinierter und Kursbericht, XLSX, Schwierigkeitsanalyse und Moderationsspur |
| `addon/ai` / `quizgeistaddon_ai` | KI-Werkstatt | Thema, PDF oder PPTX zu Quiz sowie TTS |
| `addon/buehne` / `quizgeistaddon_buehne` | Bühnen-Check | Vortrag vor der Kamera mit Körpersprache-Rückmeldung, vollständig im Browser |

Alle Zugriffe folgen Moodles Einschreibungen, Capabilities, Sichtbarkeit,
Verfügbarkeiten und Gruppen. Antworten und Wertung bleiben serverautoritativ;
externe CDNs, Trackingdienste oder öffentliche KI-Endpunkte sind nicht nötig.
Fehlender Addon-Code wird in Navigation und Editor nicht als gesperrter Köder
angezeigt. Ist ein Addon installiert, aber nicht für Neuanlage berechtigt,
erklärt die Oberfläche den lokalen Lizenzstatus im Klartext.

## Installation auf einer Moodle-Instanz

1. Installieren oder aktualisieren Sie immer zuerst das Basisplugin unter
   `mod/quizgeist`. Ein reines Basispaket enthält die fünf Verzeichnisse unter
   `addon/` nicht.
2. Öffnen Sie als Administratorin oder Administrator
   **Website-Administration → Mitteilungen**, um die Datenbanktabellen,
   Capabilities, Cachedefinitionen und Hintergrundtasks anzulegen.
3. Kopieren Sie gewünschte Addons anschließend jeweils nach
   `mod/quizgeist/addon/<name>` und öffnen Sie erneut
   **Website-Administration → Mitteilungen**. Alle Addons müssen dieselbe
   Releasefamilie wie das Basisplugin verwenden; das Basisplugin darf nie nach
   den Addons aktualisiert werden.
4. Spielen Sie die vom Anbieter erhaltene signierte Datei auf
   **Website-Administration → Plugins → Aktivitäten → Quizgeist-Lizenz** ein.
   Die Prüfung erfolgt vollständig offline. Für das kostenlose Basisplugin ist
   keine Lizenzdatei erforderlich.
5. Stellen Sie sicher, dass Moodle-Cron regelmäßig läuft. Für Quizgeist selbst
   sind weder ein Prototyp-Plugin noch ein anderer Quizbaustein erforderlich.
6. Legen Sie im Kurs eine Aktivität **Quizgeist** an und weisen Sie bei
   getrennten Gruppen die Moodle-Gruppen wie gewohnt zu.

Vor einem produktiven Upgrade oder dem Entfernen eines Addons gelten die
üblichen Moodle-Backups von Datenbank und `moodledata`. Ein Addon wird über
Moodles Pluginverwaltung deinstalliert; sein Verzeichnis darf nicht einfach
während eines laufenden Upgrades verschwinden. Gemeinsame Inhalts- und
Teilnahmedaten gehören dem Basisplugin, damit ein fehlendes Addon weder
Backup/Restore noch die Privacy-API beschädigt.

### Lizenzstatus und Bestandsschutz

Die Lizenzdatei ist an die kanonische Moodle-`wwwroot` gebunden und wird lokal
per Ed25519-Signatur geprüft. Quizgeist sendet dafür weder Telemetrie noch
Aktivierungsanfragen. Die Adminseite zeigt Instanz, Revision, Laufzeit,
Kulanzzeit und Status je installiertem Addon.

Eine aktive Lizenz und die Kulanzzeit erlauben Neuanlage. Nach deren Ende ist
das Addon im Bestandsmodus: Neue Premium-Inhalte sind gesperrt, vorhandene
Fragen, Sessions, Zuweisungen und Berichte bleiben jedoch spielbar, sichtbar,
bearbeitbar und exportierbar. Dasselbe Datengeisel-Verbot gilt, wenn eine
Lizenzdatei fehlt, manipuliert oder für eine andere Instanz ausgestellt ist.
Eine abgelehnte Datei ersetzt nie die zuletzt angenommene Datei.

Für Release-Verantwortliche: Der normative Schlüssel `qg-test-2026-01` ist nur
für automatisierte Tests bestimmt und wird im Produktiv-Keyring niemals
vertraut. Der echte aktuelle Produktionsschlüssel (bei Rotation zusätzlich der
vorherige) muss vor Freigabe in
`classes/local/licence/keyring.php` eingetragen und mit dem P10-Harnisch
abgenommen sein. Ein leerer Keyring sperrt Premium-Neuanlage absichtlich und
meldet `production_keyring_missing`.

Moodle 5.2 oder neuer, PHPs DOM-, Fileinfo- und Zip-Erweiterungen sowie
JavaScript in den Teilnehmer-Browsern werden vorausgesetzt. Für große
Kahoot-ZIP-Importe müssen `upload_max_filesize`, `post_max_size`, die
Webserver-Grenze und Moodles Site-/Kurs-Dateigrenze die Archivgröße erlauben;
der Importer akzeptiert höchstens 128 MB komprimiert beziehungsweise 160 MB
entpackte Daten, zusammen 64 MB Kahoot-JSON, höchstens 150 Fragen je Kahoot und
einzelne Medien bis 25 MB.
Die KI-Werkstatt von Quizgeist arbeitet mit unserem gemanagten KI-Server. Er
ist Teil des Pakets und der Grund, warum die Funktionen zuverlässig, schnell
und DSGVO-konform laufen. Das Addon spricht wie bisher das Moodle-Plugin
`local_control_ai` und dessen GPUQ-Gateway an. Fehlt diese Serverintegration,
bleibt der regelbasierte Entwurfsmodus erhalten und die Oberfläche erklärt
freundlich, welche Paketkomponente fehlt. Schulen mit eigener
KI-Infrastruktur können Moodles bordeigene KI-Einstellungen als offenen
Standardweg nutzen. Das optionale `local_voces` stellt TTS bereit; ohne
verfügbare und berechtigte Integration werden Sprachsteuerungen ausgeblendet.
Quizgeist bringt keine Schriftdateien mit und lädt keine Webfonts nach. Alle
Motive verwenden robuste Systemschrift-Stacks. Am schönsten wirken sie mit den
site-lokal installierten Familien Sora, Poppins, Inter, Rubik und Pathway Gothic
One; an der MOS stellt das optionale Plugin `local_localfonts` diese Schriften
site-weit bereit. Ohne diese optionale Integration greifen ausschließlich die
lokalen Systemschrift-Fallbacks.
Bei einem Upgrade werden vorhandene Aktivitäten durch Moodles normales
Plugin-Upgrade migriert.

### Ausgehende Verbindungen

Die KI-Werkstatt kann zwei optionale serverseitige Ausgangsverbindungen
herstellen: Lehrkräfte mit `mod/quizgeist:manage` können eine frei eingegebene
öffentliche HTTP(S)-URL abrufen oder einen deutschsprachigen Artikel von
`de.wikipedia.org` als Quelle verwenden. Dabei wird nur die angeforderte URL
übertragen; Quizgeist fügt weder Moodle-Nutzerdaten noch Antworten oder
Bewertungen hinzu. URL-Schema, Zielhost, Port, Weiterleitungen, Antwortgröße
und Inhaltstyp werden serverseitig begrenzt und gegen interne Netzbereiche
abgesichert.

Der Site-Admin-Schalter
`mod_quizgeist | allowoutboundfetch` ist zugunsten des bisherigen Verhaltens
standardmäßig aktiviert. Wird er deaktiviert, lehnt der Server beide
Abrufpfade ab und die KI-Werkstatt zeigt statt der URL-/Wikipedia-Auswahl einen
erklärenden Hinweis; lokale Dokumentquellen und der übrige Entwurfsworkflow
bleiben verfügbar. Quizgeist lädt unabhängig davon keine externen
Schrift-, Skript-, Bild- oder Trackingressourcen.

## Kahoot-Datenrettung

Lehrkräfte mit `mod/quizgeist:manage` können im Verwaltungsbereich eine einzelne
Kahoot-JSON-Datei oder ein ZIP mit JSON und lokalen Medien importieren. Archive
werden begrenzt und ohne Entpacken ins Webverzeichnis gelesen; externe URLs
dienen nur als Herkunftsbezeichner und werden nie nachgeladen. Dateiendung,
Byte-MIME, Größe und SVG-Inhalt passieren dieselben Prüfungen wie manuelle
Editor-Uploads. Ein dauerhafter Herkunftssatz aus Kurs, Kahoot-UUID und
Quell-Prüfsumme macht den Import wiederholbar: Ein zweiter identischer Lauf
erzeugt weder Fragen- noch Mediendubletten. Eine geänderte Datei mit bereits
importierter UUID wird bewusst abgewiesen.

Moodle-Backups erhalten Fragen, Medien und den geprüften Herkunftsbericht. Eine
Aktivitätskopie im selben Kurs bekommt eine eigene Restore-Provenienz, damit die
ursprüngliche Kahoot-UUID weiterhin genau einen kanonischen Import bezeichnet.
Fehlende oder nach verschärften Sicherheitsregeln verworfene Restore-Medien
führen nie zu einem fälschlich vollständigen Marker: Betroffene Inhalte werden
quarantänisiert und bleiben über einen erneuten Import reparierbar.

Administratoren können denselben Dienst über die CLI verwenden:

```text
# Moodle mit klassischem Webroot:
php mod/quizgeist/cli/import_kahoots.php --course=<kursid> --alle --ziel-cmid=<cmid> --quelle=/absoluter/pfad/zum/export/data

# Moodle 5 mit public-Webroot:
php public/mod/quizgeist/cli/import_kahoots.php --course=<kursid> --datei=<uuid>.json --dry-run --quelle=/absoluter/pfad/zum/export/data
```

Mit `--quelle=/absoluter/pfad/zum/export/data` wird im Normalfall das
bereitgestellte Exportverzeichnis ausdrücklich angegeben.
`--moodle-config=/absoluter/pfad/config.php` unterstützt abweichende
Installationslayouts, falls die automatische Suche die Moodle-Konfiguration
nicht findet. Wird `--quelle` ausnahmsweise weggelassen, sucht das Skript nach
der lokalen Konvention `kahoot-export/data` neben dem Moodle-Webroot.
`--dry-run` führt Mapping, Schema-, Medien- und Prüfsummenprüfungen ohne
Datenbankänderung aus.
Jeder Lauf erzeugt je Kahoot einen lösungsfreien Bericht mit „übernommen“,
„angepasst“ und „ausgelassen“ samt stabiler Begründung.

### Typ-Mapping

| Kahoot-Quelltyp | Quizgeist-Zieltyp | Übernahme und bewusste Anpassung |
|---|---|---|
| `quiz` | Quiz oder Wahr/Falsch | Korrektheit, Punkte, Zeitlimit sowie Text- und Bildantworten; `TRUE_FALSE` wird als Wahr/Falsch erkannt |
| `multiple_select_quiz` | Quiz mit Mehrfachantwort | Alle markierten richtigen Antworten, Punkte, Zeitlimit und Antwortbilder |
| `survey` | Umfrage | Auswahl und Medien; Quell-Korrektheitsmarkierungen werden als bedeutungslos protokolliert |
| `multiple_select_poll` | Umfrage mit Mehrfachauswahl | Mehrere Stimmen, Zeitlimit und Medien; ungewertet |
| `scale` | Skala | Bereich auf 3–10 Schritte begrenzt, Endpunktbeschriftungen nachvollziehbar angepasst |
| `jumble` | Puzzle/Reihenfolge | Reihenfolge und Medien; Options-IDs sind nicht positional, die Live-Payload verwendet zusätzlich Visit-gebundene opake Handles |
| `drop_pin` | Pin-Heatmap | Da der Export keinen belastbaren Zielpunkt enthält, als ungewertete Heatmap mit `hasTarget=false` übernommen |
| `open_ended` | Offene Antwort | Ungewertete Texteingabe mit Zeitlimit und optionalem Medium; eine Musterlösung wird nicht erfunden |
| `word_cloud` | Wortwolke | Fragestellung, Zeitlimit und lokales Fragenmedium werden ungewertet übernommen |
| `brainstorm`, `brainstorming` | Brainstorming | Sammelphase wird begrenzt übernommen; Antwortlimit und nicht darstellbare Punktevergabe werden protokolliert |
| `slider` | Slider | Zahlenbereich, Schritt, Ziel und Toleranz werden geprüft; relative Toleranz wird nachvollziehbar in einen absoluten Abstand umgerechnet |
| `content` | Folie | Titel, Text, Aufzählungen, Layout, Reaktionen und lokales Medium werden als Folie ohne Fragenzeit übernommen |

Zeitlimits werden auf die Quizgeist-Grenzen gerundet beziehungsweise begrenzt.
Kahoot-Punktmodi ohne genaues Quizgeist-Gegenstück werden als Standardpunkte
protokolliert. HTML-Formatierung wird in sicheren Klartext überführt; nicht
darstellbare Crop-, Attributions- oder Sprachmetadaten und externe
Videoreferenzen erscheinen als Anpassungsgrund. Unbekannte zukünftige Typen,
unvollständige Pflichtfelder und fehlende erforderliche Medien werden nicht
stillschweigend verworfen, sondern als ausgelassen im Bericht ausgewiesen.

Die Migration bildet ausschließlich eigene, lokal bereitgestellte
Lehrkraft-Inhalte ab. Kahoot-Apps, Marketplace-/Abonnementfunktionen,
AccessPass, Nutzerkanäle und ein kommerzielles 800-Spieler-Limit gehören
bewusst nicht zum Plugin. Quizgeist stellt weder Kahoot-Branding noch dessen
Oberfläche, Sounds oder Dienste nach und verbindet sich nicht mit Kahoot.
Eine allein hochgeladene JSON-Datei bringt naturgemäß keine lokalen Medien mit:
optionale Bilder werden dann als Anpassung protokolliert, bildpflichtige
Einzelfragen als ausgelassen. Für die vollständige Medienrettung dient das ZIP
beziehungsweise der CLI-Lauf über das Exportverzeichnis.

## Karten-Modus (F11a)

Im Karten-Modus erhalten Teilnehmende persönliche, ausdruckbare Antwortkarten.
Die Lehrkraft fotografiert die hochgehaltenen Karten; Quizgeist erkennt daraus
die gewählten Antworten und übernimmt sie nach einer Kontrollansicht in die
laufende Runde.

Kartenscans werden nie gesichert und nie über eine URL des Plugins ausgeliefert.
Nach dem Übernehmen wird das Klassenfoto gemäß E-10 sofort gelöscht. Für
abgebrochene Scans legt `card_scan_retention_hours` die maximale
Aufbewahrungsdauer fest; der Hintergrundtask entfernt das Bild spätestens nach
Ablauf dieser Frist.

## Bühnen-Check (F13)

Der Bühnen-Check ist ein Untermodus für Präsentationen: Er ergänzt offene
Fragen (`open`, Premium-Fragetyp) und Inhaltsfolien (`slide`, Basisplugin) um
eine Vortragsphase mit unmittelbarer Rückmeldung zu Körpersprache und Dauer.
Die Auswertung läuft vollständig im Browser. Weder Bild noch Video verlässt
das Gerät oder wird gespeichert; auch rohe Körper-Landmarks werden nicht an
den Server übertragen oder dort abgelegt.

Die dafür benötigten MediaPipe-Assets liegen lokal unter
`addon/buehne/thirdparty/mediapipe/` (37,70 MiB, Apache-2.0). Eine Berechtigung
aus einer aktiven Addon-Lizenz ist nur für das Anlegen des Untermodus und das
Speichern eines Berichts erforderlich. Das Vortragen sowie das Ansehen bereits
vorhandener Berichte bleiben ohne diese Lizenzberechtigung möglich.

## Bewusst so gelöste Grenzen

### Bild aufdecken

Beim Fragetyp „Bild aufdecken“ wird das vollständige, ausschließlich aus dem
Moodle-Dateibereich geladene Bild nach dem serverautoritativen Fragestart an den
Browser übertragen. Die zeitgesteuerte Kachelmaske ist eine clientseitige
Darstellung und kann von technisch versierten Teilnehmenden in den
Entwicklerwerkzeugen entfernt werden. Serverseitig bleiben akzeptierte
Textantworten, Antwortzeit und Punkte geschützt und autoritativ; das Bild selbst
ist ab diesem Zeitpunkt jedoch nicht geheim.

Der Typ ist deshalb für motivierende Wiedererkennungs- und Aktivierungsfragen
gedacht, nicht für sicherheitskritische oder benotete Wissensprüfungen. Eine
wirklich geheime Umsetzung müsste pro Visit und Aufdeckstufe serverseitig neue
Bildzuschnitte rendern und ausliefern; dieser Aufwand und die zusätzliche
Serverlast sind für den Live-Unterricht bewusst nicht Teil der aktuellen
Architektur.

### Spielmodi

Klassik-, Genauigkeits-, Team- und Sicherheitsmodus sind derzeit alternative
Session-Modi. Moodle-Gruppen erhalten im Teammodus ein sichtbares Auffangteam
„Ohne Moodle-Gruppe“, damit fehlende Gruppenzuordnungen den Beitritt nicht
blockieren.

### Selbstständiges Lernen und Noten

Zuweisungen frieren beim Anlegen die exakten veröffentlichten Fragenversionen
ein. Solo-Versuche verwenden Tempo-Punkte, Übungen geben direkte Rückmeldung
ohne Gradebook-Wertung und Übungstests werden erst bei der Gesamtabgabe
ausgewertet. Im Solo-Modus beginnt die Uhr beim ersten Öffnen der jeweiligen
Frage; Navigation oder Neuladen setzen sie nicht zurück. Eine richtige Antwort
behält aber auch nach Ablauf des Zeitlimits mindestens 50 Prozent ihrer
qualitätsgewichteten Basispunkte.

Mehrstufige Live-Interaktionen werden im asynchronen Selbstlernen bewusst auf
ihre erste individuelle Antwortstufe reduziert. Der Zuweisungseditor weist
darauf hin, sobald die gewählte Fragenmenge solche Inhalte enthält; gemeinsame
Sammel-, Gruppier- oder Abstimmungsphasen bleiben Live-Runden vorbehalten.

Das Moodle-Gradebook übernimmt – entsprechend der Aktivitätseinstellung – den
besten, letzten oder ungewichteten Durchschnitt **aller** abgeschlossenen,
benoteten Solo- und Testversuche der Aktivität. Jeder Versuch wird dafür zuerst
auf seinen eigenen Maximalwert normiert; Zuweisungsgrenzen bilden keine
zusätzliche Gewichtungsebene. Lehrkräfte können je Zuweisung die Zahl
ausdrücklich gestarteter Versuche begrenzen und die Zuweisung aus dieser
Aktivitätsnote ausnehmen. Die Schülersicht verwendet exakt dieselbe
Aggregationsfunktion wie das Gradebook. „Letzter Versuch“ richtet sich nach
dem logischen Abschlusszeitpunkt; bei einer später ausgeführten
Serverfinalisierung ist das die Frist, der Schließzeitpunkt oder das Ende des
Sieben-Tage-Inaktivitätsfensters – nicht der Zeitpunkt des Cronlaufs.

Fristen sind optional. Nach Fristablauf oder dem Schließen einer Zuweisung
werden offene Versuche mit allen bis dahin dauerhaft gespeicherten Antworten
serverseitig abgeschlossen. Offene Positionen zählen als null Punkte mit ihrem
vollen möglichen Nenner. Dasselbe geschieht bei fristlosen, sieben Tage lang
inaktiven Versuchen. Ein Abbruch kann daher weder Antworten noch einen
bewertbaren Teilstand verschwinden lassen. Noten- und Completion-Synchronisierung
erfolgen sofort und zusätzlich über einen atomar mit der Finalisierung
eingereihten, wiederholbaren Hintergrundtask; ein vorübergehender Fehler nach
dem Commit kann den Teilstand daher nicht dauerhaft vom Gradebook entkoppeln.

Bei aktivierter Frist verschickt der geplante Task über die Moodle-Message-API
eine Erinnerung nur an bestätigte, nicht gelöschte und nicht gesperrte Konten
mit aktiver Kurseinschreibung, `mod/quizgeist:play`, Kurszugang und einer für
sie sichtbaren Aktivität einschließlich erfüllter Availability-Bedingungen.
Getrennte Gruppen begrenzen die Sicht auf andere Teilnehmende, nicht den
Zugriff auf die eigene Zuweisung; eine Gruppenzugehörigkeit ist daher keine
zusätzliche Erinnerungsbedingung. Fehlgeschlagene Zustellungen werden höchstens
dreimal versucht. Persönliche Wochenziele und ihr Fortschritt sind Nutzerdaten
und werden von Backup/Restore, Kursreset und Privacy-API erfasst.

### Berichte und Exporte

Session-, Zuweisungs-, kombinierte und kursweite Berichte gruppieren gespielte
Fragen nach ihrem stabilen `rootid`. Unterschiedliche Inhaltsversionen erscheinen
damit in einer gemeinsamen Fragenzeile; Quelle, exakte Fragen-ID, Version und
Vorkommenszahl bleiben nachvollziehbar. Persistierte Live- und
Selbstlern-Visit-Tokens verlassen das Read Model nicht; Antwort-Handles werden
in einem abgeleiteten Berichtsnamensraum projiziert. `rootid` ist dabei
ausschließlich eine Darstellungsgruppierung: Jede tatsächlich gespielte Version
und jeder abgeschlossene Versuch behält sein eigenes Gewicht. Für
Selbstlerndaten gilt der im Versuch eingefrorene Fragenstand, nicht eine später
veränderte Zuweisungsliste.

Berichtskennzahlen sind pädagogische Nutzungsdaten und unabhängig von der
Gradebook-Option `countsTowardsGrade`. Der Quellenkatalog darf auswählbare
Quellen ohne sichtbare Ergebnisdaten enthalten; im Verlauf erscheinen nur
Quellen mit sichtbaren Spielern oder abgeschlossenen Versuchen. Bei
kursweiten Berichten entscheidet die effektive Kursmodulsichtbarkeit der
betrachtenden Person: Verborgene Aktivitäten gehören für Lehrkräfte mit
`moodle/course:viewhiddenactivities` dazu, für andere Personen nicht.
Kursgruppen werden aus allen tatsächlich sichtbaren Quizgeist-Kursmodulen
gebildet. Eine explizit gewählte Gruppe, die in einer Aktivität nicht zu deren
Grouping gehört, lässt diese Aktivität mit einem sichtbaren Hinweis aus; ein
unzulässiges „alle Gruppen“ wird nicht still auf eine Einzelgruppe verengt.

Live-Kennzahlen einschließlich der Punkte verwenden ausschließlich den
autoritativen `resolvedvisit`; später per `scorevoid` neutralisierte, nicht
aufgelöste Besuche bleiben dadurch wirkungslos. Selbstlerndaten fließen nur aus
abgeschlossenen Versuchen ein; offene oder abgebrochene Versuche bleiben
ausgeschlossen, serverseitig finalisierte Versuche zählen als abgeschlossen.
Terminale `scorevoid`-Lücken zählen als falsch und fehlend, aber niemals als
Antwort oder Antwortzeit. Im Livebericht zählen fehlende wertbare Antworten
ebenfalls als falsch. Dabei werden Beitritts- und `lastseen`-Zeit gegen den
letzten Ledger-Zeitpunkt des Vorkommens abgeglichen; Antwortende gelten stets
als anwesend. Existiert kein Ledger-Zeitanker, ist nur die gröbere
Session-Teilnahme belegbar und wird als Basis verwendet.

„Punktequote“ ist `Σ Punkte / Σ Maximalpunkte` und bleibt damit über
unterschiedlich viele Quellen und Punkteskalen vergleichbar; nicht punktende
Quellen erzeugen keinen Nenner. „Ø Richtig“ ist die Mikroquote aus allen
richtigen und wertbaren Vorkommen, nicht der Mittelwert von Quellen- oder
Personenquoten. Teilnahme zählt unterschiedliche Teilnehmende gegen die aktuell
zugriffsberechtigten Personen der sichtbaren Quellen. Die Markierung
„Schwierige Frage“ verwendet standardmäßig eine Richtigquote unter 40 Prozent
und erscheint erst ab fünf wertbaren Beobachtungen. Beide Evidenzgrenzen sind
in der Website-Administration konfigurierbar.

Schülerzeilen führen den von Moodles `fullname()` bestimmten Anzeigenamen und
eine getrennte `Nutzerkennung`. Das DTO nennt diese Felder `displayName` und
`userIdentifier` und enthält zusätzlich die numerische `userId`. Als
Nutzerkennung dient eine gesetzte Moodle-`idnumber`, andernfalls der
`username`; nur bei einer Kollision im selben Bericht wird die Kennung mit der
numerischen Nutzer-ID disambiguiert. Dieselben Spalten `Name` und
`Nutzerkennung` stehen in CSV und XLSX sowie bei zuordenbaren offenen
Antworten. Schüler erhalten weiterhin ausschließlich eigene Daten,
Moodle-Profillinks ausschließlich Lehrkräfte.

Die Typstrategien erzeugen auch im Bericht Verteilungen und die Sichtung von
Wortwolken, offenen Fragen und Brainstorming. Moderations- und Gruppierungszeilen
bleiben in einer getrennten Auditspur und verändern keine Schülerkennzahl.
Die interaktive Ansicht begrenzt offene Antworten und Moderationszeilen jeweils
auf 500 Einträge und kennzeichnet die Kürzung; Exporte bleiben vollständig.
Gruppenmodus, Capability und Kursmodulsichtbarkeit werden für jede Quelle
serverseitig geprüft. Lehrkräfte erhalten Profillinks, Schüler ausschließlich
ihre eigenen Daten. Unveränderliche historische Frageprojektionen werden mit
Inhalts-, Antwort-, Rollen- und Sprachfingerprint im
`liveprojection`-Anwendungscache gehalten. CSV und XLSX werden aus demselben
autorisierten Read Model erzeugt. Umfangreiche Verteilungen werden dabei
serverseitig einzeln in einen selbstlöschenden, speicherbegrenzten
Temporärstrom projiziert; der Browser verwendet einen normalen Dateidownload
ohne Blob-Puffer. XLSX ist für deutsche Tabellenkalkulationen die empfohlene
Schaltfläche, während CSV dem deutschen Excel-Import mit Semikolon-Trennung,
UTF-8-BOM und Dezimalkomma folgt.

## Sicherheit

Spieler-Payloads verwenden pro Fragen-Visit opake Antwort-Handles. Persistierte
Autoren-/Editor-IDs sowie richtige Antworten, Zielwerte, Toleranzen und
Musterlösungen werden vor der Auflösung nicht an Spieler ausgeliefert.
Das gilt identisch für Selbstlernversuche: Solo und Übung geben Lösungen erst
nach der dauerhaft gespeicherten Einzelabgabe frei; im Übungstest bleiben
Richtigkeit, Punkte, Musterlösung und Erklärung bis zur Gesamtabgabe verborgen.
Lernkarten geben ihre Rückseite erst nach dem serverseitig protokollierten
Aufdecken frei.
