dojo.md 0.1.0 → 0.2.1

package/courses/github-actions-cicd/scenarios/level-2/matrix-builds.yaml

@@ -0,0 +1,59 @@
+meta:
+  id: matrix-builds
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Configure matrix builds — test across multiple OS, language versions, and configurations using strategy.matrix"
+  tags: [github, actions, matrix, cross-platform, multi-version, intermediate]
+
+state: {}
+
+trigger: |
+  You maintain an open-source Node.js library that must work across
+  multiple environments. The library is used by projects running
+  different Node.js versions, operating systems, and package managers.
+
+  Test matrix requirements:
+  - Node.js versions: 18, 20, 22
+  - Operating systems: ubuntu-latest, windows-latest, macos-latest
+  - Package managers: npm, yarn, pnpm
+  - Full matrix = 3 x 3 x 3 = 27 combinations
+
+  Constraints:
+  - The full matrix takes too long (45 minutes) and costs too much
+  - Node 18 on Windows with pnpm has a known incompatibility — exclude
+    this combination
+  - Node 22 is experimental — failures shouldn't block the PR
+  - macOS runners cost 10x more than Linux runners — minimize usage
+  - You want to add a specific combination not in the matrix: Node 21
+    (nightly) on ubuntu-latest with npm
+
+  Additional requirements:
+  - If any matrix job fails, you want to see all results (don't cancel
+    other jobs immediately)
+  - The matrix should generate a human-readable job name like
+    "Test (node-20, ubuntu-latest, npm)"
+  - After all matrix jobs complete, a summary job should report which
+    combinations passed/failed
+
+  Task: Write the complete matrix workflow. Include: the matrix
+  configuration with include, exclude, and fail-fast settings, the
+  strategy for reducing the 27-combination matrix to a practical subset
+  (explain your reasoning for which to cut), the Node 22 experimental
+  configuration using continue-on-error, and the summary job that
+  collects all matrix results. Explain the cost implications of your
+  matrix choices.
+
+assertions:
+  - type: llm_judge
+    criteria: "Matrix syntax is correct — uses strategy.matrix with proper include/exclude syntax, fail-fast: false, continue-on-error for Node 22, and the exclude for Node 18 + Windows + pnpm is correctly specified"
+    weight: 0.35
+    description: "Correct matrix syntax"
+  - type: llm_judge
+    criteria: "Matrix reduction is well-reasoned — reduces the 27-combination matrix to a practical subset (maybe 12-15), justifies which combinations to keep (e.g., full Linux matrix, reduced macOS to save cost), and the cost analysis shows the savings"
+    weight: 0.35
+    description: "Well-reasoned matrix reduction"
+  - type: llm_judge
+    criteria: "Summary job correctly aggregates results — uses needs with the matrix job, accesses matrix job outcomes, and produces a clear pass/fail report for all combinations. The workflow would work correctly in a real repository"
+    weight: 0.30
+    description: "Correct summary aggregation"

package/courses/github-actions-cicd/scenarios/level-2/reusable-workflows.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: reusable-workflows
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Build reusable workflows — create DRY CI/CD with reusable workflows, composite actions, and workflow templates"
+  tags: [github, actions, reusable-workflows, composite-actions, DRY, intermediate]
+
+state: {}
+
+trigger: |
+  Your organization has 15 Node.js repositories that all have nearly
+  identical CI/CD workflows. When you need to update the Node version
+  or add a security scan, you have to modify 15 files across 15 repos.
+  Last month, someone forgot to update 3 repos and they broke.
+
+  Current duplication:
+  - All 15 repos: checkout → setup-node → install → lint → test → build
+  - 8 repos: + deploy to staging on merge to main
+  - 5 repos: + deploy to production on release
+  - All repos: same Slack notification on failure
+
+  You need to create reusable components:
+
+  Component 1 — Reusable workflow (workflow_call):
+  Create a reusable CI workflow that accepts inputs:
+  - node-version (default: 20)
+  - run-e2e (boolean, default: false)
+  - deploy-target (string: none/staging/production)
+  And passes secrets:
+  - AWS credentials (for deployment)
+  - Slack webhook URL (for notifications)
+
+  Component 2 — Composite action:
+  Create a composite action "setup-and-test" that bundles:
+  - Checkout, setup-node, cache, install, lint, test
+  Into a single reusable action that can be used in any workflow
+
+  Component 3 — Workflow template (organization level):
+  Create a starter workflow template that new repos can adopt from
+  the "Actions" tab, pre-configured with your org's standards
+
+  Task: Build all 3 components. For each, write: the complete YAML
+  files, the calling workflow that uses them, and the comparison (when
+  to use reusable workflows vs composite actions vs templates). Include
+  the migration plan for moving the 15 repos from duplicated workflows
+  to the reusable approach.
+
+assertions:
+  - type: llm_judge
+    criteria: "Reusable workflow is correctly structured — uses workflow_call trigger with typed inputs and secrets, the calling workflow uses 'uses: org/repo/.github/workflows/file.yml@main' syntax, and secrets are passed correctly (secrets: inherit or explicit)"
+    weight: 0.35
+    description: "Correct reusable workflow structure"
+  - type: llm_judge
+    criteria: "Composite action is properly defined — has action.yml with inputs/outputs, uses 'composite' runs type, steps use correct shell specification, and the calling workflow uses it with 'uses: org/repo/path@version' syntax"
+    weight: 0.35
+    description: "Proper composite action definition"
+  - type: llm_judge
+    criteria: "Comparison is clear and practical — explains when to choose reusable workflows (full job reuse, secret passing), composite actions (step-level reuse, can run in existing jobs), and templates (one-time setup for new repos), with a migration plan that doesn't break existing CI"
+    weight: 0.30
+    description: "Clear comparison and migration plan"

