dojo.md 0.1.0 → 0.2.1

package/courses/docker-container-debugging/scenarios/level-5/master-debugging-shift.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: master-debugging-shift
+  level: 5
+  course: docker-container-debugging
+  type: output
+  description: "Combined master debugging shift — serve as fractional CTO advising on a complete container platform strategy encompassing technology, people, process, and business alignment"
+  tags: [Docker, troubleshooting, combined, shift-simulation, CTO, master]
+
+state: {}
+
+trigger: |
+  You're engaged as a fractional CTO for a Series B startup ($30M
+  raised, 80 engineers, growing to 200). They've been running on
+  Docker Compose across 5 servers for 2 years. Growing pains are
+  severe:
+
+  Technical challenges:
+  - 40 microservices on Docker Compose, manual deployment
+  - Last week: wrong image tag deployed, 3-hour outage ($150K impact)
+  - No security scanning — audit found 12 CRITICAL CVEs in production
+  - Database containers without proper backup — near-miss data loss
+  - Developers wait 30+ minutes for CI builds (no caching)
+  - No centralized logging — debugging requires SSH to 5 servers
+
+  People challenges:
+  - 2-person DevOps team overwhelmed (they're firefighting 80% of time)
+  - Developers have no container training, copy-paste Dockerfiles
+  - No on-call rotation — same 2 DevOps engineers handle everything
+  - Engineering velocity declining as team grows
+
+  Business context:
+  - Series C fundraising in 9 months — need to demonstrate scalability
+  - Enterprise customer prospects require SOC2 compliance
+  - Planning international expansion (EU data residency requirements)
+  - Board expects 99.95% availability SLA for enterprise tier
+
+  Budget: $500K for platform investment over next 12 months
+  Hiring: Can add 3-4 people
+
+  The CEO asks: "Give me a 12-month roadmap that gets us to Series C
+  ready. We need to stop firefighting and start scaling."
+
+  Task: Design the comprehensive 12-month roadmap. Write: the phased
+  approach (stabilize → automate → scale → optimize), technology
+  decisions (stay on Compose? Move to K8s? Use managed services?),
+  hiring plan (who to hire first and why), SOC2 compliance path,
+  cost breakdown and ROI, risk register with mitigations, and the
+  key milestones that demonstrate investor readiness.
+
+assertions:
+  - type: llm_judge
+    criteria: "Phased roadmap is realistic — Month 1-3 (Stabilize): fix critical security CVEs, implement image scanning in CI, set up proper database backups, add health checks, configure log rotation, basic monitoring (Prometheus + Grafana). Month 4-6 (Automate): CI/CD pipeline with automated build/scan/deploy, move to managed Kubernetes (EKS/GKE), centralized logging, on-call rotation. Month 7-9 (Scale): SOC2 controls implementation, multi-region readiness, developer self-service platform. Month 10-12 (Optimize): cost optimization, performance tuning, DR testing, compliance audit. Each phase builds on the previous"
+    weight: 0.35
+    description: "Phased roadmap"
+  - type: llm_judge
+    criteria: "Technology and hiring decisions are justified — recommend managed Kubernetes over Compose for 40+ services (Compose doesn't scale operationally). Managed K8s (EKS/GKE) over self-hosted (team too small to manage control plane). Hiring priority: (1) senior platform engineer (lead the migration), (2) security engineer (SOC2 + scanning), (3) SRE (on-call, monitoring, incident response), (4) DevOps engineer (CI/CD, automation). This relieves the existing 2-person team and adds specialization. Budget allocation: $200K tooling, $300K hiring (partial year)"
+    weight: 0.35
+    description: "Technology and hiring"
+  - type: llm_judge
+    criteria: "Investor readiness and compliance are addressed — SOC2 Type I achievable in 6-9 months (show controls exist), Type II requires 6+ months of evidence (start collecting immediately). Key investor metrics: 99.95% availability (track from month 3), deployment frequency (daily by month 6), MTTR < 30 minutes, security posture (0 CRITICAL CVEs). EU expansion: GDPR compliance, data residency (EU region deployment). Present to board quarterly: progress against milestones, risk reduction, cost efficiency. Risk register: migration timeline slippage (mitigate: phased approach), hiring delays (mitigate: start immediately), scope creep (mitigate: strict prioritization)"
+    weight: 0.30
+    description: "Investor readiness"

package/courses/docker-container-debugging/scenarios/level-5/organizational-transformation.yaml

@@ -0,0 +1,67 @@
+meta:
+  id: organizational-transformation
+  level: 5
+  course: docker-container-debugging
+  type: output
+  description: "Lead organizational transformation through containerization — manage cultural change, team restructuring, and DevOps transformation alongside container adoption"
+  tags: [Docker, organizational-change, DevOps, culture, transformation, leadership, master]
+
+state: {}
+
+trigger: |
+  You're leading container adoption at a 5,000-person enterprise.
+  The technology is ready but the organization isn't. Three months
+  into the initiative, adoption is stalling:
+
+  Resistance patterns observed:
+
+  Operations team (50 people):
+  "Containers are a fad. We've managed VMs for 15 years. Why change?"
+  Fear: automation will eliminate their jobs.
+  Reality: need to transform from VM operators to platform engineers.
+
+  Development teams (200 people across 30 teams):
+  Only 4 teams have adopted containers. Others: "We're too busy
+  delivering features to learn new deployment tools."
+  Fear: containers add complexity to their already-complex workflow.
+  Reality: containers simplify deployment once learned.
+
+  Security team (10 people):
+  "Containers increase our attack surface. We can't audit them."
+  Fear: loss of visibility and control.
+  Reality: containers can improve security posture with proper tooling.
+
+  Management:
+  CTO sponsors the initiative but middle managers are neutral.
+  Project managers: "Container migration isn't in our roadmap."
+  No incentives aligned with container adoption.
+
+  Change management strategy needed:
+
+  1. Create urgency — show real costs of current approach
+  2. Build a coalition — identify champions in each group
+  3. Quick wins — solve real pain points first
+  4. Enablement — training, documentation, support
+  5. Incentive alignment — tie container adoption to OKRs
+  6. Celebrate success — publicize wins, recognize adopters
+  7. Sustain — embed in hiring, onboarding, promotion criteria
+
+  Task: Design the organizational transformation strategy. Write:
+  the change management framework, addressing each stakeholder
+  group's concerns, training and enablement program, metrics for
+  transformation progress, common transformation failure modes,
+  and the role of leadership in driving technology adoption.
+
+assertions:
+  - type: llm_judge
+    criteria: "Change management framework is structured — use Kotter's 8-step model or similar: create urgency (show competitor advantage, calculate cost of status quo), build coalition (executive sponsor + tech leads from willing teams + operations champion), quick wins (solve a visible pain point in 30 days), scale (expand from pilot teams to adjacent teams). Transformation timeline: 12-18 months for meaningful adoption, 3-5 years for full organizational shift. Don't announce a 'container mandate' — enable and incentivize instead"
+    weight: 0.35
+    description: "Change framework"
+  - type: llm_judge
+    criteria: "Stakeholder-specific strategies are empathetic — operations: retrain as platform engineers (higher-value role, not elimination), pair with developers, give ownership of the container platform. Developers: provide golden paths (make containers easier than current approach), don't ask teams to stop feature work — integrate container adoption into existing projects. Security: give better tools (runtime monitoring, automated scanning gives more visibility than VMs), involve in platform design. Management: show metrics (deployment speed, incident reduction), align with business OKRs"
+    weight: 0.35
+    description: "Stakeholder strategies"
+  - type: llm_judge
+    criteria: "Failure modes and measurement are realistic — common failures: mandating adoption without enablement, moving too fast (teams overwhelmed), moving too slow (initiative loses momentum), not investing in platform team (adoption stalls without support), not celebrating wins (no positive reinforcement). Measure: adoption rate (% services containerized), developer satisfaction (NPS), deployment frequency per team, time to onboard new service, support ticket volume for container issues. Transformation is a people problem, not a technology problem — treat it accordingly"
+    weight: 0.30
+    description: "Failures and measurement"

package/courses/docker-container-debugging/scenarios/level-5/regulatory-compliance-containers.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: regulatory-compliance-containers
+  level: 5
+  course: docker-container-debugging
+  type: output
+  description: "Design regulatory compliance for containers — implement controls for SOC2, PCI-DSS, HIPAA, and FedRAMP in containerized environments"
+  tags: [Docker, compliance, SOC2, PCI-DSS, HIPAA, FedRAMP, regulation, master]
+
+state: {}
+
+trigger: |
+  Your company is pursuing SOC2 Type II certification and PCI-DSS
+  compliance. The auditor has questions about your container platform:
+
+  Auditor question 1: "How do you ensure only authorized images
+  run in production?"
+  Current answer: "We trust our developers." (Not acceptable)
+  Required: Image signing, admission control, approved registry list.
+
+  Auditor question 2: "How do you track who deployed what and when?"
+  Current answer: "We can check git history." (Insufficient)
+  Required: Immutable audit logs of all deployment actions with
+  identity, timestamp, image digest, and approval chain.
+
+  Auditor question 3: "How do you ensure containers don't contain
+  known vulnerabilities?"
+  Current answer: "We scan periodically." (When? How? What's the SLA?)
+  Required: Automated scanning in CI/CD with defined severity thresholds,
+  documented exception process, SLA for patching (CRITICAL: 24h,
+  HIGH: 7d, MEDIUM: 30d).
+
+  Auditor question 4: "How do you isolate cardholder data environments?"
+  Current answer: "Different Docker network." (Insufficient for PCI)
+  Required: Network segmentation with documented firewall rules,
+  encrypted communication (mTLS), access logging, separate
+  infrastructure for CDE.
+
+  Auditor question 5: "How do you handle secrets and encryption keys?"
+  Current answer: "Environment variables in Docker Compose."
+  Required: Dedicated secrets manager (Vault), encryption at rest,
+  rotation policy, access auditing.
+
+  Task: Design compliance controls for containerized environments.
+  Write: control mappings for SOC2 and PCI-DSS, image governance
+  (signing, scanning, admission), audit logging architecture,
+  network segmentation for compliance, secrets management, and the
+  continuous compliance monitoring approach.
+
+assertions:
+  - type: llm_judge
+    criteria: "Control mappings are specific — SOC2: CC6.1 (logical access) → RBAC, namespace isolation, registry access control. CC7.1 (monitoring) → container runtime monitoring, audit logs. CC8.1 (change management) → GitOps, immutable images, deployment approvals. PCI-DSS: Requirement 2 (secure configuration) → hardened container images, CIS benchmarks. Requirement 6 (secure development) → image scanning in CI. Requirement 10 (logging) → centralized audit logs with tamper protection. Requirement 11 (testing) → regular vulnerability scanning"
+    weight: 0.35
+    description: "Control mappings"
+  - type: llm_judge
+    criteria: "Image governance and audit are covered — image lifecycle: build → scan → sign → approve → deploy. Admission controller (OPA/Kyverno) rejects unsigned or unscanned images. Approved registry allowlist prevents pulling from public registries. Audit logging: every docker/kubectl command logged with identity (who), action (what), resource (which container/image), timestamp (when), result (success/fail). Logs must be immutable (append-only, shipped to SIEM). Retention: 1 year minimum for SOC2, as defined by PCI-DSS"
+    weight: 0.35
+    description: "Governance and audit"
+  - type: llm_judge
+    criteria: "Network and secrets compliance are practical — PCI CDE isolation: separate cluster or namespace with strict network policies. mTLS between all services in CDE (service mesh). No direct internet access from CDE containers. Secrets: HashiCorp Vault or cloud KMS, automatic rotation, access auditing, encryption at rest. Never in environment variables, Docker Compose files, or image layers. Continuous compliance: automated scanning against CIS Docker Benchmark, regular penetration testing, compliance dashboards for auditors, automated evidence collection"
+    weight: 0.30
+    description: "Network and secrets"

package/courses/github-actions-cicd/course.yaml

@@ -0,0 +1,10 @@
+id: github-actions-cicd
+name: "GitHub Actions CI/CD Setup"
+description: >
+  Master GitHub Actions for continuous integration and continuous
+  deployment. Learn workflow syntax, triggers, runners, caching,
+  matrix builds, reusable workflows, security hardening, deployment
+  strategies, self-hosted runners, and enterprise CI/CD operations.
+levels: 5
+scenarios_per_level: 10
+tags: [development, GitHub, actions, CI/CD, automation, deployment, DevOps]

package/courses/github-actions-cicd/scenarios/level-1/actions-and-runners.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: actions-and-runners
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Use actions and runners — understand GitHub-hosted runners, marketplace actions, and how to compose steps effectively"
+  tags: [github, actions, runners, marketplace, setup-actions, basics]
+
+state: {}
+
+trigger: |
+  You're building a CI workflow for a full-stack TypeScript project
+  (React frontend + Express backend) and need to understand how to use
+  actions and runners effectively.
+
+  The project needs:
+  - Node.js 20 for the application
+  - PostgreSQL for integration tests
+  - Redis for caching tests
+  - The workflow should work on both ubuntu-latest and macos-latest
+  - Artifacts: upload test coverage reports and build output
+
+  Your teammate has questions about actions and runners:
+
+  Question 1: "What's the difference between 'uses' and 'run' in a
+  step? When should I use each?"
+
+  Question 2: "I see actions like 'actions/checkout@v4' — what does
+  the @v4 mean? Should I use @v4, @main, or a specific SHA?"
+
+  Question 3: "How do I add PostgreSQL and Redis as services in my
+  workflow? I heard you can run Docker containers alongside your job."
+
+  Question 4: "What are the resource limits of GitHub-hosted runners?
+  When would we need self-hosted runners?"
+
+  Question 5: "How do I share files between jobs? My build job
+  produces artifacts that the deploy job needs."
+
+  Task: Write a complete workflow that demonstrates: using marketplace
+  actions (checkout, setup-node, upload-artifact, download-artifact),
+  service containers (PostgreSQL and Redis), multi-OS matrix, and
+  artifact sharing between jobs. Answer all 5 questions with practical
+  examples from the workflow you wrote.
+
+assertions:
+  - type: llm_judge
+    criteria: "Workflow correctly uses service containers — PostgreSQL and Redis are defined as services with proper image, ports, env vars, and health checks. The application connects to services using localhost or service names correctly"
+    weight: 0.35
+    description: "Correct service container configuration"
+  - type: llm_judge
+    criteria: "All 5 questions are answered accurately — uses vs run distinction, action versioning (@v4 vs SHA pinning with security trade-offs), service containers syntax, runner resource limits (7GB RAM, 14GB SSD, 2 CPU for ubuntu), and artifact upload/download for cross-job file sharing"
+    weight: 0.35
+    description: "Accurate answers to all questions"
+  - type: llm_judge
+    criteria: "Workflow demonstrates practical patterns — multi-OS matrix, artifact upload in build job and download in deploy job, proper action version pinning, and the workflow would run successfully in a real repository"
+    weight: 0.30
+    description: "Practical workflow patterns"

package/courses/github-actions-cicd/scenarios/level-1/basic-workflow-syntax.yaml

@@ -0,0 +1,52 @@
+meta:
+  id: basic-workflow-syntax
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Write basic GitHub Actions workflows — learn YAML structure, jobs, steps, and runners to create your first CI pipeline"
+  tags: [github, actions, workflow, YAML, CI, basics]
+
+state: {}
+
+trigger: |
+  You're setting up GitHub Actions for a new Node.js project for the
+  first time. The team needs a CI workflow that runs on every push and
+  pull request. The project uses Node.js 20, npm for package management,
+  and has lint, test, and build scripts defined in package.json.
+
+  Requirements:
+  1. File location: .github/workflows/ci.yml
+  2. Triggers: push to main branch AND all pull requests
+  3. Runner: ubuntu-latest
+  4. Steps needed:
+     - Check out the repository code
+     - Set up Node.js 20
+     - Install dependencies with npm ci
+     - Run linting (npm run lint)
+     - Run tests (npm test)
+     - Build the project (npm run build)
+  5. Include a descriptive workflow name
+  6. Set NODE_ENV=test as an environment variable for the test step
+
+  Additionally, a teammate asks these questions:
+  - "What's the difference between 'npm install' and 'npm ci' in CI?"
+  - "Why do we use 'actions/checkout@v4' instead of just cloning?"
+  - "Should lint, test, and build be separate jobs or steps in one job?"
+
+  Task: Write the complete workflow YAML file and answer all 3 questions.
+  Explain the purpose of each section of the workflow (name, on, jobs,
+  steps) and note any best practices you're following.
+
+assertions:
+  - type: llm_judge
+    criteria: "Workflow YAML is correct and complete — proper indentation, name/on/jobs structure, correct trigger syntax for push (main) and pull_request, uses actions/checkout@v4 and actions/setup-node@v4 with node-version: 20, all 6 steps present, NODE_ENV set correctly"
+    weight: 0.35
+    description: "Correct and complete workflow YAML"
+  - type: llm_judge
+    criteria: "Questions are answered accurately — npm ci vs npm install (ci uses lockfile, faster, clean install), actions/checkout provides optimized shallow clone with auth token, and the single-job-vs-multiple-jobs trade-off is explained (single job is simpler for small projects, multiple jobs allow parallelism)"
+    weight: 0.35
+    description: "Accurate question answers"
+  - type: llm_judge
+    criteria: "Best practices are explained — why npm ci is preferred in CI, why action versions should be pinned, why ubuntu-latest is the default choice, and each workflow section is explained clearly for someone new to GitHub Actions"
+    weight: 0.30
+    description: "Best practices explanation"

package/courses/github-actions-cicd/scenarios/level-1/branch-protection-checks.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: branch-protection-checks
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Set up branch protection with status checks — configure required CI checks that must pass before merging PRs"
+  tags: [github, actions, branch-protection, status-checks, merge-requirements, basics]
+
+state: {}
+
+trigger: |
+  You're the tech lead setting up branch protection for your team's
+  repository. Currently, anyone can push directly to main and merge
+  PRs without CI passing. After a broken deployment last week, the
+  team agreed to enforce CI checks.
+
+  Repository setup:
+  - Main branch: production deployments happen from here
+  - Develop branch: integration branch for features
+  - Feature branches: individual developer work
+
+  CI workflow (already exists):
+  - Job "lint": ESLint + TypeScript checks
+  - Job "test": Jest unit tests
+  - Job "e2e": Cypress E2E tests (sometimes flaky)
+  - Job "build": Production build
+
+  Requirements:
+  1. No direct pushes to main (all changes via PR)
+  2. At least 1 code review approval required
+  3. Required status checks before merging:
+     - lint must pass (always)
+     - test must pass (always)
+     - build must pass (always)
+     - e2e should be required but has a 10% flaky failure rate
+  4. Dismiss stale reviews when new commits are pushed
+  5. Require branches to be up to date with main before merging
+  6. Allow repository admins to bypass in emergencies
+
+  The team debates:
+  - "Should we make e2e tests required if they're flaky?"
+  - "What about hotfixes — do we need a fast path?"
+  - "How do we handle merge conflicts with 'require up to date'?"
+
+  Task: Write the complete branch protection configuration (as you
+  would set it in GitHub Settings or via the API), address the 3 team
+  debates with recommendations, explain how status checks interact
+  with GitHub Actions job names, and describe the developer workflow
+  under these new rules (from creating a branch to merging a PR).
+
+assertions:
+  - type: llm_judge
+    criteria: "Branch protection config is complete — requires PR, required reviewers (1), dismisses stale reviews, requires status checks (lint, test, build), requires branch up-to-date, and admin bypass is configured. The config is expressed clearly (either UI steps or API payload)"
+    weight: 0.35
+    description: "Complete branch protection config"
+  - type: llm_judge
+    criteria: "Team debates are resolved pragmatically — the flaky e2e question gets a nuanced answer (make required but add retry, or make non-required but track), hotfix fast-path is defined (admin bypass with post-merge review), and merge conflict mitigation is addressed (merge queue or frequent rebasing)"
+    weight: 0.35
+    description: "Pragmatic debate resolution"
+  - type: llm_judge
+    criteria: "Status check naming is explained — clarifies that required checks match job names in the workflow YAML, explains what happens when a workflow is skipped (path filters), and the developer workflow is described step-by-step from branch creation to merge"
+    weight: 0.30
+    description: "Clear status check and workflow explanation"

package/courses/github-actions-cicd/scenarios/level-1/environment-variables-secrets.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: environment-variables-secrets
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Manage environment variables and secrets — configure secrets, env vars, and contexts safely in GitHub Actions workflows"
+  tags: [github, actions, secrets, environment-variables, security, basics]
+
+state: {}
+
+trigger: |
+  You're setting up environment variables and secrets for a project
+  that deploys to AWS and uses a PostgreSQL database. The team has
+  been hardcoding values in their workflows and you need to fix this.
+
+  Current (insecure) workflow snippet:
+  ```yaml
+  jobs:
+    deploy:
+      runs-on: ubuntu-latest
+      steps:
+        - run: |
+            export AWS_ACCESS_KEY_ID=AKIA1234567890
+            export AWS_SECRET_ACCESS_KEY=wJalr+secret+key
+            export DATABASE_URL=postgres://admin:password123@db.example.com/prod
+            npm run deploy
+  ```
+
+  Requirements:
+  1. Move all sensitive values to GitHub Secrets
+  2. Use repository-level secrets for AWS credentials
+  3. Use environment-level secrets for database URLs (different per
+     environment: staging vs production)
+  4. Set non-sensitive configuration as environment variables (NODE_ENV,
+     LOG_LEVEL, APP_VERSION)
+  5. Make the GitHub Actions run number available as APP_VERSION
+  6. Explain the secret masking behavior (what happens if a secret
+     is accidentally printed to logs)
+
+  Your teammate asks:
+  - "What's the difference between repository secrets, environment
+    secrets, and organization secrets?"
+  - "Can I use secrets in if: conditions or as part of action inputs?"
+  - "How do I pass secrets to a Docker container step?"
+  - "What happens if I fork a repo — can the fork access the secrets?"
+
+  Task: Rewrite the workflow to use secrets and environment variables
+  correctly. Show: the GitHub Secrets configuration needed (which
+  secrets at which level), the corrected workflow YAML, the answers
+  to all 4 teammate questions, and a security checklist for secrets
+  in GitHub Actions.
+
+assertions:
+  - type: llm_judge
+    criteria: "Secrets are correctly configured — AWS credentials use repository or organization secrets (secrets.AWS_ACCESS_KEY_ID), database URLs use environment-level secrets, the workflow references secrets with ${{ secrets.NAME }} syntax, and no hardcoded sensitive values remain"
+    weight: 0.35
+    description: "Correct secrets configuration"
+  - type: llm_judge
+    criteria: "All 4 questions are answered accurately — explains the 3 secret scopes (repo/env/org) with inheritance rules, limitations of secrets in if: conditions, env: for Docker container steps, and fork security (secrets not available to forks in PRs from forks)"
+    weight: 0.35
+    description: "Accurate question answers"
+  - type: llm_judge
+    criteria: "Security best practices are covered — secret masking behavior, the GITHUB_TOKEN automatic secret, least-privilege principle for secrets, rotation strategy, and the security checklist includes at least 5 actionable items"
+    weight: 0.30
+    description: "Security best practices"

package/courses/github-actions-cicd/scenarios/level-1/first-cicd-shift.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: first-cicd-shift
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "First CI/CD shift — handle a batch of CI/CD setup tasks and troubleshooting requests as the team's GitHub Actions go-to person"
+  tags: [github, actions, shift-simulation, troubleshooting, batch, basics]
+
+state: {}
+
+trigger: |
+  You're the designated GitHub Actions person for your team this week.
+  You have 5 requests to handle.
+
+  Request 1 — New project setup (from the tech lead):
+  "We're starting a new Python project (FastAPI + PostgreSQL). Need a
+  basic CI workflow: lint with ruff, type-check with mypy, test with
+  pytest, and build a Docker image. Use Python 3.12. We also need
+  PostgreSQL as a service container for integration tests."
+
+  Request 2 — Flaky test investigation (from a frustrated developer):
+  "My E2E tests pass locally but fail randomly in CI. About 30% of
+  the time. The error is always 'connection refused' when trying to
+  reach the API server. The workflow starts the server with
+  'npm start &' and immediately runs tests. I think it's a timing
+  issue."
+
+  Request 3 — Cost optimization (from the engineering manager):
+  "Our GitHub Actions bill jumped from $200 to $800 this month. Can
+  you figure out why and fix it? I see we have 15 workflows and some
+  run on every push to every branch."
+
+  Request 4 — Secret rotation (from the security team):
+  "We're rotating all AWS credentials. Please update the GitHub Secrets
+  and make sure the deployment workflow uses the new credentials
+  without any downtime. Also, we found that the old credentials are
+  hardcoded in a workflow file. Remove them."
+
+  Request 5 — Status badge request (from the PM):
+  "Can you add a CI status badge to our README? Also, the deploys page
+  should show the current deployed version. Can GitHub Actions help
+  with that?"
+
+  Task: Handle all 5 requests. For each, write: the solution (workflow
+  YAML, configuration, or investigation steps), the explanation (so
+  the requester understands what you did), and any follow-up
+  recommendations. Prioritize the requests by urgency and explain
+  your prioritization.
+
+assertions:
+  - type: llm_judge
+    criteria: "Priority order is sensible — secret rotation (security) and flaky test (blocking developer) are higher priority than cost optimization and badge requests. The hardcoded credentials in Request 4 are flagged as critical"
+    weight: 0.35
+    description: "Sensible priority order"
+  - type: llm_judge
+    criteria: "Solutions are technically correct — Python CI workflow uses correct setup-python and service container syntax, flaky test fix uses wait-for-it or health check before running tests, cost optimization identifies unnecessary triggers and suggests path filters/concurrency"
+    weight: 0.35
+    description: "Technically correct solutions"
+  - type: llm_judge
+    criteria: "Explanations are accessible — each response is written for the specific requester's context (tech lead gets YAML, frustrated developer gets root cause, manager gets cost breakdown, security gets rotation procedure, PM gets badge markdown)"
+    weight: 0.30
+    description: "Context-appropriate explanations"

package/courses/github-actions-cicd/scenarios/level-1/job-dependencies-outputs.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: job-dependencies-outputs
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Configure job dependencies and outputs — use needs, outputs, and conditional execution to create structured workflow graphs"
+  tags: [github, actions, jobs, needs, outputs, conditional, basics]
+
+state: {}
+
+trigger: |
+  You're building a deployment workflow that requires careful job
+  orchestration. Different jobs need to pass data to each other and
+  execute conditionally.
+
+  Workflow requirements:
+  1. Job: "determine-changes" — Detect what changed in the PR
+     - Output: "backend_changed" (true/false)
+     - Output: "frontend_changed" (true/false)
+     - Output: "infra_changed" (true/false)
+     - Uses git diff to check which directories have changes
+
+  2. Job: "test-backend" — Only runs if backend code changed
+     - Needs: determine-changes
+     - Condition: only if backend_changed == 'true'
+     - Output: "test_status" (passed/failed)
+
+  3. Job: "test-frontend" — Only runs if frontend code changed
+     - Needs: determine-changes
+     - Condition: only if frontend_changed == 'true'
+     - Output: "test_status" (passed/failed)
+
+  4. Job: "deploy" — Runs only if relevant tests passed
+     - Needs: test-backend AND test-frontend
+     - Should run even if one of the test jobs was skipped (because
+       that directory didn't change)
+     - Should NOT run if any test job actually failed
+
+  5. Job: "notify" — Always runs, even if previous jobs fail
+     - Reports the final status to Slack
+     - Needs access to outputs from all previous jobs
+
+  Task: Write the complete workflow YAML. Explain: how to set and
+  read job outputs (the $GITHUB_OUTPUT syntax), how 'needs' creates
+  the dependency graph, how 'if' conditions work with job outputs and
+  status functions (success(), failure(), always(), cancelled()), and
+  the tricky behavior when a needed job is skipped (the deploy job
+  scenario).
+
+assertions:
+  - type: llm_judge
+    criteria: "Job outputs are correctly configured — uses echo 'key=value' >> $GITHUB_OUTPUT syntax, outputs are declared in job-level outputs section, and downstream jobs reference them correctly with needs.<job>.outputs.<name>"
+    weight: 0.35
+    description: "Correct job output configuration"
+  - type: llm_judge
+    criteria: "Conditional execution handles the tricky cases — the deploy job runs when tests pass OR are skipped (not failed), using the correct combination of if: conditions and status check functions. The notify job uses if: always() to run regardless"
+    weight: 0.35
+    description: "Correct conditional execution"
+  - type: llm_judge
+    criteria: "Explanations clarify confusing behaviors — explains that skipped jobs cause downstream 'needs' jobs to also skip by default, how to use 'if: always()' or '!cancelled()' to override, and the difference between a job being skipped vs failing"
+    weight: 0.30
+    description: "Clear behavior explanations"

package/courses/github-actions-cicd/scenarios/level-1/simple-ci-pipeline.yaml

@@ -0,0 +1,57 @@
+meta:
+  id: simple-ci-pipeline
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Build a simple CI pipeline — create a complete lint, test, and build pipeline with proper job dependencies and failure handling"
+  tags: [github, actions, CI, pipeline, lint, test, build, basics]
+
+state: {}
+
+trigger: |
+  You're creating a CI pipeline for a React + TypeScript project.
+  The pipeline should catch issues before code is merged to main.
+
+  Project setup:
+  - React 18 with TypeScript
+  - ESLint for linting
+  - Jest for unit tests
+  - Cypress for E2E tests (runs against a dev server)
+  - Vite for building
+
+  Pipeline requirements:
+  1. Lint job: Run ESLint and TypeScript type checking
+  2. Unit test job: Run Jest with coverage report
+  3. E2E test job: Start dev server, run Cypress tests, upload
+     screenshots on failure
+  4. Build job: Only run if lint and unit tests pass
+  5. The E2E tests should run in parallel with (not blocked by) the
+     build job
+  6. If any job fails, the PR should show a red status check
+  7. Cache node_modules to speed up subsequent runs
+
+  Additional context:
+  - The team currently runs everything locally before pushing, but
+    developers sometimes skip steps. The CI should be the safety net.
+  - E2E tests are flaky — about 10% failure rate. The team wants to
+    retry failed E2E tests once before marking as failed.
+
+  Task: Write the complete CI workflow. Include: the workflow YAML with
+  all 4 jobs and proper dependencies (needs), the caching configuration
+  for node_modules, the E2E test configuration with retry and failure
+  artifact upload, and an explanation of the job dependency graph
+  (which jobs run in parallel, which are sequential).
+
+assertions:
+  - type: llm_judge
+    criteria: "Job dependencies are correct — lint and unit tests can run in parallel, build needs lint + unit tests to pass, E2E runs independently or after lint, and the dependency graph is explicitly explained with a visual or textual representation"
+    weight: 0.35
+    description: "Correct job dependencies"
+  - type: llm_judge
+    criteria: "Caching and retry are properly configured — uses actions/cache or setup-node cache for node_modules with correct cache key (hash of package-lock.json), E2E test step has retry logic (either via Cypress retry or step-level continue-on-error with re-run), and failure artifacts are uploaded"
+    weight: 0.35
+    description: "Proper caching and retry configuration"
+  - type: llm_judge
+    criteria: "Pipeline is practical and complete — all 4 jobs have correct steps, the E2E test starts a dev server before running Cypress, coverage reports are generated, and the workflow would work in a real React + TypeScript project without modification"
+    weight: 0.30
+    description: "Practical complete pipeline"