Rework

Author: olivomarco

CONTRIBUTING.md

@@ -15,45 +15,42 @@ or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any addi
 
 ## Content architecture contract
 
-Challenge content lives under `modules/<moduleId>/challenges/<slug>/`. The build reads
+Activity content lives under `modules/<moduleId>/challenges/<slug>/`. The build reads
 `meta.yml` as the single source of truth and copies `README.md` and `COACH.md` into the
 generated Pages data. Do not hand-edit generated files under `docs/assets/data/`; run
 `npm run build` instead.
 
 Outcome journeys live in [`outcomes.json`](outcomes.json). Use that file to curate existing
-challenges into adoption, migration, security, agentic workflow, and cloud DevOps paths
-without duplicating challenge content.
+activities into adoption, migration, security, agentic workflow, and cloud DevOps paths
+without duplicating activity content.
 
-Every challenge directory must contain:
+Every activity directory must contain:
 
 ```text
 meta.yml   # catalog metadata and dependency contract
-README.md  # student guide
+README.md  # customer delivery team guide
 COACH.md   # facilitator guide, hints, expected outputs, common failures
 ```
 
 ### `meta.yml` required fields
 
 | Field | Contract |
 |---|---|
-| `id` | Globally unique challenge id. Use `<module>-<local-id>` (`ghec-ch01`, `ghas-02`, `ghaw-15`, `sre-agent-04`). Ids are stable and may have intentional gaps. |
+| `id` | Globally unique activity ID. Use `<module>-<local-id>` (`ghec-ch01`, `ghas-02`, `ghaw-15`, `sre-agent-04`). IDs are stable and may have intentional gaps. |
 | `title` | Short catalog title. |
 | `module` | One of `ghec`, `ghas`, `ghaw`, `sre-agent`. |
 | `track` | Track slug for the module; must match `docs/build.js` module config. |
 | `difficulty` | `beginner`, `intermediate`, or `advanced`. |
-| `duration_minutes` | Estimated student time in minutes. |
-| `prerequisites` | Challenge ids that must be completed first. Empty means independent except for stated environment setup. |
-| `prerequisite_capabilities` | Skills or access needed before starting; do not use this for challenge ids. |
+| `duration_minutes` | Estimated time for a delivery team member in minutes. |
+| `prerequisites` | Activity ids that must be completed first. Empty means independent except for stated environment setup. |
+| `prerequisite_capabilities` | Skills or access needed before starting; do not use this for activity ids. |
 | `description` | One-sentence catalog summary. |
-| `success_criteria` | Observable outcomes that prove the challenge is complete. |
-| `take_home_action` | Imperative production-adoption step the reader repeats in **their own org/tenant** (e.g. "In your own org, enforce push protection org-wide"). Plain scalar; drives real GitHub usage, not a coaching chat. |
-| `take_home_owner` | Who owns the rollout: `developer`, `platform-governance`, or `solution-architect`. |
-| `take_home_signal` | Observable production signal proving it landed (e.g. "Secret push protection blocks a real push in your org"). |
+| `success_criteria` | Observable outcomes that prove the activity is complete. |
 | `tags` | Search/filter terms. Use lowercase kebab-case where possible. |
 | `app_dependency` | Runtime/sample dependency (`none`, `juice-shop`, `contoso-claims`, `contoso-app`, `seed`, or `seed-repo`). |
-| `emu_compatible` | `true` when the challenge works in an EMU-controlled org; otherwise `false`. |
+| `emu_compatible` | `true` when the activity works in an EMU-controlled org; otherwise `false`. |
 | `min_environment` | Lowest required scope: `org`, `repo`, or `codespace`. |
-| `provision_creates` | Human-readable resources created by setup or student steps. Empty list is allowed. |
+| `provision_creates` | Human-readable resources created by setup or delivery team member actions. Empty list is allowed. |
 | `source_repo` | Source repository provenance. |
 | `source_path` | Repository-relative source path. Do not use absolute paths or `..`. |
 | `license` | Source license; currently `MIT`. |
@@ -63,8 +60,8 @@ Optional fields:
 | Field | Contract |
 |---|---|
 | `tier` | `setup`, `core`, `stretch`, or `bonus`. Defaults to `core` in the build. |
