~/purist Purist Bootcamp back to The Estate

Wipe the Latitude, install Xubuntu 24.04 LTS, and learn the terminal well enough that the rest of the course never has to explain cd again. This phase is written in full detail because you will be following it on a machine with no working browser of its own yet. Read it on another device or print it.

0.A Build the installer (on your Windows PC)

• Back up anything on the Latitude you care about.The install erases the whole disk. Assume nothing survives.
• Download Xubuntu 24.04 LTS from xubuntu.org/download (the LTS "desktop" ISO, about 4 GB).LTS means five years of updates. Xfce desktop keeps most of the 8 GB of RAM free for your actual work.
• Verify the download. On the download page find the SHA256 checksum, then in PowerShell run Get-FileHash .\xubuntu-24.04*-desktop-amd64.iso and compare.First lesson of the course: never install an OS from an unverified image. Two minutes of paranoia, permanent habit.
• Flash a USB stick (8 GB+) with balenaEtcher or Rufus.Etcher is simpler; Rufus is faster. Either works. The stick is erased in the process.

0.B Install

# Latitude 3490 keys, at the Dell logo:
#   F12  = one-time boot menu   (choose the USB stick)
#   F2   = BIOS setup           (only if F12 doesn't offer USB)

• Boot the stick via F12 and choose "Try Xubuntu" first. Confirm Wi-Fi, screen, and trackpad work in the live session before touching the disk.The live session is a free dress rehearsal. If hardware misbehaves here, nothing has been lost yet.
• Run the installer: normal installation, check "Install third-party software", choose Erase disk and install Xubuntu. Skip disk encryption for this machine. Hostname suggestion: latitude.Third-party software = Wi-Fi firmware and media codecs. Encryption is good practice on a travel laptop, but it adds a password prompt at every boot on a learning box that holds nothing sensitive; your call.
• First boot: update everything, then reboot.You want to learn on current packages, and doing it from the terminal instead of the GUI updater is the point.

  sudo apt update          # refresh the package index
  sudo apt full-upgrade    # install everything new
  sudo fwupdmgr refresh && sudo fwupdmgr update   # Dell firmware updates
  sudo reboot

0.C The terminal, for real

• Work through Odin's Command Line Basics and the first sections of Linux Journey (Grasshopper: the Shell).Goal: pwd, ls, cd, mkdir, cp, mv, rm, cat, less, man feel boring. Boring is the target.
• Learn permissions and sudo: read Linux Journey's Permissions section, then in practice: create a file, chmod it 600, 644, 755, and explain to yourself what changed with ls -l.Permissions confusion is the number one beginner wall on Linux. Climb it now, on purpose, on files that don't matter.
• Learn apt properly: apt search, apt show, apt install, apt remove, apt autoremove. Install something fun (htop, tree, neofetch), run each one.The package manager is the app store, the installer, and the updater in one. Every phase of this course starts with apt.
• Make the shell yours: add two aliases to ~/.bashrc (e.g. ll and update), reload with source ~/.bashrc.First taste of configuration-as-text, which is most of what "knowing Linux" means.

  alias ll='ls -alF'
  alias update='sudo apt update && sudo apt full-upgrade'

0.D Git, GitHub, and keys

• Install and configure git, then read chapters 1 and 2 of the free Pro Git book.Version control is non-negotiable and it is easier to learn before your projects get precious.

  sudo apt install git
  git config --global user.name  "Charles Spivey"
  git config --global user.email "bspivey212@gmail.com"
  git config --global init.defaultBranch main

• Generate an SSH key and add it to GitHub following GitHub's SSH guide: ssh-keygen -t ed25519, then paste the public key (.pub) into GitHub settings. Test with ssh -T git@github.com.Keys beat passwords, and understanding the public/private split now pays off again in Phase 4 when you SSH between machines.
• Create ~/projects/workbench, a repo for your notes and dotfiles. Commit your edited .bashrc aliases file and a notes.md. Push it to a private GitHub repo over SSH.Your first end-to-end git loop: init, add, commit, remote, push. This repo becomes the course logbook.

0.E Editor

• Install VS Code per the official Linux instructions (the apt repository method, not the snap), plus extensions: Prettier and Live Server.The apt-repo method teaches you how third-party repositories work, which snap hides from you.
• Learn just enough nano to edit a config file over a terminal: open, edit, save, exit. (Vim comes in Phase 4.)Sooner or later you will be editing a file on a machine with no GUI. Nano is the survival tool.
• Copy this file (course.html) onto the Latitude, open it in Firefox there, and import your exported progress JSON.From here on, the course lives on the machine it is about.

HTML, CSS, and JavaScript, written by hand in files you serve yourself. You already build websites, so this phase is a refresher that closes gaps rather than a from-zero crawl. The projects are Odin's deliberately: Odin gives no solution code, and the struggle is the curriculum.

1.A The refresher: shadow the build of this document

