3 commits

Author	SHA1	Message	Date
Daniel	055a86bbb1	feat: My Resources says what it is, offers its sources in one place, and Modify gets them too ... The screen had been trimmed to controls with no explanation of what it was for; "Private to you" said who could see it, not what it did. It now opens with a sentence that says what you get and how you get it out, and the header reads "Only you can see these". The four choices — clinical library, PubMed, web, illustration — are one "Draw on" group instead of four separate rows, with the library ticked by default. Each option hides itself when an administrator has not enabled it, so nothing appears that a person could tick and then be refused. Modify offers exactly the same choices. It had none, so "add what the 2024 trial showed" was answered from the model's memory rather than by looking anything up. Generate and Modify now go through one gatherSources(), so they cannot drift into offering different things or searching them differently. Writing "include a diagram of the airway" in the instructions now switches the illustration option on and says why, rather than the request being dropped in silence. Switching it off by hand sticks — the hint then reminds instead of fighting — and when no image model is configured it says so rather than pretending. Both the generate and modify boxes behave this way. Two things found by testing this rather than assuming it. PubMed ANDs every mapped term, so one unrecognised word takes the query to zero. "febrile seizures" returns six results and "febrile seizures in under-fives" returns none; "the anatomy of croup: subglottic narrowing and the steeple sign" returned none until it was narrowed to "anatomy croup", which returns six. A query that finds nothing is now retried against progressively shorter versions of itself, longest first, and the response says which query actually worked so the screen cannot report one that found nothing. Those extra calls tripped NCBI's three-a-second limit and produced a 429, so retries are spaced and the first attempt waits for nothing. Separately, the searches run on the topic while the library retrieval also gets the instruction: retrieval is semantic and benefits from the context, but a keyword engine handed a whole sentence returns nothing. And when a search was asked for and came back empty, the prompt now says not to invent a citation, a PMID or a URL to fill the gap. Without that the model supplies them from memory, and a fabricated PMID looks exactly like a real one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dv6sqaY6Vq3ChZHMem3cnU	2026-09-11 18:54:17 +02:00
Daniel	1270899dcb	feat: PubMed search for My Resources, and an image tool that actually fires ... PubMed joins web search as an optional source for a generated resource: a literature search on the topic, with abstracts, cited by PMID in References. Off by default, admin-enabled, with its own optional API key (NCBI raises the rate limit from 3/sec to 10/sec; it works without one). Neither search is a tool any more, and that is the point. Offering them as function calls meant the model decided whether to search, and with a prompt ending "Output ONLY Pandoc markdown" it decided not to — every time, with and without corpus grounding, no matter how the tool description was worded. Calling callAI with the tool directly produced a correct pubmed_search call, so the plumbing was never the problem. The search only ever needed the topic, and the route knows the topic before it calls the model, so both searches now run up front and their results go into the prompt as findings, exactly the way corpus excerpts do. Ticking the box now means the search happened. Verified live against deepseek-v4-flash: 30 corpus excerpts and 6 PubMed results, and a References slide carrying both the library sources and four real PMIDs (29562151, 38506440, 35721052, 28814254). Three fixes to illustration, which had never once fired: - The dispatch call had been lost in a refactor. The tool was still offered, the model still called it, and the call was dropped, so no job was ever enqueued. - imageContext was passed as a bare topic string where dispatch expects { request, history }, which made the bound request undefined. - The prompt never mentioned the tool existed while explicitly demanding only markdown — the same suppression that killed the searches. It now says an illustration is available and that calling it is not a violation of that rule. my_resources is its own image workflow rather than a reuse of learning_hub, because generated_image_links only accepts learning_hub assets, and that is exactly the barrier that keeps a private illustration out of published content. The illustration renders in the panel, rather than a toast pointing at an image history this feature does not have. Verified end to end: job queued, rendered, and the asset served to its owner as a correctly labelled subglottic-anatomy teaching diagram. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dv6sqaY6Vq3ChZHMem3cnU	2026-09-11 16:47:08 +02:00
Daniel	571a013d29	feat: optional web search, admin-enabled and off by default ... The one feature here that sends text outside the building, so the defaults are the careful ones: disabled unless an administrator turns it on, opt-in per generation even then, and the option is hidden entirely rather than shown as something a user can tick and be refused. Only the search query leaves. Library excerpts, the generated resource and anything about the user never do. Both screens say so plainly, because a topic typed while drafting clinical material can carry clinical detail and the provider keeps its own logs. Four providers behind one shape, so swapping changes nothing downstream: Tavily, Serper over Google, Brave, and SearXNG — the only one where the query does not reach a commercial third party at all, which is why it is worth supporting even though it needs somewhere to run. The tool description says when NOT to search, because a model handed a search tool will reach for it constantly: not for settled clinical knowledge, which is what the indexed library is for, and one search per resource. That last one is enforced in the route with toolChoice: 'none' on the continuation rather than trusted to the model. A failed search never fails a generation — same contract as corpus retrieval. The resource is written without it and the response says what was searched for and what came back, so a query that left the network is visible rather than silent. The API key is masked on read and preserved when the field is left blank, the handling the OIDC client secret already gets, so changing provider cannot silently wipe a working key. Verified on the running instance: with nothing configured, webSearchAvailable is false, and a request asking for it anyway is ignored rather than honoured. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dv6sqaY6Vq3ChZHMem3cnU	2026-09-11 15:47:06 +02:00