Use python3 as the canonical command name course-wide (#104) (#105)

modules/05-commit-the-ai-config/README.md

@@ -48,7 +48,7 @@ committed instructions file from the repo, and you control what's in it.**
 > content if so. The principle outlives any one vendor's filename.
 
 Without this file, you re-explain your project every session: "we use 4-space indent," "run the tests
-with `python -m unittest` before you say you're done," "don't touch the generated `tasks.json`." You say it,
+with `python3 -m unittest` before you say you're done," "don't touch the generated `tasks.json`." You say it,
 the AI complies, the session ends, the memory evaporates (Module 1's second seam), and tomorrow you
 say it all again. The instructions file is where that knowledge stops being something you retype and
 becomes something the project *carries*.
@@ -62,7 +62,7 @@ a briefing for an agent that will edit this code. Keep it to what changes the AI
   uses. "Core logic lives in `tasks.py`; the CLI front end is `cli.py`; state persists to
   `tasks.json`."
 - **Build and test commands**: the exact commands, copy-pasteable. "Run the app with
-  `python cli.py <command>`. Run tests with `python -m unittest`. Don't claim a change works until
+  `python3 cli.py <command>`. Run tests with `python3 -m unittest`. Don't claim a change works until
   the tests pass." This single line stops the AI from inventing a test runner you don't use.
 - **Coding standards**: formatting, typing, error handling, the libraries you do and don't want.
   "Use the standard library only, no third-party packages. Type-hint public functions."
@@ -83,7 +83,7 @@ useful for personal preferences, but it's the wrong home for project knowledge,
 lives: on *your* laptop, invisible to everyone else.
 
 Picture a two-person project with no committed instructions file. You've trained your local setup to
-run `python -m unittest` and avoid `tasks.json`. Your teammate's setup hasn't, so their agent reformats whole files
+run `python3 -m unittest` and avoid `tasks.json`. Your teammate's setup hasn't, so their agent reformats whole files
 and hand-edits the generated JSON. You're both "using AI on the same repo," but you're getting
 different behavior, and neither of you can see the other's configuration. That's **drift**: the same
 codebase, diverging because the rules live in two heads instead of one file.
@@ -215,7 +215,7 @@ editor-integrated AI (Module 4) for the part where the AI obeys the file.
 - The `tasks-app` repo from Module 2 (already a Git repo with some history).
 - Your agentic coding tool from Module 4, and knowledge of which filename it reads for repo-level
   instructions (check its docs; see the note in *Key concepts*).
-- Optionally, a test command for the AI to honor; Python's built-in `python -m unittest` works with
+- Optionally, a test command for the AI to honor; Python's built-in `python3 -m unittest` works with
   nothing to install (you'll write a real suite in Module 13; until then it simply reports no tests).
 
 ### Part A: Write the instructions file and let the AI commit the config
@@ -321,7 +321,7 @@ Be honest about what a committed instructions file does and doesn't buy you:
 - **Bloat kills it.** A 300-line instructions file is read the way *you* read a 300-line terms-of-
   service: not really. Every line you add dilutes the rest. Keep it to what actually changes behavior,
   and prune lines the model already honors without being told.
-- **Stale instructions are worse than none.** A file that says "run the tests with `python -m
+- **Stale instructions are worse than none.** A file that says "run the tests with `python3 -m
   unittest`" after you've switched to a different runner will actively misdirect the AI. The file is
   code-adjacent: it has to be maintained like code, and reviewed like code. That's exactly why
   committing it (so changes are