Lehrkraftansicht für bestehende Lernende per SkillPilot-ID

Generated artifact. Do not edit manually.

Generated by: scripts/build_compendia.py Regenerate with: python3 scripts/build_compendia.py --compendium didactic --web-and-tex Source of truth: docs/concept/didactic/source/

Sprache / Language: Deutsch (DE) · English (EN) | PDF: Deutsches PDF · English PDF

Kompendium: §1 Feynman · §2 Autopilot · §3 Lerngeschwindigkeit · §4 Lernplanstatus · §5 Lernzielbuch-Planung · §6 Klausurvorbereitung · §7 Update-Kontinuität · §8 Lehrkraftansicht

8. Lehrkraftansicht für bestehende Lernende per SkillPilot-ID

Status und Berechtigungsgrenze

Aktiver First-Party-WebGUI-Workflow (VITE_EXISTING_LEARNER_LINKING_ENABLED; in Package-Consumer-Builds deaktiviert). Eine Lehrkraft fügt bestehende Lernende über deren permanente SkillPilot-ID einer rein lokalen Browser-Klasse hinzu — ohne Server-Klassen, Lehrkraftkonten oder Mitgliedschaftstabellen. Wichtige Identitätsgrenze: Die permanente SkillPilot-ID ist kein öffentlicher Leseschlüssel, sondern das Bearer-Secret mit Vollzugriff auf den Lernendenzustand. Abgesehen von der ausdrücklich bestätigten Aktion „Im Cockpit verfügbar machen“ nutzt die Trainer-UI sie ausschließlich lesend; das Credential selbst ist jedoch serverseitig nicht schreibgeschützt.

8.1. Produktinvarianten

Alleiniges Eigentum der Lernenden: Personal Curriculum (Level 2), Fokus, geplante Ziele, Mastery und sämtlicher übriger Lernstand gehören ausschließlich der lernenden Person. Der Browser der Lehrkraft speichert nur Klassenname, lokalen Alias, permanente SkillPilot-ID und einen bereinigten Level-2-Snapshot (selected, filterId, durationModel, stage).
Getrennte Fachansichten: Mathematik, Physik und weitere gewählte Fächer sind umschaltbare lokale Sichten desselben Eintrags mit jeweils eigener Skill-Landschaft und gecachtem Filterumfang.
Funktionale Lesegrenze und explizite Plankopie: Alle lernstandsverändernden Steuerelemente bleiben im Trainer für bestehende IDs deaktiviert. Nur nach ausdrücklicher Bestätigung kopiert „Im Cockpit verfügbar machen“ Bezeichnung, datierte Blöcke und validierte atomare Ziel-IDs in den lernendeneigenen persönlichen Fachplan — ohne Klassenbezug, Alias, Abdeckung, Mastery, Planungs-Baseline oder Historie und niemals automatisch synchronisiert.
Unveränderliche Planungsbasis vs. aktueller Fortschritt: Beim ersten Einplanen erfasst ein no-store-Abruf sämtliche sichtbaren atomaren Level-2-Ziele des Fachs samt offener Teilmenge unabhängig vom Level-3-Fokus (nur Ziel-IDs, Summen und Zeitstempel; ohne SkillPilot-ID oder numerische Einzel-Mastery; beim Planexport weggelassen). Der aktuelle Lernfortschritt wird davon getrennt rein lesend aus dem persönlichen Backend-Zielumfang und gespeicherten Ergebnissen bestimmt (konsistent mit Cockpit/Baum; inklusive Orientierungszielen im Umfang; fehlende/veraltete Abrufe erscheinen als nicht verfügbar statt null).
Ablösung manueller Unterrichtsabdeckung: Manuelle Unterrichtsabdeckung und Attestierungen sind als Fortschrittsmodell eingestellt (kein zweites „Unterrichts-IST“; lokale Altdaten bleiben kompatibel erhalten, erzeugen aber keine Mastery).
Kein Backend-Beziehungsdatensatz: Das Backend speichert weder Lehrkraft- noch Klassenzuordnungen; das Löschen einer lokalen Klasse entfernt ausschließlich den Browser-Eintrag, während die permanente SkillPilot-ID gültig bleibt. Passwortverschlüsselte Klassenexporte enthalten die permanente ID und sind daher wie Bearer-Secret-Container zu behandeln; frühere servergekoppelte Betreuungskarten werden nicht migriert.