package/courses/github-actions-cicd/scenarios/level-2/workflow-cost-optimization.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: workflow-cost-optimization
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Optimize workflow costs — reduce GitHub Actions spend through caching, concurrency, path filters, and runner selection"
+  tags: [github, actions, cost, optimization, billing, runners, intermediate]
+
+state: {}
+
+trigger: |
+  Your engineering manager just received the GitHub Actions bill:
+  $4,200/month for a 25-person team. They want you to cut it by 50%
+  without sacrificing CI quality. Here's the current usage breakdown:
+
+  Billing data (last month):
+  - Total minutes used: 42,000
+  - Linux runners: 28,000 min ($280 at $0.008/min)
+  - macOS runners: 8,000 min ($640 at $0.08/min)
+  - Windows runners: 6,000 min ($96 at $0.016/min)
+  - Storage (artifacts + packages): $180
+  - Overage beyond free tier: $3,000
+
+  Workflow analysis:
+  | Workflow          | Runs/month | Avg duration | Total min | Cost  |
+  |-------------------|-----------|-------------|-----------|-------|
+  | ci.yml            | 1,200     | 15 min      | 18,000    | $1,440|
+  | deploy.yml        | 60        | 8 min       | 480       | $38   |
+  | nightly-tests.yml | 30        | 45 min      | 1,350     | $108  |
+  | e2e-all-os.yml    | 400       | 30 min      | 12,000    | $1,560|
+  | lint-on-save.yml  | 2,000     | 3 min       | 6,000     | $480  |
+  | security-scan.yml | 200       | 12 min      | 2,400     | $192  |
+  | stale-cleanup.yml | 30        | 5 min       | 150       | $12   |
+
+  Key observations:
+  - ci.yml runs on every push (even draft PRs, even docs-only changes)
+  - e2e-all-os.yml runs full matrix on all 3 OSes for every PR
+  - lint-on-save.yml triggers on every push including commit amends
+  - nightly-tests.yml runs a full test suite even when nothing changed
+  - Artifacts are retained for 90 days (default)
+
+  Task: Create the cost optimization plan. For each workflow, write:
+  the specific optimization (with YAML changes), the expected savings,
+  and any quality trade-offs. Include: the optimized billing projection,
+  the comparison of GitHub-hosted vs self-hosted runner economics for
+  this team's usage, and a monitoring dashboard design for ongoing
+  cost tracking. Target: reduce from $4,200 to under $2,100/month.
+
+assertions:
+  - type: llm_judge
+    criteria: "Optimizations are specific and impactful — ci.yml gets path filters and draft PR skip, e2e-all-os runs full matrix only on main (reduced matrix on PRs), lint-on-save gets concurrency cancel-in-progress, artifact retention is reduced, and each optimization has a dollar-value estimate"
+    weight: 0.35
+    description: "Specific impactful optimizations"
+  - type: llm_judge
+    criteria: "Cost reduction achieves the target — the total projected savings reach or exceed 50% ($2,100 target), each optimization's savings are calculated from the billing data, and the math is consistent and reasonable"
+    weight: 0.35
+    description: "Target-achieving cost reduction"
+  - type: llm_judge
+    criteria: "Self-hosted runner analysis is included — compares the monthly cost of GitHub-hosted vs self-hosted for this usage level, considers the maintenance overhead of self-hosted, and makes a clear recommendation with break-even analysis"
+    weight: 0.30
+    description: "Self-hosted runner analysis"

