dojo.md 0.1.0 → 0.2.0

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"

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

@@ -0,0 +1,63 @@
+meta:
+  id: security-hardening
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Harden GitHub Actions security — prevent supply chain attacks, pin actions by SHA, implement OIDC, and secure workflows"
+  tags: [github, actions, security, supply-chain, OIDC, hardening, advanced]
+
+state: {}
+
+trigger: |
+  Your security team conducted an audit of your GitHub Actions setup
+  and found critical vulnerabilities. You need to remediate all findings
+  and implement a security hardening plan.
+
+  Audit findings:
+
+  Finding 1 — Supply chain risk (Critical):
+  All 45 third-party actions are referenced by tag (e.g., @v4) not by
+  SHA. A compromised action tag could execute malicious code in your
+  CI. Example: `uses: some-popular-action/upload@v3` — if that
+  maintainer's account is compromised, v3 could be overwritten.
+
+  Finding 2 — Overly permissive GITHUB_TOKEN (High):
+  All workflows run with default GITHUB_TOKEN permissions (read+write
+  on all scopes). Most workflows only need read access to contents
+  and write access to pull-requests.
+
+  Finding 3 — Fork PR vulnerability (High):
+  Workflows triggered by pull_request_target have access to secrets
+  and run in the context of the base branch. A malicious fork could
+  submit a PR that exfiltrates secrets.
+
+  Finding 4 — No OIDC authentication (Medium):
+  AWS deployments use long-lived access keys stored as GitHub Secrets.
+  These keys never rotate and would be exposed if a workflow is
+  compromised. Should use OIDC for keyless authentication.
+
+  Finding 5 — Script injection (Medium):
+  Several workflows use github.event.pull_request.title directly in
+  run: commands. A PR title containing backticks or $() could execute
+  arbitrary commands.
+
+  Task: Remediate all 5 findings. For each, write: the vulnerability
+  explanation (how it could be exploited), the remediation (specific
+  YAML changes), the verification steps (how to confirm the fix works),
+  and the ongoing prevention strategy. Include: the complete OIDC setup
+  for AWS (IAM role, trust policy, workflow changes), the GITHUB_TOKEN
+  permission lockdown, and a security checklist for all future workflows.
+
+assertions:
+  - type: llm_judge
+    criteria: "All 5 vulnerabilities are remediated correctly — actions pinned by full SHA, GITHUB_TOKEN permissions restricted with permissions: key at workflow and job level, pull_request_target secured against fork attacks, OIDC configured for AWS, and script injection prevented with environment variables"
+    weight: 0.35
+    description: "Correct vulnerability remediation"
+  - type: llm_judge
+    criteria: "OIDC setup is complete — includes the AWS IAM OIDC identity provider, the IAM role trust policy with correct GitHub conditions (repo, branch, environment), the workflow changes to use aws-actions/configure-aws-credentials with OIDC, and explains why this is more secure than static keys"
+    weight: 0.35
+    description: "Complete OIDC setup"
+  - type: llm_judge
+    criteria: "Security checklist is actionable — covers at least 10 security practices for GitHub Actions, is formatted as a PR review checklist, and includes automated enforcement options (e.g., CodeQL for workflow scanning, required workflow for org-wide security policy)"
+    weight: 0.30
+    description: "Actionable security checklist"

package/courses/github-actions-cicd/scenarios/level-3/self-hosted-runners.yaml

