dojo.md 0.1.0 → 0.2.1

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

@@ -0,0 +1,90 @@
+meta:
+  id: workflow-debugging
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Debug GitHub Actions workflows — diagnose and fix common workflow failures, read logs effectively, and use debug mode"
+  tags: [github, actions, debugging, troubleshooting, logs, basics]
+
+state: {}
+
+trigger: |
+  You're helping a junior developer debug their first GitHub Actions
+  workflow. They've hit 5 different errors and can't figure out what's
+  wrong. For each error, diagnose the problem and provide the fix.
+
+  Error 1 — Workflow not triggering:
+  "I pushed to my feature branch but the workflow didn't run at all.
+  No entry in the Actions tab."
+  Their trigger config:
+  ```yaml
+  on:
+    push:
+      branches: [main]
+    pull_request:
+      branches: [main]
+  ```
+  They pushed to the branch 'feature/login' without opening a PR.
+
+  Error 2 — Permission denied:
+  ```
+  Error: HttpError: Resource not accessible by integration
+  ```
+  Their workflow tries to comment on a PR using the GITHUB_TOKEN.
+  The workflow is triggered by pull_request from a fork.
+
+  Error 3 — Action not found:
+  ```
+  Error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile'
+  under '/home/runner/work/_actions/actions/setup-node/4'
+  ```
+  Their step: `uses: actions/setup-node@4` (missing the 'v' prefix)
+
+  Error 4 — Cache miss every time:
+  "My workflow takes 8 minutes because npm install runs fresh every
+  time. I added caching but it never hits."
+  ```yaml
+  - uses: actions/cache@v4
+    with:
+      path: node_modules
+      key: npm-${{ hashFiles('package.json') }}
+  ```
+  The issue: they're hashing package.json not package-lock.json.
+
+  Error 5 — Job output not available:
+  "My second job can't read the output from my first job. It's always
+  empty."
+  ```yaml
+  jobs:
+    build:
+      runs-on: ubuntu-latest
+      steps:
+        - run: echo "version=1.2.3" >> $GITHUB_OUTPUT
+    deploy:
+      needs: build
+      runs-on: ubuntu-latest
+      steps:
+        - run: echo "Deploying ${{ needs.build.outputs.version }}"
+  ```
+  They forgot to declare outputs at the job level.
+
+  Task: For each error, write: the diagnosis (what went wrong and why),
+  the fix (corrected YAML or configuration), the prevention strategy
+  (how to avoid this in the future), and the debugging technique (how
+  to find this type of error faster). Include a general GitHub Actions
+  debugging guide covering: enabling debug logging, reading workflow
+  run logs effectively, and the act tool for local testing.
+
+assertions:
+  - type: llm_judge
+    criteria: "All 5 errors are correctly diagnosed — trigger scope for Error 1, fork PR permissions for Error 2, version tag format for Error 3, cache key using wrong file for Error 4, and missing job-level outputs declaration for Error 5"
+    weight: 0.35
+    description: "Correct error diagnoses"
+  - type: llm_judge
+    criteria: "Fixes are specific and correct — each fix shows the corrected YAML snippet, and the fixes address the root cause (not just the symptom). Error 2's fix addresses the fundamental fork permission model, not just a workaround"
+    weight: 0.35
+    description: "Specific correct fixes"
+  - type: llm_judge
+    criteria: "Debugging guide is practical — covers ACTIONS_RUNNER_DEBUG and ACTIONS_STEP_DEBUG secrets, how to navigate workflow run logs in the GitHub UI, the 'act' tool for local workflow testing, and at least 3 prevention strategies (linting, local testing, PR templates)"
+    weight: 0.30
+    description: "Practical debugging guide"

package/courses/github-actions-cicd/scenarios/level-1/workflow-status-notifications.yaml

