De-slop: remove every em-dash + banned words across all modules + capstone (#94)

Co-authored-by: claude <claude@jpaul.io>
Co-committed-by: claude <claude@jpaul.io>

modules/25-autonomous-agents/README.md

@@ -1,6 +1,6 @@
-# Module 25 — Autonomous Agents: Issue-to-PR and Self-Healing CI
+# Module 25. Autonomous Agents: Issue-to-PR and Self-Healing CI
 
-> **Now the AI acts on its own — takes an assigned issue, opens a pull request, even fixes its own
+> **Now the AI acts on its own: it takes an assigned issue, opens a pull request, even fixes its own
 > failing build.** The thing that makes that safe isn't watching it work. It's that everything it
 > produces still lands as a reviewable PR behind the same gates you already built.
 
@@ -43,7 +43,7 @@ By the end of this module you can:
 1. Explain the difference between *assistive* (Module 24) and *autonomous-but-supervised* agents, and
    state where supervision actually happens in each.
 2. Run an issue-to-PR agent: hand it a well-formed issue and have it produce a change on a branch
-   that arrives as a reviewable pull request — not a merge.
+   that arrives as a reviewable pull request, not a merge.
 3. Watch your existing CI / review / security gates catch a bad agent change before it can reach
    `main`, and explain why that's *structural* supervision rather than *behavioral*.
 4. Build a bounded self-healing loop: when a gate fails, feed the failure back to the agent for a
@@ -62,12 +62,12 @@ read the suggestion and took the action. Supervision was **behavioral**: you wer
 every decision, watching, approving, clicking the button.
 
 That doesn't scale, and watching an agent type is a terrible use of your attention anyway. This
-module makes the agent *take the action* — branch, edit files, commit, open a PR. The obvious worry
+module makes the agent *take the action*: branch, edit files, commit, open a PR. The obvious worry
 is: if I'm not watching, what stops it from shipping garbage?
 
 The answer is the reframe of the whole unit:
 
-> **You don't supervise an autonomous agent by watching it work. You supervise it structurally — by
+> **You don't supervise an autonomous agent by watching it work. You supervise it structurally, by
 > making everything it produces pass through gates that don't care whether a human or a machine wrote
 > the change.**
 
@@ -75,7 +75,7 @@ You already built those gates, for exactly this reason, before you needed them:
 
 | Gate | Built in | What it catches on an agent's PR |
 |------|----------|----------------------------------|
-| **Review** | Module 10 | Plausible-but-wrong logic, scope creep, dropped edge cases — read the diff, not the agent's summary. |
+| **Review** | Module 10 | Plausible-but-wrong logic, scope creep, dropped edge cases. Read the diff, not the agent's summary. |
 | **CI** | Module 14 | Lint failures, broken tests, anything that doesn't build. Runs identically on a human's PR and an agent's. |
 | **Security** | Module 15 | Hardcoded secrets, vulnerable or hallucinated dependencies, SAST findings. |
 | **Recovery** | Module 12 | The backstop: if something slips through and merges, `revert` cleanly undoes it. |
@@ -84,7 +84,7 @@ The agent is autonomous *inside* that box and powerless to escape it. It cannot
 check or an unapproved review. That's the entire safety model, and it's why this module sits at the
 end of the course instead of the start: the box had to exist first.
 
-### Pattern 1 — Issue-to-PR
+### Pattern 1: Issue-to-PR
 
 The headline pattern, and the one Module 9 set up when it called an agent a possible *assignee*. The
 loop is exactly the human collaboration loop from Module 11, with one participant swapped:
@@ -111,10 +111,10 @@ full volume: a confident, plausible, wrong PR that costs more to review than the
 taken.
 
 Crucially: the agent's last step is **open a PR**, not **merge**. The output is a proposal. Nothing
-about "autonomous" means "merges to `main` unseen" — if that's your mental model, this is where you
+about "autonomous" means "merges to `main` unseen"; if that's your mental model, this is where you
 fix it.
 
-### Pattern 2 — Self-healing CI
+### Pattern 2: Self-healing CI
 
 The second pattern points the agent at a *failure* instead of an issue. CI goes red on a branch; an
 agent reads the failing job's logs, proposes a fix, and pushes it back to the same branch so CI runs
@@ -139,9 +139,9 @@ Two design rules make this safe rather than a runaway loop:
    **reviewable PR**: a human confirms it fixed the code, not the evidence. Self-healing CI proposes
    a fix; it doesn't certify one.
 
-### Pattern 3 — Triggered and scheduled agent jobs
+### Pattern 3: Triggered and scheduled agent jobs
 
-How does an agent *start* without you launching it? It runs as a runner job (Module 19) — the same
+How does an agent *start* without you launching it? It runs as a runner job (Module 19), the same
 machinery that runs your CI, pointed at an agent instead of a test suite. Two triggers cover almost
 everything:
 
@@ -152,7 +152,7 @@ everything:
   being a slogan.
 
 Either way it's a job on a runner, which means everything Module 19 taught applies: hosted vs.
-self-hosted, whose compute, and — new and important here — **what credentials that job holds.** A
+self-hosted, whose compute, and, new and important here, **what credentials that job holds.** A
 scheduled agent with a push token and write access is unattended automation acting in your name. It
 needs scoped secrets (Module 17), ideally a sandboxed environment (Module 16), and a healthy
 suspicion of anything it reads, because an issue body or a dependency's README is untrusted input
@@ -163,7 +163,7 @@ surface; treat it like one.
 
 Here's the load-bearing idea of the module, and it's not about the model:
 
-> **An autonomous agent is exactly as safe as the gates it lands behind — no safer.** How much
+> **An autonomous agent is exactly as safe as the gates it lands behind; no safer.** How much
 > autonomy you can responsibly grant is a property of *your CI, review, and security setup*, not of
 > how smart the model is.
 
@@ -203,8 +203,8 @@ the job is non-deterministic and persuasive**, and that changes what "automation
 ## Hands-on lab
 
 **Lab language:** Python (one orchestrator script) plus a little shell and Git. It runs on your own
-machine, any OS, against the `tasks-app` repo from Module 1 — no forge account or paid agent required
-to complete it.
+machine, any OS, against the `tasks-app` repo from Module 1, with no forge account or paid agent
+required to complete it.
 
 You'll drive an issue-to-PR run and a self-healing loop *locally*, so the moving parts are visible
 and reproducible. The "PR" in the local lab is a branch plus a diff you review; the optional Part D
@@ -214,7 +214,7 @@ shows how the exact same flow runs on a real forge as a triggered/scheduled job.
 
 - Your `tasks-app` Git repo (Modules 1–2), with the `test_tasks.py` from Module 14 present and
   `pytest` and `ruff` installed (`pip install pytest ruff`). The lab runs these as the CI gate,
-  locally — the same checks `ci.yml` runs in Module 14.
+  locally, the same checks `ci.yml` runs in Module 14.
 - The starter files in this module's `lab/` folder:
   - `agent_runner.py`: the orchestrator. Drives the agent (real or simulated), then runs the gate,
     and only ever produces a branch + PR proposal, never a merge.
@@ -225,18 +225,18 @@ shows how the exact same flow runs on a real forge as a triggered/scheduled job.
 - *Optional, for the "for real" path:* an agentic coding tool that has a non-interactive / headless /
   one-shot mode (most expose a flag for running a single prompt without the interactive UI). If you
   don't have one wired up, the script's `--simulate` mode demonstrates every gate and loop
-  deterministically with no agent at all — do that first regardless.
+  deterministically with no agent at all; do that first regardless.
 
-> **What `--simulate` actually does — read this before Part A.** To stay deterministic and never
+> **What `--simulate` actually does (read this before Part A).** To stay deterministic and never
 > touch your real `cli.py` / `tasks.py`, `--simulate` does **not** implement
 > `issue-delete-command.md`. Instead it writes a small, self-contained stand-in (`agent_demo.py` with
 > a `discount()` function, plus its test) and runs the *real* gate (ruff + pytest) against that. So
-> Parts A–C exercise the machinery and the gates — not the delete feature itself. The issue is only
-> truly implemented in **Part D**, with a live agent. When you review the simulated diff you'll see
+> Parts A–C exercise the machinery and the gates, not the delete feature itself. The issue is only
+> actually implemented in **Part D**, with a live agent. When you review the simulated diff you'll see
 > the `discount()` demo, not a `delete` command; that's expected, and it's why the simulation is
 > reproducible enough to teach with.
 
-### Part A — See the gate catch a bad change (simulated, no agent needed)
+### Part A: See the gate catch a bad change (simulated, no agent needed)
 
 Copy `agent_runner.py` and `issue-delete-command.md` into your `tasks-app` folder, along with this
 module's `lab/.gitignore` (append its lines to the `.gitignore` you already have from Module 2 rather
@@ -258,7 +258,7 @@ a change, the script runs the gate (`ruff check` then `pytest -q`), a test fails
 supervision. It didn't matter that the change looked plausible; the gate caught it, and nothing
 reached `main`.
 
-### Part B — See a good change land as a PR proposal
+### Part B: See a good change land as a PR proposal
 
 ```bash
 python agent_runner.py issue-to-pr issue-delete-command.md --simulate good
@@ -272,7 +272,7 @@ self-contained `discount()` stand-in, not a `delete` command. The review *motion
 you are the human gate, and that step doesn't go away just because an agent did the typing. The agent
 stops at a PR; it never merges.
 
-### Part C — Run the self-healing loop
+### Part C: Run the self-healing loop
 
 ```bash
 python agent_runner.py self-heal --simulate bad
@@ -284,7 +284,7 @@ fix, re-runs the gate, and repeats up to its retry cap. With `--simulate bad` th
 second attempt and the result is offered as a PR proposal. Run it with `--simulate stuck` to watch the
 cap trip: after N attempts it gives up and tags the work for a human instead of looping forever.
 
-### Part D — Do it for real (optional)
+### Part D: Do it for real (optional)
 
 Two ways to go from simulation to a genuine autonomous run:
 
@@ -302,7 +302,7 @@ Two ways to go from simulation to a genuine autonomous run:
 
 2. **On a forge, triggered/scheduled.** Read `agent-job.yml`. It's a runner workflow (Module 19) that
    fires when an issue gets an `agent` label *and* on a nightly schedule, runs the agent on the
-   runner, and opens a PR — which then hits your normal CI (Module 14) and security (Module 15) gates
+   runner, and opens a PR, which then hits your normal CI (Module 14) and security (Module 15) gates
    and waits for review. Wiring it up needs a scoped token in your forge's secrets (Module 17); the
    file is commented with exactly what to set and what *not* to grant. This is the "workflow runs
    itself" endpoint, and it's intentionally the last thing you turn on.
@@ -311,7 +311,7 @@ Two ways to go from simulation to a genuine autonomous run:
 
 ## Where it breaks
 
-The honest limits — and for autonomous agents, the limits *are* the lesson:
+The honest limits, and for autonomous agents the limits *are* the lesson:
 
 - **Your gates are the ceiling, and most gates are weaker than they look.** Thin test coverage,
   skipped security scans, or review-by-rubber-stamp don't just reduce quality, they directly set how
@@ -319,12 +319,12 @@ The honest limits — and for autonomous agents, the limits *are* the lesson:
   The honest version of "should I let an agent do this unattended?" is "would my CI catch it if it got
   it wrong?"
 - **Self-healing can fix the evidence instead of the bug.** Editing the test until it passes, widening
-  an exception so the error is swallowed, deleting an assertion — all turn CI green and all are wrong.
+  an exception so the error is swallowed, deleting an assertion: all turn CI green and all are wrong.
   The bounded-retry cap stops the *loop*; only human review of the diff stops the *cheat*. Never let a
   self-heal PR auto-merge on green alone.
 - **"Autonomous" is not "auto-merge."** Everything in this module stops at a PR. The moment you wire
   an agent to merge its own work to `main` without a gate that a human controls, you've left supervised
-  autonomy and you own whatever it ships. That's a deliberate decision, not a default — and it's out
+  autonomy and you own whatever it ships. That's a deliberate decision, not a default, and it's out
   of scope for this course.
 - **Unattended agents are an attack surface, not just a convenience.** A scheduled agent holds
   credentials and reads untrusted input (issue bodies, comments, dependency files) straight into its
@@ -336,7 +336,7 @@ The honest limits — and for autonomous agents, the limits *are* the lesson:
   concurrency, and put a human checkpoint on anything that hasn't converged.
 - **Flaky gates make autonomy actively worse.** A nondeterministic test that fails 1-in-5 will send a
   self-healing agent chasing a bug that isn't there. Autonomy demands *more* gate discipline than
-  manual work, not less — fix the flake before you point an agent at it.
+  manual work, not less. Fix the flake before you point an agent at it.
 
 ---
 
@@ -345,13 +345,13 @@ The honest limits — and for autonomous agents, the limits *are* the lesson:
 **You're done when:**
 
 - You ran an issue-to-PR flow (simulated or real) and the result was a **branch + PR proposal**, not a
-  merge — and you can point to exactly where a human or a gate still has to say yes.
+  merge, and you can point to exactly where a human or a gate still has to say yes.
 - You watched the gate **reject a bad agent change** (`--simulate bad`) and accept a good one, and you
   can explain why that's structural supervision rather than watching the agent work.
 - You ran a self-healing loop, saw it propose a fix on failure, and saw the retry **cap trip**
   (`--simulate stuck`) instead of looping forever.
 - You can finish this sentence without hand-waving: *"I'd let an agent do X unattended because my
-  gates would catch it if it got X wrong — specifically the gate from Module ___."*
+  gates would catch it if it got X wrong, specifically the gate from Module ___."*
 - You can name the three patterns (issue-to-PR, self-healing CI, triggered/scheduled jobs) and the
   four gates that make any of them safe (review M10, CI M14, security M15, recovery M12).