Build an independent dynasty, career or scoreboard app

The external app owns the season/career database and consumes the same documented interfaces as every other client. No first-party runner is required. Native addresses and Windows details stay inside the adapter; HTTP/OpenAPI and SDKs are the consumer contract.

Session lifecycle

1. Export a ROS plus its exact hash-bound .openhoops.json companion, or a complete roster archive. Never attach metadata from another binary revision.
2. Resolve supported team/settings/rules/identity choices before launch. Use application-stable team/player/match IDs; record the chosen physical row mapping when required.
3. Launch one private broker for one owned match session, supplying the game executable, immutable match-request file, session state directory and loopback port.
4. Discover its private token file, verify health/compatibility and observe preparation. The loading cover remains until native startup configuration/metadata/assets have committed.
5. Subscribe/read snapshots and events. Treat validity, epoch, sequence and freshness as part of each value. Physical ball ownership is not automatically legal possession or live-ball state.
6. Acquire the exclusive control lease before mutation. Save the complete command body and ID durably before submission. Check the durable receipt after a lost response; do not invent a new command ID to retry an uncertain action.
7. Reconcile the immutable final result with your own match identity. Commit it durably before ACK, and handle duplicate delivery idempotently.
8. Explicitly close the matching finished/cancelled session and verify owned process shutdown.

Example shape, from the extracted runtime root:

.\OpenHoops.cmd api --launch-game "C:\Games\OpenHoops\nba2k14.exe" --match-request "C:\MyDynasty\requests\game-001.json" --state "C:\MyDynasty\sessions\game-001" --port 27614

Use the complete integration guide, request construction, HTTP reference, metadata contract, rules and results/recovery. Those October guides describe the API55 baseline. The final bundle's API README/OpenAPI and CROWD.html add the dev58 contracts; its OpenAPI is authoritative for dev58 schema changes.

Python and TypeScript clients are included, with runnable dynasty-session and result-consumer examples, generated types and strict runtime guards. Other languages can use the HTTP contract directly. The native C rule-extension SDK is experimental and version/capability bounded. First-party consumers must not become special authoritative rule paths.

The developer archive preserves all current API source/tests/examples/schema, TypeScript source/dist/tests, native C headers, roster writer and presentation core. Its source map and exact-checkpoint manifests separate current unqualified edits from accepted frozen builds.