dojo.md 0.1.0 → 0.2.1

package/courses/github-actions-cicd/scenarios/level-5/cicd-regulatory-landscape.yaml

@@ -0,0 +1,72 @@
+meta:
+  id: cicd-regulatory-landscape
+  level: 5
+  course: github-actions-cicd
+  type: output
+  description: "Navigate CI/CD regulatory landscape — map how global regulations shape CI/CD requirements and prepare for emerging frameworks"
+  tags: [github, actions, regulatory, compliance, global, supply-chain, master]
+
+state: {}
+
+trigger: |
+  You're the Chief Compliance Officer of a global software company
+  operating in 30 countries. Regulations increasingly require
+  demonstrable CI/CD controls, and you need to map the landscape.
+
+  Current regulatory requirements affecting CI/CD:
+
+  1. EU Cyber Resilience Act (CRA, effective 2027):
+  - Requires documented secure development lifecycle for all software
+    sold in the EU
+  - CI/CD must produce verifiable build provenance (SLSA Level 3)
+  - Vulnerability management must be automated in the pipeline
+  - Penalty: up to 15M EUR or 2.5% of global turnover
+
+  2. US Executive Order 14028 (Software Supply Chain):
+  - Software Bill of Materials (SBOM) required for government contracts
+  - CI/CD must generate and sign SBOMs automatically
+  - Build environment integrity must be verifiable
+  - Applies to your $200M government contract portfolio
+
+  3. SEC Cybersecurity Rules:
+  - Material cybersecurity incidents must be disclosed in 4 days
+  - CI/CD audit trails are part of "reasonable controls"
+  - Board must oversee cybersecurity risk management
+
+  4. India CERT-In Directive:
+  - 6-hour incident reporting requirement
+  - CI/CD logs must be retained for 180 days
+  - Your Bangalore development center is affected
+
+  5. Proposed EU AI Act CI/CD implications:
+  - High-risk AI systems must have documented CI/CD processes
+  - Model training pipelines need audit trails
+  - Continuous monitoring must be built into deployment
+
+  Emerging trends:
+  - SLSA framework adoption for build provenance
+  - Sigstore/cosign for artifact signing
+  - OpenSSF Scorecard for repository security
+  - NIST SSDF (Secure Software Development Framework)
+  - Software Liability Act proposals (US + EU)
+
+  Task: Map the regulatory landscape. Write: the regulatory matrix
+  (which regulations apply to which CI/CD components), the compliance
+  gap analysis, the unified CI/CD compliance framework (one pipeline
+  that satisfies all regulations), the SLSA Level 3 implementation
+  plan, and the future-proofing strategy. Include the board brief on
+  regulatory risk.
+
+assertions:
+  - type: llm_judge
+    criteria: "Regulatory matrix is comprehensive — maps each regulation to specific CI/CD controls (build provenance, SBOM generation, audit trail retention, artifact signing), identifies overlapping requirements, and handles jurisdictional complexity"
+    weight: 0.35
+    description: "Comprehensive regulatory matrix"
+  - type: llm_judge
+    criteria: "SLSA Level 3 implementation is technically correct — includes hermetic builds, build provenance generation, artifact signing with Sigstore, SBOM generation (CycloneDX or SPDX), and the GitHub Actions workflow modifications needed"
+    weight: 0.35
+    description: "Correct SLSA Level 3 implementation"
+  - type: llm_judge
+    criteria: "Future-proofing strategy anticipates emerging regulations — prepares for Software Liability Act, EU AI Act CI/CD requirements, and NIST SSDF compliance before they take effect, with a regulatory monitoring process"
+    weight: 0.30
+    description: "Anticipatory future-proofing"

