dojo.md 0.1.0 → 0.2.0

package/courses/github-pr-review/scenarios/level-5/review-ai-future.yaml

@@ -0,0 +1,69 @@
+meta:
+  id: review-ai-future
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Design the future of AI-powered review — architect next-generation review systems where AI and humans collaborate on code quality"
+  tags: [github, pr-review, AI, future, ML-systems, architecture, master]
+
+state: {}
+
+trigger: |
+  You're the VP of AI/ML at a developer tools company building the
+  next generation of AI-powered code review. Your product serves 10,000
+  organizations and reviews 2M PRs per month. You need to design the
+  AI system that will define how code review works in 2027-2030.
+
+  Current capabilities (baseline):
+  - Style and formatting checks (commoditized, 95% accuracy)
+  - Common bug pattern detection (70% accuracy, 15% false positive rate)
+  - Automated review comment generation (50% helpfulness rating)
+  - PR risk scoring based on file types and historical data
+
+  Target capabilities (next 3 years):
+  1. Semantic code understanding: Understand what code does (not just
+     syntax), detect logical errors, and reason about business logic
+  2. Repository-aware review: Understand the full codebase context,
+     architectural patterns, and team conventions
+  3. Personalized review: Adapt review depth and style to the author's
+     experience level and team's preferences
+  4. Predictive review: Flag potential issues before they become bugs
+     based on historical patterns and similar code in other repos
+  5. Review orchestration: Dynamically assign human reviewers based on
+     what AI can vs cannot confidently review, optimizing human time
+
+  Constraints:
+  - Customer code must never leave their tenant (privacy-critical)
+  - False positives destroy trust — must be under 5%
+  - Must work with GitHub's review UI (not a separate tool)
+  - Must handle 2M PRs/month at current scale, 10M at target scale
+  - Enterprise customers require explainable AI decisions
+
+  Ethical considerations:
+  - AI review shouldn't replace the learning benefits of human review
+  - AI shouldn't create surveillance of developer performance
+  - AI decisions on code quality must be transparent and contestable
+  - AI training data must not leak code between customers
+
+  Task: Design the next-generation AI review system. Write: the product
+  vision (what review looks like in 2030), the technical architecture
+  (models, training, inference, privacy), the human-AI collaboration
+  model (when AI leads, when humans lead, how they interact), the
+  ethical framework (principles, guardrails, transparency mechanisms),
+  and the go-to-market roadmap (what to ship when, how to build trust
+  progressively). Include the key technical challenges and proposed
+  solutions.
+
+assertions:
+  - type: llm_judge
+    criteria: "Product vision is compelling and specific — paints a concrete picture of review in 2030 (not vague 'AI will review everything'), with specific scenarios showing human-AI collaboration, and acknowledges what AI will and won't be able to do"
+    weight: 0.35
+    description: "Compelling specific product vision"
+  - type: llm_judge
+    criteria: "Technical architecture handles constraints — solves the privacy problem (per-tenant models or federated learning), scales to 10M PRs/month, keeps false positives under 5% with confidence calibration, and integrates with GitHub's UI natively"
+    weight: 0.35
+    description: "Constraint-handling technical architecture"
+  - type: llm_judge
+    criteria: "Ethical framework is substantive — goes beyond platitudes to specific guardrails (e.g., AI review scores are never used in performance reviews, developers can always override AI, AI explanations are required for any blocking comment), with enforcement mechanisms"
+    weight: 0.30
+    description: "Substantive ethical framework"