package/courses/github-actions-cicd/scenarios/level-3/advanced-cicd-shift.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: advanced-cicd-shift
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Advanced CI/CD shift — handle security incidents, compliance failures, and infrastructure emergencies in GitHub Actions"
+  tags: [github, actions, shift-simulation, security, compliance, incident, advanced]
+
+state: {}
+
+trigger: |
+  You're the CI/CD platform engineer handling an intense shift with
+  4 critical issues arriving within the same hour.
+
+  Issue 1 — Supply chain attack detected (Critical):
+  GitHub's secret scanning alerted that a popular action you use
+  (actions/setup-python@v4) had its v4 tag overwritten 30 minutes ago
+  by a compromised maintainer account. The malicious version exfiltrates
+  environment variables (including secrets) to an external server. Your
+  organization has 25 repos using this action. 8 workflow runs have
+  already executed since the compromise.
+  Immediate: Determine which repos are affected, assess exposure, and
+  block further execution.
+
+  Issue 2 — SOC 2 audit finding (High):
+  The SOC 2 auditor found that your required workflow (security scan)
+  can be bypassed. A developer discovered they can modify the workflow
+  file in their PR to skip the security scan, and since the modified
+  workflow is what runs, the bypass succeeds. This is a critical control
+  failure.
+
+  Issue 3 — Runner fleet failure (High):
+  Your self-hosted runner fleet (Kubernetes with ARC) is experiencing
+  cascading failures. The runner controller pod is in CrashLoopBackOff,
+  new jobs are queueing but not starting, and 15 deployments are
+  blocked. The last change was a Kubernetes cluster upgrade 2 hours ago.
+
+  Issue 4 — Cost spike (Medium):
+  GitHub Actions billing shows a 400% cost spike in the last 24 hours.
+  Investigation reveals a workflow with an infinite loop — a workflow
+  triggers on push, creates a commit, which triggers another push,
+  creating another commit. It's been running for 18 hours creating
+  5,000+ commits.
+
+  Task: Handle all 4 issues. For each, write: the immediate containment
+  action (what to do in the next 5 minutes), the investigation and
+  remediation steps, the root cause analysis, and the permanent fix.
+  Include: the incident communication (what to tell the security team,
+  auditors, and engineering org), and the post-incident improvements
+  to prevent all 4 types of issues.
+
+assertions:
+  - type: llm_judge
+    criteria: "Supply chain attack response is comprehensive — identifies all 25 affected repos, assesses which 8 runs were compromised, immediately pins to SHA or blocks the action, rotates all exposed secrets, and reports the compromised action to GitHub"
+    weight: 0.35
+    description: "Comprehensive supply chain response"
+  - type: llm_judge
+    criteria: "Audit finding is remediated correctly — explains that required workflows from the calling repo can be modified, the fix uses organization-level required workflows (which run the org's version, not the PR's), and the auditor is given a corrective action plan"
+    weight: 0.35
+    description: "Correct audit finding remediation"
+  - type: llm_judge
+    criteria: "Infinite loop and runner issues are resolved — the infinite loop is stopped by disabling the workflow or adding recursion prevention ([skip ci] or checking github.actor), the runner fleet recovery addresses the K8s upgrade issue, and permanent fixes prevent both recurrence"
+    weight: 0.30
+    description: "Loop and runner resolution"

