DresdenGman/EPSILON-trading-simulator

The status page correctly discloses that historical universes are user-selected and that EPSILON does not yet provide a point-in-time constituent database. Survivorship bias therefore remains possible. A public design discussion would make this limitation actionable and give quantitative-finance contributors a concrete research problem to help solve. Suggested scope: define how universe membership is associated with an effective date; cover delistings, symbol changes, mergers, suspensions, and missing observations; add universe provenance to exported evidence artifacts; define behavior when historical membership cannot be established; create a small public fixture with a known membership change; add a test showing that a security unavailable at the decision date is not silently included; keep present-day ticker lists explicitly labeled when they are used. A design document and fixture are sufficient for the first contribution; a complete commercial constituent database is not require

The instrument rate limiter currently stores counters in an in-memory map attached to globalThis and identifies a client using cf-connecting-ip, falling back to the shared key anonymous. That is useful as a local guard, but edge instances do not necessarily share memory. Counters can therefore differ between instances or reset with the runtime. In environments without the Cloudflare header, unrelated users may also share the same bucket. Suggested scope: document the threat and abuse model for the historical-data and impact endpoints; define a privacy-preserving client-key policy for production and local development; use a shared or platform-backed limiter where enforcement must be consistent; specify fail-open or fail-closed behavior when the backing store is unavailable; add tests for missing headers, window rollover, concurrent requests, and multiple runtime instances; continue avoiding storage of unnecessary personal data. This issue is about predictable resource protection; it i

The repository currently describes two different canonical product paths. The root README presents instrument/ and the public /lab workflow as the current product, while docs/PRODUCT_ARCHITECTURE.md describes /landing → /dashboard → /dashboard/backtest and docs/REPRODUCIBILITY.md still asks readers to run website/ and open /demo. This makes it difficult for a new contributor to know which workflow should be reproduced or changed. Suggested scope: identify the current canonical application and reproduction path in one source of truth; mark historical product documents clearly as legacy, or update them to the current instrument; add a short documentation index that separates current and historical material; verify all published commands from a clean clone; preserve the historical record without presenting retired routes as the active workflow. Done when a first-time contributor can determine the supported runtime, route, and verification command without comparing several conflictin