Would a small matching-semantics conformance adapter be useful? #43

Hi @chronoxor,

I maintain Tracebook, an MIT-licensed matching-engine conformance and failure-reduction toolkit. Before writing another downstream adapter, I wanted to ask whether this would be useful to CppTrader and whether the proposed mapping reflects the engine's intended public semantics.

This is not a benchmark proposal, a compatibility claim, or a request to add Python to CppTrader's core. The candidate adapter would be a small optional executable speaking newline-delimited JSON over stdin/stdout. Tracebook runs out of process, compares each lifecycle result and observable book state with its reference model, and minimizes a divergence into a deterministic JSONL regression trace.

CppTrader looks like a strong candidate because its public API already exposes the relevant lifecycle:

• AddOrder, ReduceOrder, ReplaceOrder, and DeleteOrder
• limit, market, IOC, and FOK orders
• execution callbacks through MarketHandler
• traversable bid/ask levels and resting queues

I would start with Tracebook's documented fifo-limit-v1 capability profile rather than imply support for semantics we have not validated. An optional CI check could then:

1. build the existing C++ library plus a small adapter example;
2. pip install tracebook-sim==0.4.1;
3. replay a fixed protocol trace and run a small seeded campaign;
4. emit JSON/JUnit results and retain any minimized JSONL failure as a regression case.

Two mapping questions are worth resolving before code:

1. ReplaceOrder accepts a new native order ID, while Tracebook keeps the submitted/source ID stable across replacement. Is an external-ID to current-native-ID map faithful to intended CppTrader usage?
2. onExecuteOrder appears to fire once for each participating order. Is callback order part of the public contract and therefore safe for pairing into one maker/taker fill, or is there a better public event surface for reconstructing a trade?

Would you be willing to review that protocol boundary and point out where it is awkward or semantically wrong? If the experiment seems useful, would you prefer an optional example/CI draft PR here, or a downstream adapter maintained in Tracebook? I will not open a code PR without your consent.

Relevant material:

• Tracebook 0.4.1 release
• Conformance protocol and capability profiles
• Copy-paste public-package CI example
• Five-event minimized Rust failure demo
• Prior external semantic review with orderbook-rs

The adapter process would only be a correctness boundary; its transport overhead would not be presented as engine performance.

Thanks for considering it.