Conversation Modes - Admin Created System Prompts - Opt In

[DerrickF]

Summary
Adds Conversation Modes: admins manage a catalog of custom system prompts (Guided Learning, Concise, Plan-First, Devil's Advocate, Citation-Strict, Caveman, etc.), users opt in per conversation from the model-settings panel. The active mode is appended to the base system prompt at invocation time and persists across sessions, refreshes, and devices.

Why
Assistants cover the "scoped to a body of knowledge" use case. They don't cover behavioural overlays — how the assistant works on whatever topic you're already discussing. Conversation modes fill that gap:

Topic-agnostic; one mode works across any conversation.
Mid-conversation toggle without losing context.
Admin-curated so the catalogue stays consistent across the institution.
Users see name + description only — prompt text is server-side, never exposed.
What's in the box
For admins — /admin/system-prompts CRUD UI: create, edit, enable/disable, delete prompts. Status defaults to enabled; disabled prompts are hidden from users but kept for audit.

For users — A new "Conversation Mode" radio group in the model-settings panel and a dismissable chip in the chat input. Selection persists per-conversation and survives refresh.

For the inference path — A new system_prompt_resolver module that gates on resume / continuation / preview / assistant-attached turns and appends the prompt with a consistent ## Active Mode: header.

How it works

admin → /admin/system-prompts (CRUD)
└─ DynamoDB: PROMPT# / METADATA

user → /system-prompts (read; enabled-only, name+description only)
→ settings panel selection
└─ frontend signal _activePromptId (bound to session id)
└─ on submit: forwarded as selected_prompt_id on InvocationRequest

inference path
→ resolver: request id > session metadata > none
→ mirrors id back onto session preferences for resume / refresh
→ appends prompt to base system prompt
Selection precedence
Request body (current turn's choice) — handles the first turn of a brand-new session before any metadata row exists.
Session preferences (persisted) — handles resume, refresh, and new-device flows.
Skipped on resume (snapshot owns the prompt), continuation (would invalidate prompt caching), preview (live form edits drive it), and assistant-attached turns (assistants are KB-grounded with their own instructions).

Wire format
Snake_case end-to-end, matching the user_menu_links convention. selected_prompt_id uses null-as-clear semantics on the BFF metadata PUT, leveraging Pydantic's model_fields_set to distinguish "explicitly cleared" from "field omitted — leave unchanged".

Infrastructure changes
New DynamoDB table provisioned by InfrastructureStack: -system-prompts, PAY_PER_REQUEST, point-in-time recovery, AWS-managed encryption.
SSM parameters //admin/system-prompts-table-{name,arn}.
App API IAM: full CRUD on the table.
Inference API IAM: dynamodb:GetItem only.
Tests
32 system_prompts tests — model, repository, service, admin + user routes; covers snake_case wire format, Literal status validation, TOCTOU-safe update.
5 sessions update tests — null-clear, omit-leaves-unchanged, disabled-prompt rejection.
15 resolver tests — gating matrix, composition format, request-id precedence, persistence side-effect, exception swallowing.
666 backend tests pass. Frontend typecheck and Angular build clean.

Manual verification
Create / edit / disable / delete prompts as admin
Pick a mode on the home page; submit; verify prompt is applied to first turn (no metadata round-trip needed)
Pick a mode on /s/; refresh; verify chip rehydrates from persisted preferences
Switch sessions; verify chip resets and doesn't leak across conversations
Dismiss chip; verify next turn doesn't apply the prompt
Disable a prompt admin-side; verify a user with that prompt selected silently falls back (no error)
Known limitations / follow-ups
Concurrent-write window on set_selected_prompt_id: same Read-Modify-Write on the preferences map that update_session_activity already has. Documented in code. Proper fix is nested-attribute SET, which requires pre-creating the preferences map everywhere first — tracked separately.
Sub-200ms clear race: a user who clears a prompt and submits within the BFF persist round-trip can have one stale "mode applied" turn. Bounded blast radius, self-healing, deliberately not fixed by widening the wire protocol.
Pre-existing enabled_tools falsy bug (unrelated): if request.enabled_tools treats [] as "don't update," so a user disabling all tools never persists. Worth a separate ticket.
Operational follow-up after deploy
The temp DynamoDB table created manually before CDK provisioned the real one needs to be deleted post-deploy. Steps:

Confirm -system-prompts exists post-deploy and SSM params resolve.
Smoke-test admin CRUD round-trip end-to-end.
Migrate any seeded prompts from the temp table (small enough to re-create through the UI).
aws dynamodb delete-table --table-name .
Out of scope
Mode stacking (Concise + Code Reviewer, etc.) — single active mode per session for v1.
Role-scoped modes (visible_to_roles) — would let modes be scoped to faculty / students / staff. Worth adding once role data is everywhere it needs to be.
Department-level catalogues — central catalogue only for v1; could grow into per-college / per-department admin scoping later.