The console sends a per-rule system_prompt that no page can read or edit

[Indervertrag2]

What happened

/prompt is the console's only interactive surface for the VLM system prompt. Its
heading reads "Edit the system prompt for the Vision Language Model"
(src/app/prompt/page.tsx:148-150). Saving patches the VLM_SYSTEM_PROMPT env var
on the vss-rtvi-vlm Deployment and restarts it: src/app/api/prompt/route.ts:157
calls reconcilePrompt, and src/lib/reconcile/prompt.ts:24-25 does exactly
patchDeploymentEnv + restartDeployment. POST /api/profiles/{name} applies a
profile's vlmPrompt through the same env var
(src/app/api/profiles/[name]/route.ts:99-100).

Independently of that, every realtime alert rule the console creates carries its
own system prompt, read from the realtime-alert-rules ConfigMap and put on the
wire per rule:

src/lib/helpers/ingestion.ts:198    systemPrompt: doc?.system_prompt,
src/lib/helpers/alert-bridge.ts:82  if (input.systemPrompt !== undefined)
                                      body.system_prompt = input.systemPrompt;

That value is shown nowhere in the console and cannot be changed from it. A
repository-wide search for system_prompt outside tests returns four hits: the
type declaration, the read above, the wire helper above, and the field name in a
PRESERVE array. None of them is a writer.

So the page that says it edits the VLM system prompt edits a different value from
the one the console transmits, and the transmitted one has no surface at all.
What happened:
/prompt is the console's only interactive surface for the VLM system prompt. Its
heading reads "Edit the system prompt for the Vision Language Model"
(src/app/prompt/page.tsx:148-150). Saving patches the VLM_SYSTEM_PROMPT env var
on the vss-rtvi-vlm Deployment and restarts it: src/app/api/prompt/route.ts:157
calls reconcilePrompt, and src/lib/reconcile/prompt.ts:24-25 does exactly
patchDeploymentEnv + restartDeployment. POST /api/profiles/{name} applies a
profile's vlmPrompt through the same env var
(src/app/api/profiles/[name]/route.ts:99-100).

Independently of that, every realtime alert rule the console creates carries its
own system prompt, read from the realtime-alert-rules ConfigMap and put on the
wire per rule:

src/lib/helpers/ingestion.ts:198    systemPrompt: doc?.system_prompt,
src/lib/helpers/alert-bridge.ts:82  if (input.systemPrompt !== undefined)
                                      body.system_prompt = input.systemPrompt;

That value is shown nowhere in the console and cannot be changed from it. A
repository-wide search for system_prompt outside tests returns four hits: the
type declaration, the read above, the wire helper above, and the field name in a
PRESERVE array. None of them is a writer.

So the page that says it edits the VLM system prompt edits a different value from
the one the console transmits, and the transmitted one has no surface at all.

What you expected instead

Either of these would be consistent:

• /prompt reads and writes the value the console actually sends, re-registering
  the affected rules the way PATCH /api/tuning/sampling already does
  (src/app/api/tuning/sampling/route.ts:145-176), or
• /prompt names which of the two it edits, and shows the per-rule system_prompt
  read-only beside it.

The console already proves it knows the field exists: system_prompt is in the
PRESERVE array at src/app/api/tuning/sampling/route.ts:145-150, so that a
sampling change does not drop it while deleting and re-posting each rule. It is
carried through, never shown.

The same holds for enable_reasoning, read at src/lib/helpers/ingestion.ts:202,
forwarded at src/lib/helpers/alert-bridge.ts:86, preserved on line 147, and
surfaced nowhere. It decides whether incident summaries carry the model's
reasoning text, which is a visible product of this UI.

Steps to reproduce

Entirely from the repository, no deployment required.

1. Follow the save path from the only prompt surface:
   src/app/prompt/page.tsx:148-150 -> src/app/api/prompt/route.ts:157 ->
   src/lib/reconcile/prompt.ts:24-25, which patches promptKey and restarts.
   promptKey is VLM_SYSTEM_PROMPT (src/lib/cluster-refs.ts:358).

