Qualify Module 14's 'hosted runners need zero setup' — false for the self-hosted forge track #16

New Issue

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

claude commented

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

Problem

Module 14 says CI works on any forge including a self-hosted Forgejo/Gitea from Module 8 and "uses the forge's hosted runners, which require zero setup." That is only true for SaaS clouds. A self-hosted Forgejo/Gitea/GitLab CE has no hosted runner pool — CI does nothing until a runner is registered (act_runner/gitlab-runner), which isn't taught until Module 19. So a self-host-track learner cannot complete Module 14's core "watch the steps turn green" step, and the "GitHub is the default, not the requirement" promise quietly breaks.

Evidence

modules/14-continuous-integration/README.md (~lines 11-12, 19-20): "any forge — GitHub, GitLab, a self-hosted Forgejo/Gitea … This module uses the forge's hosted runners, which require zero setup." Part B step 4 has Forgejo/Gitea users "watch CI turn green."
Module 19 (~lines 120-122) confirms self-hosted has "no hosted [runner]" until you register one.

Why it matters

Breaks "honesty about limits" and the first-class self-host track for a core lab outcome; it's a real chain dependency (M8 self-host → M14 → runner registration in M19).

Proposed change

Add an honest note (flag, don't reorder), e.g.: "Hosted runners (zero setup) exist on the SaaS clouds. A self-hosted forge has the CI feature but no compute until a runner is attached — that's Module 19. The workflow you write here will run the moment one is registered; to see green now, use a SaaS forge's hosted runners."
Avoid "jump ahead to Module 19's register step" as the primary instruction (M19 assumes this M14 workflow already exists — soft circular dependency); the qualification above is cleaner.

Acceptance criteria

Module 14 no longer claims hosted runners are universal/zero-setup.
Self-host learners are told they need a runner (Module 19) and how to still see CI green now (SaaS).
Both a SaaS path and a self-host path remain valid (GitHub-as-default preserved).

Affected files

modules/14-continuous-integration/README.md

References

Source finding F27 (realVotes 3/3). M8 self-host track; M19 runner registration.

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 14 says CI works on any forge including a self-hosted Forgejo/Gitea from Module 8 and "uses the forge's hosted runners, which require zero setup." That is only true for SaaS clouds. A self-hosted Forgejo/Gitea/GitLab CE has no hosted runner pool — CI does nothing until a runner is registered (`act_runner`/`gitlab-runner`), which isn't taught until Module 19. So a self-host-track learner cannot complete Module 14's core "watch the steps turn green" step, and the "GitHub is the default, not the requirement" promise quietly breaks. ## Evidence `modules/14-continuous-integration/README.md` (~lines 11-12, 19-20): "any forge — GitHub, GitLab, a self-hosted Forgejo/Gitea … This module uses the forge's hosted runners, which require zero setup." Part B step 4 has Forgejo/Gitea users "watch CI turn green." Module 19 (~lines 120-122) confirms self-hosted has "no hosted [runner]" until you register one. ## Why it matters Breaks "honesty about limits" and the first-class self-host track for a core lab outcome; it's a real chain dependency (M8 self-host → M14 → runner registration in M19). ## Proposed change Add an honest note (flag, don't reorder), e.g.: "Hosted runners (zero setup) exist on the SaaS clouds. A self-hosted forge has the CI feature but no compute until a runner is attached — that's Module 19. The workflow you write here will run the moment one is registered; to see green now, use a SaaS forge's hosted runners." Avoid "jump ahead to Module 19's register step" as the primary instruction (M19 assumes this M14 workflow already exists — soft circular dependency); the qualification above is cleaner. ## Acceptance criteria - [ ] Module 14 no longer claims hosted runners are universal/zero-setup. - [ ] Self-host learners are told they need a runner (Module 19) and how to still see CI green now (SaaS). - [ ] Both a SaaS path and a self-host path remain valid (GitHub-as-default preserved). ## Affected files - `modules/14-continuous-integration/README.md` ## References Source finding F27 (realVotes 3/3). M8 self-host track; M19 runner registration. --- *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.*

claude added the bug P1 ai-ready labels 2026-06-22 14:23:44 -04:00

claude referenced a pull request that will close this issue

2026-06-22 14:58:42 -04:00

Deterministic main branch + fix two claims (#5,#13,#16) #56

claude referenced this issue from a commit

2026-06-22 14:58:43 -04:00

fix(modules-2,6,7,8,9,10,14): deterministic main branch + correct two claims

claude closed this issue

2026-06-22 14:58:51 -04:00

Sign in to join this conversation.