# ROOT_ V1 Curriculum Manifest

Phase 6F — the canonical technical definition of what ROOT_ V1, the first sellable version of
the ROOT_ program, actually includes. Where this disagrees with an older doc (`ROOT_PILOT_
CURRICULUM.md`, `ROOT_PROGRAM_ARCHITECTURE.md`), this document is the current source of truth;
those documents have been updated to point back here.

## V1 course list

| # | Course | In V1? | Status | Required? | Prerequisite(s) | Duration (38-40 activities/course avg) |
|---|---|---|---|---|---|---|
| 1 | Computing & Linux Foundations | Yes | READY | Required | — | 353 min (38 activities) |
| 2 | Linux Administration & Networking | Yes | READY | Required | ROOT 01 | 388 min (37) |
| 3 | Git & Collaborative Development | Yes | READY | Required | ROOT 02 | 312 min (31) |
| 4 | Containers & Docker | Yes | READY | Required | ROOT 03 | 444 min (43) |
| 5 | Kubernetes Foundations | Yes | READY | Required | ROOT 04 | 403 min (28) |
| 6 | Kubernetes Application Workloads | Yes | READY | Required | ROOT 05 | 299 min (23) |
| 7 | Kubernetes Networking & Configuration | Yes | READY | Required | ROOT 06 | 356 min (28) |
| 8 | Kubernetes Storage & Scheduling | **No** | PARTIAL | Excluded | — | 250 min (15) — excluded from V1 total |
| 9 | Kubernetes Security | Yes | READY | Required for Capstone | ROOT 06 | 745 min (40, includes CKS-depth optional labs) |
| 10 | Kubernetes Troubleshooting & Observability | Yes | READY | Required | ROOT 06 | 280 min (21) |
| 11 | DevOps & Platform Engineering (orientation) | Yes | PARTIAL (by design) | Optional bonus | ROOT 10 (non-gating) | 35 min (3) |
| 12 | RootNode Real Ops | Yes | READY | Required for Capstone | ROOT 10 | 115 min (6) |
| — | ROOT Capstone | Yes | READY | Terminal | ROOT 12 AND ROOT 09 | 120 min (5) |

**ROOT_ V1 total: 3,850 minutes = 64.2 structured hours** (12 courses, excludes ROOT 08's 250
min). Program-wide total including the excluded ROOT 08: 4,100 minutes = 68.3 hours. Full
per-module breakdown in `docs/ROOT_PROGRAM_DURATION_MODEL.md`.

Every V1-included course's real per-module evidence (activity counts, lab list, assessment
wiring) lives in `docs/ROOT_FOUNDATIONS_PILOT_READINESS.md` (ROOT 01-04) and `docs/
ROOT_CURRICULUM_COVERAGE_MATRIX.md` (ROOT 05-13). This manifest is the scope decision; those
documents are the evidence.

## ROOT 08 — excluded from V1 (Step 2)

ROOT 08 (Storage & Scheduling) exists with 2 PARTIAL modules (bare scenario banks, no lesson
scaffolding) but critically **is not required by anything downstream** — ROOT 09 and ROOT 10
both branch directly off ROOT 06 by design (see `ROOT_PROGRAM_ARCHITECTURE.md`'s "deviations
from the suggested sequence"). Leaving it visible mid-sequence (course #8, between two READY
courses) would look to a self-paced student like a course they skipped, when V1 was never
designed to require it.

**Mechanism**: `visibility = 'draft'` on the course and both its modules — the existing hard
gate (`COURSE_CONTENT_MODEL.md` §6), excluded from every student-facing query, still fully
visible/manageable for instructors. No content was deleted; this is reversible the moment ROOT
08 gets the same authoring pass ROOT 01-04 got.

## ROOT 11 — included, repositioned as orientation-only bonus (Step 3)

ROOT 11 has exactly one real, finished, self-paced-ready module (lesson + knowledge check +
reflection) bridging "systems administration" to "platform engineering thinking." The other six
designed modules (CI/CD, GitOps, IaC) require lab infrastructure not yet built and are
explicitly out of Phase 6F's scope (per the authorization's own DO-NOT-BUILD list).

**Decision**: keep it in V1, but its course description was rewritten to say plainly that it is
a single orientation module, not a full DevOps course, and that the remaining six are designed
but not yet built. It stays `status = 'partial'` (honest) and `visibility = 'published'`
(real, finished content worth keeping visible). Nothing downstream requires it — a student who
skips it loses nothing gating-wise.

## The three instructor-led-only practice banks (Step 4)