package/courses/github-actions-cicd/scenarios/level-3/compliance-automation.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: compliance-automation
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Automate compliance in CI/CD — embed SOC 2, PCI DSS, and HIPAA controls into GitHub Actions workflows"
+  tags: [github, actions, compliance, SOC2, PCI-DSS, HIPAA, audit, advanced]
+
+state: {}
+
+trigger: |
+  Your fintech company processes healthcare payments (both PCI DSS and
+  HIPAA apply) and is pursuing SOC 2 Type II certification. The
+  auditors want to see that compliance controls are automated in CI/CD,
+  not just documented.
+
+  Required automated controls:
+
+  1. Change management (SOC 2 CC8.1):
+     - Every production change has an approved PR (no direct pushes)
+     - PR approval is from someone other than the author
+     - All CI checks pass before merge
+     - Deployment creates an auditable record (who, when, what, why)
+
+  2. Security testing (PCI DSS 6.5):
+     - SAST scan on every PR (CodeQL or Semgrep)
+     - Dependency vulnerability scan (Dependabot or Snyk)
+     - Secret scanning with push protection
+     - Container image scanning before deployment
+
+  3. Data protection (HIPAA):
+     - No PHI in logs (log sanitization check)
+     - Encryption verification (TLS, at-rest encryption config checks)
+     - Access audit log generation for every deployment
+
+  4. Evidence collection:
+     - All workflow runs produce compliance artifacts
+     - Artifacts are retained for 7 years (regulatory requirement)
+     - Evidence must be tamper-proof (signed, immutable)
+     - Monthly compliance report generation (automated)
+
+  Current gaps:
+  - Some repos don't have branch protection
+  - Security scans exist but are not required (can be skipped)
+  - No centralized compliance artifact storage
+  - Deployment audit logs are in plain text files, easy to modify
+
+  Task: Build the compliance automation pipeline. Write: the required
+  workflows (as organization-level required workflows), the branch
+  protection rulesets (org-wide enforcement), the security scan
+  configuration (CodeQL + Dependabot + secret scanning), the evidence
+  collection system (artifact storage, retention, signing), and the
+  monthly compliance report workflow. Include: the auditor-facing
+  documentation explaining how the automation satisfies each control.
+
+assertions:
+  - type: llm_judge
+    criteria: "Controls are automated correctly — organization-level required workflows enforce security scans on all repos, branch protection rulesets prevent self-merge and require CI, and deployment audit records are generated automatically with tamper-proof signatures"
+    weight: 0.35
+    description: "Correctly automated controls"
+  - type: llm_judge
+    criteria: "Evidence collection meets regulatory requirements — compliance artifacts are stored with 7-year retention (not default 90 days), artifacts are signed for tamper-proofing, and the monthly report aggregates compliance data across all repos"
+    weight: 0.35
+    description: "Regulatory-meeting evidence collection"
+  - type: llm_judge
+    criteria: "Auditor documentation maps controls to workflows — each SOC 2/PCI/HIPAA control has a corresponding workflow or configuration with evidence of automation, and the documentation would satisfy an auditor (not just an engineer)"
+    weight: 0.30
+    description: "Auditor-satisfying documentation"

package/courses/github-actions-cicd/scenarios/level-3/docker-action-development.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: docker-action-development
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Build custom Docker actions — create isolated, language-agnostic actions using Docker containers with proper testing and publishing"
+  tags: [github, actions, Docker, custom-actions, containers, advanced]
+
+state: {}
+
+trigger: |
+  Your security team needs 3 custom Docker-based actions for their
+  compliance pipeline. Docker actions are required (not JavaScript)
+  because they need specific CLI tools, language runtimes, and
+  isolation guarantees.
+
+  Action 1 — "compliance-scanner":
+  Purpose: Run a compliance scan against CIS benchmarks for Docker
+  images and Kubernetes manifests. Must include specific tools
+  (trivy, kubesec, conftest) that aren't available as standalone
+  actions with the versions you need.
+  Inputs: scan-type (docker/k8s), target (image name or manifest path),
+  severity-threshold (critical/high/medium), policy-dir (OPA policies)
+  Outputs: findings-count, report-path, pass/fail status
+  Requirements: Multi-stage Dockerfile, report in SARIF format,
+  integration with GitHub Security tab
+
+  Action 2 — "license-auditor":
+  Purpose: Audit all dependencies for license compliance. Must support
+  npm, pip, Go, and Java (Maven) in a single action. Uses a Python
+  script with specific libraries.
+  Inputs: package-manager, allowed-licenses (JSON array), fail-on-deny
+  Outputs: audit-report-path, denied-licenses-count
+  Requirements: Should generate a license bill of materials (BOM)
+
+  Action 3 — "secret-detector":
+  Purpose: Scan PR diffs for accidentally committed secrets using
+  custom regex patterns and entropy analysis. Runs in isolated
+  container for security (action itself handles sensitive data).
+  Inputs: custom-patterns (file path to regex list), entropy-threshold
+  Outputs: secrets-found-count, findings-path
+  Requirements: Must NOT log the actual secret values, must annotate
+  the PR with findings location
+
+  Task: Build all 3 Docker actions. For each, write: the Dockerfile
+  (multi-stage for size optimization), the entrypoint script, the
+  action.yml metadata, the test workflow (how to test a Docker action),
+  and the CI/CD for the action itself (building, testing, and publishing
+  the action). Include: the Docker caching strategy for action builds,
+  the versioning approach, and the security considerations for Docker
+  actions that handle sensitive data.
+
+assertions:
+  - type: llm_judge
+    criteria: "Dockerfiles are well-designed — uses multi-stage builds to minimize image size, includes all required tools, entrypoint scripts handle inputs from environment variables correctly, and the action.yml files have complete metadata with all inputs/outputs"
+    weight: 0.35
+    description: "Well-designed Docker actions"
+  - type: llm_judge
+    criteria: "Testing strategy is practical — includes unit tests for the scripts, integration tests using a test workflow (workflow_dispatch or push to test branch), and explains how to test Docker actions locally before publishing"
+    weight: 0.35
+    description: "Practical testing strategy"
+  - type: llm_judge
+    criteria: "Security considerations are addressed — the secret-detector doesn't log secrets, Docker actions run in isolation, the compliance-scanner SARIF output integrates with GitHub Security tab, and the versioning approach uses SHA-pinned tags"
+    weight: 0.30
+    description: "Security considerations addressed"