2. Follow the rule-creation path: src/lib/helpers/ingestion.ts:198 takes
   system_prompt from the rules ConfigMap and passes it to addRealtimeRule,
   which writes it into the request body at src/lib/helpers/alert-bridge.ts:82.

3. grep -rn "system_prompt" src/ --exclude=".test."
   Four hits, no writer.

4. grep -rn "system_prompt|rules.json" docs/
   No hits. The field is undocumented.

On a running console the two values can be compared directly: read the text on
/prompt, then read system_prompt on GET /api/v1/realtime after
recreating a rule via PUT /api/cameras/ with {"ingestion":{"enabled":false}}
then true, which is the path that rebuilds it
(src/app/api/cameras/[id]/route.ts:157).

This report makes no claim about which value the VLM ends up using; that is
decided outside this repository. The defect stands either way: the console can
neither show nor edit a value it sends itself.

How it is running

In-cluster Kubernetes pod (namespace console)

Console version

4688890

VSS profile and storage

alerts profile, Helm chart vss-3.2.1. Object storage is ARTESCA 4.3.0-rc.1.

Diagnostics

Not applicable: both code paths are in this repository and no cluster state is
needed to see them.

Before submitting

• This is not a security vulnerability. (Those go through the Security tab — see SECURITY.md.)
• I have redacted credentials, tokens and internal hostnames.

[Indervertrag2]

Related, same page: the "Current (read-only)" pane is not current

The prompt page renders two panes, Current (read-only) and Proposed (editable) (src/components/prompt/PromptEditor.tsx:87 and :107). The left one is fed from GET /api/prompt, which returns the config store's value, not the runtime's:

src/app/api/prompt/route.ts:38

// k8s path: Firestore is the source of truth for the desired prompt.

src/app/api/prompt/route.ts:56

return NextResponse.json({ prompt: doc?.prompt ?? "", model, runtime: "k8s", ... })

readLiveVlm() is called on the same line, but only for the model's display
name. The prompt itself is never read back from the cluster.

A helper for exactly that already exists and is unused by this page:

src/lib/helpers/prompt-apply.ts:12-29

/** Read the current VLM prompt from the live runtime. */
export async function readPromptLive(): Promise<string> {
  ...
  return envVars.find((e) => e.name === CLUSTER.rtvi.promptKey)?.value ?? "";

Its only caller in src/ is src/app/api/prompt/sync-gcs/route.ts:30.

The repository already knows the pane and the runtime can disagree.
src/lib/reconcile/prompt-seed.ts:11-13, describing a missing active pointer:

which makes the console's "Current (read-only)" pane render blank (readPrompt
returns the active set's text, and null when nothing is active) even though the
VLM is running fine off a previously-reconciled prompt.

Why this compounds the issue above

An operator on this page is looking at three values and can see only one of them:

value	where it lives	visible in the console
desired prompt	config store	yes, labelled "Current"
live VLM_SYSTEM_PROMPT	Deployment env	no, although readPromptLive() exists
per-rule system_prompt	realtime-alert-rules ConfigMap	no

The one that is shown is the only one that is not a runtime fact, and it is the
one labelled "Current". After a failed or skipped reconcile the page will happily
show a prompt that nothing is running.

Suggested shape

Feed the left pane from readPromptLive() and label it "Live". Show the per-rule
system_prompt beside it, read-only at minimum. Both values are already
obtainable with helpers this repository ships.

Impact on a deployment we run

CONTRIBUTING invites saying so, so: this is currently blocking. We are tuning VLM
prompts for a retail scenario, and no page in the console can set the prompt that
reaches the model. /prompt writes the env var described above. The per-camera
"Detection prompt" selector writes a promptId that nothing reads. /test-footage
offers only the prompts already present on live rules, although
POST /api/test-footage/run accepts an arbitrary one. Every prompt change we make
therefore goes through kubectl against the rules ConfigMap. Not urgent in the
sense of an outage, but it is the reason we went looking.