package/courses/github-pr-review/scenarios/level-5/review-behavioral-science.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: review-behavioral-science
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Apply behavioral science to code review — use psychology and behavioral economics to improve review quality, speed, and developer experience"
+  tags: [github, pr-review, behavioral-science, psychology, nudges, master]
+
+state: {}
+
+trigger: |
+  You're the Head of Developer Experience applying behavioral science
+  principles to code review. Despite having good tools, processes, and
+  training, review quality and speed haven't improved in 18 months.
+  You hypothesize that cognitive biases and behavioral patterns are the
+  root cause.
+
+  Observed behavioral patterns:
+  1. Authority bias: Senior engineers' PRs get approved 2x faster with
+     50% fewer comments than junior engineers' identical code changes
+     (tested with anonymized blind reviews)
+  2. Anchoring effect: The first reviewer's decision heavily influences
+     subsequent reviewers — if the first review is "LGTM," 85% of
+     second reviewers also approve without substantive feedback
+  3. Sunk cost fallacy: Large PRs that have been in review for days
+     get approved despite issues because "we've already invested so
+     much time reviewing this"
+  4. Status quo bias: Reviewers are 3x more likely to approve code that
+     follows existing patterns (even bad patterns) than code that
+     introduces better but unfamiliar patterns
+  5. Social loafing: PRs with 3+ required reviewers get less thorough
+     individual reviews than PRs with 1 required reviewer (diffusion
+     of responsibility)
+  6. Peak-end rule: Developers' overall satisfaction with review is
+     determined by their worst review experience and their most recent
+     experience, not the average
+
+  Available data:
+  - 2 years of review data (50,000 PRs) with timestamps, comments,
+    outcomes, and post-merge incident correlation
+  - Developer satisfaction surveys (quarterly, 600 respondents)
+  - Blind review experiment results (100 anonymized PRs)
+  - Focus group transcripts from 8 teams
+
+  Task: Design a behavioral intervention program. For each bias, write:
+  the evidence from your data, the behavioral intervention (nudge,
+  choice architecture, or environmental design), the implementation
+  plan (how to embed the intervention in the review workflow), and the
+  measurement approach (A/B test design to prove the intervention works).
+  Then write the unified "Behavioral Code Review" framework that ties
+  all interventions together, and the ethical considerations (when does
+  nudging become manipulation?).
+
+assertions:
+  - type: llm_judge
+    criteria: "Behavioral interventions are evidence-based — each intervention addresses a specific bias with a specific mechanism (e.g., randomized review order to reduce anchoring, blind review for authority bias, single-reviewer assignment to reduce social loafing), not generic 'educate people about biases'"
+    weight: 0.35
+    description: "Evidence-based interventions"
+  - type: llm_judge
+    criteria: "A/B test designs are rigorous — each intervention has a testable hypothesis, control group, sample size consideration, and success metric. The experiment design accounts for confounding variables and ethical review"
+    weight: 0.35
+    description: "Rigorous A/B test designs"
+  - type: llm_judge
+    criteria: "Ethical framework is thoughtful — distinguishes between nudging (preserving choice) and manipulation, addresses transparency (should developers know they're being nudged?), and sets limits on behavioral interventions in the workplace"
+    weight: 0.30
+    description: "Thoughtful ethical framework"

package/courses/github-pr-review/scenarios/level-5/review-board-strategy.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: review-board-strategy
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Board-level review strategy — present code review as a strategic capability to the board of directors of a public company"
+  tags: [github, pr-review, board, strategy, governance, master]
+
+state: {}
+
+trigger: |
+  You're the CTO of a $3B public company presenting to the board of
+  directors. The board has 3 agenda items related to code review, driven
+  by recent events.
+
+  Agenda Item 1 — Risk governance after a competitor's review failure:
+  A competitor had a catastrophic production failure (48-hour outage,
+  $200M revenue impact) traced to a code change that bypassed review.
+  The board wants assurance that "it can't happen here." They want to
+  understand your change management controls and whether code review
+  is a governance strength or weakness.
+
+  Your data:
+  - 99.7% of production changes go through code review
+  - 0.3% are emergency changes with post-deployment review
+  - No review-related incidents exceeded $500K in the last 3 years
+  - SOC 2, PCI DSS, and SOX compliance are current
+  - Review process is audited quarterly
+
+  Agenda Item 2 — AI strategy for code review:
+  The board read about AI replacing code review in a McKinsey report.
+  They want to know: (a) Should the company invest in AI-powered review?
+  (b) What's the competitive advantage? (c) What are the risks of AI
+  reviewing code that handles $50B in annual transactions?
+
+  Agenda Item 3 — M&A due diligence:
+  The company is acquiring a 200-engineer startup. During due diligence,
+  you discovered the startup has no formal code review process — they
+  rely on pair programming and trust. The board wants to know the
+  integration risk and timeline to bring them to your review standards.
+
+  Task: Prepare the board presentation. For each agenda item, write:
+  the board-ready materials (1-page brief per item), the data
+  visualizations you would present (described in text), the Q&A
+  preparation (likely board questions and answers), and the governance
+  recommendations (what the board should approve or direct). End with
+  a unified strategic narrative connecting all 3 items to the company's
+  competitive position.
+
+assertions:
+  - type: llm_judge
+    criteria: "Risk governance answer is reassuring without being complacent — presents strong controls with data, acknowledges the competitor's failure couldn't 'absolutely never happen' but shows defense-in-depth, and proposes board-level oversight mechanisms (quarterly review health reports)"
+    weight: 0.35
+    description: "Reassuring risk governance"
+  - type: llm_judge
+    criteria: "AI strategy is pragmatic — doesn't over-promise AI capabilities, identifies specific use cases where AI review adds value ($50B transaction context requires human judgment for business logic), proposes a measured adoption approach, and addresses the risk question honestly"
+    weight: 0.35
+    description: "Pragmatic AI strategy"
+  - type: llm_judge
+    criteria: "M&A integration plan is realistic — acknowledges that pair programming has value (not just 'they're doing it wrong'), proposes a phased integration (not day-1 mandate), quantifies the risk timeline, and connects to the AI strategy (AI tools can accelerate integration)"
+    weight: 0.30
+    description: "Realistic M&A integration plan"

