Module prereqs: sort Prerequisites lists numerically ascending (#102)

modules/07-worktrees-running-agents-in-parallel/README.md

@@ -8,15 +8,15 @@
 
 ## Prerequisites
 
-- **Module 6: Branches.** You can create a branch, switch to it, merge it back, and resolve a
+- **Module 1: the `tasks-app`.** The running example continues here.
-  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 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.

modules/09-issues-and-the-task-layer/README.md

@@ -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.

modules/14-continuous-integration/README.md

@@ -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

modules/15-security-scanning/README.md

@@ -9,14 +9,14 @@
 
 ## Prerequisites
 
-- **Module 14: Continuous Integration.** You have a pipeline that runs lint, build, and tests on
+- **Module 1: the `tasks-app`.** The running example. We'll let the AI bolt a "cloud sync" feature
-  every push. Security scanning is *more gates on that same pipeline*, so you need somewhere to bolt
+  onto it and watch it introduce all three failure modes at once.
-  them on.
 - **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
+- **Module 14: Continuous Integration.** You have a pipeline that runs lint, build, and tests on
-  onto it and watch it introduce all three failure modes at once.
+  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

modules/22-securing-third-party-mcp-and-skills/README.md

@@ -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*.
+- Helpful but not required: **Module 5** (committed config; your MCP/skill setup is itself a
-  This module secures the AI *as an actor*. Same instinct (automated gates against AI-shaped
+  reviewable, versioned artifact), **Module 16** (containers, for sandboxing untrusted servers), and
-  failure), different target. The hallucinated-package supply-chain risk from Module 15 has a direct
+  **Module 17** (secrets, for scoping the tokens you hand a server).
-  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).
 
 ---
 

modules/24-assistive-agents/README.md

@@ -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."

modules/25-autonomous-agents/README.md

@@ -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
+- **Module 5**: your committed AI instructions file: the agent's standing brief, the half of the
-  the escalation: the agent now takes a step on its own. The only reason that's responsible is the
+  spec that isn't in the issue.
-  rest of this list.
+- **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.

modules/26-orchestrating-multiple-agents/README.md

@@ -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,
+- **Module 8, Remotes.** The PRs in this lab live on a forge. (A local-only fallback is given.)
-  supervised. This module runs *several* of those at once. If you can't trust one unattended agent,
+- **Module 9, Issues.** The unit of work you split across agents. A clean fan-out is a set of clean
-  you have no business running five.
+  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.)
+- **Module 25, Autonomous agents.** You can hand an agent an issue and get a reviewable PR back,
-- **Modules 2, 5, 6.** Durable memory per worktree, the committed AI config every agent inherits,
+  supervised. This module runs *several* of those at once. If you can't trust one unattended agent,
-  and conflict resolution for the inevitable merge.
+  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.

modules/27-evals/README.md

@@ -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.