Q (sonnet): Can you help me write a production-ready Python script using Bokeh to build an interactive clinicogenomic dashboard to analyzing the MSK-CHORD dataset? I have some specific requirements I can give you

▶ get_study_guide
{
 "study_id": "msk_chord_2024"
}

▶ list_guides
{}

◀ result
# MSK-CHORD (MSK, Nature 2024)

**Study ID:** `msk_chord_2024`

## Overview
Targeted sequencing via MSK-IMPACT panels. Clinical annotations include some derived from natural language processing (denoted NLP).

**Exactly five cancer types** (`CANCER_TYPE`, patients): Non-Small Cell Lung Cancer 7,809, Colorectal Cancer 5,543, Breast Cancer 5,368, Prostate Cancer 3,211, Pancreatic Cancer 3,109. There is **no melanoma** or any other cancer type; say so up front if asked, instead of substituting another type.

**No therapy-response variable.** There is no RECIST, objective response, or best-response attribute or event. For treatment-outcome questions (e.g. immunotherapy response), say this first; the only proxies are `OS_MONTHS`/`OS_STATUS`, or NLP radiology progression events (`Diagnosis` events with `SUBTYPE = 'Progression'`, key `PROGRESSION` = Y/N/Indeterminate), in patients with `Treatment` events of the relevant `SUBTYPE` (e.g. `Immuno`: 3,341 patients). Hand off the comparison to cBioPortal group comparison / survival.

**Nearly one sample per patient: 24,950 patients / 25,040 samples.** Only 90 patients have more than one sample, and all 90 have samples from two different cancer types (second primaries); only 26 have both a `Primary` and a `Metastasis` sample. There is no meaningful same-patient (paired) primary-vs-metastasis cohort. For "same patient" / paired questions, say this up front, then offer the **unpaired** comparison of all `Primary` vs `Metastasis` samples (`SAMPLE_TYPE`), labelled as unpaired.
```sql
SELECT countIf(n > 1) AS multi_sample_patients,         -- 90
       countIf(has_p AND has_m) AS primary_and_met      -- 26
FROM (SELECT patient_unique_id, count() AS n,
             has(groupArray(attribute_value), 'Primary') AS has_p,
             has(groupArray(attribute_value), 'Metastasis') AS has_m
      FROM clinical_data_derived
      WHERE cancer_study_identifier = 'msk_chord_2024' AND attribute_name = 'SAMPLE_TYPE'
      GROUP BY patient_unique_id);
```

## Gene Panels
This study uses multiple MSK-IMPACT panel versions:
- **IMPACT341**: Earlier version, 341 genes
- **IMPACT410**: 410 genes
- **IMPACT468**: 468 genes  
- **IMPACT505**: Latest version, 505 genes

**Important:** Different samples may have different gene coverage. Always use gene-specific denominators when calculating mutation frequencies.

## Clinical Attributes - Semantic Guide

### Cancer Classification
| Attribute | Description | Values |
|-----------|-------------|--------|
| `CANCER_TYPE` | Broad cancer category | e.g., "Non-Small Cell Lung Cancer", "Breast Cancer" |
| `CANCER_TYPE_DETAILED` | Specific subtype | e.g., "Lung Adenocarcinoma", "Invasive Ductal Carcinoma" |
| `ONCOTREE_CODE` | OncoTree classification code | Standardized cancer type codes |

### Sample Information
| Attribute | Description | Values |
|-----------|-------------|--------|
| `SAMPLE_TYPE` | Sample origin | Primary, Metastasis, Local Recurrence, Unknown |
| `SAMPLE_CLASS` | Sample … (5439 more chars)

