# External specifications — `ironcondor`
This directory captures **condensed references** to the ecosystem crates
`ironcondor` consumes as dependencies. `ironcondor` is an engine, not a
library-of-formulas: pricing, Greeks, strategies, and exit policies live
upstream in `optionstratlib`; matching lives upstream in
`option_chain_orderbook`; synthetic chains come from
`optionchain_simulator`. Each summary excerpts only the parts this crate
uses ([00-design-bootstrap.md](../00-design-bootstrap.md)).
These are **sibling projects by the same author**, not third-party
venues — but the discipline is the same as pinning an external API: a
summary here means we do not re-read the whole upstream crate to make an
adjacent change, and it captures the surface **at the revision
`ironcondor` depends on**, which can differ from `main`.
Authoritative sources are the upstream repositories; URLs are in each
file. When an upstream crate revises a surface `ironcondor` consumes, the
corresponding file here is updated in the same diff that adopts the new
version.
## Inventory
| [optionstratlib.md](optionstratlib.md) | [OptionStratLib](https://github.com/joaquinbejar/OptionStratLib) | `src/engine/`, `src/data/convert.rs`, `src/analytics/` |
| [option-chain-orderbook.md](option-chain-orderbook.md) | [Option-Chain-OrderBook](https://github.com/joaquinbejar/Option-Chain-OrderBook) | `src/execution/realistic.rs` |
The `optionchain_simulator` REST DTO surface is consumed through the
migrated `ApiClient` and is documented in
[optionstratlib.md §7](optionstratlib.md#7-optionchain-simulator-dtos)
rather than in its own file, because its `method` walk enum mirrors
`optionstratlib`'s `WalkType` and it is reached through the same
data-feed path ([03-data-layer.md](../03-data-layer.md)).
## What goes in each file
- **Crate name and version** the summary reflects.
- **Module map** — the upstream modules `ironcondor` touches.
- **Exact type and function names** — constructors, traits, enums, and
their signatures, so a caller does not guess.
- **The consumed surface only** — not the crate's full API.
- **The conversion rule** at the boundary (`Positive`/`Decimal` ↔
integer cents; DTO f64 ↔ typed chain).
- **What `ironcondor` consumes vs. what it must build new** on top —
the audit that keeps "engine, not library-of-formulas" honest.
- **Known oddities** captured during integration (latent bugs,
surprising defaults, trait-bound gotchas).
- **Revision date** the summary reflects.
## How to update a spec
1. Read the upstream crate at the URL listed in the file (the source,
not just the docs — these crates are pre-1.0 and move).
2. Diff the consumed surface against the in-tree summary.
3. Update the summary; bump the `Last edit` and `Source revision`
fields at the top.
4. Update the affected design doc if the change touches a boundary —
[03-data-layer.md](../03-data-layer.md) for the chain/DTO surface,
[04-execution-models.md](../04-execution-models.md) for the matching
surface, [05-analytics-and-reporting.md](../05-analytics-and-reporting.md)
for the `backtesting` result types.
5. Capture fixtures under `tests/fixtures/` for any new shape the engine
ingests or emits.
6. Open a PR; the `architect` review checks docs drift.
## What these files are NOT
- They are not the canonical reference — the upstream crates are.
- They are not exhaustive — they cover what `ironcondor` consumes, not
the crate's full surface.
- They are not a tutorial for the upstream crate — its own docs and
examples are.
They exist to remove the round-trip to the upstream source when making
an adjacent change, and to capture the upstream surface **at the version
`ironcondor` depends on**, which is often different from what upstream
`main` looks like today.