`root-06-m01-deployments-and-workloads`, `root-07-m01-services-and-networking`, and
`root-10-m02-general-troubleshooting` were flagged in Phase 6E as instructor-led-only: bare
scenario banks with zero lesson/demonstration/knowledge-check framing.

**Critical finding before any fix was applied**: these three modules' scenario_ids are not
generic supplemental practice — they are the *literal* content of the pre-existing
`scenarios/rootnode-path.json` "workloads"/"networking"/"troubleshooting" stages, the older,
separate mechanism that gates whether a student can even **start** the `rootnode-capstone`
assessment. An initial attempt to reclassify them `is_required = false` (making them optional
for course completion) was caught during this phase's own audit before being committed: it would
have let a self-paced student reach a course-tree-"complete" state while remaining silently,
confusingly blocked from the Capstone by the older stage gate. See `platform/api/migrations/
030_phase6f_capstone_gate_correction.sql` for the full self-correction record.

**Actual fix (Option A, not B)**: each module kept its activities `is_required = true` and
received one short intro-lesson activity (`*-a00-lab-bank-intro`) explaining what the bank is,
why it has no per-scenario teaching, and how to use it — the minimum real authoring needed to
be honestly self-paced-ready, not a reclassification. All three modules, and their parent
courses (ROOT 06, 07, 10), now genuinely earn `status = 'ready'`.

## Course-level status audit correction (Step 0)

Auditing `courses.status` against actual module-level status (not trusting prior phase reports)
found it had drifted stale for ROOT 05, 06, 07, 09, 10, 12, and Capstone — every module in each
had already reached real `ready` content, but the course-level field was never bumped. Corrected
in `029_phase6f_root_v1_integration.sql`; no new content was required for ROOT 05, 09, 12, or
Capstone (already fully authored), only for 06/07/10 (the practice-bank intro lessons above).

## Capstone gate review (Step 7)

Two separate, independent gates protect the Capstone:

1. **The legacy stage-based gate** (`scenarios/rootnode-path.json`'s `unlock_rule`, checked by
   `POST /api/assessments/rootnode-capstone/start`): six K8s scenario stages (foundation,
   workloads, networking, configuration, troubleshooting, real-ops). **Left unchanged** this
   phase — it has no natural "security stage" without new scenario-bank authoring, out of scope.
2. **The course-layer gate** (`courses.prerequisites` on `root-capstone`, checked by
   `buildCourseTree()`): previously `{root-12-real-ops}` only.

**Decision: strengthened.** `root-capstone.prerequisites` now also requires
`root-09-kubernetes-security`. Evidence: the Capstone's own scenario pool
(`assessment_definitions.pool_spec`) has zero overlap with the security assessment's CKS-style
pool — a student could pass the Capstone having never touched a security scenario. ROOT 09 only
reached genuine `ready` status this same phase, so requiring it any earlier would have gated on
unfinished content. ROOT 09 and ROOT 12 are already sibling courses (both prerequisite = ROOT
06), so this adds no new sequencing burden — either order, or in parallel. See `031_phase6f_
capstone_security_prerequisite.sql`.

## Program + Lab orientation (Steps 9-11)

No orientation content existed anywhere before this phase (audited by grep across
`content/root`). Added `root-01-m00-welcome-to-root`, a new required front-door module — the
same pattern `root-05-m00` already established — with two lessons (program overview and Lab
lifecycle) and a knowledge check, sequenced before what was previously ROOT 01's first module.
See `032_phase6f_root_v1_orientation.sql`.

## ROOT_ V1 curriculum version (Step 26)

No second versioning system was built — this manifest reuses the existing per-row `version`
integer (`courses`/`course_modules`/`module_activities`), unchanged in convention from
`COURSE_CONTENT_MODEL.md` §6b. "ROOT_ V1" itself is a scope label (which course/module ids are
included, defined by this document), not a new database concept. What's frozen for a historical
enrollment is exactly what was already true pre-Phase-6F: a student's `activity_completions`
row stays valid across a later semantic edit to the same `activity_id`, keyed by the stable id,
not a snapshot. A future "V1.1" content correction follows the same rule `COURSE_CONTENT_MODEL.md`
§6b already documents — bump `version` on the changed row for a semantic edit, skip it for a
typo-only fix. A future V1 SCOPE change (adding/removing a course from the manifest) is a change
to this document plus a `visibility`/`prerequisites` migration, exactly like ROOT 08's exclusion
this phase — not a new mechanism to build.

## What this manifest deliberately does not cover

Pricing, registration, marketing copy, and camp scheduling are out of scope for this document —
see `docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md` and `docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md`
for delivery packaging, and Phase 7 for the business/product architecture layer.