renderVarStrip's rebuild-signature computation (src/ui/workbench/variable-strip.ts, the sigNew build — moved verbatim from src/ui/app.ts, present unchanged on origin/main before the #588 phase-4 refactor) folds in each variable's control kind and enumOptions.length, but not the option identities:
return v.name + ':' + v.type + (v.optional ? '?' : '') + (v.conflict ? '!' : '')
+ ':' + c.kind + (c.enumOptions ? c.enumOptions.length : '');
Repro: a variable's inferred enum options change from ['a', 'b'] to ['c', 'd'] (same cardinality) between two renderVarStrip passes — e.g. a background schema/column reload landing between keystrokes. The signature is unchanged, so the strip does not rebuild, and the dropdown keeps offering the stale ['a', 'b'] set even though deps.params.inferredEnumOptions(...) now returns different values.
Surfaced during phase 4 of the #593 refactor umbrella's PR review (#604) — pre-existing, not introduced by that PR, and deliberately left unfixed there (a pure structural extraction is not the place for a behavior change). A comment at the signature site documents this; no regression test was added for the same reason.
Suggested fix direction: fold a stable digest of the option identities themselves into the signature (e.g. join the resolved enumOptions array), not just its length.
renderVarStrip's rebuild-signature computation (src/ui/workbench/variable-strip.ts, thesigNewbuild — moved verbatim fromsrc/ui/app.ts, present unchanged onorigin/mainbefore the #588 phase-4 refactor) folds in each variable's controlkindandenumOptions.length, but not the option identities:Repro: a variable's inferred enum options change from
['a', 'b']to['c', 'd'](same cardinality) between tworenderVarStrippasses — e.g. a background schema/column reload landing between keystrokes. The signature is unchanged, so the strip does not rebuild, and the dropdown keeps offering the stale['a', 'b']set even thoughdeps.params.inferredEnumOptions(...)now returns different values.Surfaced during phase 4 of the #593 refactor umbrella's PR review (#604) — pre-existing, not introduced by that PR, and deliberately left unfixed there (a pure structural extraction is not the place for a behavior change). A comment at the signature site documents this; no regression test was added for the same reason.
Suggested fix direction: fold a stable digest of the option identities themselves into the signature (e.g. join the resolved
enumOptionsarray), not just its length.