package/courses/github-actions-cicd/scenarios/level-3/github-environments.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: github-environments
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Configure GitHub Environments — set up deployment protection rules, approval gates, and environment-specific secrets"
+  tags: [github, actions, environments, protection-rules, deployment-gates, advanced]
+
+state: {}
+
+trigger: |
+  Your company needs a multi-environment deployment pipeline with
+  proper gates and controls. Currently, deployments go directly to
+  production with no staging or approval process.
+
+  Environment requirements:
+  1. Development (dev):
+     - Auto-deploy on every push to feature branches
+     - Ephemeral environments (one per PR, destroyed on merge)
+     - No approval required
+     - Uses development database and mock services
+
+  2. Staging:
+     - Auto-deploy on merge to main
+     - Protected: only deployable from main branch
+     - Runs smoke tests after deployment
+     - Uses staging database with anonymized production data
+     - Secrets: staging-specific AWS credentials, API keys
+
+  3. Production:
+     - Manual approval required (2 reviewers from @devops team)
+     - Deployment window: weekdays 9AM-4PM ET (no weekend deploys)
+     - Wait timer: 5-minute delay after approval (for last-minute
+       cancellation)
+     - Branch restriction: only main branch
+     - Secrets: production AWS credentials, API keys, DB connection
+     - Required: all staging smoke tests must have passed
+
+  4. Canary (subset of production):
+     - Deploy to 5% of production traffic first
+     - Monitor error rates for 15 minutes
+     - Auto-promote to full production if error rate < 0.5%
+     - Auto-rollback if error rate > 1%
+
+  Task: Configure all 4 environments. Write: the GitHub Environment
+  settings for each (protection rules, secrets, deployment branch
+  policy), the deployment workflow that uses all 4 environments in
+  sequence, the canary deployment logic (traffic splitting and
+  monitoring), and the ephemeral environment management for dev (create
+  on PR open, destroy on PR close). Include the IAM and infrastructure
+  setup needed to support environment-specific secrets.
+
+assertions:
+  - type: llm_judge
+    criteria: "GitHub Environment configuration is correct — each environment has appropriate protection rules (required reviewers for production, wait timer, branch policy), environment-specific secrets are properly scoped, and the deployment window restriction uses custom deployment protection rules"
+    weight: 0.35
+    description: "Correct environment configuration"
+  - type: llm_judge
+    criteria: "Deployment workflow uses environments correctly — references environments with 'environment:' key in each job, environment approvals pause the workflow, secrets are accessed per-environment, and the sequential flow (dev → staging → canary → production) is properly orchestrated"
+    weight: 0.35
+    description: "Correct environment workflow usage"
+  - type: llm_judge
+    criteria: "Canary and ephemeral environments are practical — canary deployment includes traffic splitting logic and monitoring-based auto-promote/rollback, ephemeral dev environments are created/destroyed via PR lifecycle events, and the infrastructure requirements are addressed"
+    weight: 0.30
+    description: "Practical canary and ephemeral environments"

