rootnode-academy/docs/ROOT_V1_INSTRUCTOR_GUIDE.md

ROOT_ V1 Instructor Guide

Phase 6F Step 12 — a practical guide for teaching ROOT_ V1. This does not duplicate any individual module's own Instructor Notes (every lesson/lab content file ends with an ## Instructor Notes section — facilitation tips, timing, common mistakes); it covers what spans the whole program instead.

Program overview & audience

See docs/ROOT_V1_SYLLABUS.md for the full course sequence, outcomes, and duration. Audience is approximately age 15+ through adults — readiness (comfort with a keyboard, following multi-step instructions), not age, is the real gate.

Using CurriculumView

The instructor curriculum view (/admin, Curriculum tab) shows every course/module/activity for a given student or cohort with the exact same lock/completion state the student sees — plus instructor_notes on every activity (never shown to students). Use it to see precisely where a student is stuck before a help request even comes in.

Preparing Labs

Use Prepare Labs (classroom/cohort view) to provision every enrolled student's disposable Lab ahead of a session, rather than each student launching cold when class starts — this was built and load-tested in Phase 2B and confirmed to run concurrently across a full cohort.

Classroom workflow

1. Prepare Labs before the session starts.
2. Students work through the current module at their own pace; you see live progress per student in the classroom view.
3. A student's Need Help request notifies you immediately with a category and message — respond in whatever way your delivery format supports (in person, chat, screen share).
4. If a Lab environment itself seems broken for a student (not just the task being hard), an instructor can reset it the same way a student can (Reset Scenario & Environment) — this never touches the student's academic progress.
5. At the end of a session, cohort Labs can be destroyed in bulk (build/reprovision cost, not an academic reset) — progress survives regardless (proven in Phase 2B/5B).

Self-paced vs. instructor-led

The platform makes no code-level distinction between the two — the same courses, Labs, and assessments work identically either way. The difference is entirely in who else is watching: an instructor-led student additionally has a live instructor able to see their progress and receive help requests. Timing/pacing guidance for instructor-led delivery lives in each module's own Instructor Notes and in docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md.

Assessments & Capstone

Formal assessments (ROOT 01/02/03/04/09) and the Capstone are timed and hints-limited by design — see docs/ROOT_V1_ASSESSMENT_MAP.md. Do not pre-brief students on the exact random-pool draw; it's server-authoritative and drawn fresh per attempt specifically so this isn't possible to game, and pre-briefing undermines what the assessment is actually checking.

Help-request workflow

Need Help categories exist to help you triage at a glance (e.g. lab_problem vs. a conceptual question) — treat a lab_problem report as potentially a real broken environment worth checking yourself before assuming the student made an error.

Common student issues

• "My Lab disappeared / lost my work" — expected if a Lab was recreated; see the student Lab-orientation content (root-01-m00-a02-lesson-disposable-lab) and reassure them their academic progress is untouched.
• Confusing a module's optional activities for a blocker — is_required=false activities (e.g. ROOT 09's advanced CKS labs) never block module/course completion; the platform will never require them, but some students assume more is mandatory than actually is.
• Getting to ROOT 09/10/12 out of order — real, server-enforced module prerequisites inside a course (e.g. root-06-m01's own practice bank requires root-06-m02 first) sometimes surprise a student used to free-form navigation; this is intentional sequencing, not a bug.

Lab reset/recreate — what it means

Resetting a Lab rebuilds the disposable environment from scratch; recreating one (e.g. after a Lab-host failure) does the same at the infrastructure level. Neither ever touches activity_completions, progress, or achievements — a student's actual academic record.

What student progress actually means

Course/module/activity complete flags are computed live, every time, from real underlying facts (a real scenario pass, a real assessment pass, or an explicit manual marker for lesson-type content) — never a separately-maintained flag that could silently drift from reality. See docs/COURSE_CONTENT_MODEL.md §4.

What not to do

• Don't manually flip a student's completion state via the admin API/database to "help them along" — it breaks the guarantee that a complete flag reflects real work, and the Phase 6E security fix means the platform will refuse a manual mark on a still-locked module anyway.
• Don't rely on the legacy rootnode-quick-assessment as a course-completion signal for any V1 course — it's a general diagnostic tool, not wired to any course's own gate.
• Don't assume ROOT 08 or ROOT 11's un-built modules are "coming soon this cohort" — they're explicitly out of V1 scope (see docs/ROOT_V1_CURRICULUM_MANIFEST.md); don't promise timelines the curriculum doesn't yet support.

Security boundaries

Every student's Lab is an isolated, disposable, non-privileged-to-the-host container — even though it runs a real nested Docker Engine and a real k3s cluster inside itself. No student Lab can reach another student's Lab, the Lab host's own Docker daemon, or any RootNode credential. This is unchanged infrastructure from earlier phases (see docs/LAB_ARCHITECTURE.md, docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md) — instructors do not need to configure anything for this to hold.

Troubleshooting/operations notes

If a whole cohort's Labs seem slow to provision, check Provisioner health before assuming a content problem — this program's content changes never affect Lab boot performance (see docs/PHASE6F_ROOT_V1_PILOT_READINESS.md's resource observations for real numbers from this phase's own rehearsals).