fix(capstone,module-11): correct squash-revert recovery, M11 lab honesty, relative dates

- Capstone Part F: sync local main after the forge squash-merge, then plain
  `git revert <squash-sha>` (NOT `-m 1`, which is only for true --no-ff merge
  commits — Module 12, left untouched). Break-then-recover finale preserved.
- Capstone: replace hardcoded due date 2026-07-15 with relative-date guidance.
- M11 Part C: list-then-use-shown-index instead of hardcoded `done 1` (breaks on
  a carried-forward tasks.json).
- M11 Part E: be honest that "agent opens a PR" needs forge integration — host
  CLI path or push-then-human-opens fallback; MCP forward-pointer (M20).

Closes #8
Closes #14
Closes #15
Closes #30

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

modules/11-collaboration-humans-and-agents/README.md

@@ -267,8 +267,10 @@ loop, not the code, is what you're practicing.
   issues and PRs.
 - Push access to that repo (it's yours, so you have it).
 - Your editor-integrated AI tool (Module 4).
-- Optionally, your host's CLI (`gh` for GitHub, `glab` for GitLab, `tea` for Gitea/Forgejo) — the web
-  UI works for everything here, so the CLI is convenience, not a requirement.
+- Your host's CLI (`gh` for GitHub, `glab` for GitLab, `tea` for Gitea/Forgejo). The web UI covers the
+  whole human-driven loop (Parts A–D), so there the CLI is just convenience. Part E is the exception:
+  for an *agent* to open the PR itself it has to reach the forge, which needs the CLI installed and
+  authenticated — or you take the no-CLI fallback that section spells out.
 
 Starter artifacts are in this module's `lab/`: `issue.md` (the issue to file) and `pr-body.md` (the
 PR description, including the load-bearing closing keyword).
@@ -320,11 +322,16 @@ If the push went through, protection isn't on — fix that before continuing. Fe
    the CLI), and it does what you asked. Run it:
 
    ```bash
-   python cli.py add "keeper" ; python cli.py add "trash" ; python cli.py done 1
+   python cli.py add "keeper" ; python cli.py add "trash"
+   python cli.py list                   # note the index shown next to "trash"
+   python cli.py done <trash-index>     # use the index "list" just printed — NOT a fixed 1
    python cli.py clear-done             # expect it to remove the completed one
    python cli.py list                   # "keeper" remains, "trash" is gone
    ```
 
+   Read the index off `list` rather than assuming it: `done` is positional, and your `tasks-app` has
+   been carrying tasks since Module 1, so "trash" won't reliably land at index 1.
+
 5. Commit and push the branch:
 
    ```bash
@@ -363,16 +370,38 @@ If the push went through, protection isn't on — fix that before continuing. Fe
 
 Run the loop one more time, but this time **let an agent be the contributor for steps 2–6.** File a
 second issue (e.g. "Add a `pending` command that lists only incomplete tasks" — the `TaskList.pending()`
-method already exists, so this is wiring only). Then prompt your agent:
+method already exists, so this is wiring only).
 
-> "Take issue #43. Create a branch named `43-pending-command`, implement the feature, commit
-> referencing the issue with a closing keyword, push the branch, and open a PR into `main` whose
-> description closes #43."
+**First, a reality check the rest of the lab let you skip.** Two of those steps cross the forge
+boundary: the agent has to *read* issue #43 from the forge and *open* a PR back into it. Your Module 4
+editor agent only edits files and runs local commands — and `git push` publishes a branch, it does
+**not** open a PR. The web UI you've been clicking can't be handed to the agent. So before you prompt,
+give the agent a way to reach the forge. Pick one path:
 
-Let the agent drive to the open-PR state. Then **you** are the human at the gate: review the diff,
-and merge (or request changes) yourself. You've just watched the exact loop run with a non-human
-contributor — and felt precisely where you, the human, stayed in it. If you want the parallel-agents
-case, file two issues and run two agents in separate worktrees (Module 7), each on its own branch.
+- **Full agent-opens-PR path (host CLI required).** Install and authenticate your host's CLI (`gh`,
+  `glab`, or `tea`) so the agent can run, e.g., `gh pr create` itself. For *this* step the CLI is a
+  requirement, not the convenience it was in Parts A–D. Then prompt the agent:
+
+  > "Take issue #43. Create a branch named `43-pending-command`, implement the feature, commit
+  > referencing the issue with a closing keyword, push the branch, and open a PR into `main` whose
+  > description closes #43."
+
+- **No-CLI fallback (you open the PR).** Have the agent do everything local — branch, implement,
+  commit, push — and *you* open the PR in the web UI, reusing `lab/pr-body.md` and keeping the
+  `Closes #43` line. Prompt it the same way, but stop it at the push:
+
+  > "Take issue #43. Create a branch named `43-pending-command`, implement the feature, commit
+  > referencing the issue with a closing keyword, and push the branch. I'll open the PR."
+
+  Wiring an agent *directly* into the forge — so it reads issues and opens PRs with no human hand-off
+  and no CLI to shell out to — is what an MCP forge integration buys you in **Module 20**. Here you're
+  feeling the exact seam that module closes.
+
+Either way, let the agent drive to the open-PR state. Then **you** are the human at the gate: review
+the diff, and merge (or request changes) yourself. You've just watched the exact loop run with a
+non-human contributor — and felt precisely where you, the human, stayed in it. If you want the
+parallel-agents case, file two issues and run two agents in separate worktrees (Module 7), each on its
+own branch.
 
 ---