8.2. Lokale Einrichtung, Aktualisierung und Planübergabe

Unter + Neue Klasse → Bestehende SkillPilot-ID lokal hinzufügen gibt die Lehrkraft Klassenname, lokalen Namen/Alias und permanente SkillPilot-ID ein.
Der Browser lädt GET /api/ui/learners/{skillpilotId} (cache: no-store), prüft die exakte ID sowie ein lesbares personalCurriculum mit mindestens einem ausgewählten Fach und legt eine lokale ClassSession an.
Beim Öffnen der Klasse aktualisiert der Trainer Profil und Mastery über die regulären Lernenden-Endpunkte; für den ersten Planabschnitt liest er ergänzend GET /api/ui/learners/{skillpilotId}/planning-scope (cache: no-store) für den vollständigen Level-2-Zielumfang unabhängig vom Level-3-Fokus (rein lesend; die Kompatibilitätsschwelle ist keine Notenskala). Auch Speichern im Klasseneditor aktualisiert den Snapshot erst nach erfolgreichem Abruf.
„Im Cockpit verfügbar machen“ expandiert jeden Lernabschnitt gegen den persönlichen Fachgraphen und verlangt eine Ersetzungsbestätigung. Der Server validiert Atom-IDs und Fokus, übernimmt neue IDs nur solange sie offen sind, erhält bereits im persönlichen Plan enthaltene IDs für Plankontinuität, bereinigt Überlappungen chronologisch und schützt per Revisionsprüfung vor unbeabsichtigtem Überschreiben — ohne Fokus, aktives Ziel oder Mastery zu ändern.

Der übernommene Plan bleibt lernendengesteuert: Der Planmodus ist standardmäßig aus, das erste Ziel wird bewusst gestartet, und aktiver Planmodus unterdrückt den generischen Autopilot (2.2). Nach einem bestätigten Zielabschluss erfolgt eine automatische Übergabe nur, wenn das abgeschlossene Ziel mindestens einem gültigen gespeicherten Plan angehört: Genau ein zulässiger Kandidat aus einem Plan mit diesem Ziel hat Vorrang; nur wenn dort keiner existiert, greift genau ein zulässiger Kandidat über alle gültigen Pläne hinweg. Bei Mehrdeutigkeit, ungültigen/fehlenden Plänen oder fehlendem fälligem Ziel greift Fail-Closed (bestehender Fokus bleibt, kein neues aktives Ziel wird gesetzt).

8.3. Lesegrenze, Verschlüsselung und Altbestand-Bereinigung

Frontend-Projektion statt Server-Capability: Der Workflow nutzt die regulären Lernenden-Routen (einschließlich globaler Mastery-Map); Fachwechsel blenden fremde Fachdaten im Baum strikt aus, beschränken aber nicht die technische Reichweite der ID. Echter serverseitiger Nur-Lese-Zugriff würde ein separates Scoped Credential erfordern; Lehrkraftgerät und Browserprofil liegen daher innerhalb der Vertrauensgrenze.
Lokale Speicherung und AES-256-GCM-Export: Der aktive Klasseneintrag liegt unverschlüsselt im lokalen Browserprofil; heruntergeladene Klassendateien werden im Browser per PBKDF2-SHA-256 und AES-256-GCM mit einer nur der Lehrkraft bekannten Passphrase verschlüsselt (Schutz nur at rest; ältere Klartextdateien werden nur als markierter Migrationsinput akzeptiert, servergekoppelte Altdateien abgewiesen).
Bereinigung früherer Server-Karten: Beim ersten Trainer-Start entfernt der Browser alte Einträge mit linked-supervision, linkedSupervision oder teacher-membership samt zugehörigen Credentials und lokalen Plan-Keys; im Backend entfernen Vorwärts-Migrationen die früheren Workspace-, Kurs- und Mitgliedschaftstabellen. Lernsessions, MCP/OAuth-Tools, Provider-Starts und eingereichte MCP-Apps-Artefakte bleiben von diesem Workflow unberührt.