Engineering note · Editor state integrity
A Pine Script Save Is Not Successful Until the Target Script Is Verified
Prevent Pine Script automation from saving into the wrong TradingView editor by verifying the exact script binding before dispatch and the persisted source after save.
Visible symptom
Automation reports Save completed, but another Pine script changed or the intended script stayed untouched.
Root boundary
A UI command was treated as success without proving which editor document owned the action.
Hard rule
Verify the exact script before dispatch, then re-read the persisted target before returning success.
A successful shortcut is not a successful save
Pine editor automation often starts with a simple sequence: find a script, focus the editor, replace source and trigger Save. The sequence looks deterministic when only one document is open. It becomes unsafe as soon as the browser restores another tab, a duplicate title exists, a modal changes focus or the platform finishes loading after the command starts.
The failure is easy to miss because the shortcut itself can succeed. No browser error is required. The wrong document may accept the write and the automation may return a green result even though the requested target was never persisted. A save contract therefore has to prove identity on both sides of the side effect.
Use a two-sided save contract
The precondition protects the wrong script from mutation. The postcondition prevents a dispatched shortcut from being mistaken for persisted state.
Resolve
exact script identity
Dispatch
replace and save once
Verify
re-read persisted source
Fail closed when identity is missing, duplicated or changed during the command. A visible editor and a clickable Save control are not enough evidence.
The smallest reliable implementation
- 1
Name the expected target.
Use a stable script ID when available. Otherwise require an exact normalized title plus one additional identity field.
- 2
Read the active binding.
Inspect the document actually attached to the editor immediately before mutation.
- 3
Reject ambiguity.
Zero matches and multiple matches are both failures. Never choose the first substring result.
- 4
Dispatch one mutation.
Replace the intended source and issue one save action without blind retries.
- 5
Re-read the target.
Compare persisted content or a strong source hash with the expected value before returning success.
Three acceptance tests
These tests exercise identity, ambiguity and persistence separately. A clean happy-path save does not cover any of them.
Test 1
Wrong editor binding
Input: The open editor is bound to Strategy B while the command expects Strategy A.
Pass: The save is rejected before any keyboard shortcut or write action is dispatched.
Test 2
Ambiguous script lookup
Input: Two scripts contain the requested text, such as Breakout and Breakout Copy.
Pass: Exact identity resolution returns one script or fails. A substring match never selects a target.
Test 3
False success after dispatch
Input: The save command runs, but the persisted target still contains the previous source.
Pass: The command reports failure because the re-read source does not match the expected content.
What this contract does not prove
Exact persistence does not prove that the Pine code compiles, produces the intended alerts or behaves the same after a chart reload. Compilation, alert snapshots, higher-timeframe timing and strategy execution each need their own acceptance cases.
It also does not prove profitability or future results. The contract only establishes that automation changed the requested source document and can demonstrate the persisted result.
Free next step
Freeze the target before changing editor automation
Use the free scope builder to record the Pine version, exact script identity, authorized source, expected persisted content and the three failure cases the save path must reject.