@@ -0,0 +1,60 @@
+meta:
+  id: self-hosted-runners
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Manage self-hosted runners — set up, secure, scale, and maintain self-hosted runner infrastructure for GitHub Actions"
+  tags: [github, actions, self-hosted-runners, infrastructure, scaling, advanced]
+
+state: {}
+
+trigger: |
+  Your company is migrating from GitHub-hosted to self-hosted runners
+  for 3 reasons: cost reduction (spending $15K/month on GitHub runners),
+  specialized hardware needs (GPU for ML model testing), and compliance
+  requirements (code must not leave your network).
+
+  Infrastructure requirements:
+  - 80 engineers, 300 workflow runs per day
+  - Peak: 50 concurrent jobs during 10AM-2PM
+  - Job types: CI (80%), deployment (15%), ML training (5%)
+  - Runner OS: Linux (90%), macOS (10% for iOS builds)
+  - Security: runners must be ephemeral (clean state per job)
+  - Network: runners need access to internal services but not
+    unrestricted internet access
+
+  Architecture options to evaluate:
+  1. Bare metal servers in your data center
+  2. VMs on existing VMware infrastructure
+  3. Kubernetes with actions-runner-controller (ARC)
+  4. Auto-scaled cloud VMs (AWS EC2 with runner auto-scaler)
+
+  Security concerns:
+  - How to prevent a malicious workflow from compromising the runner
+  - How to handle secrets on self-hosted runners
+  - How to ensure runners are patched and updated
+  - How to isolate runners between teams/repos
+  - How to prevent crypto mining on organization runners
+
+  Task: Design the self-hosted runner infrastructure. Write: the
+  architecture recommendation (which option and why), the runner
+  configuration (labels, groups, scaling policies), the security
+  hardening guide (ephemeral runners, network isolation, secret
+  handling), the monitoring and alerting setup (runner health, queue
+  depth, job wait times), and the cost comparison (self-hosted vs
+  GitHub-hosted for your usage). Include the runner registration
+  automation and the disaster recovery plan.
+
+assertions:
+  - type: llm_judge
+    criteria: "Architecture recommendation is well-reasoned — evaluates all 4 options with pros/cons for the specific requirements, likely recommends ARC or cloud auto-scaling for ephemeral runners, and addresses GPU needs for ML jobs separately from general CI"
+    weight: 0.35
+    description: "Well-reasoned architecture"
+  - type: llm_judge
+    criteria: "Security hardening is comprehensive — covers ephemeral runners (clean state per job), network isolation (firewall rules, no internet for sensitive repos), runner groups for team isolation, automatic patching, and protection against malicious workflows"
+    weight: 0.35
+    description: "Comprehensive security hardening"
+  - type: llm_judge
+    criteria: "Cost comparison is data-driven — calculates the total cost of self-hosted (hardware, maintenance, networking, engineer time) vs GitHub-hosted ($15K/month), identifies the break-even point, and the monitoring setup tracks runner utilization to optimize costs"
+    weight: 0.30
+    description: "Data-driven cost comparison"

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

@@ -0,0 +1,59 @@
+meta:
+  id: workflow-optimization
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Optimize workflow performance — reduce CI time from 30 to 10 minutes using parallelism, caching, and smart architecture"
+  tags: [github, actions, optimization, parallelism, performance, advanced]
+
+state: {}
+
+trigger: |
+  Your team's main CI workflow takes 30 minutes to complete. This is
+  the #1 developer experience complaint. The CTO wants it under 10
+  minutes. Here's the current workflow and timing breakdown:
+
+  Current workflow (sequential):
+  ```
+  checkout (30s) → install (3min) → lint (2min) → typecheck (3min) →
+  unit-tests (8min) → integration-tests (6min) → e2e-tests (5min) →
+  build (2min) → docker-build (1.5min) = 31 minutes total
+  ```
+
+  Additional data:
+  - Unit tests: 1,200 tests in 45 test files
+  - Integration tests: 80 tests requiring PostgreSQL + Redis
+  - E2E tests: 30 Cypress tests requiring a running dev server
+  - Build output: 12MB frontend bundle + Docker image
+  - Cache hit rate: 60% (should be 95%+)
+  - Runner: ubuntu-latest (2 CPU, 7GB RAM)
+
+  Optimization budget:
+  - Can split into multiple parallel jobs
+  - Can use larger runners (4 CPU, 16GB RAM) — 2x cost but 2x faster
+  - Can use test sharding (split tests across parallel workers)
+  - Can use remote caching (Turborepo remote cache or similar)
+  - Can restructure tests (some unit tests may actually be integration)
+
+  Task: Redesign the workflow for sub-10-minute completion. Write: the
+  optimized workflow YAML with parallel jobs, the test sharding
+  configuration (split unit tests across N workers), the caching
+  strategy (to achieve 95%+ hit rate), the runner sizing analysis
+  (standard vs larger runners — cost vs speed trade-off), and the
+  before/after comparison (timeline diagram showing parallel execution
+  vs sequential). Explain each optimization technique and its expected
+  impact.
+
+assertions:
+  - type: llm_judge
+    criteria: "Workflow is redesigned for parallelism — lint, typecheck, and unit tests run in parallel (not sequential), e2e tests use sharding across multiple runners, and the critical path is identified and optimized to under 10 minutes"
+    weight: 0.35
+    description: "Parallel workflow redesign"
+  - type: llm_judge
+    criteria: "Test sharding is correctly implemented — unit tests split across N parallel workers using matrix strategy with test file distribution, integration tests use proper service containers, and e2e tests are sharded with Cypress's parallelization"
+    weight: 0.35
+    description: "Correct test sharding"
+  - type: llm_judge
+    criteria: "Before/after comparison is clear — shows the timeline diagram (text-based) of sequential vs parallel execution, quantifies each optimization's contribution, and the cost analysis compares standard vs larger runners at the new parallel configuration"
+    weight: 0.30
+    description: "Clear before/after comparison"

