feat(course): build out all 27 modules, capstone, scaffold, and conventions

Scaffold the course repo and author the full curriculum in dependency-chain
order, following the settled build decisions in handoff.md.

- Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5),
  _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config.
- Modules 1-2: reference exemplars (locked for tone/depth/lab style).
- Modules 3-27: full lessons + runnable labs, each following the template,
  respecting the chain, vendor/model-agnostic, with "feel the pain" labs.
- Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22),
  not written from memory; expansion-zone modules carry Verify-before-publish.
- Capstone: the full loop end to end on the running tasks-app example.

Lab code syntax-checked (Python/shell/YAML); every module has the 7 core
template sections.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT

modules/15-security-scanning/lab/ci-security.yml

@@ -0,0 +1,42 @@
+# ci-security.yml — the security gate as a CI step (Module 15).
+#
+# This is a PROVIDER-NEUTRAL snippet, not a drop-in file. The YAML below uses the widely-shared
+# "workflow / job / steps" shape that most hosted and self-hosted CI systems understand (the exact
+# top-level keys and runner labels follow whatever host you set up in Module 14). Copy the *steps*
+# into the pipeline you already have rather than adding a second, competing workflow.
+#
+# The contract is the same on every platform:
+#   1. check out the code
+#   2. install the scanners
+#   3. run the gate (security-scan.sh), which exits non-zero on any finding -> the job goes red
+#
+# Because the real logic lives in security-scan.sh, this file stays tiny and your local run and your
+# CI run can never drift apart.
+
+name: security
+
+on: [push, pull_request]   # run on the same events as your Module 14 build/test job
+
+jobs:
+  security-scan:
+    runs-on: ubuntu-latest   # or your self-hosted runner label (Module 19)
+    steps:
+      - name: Check out the code
+        uses: actions/checkout@v4
+        # Secret scanning cares about history. If your tool scans commits (not just the working
+        # tree), fetch full history here — e.g. set `with: { fetch-depth: 0 }`.
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.x"
+
+      - name: Install scanners
+        run: pip install pip-audit detect-secrets
+
+      - name: Run the security gate
+        run: |
+          chmod +x security-scan.sh
+          ./security-scan.sh
+        # Non-zero exit fails the job. Require this job to pass before merge (branch protection on
+        # your remote, Module 8/10) and the gate actually has teeth.

modules/15-security-scanning/lab/config.py

@@ -0,0 +1,28 @@
+"""Cloud-sync config for tasks-app — a realistic snapshot of what an AI hands you.
+
+Asked to "sync tasks to a cloud service," a model will cheerfully produce something like this: it
+works, it reads naturally, it passes lint and tests... and it has a live credential baked straight
+into the source. That is the *exact* failure mode Module 15's secret-scanning gate exists to catch.
+
+DO NOT copy this pattern. The point of this file is to be caught by a scanner, not imitated.
+The fix (read from the environment) is shown at the bottom, commented out, so you can see the
+difference once Part C of the lab is done.
+"""
+
+# --- The problem the scanner should flag -------------------------------------------------------
+# A hardcoded API key. Looks like a normal string literal; lint and tests will never complain.
+SYNC_API_KEY = "sk_live_9c3f2a7b41d84e0fa6b2c5d8e1f09a73bdac46"
+SYNC_ENDPOINT = "https://api.example-task-cloud.com/v1/sync"
+
+
+def sync_headers() -> dict:
+    return {"Authorization": f"Bearer {SYNC_API_KEY}"}
+
+
+# --- The fix (Part C) --------------------------------------------------------------------------
+# Read the secret from the environment instead of committing it. Proper secret management — env
+# files, secret stores, per-environment config — is Module 17. This is just enough to make the
+# scanner go quiet honestly.
+#
+# import os
+# SYNC_API_KEY = os.environ["SYNC_API_KEY"]   # set it outside the repo; never commit the value

modules/15-security-scanning/lab/requirements.txt

@@ -0,0 +1,24 @@
+# Dependencies an AI "suggested" for the tasks-app cloud-sync feature.
+#
+# This file is deliberately booby-trapped with the three things AI gets wrong about dependencies.
+# Read it before you run anything — every line looks plausible, which is the whole problem.
+#
+# Work through it in Part B of the lab:
+#   1) `pip-audit -r requirements.txt` will FAIL TO RESOLVE because of the bad names below.
+#   2) Comment out the unresolvable lines (do NOT "autocorrect" them to the nearest real name).
+#   3) Re-run; the real-but-old package will report an advisory. Bump it until the scan is clean.
+
+# (1) REAL package, pinned to a KNOWN-VULNERABLE old version.
+#     SCA should flag an advisory here and tell you the fixed version. (Verify-before-publish:
+#     confirm this version still trips your scanner; re-pin if the advisory DB has moved.)
+requests==2.19.1
+
+# (2) TYPOSQUAT of a real package ("requests"). One transposed letter. Does not exist on the
+#     public index today — the resolver will reject it. The danger isn't the 404; it's "fixing"
+#     it by guessing instead of verifying what was actually meant.
+reqeusts==2.31.0
+
+# (3) HALLUCINATION — a plausible-but-invented name the model produced from thin air. This is the
+#     slopsquatting target: register this name with malware and the next person to `pip install`
+#     gets owned. Confirm it does not resolve; never add it without verifying the real project.
+task-cloud-sync-client==1.4.2

modules/15-security-scanning/lab/security-scan.sh

@@ -0,0 +1,48 @@
+#!/usr/bin/env bash
+#
+# security-scan.sh — the security gate for tasks-app (Module 15).
+#
+# Runs two scanners and exits non-zero if EITHER finds something. That non-zero exit is what turns
+# a CI run red (Module 14). One script, two homes: run it by hand for fast local feedback, and call
+# it from the pipeline so the same definition of "a finding" enforces the merge.
+#
+# These two tools (pip-audit, detect-secrets) are concrete examples of their categories — SCA and
+# secret scanning. Swap in any equivalent; keep the contract the same: scan, print, fail on findings.
+#
+# Usage:   ./security-scan.sh
+# Install: pip install pip-audit detect-secrets
+
+set -u  # treat unset vars as errors; we manage exit codes explicitly below.
+
+status=0
+
+echo "=== Gate 1: SCA / dependency scan (pip-audit) ==="
+if [ -f requirements.txt ]; then
+  if ! pip-audit -r requirements.txt; then
+    echo ">> SCA gate FAILED: unresolvable or vulnerable dependency. See above." >&2
+    status=1
+  fi
+else
+  echo "(no requirements.txt found — skipping SCA)"
+fi
+
+echo
+echo "=== Gate 2: secret scan (detect-secrets) ==="
+# detect-secrets prints a JSON report of any secrets it finds. We treat a non-empty results set as a
+# failure. `python -c` keeps this portable (no jq dependency).
+report="$(detect-secrets scan)"
+if printf '%s' "$report" | python -c 'import sys, json; sys.exit(0 if json.load(sys.stdin).get("results") else 1)'; then
+  echo "$report"
+  echo ">> SECRET gate FAILED: a credential was detected in the tree. See report above." >&2
+  status=1
+else
+  echo "no secrets detected."
+fi
+
+echo
+if [ "$status" -ne 0 ]; then
+  echo "SECURITY GATE: FAILED" >&2
+else
+  echo "SECURITY GATE: passed"
+fi
+exit "$status"