# 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).