ced4568andClaude Sonnet 5
bd0a10fbfb
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]>
5.5 KiB
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 for how this fits the overall
pilot manifest.