package/courses/github-actions-cicd/scenarios/level-3/monorepo-ci.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: monorepo-ci
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Design monorepo CI — build efficient CI pipelines for monorepos with path filters, dynamic matrices, and selective testing"
+  tags: [github, actions, monorepo, path-filters, dynamic-matrix, turborepo, advanced]
+
+state: {}
+
+trigger: |
+  Your company migrated 8 microservices into a Turborepo monorepo.
+  The current CI runs ALL tests for every PR, taking 35 minutes and
+  costing $800/month unnecessarily. You need to make CI smart enough
+  to only test what changed.
+
+  Monorepo structure:
+  ```
+  /
+  ├── apps/
+  │   ├── web/          (React, 12,000 lines)
+  │   ├── api/          (Express, 8,000 lines)
+  │   ├── mobile/       (React Native, 10,000 lines)
+  │   └── admin/        (Next.js, 5,000 lines)
+  ├── packages/
+  │   ├── ui/           (Shared components, used by web + mobile + admin)
+  │   ├── auth/         (Auth library, used by api + web + admin)
+  │   ├── database/     (Prisma client, used by api + admin)
+  │   └── config/       (Shared config, used by all)
+  ├── turbo.json
+  └── package.json
+  ```
+
+  Dependency graph:
+  - web depends on: ui, auth, config
+  - api depends on: auth, database, config
+  - mobile depends on: ui, auth, config
+  - admin depends on: ui, auth, database, config
+
+  Requirements:
+  1. Only run tests for changed packages and their dependents
+  2. If packages/auth changes, test web, api, mobile, and admin
+  3. If apps/web changes, only test web
+  4. If packages/config changes, test everything (affects all)
+  5. Generate the test matrix dynamically based on affected packages
+  6. Run Turborepo's --filter for selective builds
+  7. Cache Turborepo's .turbo directory across workflow runs
+
+  Task: Write the monorepo CI workflow. Include: the change detection
+  job (determines which packages are affected), the dynamic matrix
+  generation (creates a matrix from affected packages), the selective
+  test execution (only tests affected packages), the Turborepo
+  integration (using --filter and caching), and the deployment trigger
+  logic (deploy web only if web or its dependencies changed).
+
+assertions:
+  - type: llm_judge
+    criteria: "Change detection correctly identifies affected packages — uses git diff with path matching, understands the dependency graph (changing auth affects all consumers), and handles the transitive dependency case (config affects everything)"
+    weight: 0.35
+    description: "Correct change detection"
+  - type: llm_judge
+    criteria: "Dynamic matrix is properly generated — the detection job outputs a JSON array of affected packages, the test job uses fromJson() to create a dynamic matrix, and the matrix correctly handles the case where no packages are affected (skips testing)"
+    weight: 0.35
+    description: "Proper dynamic matrix generation"
+  - type: llm_judge
+    criteria: "Turborepo integration is correct — uses turbo run test --filter with correct syntax, caches .turbo directory between runs, and the cost savings are estimated (from 35 minutes for all packages to X minutes for affected only)"
+    weight: 0.30
+    description: "Correct Turborepo integration"

package/courses/github-actions-cicd/scenarios/level-3/oidc-cloud-deployments.yaml

