modules/02-version-control-as-a-safety-net/README.md

@@ -61,7 +61,7 @@ minutes of work."
 The core commands:
 
 ```bash
-git init                 # turn the current folder into a repository (once per project)
+git init -b main         # turn the current folder into a repository, first branch named "main" (once per project)
 git status               # what's changed since the last commit?
 git add .                # stage the changes you want in the next commit
 git commit -m "message"  # save a checkpoint with a note
@@ -154,10 +154,17 @@ and your AI assistant.
 
    ```bash
    cd ~/workflow-course/tasks-app
-   git init
+   git init -b main           # start the repo with its first branch named "main" (Git 2.28+)
    git status                 # everything shows as "untracked" — Git sees the files but isn't saving them yet
    ```
 
+   > **Why `-b main`, and what if your Git is older.** Stock Git still names the first branch
+   > `master`, but every later module in this course says `main` (you'll `git switch main`, compare
+   > `git log main..HEAD`, merge into `main`). `git init -b main` settles that name once so those
+   > commands resolve. The `-b` flag needs Git 2.28+ (`git --version` to check); on an older Git, run
+   > plain `git init`, finish the first commit in step 2, then rename the branch once with
+   > `git branch -m master main`. Either route leaves you on `main`.
+
 2. Add a `.gitignore` so you don't version generated junk. Copy this module's
    `lab/gitignore-starter` to a file named exactly `.gitignore` in the project root, then:
 

modules/06-branches-sandboxes-for-experiments/README.md

@@ -47,8 +47,9 @@ Strip the mystique and a branch is **a named, movable pointer to a commit.** Tha
 definition. Your commit history is a chain of snapshots (Module 2); a branch is a sticky label that
 points at one of them and *moves forward* every time you commit on it.
 
-When you ran `git init` in Module 2, Git made one branch for you automatically — usually called
-`main`. Every commit you made moved the `main` label forward. You were "on a branch" the entire time
+When you ran `git init -b main` in Module 2, Git made one branch for you automatically — named
+`main` (the `-b main` is what guaranteed that name; in this course your repo is always on `main`).
+Every commit you made moved the `main` label forward. You were "on a branch" the entire time
 without thinking about it.
 
 The thing that surprises people coming from an ops background: **creating a branch copies nothing.**

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

@@ -220,7 +220,8 @@ collide. Then you'll merge both back and clean up.
 **You'll need:**
 
 - The `tasks-app` Git repo from Module 2 (initialized, with a few commits). If you skipped ahead,
-  `git init` it and make one commit first.
+  run `git init -b main` and make one commit first — the `-b main` matches Module 2, so the
+  `git switch main` steps below resolve.
 - Git 2.5 or newer (worktrees landed in 2.5; any modern Git is fine — `git --version` to check).
 - **Two** editor-integrated AI sessions you can run at once (Module 4) — two editor windows, or two
   terminal AI sessions. If you only have a browser chat, you can still do the lab; just treat each

modules/08-remotes-and-hosting/README.md

@@ -119,8 +119,9 @@ the "someone else" was the host's auto-generated README.)
 **3. Branch-name mismatch.** Your local default branch is `master` but the host expects `main` (or
 vice versa). `git push -u origin main` then errors with `src refspec main does not match any`. Fix:
 check what you actually have with `git branch`, and either push the branch you have
-(`git push -u origin master`) or rename it first (`git branch -m main`). Worth settling early so it
-doesn't confuse you for the rest of the course.
+(`git push -u origin master`) or rename it first (`git branch -m main`). If you initialized with
+`git init -b main` back in Module 2, you're already on `main` and this one won't bite you here — but
+it's the classic wall for any repo that started life on `master`, so it's worth recognizing.
 
 ### Pull, fetch, and the everyday loop
 

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

@@ -233,8 +233,11 @@ from whichever forge's web form you happen to be filling in.
 
 **You'll need:**
 
-- Your `tasks-app` repo on a forge (Module 8), with issues enabled (they are by default on every
-  forge named in Module 8).
+- Your `tasks-app` repo on a forge (Module 8), with its issue tracker enabled. Most forges turn
+  issues on by default, but not all of them do — consistent with the "the feature set varies" caveat
+  above. Bitbucket Cloud's tracker is off until you enable it, Azure DevOps uses Boards/Work Items
+  rather than an Issues tab, and SourceHut uses a separately provisioned `todo.sr.ht` tracker. If you
+  took the forge-agnostic path, confirm yours has issues available before Part C.
 - The starter files in this module's `lab/` folder:
   - `issue-template.md` — the well-formed-issue skeleton to copy for each issue.
   - `example-issues.md` — three worked issues for `tasks-app`, as a reference/answer key.

modules/10-reviewing-code-you-didnt-write/README.md

@@ -206,7 +206,7 @@ real change, then review a diff the "AI" produced and catch the trap planted in
    ```bash
    mkdir -p ~/workflow-course/review-lab && cd ~/workflow-course/review-lab
    cp /path/to/modules/10-reviewing-code-you-didnt-write/lab/tasks-app/*.py .
-   git init -q && git add . && git commit -qm "base: tasks-app"
+   git init -qb main && git add . && git commit -qm "base: tasks-app"   # -b main so the git switch main / git diff main.. steps below resolve
 
    python cli.py add "write the review module"
    python cli.py done 99        # baseline: prints "error: no task at index 99", exits non-zero

modules/14-continuous-integration/README.md

@@ -17,7 +17,12 @@
 - **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. This module uses the forge's hosted runners, which require zero setup.
+and 19. On a **SaaS forge** (GitHub, GitLab.com, Bitbucket, and the rest) this module uses the
+forge's hosted runners, which require zero setup. **One honesty note for the self-host track:** a
+self-hosted Forgejo/Gitea/GitLab CE has the CI *feature* but no hosted compute — nothing actually
+runs until you attach a runner, and that's Module 19. The workflow you write here is correct either
+way and will run the moment a runner is registered; to watch it go green *now*, use a SaaS forge's
+hosted runners, then come back and own the compute end-to-end in Module 19.
 
 ---
 
@@ -245,7 +250,10 @@ your machine first.
 
 4. Open your repo in the forge's web UI and find the run (usually an "Actions," "CI/CD," or
    "Pipelines" tab, and a status icon on the commit). Watch the steps execute and turn green.
-   **That green check is the gate now standing guard on every future push.**
+   **That green check is the gate now standing guard on every future push.** (Self-host track: if
+   the run sits queued with nothing picking it up, that's the no-hosted-runner situation from the
+   prerequisites — the workflow is correct, it just has no compute until you attach a runner in
+   Module 19. Run this part on a SaaS forge to see green here and now.)
 
 ### Part C — Break it on purpose and watch CI catch it