[MikolajSzczepkowski]

What changed

• Lists DFO holdings and core datasets as static copy
• Links to Sources, or starts a canvas on the question (not past wall)

Why

How it was tested

Linked issue

https://app.asana.com/1/9116197837664/project/1219967636350866/task/1219943150717427?focus=true
Closes #38

Screenshots

Before is dev at bf9232d on a local server against the dev API, and after is this branch at 3aa87b1 on a local server reading dev data through the staging website (the dev API refuses the drawer's unauthenticated server reads), both signed out, at 1440 by 900.

Change	Before	After
Link under the lead
Drawer open	No drawer

[jm-rivera]

@MikolajSzczepkowski @ramyamahalingamatode Hardcoding this information is not the right solution. Please look at how /data manages the question of what data do you have.

Please also make sure you're leveraging the API capabilities fully as we have built ways for you to get an up to date view of these things.

[MikolajSzczepkowski]

Agreed, dropped the static copy: the drawer now reads the same two endpoints the Data pages use, GET /api/search/catalogue for the counts (as /data's starting point does) and GET /api/graph/sources for the publishers and their dataset counts (as /data/sources does)

[jm-rivera]

Claude's automated review (Claude Code), posted from Jorge's account. It is a machine review, so treat each point as a lead to check.

Performance and reliability

• src/app/studio/page.tsx:17: the landing's first paint now waits for the slower of the catalogue read and the graph read, each capped at 3 s, to fill a drawer most visitors never open. Before this PR it waited only for the session. Streaming the data (a promise read with use() inside the drawer) or fetching when the drawer opens would keep the landing at its old speed.
• src/app/studio/[id]/page.tsx:17: the conversation page waits for the same reads, but it renders the workspace and never shows the drawer, so a cold graph delays a saved canvas by up to 3 s for data nobody sees.
• src/lib/studio/dataAvailabilityLoader.ts:26: a failed graph read is never remembered and concurrent cache misses are not merged, unlike catalogueLoader's FAILURE_TTL_MS. During a graph outage each landing visit fires its own read with one retry (15 s + 1 s + 15 s), so N concurrent visits hold N reads open on an API that is already struggling.
• src/lib/studio/dataAvailabilityLoader.ts:39: after the race times out, the graph read that should fill the hour cache runs as a dangling promise, not registered with after(). On Cloud Run with request-only CPU it can stall once the response is sent, so the cache may never fill and the drawer keeps rendering without publishers.

Correctness

• src/components/organisms/Studio/landing/DataAvailabilityPanel.tsx:78: the drawer mixes two catalogues. "42 publishers" comes from the search catalogue, while the "Data comes from:" list comes from filterGroups, which folds about forty upstream publishers into the "Data Commons by Google" and "UN System Data Commons" rows. A reader sees "42 publishers" above a list of six, two of which are not publishers. Either label the list as sources or list the publishers within each Data Commons.
• src/lib/studio/dataAvailability.ts:54: dataFacts re-implements formatCount and the indicator and dataset tiles from lib/search/catalogue.ts. The drawer shows "109,040" indicators where /data shows the rounded "100K+", and a change to catalogueTiles will not reach the drawer.

UX

• DataAvailabilityPanel.tsx:65: the scope line gives the publisher and country counts, and the tiles directly below repeat both.
• src/components/organisms/Studio/landing/StudioLanding.tsx:110: "Ask a follow-up" closes the modal and enters the workspace in the same tick, so onCloseAutoFocus returns focus to the fading "What data is available?" button. When the landing unmounts, focus drops to <body> instead of the workspace prompt, which strands keyboard and screen-reader users.

Comments

• DataAvailabilityPanel.tsx:30, src/lib/studio/dataAvailability.ts and the rewritten docstring in StudioLanding.tsx use em dashes and "rather than" constructions ("Then the two ways on — the Sources page, or a canvas…", "built from the same two reads … rather than from copy"). Stating what the code does in plain sentences reads more easily.

[jm-rivera]

@MikolajSzczepkowski please see the automated review findings above

[MikolajSzczepkowski]

Thanks, all addressed. The reads moved off the landing's first paint: both pages are back to the session read only, and the drawer fetches GET /api/data-availability when it opens, showing "Reading the catalogue…" meanwhile. The loader remembers a failed graph read for a minute and shares one in-flight read between concurrent callers, and the 3 s race (with its dangling promise) is gone. The drawer now reuses scopeLine, catalogueTiles and a new aidLine from lib/search/catalogue, so nothing is formatted twice and the indicator count reads "100K+" as on /data; the list is labelled "Sources" and matches the Sources page's chips. "Ask a follow-up" now lands focus in the workspace's follow-up field (ChatPanel autoFocus on entry from the landing, not on phones or shares). Comments rewritten as plain sentences. Verified headless against the dev API.