@@ -0,0 +1,59 @@
+meta:
+  id: workflow-status-notifications
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Configure workflow notifications — set up status badges, Slack alerts, and PR comments to communicate CI results effectively"
+  tags: [github, actions, notifications, badges, Slack, PR-comments, basics]
+
+state: {}
+
+trigger: |
+  Your team wants better visibility into CI status. Currently, the
+  only way to know if CI passed is to click into the Actions tab.
+  You need to set up 3 notification channels.
+
+  Channel 1 — README status badges:
+  - Add build status badge to README.md
+  - Show status for the main branch
+  - Include separate badges for: CI tests, deploy status, and
+    code coverage percentage
+
+  Channel 2 — Slack notifications:
+  - Send a message to #engineering-ci channel when:
+    * A deployment to production succeeds (green message)
+    * Any CI run on main fails (red message with link to logs)
+  - Do NOT notify on:
+    * Successful PR CI runs (too noisy)
+    * Cancelled workflows
+  - Include: commit message, author, branch, link to workflow run
+
+  Channel 3 — PR comments:
+  - Post a comment on the PR with:
+    * Test results summary (X passed, Y failed, Z skipped)
+    * Code coverage percentage (from coverage report)
+    * Build size comparison (current vs main)
+    * Link to full logs
+  - Update the existing comment instead of posting a new one each
+    time (avoid comment spam)
+
+  Task: Write the workflow additions for all 3 channels. Include: the
+  status badge markdown for the README, the Slack notification workflow
+  job (using a Slack webhook or action), the PR comment job (using
+  actions/github-script or similar), and the logic to update existing
+  comments instead of creating new ones. Explain the trade-offs of each
+  notification approach.
+
+assertions:
+  - type: llm_judge
+    criteria: "Status badges are correct — uses the correct GitHub badge URL format (https://github.com/OWNER/REPO/actions/workflows/FILE/badge.svg?branch=main), includes multiple badges, and the markdown syntax is valid for README.md"
+    weight: 0.35
+    description: "Correct status badges"
+  - type: llm_judge
+    criteria: "Slack notification is properly conditional — only sends on main branch failures and production deploy successes, uses correct if: conditions to filter events, and the message includes all required context (commit, author, link)"
+    weight: 0.35
+    description: "Properly conditional Slack notification"
+  - type: llm_judge
+    criteria: "PR comment uses find-and-update pattern — searches for existing bot comment (by marker text or comment body pattern), updates if found or creates if not, includes test results and coverage, and the implementation uses GitHub API correctly"
+    weight: 0.30
+    description: "Smart PR comment updates"

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

