What happened

An LLM node’s prompts were fixed strings. The only dynamism available was the node’s inputs list, whose members were serialized into the user turn as context — so “make the prompt be the newest camera frame” or “be the payload the webhook just received” was not expressible, and users approximated it by wiring nodes into inputs and hoping the model made the connection. krill-sdk 0.0.59 added LLMMetaData.promptDataSource / systemPromptDataSource for exactly this, and nothing in the server read them.

Two bugs surfaced while wiring them up, both from the same root: a camera prompt source resolves to an image and an empty string, and empty-string is not null.

• (resolution as? Ok)?.prompt?.text ?: meta.systemPrompt.ifBlank { DEFAULT_SYSTEM_PROMPT } — the elvis never fires for "", so a camera named as the system prompt source silently shadowed the default persona and the model was sent with no persona at all.
• The skip guard checked meta.inputs.isEmpty() rather than the inputs that actually resolved. When every input had been deleted or lived on an unreachable peer, the guard passed and the node POSTed a user turn consisting of one blank line — then persisted whatever the model invented into its snapshot and fanned it out over SSE.

Fix

• server/.../krillapp/server/llm/PromptSourceResolver.kt (new) resolves a NodeIdentity? into prompt material per node type: a Camera contributes its frame as a base64 image (read from local disk, else fetched from the host that captured it), every other node contributes its snapshot.value verbatim. A configured-but-unusable source is Failed(reason) — never a silent fallback — and the reason names the actual cause (cold camera vs. over the size cap vs. node missing) rather than collapsing them into one string.
• server/.../krillapp/server/llm/ServerLLMProcessor.kt resolves each prompt slot as source → fixed text → empty, where an Ok resolution with blank text (i.e. an image-only source) contributes no text and falls through. A camera wired as the prompt source alongside a typed prompt therefore sends the user’s question with the frame. DEFAULT_SYSTEM_PROMPT remains the system fallback; the invented "Summarize the current state of the input nodes." user-prompt default is deleted.
• A Failed on either slot records meta.error via nodeManager.failed() and skips the backend call outright; both slots’ reasons are aggregated and slot-labelled.
• Camera-frame reading and the 10 MB cap moved into the resolver, so the prompt-source path and the input-camera path share one implementation. Images are deduped by node id.
• composeApp/.../krillapp/server/llm/EditLLM.kt picks and clears a source per prompt slot; the text field is disabled (never wiped) while a source is set.

Prevention

• An empty string is not an absent value. ?: guards null, not blank. Any fallback chain whose upstream can legitimately produce "" needs ifBlank { null }, and the type should say so. This bug pattern will recur wherever a resolver returns “success, but with nothing in it.”
• Guard on what resolved, not on what was configured. A list of ids is a request; the list of nodes you actually found is the fact. Any check of the form if (config.isEmpty()) sitting next to an already-computed resolved collection is asking to be wrong.
• A default that invents user intent is worse than an empty field. “Summarize the input nodes” was obeyed by the model and looked like the user’s instruction. Prefer empty and let the skip guard decide.
• When a config field can be set but not satisfied, fail the node loudly. A cold camera degrading to “no prompt” yields a confident answer about nothing, which reads as a model failure rather than the wiring failure it is.
• kotlin.test.assertIs<T> returns T. A test function whose expression body ends in it infers a non-Unit return type, and JUnit Jupiter silently skips it — the suite reports green while the test never ran. This bit us twice here. Give such functions an explicit : Unit, and read skipped="0" out of the XML rather than trusting the console’s test count.
• A mid-stream semantics change invalidates the instructions written before it. The UI half of this change was specced as “disable the text field whenever a source is set” — correct against the design, and wrong against the server the moment the image-only fallback landed. It would have greyed out the Prompt field the instant you wired a camera, making the feature’s own headline flow (wire the camera, ask “is anyone at the gate?”) impossible to author. When a rule changes on one side of a boundary, re-read what the other side was told, not just what it does.
• Adding SDK fields is not shipping a feature. Grep the consuming repo after an SDK bump — these two fields sat unread through a release.