Persona edits silently leave linked instance parallelism and ACP command stale

[rsaulo]

Summary

In desktop-v0.5.8, editing a persona does not propagate parallelism or acp_command to already-linked instances, while neighboring persona-backed fields do update. The UI gives no indication that the persisted instance has diverged from the values shown in the persona dialog.

This is a consistency bug rather than a feature request: these two fields bypass the effective-config/live-persona paths used by adjacent settings, and the mismatch is silent.

Evidence

For a linked record, resolve_effective_config matches record.persona_id; resolve_linked then resolves model, provider, and system prompt from the persona. Those fields therefore reflect persona edits.

Persona environment variables are also live at spawn: the descriptor is documented and applied as definition ... -> global -> live persona -> per-agent on every spawn (runtime.rs:801-810). I also confirmed this at runtime by adding a variable only to the persona definition and observing the child process read it.

parallelism and acp_command bypass those paths:

• runtime.rs:677-678 computes BUZZ_ACP_AGENTS from raw record.parallelism.
• runtime.rs:476-477 resolves raw record.acp_command.

The persona update path does not refresh either snapshot. Its helper explicitly propagates only a display_name rename (personas/update.rs:31-35), and the update path only considers avatar/display-name propagation (personas/update.rs:140-184).

Reproduction observed

1. Set a persona to parallelism = 3.
2. Start an already-linked instance.
3. Observe that it starts with BUZZ_ACP_AGENTS=10.
4. Restart it repeatedly; it continues to use 10 while the persona dialog shows 3.
5. Edit the instance record directly; only then does the spawned value change.

User impact

The displayed configuration and actual runtime configuration disagree without a warning. acp_command is especially difficult to recover from because the instance-edit dialog is not reachable for an agent linked to a persona, so there is no UI path to correct the stale instance value.

Possible resolutions

Either approach would make the behavior coherent:

1. Route parallelism and acp_command through the effective-config/live-persona resolution used by neighboring fields; or
2. Keep instance snapshots authoritative, but surface the divergence clearly in the UI.

I am not prescribing which ownership model is preferable; the key requirement is to avoid silently showing persona values that the linked instance will not run.

[wolfyy970]

I think this is the same ownership problem being worked on in #5328. Blindly cascading persona values into every linked record would overwrite deliberate instance choices.

The durable rule should be: the template owns defaults, an agent stores only explicit overrides, and runtime resolution records what the current generation actually applied. The edit flow must also say whether the owner is editing this agent or its template, show which agents the template change affects, and show restart or redeploy required until applied state matches.

[rsaulo]

Agreed, and thanks for the pointer — I read through #5328 and you are right that this is the same ownership problem. Linking it explicitly: this issue is the runtime-side half of the blocker you have been holding #5328 on. Your durable rule is the right one, so let me add what the persona path specifically breaks under it, because I do not think it is covered by the dialog work yet.

1. There is no record of what the running generation applied — for these two fields there cannot be one today.

Your third bullet — runtime resolution records what the current generation actually applied — is exactly what is missing here. BUZZ_ACP_AGENTS is computed from raw record.parallelism at spawn (runtime.rs:677-678) and acp_command is read raw at runtime.rs:476-477, neither through resolve_effective_config. Nothing writes the applied value back, so there is no state to compare the saved value against. "Restart or redeploy required" cannot be surfaced for these two fields until that resolution goes through the effective-config path that model, provider, prompt and persona env already use.

2. Under your rule, these fields are currently neither a default nor an explicit override.

The instance's parallelism and acp_command are snapshots seeded at link time, not choices the owner made. If #5328 lands the template/override model and treats every existing instance value as an explicit override, every already-linked agent keeps a phantom override, and template edits go on appearing to do nothing — the same silent divergence, now with a UI that claims field ownership is settled. So this needs a migration call: an instance value that still equals the persona value it was seeded from should resolve as inherit, not as a frozen override.

3. acp_command is the worst case because there is no way out of it.

In desktop-v0.5.8 the instance-edit dialog is not reachable for an agent linked to a persona, so a stale acp_command is a phantom override the owner cannot see or correct from any UI path — only by editing the instance record directly. Whatever object-choice UI #5328 settles on, this field needs an escape hatch on day one.

One smaller overlap worth flagging: the parallelism validation gap in your last review at 8cc6e5a11 (no maximum, nonblank 0/negatives silently reverting) is the same field as this one. If validation lands on the definition form while the value is still resolved raw from the instance record at spawn, a valid definition value and an invalid instance snapshot can still coexist. Validating where the value is resolved, not only where it is typed, would close both.

Happy to fold this into #5328 as a review comment instead if you would rather keep it in one place — the reproduction and the code references are in the issue body above.

[wolfyy970]

Keep this issue open. It gives #5328 a concrete runtime acceptance test, and I would not bury it in that PR.

One correction after checking current main: local processes already stamp acp_command and effective parallelism in SpawnConfigSnapshot, so the applied-state seam exists. The missing piece is desired resolution. Parallelism still comes from the copied record, so a template change produces no prospective diff. acp_command is different: AgentDefinition has no such field. The definition owns the agent runtime, while buzz-acp remains instance and target launch plumbing.

For migration, equality can safely become inherit. A different legacy value is ambiguous, so I would preserve it as a legacy override and ask the owner rather than guess. I will use this issue as the runtime dependency for #5328.