package/courses/github-actions-cicd/scenarios/level-5/comprehensive-cicd-system.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: comprehensive-cicd-system
+  level: 5
+  course: github-actions-cicd
+  type: output
+  description: "Design a comprehensive CI/CD system — architect a 5-layer CI/CD platform for a Fortune 500 company"
+  tags: [github, actions, comprehensive, enterprise, architecture, Fortune-500, master]
+
+state: {}
+
+trigger: |
+  You're the CTO of a Fortune 500 company ($10B revenue, 4,000
+  engineers) designing a unified CI/CD system. The company has 8
+  business units acquired over 15 years, each with different platforms,
+  processes, and cultures. The board mandated unification after a
+  regulatory finding.
+
+  Current state:
+  - BU1 Cloud (800 eng): GitHub Actions, mature, 50 deploys/day
+  - BU2 Consumer (600 eng): GitLab CI, fast, no compliance
+  - BU3 Enterprise (500 eng): Jenkins, slow, SOX/SOC 2 compliant
+  - BU4 Data (400 eng): Airflow + custom scripts, no standard CI
+  - BU5 Mobile (300 eng): Bitrise + Fastlane, iOS/Android specific
+  - BU6 IoT (200 eng): Custom embedded CI, hardware-in-loop testing
+  - BU7 Fintech (150 eng): CircleCI, PCI DSS compliant
+  - BU8 AI Lab (50 eng): No CI, Jupyter notebooks + manual deploys
+
+  Design the CI/CD system in 5 layers:
+
+  Layer 1 — Governance: Universal policies, compliance mapping (SOX,
+  SOC 2, PCI DSS, HIPAA, FedRAMP), action allowlisting, audit trails
+  Layer 2 — Platform: GitHub Actions standardization, runner fleet,
+  reusable workflows, secret management (Vault)
+  Layer 3 — Delivery: Deployment pipelines per BU (web, mobile, IoT,
+  ML, data pipelines), environment management, release automation
+  Layer 4 — Intelligence: DORA metrics, cost optimization, failure
+  prediction, anomaly detection, compliance reporting
+  Layer 5 — Experience: Developer portal, workflow catalog, self-
+  service onboarding, documentation, training
+
+  Constraints:
+  - $20M budget over 3 years
+  - Cannot disrupt any BU's current shipping velocity
+  - Must handle specialized needs (IoT hardware testing, ML GPU
+    training, mobile signing)
+  - Must satisfy 5 compliance frameworks simultaneously
+  - Must handle 10,000+ pipeline runs per day
+
+  Task: Design all 5 layers. For each, write the detailed design,
+  migration plan, interactions with other layers, and success metrics.
+  Then write: the 3-year phased roadmap, the $20M budget allocation,
+  and the board presentation for approval.
+
+assertions:
+  - type: llm_judge
+    criteria: "5-layer design is coherent — each layer builds on the one below, there are clear interfaces, and the design handles the extreme diversity of 8 BUs without over-simplifying. Specialized needs (IoT, ML, mobile) are accommodated, not forced into a single template"
+    weight: 0.35
+    description: "Coherent 5-layer design"
+  - type: llm_judge
+    criteria: "Migration plan handles complexity — phases the 8 BUs based on difficulty and business criticality, doesn't force simultaneous migration, provides BU-specific migration paths (Jenkins→Actions, GitLab→Actions, custom→Actions), and has rollback plans"
+    weight: 0.35
+    description: "Complexity-handling migration plan"
+  - type: llm_judge
+    criteria: "Budget allocation is justified — the $20M is distributed across layers, BUs, and years with clear rationale, build-vs-buy decisions for each component, and the ROI projection shows when the investment pays back"
+    weight: 0.30
+    description: "Justified budget allocation"

package/courses/github-actions-cicd/scenarios/level-5/master-cicd-shift.yaml