-| `references` | Source-backed docs and product links used by students or coaches. |
-| `outcomes` | Outcome ids from `outcomes.json` when a challenge needs explicit membership beyond journey curation. |
+| `references` | Source-backed docs and product links used by customer delivery team members or coaches. |
+| `outcomes` | Outcome ids from `outcomes.json` when a activity needs explicit membership beyond journey curation. |
 | `personas` | Personas such as `platform-engineer`, `security-lead`, `developer`, `sre`, or `migration-lead`. |
 | `business_value` | Value tags such as `reduce-migration-risk`, `shift-left-security`, or `automate-repetitive-work`. |
 | `adoption_stage` | `assess`, `pilot`, `scale`, or `operate`. |
@@ -84,23 +81,23 @@ Each outcome requires:
 | `adoption_stage` | Stages covered by the journey: `assess`, `pilot`, `scale`, `operate`. |
 | `business_value` | Searchable value tags. |
 | `source_platforms` | Relevant starting platforms, such as `azure-devops`, `bitbucket`, `gitlab`, `github`, or `greenfield`. |
-| `challenge_ids` | Ordered list of existing challenge ids included in the journey. |
+| `challenge_ids` | Ordered list of existing activity ids included in the journey. |
 | `success_metrics` | Production-observable outcomes the customer's own team can verify in their GitHub organization or Azure tenant. |
 
-## Per-challenge QA rubric
+## Per-activity QA rubric
 
-Use this 100-point rubric for every new or materially changed challenge. Record manual
+Use this 100-point rubric for every new or materially changed activity. Record manual
 review results in PR comments or issue bodies, not in throwaway repo planning files.
 
 | Area | Points | Pass standard |
 |---|---:|---|
 | Metadata and provenance | 15 | Required fields complete; ids stable; module/track valid; source attribution present; generated catalog matches source. |
-| Independence and setup | 20 | Challenge can be started from a clean environment with only listed prerequisites/capabilities; no hidden state from previous challenges; app dependency acquisition is documented. |
-| Student guide quality | 20 | README has clear goal, steps, validation commands/screens, expected outputs, cleanup notes where needed, and no dead/internal-only links. |
+| Independence and setup | 20 | Activity can be started from a clean environment with only listed prerequisites/capabilities; no hidden state from previous activities; app dependency acquisition is documented. |
+| Customer delivery team guide quality | 20 | README has clear goal, steps, validation commands/screens, expected outputs, cleanup notes where needed, and no dead/internal-only links. |
 | Coach guide quality | 15 | COACH covers facilitator intent, hints, expected solution/evidence, timing, and common failure modes without leaking secrets. |
 | Validation evidence | 15 | Build/audit pass; success criteria are objectively checkable; commands are current; external dependency versions or availability claims are source-backed. |
 | Accessibility and operational safety | 10 | Works in intended org/account type; calls out Azure/billing/permissions risk; avoids destructive defaults and committed secrets. |
-| Catalog fit and coverage | 5 | Challenge fills a real module/track need, avoids unnecessary duplication, and has useful tags for discovery. |
+| Catalog fit and coverage | 5 | Activity fills a real module/track need, avoids unnecessary duplication, and has useful tags for discovery. |
 
 Score bands:
 
@@ -115,14 +112,14 @@ Severity levels:
 
 | Severity | Definition | Merge policy |
 |---|---|---|
-| P0 | Build/audit failure, broken prerequisite graph, missing guide, unsafe instruction, secret exposure, or challenge cannot start. | Blocks merge. |
+| P0 | Build/audit failure, broken prerequisite graph, missing guide, unsafe instruction, secret exposure, or activity cannot start. | Blocks merge. |
 | P1 | Core learning path fails, hidden dependency, stale product instruction, dead required link, or misleading success criteria. | Blocks merge unless owner accepts documented risk. |
-| P2 | Coach/student quality gap, weak evidence, missing optional metadata, incomplete cleanup, or confusing catalog fit. | May merge with assigned follow-up. |
+| P2 | Coach/delivery team member quality gap, weak evidence, missing optional metadata, incomplete cleanup, or confusing catalog fit. | May merge with assigned follow-up. |
 | P3 | Editorial polish, tag improvement, minor timing mismatch, or optional reference update. | Non-blocking. |
 
 ### QA inventory format
 
-For audit-friendly reviews, use one inventory object per challenge. JSON Lines works well
+For audit-friendly reviews, use one inventory object per activity. JSON Lines works well
 in PR comments, issue bodies, or generated local reports because it is machine-diffable
 and does not require a repo planning markdown file.
 
@@ -138,10 +135,10 @@ Required inventory keys: `id`, `reviewed_at`, `reviewer`, `score`, `severity`,
 
 ## Catalog coverage and backlog decisions
 