package/courses/github-pr-review/scenarios/level-5/review-consulting-engagement.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: review-consulting-engagement
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Lead a review consulting engagement — diagnose and transform a client's broken code review process as an external consultant"
+  tags: [github, pr-review, consulting, transformation, engagement, master]
+
+state: {}
+
+trigger: |
+  You're a senior engineering consultant hired for a 16-week, $250K
+  engagement to transform code review at a 400-engineer fintech company.
+  They've had 5 production incidents in 6 months traced to review
+  failures, lost 2 enterprise customers due to compliance gaps, and
+  their Glassdoor reviews specifically mention "toxic code reviews."
+
+  Client diagnostic findings (Week 1):
+  - 12 teams, 3 GitHub organizations, no consistent review process
+  - Average merge time: 5.2 days (industry benchmark: 1.5 days)
+  - 28% of PRs are abandoned (never merged)
+  - Developer satisfaction with review: 32% (industry benchmark: 70%)
+  - Top reviewer does 40% of all reviews (single point of failure)
+  - No reviewer training program exists
+  - CODEOWNERS files exist but 60% are outdated (point to departed employees)
+  - Branch protection varies: some repos require 0 approvals, payment
+    repos require 4 approvals (both extremes are problematic)
+  - The security team does a "security review gate" that adds 2 weeks
+    to any PR touching auth/payment code
+  - 15% of review comments contain personal attacks or dismissive
+    language (analyzed via NLP on comment history)
+  - No review metrics are tracked or reported
+
+  Client stakeholders:
+  - CTO: "Fix this fast, we can't keep losing customers"
+  - VP Engineering: "My team leads don't see this as their problem"
+  - Head of Security: "If we relax security reviews, we'll get breached"
+  - Engineering Manager (vocal critic): "We tried improving review
+    before. Consultants don't understand our codebase."
+
+  Task: Design the complete consulting engagement. Write: the client
+  diagnostic report (executive summary, findings, risk assessment), the
+  16-week transformation roadmap (phased, with milestones and
+  deliverables each sprint), the quick wins for Week 2-4 (to build
+  credibility), the organizational change management plan (handling
+  resistance from the vocal critic and security team), and the handoff
+  package (what you leave behind so improvements stick after you leave).
+  Include the success metrics and the "after" state you're targeting.
+
+assertions:
+  - type: llm_judge
+    criteria: "Diagnostic is comprehensive and data-driven — quantifies every problem (merge time, satisfaction, abandonment rate), benchmarks against industry, identifies root causes (not just symptoms), and presents findings without blame. The risk assessment connects review failures to business impact ($)"
+    weight: 0.35
+    description: "Comprehensive data-driven diagnostic"
+  - type: llm_judge
+    criteria: "Transformation roadmap is realistic for 16 weeks — quick wins build credibility (Weeks 2-4: fix CODEOWNERS, add basic branch protection, address toxic comments), middle phase tackles process (Weeks 5-10: SLAs, automation, training), final phase embeds sustainability (Weeks 11-16: metrics, governance, handoff)"
+    weight: 0.35
+    description: "Realistic 16-week roadmap"
+  - type: llm_judge
+    criteria: "Change management handles real resistance — addresses the vocal critic by involving them (not overriding), negotiates with security team on risk-based reviews (not just faster reviews), builds team lead ownership, and the handoff package ensures improvements survive the consultant's departure"
+    weight: 0.30
+    description: "Resistance-handling change management"

