Core Laravel Package

Getting Started

Baseline assumptions. This is a Symfony bundle (PHP 8.1+) with 14 stars and zero dependents, so treat the README as aspirational and the source as the truth. Do not expect a Flex recipe, a docs site, or Stack Overflow answers.

Install and register manually.

composer require stochastix/core

No Flex recipe almost certainly means you add the bundle yourself in config/bundles.php:

Stochastix\Core\StochastixCoreBundle::class => ['all' => true],

Then verify the real bundle class name rather than trusting the above — composer show stochastix/core and grep -r "class .*Bundle" vendor/stochastix/core/src.

Where to look first, in this order.

1. vendor/stochastix/core/src/ — directory layout tells you the architecture faster than the README. Look for Strategy, Backtest/Runner, MarketData, Indicator, Console/Command.
2. DependencyInjection/Configuration.php — this is the authoritative config schema. Dump it:

   bin/console config:dump-reference stochastix_core   # or whatever the extension alias is
   

3. bin/console list — console commands are the package's real entry points. Look for an import/fetch command and a run/backtest command.
4. composer.json inside the package — check the Symfony version constraint before you plan an upgrade.

First use case: one instrument, daily bars, one toy strategy.

Get a reproducible backtest end-to-end before touching anything clever:

bin/console stochastix:data:import --symbol=BTCUSDT --timeframe=1d   # name will differ; use `list`
bin/console stochastix:backtest:run --strategy=sma_cross --from=2022-01-01 --to=2024-01-01 -vvv

Use SQLite for local development so you can reset state instantly and inspect the candle table by hand. Do not wire this to a live exchange adapter on day one.

Implementation Patterns

Strategy as a Symfony service, not a config string. The most common failure with small bundles is assuming strategies are discovered by name. They are usually just services resolved from the container, so define them in config/services.yaml and let autowiring inject repositories, loggers, and package services:

App\Strategy\SmaCrossStrategy:
    tags: ['stochastix.strategy']

Check the package for a compiler pass or AutoconfigureTag before inventing a tag name.

Separate ingestion from execution. Import once, backtest many times. Store a run record (strategy, params, data_range, config_hash) so a result is reproducible and comparable — the package will rarely do this for you.

Parameter sweeps as a driver script, not a feature. With no ecosystem around it, write your own matrix runner as a console command or a thin script that loops over config objects and persists each result. Keep results in your app's tables, not the package's, so a vendor update can't destroy your history.

Indicators as pure functions. Even if the package ships helpers, write your own as array $closes -> array $values functions. They are trivially unit-testable, survive vendor breakage, and let you verify the package's math against a known-good implementation (e.g. a spreadsheet).

Deterministic test fixtures. Build a 30-bar handwritten candle series with a known SMA cross, assert on final equity and trade count. This is the only cheap way to gain confidence in a 14-star dependency — and it doubles as upgrade insurance: if a version bump changes results, your fixture catches it.

Keep the runner behind an interface you own. Define App\Backtest\RunnerInterface, implement it with a thin adapter over the package. Strategies and controllers depend on your interface, so swapping the engine later is a one-file change.

Gotchas and Tips

Pin hard and commit the lock file. Bus factor of one, zero dependents, no release cadence guarantees. Use an exact version ("stochastix/core": "1.2.3"), commit composer.lock, and be prepared to path-fork the package into your repo if it stalls. Budget a day for this; it is not pessimism, it is the tax on low-adoption dependencies.

Look-ahead bias is the default failure mode. The single most valuable code review on any backtester is verifying the strategy receives only bars[0..i]. Grep the runner for array_slice, foreach, and any place it passes the full dataset. Test with a strategy that buys on a bar and asserts the price it got was the next bar's open.

Check the fill model before trusting a single number. Commission, slippage, and whether fills happen at bar close, next open, or intrabar high/low are usually configurable and usually default to optimistic-zero. Set explicit fees and slippage, then run the same strategy with fees doubled and confirm the P&L moves. If it doesn't, the fees aren't wired up.

Timezone and bar-boundary semantics. Store UTC everywhere. Be explicit whether a daily bar's timestamp is the open or the close — mixing these silently shifts every signal by one day and makes results look great for the wrong reason.

Doctrine entities may ship without migrations. Run bin/console doctrine:schema:validate and generate your own migration rather than relying on schema:update. Own the schema so an upgrade can't silently alter or drop your candle history.

Performance: large bar sets in PHP are a memory problem. Index (symbol, timeframe, open_time), read with generators/DQL iterate() if the package supports it, and chunk long ranges by month. If the runner materializes everything into arrays, keep ranges small and run sweeps as separate processes.

Determinism in debugging. If the runner calls new \DateTime() anywhere, results aren't reproducible across runs. Grep for it; prefer explicit from/to arguments. Log every simulated order on a dedicated channel at -vvv — you will need it.

Extension points worth knowing. Strategies, indicator calculators, commission/fill models, and result formatters are the four seams most backtesters expose. Map which of these are interfaces versus final classes before you design around them; if they're final, fork.

Treat output as research, not trading. No live-trading claims should be made without paper-trade validation over a meaningful period. Keep the backtester in the research pipeline, out of the order path.