@@ -0,0 +1,55 @@
+meta:
+  id: oidc-cloud-deployments
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Deploy with OIDC — configure keyless authentication to AWS, GCP, and Azure using GitHub Actions OIDC tokens"
+  tags: [github, actions, OIDC, AWS, GCP, Azure, cloud-auth, advanced]
+
+state: {}
+
+trigger: |
+  Your company deploys to all 3 major cloud providers and currently
+  uses long-lived credentials stored as GitHub Secrets. The security
+  team mandates a migration to OIDC (keyless authentication) within
+  30 days. No more static credentials in GitHub Secrets.
+
+  Current setup (to be replaced):
+  - AWS: IAM user access key + secret key in GitHub Secrets
+  - GCP: Service account key JSON file in GitHub Secrets
+  - Azure: Service principal client ID + secret in GitHub Secrets
+
+  Deployment targets:
+  - AWS: ECS (API), S3 + CloudFront (frontend), Lambda (serverless)
+  - GCP: Cloud Run (microservices), GCS (static assets)
+  - Azure: AKS (Kubernetes), Azure Functions (serverless)
+
+  Requirements:
+  - Each cloud provider should only trust tokens from specific repos
+  - Production deployments should only be allowed from the main branch
+  - Staging deployments should be allowed from any branch
+  - Each cloud role should have minimum required permissions
+  - The OIDC configuration should work with GitHub Environments
+
+  Task: Configure OIDC for all 3 cloud providers. For each, write:
+  the identity provider setup (cloud-side configuration), the trust
+  policy (limiting which repos/branches can assume the role), the
+  IAM role with minimum permissions, the workflow changes (replacing
+  static credentials with OIDC), and the testing/verification steps.
+  Include: a comparison of OIDC across the 3 providers, the common
+  pitfalls, and the migration checklist for removing old static
+  credentials safely.
+
+assertions:
+  - type: llm_judge
+    criteria: "AWS OIDC is correctly configured — IAM OIDC provider with GitHub's thumbprint, IAM role trust policy with conditions on repo and branch (sub claim), workflow uses aws-actions/configure-aws-credentials with role-to-assume and no static credentials"
+    weight: 0.35
+    description: "Correct AWS OIDC configuration"
+  - type: llm_judge
+    criteria: "GCP and Azure OIDC are also configured — GCP uses Workload Identity Federation with correct attribute mapping, Azure uses federated credentials on the app registration, and both have branch-restricted trust policies matching the AWS pattern"
+    weight: 0.35
+    description: "Complete multi-cloud OIDC"
+  - type: llm_judge
+    criteria: "Migration plan is safe — includes a parallel-running period (both OIDC and static credentials work), verification steps before removing static credentials, rollback plan if OIDC fails, and the credential rotation/deletion checklist"
+    weight: 0.30
+    description: "Safe migration plan"

package/courses/github-actions-cicd/scenarios/level-3/release-automation.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: release-automation
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Automate releases — build semantic versioning, changelog generation, and GitHub Release workflows"
+  tags: [github, actions, releases, semantic-versioning, changelog, automation, advanced]
+
+state: {}
+
+trigger: |
+  Your team currently releases manually: someone bumps the version in
+  package.json, writes a changelog entry, creates a git tag, builds
+  the artifacts, and creates a GitHub Release. This takes 45 minutes
+  and has caused errors (wrong version, missing changelog entries,
+  forgotten tags). You need to fully automate the release process.
+
+  Requirements:
+  1. Semantic versioning based on commit messages:
+     - feat: → minor bump (1.2.0 → 1.3.0)
+     - fix: → patch bump (1.2.0 → 1.2.1)
+     - BREAKING CHANGE: → major bump (1.2.0 → 2.0.0)
+     - Use conventional commits to determine version bump
+
+  2. Automated changelog generation:
+     - Generate from conventional commits since last release
+     - Group by type: Features, Bug Fixes, Breaking Changes
+     - Include PR links and author attributions
+     - Update CHANGELOG.md in the repo
+
+  3. Release artifacts:
+     - Build production bundles (frontend + backend)
+     - Generate Docker images tagged with version
+     - Create source code archives (zip + tar.gz)
+     - Sign artifacts with cosign/sigstore
+
+  4. Release workflow triggers:
+     - Option A: Automatically release on merge to main (CD)
+     - Option B: Manual trigger with version override
+     - Option C: Release PR workflow (create a "release PR" that
+       shows the changelog for review before publishing)
+
+  Task: Implement all 3 release workflow options. For each, write: the
+  complete workflow YAML, the tooling configuration (semantic-release,
+  release-please, or changesets — compare all 3), the changelog format
+  and generation logic, and the artifact signing configuration. Recommend
+  which option works best for different team sizes and release cadences.
+
+assertions:
+  - type: llm_judge
+    criteria: "Semantic versioning is correctly automated — conventional commits are parsed, version bumps follow semver rules, package.json version is updated, git tag is created, and BREAKING CHANGE triggers a major bump correctly"
+    weight: 0.35
+    description: "Correct semantic versioning automation"
+  - type: llm_judge
+    criteria: "Tool comparison is informative — compares semantic-release, release-please, and changesets on features, complexity, customization, and team fit. Makes a clear recommendation for different scenarios (OSS vs enterprise, mono vs multi-repo)"
+    weight: 0.35
+    description: "Informative tool comparison"
+  - type: llm_judge
+    criteria: "All 3 workflow options are implemented — automatic CD, manual trigger with override, and release PR workflow are all provided with complete YAML, and the recommendation explains when each is appropriate"
+    weight: 0.30
+    description: "All release workflow options"