pine_open replaces the editor buffer with no confirm_overwrite guard, unlike pine_new and pine_set_source

[stanzhang]

pine_open replaces the editor buffer with no guard, unlike its siblings.

src/core/pine.js, openScript():

var m = FIND_MONACO;
if (m) {
  m.editor.setValue(source);
  return {success: true, ...};
}

pine_new and pine_set_source both call _assertBufferSafeToReplace() and
refuse a non-trivial buffer unless confirm_overwrite is passed — which reads
like a deliberate policy, and 2.3.0's changelog describes adding exactly that
guard after a real script was destroyed. pine_open takes the same destructive
action against the same buffer and skips it.

Why it bites

Opening a saved script is the natural way to read one, so an agent reaches for
it early and often. If the user had unsaved work in the editor — which is the
normal state while iterating on a script — it is gone, with no prompt and no
mention in the result.

Suggested fix

Route it through the same guard and accept the same parameter:

await _assertBufferSafeToReplace(confirm_overwrite, 'pine_open');

That makes the three buffer-replacing tools consistent, and the failure mode
becomes an error a caller can act on rather than silent data loss.

Worth knowing: reading source does not need the editor at all

openScript already fetches the source over the pine-facade REST API before
injecting it:

GET https://pine-facade.tradingview.com/pine-facade/get/<scriptIdPart>/<version>

So a read-only pine_get_script_source(name_or_id) that returns the source
without touching Monaco would serve the common case — comparing a saved
script against a local file, auditing what is deployed — with no buffer risk at
all. I use that endpoint directly for exactly this, and it means the guard above
would rarely be hit in practice.

Two adjacent observations from the same account

• A saved script's list name and the title declared in its code diverge
  often — 20 of 53 scripts here. openScript matches on scriptName first,
  then scriptTitle, then a substring fallback, so "open the script called X"
  can land on something whose code says it is Y.
• One in-code title was shared by four different saved scripts, because
  source had been saved over each of them at some point. Any name-based lookup
  is ambiguous in that situation, and the substring fallback resolves it
  silently. Returning the candidates instead of guessing would be safer.