dojo.md 0.1.0 → 0.2.0

package/courses/github-pr-review/scenarios/level-4/review-economics-roi.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: review-economics-roi
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Analyze review economics — calculate the true cost of code review, model ROI of review improvements, and present to executive leadership"
+  tags: [github, pr-review, economics, ROI, cost-analysis, expert]
+
+state: {}
+
+trigger: |
+  You're the Director of Engineering presenting a business case to the
+  CFO for investing in code review infrastructure. The CFO's question:
+  "Code review costs us millions in engineer time. How do we know it's
+  worth it? And if we invest more, what's the return?"
+
+  Data you've collected:
+  - 600 engineers, average fully-loaded cost: $200K/year ($100/hour)
+  - Average engineer spends 6 hours/week on code review
+  - That's 600 × 6 × 52 = 187,200 review hours/year = $18.7M/year
+  - Average PR takes 25 minutes to review
+  - 78,000 PRs merged per year
+
+  Cost of review failures (incidents traced to review gaps):
+  - 12 production incidents/year attributed to review failures
+  - Average incident cost: $150K (engineering time, customer impact,
+    reputation)
+  - 3 compliance findings in last audit: $500K in remediation + fines
+  - 2 security vulnerabilities that passed review: $800K total impact
+  - Total cost of review failures: $3.5M/year
+
+  Proposed investments:
+  1. Review automation platform: $800K (build) + $200K/year (maintain)
+     Expected: Reduce review time by 30%, catch 60% of style issues
+  2. Reviewer training program: $150K/year
+     Expected: Reduce review rounds by 25%, improve bug detection by 15%
+  3. AI-assisted review: $300K/year (tooling)
+     Expected: Reduce first-review time by 40%, flag 50% of common issues
+  4. Review analytics dashboard: $200K (build) + $50K/year (maintain)
+     Expected: Identify bottlenecks, reduce merge time by 20%
+
+  Task: Build the complete economic model. Write: the true cost of
+  code review (including hidden costs like context switching, blocked
+  PRs, opportunity cost), the value model (what code review prevents,
+  quantified), the ROI analysis for each investment (with sensitivity
+  analysis), the 3-year financial projection, and the executive
+  presentation (2-page summary the CFO can present to the board).
+  Include the assumptions, risks, and what metrics to track to validate
+  the projections.
+
+assertions:
+  - type: llm_judge
+    criteria: "Cost model includes hidden costs — beyond the $18.7M direct cost, includes context-switching costs (review interrupting deep work), blocked PR costs (engineers waiting for review), and opportunity cost (what engineers could build instead of reviewing)"
+    weight: 0.35
+    description: "Complete cost model with hidden costs"
+  - type: llm_judge
+    criteria: "ROI analysis is rigorous — each investment has NPV calculation, payback period, sensitivity analysis (what if improvements are 50% less than expected?), and the analysis accounts for interaction effects (automation + training together may have compounding benefits)"
+    weight: 0.35
+    description: "Rigorous ROI analysis"
+  - type: llm_judge
+    criteria: "Executive presentation is CFO-ready — leads with the business impact (not technical details), quantifies the 'do nothing' cost, presents investment options with clear ROI comparison, and includes metrics to track for accountability"
+    weight: 0.30
+    description: "CFO-ready executive presentation"