package/courses/github-pr-review/scenarios/level-5/review-devtools-product.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: review-devtools-product
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Build a review DevTools product — design and launch a code review SaaS product as a startup co-founder"
+  tags: [github, pr-review, product, startup, SaaS, go-to-market, master]
+
+state: {}
+
+trigger: |
+  You're the co-founder/CPO of a startup building "ReviewIQ" — an
+  AI-powered code review platform. You've raised $5M in seed funding
+  and have 12 months of runway. Your thesis: code review is broken at
+  scale and the market is ready for a purpose-built solution.
+
+  Market analysis:
+  - TAM: $4.2B (developer productivity tools market)
+  - SAM: $800M (code review and quality tools)
+  - SOM: $80M (AI-powered review for GitHub-based teams)
+  - Competitors: CodeRabbit ($12M ARR), Sourcery ($5M ARR), GitHub
+    Copilot code review (free, basic), Graphite (focused on stacking)
+  - Gap: No tool combines AI review + analytics + workflow automation
+    in a single platform
+
+  Product vision:
+  1. AI Reviewer: Catches bugs, security issues, and style violations
+     with <5% false positive rate
+  2. Review Analytics: Team-level and org-level metrics with benchmarks
+  3. Smart Assignment: Expertise-based reviewer assignment with load
+     balancing
+  4. Review Workflow: Custom review workflows (different rules per repo,
+     team, risk level)
+  5. Developer Experience: Integrates into GitHub's native review UI
+
+  Technical constraints:
+  - Must work with GitHub (80% of target market)
+  - Customer code must never leave their environment (enterprise
+    requirement)
+  - Must handle repos with 500K+ lines without timeout
+  - Must work with monorepos and polyglot codebases
+
+  Go-to-market constraints:
+  - 12-month runway ($5M, burn rate $400K/month)
+  - 6-person engineering team (including you)
+  - Need to reach $1M ARR to raise Series A
+  - Developer-led growth (PLG) is the primary motion
+
+  Task: Design the complete product strategy. Write: the product
+  roadmap (MVP scope for Month 1-3, growth features for Month 4-8,
+  enterprise features for Month 9-12), the technical architecture
+  (handle the privacy constraint with on-prem or edge deployment), the
+  pricing strategy (free tier, team, enterprise — with specific limits),
+  the PLG go-to-market plan (developer adoption → team adoption →
+  enterprise sale), and the competitive positioning (how to win against
+  GitHub Copilot's free review and funded competitors). Include the
+  metrics dashboard for the board and the 12-month financial projection.
+
+assertions:
+  - type: llm_judge
+    criteria: "MVP scope is achievable by a 6-person team in 3 months — focuses on one killer feature (likely AI review or analytics, not everything), defers enterprise features, and the scope decision is justified with competitive analysis"
+    weight: 0.35
+    description: "Achievable MVP scope"
+  - type: llm_judge
+    criteria: "Technical architecture solves the privacy constraint — proposes a viable approach for keeping customer code private (edge deployment, customer-hosted inference, or GitHub App with minimal data transmission), and this doesn't compromise the AI quality"
+    weight: 0.35
+    description: "Privacy-solving technical architecture"
+  - type: llm_judge
+    criteria: "GTM strategy reaches $1M ARR in 12 months — the PLG funnel is realistic (free users → team conversion → enterprise expansion), pricing tiers incentivize team adoption, and the competitive positioning against GitHub Copilot is credible (not just 'we're better')"
+    weight: 0.30
+    description: "ARR-reaching GTM strategy"

package/courses/github-pr-review/scenarios/level-5/review-industry-benchmarks.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: review-industry-benchmarks
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Publish industry benchmarks — create the definitive 'State of Code Review' report with cross-industry analysis and strategic insights"
+  tags: [github, pr-review, benchmarks, research, industry-analysis, master]
+
+state: {}
+
+trigger: |
+  You're the Head of Engineering Research at a developer tools company
+  publishing the annual "State of Code Review 2026" report. This report
+  is read by 50,000+ engineering leaders and influences industry
+  practices. You have survey data from 2,500 organizations.
+
+  Raw data highlights:
+  - Average merge time by company size:
+    Startup (<50 eng): 0.8 days | Mid (50-500): 2.1 days |
+    Enterprise (500+): 4.3 days
+  - Review practices adoption:
+    Required reviews: 89% | CODEOWNERS: 52% | AI review tools: 34% |
+    Review training: 18% | Review metrics: 27%
+  - Developer satisfaction with review:
+    Very satisfied: 15% | Satisfied: 35% | Neutral: 25% |
+    Dissatisfied: 18% | Very dissatisfied: 7%
+  - Correlation data:
+    Teams with review training: 2.3x fewer review-related incidents
+    Teams using AI review: 35% faster first review, no change in bug
+    detection rate
+    Teams with stale review dismissal: 40% fewer post-merge issues
+    Teams tracking review metrics: 1.8x faster improvement velocity
+  - Industry breakdown (merge time):
+    Fintech: 3.2 days | Healthcare: 4.8 days | SaaS: 1.5 days |
+    Gaming: 0.9 days | Government: 7.1 days | E-commerce: 1.8 days
+  - Emerging trends:
+    28% considering "review-free" paths for AI-generated code
+    45% exploring AI as first reviewer before human review
+    62% report "review fatigue" as top developer experience issue
+    33% have reduced required approvals in the last year
+
+  Task: Write the "State of Code Review 2026" report. Include: the
+  executive summary (key findings in 1 page), the benchmarking
+  methodology (how data was collected, limitations, statistical
+  significance), the cross-industry analysis (why healthcare and
+  government are slow, what gaming and SaaS do differently), the
+  emerging trends analysis (AI review, review-free paths, review
+  fatigue — with predictions), and the strategic recommendations by
+  company size. Each section should include data visualizations
+  described in text and key takeaways.
+
+assertions:
+  - type: llm_judge
+    criteria: "Benchmarking methodology is credible — describes data collection, sample sizes, statistical methods, and explicitly states limitations (survival bias, self-selection, correlation ≠ causation). The methodology section would withstand peer review"
+    weight: 0.35
+    description: "Credible benchmarking methodology"
+  - type: llm_judge
+    criteria: "Cross-industry analysis reveals insights — explains why industries differ (healthcare: compliance overhead, gaming: rapid iteration culture, government: audit requirements), identifies transferable practices, and doesn't just present data but interprets it"
+    weight: 0.35
+    description: "Insightful cross-industry analysis"
+  - type: llm_judge
+    criteria: "Predictions and recommendations are bold but grounded — makes specific predictions about AI review adoption, review-free paths, and review fatigue trends, with recommendations tailored by company size and industry. Addresses the controversial 'review-free for AI code' trend thoughtfully"
+    weight: 0.30
+    description: "Bold grounded predictions"

package/courses/github-pr-review/scenarios/level-5/review-ma-integration.yaml

@@ -0,0 +1,76 @@
+meta:
+  id: review-ma-integration
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "M&A review integration — harmonize code review processes across acquired companies with different engineering cultures"
+  tags: [github, pr-review, M&A, integration, culture, harmonization, master]
+
+state: {}
+
+trigger: |
+  You're the CTO overseeing the technical integration of 3 recently
+  acquired companies into the parent company. Each has a radically
+  different code review culture, and you need to create a unified
+  review process that preserves the best of each while meeting the
+  parent company's compliance requirements.
+
+  Parent company (800 engineers):
+  - GitHub Enterprise, strict 2-reviewer requirement
+  - CODEOWNERS, branch protection, SOC 2/PCI DSS compliance
+  - Average merge time: 2 days, developer satisfaction: 72%
+  - Strong tooling: automated review assignment, SLA tracking, analytics
+  - Weakness: perceived as "bureaucratic" by some teams
+
+  Acquisition A — Fast-moving SaaS startup (120 engineers):
+  - GitHub Cloud, 1-reviewer requirement, frequent self-merges
+  - No CODEOWNERS, minimal branch protection
+  - Average merge time: 4 hours, developer satisfaction: 85%
+  - Culture: "Ship fast, fix fast," trunk-based development
+  - Strength: Incredible velocity. Weakness: 3x incident rate
+
+  Acquisition B — Enterprise security company (200 engineers):
+  - GitLab self-hosted, 3-reviewer requirement including mandatory
+    security review
+  - Average merge time: 8 days, developer satisfaction: 45%
+  - Culture: "Every line must be perfect." Zero incidents but very slow
+  - Strength: Security rigor. Weakness: Engineering burnout, 30% attrition
+
+  Acquisition C — AI/ML research lab (80 engineers):
+  - Mix of GitHub and Jupyter notebooks in shared drives
+  - No formal review process — pair programming and "demo day" reviews
+  - No merge times (no PRs), developer satisfaction: 90%
+  - Culture: Academic, collaborative, experimental
+  - Strength: Innovation. Weakness: Production code quality varies wildly
+
+  Integration constraints:
+  - Must unify on GitHub Enterprise within 12 months
+  - Must achieve SOC 2 compliance across all entities within 18 months
+  - Must not lose more than 10% of acquired talent (especially from A
+    and C where culture change risk is highest)
+  - Must maintain each acquisition's product velocity during integration
+  - Budget: $1.5M for integration tooling and training
+
+  Task: Design the M&A review integration strategy. Write: the
+  assessment of each acquisition's review culture (strengths to preserve,
+  gaps to close), the unified review framework (minimum standard +
+  team-specific extensions), the migration plan for each acquisition
+  (phased, with specific milestones and risk mitigations), the culture
+  integration approach (how to merge 4 different review cultures without
+  destroying what works), and the retention risk mitigation plan.
+  Include the 18-month timeline and the executive dashboard for tracking
+  integration progress.
+
+assertions:
+  - type: llm_judge
+    criteria: "Assessment preserves strengths — Acquisition A's velocity practices are identified for adoption (not just compliance), B's security rigor informs the security review standard, and C's collaborative culture inspires pair/mob programming practices. Integration isn't one-way assimilation"
+    weight: 0.35
+    description: "Strength-preserving assessment"
+  - type: llm_judge
+    criteria: "Migration plans are tailored — A gets gradual compliance addition without killing velocity (start with CODEOWNERS, then branch protection), B gets process streamlining (reduce from 3 to 2 reviewers, optimize security review), C gets formalization without bureaucracy (lightweight PR process for production code, freedom for research)"
+    weight: 0.35
+    description: "Tailored migration plans"
+  - type: llm_judge
+    criteria: "Retention risk is specifically addressed — identifies flight risks (A's engineers who value speed, C's researchers who value freedom), proposes specific retention mechanisms (cultural ambassadors, review process autonomy periods, transparent timeline), and the 10% attrition target is tracked"
+    weight: 0.30
+    description: "Specific retention risk mitigation"

