Skip to content

Existing-Learner Teacher View by 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/

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

Compendium: §1 Feynman · §2 Autopilot · §3 Velocity · §4 Plan Status · §5 Goal-Book Planning · §6 Exam Prep · §7 Update Continuity · §8 Teacher View

8. Existing-Learner Teacher View by SkillPilot ID

Status and Credential Boundary

Active first-party WebGUI workflow (VITE_EXISTING_LEARNER_LINKING_ENABLED; disabled in package-consumer builds). A teacher adds an existing learner to a strictly browser-local class card by entering that learner's permanent SkillPilot ID — creating no server-side classes, teacher accounts, or membership records. Identity limitation: A permanent SkillPilot ID is not a publicly shareable read-only identifier; it is the bearer secret granting full learner-state access. Apart from the explicit, confirmed "Make available in cockpit" plan-copy action, the Trainer UI uses it solely via read operations, while the credential itself remains a full learner key.

8.1. Product invariants

  • Sole learner ownership: Personal Curriculum Level 2, focus, planned goals, mastery, and all other learner state remain owned exclusively by the learner. The teacher's browser stores only the local class name, local learner alias, permanent SkillPilot ID, and a sanitized Level-2 snapshot (selected, filterId, durationModel, stage).
  • Separate subject views: Mathematics, Physics, and other selected subjects act as switchable local views of the same record, each bound to its own skill landscape and cached scope filter.
  • Functional read-only UI and explicit plan copy: Every Trainer control that mutates learner state remains disabled for existing-learner classes. Only after explicit confirmation does "Make available in cockpit" copy the schedule label, dated blocks, and validated atomic goal IDs into the learner-owned personal subject schedule — omitting class names, aliases, coverage, mastery, baselines, and teacher history, with zero automatic sync.
  • Immutable planning baseline vs. live progress: When first scheduling a scope, a dedicated no-store read captures all learner-facing atomic Level-2 targets and their open subset independently of Level-3 focus (storing only goal IDs, counts, and timestamp — no SkillPilot ID or numeric per-goal mastery, and omitted from plan exports). Live progress is read separately from the backend's current personal target set and stored outcomes (matching Cockpit/tree counts, including in-scope orientation completions without claiming subject mastery, and surfacing missing/stale reads as unavailable rather than zero).
  • Retirement of manual teaching coverage: Manual teaching coverage and completeness attestations are retired as a progress workflow (no second Unterrichts-IST; legacy browser-local records stay intact without producing mastery).
  • Zero backend relationship records: No teacher, class, invitation, or membership record is persisted server-side; deleting a local class removes only that browser entry while the permanent SkillPilot ID stays valid elsewhere. Password-encrypted class exports carry the permanent ID and must be handled as bearer-secret containers; former server-linked supervision cards are never migrated.

8.2. Local setup, refresh, and plan-handoff flow

  1. Under + New class → Add an existing SkillPilot ID locally, the teacher enters class name, local learner name/alias, and permanent SkillPilot ID.
  2. The browser fetches GET /api/ui/learners/{skillpilotId} (cache: no-store), verifies the exact ID and a readable personalCurriculum with at least one selected subject, and creates a local ClassSession.
  3. Opening the class refreshes profile and mastery via ordinary learner routes; scheduling additionally reads GET /api/ui/learners/{skillpilotId}/planning-scope (cache: no-store) to obtain the complete Level-2 target set independently of Level-3 focus (read-only; numeric storage threshold is a compatibility detail, not a grading scale). Editing and saving the class replaces the cached snapshot only after a successful refresh.
  4. "Make available in cockpit" expands each block against the personalized subject graph and prompts for replacement confirmation. The server revalidates atom IDs and block focus, admits newly added IDs only while open, lets IDs already in the personal schedule remain for continuity, removes chronological overlap, and enforces an expected revision so stale local drafts never silently overwrite newer schedules — mutating neither focus, active goal, nor mastery.

The copied schedule stays learner-controlled: plan mode defaults to off, its first goal starts deliberately, and enabling plan mode suppresses generic Autopilot (2.2). After a confirmed completion, automatic handoff applies only when the completed goal belongs to at least one currently valid stored plan: a unique eligible candidate from a plan containing that goal takes precedence, falling back to a unique eligible candidate across all valid plans only if none exists there. Ties, invalid/missing plans, or absent due goals fail closed (keeping current focus without selecting a new active goal).

8.3. Read boundary, encryption, and legacy retirement

  • Frontend projection vs. bearer authority: Requests hit standard learner endpoints (including the global mastery map); switching subjects clears navigation state and never cross-renders Mathematics state in Physics or vice versa, while enforceable read-only isolation in future features would require a distinct scoped credential. The teacher device and unlocked browser profile sit inside the trust boundary.
  • Browser storage and AES-256-GCM exports: Active class records sit unencrypted in the local browser profile; downloaded class files are encrypted client-side via PBKDF2-SHA-256 + AES-256-GCM using a teacher-chosen passphrase never sent to SkillPilot (protecting exported files at rest only; legacy plaintext files load only as flagged migration input, and former server-linked files are rejected).
  • Removal of server-linked supervision cards: On first Trainer load, the browser purges entries marked linked-supervision, linkedSupervision, or teacher-membership along with their local credentials and course-plan keys, while a forward-only database migration drops legacy workspace, course, and membership tables. Learner sessions, MCP/OAuth tools, provider launch flows, and submitted MCP Apps UI artifacts remain untouched.