StockSharp Odysseus

Measure what this instrument's history actually contains, before proposing anything for it: how much it moves, whether moves continue or come back, what followed the events a strategy would trade, and how the day is shaped. Read this first. A breakout hypothesis on an instrument whose breakouts led nowhere costs a generation of candidates to disprove, and the numbers here say so beforehand. Measured on the development slice only, so nothing here comes from data held back for judging.

Turn a recorded specification into a real StockSharp strategy and compile it. This is where a project starts spending its allowance, so it is worth reading analyze_market first: a hypothesis the data already contradicts costs a candidate to disprove. A specification reworded without changing what it does builds to the same code and costs nothing — the same candidate is returned. Nothing is run here; use run_backtest for that.

Check whether this candidate is a function of its data: the same history in, the same trades out. Two checks. Its source is read for anything that differs between runs - the machine clock, numbers nobody seeded, a string's per-process hash, the file system, the network, timing - however it is reached. And it is run twice over the development slice and the two runs compared trade by trade, which catches what the source does not show. Costs two backtests. A candidate that fails either check produces numbers that cannot be arrived at twice, so nothing measured of it means what it says.

Declare a strategy finished and keep it. This is the one place a conclusion is recorded, and the conclusion is yours: the server runs strategies and reports numbers, and whether these numbers are worth trading is a judgement it never makes. Call it once you have read the runs and decided. What gets written into the project folder is the generated C#, the specification it was translated from, and one metadata file holding everything the server knows — the instrument, the timeframe, the parameters it was run with, the dataset and where its bars came from, how the data was divided, every completed run with its full metrics, both measurements, and the reason you give here. Say that reason properly: it is the only part of your decision the server can keep, and in six months it is the only thing that explains why this strategy and not another. A candidate the closed data has never seen is refused.

Create a research project. Pass an operationKey you generate once per intent: repeating a call with the same key returns the project the first call created instead of making a second one, which is what makes a retry after a dropped connection safe.

Run a candidate the closed data has already measured against the live paper account, with the numbers it was measured with and a position sized by the same rule the backtests used. This is the first thing that can contradict a backtest: a fill that never comes, a spread wider than the one that was charged, a bar that arrives late. None of it shows up in history. IMPORTANT: the deployment runs in a process of its own and keeps trading when you disconnect, when this server exits, and after the machine's session ends - until something stops it. Nothing stops it on your behalf, so whatever you start here is yours to stop with stop_deployment, and a later session can find it again with list_deployments. Every deployment this server starts trades on a paper account. One deployment per project: two strategies on one account trade against each other's positions and neither result means anything afterwards.

Download a connector package and report what it is without binding it: the adapter inside it, what it is for, which credentials it takes, whether it can be proven to be on a paper account, and every setting it accepts with the values each one allows. Reading it downloads the package and builds the adapter, so a hosted instance refuses this as it refuses select_connector. Read this before select_connector: the settings it reports are exactly the ones selecting will accept.

Report the server version, the mode it runs in, and whether a broker connector is bound. Call this first: half of what this server can do depends on whether a connector was chosen, and being refused mid-plan is a worse way to find that out. It also says where the deployments this server starts keep their records, which is what a later session reads them back from.

Describe how the history is divided in time: development (the first three fifths), validation (the next fifth) and the closed slice (the last fifth). Form hypotheses and search on development, measure on validation through run_backtest. No tool hands out the closed slice's bars; it is measured once, for the finalist only, and once spent it is spent for every project on this machine that imports the same stretch of the same instrument.

Run a candidate six times — development, validation, validation with costs half again as high, and three consecutive walk-forward windows — and report what each one came to. Which runs those are is fixed, so the evidence cannot be chosen to suit the answer. All six fill on the bar the signal fired on; whether the result survives an entry a bar later is a separate question, asked with run_backtest under the 'entryOneBarLater' scenario. The result is statistics: profit, drawdown, trade counts, win rate, exposure, costs, concentration, and the spread between windows. It contains no verdict and no score, because deciding whether these numbers are worth trading is yours to do, not the server's. The closed part of the history is not touched here.

Cut a run's result apart: month by month, by the part of the session a position was opened in, by how long positions were held, and by direction. A run reports one number for a whole stretch of history, and one number cannot tell an edge that held throughout from a single fortnight that paid for everything around it - which is the common case. Read netWithoutBestMonth first: a candidate that turns negative there made its money in one stretch of the market rather than out of something repeatable. Nothing is re-run and nothing is charged, so ask freely; these are the trades the run already recorded, grouped.

Read an account itself: whether it may trade, what it can buy with, everything it is holding and every order it has live. This is the broker talking, not this server - every other number about a deployment is what was recorded while something was watching, and a deployment nobody has spoken to since has been recording nothing. Pass a deploymentId to read the account that deployment's own process is trading on, which is the one holding its position; pass an empty deploymentId to read the account this server bound, which is a paper one and need not be the same. Read this after anything ends unexpectedly. It only reads; closing a position is not something this server does on your behalf.

Read the permanent record of a project: what happened, who caused it — user, agent or the server itself — and when. Entries are append-only and their sequence has no gaps, so a missing step is visible. The record grows with everything the project does, so this answers a page at a time and says how to ask for the next.

