Standardize how later labs reference modules/NN/lab/... scripts from inside the standalone tasks-app folder #7

New Issue

2026-06-22T14:23:40-04:00

claude commented

2026-06-22 14:23:40 -04:00

Problem

Module 1 creates tasks-app as a standalone folder at ~/workflow-course/tasks-app containing only three files; the course's modules/ tree is elsewhere (the unzipped course repo). Yet several later labs run scripts by paths that only resolve inside the course repo, while working "from inside tasks-app":

M4: bash lab/verify.sh (there is no lab/ in tasks-app).
M6: bash modules/06-.../lab/make-conflict.sh.
M7: bash modules/07-.../lab/setup-worktrees.sh (its own header says "Run this from INSIDE your tasks-app repo").
M26: bash modules/26-.../lab/fan-out.sh.
Each fails with "No such file or directory". The course never establishes the directory relationship. M1/M5/M25 handle this correctly (copy the file in, or use a /path/to placeholder); these modules don't.

Evidence

modules/04-.../README.md ~line 328 bash lab/verify.sh; modules/06-.../README.md ~line 424; modules/07-.../lab/setup-worktrees.sh header lines 4-6; modules/26-.../README.md ~line 300. tasks-app is created at M1 README lines 144-149 with only tasks.py cli.py README.md.

Why it matters

These are load-bearing lab steps (M4's verify.sh is the done-check proving the AI change works). Literal commands fail across four modules. The locked exemplars are precise about paths; the course needs one stated convention.

Proposed change

Pick the M5/M25 copy-the-script-in convention and apply it everywhere:

State once (in Module 1 or each lab's "You'll need") that scripts live in the course repo's modules/NN/lab/ and must be copied into tasks-app before running.
For each affected lab, instruct: copy the needed script into tasks-app and run bash <script>.sh (or use an explicit /path/to/modules/... placeholder as M5 does).
For M4 specifically: tell the learner to copy verify.sh into tasks-app, then run bash verify.sh (the script already self-locates cli.py).
Do NOT adopt the "create tasks-app inside the course repo" option: relative modules/... from inside tasks-app still wouldn't resolve, tasks-app is git init'd so nesting creates a repo-in-a-repo, and sibling worktrees (../tasks-app-count) would land inside the course repo.

Acceptance criteria

One stated convention covers how later labs reach modules/NN/lab/ scripts.
M4, M6, M7, M26 commands resolve when followed literally from tasks-app.
M7's setup-worktrees.sh header matches the chosen convention.

Affected files

modules/04-.../README.md, modules/06-.../README.md, modules/07-.../README.md, modules/07-.../lab/setup-worktrees.sh, modules/26-.../README.md

References

Source finding F6 (realVotes 3/3). Interacts with F1 (M4 verify.sh).

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 Module 1 creates `tasks-app` as a standalone folder at `~/workflow-course/tasks-app` containing only three files; the course's `modules/` tree is elsewhere (the unzipped course repo). Yet several later labs run scripts by paths that only resolve inside the course repo, while working "from inside tasks-app": - M4: `bash lab/verify.sh` (there is no `lab/` in tasks-app). - M6: `bash modules/06-.../lab/make-conflict.sh`. - M7: `bash modules/07-.../lab/setup-worktrees.sh` (its own header says "Run this from INSIDE your tasks-app repo"). - M26: `bash modules/26-.../lab/fan-out.sh`. Each fails with "No such file or directory". The course never establishes the directory relationship. M1/M5/M25 handle this correctly (copy the file in, or use a `/path/to` placeholder); these modules don't. ## Evidence `modules/04-.../README.md` ~line 328 `bash lab/verify.sh`; `modules/06-.../README.md` ~line 424; `modules/07-.../lab/setup-worktrees.sh` header lines 4-6; `modules/26-.../README.md` ~line 300. `tasks-app` is created at M1 README lines 144-149 with only `tasks.py cli.py README.md`. ## Why it matters These are load-bearing lab steps (M4's `verify.sh` is the done-check proving the AI change works). Literal commands fail across four modules. The locked exemplars are precise about paths; the course needs one stated convention. ## Proposed change Pick the M5/M25 copy-the-script-in convention and apply it everywhere: 1. State once (in Module 1 or each lab's "You'll need") that scripts live in the course repo's `modules/NN/lab/` and must be copied into `tasks-app` before running. 2. For each affected lab, instruct: copy the needed script into `tasks-app` and run `bash <script>.sh` (or use an explicit `/path/to/modules/...` placeholder as M5 does). 3. For M4 specifically: tell the learner to copy `verify.sh` into tasks-app, then run `bash verify.sh` (the script already self-locates `cli.py`). Do NOT adopt the "create tasks-app inside the course repo" option: relative `modules/...` from inside tasks-app still wouldn't resolve, tasks-app is `git init`'d so nesting creates a repo-in-a-repo, and sibling worktrees (`../tasks-app-count`) would land inside the course repo. ## Acceptance criteria - [ ] One stated convention covers how later labs reach `modules/NN/lab/` scripts. - [ ] M4, M6, M7, M26 commands resolve when followed literally from `tasks-app`. - [ ] M7's `setup-worktrees.sh` header matches the chosen convention. ## Affected files - `modules/04-.../README.md`, `modules/06-.../README.md`, `modules/07-.../README.md`, `modules/07-.../lab/setup-worktrees.sh`, `modules/26-.../README.md` ## References Source finding F6 (realVotes 3/3). Interacts with F1 (M4 `verify.sh`). --- *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.*