Engineering note · Handoff acceptance
Three Acceptance Tests Every Trading Bot Should Pass Before Handoff
Test attach behavior, one new event and refresh or reconnect recovery before accepting an EA, cBot or Pine automation handoff.
Attach
Historical data may load, but it must not become a new action.
Next event
One newly completed valid event must create exactly one expected result.
Recovery
Refresh or reconnect must preserve what the bot already handled.
A successful demo run is not a handoff test
Most trading bots are demonstrated on the easiest path: attach the program, wait for a valid signal and show that an alert or order appears. That confirms the main rule can execute. It does not confirm what happens when the chart already contains signals, when the platform reloads history or when a network reconnect repeats the newest event.
Those boundaries matter because a trading automation does not start in an empty world. An EA receives existing bars during initialization. A Pine script recalculates across its dataset. A cBot can restart while positions and pending orders still exist. If the handoff says only “the strategy works,” the buyer still has no objective answer for the three moments most likely to create surprise actions.
The source for this note is a public issue about alerts being triggered on historical bars after refresh. The useful engineering question is broader than that one script: which event is genuinely new, which event was already handled, and where is that decision stored?
Source and public evidence
The minimum state boundary
The bot needs a small, explicit answer to “what have I already handled?” For bar-based logic, that may be the newest completed bar time. For an external webhook, it may be a stable event ID. For position management, it may include the owned ticket and the active management stage. The exact fields differ, but the rule does not: initialization reconstructs state; it does not invent a new event.
Baseline
Read the current platform and owned-trade state without producing an external side effect.
Identity
Give each actionable bar, signal or message one stable identity.
Commit
Record the handled identity only at the defined success boundary, then recover it after restart.
The three acceptance cases
Run these cases on the exact platform build, symbol, timeframe and settings named in the scope. A screenshot of one successful alert is not enough. Each case needs a repeatable setup, one visible expected result and a saved log or platform artifact.
Attach without replay
Setup: Start the bot on a chart that already contains historical signals or completed bars.
Pass: The bot establishes its baseline and emits no historical alert, order or duplicate side effect.
One new event
Setup: Close one new bar or deliver one new event that satisfies the frozen rule.
Pass: Exactly one expected action appears with the correct symbol, side, size and event identity.
Refresh or reconnect
Setup: Refresh the chart or reconnect after the newest event has already been handled.
Pass: Handled history stays handled and the newest event is not repeated.
What the evidence should show
The attach case should show the loaded history boundary and zero outbound actions. The next-event case should show the event identity, the evaluated rule and one resulting action. The recovery case should show the same stored boundary before and after refresh, with no second alert, order or management transition.
Keep the proof close to the behavior. Platform logs, a short deterministic replay and an exported settings file are more useful than a long screen recording with no visible event identity. If the system talks to a broker or webhook receiver, add the external ticket or request ID so the two sides can be reconciled.
A failed case should stop acceptance. It should not become a vague promise to “watch it live.” The developer can fix the smallest failing boundary and rerun the same case. That is cheaper and safer than changing unrelated strategy logic or judging the result by profit.
What these tests do not prove
Passing these cases does not prove profitability, favorable fills, low drawdown or challenge success. It proves only that initialization, one new event and recovery follow the frozen behavior without replaying handled history.
Entry rules, position sizing, broker constraints, platform version and ownership of existing trades remain separate scope fields. Freeze them before implementation, then add strategy-specific positive and negative cases on top of this handoff baseline.
Free next step
Freeze the three cases before coding
Use the free scope builder to name the attach baseline, the one valid next event and the refresh or reconnect result. That gives the buyer and developer the same pass condition before price and delivery are fixed.