Read the C# a candidate was compiled from. It is an ordinary StockSharp strategy: the parameters it declares are the ones an optimiser may vary, and every rule carries the identifier it has in the specification, so the two can be read side by side. This is also the file to hand to anyone who asks what the strategy actually does.

Say whether this project has spent its one measurement against the closed part of the history, and on which candidates. Where the closed part lies is in describe_split.

Report the dataset this project researches: symbols, timeframe, range, how many bars each symbol kept, and what was rejected — malformed bars, repeated moments, missing bars. Bad bars are dropped rather than repaired, so a gap here is a gap in what any result can be based on.

What a deployment has done against the broker, next to what the closed-data run said it would do. Rates are per trading day on both sides, so a deployment up for a few days can be read against a run measured over months. Watch two things above all: whether it trades at the rate it was supposed to, and whether one trade comes to what one trade came to in the backtest. A strategy that trades far less than expected is not being filled; one whose average trade is far worse is paying costs the backtest did not charge. Read 'runner' before any of the numbers: 'attached' means the figures are current, 'gone' means the process ended and left whatever it held as it stood, and 'unresponsive' means the process is alive and not answering - which is the one that may still be trading and still be holding a position.

Read the numbers already recorded for a candidate: every run, every figure, and how many times it has been measured. Nothing is re-run and nothing is spent.

List every indicator a specification may refer to, with what it reads and the window lengths it accepts. This is the only vocabulary that exists: a specification naming anything else is refused before any code is generated, so read this before writing rules.

Report whether this server can install StockSharp products at all: whether the installer console is where it expects it, whether this machine has a StockSharp account signed in, which product ids the operator allowed, and where products would be installed. Call this before the other product tools - installing is off by default and most machines do not have the installer on them, so being refused mid-plan is a worse way to find that out. This touches no network and installs nothing; it does briefly run the installer to read this machine's hardware id, which is the one thing it can answer offline.

Read what a run measured: the result before and after costs, the drawdown, the trade population, and how much of the result rests on a single trade. Read the net side, which is the one an account would have seen, and read the concentration beside it, because a result carried by one trade is one observation rather than an edge.

Read one project: its name, status, dataset if any, and how much of its research budget is left. The budget is a server-side ceiling, so check it before planning a long search.

Read the individual trades of a run, in the order they closed: when each opened and closed, at what price, and what it made after costs. Use this when a metric is surprising — a high win rate with a poor result, or a profit that arrived in one week — because the trade list says which it is and a summary cannot.

Import the bundled dataset for this project, so the whole pipeline can run without a broker account. These bars are generated, not observed: use them to prove the machinery works, never to judge whether a strategy is any good. Every report over them says so.

Download real market history for one or more symbols into the market-data storage every project shares, and make that range this project's dataset. The bars come from the bound broker, or from the StockSharp storage server the operator named when there is one. Ask for enough days that the development slice - the first three fifths - holds at least a few thousand bars, or the measurements below it rest on too little.

Download and install one StockSharp product on this machine. Takes the numeric product id list_products reports and nothing else: where it lands is derived from this server's own projects root and is not something a caller chooses. Only the product ids the operator allowed can be installed, and the refusal names the ones that can. Set reinstall true to remove an already installed copy first and put it back - the two behaviours differ enough to be asked about rather than defaulted. This downloads packages and can take many minutes; it does not start the product afterwards.

List the candidates a project has built, oldest first, with where each has reached in its lifecycle. Read this before building another: the project's allowance is finite, and a candidate that has already been measured is a hypothesis that has already been answered.

List the strategies this project has been finished with, oldest first, with what each was measured on and why it was kept. Nothing is re-run and nothing is spent.

Report which broker connectors this server has already downloaded, which one is bound now, where it may download from and which package names it will accept. Touches no network, but it does build one of every connector in the cache to read it, which is why a hosted instance refuses it. A connector is what turns import_history, the instrument lookups and paper trading on; everything else works without one.

Every deployment this project has had, newest first, and every runner on this machine that no row here accounts for. Two things are reported about each: what was recorded, and what was found when the process trading it was looked for. Start here in a new session - a deployment an earlier conversation started is still running, and this is how it is found again. A row recorded as running whose runner is 'gone' belonged to a process that ended: nothing was stopped in an orderly fashion, so read the account for anything it left open and call stop_deployment to end it properly. Reading this list changes nothing.

List the StockSharp products already installed on this machine, with the directory each one is in. Reads the installer's own registry of installations, which covers products this server never installed. Needs the network and a StockSharp account for the same reason list_products does, and reports the same 'unparsed' lines for anything it could not read.

List the StockSharp products the store offers, with the numeric id each one is installed by. Needs the network and a StockSharp account on this machine even though it sounds local: the installer reloads its whole product catalogue from the web on every call. The program behind this has no machine-readable output, so an entry it printed in a shape this server does not recognise comes back in 'unparsed' as raw text rather than being dropped.

List the research projects on this server, most recently changed first, a page at a time.

