docs: sort Prerequisites lists numerically ascending (#100)

Reorder the `## Prerequisites` bullets in 9 modules so prior modules are listed lowest number first instead of by pedagogical importance or at random. A trailing "Helpful but not required" group stays last and is sorted within itself; multi-module bullets sort by their lowest number. Intro/closing paragraphs are left in place. Prose is unchanged; only bullet order moves. Modules touched: 7, 9, 14, 15, 22, 24, 25, 26, 27. The other 18 modules were already ascending (or have one/zero prereqs) and are untouched. Module 19's "Helpful but not required: Module 16" correctly trails its ascending 8/14/18 main list, so it stays as is. Closes #100 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CamgR4HaVpfaqUViuHUcWw
2026-06-23 09:53:05 -04:00
parent edf3f34336
commit 65c6c6b2b6
9 changed files with 49 additions and 49 deletions
@@ -8,15 +8,15 @@

 ## Prerequisites

- **Module 6: Branches.** You can create a branch, switch to it, merge it back, and resolve a
-  conflict. A worktree is the physical counterpart to the logical isolation a branch already gives
-  you, so this module makes no sense without it.
- **Module 4: Getting the AI out of the browser.** The agents in this module edit real files in a
-  folder. You'll point an editor-integrated AI session at each worktree directory.
+- **Module 1: the `tasks-app`.** The running example continues here.
 - **Module 2: Version control.** The `tasks-app` is already a Git repo with commits, and you read
  a project's state from `git status` / `git diff` / `git log`. Each worktree has its own answer to
  those, which is the whole point.
- **Module 1: the `tasks-app`.** The running example continues here.
+- **Module 4: Getting the AI out of the browser.** The agents in this module edit real files in a
+  folder. You'll point an editor-integrated AI session at each worktree directory.
+- **Module 6: Branches.** You can create a branch, switch to it, merge it back, and resolve a
+  conflict. A worktree is the physical counterpart to the logical isolation a branch already gives
+  you, so this module makes no sense without it.

 If you parachuted in: you minimally need a Git repo with at least one commit and a working
 understanding of branches.
@@ -8,14 +8,14 @@

 ## Prerequisites

+- **Module 1**: the `tasks-app` project. The lab writes issues against it.
+- **Module 2**: the repo-as-durable-memory reframe. Issues are the team-scale version of the same
+  idea: shared memory for the work that *hasn't happened yet*.
+- **Module 5**: you committed your AI instructions file. That file plus a good issue is what gives
+  an agent enough context to attempt a task; this module puts that pairing to work.
 - **Module 8**: you have a repo on a remote forge (GitHub or any alternative). Issues live on the
  forge, alongside the code, so this module needs the remote you set up there. Everything here is
  provider-neutral: issues exist on every forge.
- **Module 5**: you committed your AI instructions file. That file plus a good issue is what gives
-  an agent enough context to attempt a task; this module puts that pairing to work.
- **Module 2**: the repo-as-durable-memory reframe. Issues are the team-scale version of the same
-  idea: shared memory for the work that *hasn't happened yet*.
- **Module 1**: the `tasks-app` project. The lab writes issues against it.

 You do **not** yet need pull requests (Module 10) or the full collaboration loop (Module 11). This
 module produces the *input* to that loop. We'll point forward to it, not teach it here.
@@ -8,13 +8,13 @@

 ## Prerequisites

+- **Module 2: Version Control.** Pushes, commits, and the diff habit are the substrate CI sits on.
 - **Module 8: Remotes and Hosting.** CI runs *on the forge*, triggered by pushes. You need a repo
  pushed to a remote (any forge: GitHub, GitLab, a self-hosted Forgejo/Gitea, whatever you set up
  in Module 8) for there to be anything to trigger.
 - **Module 13: Testing in the AI Era.** CI is mostly "run the tests, automatically." You need tests
  to run. If you skipped writing them, this module's lab ships a small suite so you're not blocked,
  but the real payoff is automating *your* tests.
- **Module 2: Version Control.** Pushes, commits, and the diff habit are the substrate CI sits on.

 You do **not** need Docker, secrets management, or your own runner yet; those are Modules 16, 17,
 and 19. On a **SaaS forge** (GitHub, GitLab.com, Bitbucket, and the rest) this module uses the
@@ -9,14 +9,14 @@

 ## Prerequisites

- **Module 14: Continuous Integration.** You have a pipeline that runs lint, build, and tests on
-  every push. Security scanning is *more gates on that same pipeline*, so you need somewhere to bolt
-  them on.
+- **Module 1: the `tasks-app`.** The running example. We'll let the AI bolt a "cloud sync" feature
+  onto it and watch it introduce all three failure modes at once.
 - **Module 2: Version Control as a Safety Net.** Scanners flag findings in a diff; you'll commit,
  re-scan, and confirm a gate goes red then green. Secret scanning in particular cares about *history*,
  not just the working tree; that only makes sense once you think in commits.
- **Module 1: the `tasks-app`.** The running example. We'll let the AI bolt a "cloud sync" feature
-  onto it and watch it introduce all three failure modes at once.
+- **Module 14: Continuous Integration.** You have a pipeline that runs lint, build, and tests on
+  every push. Security scanning is *more gates on that same pipeline*, so you need somewhere to bolt
+  them on.

 Helpful but not required: **Module 8 (remotes/hosting)** gives you host-native scanning (Dependabot-style
 alerts, push protection) that lives on the remote; **Module 10 (reviewing code you didn't write)** frames
@@ -8,20 +8,20 @@

 ## Prerequisites

+- **Module 2, Version Control as a Safety Net.** `git restore` and a clean commit are part of the
+  blast-radius story when something an agent did needs undoing.
+- **Module 15, Security Scanning for AI-Generated Code.** Module 15 scans the code the AI *writes*.
+  This module secures the AI *as an actor*. Same instinct (automated gates against AI-shaped
+  failure), different target. The hallucinated-package supply-chain risk from Module 15 has a direct
+  cousin here.
 - **Module 20, MCP Servers.** You've connected the AI to real tools and data over MCP. That
  connection is exactly the attack surface this module defends.
 - **Module 21, Skills.** You've installed and authored skills (and seen that a skill is just
  instructions plus, often, scripts the AI runs). A third-party skill is someone else's code and
  someone else's instructions.
- **Module 15, Security Scanning for AI-Generated Code.** Module 15 scans the code the AI *writes*.
-  This module secures the AI *as an actor*. Same instinct (automated gates against AI-shaped
-  failure), different target. The hallucinated-package supply-chain risk from Module 15 has a direct
-  cousin here.
- **Module 2, Version Control as a Safety Net.** `git restore` and a clean commit are part of the
-  blast-radius story when something an agent did needs undoing.
- Helpful but not required: **Module 16** (containers, for sandboxing untrusted servers),
-  **Module 17** (secrets, for scoping the tokens you hand a server), and **Module 5** (committed
-  config; your MCP/skill setup is itself a reviewable, versioned artifact).
+- Helpful but not required: **Module 5** (committed config; your MCP/skill setup is itself a
+  reviewable, versioned artifact), **Module 16** (containers, for sandboxing untrusted servers), and
+  **Module 17** (secrets, for scoping the tokens you hand a server).

 ---

@@ -25,14 +25,14 @@ trusting an agent in the loop, before Module 25 lets one actually open a PR.

 ## Prerequisites

+- **Module 5: Commit the AI's config.** The review rubric and the label taxonomy in this lab are
+  committed, versioned config: change how the agent behaves and it arrives as a reviewable diff.
 - **Module 9: Issues and the task layer.** You have issues describing work, and the idea that an
  assignee can be a human *or* an agent. The triage half of this module is the agent that sorts the
  incoming pile and decides which is which.
 - **Module 10: Reviewing code you didn't write.** You learned to read an AI's diff for plausibility
  traps, not just correctness. The review half hands the *first pass* of exactly that skill to an
  agent, so your attention lands where it matters.
- **Module 5: Commit the AI's config.** The review rubric and the label taxonomy in this lab are
-  committed, versioned config: change how the agent behaves and it arrives as a reviewable diff.
 - **Module 22: Securing third-party MCP servers and skills.** The least-privilege and
  prompt-injection thinking from there is what keeps an assistive agent inside its lane. We lean on
  it directly in "Where it breaks."
@@ -11,25 +11,25 @@
 This is the module the whole back half of the course was load-bearing for. It assumes a lot, on
 purpose; each piece is a wall the autonomous agent has to land behind.

- **Module 24**: assistive agents, where the AI helped and *you* decided every step. This module is
-  the escalation: the agent now takes a step on its own. The only reason that's responsible is the
-  rest of this list.
+- **Module 5**: your committed AI instructions file: the agent's standing brief, the half of the
+  spec that isn't in the issue.
+- **Module 6**: branches. The agent's work goes on a branch, never straight onto `main`.
 - **Module 9**: issues as an agent's task specification, including the `ready` label and the idea of
  an agent as an *assignee*. An issue is the agent's input here.
- **Module 6**: branches. The agent's work goes on a branch, never straight onto `main`.
 - **Modules 10 and 11**: the PR review gate and the full issue → branch → implementation → PR →
  review → merge → close loop. The PR *is* the unit of supervision in this module.
+- **Module 12**: revert, reset, recovery. The backstop for when a gate misses something.
 - **Modules 13 and 14**: tests and CI. The automated gate that runs on the agent's PR.
 - **Module 15**: security scanning as another gate on the same pushes. Autonomy makes this
  non-optional, not optional.
- **Module 19**: runners. A triggered or scheduled agent is just a runner job; you need to know
-  what's executing it and whose compute it's burning.
- **Module 12**: revert, reset, recovery. The backstop for when a gate misses something.
- **Module 5**: your committed AI instructions file: the agent's standing brief, the half of the
-  spec that isn't in the issue.
 - **Modules 16, 17, 22**: containers (sandboxing), secrets (scoped credentials), and the prompt-
  injection attack surface. An unattended agent with a push token is a security boundary; these are
  why.
+- **Module 19**: runners. A triggered or scheduled agent is just a runner job; you need to know
+  what's executing it and whose compute it's burning.
+- **Module 24**: assistive agents, where the AI helped and *you* decided every step. This module is
+  the escalation: the agent now takes a step on its own. The only reason that's responsible is the
+  rest of this list.

 If you skipped straight here, the lesson will read as reckless, because without those gates, it
 *would* be.
@@ -9,27 +9,27 @@

 ## Prerequisites

+- **Modules 2, 5, 6.** Durable memory per worktree, the committed AI config every agent inherits,
+  and conflict resolution for the inevitable merge.
 - **Module 7, Worktrees.** The primitive everything here rests on. One repo, many working directories, each on
  its own branch, each safe for an agent to edit without touching the others. Module 7 proved this on
  *two* agents and told you the scale-up lived here. This is here. If `git worktree add` /
  `list` / `remove` aren't muscle memory yet, go back; everything below is that, multiplied.
- **Module 25, Autonomous agents.** You can hand an agent an issue and get a reviewable PR back,
-  supervised. This module runs *several* of those at once. If you can't trust one unattended agent,
-  you have no business running five.
+- **Module 8, Remotes.** The PRs in this lab live on a forge. (A local-only fallback is given.)
+- **Module 9, Issues.** The unit of work you split across agents. A clean fan-out is a set of clean
+  issues.
+- **Module 10, Reviewing code you didn't write.** The skill that becomes the bottleneck. N agents
+  produce N diffs; one human reviews them one at a time.
 - **Module 11, Collaboration: humans and agents on one repo.** The issue → branch →
  implementation → PR → review → merge → close loop. Orchestration is that loop run N times in
  parallel and fanned back into one `main`. Parallel agents are just contributors who happen to
  share a clock.
- **Module 10, Reviewing code you didn't write.** The skill that becomes the bottleneck. N agents
-  produce N diffs; one human reviews them one at a time.
- **Module 9, Issues.** The unit of work you split across agents. A clean fan-out is a set of clean
-  issues.
 - **Module 14, Continuous integration.** The automated gate every parallel branch passes through
  before it's yours to review. With many agents, CI stops being a nicety and becomes the only thing
  keeping the merge queue honest.
- **Module 8, Remotes.** The PRs in this lab live on a forge. (A local-only fallback is given.)
- **Modules 2, 5, 6.** Durable memory per worktree, the committed AI config every agent inherits,
-  and conflict resolution for the inevitable merge.
+- **Module 25, Autonomous agents.** You can hand an agent an issue and get a reviewable PR back,
+  supervised. This module runs *several* of those at once. If you can't trust one unattended agent,
+  you have no business running five.

 If you parachuted in: you minimally need worktrees, the PR loop, and one agent you'd let run on its
 own. This module is about coordinating many of those, not about any one of them.
@@ -13,12 +13,12 @@ This is the closer. It assumes the whole course, but it leans hardest on:
 - **Module 1**: the thesis (the model is the cheap, swappable part; the workflow is the durable
  skill) and the `tasks-app` we've carried the whole way. This module is where the thesis gets its
  proof.
+- **Module 10, Reviewing Code You Didn't Write**: the human review skill evals partially automate
+  and partially *replace* once a human isn't in the loop.
 - **Module 13, Testing in the AI Era**: you can write a deterministic pass/fail check. Evals are
  the next thing up the ladder: scoring output that a single test can't fully pin down.
 - **Module 14, Continuous Integration**: running checks automatically on every change, with an
  exit code that gates. Evals run the same way and gate the same way.
- **Module 10, Reviewing Code You Didn't Write**: the human review skill evals partially automate
-  and partially *replace* once a human isn't in the loop.
 - **Modules 24–26, the Unit 5 agent ladder**: assistive agents (24), autonomous-but-supervised
  agents (25), and orchestrated fleets (26). Evals are what decide how far up that ladder any given
  agent is allowed to climb.