-Use these rules when deciding whether a missing challenge belongs in the backlog:
+Use these rules when deciding whether a missing activity belongs in the backlog:
 
 1. Preserve current scoped modules before adding new scope.
-2. Prefer a gap-filling challenge over a duplicate topic.
+2. Prefer a gap-filling activity over a duplicate topic.
 3. Do not restore intentionally removed ids unless the original scope decision is reversed.
 4. If a candidate needs a new product area, create a new module/track proposal rather than
    stretching an existing module.

README.md

@@ -1,12 +1,12 @@
 # Agentic DevOps
 
-One repo. One GitHub Pages site. Five adoption journeys, four delivery session modules, 64 challenges, zero configuration drama.
+One repo. One GitHub Pages site. Five adoption journeys, four delivery session modules, 64 activities, zero configuration drama.
 
-> **Bring your own.** These challenges are built to run on **your** tenant — work each one
+> **Bring your own.** These activities are built to run on **your** tenant — work each one
 > against your own applications, repositories, and data so the result keeps running in
 > production after the session, not just as an upskilling exercise. The sample apps
 > (OWASP Juice Shop, the Grubify sample, seed repos) are only a fallback so no one is
-> blocked. Wherever a challenge says "bring your own," start from your real work; the
+> blocked. Wherever a activity says "bring your own," start from your real work; the
 > setup script and sample are there when you don't yet have a candidate.
 
 ## Outcomes
@@ -23,21 +23,21 @@ The site is organized around customer adoption outcomes first, then platform mod
 
 ## Modules
 
-| Module ID | Name | Challenges | Tracks |
+| Module ID | Name | Activities | Tracks |
 |---|---|---|---|
 | `ghec` | GitHub Enterprise Cloud | 27 | Developer Flow, Admin & Governance, Security, Automation & AI, Migration |
 | `ghas` | GitHub Advanced Security | 7 | Security |
 | `ghaw` | GitHub Agentic Workflows | 25 | Hello, Agent, Repo Concierge, Continuous Intelligence, Production Patterns |
 | `sre-agent` | SRE Agent | 5 | Azure SRE Agent |
 
-> **Total:** 64 challenges across 4 modules.
+> **Total:** 64 activities across 4 modules.
 
 ## Architecture
 
 ```
 modules/<moduleId>/challenges/<slug>/
   meta.yml      ← single source of truth (build reads ONLY this)
-  README.md     ← student guide
+  README.md     ← customer delivery team guide
   COACH.md      ← coach guide (facilitator notes, expected outputs, hints)
         │
         ▼
@@ -47,7 +47,7 @@ modules/<moduleId>/challenges/<slug>/
 docs/assets/data/
   platform.json              ← full catalog (modules + challenges)
   dependency-graph.json      ← prereq graph (nodes + edges)
-  challenges/<id>/README.md  ← copied student guide (served by Pages)
+  challenges/<id>/README.md  ← copied customer delivery team guide (served by Pages)
   challenges/<id>/COACH.md   ← copied coach guide
 ```
 
@@ -68,7 +68,7 @@ Output lands in `docs/assets/data/`. The Pages site (`docs/`) is fully self-cont
 ```
 ✓ built platform.json  (modules: 4, challenges: N)
 ✓ built dependency-graph.json  (nodes: N, edges: N)
-✓ copied student/coach guides → docs/assets/data/challenges/
+✓ copied customer delivery team/coach guides → docs/assets/data/challenges/
 ```
 
 Exit code 0 = success. Non-zero = validation errors (check stderr).
@@ -87,7 +87,7 @@ To prefetch everything during clone, use `git clone --recurse-submodules <repo>`
 ## Validation
 
 The build validates:
-- Every `prerequisites` entry references a real challenge `id` in the catalog.
+- Every `prerequisites` entry references a real activity `id` in the catalog.
 - No circular dependencies.
 - Warns on missing optional fields.
 
@@ -107,7 +107,7 @@ CI runs the same build on every PR and fails the check if validation errors are
 See [`CONTRIBUTING.md`](CONTRIBUTING.md) for the `meta.yml` field contract and authoring guide.  
 See [`modules/README.md`](modules/README.md) for the module and directory layout.  
 See [`docs/EXTERNAL-REPOS.md`](docs/EXTERNAL-REPOS.md) for how external dependencies (Juice Shop, sample apps, third-party delivery sessions) are managed and pinned.  
-Use `modules/_TEMPLATE/challenge/` as your starting point for new challenges.
+Use `modules/_TEMPLATE/challenge/` as your starting point for new activities.
 
 ## Deploy