List what this project has already run, oldest first. Read it before running anything: the allowance is finite, and a slice already measured under the same scenario will answer with the same numbers. A project may hold hundreds of runs, so this answers a page at a time and says how to ask for the next.

List the specifications recorded for a project, oldest first, so the history of what was tried can be read back. Answers a page at a time and says how to ask for the next.

List the option contracts the broker offers on an instrument, optionally within a window of expiries. An option is traded here by its full contract code, which carries the underlying, the expiry, the right and the strike in nineteen characters that have to be exactly right - so this is where one comes from. Everything else in this product treats such a code like any other symbol: the same specification, the same runs, the same measurements, with the hundred shares a contract carries taken into account when the result is worked out.

Find instruments the broker offers, by part of a code or a name. Use it before import_history rather than guessing a symbol: a code the account cannot hold is discovered here in one call, or at the end of a download that returns nothing. It reads the broker and imports nothing.

Measure a candidate ONCE against the part of the history that has been closed all along, and report what it did there beside what it did on the data it was allowed to see. Use it on the candidate you would actually trade and on nothing else: a candidate cannot be measured here twice, and once a second candidate of the same project has been, neither result is independent of the slice any more — whoever chose the second one knew how the first went. Everything the earlier numbers are worth rests on this slice not having been touched, so spend it last. What gets measured is not yours to choose here: the instrument and the parameters come from the run validation was taken on, because measuring some other setting spends the only slice that could have said anything about the one you validated. It also asks the closed data the walk-forward question, in consecutive stretches, so that answer too comes from data nobody could have tuned to. That costs five backtests. The result is statistics and nothing else: what the gap between the open and closed numbers means is yours to read.

Record a specification as this project's next revision. It is checked first and refused if it would not survive translation, so an invalid one never becomes part of the history. Specifications are never edited: a change is a new revision, and every candidate points at the exact words it was built from.

Remove one installed StockSharp product from this machine. removeData decides what happens to that product's own application data - the settings, schemas and logs it wrote, which live outside its install directory and are not recoverable once removed. There is no safe default for that, which is why the tool asks rather than choosing. Only the product ids the operator allowed can be removed.

Rename a project. The previous name is kept in the audit trail.

Run a candidate over one part of the project's history and measure what it did. Start on 'development'; 'validation' is where a candidate is checked against data it was not tuned on, so running it repeatedly while still adjusting the rules is how a validation result stops meaning anything. Costs are charged from the first run — a candidate that only works without them is not a candidate. A run that has already been done with the same candidate, data, slice and scenario is returned rather than repeated, and does not spend the allowance again.

Search the numbers this candidate declared and measure the setting that came out best. The ranges come from the specification, not from this call: each number was declared with its bounds and its step, and the search stays inside them. It runs on the development slice only — searching on validation would tune the candidate to the data meant to judge it. Every setting evaluated costs a backtest, so the whole search is charged up front and refused if the project cannot afford it. The search ranks; it does not decide: what it picks is then run and judged like anything else. Look at the spread of the results, not only at the winner — a lone peak surrounded by poor neighbours is a number that fitted this history, not an edge.

Walk this candidate's declared numbers forward over the development slice. The slice is cut into windows that step forward by the tested length: each window searches every setting the specification allows on its first stretch, takes the best, and runs it on the stretch right after, which the choice never saw. So every tested result comes from numbers chosen without it, which is the question run_optimization alone cannot answer. Every window costs a backtest per setting plus one for the test, charged up front and refused if the project cannot afford it. Read the tested results side by side: numbers that hold up window after window are a property of the instrument, numbers that change every window and only win where they were chosen are a fit to the history.

Download a connector, put it into demo mode, apply the credentials this server was started with and the settings you pass, and bind it: from then on import_history, lookup_symbols, lookup_option_contracts, deploy_candidate and get_account_state work. Two settings are reserved by this server rather than passed on - 'board' and 'optionBoard' name the markets a symbol is quoted on. Credentials are never passed here; they are read from a file the server was started with. A connector that cannot be told it is on a paper account is refused. Selecting again loads a second connector and leaves the first one loaded, so choose once per server if you can. A hosted instance refuses this, as it refuses the other two: its connector is chosen when the process starts.

Stop a deployment. Say what to do with any position it is holding: closing one places a trade on your behalf, and leaving one open keeps money at risk with nothing watching it. There is no safe default, which is why this asks. A stop is a decision about the position; a process that died is not, and nothing here turns one into the other - a deployment whose runner is gone is recorded as interrupted with whatever it last wrote down, and its position is left exactly as it stood. A runner whose process is alive and not answering is refused: nothing is recorded, because recording it as stopped would say something untrue about an open position. This cannot kill a process; that is a person's job at a terminal.

Update one installed StockSharp product to the newest version the store offers. Note the side effect before calling it: the installer closes a running copy of the product first, so updating something a person has open in front of them will shut it. Set backupSettings true to copy that product's settings aside before the update. Only the product ids the operator allowed can be updated.

Check a specification and report everything wrong with it at once, each with the place in the document, what is wrong and what would fix it. Nothing is recorded, so use this freely while drafting. Every problem it reports would otherwise become a refusal from propose_spec.