package/courses/github-pr-review/scenarios/level-4/review-executive-communication.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: review-executive-communication
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Executive communication about review — present review process health, investments, and strategy to C-suite and board audiences"
+  tags: [github, pr-review, executive, communication, strategy, expert]
+
+state: {}
+
+trigger: |
+  You're the CTO preparing 3 different communications about code review
+  for executive audiences with different concerns.
+
+  Communication 1 — Board of Directors quarterly update:
+  The board wants to understand "engineering quality" as a competitive
+  advantage. They've heard competitors are shipping faster. Your data:
+  - Code review catches 65% of bugs before production
+  - Average merge time: 1.8 days (industry median: 2.5 days)
+  - Review-related incidents: 4/quarter (down from 12 last year)
+  - Review investment: $3.2M/year (5.3% of engineering budget)
+  - Developer satisfaction with review: 78% (up from 45% last year)
+  The board asks: "Are we over-investing in review at the expense of
+  shipping speed?"
+
+  Communication 2 — CEO 1:1 escalation:
+  The Head of Product is complaining that code review is the #1
+  bottleneck to shipping features. They want to reduce required reviews
+  from 2 to 0 for "low-risk" PRs and allow self-merge for senior
+  engineers. Your security team says this violates SOC 2 controls. The
+  CEO wants your recommendation by Friday.
+
+  Communication 3 — All-hands engineering presentation:
+  The annual engineering all-hands is next week. You want to present
+  the "State of Code Review" — celebrating improvements, acknowledging
+  remaining challenges, and building excitement for the review platform
+  investment. Your audience is 600 engineers ranging from interns to
+  distinguished engineers.
+
+  Task: Write all 3 communications. For each: adapt the message to the
+  audience (board speaks business/risk, CEO wants a decision framework,
+  engineers want to understand the "why"), use data effectively (board
+  gets trends and benchmarks, CEO gets risk analysis, engineers get
+  impact stories), and include clear asks or next steps. The board
+  update should be 1 page, the CEO memo should be 2 pages with a
+  recommendation, and the all-hands should be an outline with speaker
+  notes.
+
+assertions:
+  - type: llm_judge
+    criteria: "Board communication speaks business language — frames review as risk management and competitive advantage (not engineering process), uses industry benchmarks to show strong performance, and answers the 'over-investing' question with data showing declining incidents and competitive merge times"
+    weight: 0.35
+    description: "Business-language board communication"
+  - type: llm_judge
+    criteria: "CEO memo provides a clear recommendation — doesn't just present options, takes a position on the self-merge request with risk analysis, proposes a middle ground that addresses product's velocity concerns while maintaining compliance, and includes a decision framework for future review policy changes"
+    weight: 0.35
+    description: "Decision-ready CEO memo"
+  - type: llm_judge
+    criteria: "All-hands presentation engages engineers — celebrates specific team and individual contributions, uses concrete impact stories (not just metrics), acknowledges pain points honestly, and builds excitement for the review platform investment with a clear vision"
+    weight: 0.30
+    description: "Engineer-engaging all-hands"

package/courses/github-pr-review/scenarios/level-4/review-incident-postmortem.yaml

@@ -0,0 +1,69 @@
+meta:
+  id: review-incident-postmortem
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Conduct review process postmortems — lead blameless investigations into systemic review failures and implement organizational improvements"
+  tags: [github, pr-review, postmortem, incident-response, process-improvement, expert]
+
+state: {}
+
+trigger: |
+  You're the Head of Engineering conducting a postmortem after the most
+  serious review-related incident in company history. A payment
+  processing bug caused $2.3M in duplicate charges over 72 hours before
+  detection.
+
+  Incident timeline:
+  - Day 0: PR #4521 "Optimize payment batch processing" submitted by a
+    senior engineer (800 lines, refactoring payment job scheduler)
+  - Day 1: First review by a mid-level engineer — "LGTM, nice refactor"
+    (spent 8 minutes on 800 lines based on GitHub activity timestamps)
+  - Day 1: Second review by another mid-level — requested minor naming
+    change, then approved after the change was made
+  - Day 2: PR merged after CI passed (all 247 tests green)
+  - Day 3: Deployed to production via automated pipeline
+  - Day 5: Customer reports duplicate charges. Investigation begins
+  - Day 6: Root cause identified — race condition in the batch scheduler
+    that causes payment jobs to be processed twice under high load
+  - Day 8: Hotfix deployed. Customer refund process begins
+
+  Review failures identified:
+  1. Neither reviewer had payment domain expertise (CODEOWNERS didn't
+     include the batch scheduler directory)
+  2. The 8-minute review of 800 lines was clearly insufficient
+  3. The race condition was subtle but identifiable with careful review
+     of the concurrency logic
+  4. Test coverage was high (85%) but no tests simulated concurrent
+     execution or high-load conditions
+  5. The PR was marked "refactoring" which reduced perceived risk
+  6. The senior author's reputation created unconscious trust bias
+
+  Additional context:
+  - The payment team lost their tech lead 2 months ago (not replaced)
+  - CODEOWNERS for payment code points to a team that was reorganized
+  - The review SLA pressure (merge within 1 day) may have rushed reviews
+  - 3 similar but smaller incidents occurred in the past year
+
+  Task: Lead the postmortem. Write: the blameless incident analysis
+  (contributing factors at the individual, team, process, and
+  organizational levels), the immediate fixes (what changes this week),
+  the systemic improvements (what changes in 30/60/90 days), the review
+  process changes specifically for payment/financial code, and the
+  executive summary for the board (including financial impact and
+  remediation plan). Address the pattern of 3 similar incidents and why
+  previous fixes didn't prevent this one.
+
+assertions:
+  - type: llm_judge
+    criteria: "Analysis is truly blameless — doesn't blame the 8-minute reviewer or the senior author, instead identifies systemic factors: outdated CODEOWNERS, missing domain expertise after tech lead departure, SLA pressure encouraging superficial reviews, and trust bias toward senior engineers"
+    weight: 0.35
+    description: "Truly blameless analysis"
+  - type: llm_judge
+    criteria: "Improvements address all levels — individual (reviewer training on concurrency), team (payment domain expertise gap), process (CODEOWNERS update, risk-based review requirements), and organizational (SLA policy that doesn't incentivize rubber-stamping)"
+    weight: 0.35
+    description: "Multi-level improvements"
+  - type: llm_judge
+    criteria: "Pattern analysis explains why previous fixes failed — the 3 prior incidents likely led to narrow fixes (fix the specific bug) rather than systemic changes, and this postmortem addresses the meta-problem of why postmortem action items aren't preventing recurrence"
+    weight: 0.30
+    description: "Pattern-breaking analysis"

