Positions

A position is the runtime's current reported exposure. Read it before placing or closing an order; a strategy signal is not a substitute for execution state.

Read the position snapshot

Use await context.getPositions() and verify the returned shape expected by your strategy. The example relies on instrument, action, and quantity, with BUY representing a long and SELL a short in the shared model.

Use the full returned position when requesting a close. Do not invent a position from the last signal or mutate the snapshot as a way of changing broker exposure.

Keep ownership explicit

The first SJS example assumes one instrument and at most one position. It waits on multiple returned positions and leaves an unexpected short alone. Those are intentional guards, not a portfolio allocation system.

Broker/session adapters determine how account state is reflected into a session. If multiple apps can affect the same account, inspect identity and ownership before interpreting a position as exclusively controlled by your strategy.

Shared simulated updates

A same-side fill adds to the existing position quantity. An equal opposite-side fill removes the position. A smaller opposite-side fill reduces its quantity. An oversized opposite-side order is not automatically converted into a reversal by this shared routine.

These simplified mechanics do not establish broker-quality average-cost or partial-close accounting. In particular, do not infer a fully weighted cost basis merely because same-side quantity increased. See simulation versus broker.

Separate exposure from records

Trade history can contain entry records and closing records. Counting those rows does not necessarily count completed positions or round trips.

After a request, inspect pending orders, position quantity, and new trade records together. A position may remain while an exit is pending, and a run marked completed does not guarantee it finished flat.

Continue with closing positions.