dojo.md 0.2.0 → 0.2.1

package/courses/postgresql-query-optimization/scenarios/level-5/database-behavioral-science.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: database-behavioral-science
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Apply behavioral science to database operations — design systems that nudge engineers toward good query practices and prevent performance anti-patterns"
+  tags: [PostgreSQL, behavioral-science, nudge-theory, developer-experience, culture, master]
+
+state: {}
+
+trigger: |
+  Your organization has 400 engineers writing queries against PostgreSQL.
+  Despite documentation, training, and code reviews, the same performance
+  anti-patterns keep appearing: SELECT *, missing indexes on foreign keys,
+  N+1 queries, unfiltered aggregations on large tables, and long-running
+  transactions holding locks.
+
+  You've tried traditional approaches:
+  - Wiki documentation: 15% of engineers read it
+  - Quarterly training sessions: Attendance drops 50% after first session
+  - Code review checklist: Reviewers skip database items under time pressure
+  - Slack channel for DB questions: Same 5 people answer, 10 people ask
+
+  Anti-pattern frequency (last quarter):
+  - SELECT * on tables with 50+ columns: 120 new instances
+  - Missing WHERE clause on UPDATE/DELETE: 8 incidents (3 in production)
+  - N+1 queries in new endpoints: 45 instances
+  - Queries without LIMIT on unbounded result sets: 67 instances
+  - ALTER TABLE without CONCURRENTLY on large tables: 12 instances
+  - Long transactions (>5 min) blocking autovacuum: 30 incidents
+
+  Behavioral science concepts to apply:
+  1. Choice architecture: Make the right thing the default
+  2. Nudge theory: Gentle prompts at the right moment
+  3. Feedback loops: Immediate visibility of consequences
+  4. Social proof: Show what good teams are doing
+  5. Friction: Make bad patterns slightly harder, good patterns easier
+  6. Gamification: Make query optimization engaging
+
+  The VP of Engineering says: "We can't review every query manually.
+  We need a system where engineers naturally write good queries without
+  needing a DBA to catch every mistake."
+
+  Task: Design the behavioral system for database excellence. Write:
+  the choice architecture (how to make good defaults), the automated
+  nudge system (when and how to prompt engineers), the feedback loop
+  design (showing query impact in real-time), the social proof
+  mechanisms (leaderboards, team comparisons), and the organizational
+  change management plan.
+
+assertions:
+  - type: llm_judge
+    criteria: "Choice architecture makes good practices the default — ORM configuration defaults to safe patterns (SELECT with explicit columns, query timeouts, connection limits), migration tools default to CONCURRENTLY for index creation, CI/CD pipeline includes automatic EXPLAIN analysis that flags anti-patterns before merge, and database client libraries include built-in guardrails"
+    weight: 0.35
+    description: "Effective choice architecture"
+  - type: llm_judge
+    criteria: "Nudge system intervenes at the right moment — IDE plugins that warn about SELECT * as you type, PR bot that comments with query performance estimates, pre-deploy checks that show estimated query cost, and post-deploy dashboards that attribute latency changes to specific deployments. Nudges are informative, not blocking (most of the time)"
+    weight: 0.35
+    description: "Well-timed nudge system"
+  - type: llm_judge
+    criteria: "Feedback loops and social proof create sustainable improvement — real-time query performance dashboard per team, weekly automated reports comparing team query performance, gamification elements (query optimization challenges, leaderboards), and the change management plan addresses resistance (making it fun, not punitive) with measurable success metrics"
+    weight: 0.30
+    description: "Sustainable feedback and social proof"

package/courses/postgresql-query-optimization/scenarios/level-5/database-board-strategy.yaml

