fix: apply custom prompts to new sessions

[mason5052]

Summary

Custom system prompts saved via the Settings -> Prompts UI are now applied to newly created assistant and flow sessions. Prior to this change, every session creation path used templates.NewDefaultPrompter() (with a leftover TODO comment), so user customizations never reached the agents and Langfuse traces always showed the default templates.

Problem

backend/pkg/controller/assistant.go (NewAssistantWorker, LoadAssistantWorker) and backend/pkg/controller/flow.go (NewFlowWorker, LoadFlowWorker) all built the prompter from templates.NewDefaultPrompter() and ignored the per-user prompts table that the Prompts UI persists. The Custom badge in the UI was therefore decorative -- saved overrides had no effect on subsequent sessions.

Solution

Introduce a small controller-side helper, newUserPrompter, which:

1. Loads the user's saved prompts via database.Querier.GetUserPrompts.
2. Loads the compiled defaults via templates.LoadDefaultPromptsMap() (a new helper that returns the embedded defaults as a PromptsMap directly, avoiding a JSON round-trip) and overlays each non-empty user override onto the resulting map.
3. Returns a templates.NewFlowPrompter(merged) so prompt types the user never customized continue to resolve to the defaults.

A database error fails session creation explicitly (wrapErrorEndSpan on the existing langfuse span) instead of silently falling back to defaults. Empty bodies are skipped because the UI uses delete (or reset, which writes the default body back) to remove a customization, so an empty row is unexpected and would otherwise surface as ErrTemplateNotFound deep inside agent rendering.

The helper lives in pkg/controller rather than pkg/templates to avoid creating a new templates -> database import edge.

To avoid an N+1 pattern on flow load, assistantWorkerCtx carries an optional prompter field. LoadFlowWorker builds the user prompter once for the flow and reuses it across every assistant in that flow; LoadAssistantWorker falls back to building its own prompter when invoked outside a flow load.

Lifecycle Semantics

• The user prompter is snapshotted at session creation time (NewFlowWorker, LoadFlowWorker, NewAssistantWorker, standalone LoadAssistantWorker).
• Customizations edited mid-session are not applied retroactively to running sessions; only sessions created or loaded after the edit pick them up. This matches the existing per-session lifecycle of every other agent setting and is intentional -- live mutation of the prompter would race with in-flight agent calls.
• Within a single flow load, all assistants share the same snapshot, so every assistant in a given flow sees a consistent set of prompts even if the user edits between assistants.

User Impact

• New assistant and flow sessions now use the saved custom prompts for each PromptType the user has overridden.
• Sessions for users who have not customized any prompts behave exactly as before.
• No GraphQL schema, REST API, database migration, or frontend change.

Test Plan

• go test ./pkg/controller/... ./pkg/templates/... (passes locally on Go 1.24)
• New unit tests in backend/pkg/controller/prompter_test.go cover:
  • No user prompts -> defaults preserved
  • Single override -> custom body returned, unrelated types still default
  • Partial overrides on multiple types -> overridden types custom, others default
  • Empty body row -> default preserved (override skipped)
  • DB error from GetUserPrompts -> wrapped error propagated, nil prompter returned
  • Happy path through newUserPrompter end-to-end with a fake database.Querier

Follow-ups

• backend/cmd/ftester/worker/tester.go carries the same TODO and was intentionally left alone here -- it is a developer harness rather than a session creation path. Happy to fold it in if reviewers prefer one place.

Closes #300

[Copilot]

Pull request overview

This PR fixes a long-standing bug where user-customized system prompts (saved via Settings → Prompts) were never applied to newly created assistant and flow sessions, because controllers always instantiated templates.NewDefaultPrompter().

Changes:

• Added controller-side prompter construction that loads per-user prompt overrides from the DB and overlays them onto compiled defaults.
• Updated assistant + flow worker creation/loading paths to use the user-aware prompter and to fail explicitly on DB prompt-load errors.
• Added unit tests covering default behavior, overrides, empty-body handling, and DB error propagation.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
backend/pkg/controller/prompter.go	Adds newUserPrompter / buildUserPrompter to merge user overrides with default templates and return a flow prompter.
backend/pkg/controller/prompter_test.go	Adds unit tests validating merge behavior, fallback to defaults, and error propagation.
backend/pkg/controller/flow.go	Switches flow worker creation/loading to use newUserPrompter instead of NewDefaultPrompter().
backend/pkg/controller/assistant.go	Switches assistant worker creation/loading to use newUserPrompter instead of NewDefaultPrompter().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mason5052]

Pushed a follow-up commit (3278c62) addressing both Copilot review comments:

1. JSON round-trip in buildUserPrompter -- Added a new templates.LoadDefaultPromptsMap() helper that returns the embedded defaults as a PromptsMap directly. buildUserPrompter is now a pure map-merge step with no encoding/json involvement. defaultPrompter.DumpTemplates() was refactored to delegate to the same helper, so the JSON output exposed through the existing API is byte-identical (still alphabetical order from embed.FS.ReadDir).

2. N+1 prompter loads in LoadFlowWorker -> LoadAssistantWorker -- Added an optional prompter templates.Prompter field to assistantWorkerCtx. LoadFlowWorker builds the user prompter once for the flow and threads it through to every assistant in the flow load. LoadAssistantWorker reuses it when present and falls back to newUserPrompter(...) when invoked outside a flow load (i.e., the existing standalone code path keeps working unchanged). Net effect: a flow with N assistants now does one GetUserPrompts query + one default-template merge instead of N+1.

Also updated the PR description to make the per-session snapshot semantics explicit: customizations edited mid-session are not applied retroactively; only sessions created/loaded after the edit pick them up. This is unchanged behavior, but worth calling out so future readers don't expect live mutation.

go test ./pkg/controller/... ./pkg/templates/... is green.

[jakgeg009]

Hi, thanks for proposing those changes so quickly. Are there any updates on when this will be merged with main, to update Docker Hub with the new image. It would be great to be able to customize the system prompts. Seems like a pretty basic feature, but would be very helpful.