package/courses/github-pr-review/scenarios/level-4/review-org-design.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: review-org-design
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Design review organization — build teams and roles dedicated to code review excellence, training, and tooling"
+  tags: [github, pr-review, org-design, teams, roles, career-paths, expert]
+
+state: {}
+
+trigger: |
+  You're the SVP of Engineering creating a dedicated "Developer
+  Productivity" organization that includes a Code Review Excellence
+  team. The company has 600 engineers and the CEO has approved headcount
+  for this new function.
+
+  The mandate:
+  - Reduce average merge time from 3 days to 1 day
+  - Reduce review-related production incidents by 80%
+  - Achieve 90%+ developer satisfaction with the review process (from
+    current 45%)
+  - Build review tooling and automation as a platform
+  - Create a reviewer training and certification program
+  - Establish review standards that scale with the company
+
+  Available headcount: 12 FTEs
+  Budget: $500K/year for tooling (separate from headcount)
+
+  Questions to answer:
+  1. What roles do you need? (Platform engineers, program managers,
+     trainers, data analysts?)
+  2. How does this team interact with the 50 product teams?
+  3. Where does this team sit in the org chart?
+  4. What does the career ladder look like for "review excellence"?
+  5. How do you avoid becoming a bottleneck or bureaucratic overhead?
+  6. What does success look like at 6 months, 1 year, and 2 years?
+
+  Constraint: The engineering culture values autonomy. Any centralized
+  function risks being seen as "the review police." You need buy-in from
+  team leads.
+
+  Task: Design the organization. Write: the team structure (roles,
+  responsibilities, reporting lines), the interaction model with product
+  teams (embedded vs centralized vs hybrid), the career ladder for review
+  excellence roles, the buy-in strategy (how to get team lead support
+  without being "review police"), the phased roadmap (what to deliver at
+  6 months, 1 year, 2 years), and the success metrics with accountability
+  framework.
+
+assertions:
+  - type: llm_judge
+    criteria: "Team structure is well-designed — includes platform engineers (build tooling), program managers (process), trainers (education), and data analysts (metrics), with clear roles and not too top-heavy for a 12-person team"
+    weight: 0.35
+    description: "Well-designed team structure"
+  - type: llm_judge
+    criteria: "Interaction model preserves autonomy — uses an enabling/platform model (not command-and-control), product teams opt in to services, the team provides tools and training rather than mandates, and the 'review police' perception is actively countered"
+    weight: 0.35
+    description: "Autonomy-preserving interaction model"
+  - type: llm_judge
+    criteria: "Career ladder is viable — creates career progression for review excellence roles (not a dead-end), connects to broader developer productivity career paths, and provides incentives for engineers to specialize in this area"
+    weight: 0.30
+    description: "Viable career ladder"