• Read docs/BUILD-NOTES.md side by side with this file's source code.The course app you are using was built as your training material: every markup, CSS, and JS decision in it is narrated as if you were shadowing the build. Open the source in VS Code, find each numbered decision, and make sure you could defend or attack it.
• Break it, then fix it. In a git branch of the bootcamp repo, change three things in course.html on purpose (a token, a selector, a JS function), observe what happens, revert with git.Reading code is weak learning. Predicting what a change does, then checking, is strong learning, and it doubles as git branch practice.

1.B Structure and style

• Work Odin's Foundations HTML and CSS sections, skimming what you know, doing every exercise you cannot predict the output of.The honest filter: if you cannot predict it, you have not learned it yet.
• Flexbox until it is instinct: Odin's Flexbox section, then all 24 levels of Flexbox Froggy without looking anything up.Layout is where hand-coded CSS lives or dies.
• Project: Odin's Landing Page, built pixel-honest from their design image, served locally with python3 -m http.server from ~/projects/.No answer key exists. Serving it yourself instead of double-clicking the file is one more brick in the machine.

1.C JavaScript

• Work Odin Foundations' JavaScript sections (variables through objects, DOM, events), with MDN as the reference tab.Same skim-or-do filter as 1.B.
• Project: Etch-a-Sketch. Hand-first; when done, ask an AI to review your finished code against the hand-first rule.DOM generation, event handling, and state in one small package.
• Project: Calculator, Odin Foundations' final boss.Forces real program design: state machines, edge cases (divide by zero, repeated equals), refactoring when your first structure collapses.
• Ship a real improvement to this course app, hand-first: pick one (a per-phase "hours logged" counter, a search box that filters tasks, or a print stylesheet) and build it in a branch. Then have an AI review the diff before you merge.Your first contribution to a codebase you did not start, which is most of professional development.

The modern toolchain: Node, npm, Vite, React. Spine: Full Stack Open, which runs every exercise on your own machine and grades by GitHub repo. Do the exercises; the reading alone teaches nothing.

• Install Node via nvm (not apt): nvm install --lts, then verify node -v and npm -v.nvm lets you switch Node versions per project, which apt cannot. Also: reading an install script before piping it to bash is a habit worth forming today.
• FSO Part 0: Fundamentals of Web Apps. Do the sequence-diagram exercises honestly, using Firefox dev tools' Network tab on real sites.Request/response mechanics are the ground truth under every framework you will ever use.
• FSO Part 1: Introduction to React, all exercises, each committed to a course repo.Components, props, state, hooks. Vite scaffolds the projects; look at what it generates.
• FSO Part 2: Communicating with Server, all exercises, running json-server locally as the fake backend.Effects, fetching, forms, rendering collections. json-server previews Phase 3's real thing.
• Project: rebuild your Phase 1 Calculator as a React app, hand-first, no tutorial.Porting a project you already solved isolates the new variable: thinking in components instead of DOM manipulation.

Express, REST, a real database daemon running on the laptop, authentication, and automated tests. FSO Parts 3 and 4 are the spine; we swap in PostgreSQL (via FSO Part 13) because SQL is the default of the industry and of your future products.

• FSO Part 3: Programming a Server with Node/Express. Build the phonebook backend; connect your Part 2 frontend to it. (You may skip the MongoDB sections and hold out for Postgres in p3-3, or do both and compare.)Routes, middleware, REST semantics, request logging: the backend vocabulary.
• Install PostgreSQL on the laptop: sudo apt install postgresql, then learn your way around psql: create a database and a user, create a table, INSERT/SELECT/UPDATE/DELETE by hand.A database is just another Linux service you administer. Feeling that demystifies the whole category.
• FSO Part 13: Using Relational Databases. Rebuild the phonebook/notes backend on Postgres with Sequelize, migrations included.ORMs, migrations, and the moment you learn why schema changes are scarier than code changes.
• FSO Part 4: Testing Servers, User Administration. Supertest, password hashing with bcrypt, token (JWT) auth.Auth is the first thing every real app needs and the first thing beginners get dangerously wrong. Tests are how you touch auth code without fear.
• Project, hand-first: the Bootcamp API. An Express + Postgres service that stores this course's progress (tasks, notes, hours), with token auth and tests. Design the schema yourself. Then wire a small React admin page to it.Your first fully self-designed full-stack slice, and it foreshadows the capstone: this course app growing its own backend.

The layer most courses skip and most jobs assume: SSH, Vim survival, containers, and a CI pipeline. Spine: FSO Parts 12 and 11, plus the topic skeleton of Frontend Masters' backend path. After this phase the Latitude is not just a dev box, it is an ops box.