package/courses/github-pr-review/scenarios/level-5/review-regulatory-landscape.yaml

@@ -0,0 +1,78 @@
+meta:
+  id: review-regulatory-landscape
+  level: 5
+  course: github-pr-review
+  type: output
+  description: "Navigate the regulatory landscape for code review — analyze how global regulations shape review requirements and prepare for emerging compliance frameworks"
+  tags: [github, pr-review, regulatory, compliance, global, master]
+
+state: {}
+
+trigger: |
+  You're the Chief Compliance Officer of a global software company
+  operating in 35 countries. You need to map the regulatory landscape
+  for code review and change management, as regulations increasingly
+  require demonstrable software quality controls.
+
+  Current regulatory requirements affecting code review:
+
+  1. EU AI Act (effective 2026):
+  - High-risk AI systems require documented development processes
+  - Code changes to AI models need traceable review and testing
+  - Your AI-powered recommendation engine and fraud detection system
+    are classified as "high-risk"
+  - Penalty: up to 7% of global annual turnover
+
+  2. SEC Cybersecurity Rules (2024+):
+  - Material cybersecurity incidents must be disclosed within 4 days
+  - Board must demonstrate oversight of cybersecurity risk management
+  - Code review is part of the "reasonable controls" expectation
+  - Your financial reporting software processes $50B annually
+
+  3. DORA (Digital Operational Resilience Act, EU):
+  - ICT change management must be documented and tested
+  - Third-party ICT risk (including code review tools) must be managed
+  - Incident response must include root cause analysis of code changes
+  - Applies to your financial services customers in the EU
+
+  4. India's DPDP Act + China's PIPL:
+  - Data processing code changes must have privacy review
+  - Cross-border data flow code must have additional scrutiny
+  - You have engineering teams in Bangalore and Shanghai
+
+  5. Proposed US legislation:
+  - "Software Liability Act" draft would make companies liable for
+    known vulnerabilities that passed code review
+  - Bipartisan support, expected to pass within 2 years
+  - Would require "reasonable review practices" (undefined)
+
+  Emerging trends:
+  - Supply chain security regulations (NIST SSDF, EU CRA)
+  - AI-specific code review requirements (model governance)
+  - "Software bill of materials" requirements affecting dependency PRs
+  - Insurance underwriters requiring code review evidence for cyber
+    insurance renewals
+
+  Task: Map the regulatory landscape. Write: the regulatory matrix
+  (which regulations apply to which codebases, by jurisdiction and risk
+  level), the compliance gap analysis (where current review practices
+  fall short), the unified compliance framework (one review process
+  that satisfies all applicable regulations), the future-proofing
+  strategy (how to prepare for proposed and emerging regulations), and
+  the executive brief for the board on regulatory risk and investment
+  needed. Include the timeline for compliance milestones and the
+  consequences of non-compliance.
+
+assertions:
+  - type: llm_judge
+    criteria: "Regulatory matrix is comprehensive — maps each regulation to affected codebases, identifies overlapping requirements (e.g., EU AI Act + DORA both require documentation), and notes jurisdictional complexity (different requirements in EU, US, India, China)"
+    weight: 0.35
+    description: "Comprehensive regulatory matrix"
+  - type: llm_judge
+    criteria: "Unified framework satisfies all regulations efficiently — doesn't create separate review processes per regulation, identifies the superset of requirements, and implements the most stringent standard as the baseline with lighter paths for lower-risk code"
+    weight: 0.35
+    description: "Efficient unified compliance framework"
+  - type: llm_judge
+    criteria: "Future-proofing strategy is forward-looking — prepares for the Software Liability Act, supply chain regulations, and AI governance requirements before they take effect, with a regulatory monitoring process that detects new requirements early"
+    weight: 0.30
+    description: "Forward-looking future-proofing"