package/courses/github-pr-review/scenarios/level-4/review-platform-architecture.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: review-platform-architecture
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Architect a review platform — design the technical architecture for a company-wide review automation and analytics platform"
+  tags: [github, pr-review, architecture, platform, automation, expert]
+
+state: {}
+
+trigger: |
+  You're the Staff Engineer tasked with building an internal "Review
+  Platform" — a centralized system that orchestrates code review across
+  your 600-engineer organization. The platform replaces a patchwork of
+  scripts, bots, and manual processes.
+
+  Platform requirements:
+  1. Unified reviewer assignment across all repos and GitHub orgs
+  2. Risk-based review routing (auto-classify PRs by risk level and
+     route to appropriate reviewers)
+  3. Real-time review analytics dashboard
+  4. Compliance audit trail generator
+  5. Integration with GitHub, GitLab, Slack, Jira, PagerDuty
+  6. AI-assisted review suggestions (flag potential issues before human
+     review)
+  7. Custom review workflows (different flows for different teams/repos)
+
+  Scale requirements:
+  - 200+ repos across 3 GitHub orgs
+  - 1,500 PRs per week
+  - 50ms p99 latency for webhook processing
+  - 99.9% uptime (review platform down = all merges blocked)
+  - 30-day event replay for debugging
+  - Horizontal scalability for 3x growth
+
+  Technical constraints:
+  - Must run on existing Kubernetes cluster
+  - Must use existing PostgreSQL and Redis infrastructure
+  - GitHub API rate limits: 5,000/hour per installation
+  - Must handle GitHub webhook delivery guarantees (at-least-once)
+  - Must support gradual rollout (repo by repo)
+
+  Task: Design the platform architecture. Write: the system design
+  (components, data flow, storage, event processing), the API design
+  (internal APIs for team customization), the scalability strategy
+  (how to handle 1,500 PRs/week within rate limits, horizontal scaling
+  plan), the reliability design (what happens when the platform is down,
+  circuit breakers, graceful degradation), and the deployment strategy
+  (gradual rollout, feature flags, rollback plan). Include architecture
+  diagrams (text-based) and key technical decisions with trade-offs.
+
+assertions:
+  - type: llm_judge
+    criteria: "Architecture handles the scale — event-driven design with webhook receivers, job queues, and workers that handle 1,500 PRs/week within API rate limits. Includes rate limit pooling across 3 GitHub orgs and back-pressure mechanisms"
+    weight: 0.35
+    description: "Scale-handling architecture"
+  - type: llm_judge
+    criteria: "Reliability is enterprise-grade — graceful degradation when platform is down (PRs can still be merged manually), circuit breakers for external services, idempotent webhook processing (at-least-once handling), and 30-day event replay for debugging"
+    weight: 0.35
+    description: "Enterprise-grade reliability"
+  - type: llm_judge
+    criteria: "Deployment strategy is low-risk — gradual rollout repo by repo, feature flags for each capability, rollback plan that doesn't disrupt ongoing reviews, and the platform can be disabled per-repo without affecting others"
+    weight: 0.30
+    description: "Low-risk deployment strategy"

