rootnode-academy/docs/ROOT_FOUNDATIONS_ARCHITECTURE.md

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.

Status as of Phase 6E: this document was written as a DESIGN in Phase 6D, when only ROOT 01 was actually authored. As of Phase 6E, all four courses below (ROOT 01-04) are fully authored and READY exactly as designed here — see docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md and docs/ROOT_FOUNDATIONS_PILOT_READINESS.md for the built/verified state. The module tables below remain accurate as the as-built architecture, not just the original plan.

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.