@@ -0,0 +1,76 @@
+meta:
+  id: master-cicd-shift
+  level: 5
+  course: github-actions-cicd
+  type: output
+  description: "Master CI/CD shift — navigate existential threats to the CI/CD platform while maintaining organizational trust and delivery velocity"
+  tags: [github, actions, shift-simulation, crisis, existential, master]
+
+state: {}
+
+trigger: |
+  You're the CTO facing a perfect storm of CI/CD-related crises that
+  threaten the company's delivery capability, compliance posture, and
+  competitive position simultaneously.
+
+  Crisis 1 — Supply chain attack:
+  A critical supply chain attack was discovered in a widely-used GitHub
+  Action (200K+ installations). The malicious version was active for
+  48 hours before detection. Your organization used this action in 85
+  repositories. The malicious code exfiltrated GITHUB_TOKEN and any
+  secrets passed to the action. GitHub has revoked the compromised
+  action but the damage may be done.
+  Questions: How many of your secrets are compromised? Was production
+  code tampered with? Can you trust any deployment from the last 48
+  hours?
+
+  Crisis 2 — Regulatory enforcement:
+  The SEC issued an enforcement action against your company for
+  "inadequate change management controls." They cite: deployments
+  without code review (12% via workflow_dispatch), missing audit trails
+  for 3 months of workflow runs (GitHub data retention expired), and
+  inability to prove who approved what change. The hearing is in 45
+  days. Legal estimates potential fines of $5-10M.
+
+  Crisis 3 — Platform vendor risk:
+  GitHub announced they're deprecating key features you depend on:
+  (a) self-hosted runner auto-scaling API changes in 60 days,
+  (b) organization-level required workflows moving to a new system,
+  (c) pricing restructure eliminating the large runner discount.
+  The changes require 3 months of engineering work with your current
+  (depleted) team.
+
+  Crisis 4 — Engineering exodus:
+  The "State of CI/CD" blog post by your competitor (the one in Crisis
+  2's news) went viral. 8 senior engineers cited it in exit interviews:
+  "Our CI/CD is years behind. I want to work somewhere with modern
+  infrastructure." Your platform team lost 5 of 15 engineers in the
+  last quarter.
+
+  Crisis 5 — Board emergency meeting:
+  The board called an emergency session in 48 hours. They want a
+  unified briefing on all 4 crises above and a strategic response.
+  Two board members are pushing to "abandon GitHub Actions entirely."
+  One board member (former CISO) is pushing to "freeze all deployments
+  until the supply chain attack is fully investigated."
+
+  Task: Navigate all 5 crises. Write: the 48-hour action plan, the
+  supply chain attack response (forensics, containment, communication),
+  the SEC response strategy (legal coordination, evidence preservation,
+  remediation), the vendor risk mitigation plan, the talent retention
+  strategy, and the board presentation that unifies everything into a
+  coherent strategic response.
+
+assertions:
+  - type: llm_judge
+    criteria: "Board presentation unifies all crises — shows interconnections (supply chain attack worsens SEC case, talent loss impacts remediation capacity), doesn't present 5 separate plans but a coherent strategy, and addresses both board extremes (abandon GitHub vs freeze deployments)"
+    weight: 0.35
+    description: "Unified crisis board presentation"
+  - type: llm_judge
+    criteria: "Supply chain response is forensically sound — identifies all 85 affected repos, traces which secrets were exfiltrated, verifies deployment integrity for the 48-hour window, rotates all compromised credentials, and implements permanent supply chain protections (SHA pinning, action allowlist)"
+    weight: 0.35
+    description: "Forensically sound supply chain response"
+  - type: llm_judge
+    criteria: "SEC response balances legal and technical — coordinates with legal counsel, preserves evidence (does not delete any data), presents a proactive remediation plan, and the corrective actions address the specific findings (workflow_dispatch controls, audit trail retention, approval documentation)"
+    weight: 0.30
+    description: "Legal-technical SEC response"

package/courses/github-pr-review/scenarios/level-2/api-change-review.yaml

@@ -0,0 +1,82 @@
+meta:
+  id: api-change-review
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Review API changes — evaluate backward compatibility, versioning strategy, and migration paths in API-modifying PRs"
+  tags: [github, pr-review, API, backward-compatibility, versioning, intermediate]
+
+state: {}
+
+trigger: |
+  You're reviewing a PR titled "Update user API — v2 endpoints." The PR
+  modifies the public REST API consumed by 3 mobile apps and 12 third-
+  party integrations. The changes include:
+
+  Change 1 — Response format change:
+  ```
+  // Before (v1)
+  GET /api/users/123
+  { "id": 123, "name": "Jane Doe", "email": "jane@example.com",
+    "created": "2024-01-15" }
+
+  // After (v2 in this PR)
+  GET /api/users/123
+  { "id": "usr_123", "fullName": "Jane Doe",
+    "contact": { "email": "jane@example.com" },
+    "metadata": { "createdAt": "2024-01-15T00:00:00Z" } }
+  ```
+
+  Change 2 — Endpoint restructuring:
+  ```
+  // Before
+  GET /api/users/:id/orders
+  POST /api/users/:id/orders
+
+  // After
+  GET /api/v2/users/:id/orders?include=items,shipping
+  POST /api/v2/orders  (userId in request body instead of URL)
+  ```
+
+  Change 3 — Authentication change:
+  ```
+  // Before: API key in query parameter
+  GET /api/users?api_key=abc123
+
+  // After: Bearer token in header
+  GET /api/v2/users
+  Authorization: Bearer <token>
+  ```
+
+  Change 4 — New pagination:
+  ```
+  // Before: offset-based
+  GET /api/users?page=2&per_page=20
+
+  // After: cursor-based
+  GET /api/v2/users?cursor=eyJpZCI6MTIzfQ&limit=20
+  ```
+
+  The PR has no migration guide, no deprecation timeline, and the old
+  endpoints are removed (not deprecated).
+
+  Task: Review the API changes. Write: the backward compatibility
+  assessment (what breaks and for whom), the versioning strategy
+  recommendation (how v1 and v2 should coexist), the migration plan for
+  consumers (timeline, communication, tooling), the review comments for
+  each change (what to keep, what to change, what to add), and the
+  checklist for future API-breaking PRs.
+
+assertions:
+  - type: llm_judge
+    criteria: "Breaking changes are comprehensively identified — field renames (name→fullName), nested restructuring (email→contact.email), ID format change (123→usr_123), endpoint moves, auth mechanism change, and pagination model change are all flagged as breaking"
+    weight: 0.35
+    description: "Comprehensive breaking change identification"
+  - type: llm_judge
+    criteria: "Versioning strategy is sound — recommends keeping v1 endpoints active with deprecation timeline (not immediate removal), API versioning approach (URL path vs header), and coexistence strategy during migration period"
+    weight: 0.35
+    description: "Sound versioning strategy"
+  - type: llm_judge
+    criteria: "Migration plan is actionable — includes consumer communication (changelog, migration guide), timeline with milestones, tooling suggestions (compatibility layer, SDK updates), and a checklist that would prevent this situation in future API PRs"
+    weight: 0.30
+    description: "Actionable migration plan"

package/courses/github-pr-review/scenarios/level-2/automated-review-tooling.yaml

@@ -0,0 +1,53 @@
+meta:
+  id: automated-review-tooling
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Set up automated review tools — configure linters, CodeQL, and automated checks to catch issues before human review"
+  tags: [github, pr-review, automation, linting, CodeQL, CI, intermediate]
+
+state: {}
+
+trigger: |
+  Your team spends 40% of review time on issues that could be caught
+  automatically: formatting inconsistencies, unused imports, type errors,
+  known vulnerability patterns, and missing test coverage. You've been
+  tasked with setting up automated review tools to reduce this burden.
+
+  Current state:
+  - TypeScript/React monorepo with Node.js backend
+  - GitHub Actions CI runs build and tests only
+  - No linting in CI (only local, inconsistently used)
+  - No security scanning
+  - No automated review comments
+  - PRs average 3 review rounds before merge (1st round is mostly
+    formatting and lint issues)
+
+  Available tools to evaluate and configure:
+  1. ESLint + Prettier (formatting/linting)
+  2. GitHub CodeQL (security analysis)
+  3. Codecov/Coveralls (test coverage reporting)
+  4. danger.js (custom PR checks: size, description, labels)
+  5. GitHub branch protection rules
+
+  Task: Design the automated review pipeline. Write: the GitHub Actions
+  workflow file(s) for the automated checks, the configuration for each
+  tool (ESLint rules focused on bugs not style, Prettier config, CodeQL
+  queries, danger.js rules for PR hygiene), the branch protection rules
+  that require these checks to pass, and the team rollout plan (how to
+  introduce without disrupting existing workflows). Include the expected
+  impact on review time and number of review rounds.
+
+assertions:
+  - type: llm_judge
+    criteria: "GitHub Actions workflow is correct and complete — runs lint, type-check, CodeQL, coverage, and danger.js as separate jobs or steps, uses proper triggers (pull_request), caches dependencies, and handles monorepo paths correctly"
+    weight: 0.35
+    description: "Complete CI workflow"
+  - type: llm_judge
+    criteria: "Tool configurations are practical — ESLint focuses on bug-catching rules over style (since Prettier handles formatting), CodeQL uses relevant queries for JS/TS, danger.js checks PR size/description/labels, and coverage thresholds are reasonable"
+    weight: 0.35
+    description: "Practical tool configurations"
+  - type: llm_judge
+    criteria: "Rollout plan is realistic — addresses existing code that won't pass new rules (baseline approach), gradual enforcement strategy, team communication, and doesn't block all PRs on day one"
+    weight: 0.30
+    description: "Realistic rollout plan"

package/courses/github-pr-review/scenarios/level-2/cross-team-review.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: cross-team-review
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Cross-team code review — review PRs outside your domain expertise, ask effective questions, and provide value without deep context"
+  tags: [github, pr-review, cross-team, knowledge-sharing, communication, intermediate]
+
+state: {}
+
+trigger: |
+  You're a frontend engineer asked to review 3 PRs from teams outside
+  your usual domain. You need to provide valuable feedback despite not
+  being a domain expert.
+
+  PR #401 — From the Data team: "Add real-time analytics pipeline"
+  You don't know Kafka or Spark, but the PR touches shared API contracts
+  your frontend consumes. Changes include:
+  - New event schema for user interactions (affects your tracking code)
+  - API response format change for the analytics dashboard endpoint
+  - New WebSocket endpoint for real-time data
+  The PR has 400 lines, good tests, but the API changes aren't
+  documented and the response format breaks backward compatibility.
+
+  PR #402 — From the Infrastructure team: "Migrate to Kubernetes"
+  You don't know K8s well, but the PR modifies environment variables and
+  deployment configuration that affect your app. Changes include:
+  - New environment variable naming convention (REACT_APP_ → NEXT_PUBLIC_)
+  - Health check endpoint added (your app needs to implement /healthz)
+  - Changed base URL configuration from hardcoded to dynamic
+  The PR is 600 lines of YAML and config, with a migration guide buried
+  in a comment.
+
+  PR #403 — From the Mobile team: "Add shared component library"
+  The mobile team is creating a shared React Native component library
+  that should share design tokens with your web components. Changes:
+  - New design token format (different from your current CSS variables)
+  - Shared TypeScript types for API responses
+  - A utility function that duplicates logic from your web codebase
+  The PR is 250 lines with no mention of the web team in the description.
+
+  Task: Review all 3 PRs. For each, write: what you can and can't
+  evaluate as a non-domain expert, the specific feedback you can provide
+  (API contracts, compatibility, shared code), the questions to ask the
+  authors (framed constructively, not "I don't understand"), and the
+  cross-team concerns to raise. Include a meta-analysis of what this
+  cross-team review experience reveals about organizational communication.
+
+assertions:
+  - type: llm_judge
+    criteria: "Reviews add value despite limited domain knowledge — identifies API contract breaks in #401, environment variable migration risks in #402, and code duplication in #403, all from the frontend perspective without pretending to understand Kafka/K8s internals"
+    weight: 0.35
+    description: "Value-adding cross-team reviews"
+  - type: llm_judge
+    criteria: "Questions are constructive and specific — asks about backward compatibility plans (not 'will this break things?'), migration timeline for env vars, and design token unification strategy, showing respect for the authors' domain expertise"
+    weight: 0.35
+    description: "Constructive cross-team questions"
+  - type: llm_judge
+    criteria: "Organizational patterns are identified — notes that cross-team PRs need better API change documentation, shared code should have cross-team visibility, and suggests process improvements (RFC for cross-team changes, shared API contract tests)"
+    weight: 0.30
+    description: "Organizational pattern recognition"

package/courses/github-pr-review/scenarios/level-2/intermediate-review-shift.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: intermediate-review-shift
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Intermediate review shift — handle a complex batch of PRs requiring security, performance, and cross-team review skills"
+  tags: [github, pr-review, shift-simulation, batch-review, intermediate]
+
+state: {}
+
+trigger: |
+  You're doing a review shift with 4 challenging PRs. Each requires
+  different intermediate skills.
+
+  PR #501 (critical, 2 hours old): "Hotfix: Rate limit the signup
+  endpoint"
+  Author: On-call engineer. Context: The signup endpoint is being
+  abused — 10,000 fake accounts created in the last hour. The fix adds
+  Redis-based rate limiting: 5 signups per IP per hour.
+  Code concern: The rate limit key is based only on IP address (easily
+  bypassed with proxies), the Redis connection has no error handling (if
+  Redis is down, all signups fail), and the rate limit response doesn't
+  include Retry-After header.
+  Urgency: Active abuse happening now.
+
+  PR #502 (medium, 1 day old): "Add real-time notifications via SSE"
+  Author: Mid-level engineer. 350 lines adding Server-Sent Events for
+  notification delivery. The implementation keeps all SSE connections in
+  a Map in memory, with no connection limit, no heartbeat, and no
+  cleanup of dead connections. In production with 50K concurrent users,
+  this would exhaust memory.
+  Tests: Only tests the happy path with 1 connection.
+
+  PR #503 (low urgency, 3 days old): "Migrate from Moment.js to
+  date-fns"
+  Author: Junior engineer. 800 lines of date library migration. Most
+  changes are mechanical (moment().format() → format(new Date())), but
+  3 timezone conversions are incorrect — they use local timezone instead
+  of UTC, which would break for users in non-UTC timezones.
+  CI: Green (tests don't cover timezone edge cases).
+
+  PR #504 (medium, 4 hours old): "Stacked PR 2/3: Add payment webhooks"
+  This is the second PR in a 3-PR stack. PR 1/3 (payment model) was
+  merged with a review comment about adding an index that was never
+  addressed. This PR adds webhook handling but references the unindexed
+  column in queries that will be called for every webhook event.
+
+  Task: Review all 4 PRs. For each, write: the priority order with
+  justification, a focused review addressing the key technical concern,
+  the decision (approve/request changes/comment) with rationale, and
+  specific code-level feedback. End with a shift summary noting patterns
+  and team-level observations.
+
+assertions:
+  - type: llm_judge
+    criteria: "Priority order balances urgency with risk — PR #501 is first (active abuse), but the review still catches security gaps in the rate limit implementation rather than rubber-stamping the hotfix. The stacked PR #504 gets attention for the carried-over tech debt"
+    weight: 0.35
+    description: "Urgency-balanced priority order"
+  - type: llm_judge
+    criteria: "Technical depth is appropriate per PR — #501 gets security-focused review (rate limit bypass, Redis failure mode), #502 gets scalability review (memory exhaustion, connection management), #503 catches timezone bugs, #504 addresses the unresolved index issue from the previous PR"
+    weight: 0.35
+    description: "Appropriate technical depth"
+  - type: llm_judge
+    criteria: "Shift summary identifies systemic issues — notes patterns across PRs (missing error handling, insufficient test coverage for edge cases, tech debt carried across stacked PRs) and recommends team-level improvements"
+    weight: 0.30
+    description: "Systemic issue identification"

package/courses/github-pr-review/scenarios/level-2/performance-review-patterns.yaml

@@ -0,0 +1,99 @@
+meta:
+  id: performance-review-patterns
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Performance-focused code review — identify N+1 queries, memory leaks, and inefficient patterns in pull requests"
+  tags: [github, pr-review, performance, N+1, memory-leaks, intermediate]
+
+state: {}
+
+trigger: |
+  You're reviewing a PR titled "Add order history page with product
+  details." The PR loads a user's order history and displays product
+  information. Review these code sections for performance issues:
+
+  Section 1 — API endpoint:
+  ```javascript
+  app.get('/api/orders', async (req, res) => {
+    const orders = await Order.findAll({ where: { userId: req.user.id } });
+    const result = [];
+    for (const order of orders) {
+      const items = await OrderItem.findAll({ where: { orderId: order.id } });
+      for (const item of items) {
+        item.product = await Product.findOne({ where: { id: item.productId } });
+        item.reviews = await Review.findAll({ where: { productId: item.productId } });
+      }
+      result.push({ ...order.toJSON(), items });
+    }
+    res.json(result);
+  });
+  ```
+
+  Section 2 — React component:
+  ```jsx
+  function OrderHistory() {
+    const [orders, setOrders] = useState([]);
+    const [enrichedOrders, setEnrichedOrders] = useState([]);
+
+    useEffect(() => {
+      fetch('/api/orders').then(r => r.json()).then(setOrders);
+    }, []);
+
+    useEffect(() => {
+      orders.forEach(async (order) => {
+        const shipping = await fetch(`/api/shipping/${order.id}`).then(r => r.json());
+        setEnrichedOrders(prev => [...prev, { ...order, shipping }]);
+      });
+    }, [orders]);
+
+    return (
+      <div>
+        {enrichedOrders.map(order => (
+          <OrderCard key={order.id} order={order} />
+        ))}
+      </div>
+    );
+  }
+  ```
+
+  Section 3 — Utility function:
+  ```javascript
+  function formatOrdersForExport(orders) {
+    const allProducts = [];
+    orders.forEach(order => {
+      order.items.forEach(item => {
+        allProducts.push(JSON.parse(JSON.stringify(item.product)));
+      });
+    });
+    return allProducts.map(p => ({
+      ...p,
+      formattedPrice: new Intl.NumberFormat('en-US', {
+        style: 'currency', currency: 'USD'
+      }).format(p.price)
+    }));
+  }
+  ```
+
+  The user has 50 orders on average, each with 3-5 items. The page
+  currently takes 8 seconds to load.
+
+  Task: Write a performance-focused review. For each section: name the
+  performance anti-pattern, estimate the impact (number of queries,
+  memory usage, render cycles), provide the optimized solution with code,
+  and explain why the optimization works. Include a summary of expected
+  performance improvement.
+
+assertions:
+  - type: llm_judge
+    criteria: "N+1 query problem is identified and fixed — Section 1 has nested N+1 queries (orders → items → products → reviews), and the fix uses eager loading (includes/joins) or batch queries to reduce from O(n*m) queries to O(1) or O(k)"
+    weight: 0.35
+    description: "N+1 query identification and fix"
+  - type: llm_judge
+    criteria: "Frontend performance issues are identified — Section 2 causes waterfall API calls (one per order), causes re-renders on every setState in the loop, and has a race condition with the enrichedOrders accumulation. Fix uses Promise.all or batched endpoint"
+    weight: 0.35
+    description: "Frontend performance issues"
+  - type: llm_judge
+    criteria: "Memory and computation waste identified — Section 3 deep-clones objects unnecessarily with JSON.parse/JSON.stringify, creates a new Intl.NumberFormat for each item instead of reusing it, and the fixes show proper optimization with minimal memory allocation"
+    weight: 0.30
+    description: "Memory and computation optimization"

package/courses/github-pr-review/scenarios/level-2/review-disagreement-resolution.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: review-disagreement-resolution
+  level: 2
+  course: github-pr-review
+  type: output
+  description: "Resolve review disagreements — handle conflicting reviewer opinions, technical disputes, and author pushback constructively"
+  tags: [github, pr-review, conflict-resolution, disagreement, communication, intermediate]
+
+state: {}
+
+trigger: |
+  You're a senior engineer mediating review disagreements on 3 PRs
+  where reviewers and authors have reached an impasse.
+
+  Dispute #1 — Architecture disagreement:
+  PR "Refactor user service to microservice" has been open for 2 weeks.
+  - Author (mid-level): Extracted the user service into a separate
+    microservice with its own database. Says it improves scalability.
+  - Reviewer A (staff engineer): "This adds unnecessary complexity.
+    We're a 10-person team. Keep it as a module in the monolith."
+  - Reviewer B (senior): "I agree with the extraction but the API
+    contract is wrong — it should use gRPC, not REST."
+  - Author: "I've already spent 3 weeks on this. I'm not rewriting it."
+  Both reviewers have valid points. The PR has 1,500 lines changed.
+
+  Dispute #2 — Style/preference war:
+  PR "Add error handling to checkout flow" has 47 review comments.
+  - Reviewer keeps requesting changes for style preferences not in the
+    style guide: single quotes vs double quotes, trailing commas,
+    function declarations vs arrow functions.
+  - Author: "These are personal preferences, not bugs. Our style guide
+    doesn't cover this. I'm not changing them."
+  - The actual error handling logic hasn't been reviewed at all.
+
+  Dispute #3 — Testing philosophy clash:
+  PR "Add payment retry logic" has 2 reviewers disagreeing:
+  - Reviewer A: "These tests mock too much. They don't test real
+    behavior. Write integration tests."
+  - Reviewer B: "Integration tests are slow and flaky. Unit tests with
+    mocks are the right approach. Ship it."
+  - Author: "I wrote what Reviewer B asked for last time. Now Reviewer A
+    wants something different. Which is it?"
+  The team has no documented testing strategy.
+
+  Task: For each dispute, write: the root cause of the disagreement
+  (technical, process, or interpersonal), the mediation approach (how
+  to move forward without picking sides), the specific resolution with
+  rationale, the process improvement to prevent recurrence, and the
+  actual review comments you would post. Include a summary of when to
+  escalate vs mediate.
+
+assertions:
+  - type: llm_judge
+    criteria: "Root causes are correctly diagnosed — Dispute #1 is a scope/architecture issue (PR too large, decision should have been made before coding), #2 is a process issue (style guide gaps), #3 is a documentation/alignment issue (no testing strategy)"
+    weight: 0.35
+    description: "Correct root cause diagnosis"
+  - type: llm_judge
+    criteria: "Resolutions are practical and fair — doesn't just pick a side, suggests concrete paths forward (e.g., for #1: scope down to module extraction without separate service, for #2: end the style war and focus on the error handling, for #3: define testing strategy then apply)"
+    weight: 0.35
+    description: "Practical and fair resolutions"
+  - type: llm_judge
+    criteria: "Process improvements prevent recurrence — suggests architectural decision records (ADRs) for #1, style guide expansion and linter rules for #2, documented testing strategy for #3, and general guidelines for when reviewers disagree"
+    weight: 0.30
+    description: "Recurrence-preventing process improvements"