package/courses/github-pr-review/scenarios/level-4/review-training-program.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: review-training-program
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Design reviewer training program — create a comprehensive curriculum for building review expertise across seniority levels"
+  tags: [github, pr-review, training, education, certification, expert]
+
+state: {}
+
+trigger: |
+  You're designing a company-wide code review training program for your
+  600-engineer organization. The program should transform review from a
+  chore into a valued skill with career impact.
+
+  Current problems the training must address:
+  - New hires take 3+ months before their reviews add value
+  - 30% of review comments are preferences, not issues
+  - Reviewers miss bugs because they focus on style
+  - Senior engineers' reviews are rubber-stamped ("too experienced to
+    question")
+  - No one teaches how to write good review comments
+  - Reviewers don't know when to approve vs request changes
+  - Cross-domain reviews (backend reviewer on frontend PR) are shallow
+
+  Target audience tiers:
+  1. New hires / juniors: First-time reviewers who need fundamentals
+  2. Mid-level engineers: Competent reviewers who need depth and breadth
+  3. Senior / staff engineers: Experienced reviewers who need to review
+     architecture and mentor through reviews
+  4. Engineering managers: Need to evaluate review quality and coach
+
+  Available formats:
+  - Self-paced online modules (budget: $50K to build)
+  - Live workshops (budget: $30K/year, monthly cadence)
+  - Shadow reviewing program (pair reviewing with a mentor)
+  - Review certification (gamification to incentivize learning)
+  - Practice exercises with curated PRs (real anonymized examples)
+
+  Constraints:
+  - Maximum 2 hours/month of training time per engineer
+  - Must show measurable improvement within 3 months
+  - Must not feel punitive (training shouldn't be "you review badly")
+  - Must work for remote-first company (75% remote)
+
+  Task: Design the complete training program. Write: the curriculum for
+  each tier (learning objectives, modules, exercises), the shadow
+  reviewing program design (matching, structure, graduation criteria),
+  the certification system (levels, requirements, incentives, badge
+  visibility), the measurement framework (how to prove training works),
+  and the rollout plan (who goes first, how to drive adoption without
+  mandating). Include sample exercise materials for each tier.
+
+assertions:
+  - type: llm_judge
+    criteria: "Curriculum is tier-appropriate — juniors learn fundamentals (comment types, approval criteria, etiquette), mid-level learn depth (security review, performance review, architecture), seniors learn strategic review and mentoring, and managers learn to evaluate and coach review quality"
+    weight: 0.35
+    description: "Tier-appropriate curriculum"
+  - type: llm_judge
+    criteria: "Shadow reviewing program is well-structured — includes matching criteria (expertise, personality, timezone), session structure (observe → co-review → independent with feedback), graduation criteria, and scales beyond 1:1 mentoring"
+    weight: 0.35
+    description: "Well-structured shadow program"
+  - type: llm_judge
+    criteria: "Measurement framework proves ROI — tracks leading indicators (comment quality scores, training completion) and lagging indicators (review-related incidents, merge time, developer satisfaction), with a control group or before/after comparison design"
+    weight: 0.30
+    description: "ROI-proving measurement framework"

package/courses/github-pr-review/scenarios/level-4/review-vendor-evaluation.yaml

@@ -0,0 +1,76 @@
+meta:
+  id: review-vendor-evaluation
+  level: 4
+  course: github-pr-review
+  type: output
+  description: "Evaluate review tool vendors — conduct a thorough evaluation of code review platforms, AI review tools, and analytics vendors"
+  tags: [github, pr-review, vendor-evaluation, procurement, tooling, expert]
+
+state: {}
+
+trigger: |
+  You're leading the vendor evaluation for code review tooling. The
+  company has budget for 1-2 tools and needs a recommendation within
+  30 days. Your 600-engineer organization currently uses GitHub's native
+  review features with some custom scripts.
+
+  Vendors to evaluate:
+
+  Vendor A — ReviewBot Pro ($15/user/month):
+  - AI-powered code review with custom model training
+  - Automated reviewer assignment based on expertise
+  - Review analytics dashboard
+  - Claims: "Reduces review time by 50%"
+  - Integration: GitHub, GitLab, Bitbucket
+  - Security: SOC 2 Type II certified, code never leaves your network
+  - Concerns: requires GitHub App with broad repo permissions, new
+    startup (2 years old, Series A)
+
+  Vendor B — CodeGuard Enterprise ($25/user/month):
+  - Security-focused review automation (SAST, dependency scanning)
+  - Compliance reporting (SOC 2, PCI, HIPAA)
+  - Custom policy engine (enforce review rules per repo)
+  - Claims: "Catches 70% of security issues before human review"
+  - Integration: GitHub only
+  - Security: FedRAMP authorized, self-hosted option available
+  - Concerns: expensive, long implementation timeline (3-6 months)
+
+  Vendor C — DevMetrics ($8/user/month):
+  - Review analytics and team performance dashboards
+  - Review SLA tracking and alerting
+  - Developer experience surveys integrated with review data
+  - Claims: "Teams using DevMetrics improve merge time by 35%"
+  - Integration: GitHub, Jira, Slack
+  - Security: SOC 2 Type I, cloud only
+  - Concerns: analytics only (no automation), uses anonymized data for
+    their own ML model training
+
+  Vendor D — Open source alternative (Danger.js + custom GitHub Actions):
+  - Free, fully customizable
+  - Active community
+  - No vendor lock-in
+  - Concerns: maintenance burden (estimated 0.5 FTE), limited analytics,
+    no AI capabilities, no support SLA
+
+  Task: Conduct the vendor evaluation. Write: the evaluation framework
+  (weighted criteria matrix), the detailed assessment of each vendor
+  (strengths, weaknesses, risks), the total cost of ownership analysis
+  (3-year TCO including implementation, maintenance, training), the
+  security and privacy assessment (data handling, permissions, vendor
+  risk), and the recommendation memo (which vendor(s) to choose, with
+  implementation plan and exit strategy). Include the pilot program
+  design to validate the choice.
+
+assertions:
+  - type: llm_judge
+    criteria: "Evaluation framework is rigorous — weighted criteria include functionality, security, cost, integration complexity, vendor viability (startup risk for Vendor A), scalability, and exit strategy. Weights reflect the organization's priorities"
+    weight: 0.35
+    description: "Rigorous evaluation framework"
+  - type: llm_judge
+    criteria: "TCO analysis is complete — includes license costs, implementation effort, ongoing maintenance, training, and hidden costs (productivity loss during migration, vendor lock-in costs). Compares 3-year TCO across all options including the open-source alternative"
+    weight: 0.35
+    description: "Complete TCO analysis"
+  - type: llm_judge
+    criteria: "Recommendation is well-reasoned — makes a specific recommendation (not 'it depends'), addresses security concerns (especially Vendor C's data usage), includes a pilot program to validate before full rollout, and has an exit strategy for each vendor"
+    weight: 0.30
+    description: "Well-reasoned recommendation"

package/courses/github-pr-review/scenarios/level-5/comprehensive-review-system.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: comprehensive-review-system
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Design comprehensive review system — architect a 5-layer review system for a Fortune 500 technology company"
+  tags: [github, pr-review, comprehensive, enterprise, architecture, master]
+
+state: {}
+
+trigger: |
+  You're the CTO of a Fortune 500 technology company ($8B revenue, 3,000
+  engineers) designing a unified code review system. The company has 6
+  business units acquired over 10 years, each with different tooling,
+  processes, and cultures. The board has mandated unification after a
+  regulatory finding that change management controls were "inconsistent
+  and insufficient."
+
+  Current state by business unit:
+  - Cloud Platform (600 eng): GitHub Enterprise, mature review process
+  - Consumer Apps (500 eng): GitHub Cloud, fast-moving, minimal process
+  - Enterprise Software (400 eng): GitLab, heavyweight review gates
+  - Data & Analytics (300 eng): Mix of GitHub and Jupyter, informal
+  - IoT/Embedded (200 eng): Gerrit, hardware-focused review needs
+  - Recently acquired AI startup (200 eng): No formal process, pair
+    programming culture
+
+  Design the review system in 5 layers:
+
+  Layer 1 — Governance: Universal policies, compliance mapping (SOX,
+  SOC 2, PCI DSS, HIPAA, FedRAMP across different BUs), audit trail
+  Layer 2 — Platform: Unified tooling, migration from 4 VCS platforms
+  to GitHub Enterprise, custom automation
+  Layer 3 — Process: Review workflows per risk level, SLAs, escalation,
+  cross-BU reviews for shared code
+  Layer 4 — Intelligence: AI-powered review, analytics, predictive
+  quality, anomaly detection
+  Layer 5 — Culture: Training, certification, incentives, career paths,
+  developer experience
+
+  Constraints:
+  - $10M budget over 3 years
+  - Cannot disrupt any BU's shipping velocity during migration
+  - Must satisfy 6 different compliance frameworks simultaneously
+  - Must handle 5,000+ PRs per week across all BUs
+  - IoT/Embedded team has legitimate needs for Gerrit's change-based
+    review model
+  - Board expects quarterly progress reports
+
+  Task: Design all 5 layers. For each, write: the detailed design, the
+  migration/implementation plan, the interaction with other layers, and
+  the success metrics. Then write: the 3-year phased roadmap with
+  quarterly milestones, the $10M budget allocation, the organizational
+  model (who owns each layer), 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 between layers, and the design handles the complexity of 6 BUs without over-simplifying. The IoT/Gerrit exception is handled gracefully (bridge or adapter, not forced migration)"
+    weight: 0.35
+    description: "Coherent 5-layer design"
+  - type: llm_judge
+    criteria: "Migration plan is realistic — handles the 4-to-1 VCS consolidation without disrupting shipping, phases the migration BU by BU, has rollback plans for each phase, and the 3-year timeline with quarterly milestones is achievable"
+    weight: 0.35
+    description: "Realistic migration plan"
+  - type: llm_judge
+    criteria: "Budget allocation is justified — the $10M is distributed across layers and years with clear rationale, the build-vs-buy decisions are made for each component, and the ROI projection shows when the investment pays back through reduced incidents, compliance costs, and engineering productivity"
+    weight: 0.30
+    description: "Justified budget allocation"

