Files
rootnode-academy/docs/RUNBOOK_REMOTE_CLASSROOM.md
T
ced4568 896c230142
Release to Docker Hub / Build & Push Docker Image (push) Canceled after 0s
Release to Docker Hub / Create GitHub Release (push) Canceled after 0s
docs(phase5a): student identity and remote classroom documentation
- PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md: the full design doc.
- RUNBOOK_STUDENT_ACCOUNT_LIFECYCLE.md, RUNBOOK_REMOTE_CLASSROOM.md: operational runbooks.
- REMOTE_AND_SELF_PACED_ARCHITECTURE.md: closes the 'no real student authentication' gap this
  doc previously flagged as the one item blocking self-paced delivery.
- ENGINEERING_SOP.md §5 rewritten (was describing a pre-Phase-2A state no longer true of any
  deployed version of this codebase) plus a new §14; roadmap item 3 updated.
- LAB_ARCHITECTURE.md, PRODUCTION_VALIDATION_CHECKLIST.md, README.md, platform/README.md:
  cross-references and a Phase 5A production-validation section.
2026-08-25 01:20:13 -05:00

54 lines
2.9 KiB
Markdown

# Runbook: Running a Remote Classroom
Covers scheduling, running, and recovering a live class through `/admin` → Classroom. See
`docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` for the underlying design. RootNode does
**not** provide video/voice — the meeting URL field just links out to Meet/Zoom/Teams/whatever
you already use for that.
**Before class: schedule it**
`/admin` → Classroom → pick the cohort → Schedule a class. Title is required; scheduled start,
description, and a meeting URL are optional. Only one class can be `live` per cohort at a time —
scheduling a second one is fine, starting it while another is live is rejected.
**Right before class: Prepare Labs**
Open the classroom → Prepare Labs. This provisions/warms every enrolled student's Lab ahead of
time (same underlying flow as the cohort-level Prepare Labs button) so nobody is waiting on a
cold start once class begins. If a Lab host is at capacity, that student shows as
`capacity_waiting` in the results rather than failing silently — check back or ease off other
concurrent load.
**Start class**
Open the classroom → Start class. Status moves to `live`; students now see a "LIVE NOW" banner
on their Classroom tab and can join.
**During class**
- **Participants table**: presence (`online`/`recently_active`/`offline`, derived from each
student's last heartbeat — not a hard real-time signal, allow ~30s of lag), Lab status, and a
one-line current-work snapshot (stage, scenario, validation failures, hints used).
- **Set current activity**: enter a scenario ID and Set. This only shows students a link — it
never redirects their browser or marks anything complete. Use it to say "everyone open this
next," not to force navigation.
- **Post an announcement**: short messages, shown newest-first on the student side.
- **Help queue**: students flag `lab_problem` / `dont_understand` / `validation_failing` /
`other` with an optional note. Acknowledge when you've seen it, Resolve when it's handled.
There is no chat here — if it needs back-and-forth, use your actual video call.
**End of class**
Open the classroom → End class. Status moves to `ended`; this does not touch Labs or student
progress — destroy Labs separately from the cohort view if you're done with them for the day.
**If you need to cancel a scheduled (not yet started) class:** Cancel, from the classroom
detail view. A `live` class can only be ended, not cancelled.
**If the Platform API restarts mid-class** (deploy, crash, host reboot): nothing to do. Sessions,
the live classroom row, and participant presence all live in Postgres, not in the API process's
memory — students' browsers keep their existing session and heartbeat right through it, and the
dashboard shows the same state a few seconds after the API comes back. This is exercised for
real in `infra/scripts/drills/test-phase5a-rehearsal.js`, which restarts the API mid-rehearsal
and asserts on exactly this.