@@ -0,0 +1,77 @@
+meta:
+  id: database-board-strategy
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Present database strategy to the board — frame PostgreSQL infrastructure as a strategic asset, quantify technical debt, and secure multi-year investment"
+  tags: [PostgreSQL, board-strategy, investment, technical-debt, governance, master]
+
+state: {}
+
+trigger: |
+  You're the CTO presenting the database infrastructure strategy to
+  the Board of Directors at the quarterly meeting. The board includes
+  3 technical members and 4 non-technical members. You need to secure
+  approval for a $5M, 3-year database modernization program.
+
+  Company context:
+  - $200M ARR SaaS platform, 5,000 enterprise customers
+  - IPO planned in 18 months
+  - Due diligence will examine infrastructure scalability
+  - Current database: 30 PostgreSQL clusters, 50TB total
+  - 8 DBAs, $3.5M/year database infrastructure cost
+  - 3 major outages last year (total 14 hours downtime)
+  - Customer-facing latency SLA: 99.9% of requests <200ms
+  - Current achievement: 99.2% (SLA breach, contractual penalties possible)
+
+  The $5M modernization program includes:
+  Year 1 ($2M):
+  - Consolidate 30 clusters to 15 (eliminate redundancy)
+  - Implement automated query review pipeline
+  - Deploy comprehensive monitoring (pg_stat_statements, pgwatch2)
+  - Partition all tables >100M rows
+  - Upgrade all clusters to PG 16
+
+  Year 2 ($1.8M):
+  - Migrate to managed service (Aurora) for 10 clusters
+  - Implement multi-region disaster recovery
+  - Reduce DBA team from 8 to 5 (3 transition to platform engineering)
+  - Achieve 99.95% latency SLA compliance
+
+  Year 3 ($1.2M):
+  - Achieve 99.99% availability
+  - Implement auto-scaling for variable workloads
+  - Reduce infrastructure cost by 30% through optimization
+  - Full self-service database provisioning for engineering teams
+
+  Expected outcomes:
+  - Infrastructure cost: $3.5M/year → $2.5M/year by Year 3
+  - Downtime: 14 hours/year → <1 hour/year
+  - SLA compliance: 99.2% → 99.99%
+  - Engineering velocity: 40% faster feature delivery (less DB bottleneck)
+
+  Board member concerns:
+  - "Why not just move everything to the cloud and let AWS handle it?"
+  - "Can't we just hire more DBAs instead of spending $5M?"
+  - "What if we delay this until after the IPO?"
+  - "How does this compare to what our competitors are doing?"
+
+  Task: Write the board presentation narrative. Include: the strategic
+  framing (database as competitive advantage), the investment case with
+  ROI, the risk of inaction (IPO due diligence, SLA penalties, customer
+  churn), the phased execution plan, and prepared responses to the 4
+  board concerns.
+
+assertions:
+  - type: llm_judge
+    criteria: "Strategic framing resonates with board audience — presents the database as a business asset (not just infrastructure), connects reliability to customer retention and revenue, frames the investment in context of IPO readiness, and uses business language (not technical jargon) for non-technical board members"
+    weight: 0.35
+    description: "Board-appropriate strategic framing"
+  - type: llm_judge
+    criteria: "Investment case is compelling — ROI is clearly calculated ($5M investment vs quantified returns: $1M/year cost reduction, avoided SLA penalties, reduced outage costs, IPO readiness), risk of inaction is quantified (SLA penalty exposure, due diligence failure risk, customer churn from outages), and the phased approach reduces execution risk"
+    weight: 0.35
+    description: "Compelling investment case"
+  - type: llm_judge
+    criteria: "Board concerns are addressed directly — explains why lift-and-shift to cloud isn't sufficient (still need optimization, higher cost without tuning), why more DBAs don't solve the structural problem, why delaying risks IPO timeline and increases cost, and provides competitive context. Responses are concise and business-focused"
+    weight: 0.30
+    description: "Board concerns addressed"

