Unlike the Module 1 exemplar's concrete copy instruction, Module 10 embeds literal cp /path/to/modules/10-…/lab/tasks-app/*.py . and git apply /path/to/…/ai-change.patch, which a literal-minded learner can type verbatim. git apply is a brand-new command (it appears only in M10 across all modules) and is used with no gloss; it silently rewrites two files. Part A also creates a separate review-lab repo distinct from tasks-app, which can confuse.
Evidence
modules/10-reviewing-code-you-didnt-write/README.md Part B step 3 (~line 242): "git apply /path/to/modules/10-reviewing-code-you-didnt-write/lab/ai-change.patch" with no explanation; cp /path/to/... (~line 209). git apply appears nowhere else in the course.
Why it matters
Clarity/consistency gap vs the locked Module 1 exemplar, plus a first-use command with no gloss in a module otherwise careful about its git mechanics.
Proposed change
Replace /path/to/ with a concrete repo-relative instruction in the Module 1 style (or the M5 /path/to/... placeholder convention used elsewhere).
Add a half-sentence gloss on git apply, e.g. "applies the AI's proposed change onto this branch as if it were its PR, so you can review it before merging." (Avoid "simulating its PR landing" — the lab ends in "request changes," not a merge.)
Note that review-lab is a throwaway repo separate from tasks-app.
Acceptance criteria
No paste-ready command contains an unresolved /path/to/ placeholder without explanation.
git apply is glossed on first use.
review-lab is identified as a throwaway repo distinct from tasks-app.
Source finding F59 (realVotes 2/3 — one lens judged /path/to/ an acceptable course-wide convention for this audience; lower confidence).
Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.
## Problem
Unlike the Module 1 exemplar's concrete copy instruction, Module 10 embeds literal `cp /path/to/modules/10-…/lab/tasks-app/*.py .` and `git apply /path/to/…/ai-change.patch`, which a literal-minded learner can type verbatim. `git apply` is a brand-new command (it appears only in M10 across all modules) and is used with no gloss; it silently rewrites two files. Part A also creates a separate review-lab repo distinct from `tasks-app`, which can confuse.
## Evidence
`modules/10-reviewing-code-you-didnt-write/README.md` Part B step 3 (~line 242): "git apply /path/to/modules/10-reviewing-code-you-didnt-write/lab/ai-change.patch" with no explanation; `cp /path/to/...` (~line 209). `git apply` appears nowhere else in the course.
## Why it matters
Clarity/consistency gap vs the locked Module 1 exemplar, plus a first-use command with no gloss in a module otherwise careful about its git mechanics.
## Proposed change
1. Replace `/path/to/` with a concrete repo-relative instruction in the Module 1 style (or the M5 `/path/to/...` placeholder convention used elsewhere).
2. Add a half-sentence gloss on `git apply`, e.g. "applies the AI's proposed change onto this branch as if it were its PR, so you can review it before merging." (Avoid "simulating its PR landing" — the lab ends in "request changes," not a merge.)
3. Note that review-lab is a throwaway repo separate from `tasks-app`.
## Acceptance criteria
- [ ] No paste-ready command contains an unresolved `/path/to/` placeholder without explanation.
- [ ] `git apply` is glossed on first use.
- [ ] review-lab is identified as a throwaway repo distinct from tasks-app.
## Affected files
- `modules/10-reviewing-code-you-didnt-write/README.md`
## References
Source finding F59 (realVotes 2/3 — one lens judged `/path/to/` an acceptable course-wide convention for this audience; lower confidence).
---
*Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.*
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
Unlike the Module 1 exemplar's concrete copy instruction, Module 10 embeds literal
cp /path/to/modules/10-…/lab/tasks-app/*.py .andgit apply /path/to/…/ai-change.patch, which a literal-minded learner can type verbatim.git applyis a brand-new command (it appears only in M10 across all modules) and is used with no gloss; it silently rewrites two files. Part A also creates a separate review-lab repo distinct fromtasks-app, which can confuse.Evidence
modules/10-reviewing-code-you-didnt-write/README.mdPart B step 3 (~line 242): "git apply /path/to/modules/10-reviewing-code-you-didnt-write/lab/ai-change.patch" with no explanation;cp /path/to/...(~line 209).git applyappears nowhere else in the course.Why it matters
Clarity/consistency gap vs the locked Module 1 exemplar, plus a first-use command with no gloss in a module otherwise careful about its git mechanics.
Proposed change
/path/to/with a concrete repo-relative instruction in the Module 1 style (or the M5/path/to/...placeholder convention used elsewhere).git apply, e.g. "applies the AI's proposed change onto this branch as if it were its PR, so you can review it before merging." (Avoid "simulating its PR landing" — the lab ends in "request changes," not a merge.)tasks-app.Acceptance criteria
/path/to/placeholder without explanation.git applyis glossed on first use.Affected files
modules/10-reviewing-code-you-didnt-write/README.mdReferences
Source finding F59 (realVotes 2/3 — one lens judged
/path/to/an acceptable course-wide convention for this audience; lower confidence).Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.