Execution primitives
Coordinate configured actions with SJS and interpret primitive parameters through their implementation.
Execution primitives can request entries, closes, or other actions when their conditions hold. They are not simply numeric indicators. Read the primitive reference and the selected implementation before combining one with SJS.
Assign an owner for each action
A strategy might let SJS own entries while a configured primitive owns exits. Alternatively, SJS can own both. Define that division explicitly and test a frame where several conditions become true together.
If SJS submits an action and calls skipall, later ordinary model callbacks can be skipped. Session-model exceptions still exist. A configured exit is therefore not automatically an independent broker-resident protection order.
Inspect stopLoss concretely
The current shared stopLoss primitive evaluates an existing position during its callback. When its condition holds and transmission is enabled, it calls context.closePositions(position).
Its ticks comparison currently uses the raw difference between entry and current price. Do not assume it converts exchange tick counts using an instrument tick size. Its percentage calculation is also specific to this implementation; verify the units with a known entry/current-price fixture before configuring it.
The reference lists transmit, but the current constructor initializes it to false unless enabled. Set transmit explicitly instead of relying on a displayed default. These notes describe the existing implementation without changing the generated catalog.
A trigger is a close request
A triggered primitive still depends on runtime processing and execution. The shared close path can encounter automation and L3 checks, placement eligibility, and fill delay. It is not proof of a filled exit at the threshold price.
A runtime that never receives the expected observation cannot evaluate that callback at the imagined time. Review the selected data granularity and session rules with the primitive's condition.
Test ownership and outcomes
Begin with one primitive and one clear triggering case. Inspect the request source, signal/condition, pending order, and resulting position. Then add the main SJS strategy and verify that it does not duplicate or skip the intended action.
Continue with examples for calculation-only scripts, or Orders & Positions for execution behavior.