package/courses/github-actions-cicd/scenarios/level-4/cicd-data-architecture.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: cicd-data-architecture
+  level: 4
+  course: github-actions-cicd
+  type: output
+  description: "Design CI/CD data architecture — build analytics pipelines for workflow metrics, cost tracking, and predictive insights"
+  tags: [github, actions, data-architecture, analytics, metrics, DORA, expert]
+
+state: {}
+
+trigger: |
+  You're the Head of Data Engineering building the data infrastructure
+  for CI/CD analytics. The platform team needs data to track DORA
+  metrics, optimize costs, and predict failures. Currently there's no
+  centralized CI/CD data — metrics are scattered across GitHub API
+  responses, runner logs, and deployment systems.
+
+  Data sources:
+  - GitHub Actions API: Workflow runs, job details, step timings, costs
+  - GitHub webhooks: Real-time workflow events (50,000+ events/day)
+  - Self-hosted runner metrics: CPU, memory, queue depth (Prometheus)
+  - Cloud provider APIs: Deployment status, resource costs
+  - Incident management: PagerDuty alerts, incident timelines
+  - Git data: Commit frequency, PR merge times, branch patterns
+
+  Analytics requirements:
+  1. DORA metrics dashboard (deployment frequency, lead time, MTTR,
+     change failure rate) — real-time, per team, trending
+  2. Cost analytics (per-team, per-repo, per-workflow cost allocation
+     with budget alerts)
+  3. Failure prediction (ML model to predict which PRs will have CI
+     failures based on files changed, time of day, author history)
+  4. Performance trending (workflow duration trends, bottleneck
+     detection, runner utilization optimization)
+  5. Compliance reporting (automated evidence for SOC 2 audits)
+
+  Constraints:
+  - Budget: $100K/year for data infrastructure
+  - Must handle 50K+ events/day without data loss
+  - DORA dashboard must update within 5 minutes of events
+  - Cost data must be accurate to within $1 per team per month
+  - 2-year data retention for compliance
+
+  Task: Design the CI/CD data architecture. Write: the data model
+  (entities, relationships, derived metrics), the ingestion pipeline
+  (webhook processing, API polling, stream processing), the storage
+  strategy (time-series for metrics, OLAP for analytics, feature store
+  for ML), the DORA metrics computation logic, and the ML pipeline for
+  failure prediction. Include the cost breakdown for the $100K budget.
+
+assertions:
+  - type: llm_judge
+    criteria: "DORA metrics computation is correct — deployment frequency counts production deploys per day, lead time measures commit-to-deploy, MTTR measures incident-open-to-resolved, change failure rate is failed-deploys/total-deploys, and all are computed per-team with correct time windows"
+    weight: 0.35
+    description: "Correct DORA metrics computation"
+  - type: llm_judge
+    criteria: "Architecture fits the $100K budget — uses cost-effective technologies (not enterprise tools), handles 50K+ events/day reliably, and the cost breakdown accounts for compute, storage, and data transfer across all components"
+    weight: 0.35
+    description: "Budget-fitting architecture"
+  - type: llm_judge
+    criteria: "ML failure prediction is practical — identifies useful features (files changed, test history, time of day, PR size, author failure rate), proposes a reasonable model (not over-engineered), and the feature store design supports both batch training and real-time inference"
+    weight: 0.30
+    description: "Practical ML failure prediction"