• SSH in both directions. Install openssh-server on the Latitude, connect to it from your Windows PC by key (no password auth), move files with scp and rsync. Then read what ~/.ssh/config can do and set up a host alias.Every server you will ever touch is reached this way. Practicing on your own hardware makes the cloud version feel routine.
• Vim survival: run vimtutor twice on different days, then do one real config edit over SSH in vim without notes.Vim is the editor that is always there. Survival level (move, edit, save, quit, search) is the requirement; mastery is optional.
• Install Docker Engine per the official Ubuntu instructions (the apt repo, not Docker Desktop), add yourself to the docker group, run hello-world, then run Postgres in a container and connect psql to it.On 8 GB of RAM, Engine alone is the right call; Docker Desktop's VM would eat a third of your memory.
• FSO Part 12: Containers. Containerize your Bootcamp API; write a docker-compose file that brings up API + Postgres together.Dockerfiles, images vs containers, volumes, networks, multi-stage builds. Compose is how real stacks are run in development.
• FSO Part 11: CI/CD with GitHub Actions. Build a pipeline for the Bootcamp API: lint, test, and build the container image on every push.The moment git push starts triggering robots that judge your code, you are working the way teams work.
• Deploy one project off the laptop to a free-tier host of your choice (evaluate the current options when you get here; free tiers move). Alternatively, deploy to a home server or a Warpyard box.DNS, environment variables, build commands, logs you do not own: deployment friction is a curriculum of its own. Your call on target and timing; nothing goes public without your own go decision.

The hand-first apprenticeship ends; the AI-assisted workflow begins, done deliberately instead of by vibes. You now have four phases of real code for an AI agent to work on, and the judgment to evaluate what it does. Spine: Anthropic Academy's developer track (free, certificates included).

• Anthropic Academy: Claude Code 101. Install Claude Code on the Latitude and complete the course.The terminal-native agent matches the terminal-native machine you have built.
• Anthropic Academy: Claude Code in Action, plus DeepLearning.AI's free short course Claude Code: A Highly Agentic Coding Assistant.Real workflows: exploring unfamiliar code, screenshot-driven UI iteration, running agents in parallel.
• Retrofit an old project with the agent: point Claude Code at your Phase 1 Calculator, have it review and propose refactors, and accept only what you can defend line by line. Write a CLAUDE.md for the Bootcamp API repo.The skill being trained is not prompting, it is reviewing. You are the senior in this pair now.
• Anthropic Academy: Intro to Subagents, Intro to Agent Skills, and Intro to MCP. Then install one MCP server (e.g. Playwright) and use it in a session on a real task.Subagents, skills, and MCP are how a single assistant becomes a configurable toolchain, which is Phase 6's foundation.

Building the AI-powered apps themselves: LLM API calls, embeddings, retrieval (RAG), tool-using agents, and your own MCP server. Lab material: Ed Donner's public repos and Hugging Face's free Agents course.

• First API call from code: from Node and from Python, call an LLM API (see the Anthropic docs or OpenRouter), with the key in an environment variable, never in code.The entire field, reduced to its atom: a POST request with messages in, messages out.
• Build a CLI chatbot with tool calling, hand-first, using Ed Donner's agents repo as reference after your own attempt: give the model 2 or 3 tools (read a file, fetch a URL, query your Bootcamp API) and a loop.Tool calling is the hinge between chatbots and agents. Writing the loop yourself removes all the magic.
• Embeddings and RAG over your own notes: chunk your workbench repo's notes, embed them into Chroma running locally, and build ask-my-notes retrieval + answer. Reference: the RAG week of llm_engineering.RAG on your own real notes gives you an immediate feel for chunking, retrieval quality, and hallucination that toy datasets never do.
• Hugging Face AI Agents Course, units 1 and 2, and submit the benchmarked final assignment for the certificate if it grabs you.A second perspective on agents (smolagents/LangGraph) and an external graded checkpoint.
• Write your own MCP server that exposes your Bootcamp API (progress, notes) as tools, and use it from Claude Code: "how many hours have I logged in Phase 6?"Full circle: the machine's own learning record becomes an AI-queryable service, built by you, on standards you learned in Phase 5.

One app that uses everything: designed by you, built with Claude Code as your pair (you now know how to be the senior in that pair), React frontend, Express + Postgres backend, at least one real AI feature, containerized, CI-tested, and deployed. Idea candidates from your own world: a client-brief intake assistant for chuck design, a family study coach for the hub, or this course app reborn with its own backend and RAG over your entire logbook. Your pick; write the spec first.

• Write a one-page spec: the problem, the user, the stack, the AI feature, and what "done" means.Professional habit number one. The spec is also your defense against scope creep, the capstone killer.
• Build it, Claude Code as pair, you as reviewer of record, committing in coherent slices.The build itself is the exam.
• Harden it: tests on the API and the AI feature's failure modes (timeouts, refusals, garbage retrieval), CI green, compose file, README that lets a stranger run it.The difference between a demo and software.
• Deploy it and demo it to someone.Deployment target and publicity are your call, per your own rules. A demo to one real human closes the loop a checkbox cannot.