@@ -0,0 +1,56 @@
+meta:
+  id: workflow-triggers
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Configure workflow triggers — set up push, pull_request, schedule, workflow_dispatch, and release triggers with filters"
+  tags: [github, actions, triggers, events, schedule, workflow-dispatch, basics]
+
+state: {}
+
+trigger: |
+  You're configuring triggers for an e-commerce application's CI/CD
+  pipeline. The team needs 5 different workflow files, each with a
+  specific trigger configuration.
+
+  Workflow 1 — CI Tests (ci.yml):
+  - Run on every push to any branch
+  - Run on every pull request to the main branch
+  - Only run when source code changes (src/** or package.json), NOT
+    when only documentation (docs/**) or README changes
+
+  Workflow 2 — Nightly Cleanup (nightly.yml):
+  - Run every day at 2:00 AM UTC
+  - Also allow manual triggering for on-demand cleanup
+
+  Workflow 3 — Production Deploy (deploy.yml):
+  - Manual trigger only (workflow_dispatch)
+  - Accept an input parameter "environment" with options: staging, production
+  - Accept an input parameter "version" (required, string)
+
+  Workflow 4 — Release (release.yml):
+  - Trigger when a GitHub Release is published
+  - Should NOT trigger on draft releases or pre-releases
+
+  Workflow 5 — Dependency Update (deps.yml):
+  - Run every Monday at 9:00 AM UTC
+  - Also trigger when package-lock.json changes on push to main
+
+  Task: Write the complete 'on:' section for each workflow file. For
+  each, explain: when it will trigger, when it will NOT trigger, and
+  one common pitfall to avoid. Also explain the difference between
+  'paths' and 'paths-ignore' filters, and when to use each.
+
+assertions:
+  - type: llm_judge
+    criteria: "All 5 trigger configurations are syntactically correct — push with branch and path filters, schedule with valid cron expressions (0 2 * * * for daily 2AM, 0 9 * * 1 for Monday 9AM), workflow_dispatch with typed inputs, release with types: [published]"
+    weight: 0.35
+    description: "Syntactically correct triggers"
+  - type: llm_judge
+    criteria: "Trigger behavior is accurately explained — each workflow's trigger and non-trigger conditions are correct, the paths/paths-ignore distinction is clear, and pitfalls are practical (e.g., schedule cron runs on default branch only, workflow_dispatch only works on default branch)"
+    weight: 0.35
+    description: "Accurate trigger behavior explanation"
+  - type: llm_judge
+    criteria: "Pitfalls and edge cases are noted — mentions that paths filters don't work with schedule triggers, that release published excludes drafts, that cron schedules can be delayed by GitHub load, and that workflow_dispatch inputs have no runtime validation by default"
+    weight: 0.30
+    description: "Practical pitfalls and edge cases"

package/courses/github-actions-cicd/scenarios/level-2/concurrency-control.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: concurrency-control
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Manage workflow concurrency — prevent duplicate runs, configure merge queues, and handle parallel deployments safely"
+  tags: [github, actions, concurrency, merge-queue, parallel, intermediate]
+
+state: {}
+
+trigger: |
+  Your team's CI/CD has several concurrency problems causing wasted
+  resources and deployment conflicts:
+
+  Problem 1 — Duplicate CI runs:
+  A developer pushes 3 commits in quick succession. Each push triggers
+  a separate CI run. The first 2 runs are wasted because only the
+  latest commit matters. This wastes 24 minutes of runner time per
+  occurrence, happening ~20 times per day.
+
+  Problem 2 — Deployment conflicts:
+  Two PRs merge to main within seconds of each other. Both trigger
+  deployment workflows. The deployments race — sometimes deployment B
+  starts before deployment A finishes, causing a partially deployed
+  state. Last week this caused a 30-minute outage.
+
+  Problem 3 — PR merge bottleneck:
+  With "require branch up to date with main" enabled, only one PR can
+  merge at a time. Each PR merge triggers CI again. With 15 PRs per
+  day, this creates a 2-hour queue. The team is considering GitHub's
+  merge queue feature.
+
+  Problem 4 — Resource contention:
+  Self-hosted runners (4 total) are overwhelmed during peak hours
+  (10AM-2PM). 12 workflows queue up for runners, and some time out
+  after 30 minutes waiting.
+
+  Task: Solve all 4 problems. For each, write: the root cause analysis,
+  the solution using GitHub Actions concurrency features (concurrency
+  groups, cancel-in-progress, merge queue), the workflow YAML changes,
+  and the trade-offs of each solution. Include: the concurrency group
+  naming strategy (how to scope groups by PR, branch, or workflow),
+  the merge queue configuration, and the runner capacity planning
+  recommendations.
+
+assertions:
+  - type: llm_judge
+    criteria: "Concurrency groups are correctly configured — uses concurrency with group names scoped appropriately (e.g., ci-${{ github.ref }} for CI, deploy-production for deployments), cancel-in-progress: true for CI but false for deployments, and the naming strategy prevents accidental conflicts"
+    weight: 0.35
+    description: "Correct concurrency configuration"
+  - type: llm_judge
+    criteria: "All 4 problems are solved — duplicate runs cancelled with concurrency groups, deployments serialized with concurrency (no cancel), merge queue configured to batch PRs, and runner capacity recommendations address peak load (scaling, priority queues)"
+    weight: 0.35
+    description: "All problems solved"
+  - type: llm_judge
+    criteria: "Trade-offs are explained — notes that cancel-in-progress means intermediate results are lost, serialized deployments slow down when many PRs merge, merge queue adds complexity, and runner scaling has cost implications"
+    weight: 0.30
+    description: "Trade-offs explained"

package/courses/github-actions-cicd/scenarios/level-2/conditional-execution.yaml

@@ -0,0 +1,60 @@
+meta:
+  id: conditional-execution
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Master conditional execution — use if expressions, status functions, and context variables to control when jobs and steps run"
+  tags: [github, actions, conditional, if-expressions, contexts, intermediate]
+
+state: {}
+
+trigger: |
+  You're building a sophisticated deployment workflow that must behave
+  differently based on various conditions. The workflow needs to handle
+  multiple deployment targets, branch-specific logic, and failure
+  recovery.
+
+  Scenarios to implement:
+
+  Scenario 1 — Branch-based deployment:
+  - Push to main → deploy to staging
+  - Push with tag v*.*.* → deploy to production
+  - Push to feature/* → deploy to preview environment
+  - Pull request → run tests only (no deployment)
+
+  Scenario 2 — Conditional step execution:
+  - Run database migrations only if migration files changed
+  - Send Slack notification only on failure
+  - Skip expensive E2E tests if the PR is labeled "skip-e2e"
+  - Run security scan only on PRs touching src/auth/** files
+
+  Scenario 3 — Context-based decisions:
+  - Use different AWS accounts based on environment (staging/production)
+  - Set different resource limits based on runner type
+  - Include debug logging only when triggered manually with debug=true
+
+  Scenario 4 — Error recovery:
+  - If deployment fails, automatically run rollback
+  - If rollback also fails, page the on-call engineer
+  - Always run cleanup steps regardless of failure
+  - Produce a deployment report with pass/fail status for each step
+
+  Task: Write the workflow YAML covering all 4 scenarios. For each
+  condition, explain: the expression syntax, the available context
+  variables (github.event_name, github.ref, contains(), startsWith()),
+  and the evaluation rules (when does a condition short-circuit). Include
+  a cheat sheet of the most useful conditional expressions.
+
+assertions:
+  - type: llm_judge
+    criteria: "Conditional expressions are syntactically correct — uses github.ref, github.event_name, contains(), startsWith(), success(), failure(), always(), and the expressions handle all 4 scenarios correctly including tag matching for semver"
+    weight: 0.35
+    description: "Correct conditional expressions"
+  - type: llm_judge
+    criteria: "Error recovery pattern is sound — deployment failure triggers rollback step (if: failure()), rollback failure triggers paging, cleanup runs with if: always(), and the deployment report captures status from all steps using step outcomes"
+    weight: 0.35
+    description: "Sound error recovery pattern"
+  - type: llm_judge
+    criteria: "Cheat sheet is comprehensive and practical — covers the most common 10+ conditional patterns, explains boolean logic in expressions, notes that secrets context is not available in if: conditions, and clarifies the difference between job-level and step-level if:"
+    weight: 0.30
+    description: "Comprehensive conditional cheat sheet"

package/courses/github-actions-cicd/scenarios/level-2/custom-actions-development.yaml

@@ -0,0 +1,55 @@
+meta:
+  id: custom-actions-development
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Develop custom GitHub Actions — build JavaScript, Docker, and composite actions for team-specific automation needs"
+  tags: [github, actions, custom-actions, JavaScript, Docker, composite, intermediate]
+
+state: {}
+
+trigger: |
+  Your team has 3 automation needs that aren't covered by existing
+  marketplace actions. You need to build custom actions.
+
+  Action 1 — "deployment-notifier" (Composite action):
+  Purpose: Post a formatted deployment summary to Slack and update
+  a GitHub deployment status. Used in 8 repos.
+  Inputs: environment, version, status (success/failure), slack-webhook
+  Behavior: Posts Slack message with deployment details, creates GitHub
+  deployment status, and writes a summary to $GITHUB_STEP_SUMMARY
+
+  Action 2 — "pr-size-labeler" (JavaScript action):
+  Purpose: Automatically label PRs by size (XS, S, M, L, XL) based
+  on lines changed. Also warn if the PR exceeds 500 lines.
+  Inputs: github-token, size-thresholds (JSON: {XS: 10, S: 50, ...})
+  Behavior: Reads PR diff stats, applies label, posts warning comment
+  if over threshold
+
+  Action 3 — "security-context-check" (Docker action):
+  Purpose: Scan environment for leaked secrets, check that no
+  hardcoded credentials exist in the code, and verify .env files
+  aren't committed. Runs in an isolated Docker container for security.
+  Inputs: scan-paths, exclude-patterns, severity-threshold
+  Outputs: findings-count, report-path
+
+  Task: Build all 3 actions. For each, write: the action.yml metadata
+  file, the implementation (shell script for composite, index.js for
+  JavaScript, Dockerfile + entrypoint for Docker), the test strategy
+  (how to test custom actions), and the publishing approach (how to
+  version and release). Compare the 3 action types: when to use each,
+  performance differences, and maintenance considerations.
+
+assertions:
+  - type: llm_judge
+    criteria: "action.yml files are correctly structured — each has proper name, description, inputs with types/defaults/required, outputs where applicable, runs section matching the action type (composite/node20/docker), and branding metadata"
+    weight: 0.35
+    description: "Correct action.yml structure"
+  - type: llm_judge
+    criteria: "Implementations are functional — composite action uses correct shell syntax with ${{ inputs.* }}, JavaScript action uses @actions/core and @actions/github packages correctly, Docker action has proper Dockerfile and entrypoint script receiving inputs as env vars"
+    weight: 0.35
+    description: "Functional implementations"
+  - type: llm_judge
+    criteria: "Comparison helps decision-making — explains when to choose composite (simple, no build step), JavaScript (rich API access, fast startup), or Docker (isolation, any language), and covers testing strategies, versioning with tags, and the marketplace publishing process"
+    weight: 0.30
+    description: "Decision-helping comparison"

package/courses/github-actions-cicd/scenarios/level-2/dependency-caching.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: dependency-caching
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Optimize dependency caching — configure actions/cache and built-in caching to dramatically reduce CI build times"
+  tags: [github, actions, caching, dependencies, optimization, intermediate]
+
+state: {}
+
+trigger: |
+  Your team's CI workflow takes 12 minutes per run, and 8 of those
+  minutes are spent installing dependencies. With 80 CI runs per day,
+  that's over 10 hours wasted on dependency installation daily. You
+  need to implement an effective caching strategy.
+
+  Project details:
+  - Monorepo with 3 packages (frontend, backend, shared)
+  - Frontend: npm (package-lock.json)
+  - Backend: pip (requirements.txt + requirements-dev.txt)
+  - Shared: Go modules (go.sum)
+  - Docker builds: multi-stage Dockerfile for backend
+
+  Current (no caching) timing:
+  - npm ci: 3 minutes
+  - pip install: 2 minutes
+  - go mod download: 1.5 minutes
+  - Docker build: 1.5 minutes (downloads base images each time)
+
+  Caching scenarios to solve:
+  1. Basic npm caching using actions/setup-node's built-in cache
+  2. Advanced npm caching using actions/cache with fallback keys
+  3. pip caching with multiple requirements files as cache key
+  4. Go module caching
+  5. Docker layer caching (using actions/cache or buildx cache)
+  6. Cross-branch cache sharing (feature branch uses main's cache)
+
+  Task: Implement caching for all 5 dependency types. For each, write:
+  the cache configuration (key, restore-keys, path), the explanation
+  of the cache key strategy (why hash this file, what happens on
+  cache miss), the expected time savings, and common caching pitfalls
+  to avoid. Include a comparison of built-in caching (setup-node,
+  setup-python) vs explicit actions/cache, and explain when each is
+  preferred.
+
+assertions:
+  - type: llm_judge
+    criteria: "Cache keys are correctly designed — npm uses hashFiles('**/package-lock.json'), pip uses hashFiles of requirements files, Go uses hashFiles('**/go.sum'), restore-keys provide fallback for partial matches, and the cross-branch sharing strategy is explained"
+    weight: 0.35
+    description: "Correctly designed cache keys"
+  - type: llm_judge
+    criteria: "All 5 dependency types are cached — npm, pip, Go modules, and Docker layers all have correct cache configurations with appropriate paths (node_modules or ~/.npm, ~/.cache/pip, ~/go/pkg/mod) and the Docker caching uses buildx with cache-from/cache-to or actions/cache"
+    weight: 0.35
+    description: "Complete caching for all types"
+  - type: llm_judge
+    criteria: "Pitfalls and trade-offs are addressed — explains cache size limits (10GB per repo), cache eviction policy (LRU, 7-day expiry), the danger of caching node_modules vs ~/.npm, and when built-in caching (setup-node cache: npm) is simpler than explicit actions/cache"
+    weight: 0.30
+    description: "Pitfalls and trade-offs addressed"

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

@@ -0,0 +1,61 @@
+meta:
+  id: deployment-workflows
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Build deployment workflows — create staging and production deployment pipelines with approval gates and rollback"
+  tags: [github, actions, deployment, staging, production, rollback, intermediate]
+
+state: {}
+
+trigger: |
+  You're building deployment workflows for a web application that needs
+  to deploy to staging automatically and to production with manual
+  approval. The application runs on AWS (ECS for the API, S3 + CloudFront
+  for the frontend).
+
+  Deployment requirements:
+  1. Staging deployment:
+     - Automatically deploy when PR is merged to main
+     - Deploy both frontend (S3) and backend (ECS)
+     - Run smoke tests after deployment
+     - Notify #staging Slack channel with deployment URL
+
+  2. Production deployment:
+     - Requires manual approval from a team lead
+     - Uses GitHub Environments with protection rules
+     - Deploy frontend first, then backend (ordered)
+     - Run health checks between each deployment step
+     - If health check fails, automatically rollback
+     - Notify #production Slack channel
+
+  3. Rollback workflow:
+     - Manual trigger (workflow_dispatch) with version input
+     - Rolls back to the specified previous version
+     - Can also be triggered automatically from deployment failure
+
+  4. Environment configuration:
+     - Staging: auto-deploy, no approval, 5-minute timeout
+     - Production: manual approval (2 required reviewers), deployment
+       window (weekdays 9AM-4PM ET only)
+
+  Task: Write all 3 workflow files (deploy-staging.yml, deploy-
+  production.yml, rollback.yml). Include: the GitHub Environment
+  configuration (protection rules, secrets per environment), the
+  deployment steps with health checks, the rollback mechanism, and
+  the Slack notification integration. Explain the deployment strategy
+  (blue-green, rolling, or canary) and why you chose it.
+
+assertions:
+  - type: llm_judge
+    criteria: "GitHub Environments are correctly used — staging environment has no protection rules (auto-deploy), production has required reviewers and deployment branch restriction (main only), and environment-specific secrets are referenced correctly"
+    weight: 0.35
+    description: "Correct GitHub Environment usage"
+  - type: llm_judge
+    criteria: "Deployment and rollback are properly orchestrated — staging deploys automatically on merge, production requires approval, health checks run between steps, failures trigger automatic rollback, and the manual rollback workflow accepts a version input"
+    weight: 0.35
+    description: "Proper deployment orchestration"
+  - type: llm_judge
+    criteria: "Deployment strategy is explained and implemented — the chosen strategy (blue-green, rolling, or canary) is justified for the architecture (ECS + S3), the implementation matches the strategy, and the rollback mechanism is consistent with the deployment approach"
+    weight: 0.30
+    description: "Explained deployment strategy"

package/courses/github-actions-cicd/scenarios/level-2/github-packages-publishing.yaml

@@ -0,0 +1,59 @@
+meta:
+  id: github-packages-publishing
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Publish to GitHub Packages — automate npm, Docker, and container registry publishing with versioning and access control"
+  tags: [github, actions, packages, npm, Docker, registry, intermediate]
+
+state: {}
+
+trigger: |
+  Your organization has internal libraries and Docker images that need
+  to be published to GitHub Packages. You need to set up automated
+  publishing workflows for 3 different package types.
+
+  Package 1 — npm library (@myorg/shared-utils):
+  - Publish to GitHub Packages npm registry (not npmjs.com)
+  - Version from package.json
+  - Publish on GitHub Release creation
+  - Include provenance attestation
+  - Scoped to the organization (@myorg/*)
+
+  Package 2 — Docker image (myorg/api-server):
+  - Build and push to GitHub Container Registry (ghcr.io)
+  - Tag with: git SHA, branch name, semver from git tag, and "latest"
+  - Multi-architecture build (amd64 + arm64)
+  - Push on merge to main (tagged as latest + SHA)
+  - Push on release (tagged with version)
+
+  Package 3 — Python package (myorg-sdk):
+  - Build wheel and sdist
+  - Publish to GitHub Packages (not PyPI)
+  - Include in the same workflow as tests
+
+  Access control requirements:
+  - Internal packages: readable by all org members
+  - Docker images: public (for open-source project)
+  - npm packages: scoped to org, installable with GITHUB_TOKEN
+
+  Task: Write the publishing workflows for all 3 package types.
+  Include: the workflow YAML, the package.json / Dockerfile / setup.py
+  configuration needed for GitHub Packages, the authentication setup
+  (GITHUB_TOKEN permissions, .npmrc configuration), and the versioning
+  strategy for each package type. Explain the difference between GitHub
+  Packages and external registries.
+
+assertions:
+  - type: llm_judge
+    criteria: "npm publishing is correctly configured — uses .npmrc with GitHub Packages registry URL, GITHUB_TOKEN authentication, publishConfig in package.json, provenance attestation with --provenance flag, and the workflow triggers on release published"
+    weight: 0.35
+    description: "Correct npm publishing"
+  - type: llm_judge
+    criteria: "Docker publishing uses GHCR correctly — authenticates with ghcr.io, uses docker/metadata-action for smart tagging (SHA, branch, semver), multi-arch build with docker/build-push-action and QEMU, and the image is properly tagged for both main and release triggers"
+    weight: 0.35
+    description: "Correct Docker GHCR publishing"
+  - type: llm_judge
+    criteria: "Access control and versioning are properly explained — differentiates package visibility settings, explains GITHUB_TOKEN vs PAT for cross-repo access, and the versioning strategy is consistent across package types (semver from git tags or package.json)"
+    weight: 0.30
+    description: "Proper access control and versioning"

package/courses/github-actions-cicd/scenarios/level-2/intermediate-cicd-shift.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: intermediate-cicd-shift
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Intermediate CI/CD shift — handle complex workflow issues, optimization requests, and deployment incidents simultaneously"
+  tags: [github, actions, shift-simulation, troubleshooting, optimization, intermediate]
+
+state: {}
+
+trigger: |
+  You're the CI/CD on-call engineer handling multiple requests during
+  a busy shift. Handle all 4 situations.
+
+  Situation 1 — Deployment rollback needed:
+  Production deployment just completed but monitoring shows 500 errors
+  spiking from 0.1% to 5%. The deployment was triggered by a merge
+  to main 10 minutes ago. You need to:
+  - Identify which commit caused the issue
+  - Trigger a rollback to the previous version
+  - The rollback workflow exists but has never been used — you need
+    to verify it works and execute it
+  - Prevent further auto-deployments until the issue is resolved
+
+  Situation 2 — Matrix build timeout:
+  The cross-platform test matrix has been running for 2 hours (normal
+  is 20 minutes). Investigation shows: macOS runner is stuck on "Set
+  up job" with no logs. This is blocking a critical security patch PR.
+  You need to:
+  - Unblock the security patch
+  - Fix the matrix build for future runs
+  - Decide if you should rerun the entire matrix or just the failed job
+
+  Situation 3 — Secret exposure alert:
+  GitHub sent a secret scanning alert: an AWS access key was found in
+  a workflow file committed 2 hours ago. The key was in a hardcoded
+  env value (not using secrets). You need to:
+  - Assess the exposure (was the key used in any workflow runs?)
+  - Remediate immediately (rotate key, remove from code)
+  - Prevent recurrence (how to block secret commits)
+
+  Situation 4 — Cache corruption:
+  Multiple teams report that their CI workflows are failing with
+  "Module not found" errors despite no code changes. Investigation
+  shows the shared cache (node_modules) was corrupted by a workflow
+  that ran during a failed npm publish. You need to:
+  - Clear the corrupted cache for affected repos
+  - Fix the failing workflows immediately
+  - Prevent cache corruption from happening again
+
+  Task: Handle all 4 situations. For each, write: the immediate action
+  (what to do in the next 5 minutes), the resolution steps, the root
+  cause analysis, and the prevention measures. Prioritize and explain
+  your priority order.
+
+assertions:
+  - type: llm_judge
+    criteria: "Priority order is correct — secret exposure (Situation 3) and production errors (Situation 1) are highest priority, matrix timeout (Situation 2) is medium (blocks security patch), and cache corruption (Situation 4) is handled but less urgent. The security patch PR gets unblocked quickly"
+    weight: 0.35
+    description: "Correct priority order"
+  - type: llm_judge
+    criteria: "Resolutions are technically sound — rollback uses the existing workflow with correct version targeting, secret remediation includes key rotation AND code removal AND history rewriting if needed, cache clearing uses correct GitHub API or CLI, and matrix fix addresses the macOS runner issue"
+    weight: 0.35
+    description: "Technically sound resolutions"
+  - type: llm_judge
+    criteria: "Prevention measures are systemic — secret scanning with push protection, pre-commit hooks for secrets, cache key design that prevents corruption (immutable keys), macOS runner fallback strategy, and deployment safeguards (canary, automatic rollback on error rate)"
+    weight: 0.30
+    description: "Systemic prevention measures"