package/courses/postgresql-query-optimization/scenarios/level-5/database-consulting-engagement.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: database-consulting-engagement
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Lead a database consulting engagement — assess a client's PostgreSQL infrastructure, identify optimization opportunities, and deliver a transformation roadmap"
+  tags: [PostgreSQL, consulting, assessment, transformation, roadmap, master]
+
+state: {}
+
+trigger: |
+  You're a PostgreSQL consulting lead hired by a Series C fintech
+  company ($500M valuation) that's experiencing database growing pains.
+  They've doubled their engineering team to 200 in the past year, and
+  their PostgreSQL infrastructure is struggling to keep up.
+
+  Client briefing:
+  - Company: PayStream (B2B payment processing)
+  - Revenue: $80M ARR, growing 100% YoY
+  - Transaction volume: 10M transactions/day, projected 50M in 12 months
+  - Database: 8 PostgreSQL clusters, 3TB total, mix of PG 13 and PG 15
+  - Team: 2 DBAs (both joined <6 months ago), 15 backend engineers
+  - Monthly infrastructure cost: $120K (growing 20%/quarter)
+
+  Assessment findings (your first week):
+  1. Performance: 40% of API endpoints exceed 500ms P99 latency
+  2. Schema: 15 tables over 1B rows with no partitioning
+  3. Indexes: 2,000 indexes total, estimated 40% unused (wasting 400GB)
+  4. Queries: Top 50 queries consume 80% of database CPU
+  5. Configuration: All 8 clusters use identical postgresql.conf despite
+     wildly different workloads (OLTP, reporting, event storage)
+  6. Monitoring: Basic CloudWatch only — no query-level visibility
+  7. No connection pooling on 5 of 8 clusters
+  8. Backups: Daily pg_dump (takes 6 hours), never tested restoration
+  9. Version: 3 clusters still on PG 13 (EOL approaching)
+  10. No query review process — any engineer can deploy any query
+
+  The CEO says: "We're spending more on database infrastructure every
+  quarter. Our engineers complain the database is slow. Our DBAs are
+  overwhelmed. We need a plan to fix this before our Series D."
+
+  Task: Write the consulting deliverable. Include: the executive
+  assessment (current state in business terms), the prioritized
+  optimization roadmap (quick wins, medium-term, long-term), the
+  staffing and organizational recommendations, the cost projection
+  (infrastructure costs with and without optimization), and the risk
+  register (what happens if they don't act).
+
+assertions:
+  - type: llm_judge
+    criteria: "Assessment translates technical findings into business impact — quantifies the cost of poor performance (revenue impact of 500ms latency, cost of unused indexes, risk of untested backups), prioritizes findings by business impact, and presents a clear current-state summary that a CEO can understand"
+    weight: 0.35
+    description: "Business-impact assessment"
+  - type: llm_judge
+    criteria: "Roadmap is prioritized and realistic — quick wins (drop unused indexes, deploy PgBouncer, tune top 50 queries) deliver measurable improvement in 2-4 weeks, medium-term (partition large tables, upgrade PG 13→16, implement monitoring) in 2-3 months, long-term (query review process, architecture evolution) in 6-12 months. Each phase has estimated cost savings"
+    weight: 0.35
+    description: "Prioritized optimization roadmap"
+  - type: llm_judge
+    criteria: "Staffing and cost projections are realistic — recommends DBA team growth or managed service adoption, projects infrastructure costs with optimization (reducing growth rate) vs without (linear extrapolation), and presents a compelling case for investment before Series D (database health as investor due diligence concern)"
+    weight: 0.30
+    description: "Staffing and cost projections"

package/courses/postgresql-query-optimization/scenarios/level-5/database-industry-benchmarks.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: database-industry-benchmarks
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Design and interpret database benchmarks — create meaningful PostgreSQL benchmarks, avoid common pitfalls, and use benchmarks for capacity planning and vendor selection"
+  tags: [PostgreSQL, benchmarks, TPC, pgbench, performance-testing, capacity-planning, master]
+
+state: {}
+
+trigger: |
+  Your company needs to make a $2M infrastructure decision — whether to
+  migrate from self-managed PostgreSQL to Aurora PostgreSQL. The CTO
+  says "run some benchmarks and tell me which is faster." You know that
+  naive benchmarking leads to wrong conclusions, so you need to design
+  a rigorous benchmark that actually answers the right questions.
+
+  Context:
+  - Current: Self-managed PG 16 on r6g.4xlarge (16 vCPU, 128GB RAM)
+  - Candidate: Aurora PG 16 on db.r6g.4xlarge (same compute class)
+  - Workload: Mixed OLTP (70% reads, 30% writes), 50K TPS peak
+  - Data size: 500GB active dataset, 2TB total
+  - Critical queries: Point lookups, range scans, complex joins, bulk inserts
+
+  Common benchmarking mistakes you've seen teams make:
+  1. Using pgbench with default scale factor (fits entirely in RAM)
+  2. Benchmarking with empty tables (no realistic data distribution)
+  3. Running benchmarks for 5 minutes (not long enough for caches to warm)
+  4. Testing on a quiet system (no concurrent workload)
+  5. Ignoring storage performance (only testing CPU-bound queries)
+  6. Not testing failure scenarios (how does performance degrade under
+     replica failure, disk pressure, connection storms?)
+  7. Comparing list price vs actual cost (ignoring IOPS charges, data
+     transfer, backup costs)
+
+  Industry standard benchmarks:
+  - TPC-C: OLTP transactions (orders, payments, deliveries)
+  - TPC-H: Analytical queries (decision support)
+  - pgbench: PostgreSQL-specific, configurable
+  - sysbench: General-purpose database benchmark
+  - HammerDB: TPC-C/TPC-H implementation for PostgreSQL
+
+  Your VP asks: "Can you give me a number — queries per second on
+  Aurora vs self-managed — by Friday?"
+
+  Task: Design the benchmark plan. Write: the benchmark methodology
+  (what to test, how to test, how long), the workload design (realistic
+  representation of your actual workload), the metrics to collect and
+  how to interpret them, the pitfalls to avoid, and the decision
+  framework (how benchmark results translate into the migration decision).
+
+assertions:
+  - type: llm_judge
+    criteria: "Benchmark methodology is rigorous — tests realistic data volume (500GB+ to exceed RAM), runs long enough for steady state (hours, not minutes), includes warm-up phase, tests under concurrent load matching production patterns, and tests both normal operation and degraded modes (replica failure, high connection count)"
+    weight: 0.35
+    description: "Rigorous benchmark methodology"
+  - type: llm_judge
+    criteria: "Workload design represents real usage — captures the 70/30 read/write mix, includes representative query types (point lookups, range scans, complex joins, bulk inserts), uses realistic data distributions (not uniform), and tests at multiple concurrency levels (10, 50, 100, 500 connections) to find saturation points"
+    weight: 0.35
+    description: "Realistic workload design"
+  - type: llm_judge
+    criteria: "Decision framework goes beyond QPS — considers latency percentiles (P50/P95/P99), throughput under load, cost-per-transaction, operational overhead, failure behavior, and long-term cost trajectory. Acknowledges that benchmarks are one input to the decision alongside operational, compliance, and strategic factors"
+    weight: 0.30
+    description: "Holistic decision framework"

package/courses/postgresql-query-optimization/scenarios/level-5/database-ma-integration.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: database-ma-integration
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Plan database integration after M&A — merge two companies' PostgreSQL infrastructures while maintaining service continuity"
+  tags: [PostgreSQL, M&A, integration, data-migration, schema-merge, master]
+
+state: {}
+
+trigger: |
+  Your company (AcmePay, $200M ARR) just acquired a competitor
+  (QuickBill, $50M ARR). Both run on PostgreSQL. The board mandates
+  full technology integration within 12 months. You're leading the
+  database integration.
+
+  AcmePay (acquirer):
+  - PostgreSQL 16 on Aurora, 20 clusters, 30TB
+  - Well-documented schema, strong naming conventions
+  - 500 tables across 8 microservices
+  - 100K QPS peak, 99.95% availability
+  - PgBouncer, comprehensive monitoring
+  - 5 DBAs, mature processes
+
+  QuickBill (acquired):
+  - PostgreSQL 14 on self-managed EC2, 8 clusters, 10TB
+  - Organic schema growth, inconsistent naming
+  - 300 tables in a monolithic database
+  - 20K QPS peak, 99.5% availability
+  - No connection pooling, basic monitoring
+  - 1 DBA (the founder who wrote the original schema)
+
+  Integration challenges:
+  1. Schema conflicts: Both have "users", "invoices", "payments" tables
+     with different schemas, different ID formats (UUID vs serial), and
+     overlapping customer IDs
+  2. Data overlap: 2,000 customers exist in both systems — their data
+     must be merged, not duplicated
+  3. Compliance: QuickBill stores PII in plain text; AcmePay encrypts
+     at rest and at column level for SSN/tax IDs
+  4. Versioning: QuickBill on PG 14 needs upgrade to PG 16
+  5. Performance: QuickBill's monolith has 50 queries >10 seconds
+  6. Business continuity: Both products must remain operational during
+     integration — customers of both products are paying
+  7. API contracts: QuickBill's API returns data in different formats;
+     3rd-party integrations depend on these formats
+  8. Regulatory: Financial data retention requirements (7 years) mean
+     historical data must be carefully preserved and mapped
+
+  The CEO's directive: "I want one database, one platform, one team —
+  within 12 months. But we can't lose a single customer or a single
+  dollar of data."
+
+  Task: Write the integration plan. Include: the assessment of both
+  systems (gaps and risks), the schema unification strategy, the data
+  migration plan (handling overlapping customers), the phased timeline,
+  and the risk mitigation plan (what if integration fails mid-way).
+
+assertions:
+  - type: llm_judge
+    criteria: "Schema unification strategy handles conflicts — defines approach for merging users/invoices/payments tables (ID mapping tables, namespace prefixing, or new unified schema), resolves UUID vs serial ID conflict, handles the 2,000 overlapping customers (deduplication strategy with merge rules), and preserves data lineage for regulatory compliance"
+    weight: 0.35
+    description: "Sound schema unification"
+  - type: llm_judge
+    criteria: "Phased timeline is realistic — breaks 12 months into phases (assessment, preparation, parallel run, migration, decommission), ensures business continuity at each phase (both products operational), includes PG 14→16 upgrade and PII encryption remediation for QuickBill data, and identifies dependencies between phases"
+    weight: 0.35
+    description: "Realistic phased timeline"
+  - type: llm_judge
+    criteria: "Risk mitigation addresses business-critical concerns — rollback plan at each phase, data validation (row counts, financial totals, customer record integrity), parallel running period where both systems serve traffic, and a kill switch to halt integration if customer impact is detected. Addresses API compatibility for 3rd-party integrations"
+    weight: 0.30
+    description: "Business-critical risk mitigation"

package/courses/postgresql-query-optimization/scenarios/level-5/database-product-development.yaml

@@ -0,0 +1,72 @@
+meta:
+  id: database-product-development
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Build a database performance product — design a SaaS tool that helps teams optimize PostgreSQL performance, from architecture to go-to-market"
+  tags: [PostgreSQL, product-development, SaaS, performance-monitoring, go-to-market, master]
+
+state: {}
+
+trigger: |
+  You're a technical co-founder building a SaaS product for PostgreSQL
+  performance optimization. After 10 years as a DBA, you've seen the
+  same problems at every company. You want to productize your expertise.
+
+  Product vision: "Autopilot for PostgreSQL performance"
+  - Connects to any PostgreSQL database (RDS, Aurora, self-managed)
+  - Analyzes query performance continuously
+  - Recommends and optionally applies optimizations
+  - Provides actionable insights (not just dashboards)
+
+  Competitive landscape:
+  - pganalyze: Query performance monitoring ($500-2,000/mo)
+  - Datadog Database Monitoring: Part of broader APM ($23/host/mo)
+  - New Relic: Database monitoring as part of observability
+  - OtterTune: AI-powered tuning (acquired by AWS)
+  - Percona PMM: Open-source monitoring
+  - pgDash: Simple PostgreSQL monitoring
+
+  Your differentiation: Not just monitoring — actually fixing problems.
+  Every competitor shows you dashboards. You want to show the specific
+  query change, the specific index to add, and optionally apply it.
+
+  Technical challenges:
+  1. Data collection: How to gather query plans, statistics, and
+     performance data with minimal overhead (<1% CPU)
+  2. Analysis engine: How to identify optimization opportunities
+     automatically (unused indexes, missing indexes, query rewrites)
+  3. Safe recommendations: How to ensure recommendations don't break
+     things (test in shadow mode, rollback capability)
+  4. Multi-tenant: Each customer's data is sensitive — isolation required
+  5. Agent vs agentless: Install agent on customer's server vs connect
+     to pg_stat_statements remotely
+
+  Business model options:
+  A. Per-host pricing ($100-500/host/month)
+  B. Per-query pricing (based on optimized queries)
+  C. Value-based pricing (% of infrastructure cost saved)
+  D. Freemium (monitoring free, optimization paid)
+
+  You have $2M seed funding, 6 engineers, and 12 months to get to
+  product-market fit (50 paying customers).
+
+  Task: Write the product strategy. Include: the product architecture
+  (data collection, analysis, recommendation, application), the MVP
+  scope (what to build first for fastest path to 50 customers), the
+  go-to-market strategy (how to reach PostgreSQL teams), the pricing
+  model recommendation, and the technical roadmap (12-month plan).
+
+assertions:
+  - type: llm_judge
+    criteria: "Product architecture is technically sound — data collection uses pg_stat_statements + pg_stat_activity with minimal overhead, analysis engine identifies missing/unused indexes and slow query patterns, recommendations include specific SQL (CREATE INDEX, query rewrites), and the safe application path includes shadow testing and rollback. Multi-tenant data isolation is addressed"
+    weight: 0.35
+    description: "Sound product architecture"
+  - type: llm_judge
+    criteria: "MVP scope is focused on fastest path to customers — identifies the highest-value feature to ship first (likely index recommendations or slow query identification), scopes an MVP achievable in 3-4 months with 6 engineers, explains what to cut from v1 (automated application, multi-database support), and defines clear success metrics for product-market fit"
+    weight: 0.35
+    description: "Focused MVP scope"
+  - type: llm_judge
+    criteria: "Go-to-market and pricing are realistic — identifies target customer profile (mid-size companies with 5-20 PostgreSQL instances, no dedicated DBA), distribution channels (PostgreSQL community, DevOps conferences, content marketing), pricing model is justified against competitors, and the 12-month roadmap has realistic milestones leading to 50 customers"
+    weight: 0.30
+    description: "Realistic GTM and pricing"

package/courses/postgresql-query-optimization/scenarios/level-5/database-regulatory-landscape.yaml

@@ -0,0 +1,76 @@
+meta:
+  id: database-regulatory-landscape
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Navigate database regulatory compliance — design PostgreSQL configurations for GDPR, PCI DSS, HIPAA, SOX, and emerging data sovereignty regulations"
+  tags: [PostgreSQL, compliance, GDPR, PCI-DSS, HIPAA, SOX, data-sovereignty, master]
+
+state: {}
+
+trigger: |
+  Your company is expanding into 3 new markets (EU, healthcare, and
+  government contracts). Each market has different database compliance
+  requirements, and your PostgreSQL infrastructure wasn't designed for
+  regulatory compliance. The legal team has given you 6 months to achieve
+  compliance or the expansion deals ($30M combined) will be lost.
+
+  Current PostgreSQL infrastructure:
+  - 20 clusters, all in US-East region
+  - No data classification (PII mixed with non-PII)
+  - Audit logging: only pg_log (not queryable, not tamper-evident)
+  - Encryption: TLS in transit, no encryption at rest, no column-level
+  - Access control: 5 shared database users for 200 engineers
+  - Data retention: No automated deletion, data kept forever
+  - Backups: Daily pg_dump, stored unencrypted in same region
+
+  Compliance requirements by market:
+
+  1. EU expansion (GDPR):
+  - Data residency: EU customer data must stay in EU
+  - Right to erasure: Must delete customer data on request within 30 days
+  - Data portability: Must export customer data in machine-readable format
+  - Breach notification: 72 hours to report data breaches
+  - Data minimization: Only collect what's necessary
+  - Audit trail: Prove who accessed what data and when
+
+  2. Healthcare (HIPAA):
+  - PHI must be encrypted at rest and in transit
+  - Access controls: Role-based, minimum necessary access
+  - Audit trail: All access to PHI must be logged and retained 6 years
+  - Business Associate Agreements with all vendors (including AWS)
+  - Breach notification: 60 days for breaches affecting 500+ individuals
+
+  3. Government (FedRAMP / NIST 800-53):
+  - Data must reside in US government-authorized regions
+  - FIPS 140-2 validated encryption modules
+  - Continuous monitoring and vulnerability scanning
+  - System categorization (Low, Moderate, High impact)
+  - Multi-factor authentication for all database access
+
+  Cross-cutting requirements:
+  - SOX compliance (public company): Database changes must be auditable,
+    separation of duties between development and production access
+  - PCI DSS (payment processing): Cardholder data encrypted, quarterly
+    vulnerability scans, access logging, tokenization
+
+  Task: Design the compliance architecture. Write: the data
+  classification and residency strategy, the encryption architecture
+  (at rest, in transit, column-level), the audit logging system (tamper-
+  evident, queryable, retained per regulation), the access control
+  redesign (from 5 shared users to RBAC), and the compliance automation
+  (how to continuously verify compliance, not just achieve it once).
+
+assertions:
+  - type: llm_judge
+    criteria: "Data classification and residency are addressed — defines data classification tiers (public, internal, confidential, restricted), maps PII/PHI/cardholder data to appropriate tiers, designs multi-region deployment for EU data residency (PostgreSQL in EU region with logical replication or partitioned access), and addresses right-to-erasure with soft-delete + scheduled purge patterns"
+    weight: 0.35
+    description: "Data classification and residency"
+  - type: llm_judge
+    criteria: "Encryption and access control are comprehensive — implements TDE or filesystem encryption at rest, column-level encryption (pgcrypto or application-level) for PII/PHI/cardholder data, redesigns access from 5 shared users to role-based access with per-engineer credentials, implements row-level security for data isolation, and addresses FIPS 140-2 requirements for government"
+    weight: 0.35
+    description: "Encryption and access control"
+  - type: llm_judge
+    criteria: "Audit logging and compliance automation are production-ready — implements tamper-evident audit logging (pgAudit or custom triggers with hash chains), retains logs per regulation (6 years for HIPAA, 7 for SOX), provides queryable audit trail, and designs continuous compliance monitoring (automated checks, drift detection, compliance dashboard) rather than point-in-time audits"
+    weight: 0.30
+    description: "Audit and compliance automation"

package/courses/postgresql-query-optimization/scenarios/level-5/master-optimization-shift.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: master-optimization-shift
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Master optimization shift — advise a CEO on a complete database transformation combining M&A integration, regulatory compliance, AI adoption, and 10x scaling"
+  tags: [PostgreSQL, shift-simulation, transformation, CEO-advisory, comprehensive, master]
+
+state: {}
+
+trigger: |
+  You're an external database strategy advisor. A CEO calls you with
+  an urgent, complex situation that touches everything you know about
+  PostgreSQL.
+
+  The situation:
+  DataCorp ($500M ARR, 2,000 engineers) just acquired two companies
+  simultaneously:
+  - HealthSync ($50M ARR, healthcare SaaS, HIPAA-regulated)
+  - EuroTrade ($80M ARR, EU-based fintech, GDPR + PCI DSS)
+
+  DataCorp runs PostgreSQL 15 on Aurora (30 clusters, 100TB).
+  HealthSync runs PostgreSQL 13 on self-managed EC2 (5 clusters, 8TB).
+  EuroTrade runs PostgreSQL 16 on Citus (10 clusters, 40TB, sharded).
+
+  The board has set 4 concurrent mandates (18-month timeline):
+  1. Integrate all three databases into a unified platform
+  2. Achieve HIPAA, GDPR, and PCI DSS compliance across the platform
+  3. Prepare for IPO (99.99% availability, SOX compliance, cost optimization)
+  4. Support 10x growth (DataCorp expects to grow from $500M to $5B ARR
+     in 5 years)
+
+  Constraints:
+  - Total database team across all 3 companies: 15 DBAs
+  - Combined infrastructure cost: $2M/month
+  - Zero customer data loss is non-negotiable
+  - All 3 products must remain operational during integration
+  - EU data must stay in EU (HealthSync currently stores some EU patient
+     data in US)
+  - IPO due diligence begins in 12 months
+
+  The CEO asks: "Give me the plan. I need to know: What's the unified
+  architecture? What's the timeline? What's the budget? What's the risk?
+  And what should I tell the board?"
+
+  Task: Write the comprehensive advisory document. Include: the unified
+  database architecture (handling Aurora + self-managed + Citus), the
+  compliance strategy (achieving all 4 regulatory frameworks
+  simultaneously), the integration timeline (phased approach over 18
+  months), the budget projection (with cost optimization targets), and
+  the board communication strategy (how to frame this as opportunity,
+  not just cost).
+
+assertions:
+  - type: llm_judge
+    criteria: "Unified architecture handles all 3 database platforms — addresses Aurora-to-Citus or Citus-to-Aurora consolidation (or hybrid approach), PG 13→16 upgrade path for HealthSync, handles Citus sharding patterns (distributed tables, reference tables) during migration, and designs for 10x scale (100TB→1PB trajectory). Architecture is realistic given 15 DBAs"
+    weight: 0.35
+    description: "Viable unified architecture"
+  - type: llm_judge
+    criteria: "Compliance strategy achieves all 4 frameworks — HIPAA (PHI encryption, access logging, BAAs), GDPR (EU data residency, right to erasure, DPA), PCI DSS (cardholder tokenization, network segmentation), and SOX (audit trails, separation of duties). Addresses the immediate risk of EU patient data in US. Identifies overlapping requirements to reduce effort"
+    weight: 0.35
+    description: "Multi-framework compliance"
+  - type: llm_judge
+    criteria: "Timeline, budget, and board communication are executive-ready — 18-month phased plan with clear milestones and go/no-go gates, budget includes infrastructure, personnel, and opportunity cost, risk register identifies top 5 risks with mitigation strategies, and the board narrative frames integration as competitive advantage (unified data platform enables cross-sell, AI/ML, faster innovation) not just technical debt remediation"
+    weight: 0.30
+    description: "Executive-ready delivery"

package/courses/terraform-infrastructure-setup/course.yaml

@@ -0,0 +1,11 @@
+id: terraform-infrastructure-setup
+name: "Terraform Infrastructure Setup"
+description: >
+  Master Terraform infrastructure setup from basic HCL syntax and resource
+  provisioning to enterprise IaC platform strategy. Progress through provider
+  configuration, state management, module design, CI/CD pipelines, policy
+  enforcement, and organizational transformation — the complete journey from
+  first terraform init to advising boards on infrastructure investment.
+levels: 5
+scenarios_per_level: 10
+tags: [development, Terraform, IaC, infrastructure, DevOps, HCL, cloud, provisioning]

package/courses/terraform-infrastructure-setup/scenarios/level-1/terraform-init-errors.yaml

@@ -0,0 +1,72 @@
+meta:
+  id: terraform-init-errors
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Debug terraform init failures — diagnose provider installation errors, backend configuration issues, and registry connectivity problems"
+  tags: [Terraform, init, providers, backend, registry, beginner]
+
+state: {}
+
+trigger: |
+  You run `terraform init` and get this error:
+
+  ```
+  Initializing the backend...
+
+  Initializing provider plugins...
+  - Finding hashicorp/aws versions matching "~> 5.0"...
+
+  Error: Failed to query available provider packages
+
+  Could not retrieve the list of available versions for provider
+  hashicorp/aws: could not connect to registry.terraform.io:
+  connection timed out
+  ```
+
+  Your terraform configuration:
+
+  ```hcl
+  terraform {
+    required_providers {
+      aws = {
+        source  = "hashicorp/aws"
+        version = "~> 5.0"
+      }
+    }
+    backend "s3" {
+      bucket = "my-terraform-state"
+      key    = "prod/terraform.tfstate"
+      region = "us-east-1"
+    }
+  }
+
+  provider "aws" {
+    region = "us-east-1"
+  }
+  ```
+
+  Additional context:
+  - You're behind a corporate proxy
+  - The .terraform directory doesn't exist yet
+  - Running Terraform v1.7.0
+
+  Task: Explain terraform init, what it does step by step (backend
+  initialization, provider installation, module download), common
+  init failures and their fixes, provider version constraints
+  (= vs ~> vs >= syntax), and how to work with Terraform behind
+  proxies or air-gapped environments.
+
+assertions:
+  - type: llm_judge
+    criteria: "Init process is explained step by step — terraform init: (1) initializes backend (configures state storage, creates .terraform/terraform.tfstate for backend config), (2) downloads provider plugins from registry.terraform.io to .terraform/providers/, (3) downloads modules to .terraform/modules/. The specific error is a network connectivity issue — behind a corporate proxy, set HTTP_PROXY and HTTPS_PROXY environment variables. Alternative: use terraform provider mirror to create a local filesystem mirror for air-gapped environments. The .terraform.lock.hcl file records provider versions and hashes for reproducibility"
+    weight: 0.35
+    description: "Init process"
+  - type: llm_judge
+    criteria: "Provider version constraints are covered — version = '= 5.0.0' (exact), '~> 5.0' (allows 5.x but not 6.0, pessimistic constraint), '>= 5.0, < 6.0' (range). Best practice: use ~> for minor version flexibility. Lock file (.terraform.lock.hcl): commit to version control, records exact versions and checksums. To update: terraform init -upgrade. Provider source format: namespace/type (hashicorp/aws). Third-party providers: specify full source in required_providers block"
+    weight: 0.35
+    description: "Version constraints"
+  - type: llm_judge
+    criteria: "Common init failures are listed with fixes — (1) registry connectivity: proxy settings, TF_CLI_CONFIG_FILE for custom registry, provider mirror for air-gapped. (2) Backend errors: S3 bucket doesn't exist, DynamoDB table missing for locking, insufficient IAM permissions. (3) Provider not found: typo in source, missing required_providers block. (4) Version conflicts: lock file doesn't match config, run terraform init -upgrade. (5) Module source errors: git credentials, registry authentication"
+    weight: 0.30
+    description: "Common failures"