package/courses/postgresql-query-optimization/course.yaml

@@ -0,0 +1,11 @@
+id: postgresql-query-optimization
+name: "Database Query Optimization (PostgreSQL)"
+description: >
+  Master PostgreSQL query optimization from reading execution plans to
+  enterprise database architecture. Learn indexing strategies, JOIN
+  optimization, partitioning, parallel queries, connection pooling,
+  write optimization, monitoring, and high-availability configurations
+  for large-scale PostgreSQL deployments.
+levels: 5
+scenarios_per_level: 10
+tags: [development, PostgreSQL, database, query-optimization, performance, SQL, DevOps]

package/courses/postgresql-query-optimization/scenarios/level-1/explain-analyze-basics.yaml

@@ -0,0 +1,80 @@
+meta:
+  id: explain-analyze-basics
+  level: 1
+  course: postgresql-query-optimization
+  type: output
+  description: "Read EXPLAIN ANALYZE output — interpret PostgreSQL query execution plans to identify performance bottlenecks"
+  tags: [PostgreSQL, EXPLAIN, execution-plan, query-optimization, beginner]
+
+state: {}
+
+trigger: |
+  You're a junior developer working on an e-commerce app. The product
+  listing page takes 8 seconds to load. Your tech lead asks you to
+  run EXPLAIN ANALYZE on the query and figure out what's slow.
+
+  The query:
+  SELECT p.id, p.name, p.price, c.name as category,
+         AVG(r.rating) as avg_rating
+  FROM products p
+  JOIN categories c ON c.id = p.category_id
+  LEFT JOIN reviews r ON r.product_id = p.id
+  WHERE p.active = true AND p.price BETWEEN 10 AND 100
+  GROUP BY p.id, p.name, p.price, c.name
+  ORDER BY avg_rating DESC NULLS LAST
+  LIMIT 20;
+
+  EXPLAIN ANALYZE output:
+  Limit (cost=45892.12..45892.17 rows=20 width=76)
+        (actual time=8234.521..8234.534 rows=20 loops=1)
+    -> Sort (cost=45892.12..46142.12 rows=100000 width=76)
+           (actual time=8234.519..8234.527 rows=20 loops=1)
+         Sort Key: (avg(r.rating)) DESC NULLS LAST
+         Sort Method: top-N heapsort Memory: 27kB
+      -> HashAggregate (cost=42391.50..43391.50 rows=100000 width=76)
+             (actual time=7891.234..8102.456 rows=85000 loops=1)
+           Group Key: p.id, p.name, p.price, c.name
+         -> Hash Left Join (cost=3456.78..38141.50 rows=850000 width=48)
+                (actual time=234.567..5678.901 rows=850000 loops=1)
+              Hash Cond: (r.product_id = p.id)
+              -> Seq Scan on reviews r (cost=0..28456.00 rows=1200000
+                     width=12) (actual time=0.023..1234.567 rows=1200000
+                     loops=1)
+              -> Hash (cost=3206.78..3206.78 rows=20000 width=44)
+                     (actual time=234.123..234.123 rows=18500 loops=1)
+                   Buckets: 32768 Batches: 1 Memory Usage: 1234kB
+                -> Hash Join (cost=12.50..3206.78 rows=20000 width=44)
+                       (actual time=0.345..198.765 rows=18500 loops=1)
+                     Hash Cond: (p.category_id = c.id)
+                     -> Seq Scan on products p (cost=0..3125.00
+                            rows=20000 width=40)
+                            (actual time=0.012..178.234 rows=18500
+                            loops=1)
+                           Filter: (active AND (price >= 10)
+                                    AND (price <= 100))
+                           Rows Removed by Filter: 81500
+                     -> Hash (cost=10.00..10.00 rows=200 width=12)
+                            (actual time=0.234..0.234 rows=200 loops=1)
+
+  Table sizes: products (100K rows), reviews (1.2M rows),
+  categories (200 rows).
+
+  Task: Analyze this execution plan. Explain: what each node means
+  (in plain English), where the time is being spent, why it's doing
+  sequential scans, what indexes would help, and write the optimized
+  version of this query with the recommended indexes. Explain the
+  difference between estimated and actual rows.
+
+assertions:
+  - type: llm_judge
+    criteria: "Execution plan is correctly interpreted — identifies that the sequential scan on reviews (1.2M rows) is the biggest bottleneck, explains cost vs actual time, estimated vs actual rows, and each node type (Seq Scan, Hash Join, HashAggregate, Sort, Limit). The explanation is in plain English a junior developer can understand"
+    weight: 0.35
+    description: "Correct plan interpretation"
+  - type: llm_judge
+    criteria: "Optimization recommendations are specific — suggests index on reviews(product_id) for the JOIN, index on products(active, price) for the filter, and explains why these indexes would replace sequential scans with index scans. May suggest a materialized view or covering index for further optimization"
+    weight: 0.35
+    description: "Specific optimization recommendations"
+  - type: llm_judge
+    criteria: "Explains key EXPLAIN ANALYZE concepts — cost units (arbitrary but relative), actual time (milliseconds), loops, rows removed by filter, sort methods, hash bucket sizing, and how to identify the slowest node by looking at actual time differences between parent and child nodes"
+    weight: 0.30
+    description: "Key concepts explained"