Commit History
28 days ago
-
merge: docs/release-0.1.0-sha — repin diffs carry the 0.1.0 release commit 6a43c17; genomics diff = what was applied on its dev Space; ADOPTION verify grep fixed; docs only
Annie Voigt +1: Claude Opus 5.5Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>1378f45 -
docs: 0.1.0 released at 6a43c17 — real pin line in every repin diff; genomics applied on dev
Annie Voigt +1: Claude Opus 5.5- <RELEASE_SHA> replaced with 6a43c179b3f5a6ea9dfc9b5447235f31a699977a (the release commit carrying the wheel; tag v0.1.0) in every repin diff and README. - pdac-genomics-agent.diff is now the diff actually applied (genomics 34eaab5, merge 923f94d, dev Space RUNNING, smoke-dev PASS), via requirements.in + lock. - spatial's diff flags its stale hand-pinned mechanics (it compiles from .in now). - ADOPTION §2 verify command: `bcc-caveat{` never matches — _css.py writes `.bcc-caveat {` — and it returned 0 on a page serving the stylesheet. Fixed, with the gradio 6 config-JSON and private-Space caveats. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>6e4f0da -
release: bcc-ui-theme 0.1.0
Annie Voigt6a43c17 -
merge: docs/adoption-fixes-0.1.0 — ADOPTION §1.6 matches §5 (lit-agent adopts now), §3 withdrawn claim removed, repin mechanics rechecked; docs only
Annie Voigt +1: Claude Opus 5.5Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>c1894fc -
docs(adoption): lit-agent adopts now; drop the withdrawn genomics claim; repin table rechecked
Annie Voigt +1: Claude Opus 5.5- §1 item 6 said lit-agent adopts after its gradio 6 migration, contradicting §5 (adopt now on 5.50 via Blocks(), Annie 2026-09-25). It now matches §5, and the lit-agent repin diff's "BLOCKED" header says the same. - §3 restated the withdrawn "genomics CSS never applied" finding at length. It now states only what is true: _CSS was always served, and adoption appends it. - §1 item 4: genomics goes first because its dev Space is private and admin-only (Annie, 2026-10-15 decision queue, D4). - §6 / repin README: genomics (since 2026-09-30) and spatial compile from requirements.in (3.11 / 3.12, --python-platform linux); only lit-agent is still hand-pinned. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>4b5f31c
-
docs(adoption): §5 reverses to adopt-now — the ordering had lost its premise
Annie Voigt +1: Claude Opus 5Annie's call 2026-09-25, reversing the 2026-09-22 "migrate to gradio 6 first". That sequence rested on the premise that no call site works on both majors. The premise was already recorded as wrong in §2 and in §5's own correction note — `Blocks(theme=…, css=…)` is accepted on 5.50 and 6.18, proven by `make test-both` — but the ordering was left standing on two arguments that do not support it: - "one call site across the fleet instead of two" assumes a uniformity that does not exist: as of today NO Space has adopted, there is no `theme=` call site anywhere in the six repos. - the 5.50 Google Fonts `preconnect` is real, but it is a reason to migrate, not a reason to migrate FIRST. It arrives whenever the migration does. Both argue for doing the migration; neither argues for its position in the sequence. Motivation had been conflated with ordering. Against that, the migration touches the Space that runs lit-agent's Monday digest to OHSU PIs and needs the lit-agent-monday-check …32c84c7
-
merge: correct the gradio 6 call-site finding — no silent drop, no dead CSS
Annie Voigt2652209 -
docs+test: the 6.x call site does not fail silently — withdraw the "dead CSS" finding
Annie Voigt +1: Claude Opus 5This package was built on the premise that gradio 6.x silently drops `Blocks(theme=…, css=…)`, that no call site works on both majors, and that `pdac-genomics-agent` is shipping dead CSS because of it. All three are wrong. gradio 6.0 DEPRECATED the two arguments on `Blocks`; it did not remove them. `__init__` stashes the value in `_deprecated_theme` / `_deprecated_css` and warns, and `launch()` back-fills it (`css = css if css is not None else self._deprecated_css`, 6.18 `blocks.py:2728`). Measured against both pins: Blocks(theme=, css=) launch(theme=, css=) gradio 5.50 accepted, warns TypeError — declares neither gradio 6.18 accepted, warns, SERVED accepted So `Blocks()` is the form that works on BOTH majors and `launch()` is the 6.x-only one — the reverse of what every file here said. Nothing can lose a stylesheet without raising or warning. The guidance does not change: still `launch()` on 6.x. Only the reason does — forward p…4c64950 -
feat: bcc-ui-theme 0.1.0 — shared Gradio theme + stylesheet for the fleet
Annie Voigt +1: Claude Opus 5A behaviour-free package: a gr.themes.Base subclass and a stylesheet, so the six customer-facing apps read as one product. Created out of the fleet UI inventory (pdac-analysis-orchestrator/docs/design/fleet-ui-inventory.md). Verified on gradio 5.50.0 (py3.11) AND 6.18.0 (py3.13): 46 tests green on both, plus a real served-page check that the stylesheet is actually delivered. The theme uses only Base.set() keywords present in both — 5.50's 262 are a strict subset of 6.18's 267, so 5.50 binds, and the portable-keyword test checks against the INSTALLED gradio so `make test-both` is the proof. Two facts measured rather than assumed, both load-bearing: - The theme/css call site is version-dependent and there is NO line that works on both majors. gradio 5.50: Blocks() only (launch() has no **kwargs, so the 6.x form raises). gradio 6.18: launch() only — Blocks() silently absorbs the argument into **kwargs, warns into a build log, and stores css=None. - That silent drop is live in the…89e8390