package/courses/github-pr-review/scenarios/level-5/master-review-shift.yaml

@@ -0,0 +1,73 @@
+meta:
+  id: master-review-shift
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Master review shift — navigate existential threats to the review function while maintaining organizational trust and shipping velocity"
+  tags: [github, pr-review, shift-simulation, crisis, existential, master]
+
+state: {}
+
+trigger: |
+  You're the CTO facing a perfect storm of review-related challenges
+  that threaten the company's engineering capability, compliance
+  posture, and competitive position simultaneously.
+
+  Crisis 1 — Regulatory investigation:
+  The SEC is investigating your company's software change management
+  practices after a financial reporting error was traced to a code
+  change that bypassed review. They've subpoenaed 2 years of code
+  review records. Your legal team discovers that 12% of production
+  changes in the financial reporting codebase have incomplete review
+  trails. The SEC hearing is in 6 weeks.
+
+  Crisis 2 — Competitive disruption:
+  Your main competitor just announced "Zero-Review Deployment" — they
+  claim AI reviews 100% of their code and human review is optional.
+  Their merge time is 30 minutes vs your 2 days. Your board is asking
+  why you're "falling behind on AI adoption." Three VP-level candidates
+  withdrew from your hiring pipeline citing your "slow engineering
+  culture."
+
+  Crisis 3 — Platform outage:
+  Your GitHub Enterprise instance suffered a data corruption event.
+  The review history for 6 months of PRs is unrecoverable. This affects
+  your SOC 2 audit evidence, your review analytics baseline, and your
+  AI review model training data. GitHub's recovery ETA is "weeks."
+
+  Crisis 4 — Talent exodus:
+  Your top 3 review tooling engineers (out of 12) just gave notice —
+  they're joining the competitor from Crisis 2. They built the core
+  review automation platform and have institutional knowledge that's
+  not documented. Their last day is in 2 weeks.
+
+  Crisis 5 — Board pressure:
+  The board is meeting in 48 hours for an emergency session. They want
+  a unified briefing on all 4 crises above and a strategic response.
+  Two board members are pushing to "just adopt AI review like the
+  competitor." One board member (former regulator) is pushing to "freeze
+  all deployments until review gaps are fixed."
+
+  Task: Navigate all 5 crises. Write: the 48-hour action plan for the
+  board meeting, the SEC response strategy (what to present, what to
+  remediate, legal coordination), the competitive response (how to
+  address the AI review narrative without panic), the platform recovery
+  plan (data recovery, interim process, audit evidence reconstruction),
+  the talent retention and knowledge transfer plan, and the board
+  presentation that unifies all crises into a coherent strategic
+  response. Show how the crises interconnect and the risks of solving
+  one at the expense of others.
+
+assertions:
+  - type: llm_judge
+    criteria: "Board presentation unifies the crises — shows the interconnections (SEC investigation + data loss = compounded compliance risk, competitor + talent loss = capability risk), doesn't present 5 separate plans but a unified strategy, and addresses both board member extremes (AI adoption vs deployment freeze)"
+    weight: 0.35
+    description: "Unified crisis board presentation"
+  - type: llm_judge
+    criteria: "SEC response is legally sound — coordinates with legal counsel, presents a proactive remediation plan rather than defensive posture, addresses the 12% review gap with root cause analysis and corrective actions, and the audit evidence reconstruction plan is credible"
+    weight: 0.35
+    description: "Legally sound SEC response"
+  - type: llm_judge
+    criteria: "Competitive response is strategic not reactive — doesn't panic-adopt AI review to match competitor, analyzes the competitor's claim critically (is 'zero-review' actually safe for financial software?), proposes an AI adoption roadmap that's faster but responsible, and addresses the hiring pipeline impact"
+    weight: 0.30
+    description: "Strategic competitive response"