package/courses/github-actions-cicd/scenarios/level-4/cicd-economics-roi.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: cicd-economics-roi
+  level: 4
+  course: github-actions-cicd
+  type: output
+  description: "Analyze CI/CD economics — calculate the true cost, model ROI, and present the business case for CI/CD investment"
+  tags: [github, actions, economics, ROI, cost-analysis, business-case, expert]
+
+state: {}
+
+trigger: |
+  You're the Director of Engineering presenting a business case to the
+  CFO for a $2M CI/CD platform investment. The CFO asks: "We spend
+  $1.2M/year on GitHub Actions already. Why invest more?"
+
+  Current CI/CD costs:
+  - GitHub Actions: $1.2M/year (minutes + storage)
+  - Self-hosted runners: $300K/year (infrastructure + maintenance)
+  - Engineering time on CI/CD: 3 FTEs dedicated ($600K/year)
+  - Time lost to CI failures: estimated 2 hours/week per developer
+  - Total: ~$2.1M/year visible costs
+
+  Hidden costs (to calculate):
+  - Developer waiting time: 800 engineers × avg 20 min/day waiting
+    for CI = ? hours/year at $85/hour fully loaded
+  - Failed deployments: 12/quarter, avg 4 hours to fix, 3 engineers
+  - Rollbacks: 8/quarter, avg 2 hours, 2 engineers
+  - Context switching: developers context-switch while waiting for
+    30-minute CI runs
+
+  Proposed investment ($2M over 2 years):
+  1. CI/CD platform team: 5 FTEs ($1M/year)
+  2. Self-hosted runner infrastructure upgrade: $400K
+  3. Tooling and automation: $200K
+  4. Training program: $100K
+
+  Expected outcomes:
+  - Reduce average CI time from 25 min to 8 min
+  - Reduce deployment failures from 12/quarter to 2/quarter
+  - Eliminate 80% of developer CI wait time
+  - Standardize deployment across all 200 repos
+
+  Task: Build the complete economic model. Write: the true cost of
+  the current state (including all hidden costs), the investment
+  analysis for the proposed $2M (expected returns, payback period,
+  NPV), the risk-adjusted projection (what if improvements are only
+  50% of target), the DORA metrics improvement forecast (deployment
+  frequency, lead time, MTTR, change failure rate), and the 2-page
+  executive summary for the CFO. Include a sensitivity analysis.
+
+assertions:
+  - type: llm_judge
+    criteria: "Hidden costs are calculated — developer wait time is quantified (800 engineers × 20 min/day × 250 days × $85/hour), deployment failure costs are summed, and the total true cost is significantly higher than the visible $2.1M"
+    weight: 0.35
+    description: "Calculated hidden costs"
+  - type: llm_judge
+    criteria: "Investment analysis is rigorous — includes NPV with appropriate discount rate, payback period calculation, sensitivity analysis (best/expected/worst case), and the risk-adjusted projection shows the investment is worthwhile even at 50% of expected improvements"
+    weight: 0.35
+    description: "Rigorous investment analysis"
+  - type: llm_judge
+    criteria: "Executive summary is CFO-ready — leads with business impact (not technical details), presents the 'do nothing' cost, shows clear ROI, includes DORA metrics improvement as industry-standard benchmarks, and fits in 2 pages"
+    weight: 0.30
+    description: "CFO-ready executive summary"

package/courses/github-actions-cicd/scenarios/level-4/cicd-executive-communication.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: cicd-executive-communication
+  level: 4
+  course: github-actions-cicd
+  type: output
+  description: "Executive communication about CI/CD — present platform health, investment needs, and strategic roadmap to C-suite audiences"
+  tags: [github, actions, executive, communication, strategy, DORA-metrics, expert]
+
+state: {}
+
+trigger: |
+  You're the CTO preparing 3 executive communications about CI/CD
+  platform strategy. Each audience has different concerns.
+
+  Communication 1 — Board of Directors quarterly update:
+  The board wants to understand "engineering velocity" as a competitive
+  metric. Your DORA metrics data:
+  - Deployment frequency: 45/day (up from 8/day last year)
+  - Lead time for changes: 2.3 hours (down from 5 days)
+  - Mean time to recovery: 18 minutes (down from 4 hours)
+  - Change failure rate: 2.1% (down from 12%)
+  All metrics are now in the "Elite" DORA category. The board asks:
+  "How does this compare to competitors and how does it impact revenue?"
+
+  Communication 2 — CFO budget review:
+  CI/CD costs increased 300% year-over-year ($400K → $1.6M) due to
+  growth from 100 to 500 engineers. The CFO wants to understand: is
+  this scaling linearly (bad) or sublinearly (good)? What's the cost
+  per deployment? How does the investment in the platform team ($3M)
+  pay back? And should the company consider moving from GitHub Actions
+  to a cheaper alternative?
+
+  Communication 3 — All-engineering town hall:
+  You're presenting the CI/CD platform roadmap for the next year. The
+  audience includes engineers frustrated with current CI speed ("builds
+  take 30 minutes"), teams that want more deployment autonomy ("why
+  do we need the platform team's approval to change our pipeline"),
+  and security engineers who want stricter controls.
+
+  Task: Write all 3 communications. For each: adapt the message to
+  the audience, use data effectively, include specific asks or next
+  steps, and anticipate tough questions. The board update should be
+  1 page, the CFO review should include financial models, and the
+  town hall should be an engaging presentation outline.
+
+assertions:
+  - type: llm_judge
+    criteria: "Board communication connects DORA metrics to business value — translates elite DORA metrics into competitive advantage (faster time-to-market, lower outage costs, higher engineering productivity), with industry benchmarks for context"
+    weight: 0.35
+    description: "Business-value board communication"
+  - type: llm_judge
+    criteria: "CFO review has solid financial analysis — shows cost-per-deployment trend (should be declining despite total cost increase), demonstrates sublinear cost scaling per engineer, and makes a data-driven case against switching platforms (migration cost vs savings)"
+    weight: 0.35
+    description: "Financial CFO review"
+  - type: llm_judge
+    criteria: "Town hall addresses all audience segments — acknowledges the 30-minute build frustration with a specific improvement plan, explains the balance between autonomy and governance, and gives security engineers confidence in the compliance roadmap"
+    weight: 0.30
+    description: "Multi-audience town hall"