ced4568andClaude Sonnet 5
d066410451
New: PHASE6F_ROOT_V1_PILOT_READINESS.md (phase summary), ROOT_V1_CURRICULUM_MANIFEST.md (canonical V1 scope), ROOT_V1_PREREQUISITE_MAP.md, ROOT_V1_ASSESSMENT_MAP.md, ROOT_V1_SYLLABUS.md, ROOT_V1_INSTRUCTOR_GUIDE.md, ROOT_V1_STUDENT_REQUIREMENTS.md, ROOT_V1_INSTRUCTOR_LED_PILOT.md, WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md. Updated: ROOT_PROGRAM_ARCHITECTURE.md (course-sequence table reflects real V1 statuses), ROOT_PILOT_CURRICULUM.md (self-paced-readiness correction), ROOT_PROGRAM_DURATION_MODEL.md (real post-integration totals: 64.2 V1 hours / 68.3 program-wide), ROOT_CAPSTONE_READINESS.md (§1b, the new root-09 course-layer gate), platform/README.md (test list). Co-Authored-By: Claude Sonnet 5 <[email protected]>
112 lines
6.1 KiB
Markdown
112 lines
6.1 KiB
Markdown
# 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).
|