◀ result
{"result":[{"uri":"cbioportal://mutation-frequency-guide","description":"Comprehensive guide for calculating gene mutation frequencies with gene-specific profiling denominators"},{"uri":"cbioportal://clinical-data-guide","description":"Guide for querying clinical data including patient vs sample level considerations"},{"uri":"cbioportal://sample-filtering-guide","description":"Guide for filtering samples and studies in cBioPortal queries"},{"uri":"cbioportal://common-pitfalls","description":"Guide to avoid common mistakes when querying cBioPortal data. If you already know which numbered pitfall applies, fetch just that section via read_guide(\"cbioportal://common-pitfalls#<number>\") (e.g. #16) instead of the full guide"},{"uri":"cbioportal://treatment-guide","description":"Guide for querying treatment/clinical event data including drug agents, timelines, and linking to genomic data"},{"uri":"cbioportal://faq-guide","description":"General cBioPortal FAQ: history, how to cite, data types, reference genome, abbreviations, GISTIC thresholds, API access"},{"uri":"cbioportal://statistical-tests-guide","description":"Statistical test selection guide — decision matrix for choosing Fisher's exact, Wilcoxon, chi-squared, t-test, ANOVA, etc. based on data type and group count"},{"uri":"cbioportal://gene-expression-guide","description":"Gene expression / copy-number / methylation analysis. Covers genetic_alteration_derived, profile_type discovery, and the gene_pair_coexpression view for Spearman correlation between two genes"},{"uri":"cbioportal://external-resources-guide","description":"Guide for finding external linked resources such as imaging, pathology, Minerva, HTAN, or other resource_* table links before declaring data unavailable"},{"uri":"cbioportal://gene-resolution-guide","description":"Guide for resolving ambiguous gene symbols, aliases, gene families, and shorthand such as CD3 before querying expression or alteration data"},{"uri":"cbioportal://study-resolution-guide","description":"Guide for resolving requested studies, avoiding silent substitute cohorts, and redirecting to known external cBioPortal instances when data is not in this deployment"},{"uri":"cbioportal://germline-guide","description":"Guide for querying germline variant data — storage columns, study discovery, query patterns, and somatic vs germline considerations"},{"uri":"cbioportal://study-guide/{study_id}","description":"Dynamic study-specific guide - use get_study_guide(study_id) tool to generate"}]}

═ answer (success)
I've got a solid picture of MSK-CHORD's schema now — 5 cancer types, ~25K samples, gene panel variability across IMPACT341/410/468/505, rich treatment event data, and NLP-derived clinical fields with known caveats. This is enough grounding to architect a dashboard well.

Rather than guessing at your requirements, let me confirm the shape of what you want before I write ~500+ lines of production code. Please tell me:

**1. Data access pattern**
- Should the script query the **live cBioPortal ClickHouse database** directly (e.g., via `clickhouse-driver`/`clickhouse-connect`), or should it read from **exported flat files** (e.g., CSV/TSV downloads of clinical + mutation data), or support both?
- If live DB: do you have your own ClickHouse credentials/connection string for a deployment, or should I parameterize this generically (host/port/user/password via env vars)?

**2. Deployment target**
- `bokeh serve` app (with `curdoc()`, server-side callbacks, widgets) — for real interactivity and larger data?
- Or a static standalone HTML export (`output_file` / `components`) — simpler, no server needed, but limited interactivity (e.g., no server-side Python callbacks on selection)?

**3. Core views/panels** — do you have specific ones in mind, or want me to propose? Candidates given the schema:
   - Cancer type distribution (5 types) with drill-down
   - Mutation frequency by gene (oncoprint-style or bar chart), with gene-panel-aware denominators
   - TMB / MSI score distributions, possibly split by cancer type
   - Survival (OS_MONTHS/OS_STATUS) Kaplan-Meier curves by subgroup
   - Treatment subtype/agent breakdown (Chemo/Immuno/Targeted/etc.)
   - Primary vs. Metastasis comparisons (noting the unpaired caveat from the guide)

**4. Interactivity requirements**
- Cross-filtering between panels (e.g., select a cancer type → other plots update)?
- Widgets: dropdowns/multiselect for cancer type, gene search box, sliders for TMB/age ranges?

**5. Production-readiness specifics**
- Logging, config management (YAML/env), caching of query results, error handling/retries for DB calls?
- Tests (pytest)? Packaging (single file vs. module structure)?
- Any performance constraints (e.g., must handle all 25K samples client-side, or should heavy aggregation happen server-side/in SQL)?

Once I know these, I'll design the architecture and start implementing incrementally so it's actually correct against the real schema rather than plausible-looking placeholder code.