ced4568/rootnode-academy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(phase6c): pilot readiness standard, pilot curriculum manifest, ROOT 11 scope

Browse Source 
Adds the four required Phase 6C documents:

- ROOT_PILOT_READINESS_STANDARD.md — the explicit 8-point sufficiency bar
  used to judge every module this phase, replacing any fixed activity-count
  assumption.
- ROOT11_DEVOPS_PLATFORM_SCOPE.md — evaluates all 7 proposed ROOT 11 modules
  individually (READY TO AUTHOR NOW / PARTIAL-LESSON-ONLY / REQUIRES FUTURE
  LAB ENVIRONMENT), with what current infra supports vs. what GitOps/CI-CD/
  IaC/observability would each require.
- ROOT_PILOT_CURRICULUM.md — the authoritative pilot manifest: instructor-led
  as the first pilot's delivery mode, honest READY/PARTIAL/DEFERRED/NOT IN
  PILOT status per course and module, and what is intentionally excluded
  (ROOT 01-04 never authored, ROOT 08 non-capstone-gating and deferred, ROOT
  11 modules 2-7, three practice-bank modules instructor-led-only this pilot).
- PHASE6C_CURRICULUM_COMPLETION.md — the phase's own record of what was
  upgraded, why, the bug found and fixed, and the pilot readiness conclusion.

Updates ROOT_CURRICULUM_COVERAGE_MATRIX.md with the verified before/after
module counts (21->22 modules, 6->16 READY) and per-module upgrade rationale,
and ROOT_CAPSTONE_READINESS.md with a re-review confirming the unlock gate's
6 stages, and ROOT 08/09's non-gating status, are unchanged by this phase's
curriculum expansion.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
This commit is contained in:
ced4568
2026-08-26 11:21:09 -05:00
co-authored by Claude Sonnet 5
parent 01d3764138
commit bd0a10fbfb
6 changed files with 488 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md
+64
View File
@@ -0,0 +1,64 @@
# ROOT 11 — DevOps & Platform Engineering: Scope Decision
Phase 6C's mandate for ROOT 11 was to stop it being an undefined `planned` placeholder by
making an explicit, evidence-based scope decision — not to fake seven hands-on labs the current
platform cannot honestly deliver. This document is that decision.
## Purpose and learning outcomes
ROOT 11 exists to give a student who has just finished ROOT 05-10 (Kubernetes hands-on) and
ROOT 12 (incident response) the vocabulary and mental model to see their skills as part of a
larger DevOps/platform engineering practice, and an honest map of what comes next once the
platform can support it hands-on. It is explicitly NOT meant to teach GitOps, CI/CD, or
Infrastructure as Code as hands-on skills in this phase.
## The seven proposed modules, evaluated against current architecture
| # | Proposed module | Classification | Why |
|---|---|---|---|
| 1 | Sysadmin → Platform Thinking | **READY TO AUTHOR NOW** | Pure orientation/reframing content. No new infrastructure needed — it's built entirely on ROOT_'s existing curriculum, referenced explicitly. Authored this phase as `root-11-m01-devops-platform-thinking`. |
| 2 | GitOps & Declarative Delivery | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a Git repository the student can push to and a deployment-automation controller (ArgoCD or Flux) watching it. The Lab platform provisions an isolated k3s VM per student today; it does not provision or wire a Git remote or a GitOps controller. Faking this with a Kubernetes-only scenario would teach "apply a manifest," not GitOps — a materially wrong mental model. |
| 3 | CI/CD Fundamentals | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a CI runner (even a minimal one) that can check out code, run a pipeline, and produce an artifact or trigger a deploy. No such runner exists in the Lab image or Platform API today. |
| 4 | Infrastructure as Code | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a provisioning target and a tool like Terraform/OpenTofu applying against it. Kubernetes objects are already declarative, but IaC's actual lesson is about provisioning infrastructure *below* Kubernetes — cloud resources, networking, the cluster itself — which this platform doesn't expose to a student sandbox. |
| 5 | Observability & SLO Thinking | **PARTIAL-LESSON-ONLY** | The conceptual half (what SLIs/SLOs are, error budgets, why "is the Pod Running" isn't observability) can be taught honestly without a metrics stack. A genuinely hands-on version needs Prometheus/Grafana (or equivalent) wired into the Lab VM, which doesn't exist today. Recommend authoring the lesson-only half in a future sub-phase; do not build the metrics stack this phase. |
| 6 | Platform Engineering & DX | **READY TO AUTHOR NOW** (folded into module 1) | Conceptually adjacent enough to module 1 that a separate module would duplicate content. Its core ideas (self-service, golden paths, reducing cognitive load) are already covered in `root-11-m01`. |
| 7 | Reliability / Automation / Operational Ownership | **PARTIAL-LESSON-ONLY** | Largely already covered hands-on by ROOT 12 (Real Ops incidents) and ROOT 10 (troubleshooting framework). A short lesson connecting those two courses' skills explicitly to "reliability engineering" as a named discipline is legitimate future content; a new hands-on lab would duplicate ROOT 12 rather than teach something new. |
## What was actually authored this phase
Only module 1 (folded with module 6's ideas) — `root-11-m01-devops-platform-thinking` — a
lesson, knowledge check, and reflection. No Lab activity exists for ROOT 11 and none was
faked. The lesson explicitly tells students which future topics (GitOps, CI/CD, IaC,
observability) require infrastructure this course doesn't yet provide, rather than staying
silent about the gap.
## What current infrastructure supports vs. what future modules need
**Supports today:** Kubernetes/k3s hands-on labs via the existing Lab VM provisioning
(Platform API → Provisioner → Lab Router), the existing assessment engine, and the existing
content/course model — sufficient for orientation and conceptual lesson content referencing
Kubernetes skills already taught.
**Would need building for modules 2-4, and the hands-on half of 5 and 7 (future phases,
NOT this phase):**
- A Git hosting target reachable from a student's Lab VM, plus a GitOps controller
(ArgoCD/Flux) pre-installed or installable in that VM.
- A minimal CI runner (self-hosted GitHub Actions runner, Drone, or similar) wired to a
student-scoped repository.
- A provisioning target IaC tooling can act against — even a scoped-down one (e.g., Terraform
against a mock/local provider) — plus the tooling itself in the Lab image.
- A metrics/logging stack (Prometheus + Grafana at minimum) installed per-Lab-VM or shared with
per-student scoping, for the hands-on half of Observability.
None of this was built in Phase 6C, per its explicit "do NOT build" list (Section 26).
## Pilot inclusion recommendation
Include `root-11-m01-devops-platform-thinking` in the first pilot as a **closing orientation
module** — no hands-on requirement, explicitly scoped as conceptual. Do not present ROOT 11 as
a complete course in pilot marketing or instructor materials; present it as "orientation now,
hands-on modules 2-7 in a future phase once the required lab environments exist." This keeps
the pilot honest about what ROOT 11 currently is versus what it will become.
See [`docs/ROOT_PILOT_CURRICULUM.md`](ROOT_PILOT_CURRICULUM.md) for how this fits the overall
pilot manifest.