# ROOT Foundations Architecture — ROOT 01-04

Phase 6D §1 — the curriculum architecture for the foundational half of ROOT_, built entirely on
the existing course/module/activity model (`docs/COURSE_CONTENT_MODEL.md`) and the existing
scenario/assessment engines. See `docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md` for why no new
activity type or content model was needed. Every course below is a row that already exists in
`courses` (`status='planned'`, seeded by Phase 6A's `022_course_content.sql`) — this phase adds
their modules and activities, and updates their `status`/`objectives`/`prerequisites`.

## Course sequence and prerequisite chain

```
01 Computing & Linux Foundations
        ↓
02 Linux Administration & Networking
        ↓
03 Git & Collaborative Development
        ↓
04 Containers & Docker
        ↓
05 Kubernetes Foundations (existing)
```

Enforced server-side via `courses.prerequisites` (the same mechanism already gating
05→06→07/09/10→12→Capstone) — not UI-hidden alone. `root-05-kubernetes-foundations.prerequisites`
is updated this phase to add `root-04-containers-and-docker`, so a student cannot reach ROOT 05
without the foundations chain complete. This does not touch the capstone assessment engine's own
`unlock_rule` (still the original 6 `rootnode-path.json` stages) — course-level prerequisite
gating and the capstone's own gate remain the two independent systems `docs/COURSE_CONTENT_MODEL.md`
§5 and `docs/ROOT_CAPSTONE_READINESS.md` §3 already establish.

## Extension point for future placement/override (Step 20)

Not built this phase. The extension point already exists structurally: `courses.prerequisites`
is a plain array a future placement-assessment feature could programmatically satisfy (e.g. by
recording a passing placement score as an `activity_completions`-equivalent fact), or an
instructor override could satisfy by directly marking an enrollment's course complete through
the existing admin layer — neither requires a schema change to unlock. No bypass button is
implemented; this paragraph exists so a future phase doesn't need to reopen the prerequisite
model to add one.

---

## ROOT 01 — Computing & Linux Foundations

Target learner: a technically curious beginner with no assumed prior Linux/CLI experience.
Estimated duration: ~5.5 hours self-paced / ~4 hours instructor-led (see
`docs/ROOT_PROGRAM_DURATION_MODEL.md` for the derived total).

| # | Module | Outcome (verb-first) | Activities | Real Ops connection |
|---|---|---|---|---|
| 1 | How Computers Run Software | Explain what the OS/kernel manages (CPU, RAM, storage, processes) vs. what an application does | lesson, guided_exercise (inspect `/proc/cpuinfo`, `free -h`, `lsblk`, `ps aux` on paper first), lab (`linux-inspect-hardware` — real inspection commands), reflection | This is literally what a container later virtualizes — a Pod's resource requests/limits are promises about exactly these same resources. |
| 2 | Linux & The Shell | Use a shell confidently: run commands, read exit codes, use history/tab-completion/man pages | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-shell-basics`), reflection | Every `kubectl exec` session later drops a student into this exact shell experience. |
| 3 | Navigating the Filesystem | Navigate absolute/relative paths; explain what `/etc`, `/var`, `/home`, `/tmp`, `/usr`, `/proc` are for at a conceptual level | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-filesystem-navigation`), reflection | Container images later have this exact same tree — `/etc/nginx/nginx.conf` isn't a new idea, it's the same filesystem convention. |
| 4 | Files & Text | Manipulate files and text streams; use pipes/redirection to compose commands | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-files-and-text`), reflection | `kubectl logs \| grep` later is the exact same composition skill applied to a different data source. |
| 5 | Processes | Explain the process concept (PID, foreground/background, signals); inspect and terminate a real process | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-process-management`), reflection | A container IS (mostly) one isolated process tree — this module is the direct prerequisite for understanding what a container "contains." |
| 6 | Users & Permissions Foundations | Explain ownership and rwx permissions; use `chmod`/`sudo` correctly; state the least-privilege principle | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-permissions-foundations`), reflection | Direct root of ROOT 09's SecurityContext/RBAC — "least privilege" is introduced here first, in a context students can literally see and touch. |

Assessment: `rootnode-linux-foundations-assessment` (knowledge + state-validation, see §"Assessments" below).

## ROOT 02 — Linux Administration & Networking

Prerequisite: ROOT 01 complete. Target learner: comfortable with the ROOT 01 shell/filesystem/
process/permissions basics, ready to reason about services and networks.

| # | Module | Outcome | Activities | Real Ops connection |
|---|---|---|---|---|
| 1 | Linux System Administration | Explain packages/services/systemd conceptually; read logs; use environment variables and config files | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-admin-services-logs`), reflection | A Kubernetes controller IS a systemd-like supervisor pattern generalized across a cluster — "restart on failure" isn't new in ROOT 06, it's a concept students meet here first. |
| 2 | Storage & Filesystems | Explain block devices/partitions/mounts conceptually; distinguish persistent vs. temporary data; inspect real disk usage | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-storage-inspection`), reflection | Direct root of ROOT 08's PV/PVC model and ROOT 04's bind-mount/volume distinction. |
| 3 | Networking Mental Model | Explain hosts/interfaces/IP/subnet/gateway/DNS/ports/TCP-vs-UDP/client-server at a conceptual level | lesson, demonstration, knowledge_check, guided_exercise, reflection (conceptual module — no lab; see note below) | **Critical module** — the direct prerequisite for reasoning about Pod IPs, Services, Ingress, NetworkPolicy, and DNS later. |
| 4 | Linux Network Inspection | Use `ip addr`/`ip route`/`ss`/`ping`/`curl`/`dig` to answer a specific diagnostic question, not just run syntax | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-network-inspection`), reflection | Exactly the toolkit ROOT 10's troubleshooting framework assumes a student already has. |
| 5 | DNS & HTTP | Trace a request: browser → DNS → IP → TCP → HTTP → server → response | lesson, demonstration, knowledge_check, guided_exercise, lab (`linux-dns-http-trace`), reflection | The exact conceptual bridge `docs/ROOT_PROGRAM_ARCHITECTURE.md` names for later Kubernetes Services/Ingress/DNS. |
| 6 | Troubleshooting Linux Systems | Apply Observe→Evidence→Hypothesize→Test→Repair→Validate→Prevent to a Linux-level failure | lesson, demonstration, guided_exercise, lab (`linux-troubleshooting-framework`), reflection | Literally the same framework `root-10-m03-troubleshooting-framework` already teaches — introduced here first, at the Linux level, so it "already feels natural" by ROOT 10 (Step 15's explicit goal). |

Module 3 note: per the readiness standard's "sequence should match the subject," a purely
conceptual mental-model module earns READY through demonstrated reasoning (its knowledge check
and guided exercise), not a forced lab — mirroring `root-05-m00`'s own precedent. Module 4
immediately after it is where the same concepts become hands-on.

Assessment: `rootnode-linux-networking-assessment`.

## ROOT 03 — Git & Collaborative Development

Prerequisite: ROOT 02 complete. Uses only local repositories (a working tree + a local bare
"remote") inside the student's own Lab — no Gitea account, no network credential, no
RootNode-canonical-repo access ever reaches a student Lab (`docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md`
§4).

| # | Module | Outcome | Activities | Real Ops connection |
|---|---|---|---|---|
| 1 | Why Version Control Exists | Explain what problem version control solves (history, collaboration, reproducibility, source of truth) | lesson, knowledge_check, reflection | Sets up "Git as source of truth" — the exact idea GitOps (ROOT 11) generalizes. |
| 2 | Git Mental Model | Explain working tree / staging area / repository / commit / branch / remote as a model, before commands | lesson, demonstration, knowledge_check, guided_exercise, reflection | Same "model before commands" pedagogy as ROOT 05's mental-model module. |
| 3 | Everyday Git | Use `status`/`add`/`commit`/`log`/`diff` to make and inspect real changes | lesson, demonstration, knowledge_check, guided_exercise, lab (`git-everyday-basics`), reflection | Every future IaC/GitOps workflow assumes this fluency as a given. |
| 4 | Branching | Create branches, switch between them, merge, resolve a simple conflict | lesson, demonstration, knowledge_check, guided_exercise, lab (`git-branching-and-merge`), reflection | Direct root of CI/CD's branch-triggered pipelines (future ROOT 11 content). |
| 5 | Remote Repositories | Clone/fetch/pull/push against a real local-bare remote; explain `origin` | lesson, demonstration, knowledge_check, guided_exercise, lab (`git-remote-clone-push`), reflection | Direct root of GitOps's "push triggers deployment" model. |
| 6 | Engineering Workflow | Write meaningful commits; explain why `main` is protected and why rollback via history matters | lesson, demonstration, knowledge_check, reflection | Explicit bridge to ROOT 11's "Git as source of truth for infrastructure" framing. |

Assessment: `rootnode-git-fundamentals-assessment`.

## ROOT 04 — Containers & Docker

Prerequisite: ROOT 03 complete. Uses the nested Docker Engine
(`docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md` §3) — the direct bridge into Kubernetes.

| # | Module | Outcome | Activities | Real Ops connection |
|---|---|---|---|---|
| 1 | Why Containers Exist | Explain the packaging/dependency-isolation/repeatability problem containers solve; contrast VM vs. container | lesson, demonstration, knowledge_check, reflection | Sets up "Kubernetes orchestrates what Docker already isolates" — Module 8's thesis. |
| 2 | Images & Containers | Explain image/layer/container/registry/tag as a model | lesson, demonstration, knowledge_check, guided_exercise, reflection | A Kubernetes Pod's `image:` field is this exact concept, unchanged. |
| 3 | Docker CLI | Pull/run/inspect/log/exec/stop/remove a real container | lesson, demonstration, knowledge_check, guided_exercise, lab (`docker-cli-basics`), reflection | `kubectl exec`/`kubectl logs` are the same actions against a different orchestrator. |
| 4 | Container Networking | Explain host-vs-container port, publish a port, reach one container from another | lesson, demonstration, knowledge_check, guided_exercise, lab (`docker-container-networking`), reflection | Direct root of Pod IPs/Services — builds explicitly on ROOT 02 M3/M4. |
| 5 | Container Storage | Explain ephemeral container filesystem vs. bind mounts vs. volumes | lesson, demonstration, knowledge_check, guided_exercise, lab (`docker-container-storage`), reflection | Direct root of Kubernetes PVC — builds explicitly on ROOT 02 M2. |
| 6 | Dockerfile & Image Build | Write a Dockerfile (`FROM`/`RUN`/`COPY`/`WORKDIR`/`CMD`) and build a real image | lesson, demonstration, knowledge_check, guided_exercise, lab (`docker-build-image`), reflection | Direct root of CI/CD's build step (future ROOT 11 content). |
| 7 | Docker Compose | Define and run a real multi-service app (two services, one network, one volume) | lesson, demonstration, knowledge_check, guided_exercise, lab (`docker-compose-multiservice`), reflection | Direct conceptual root of a Kubernetes multi-Pod application. |
| 8 | Containers → Kubernetes | Explain what Kubernetes adds on top of what Docker already does (scheduling, desired state, controllers, service discovery, health management, scaling, rollout) | lesson, knowledge_check, reflection | The explicit bridge module — a student should be able to answer "why Kubernetes" in their own words entering ROOT 05. |

Assessment: `rootnode-containers-assessment`.

## Assessments (Step 18)

Four new `assessment_definitions` rows, one per course, using the existing Phase 3B engine
exactly as `rootnode-security-assessment` (Phase 6C) does — mixing knowledge-recall scenarios
(`type: mcq`) with real state-validation scenarios (`type: task`, the same `runCommand`-backed
mechanism every lab already uses). No KubeKosh/Kubernetes scenario is force-fit into a
non-Kubernetes assessment. See `docs/PHASE6D_ROOT_FOUNDATIONS.md` for which are actually wired
this phase vs. deferred.

## Duration model

See `docs/ROOT_PROGRAM_DURATION_MODEL.md` for the derived instructional-hour estimate — computed
from actual `estimated_duration_minutes` values on real activities, not invented.