/dashboard, third tab. "Teach with Scolavo."
Unlike the parent view, this one is genuinely wired — it talks to the classroom Lambda and a real roster. It has three states, and which one a teacher sees depends on deployment and sign-in.
1 · Backend not deployed → an honest coming-soon: "Classroom tools are coming", with links to /pricing#schools and /contact. Gated on classroomConfigured().
2 · Deployed but signed out → "Sign in to manage a class" — classrooms sync to a Scolavo account so students can join from any device. Gated on classroomEnabled().
3 · Signed in → the working classroom, below.
That first gate is the right pattern and worth copying: when a backend is absent the UI says so plainly rather than rendering empty tables that look broken.
They keep their own account and their own progress; joining links them to you, it does not take anything over.
skills Mastered, and last active.
No per-student emails and no setup — that is the point of the join-code design.
| column | |
|---|---|
| Student | |
| Mastered | skills at the top rung |
| Classes | finished |
| Last active | the "who needs a nudge" signal |
Only classes where you are the teacher appear; a class you joined as a student does not show here. If progress fails to load the table says so and asks you to refresh, rather than rendering zeros — a zero and a failure look identical otherwise, and one of them is a lie.
JoinClass lives on the learner dashboard: "Have a class code?", with the honest footnote "No code? You don't need one to learn on Scolavo." Classrooms are additive; nothing about the product requires one.
Classroom is its own Lambda plus per-learner cloud progress — see 20 · The admin backend. One operational note carried over from provisioning it: run the provision script in the foreground. In the background on Windows it wedges.