Skip to content

Order-shapes receipt: lowered order-call facts for closing-time order processing - #178

Merged
luisleo526 merged 8 commits into
mainfrom
lv/fu20-pooc-admission
Oct 6, 2026
Merged

luisleo526 merged 8 commits into
mainfrom
lv/fu20-pooc-admission

Conversation

@luisleo526

Copy link
Copy Markdown
Contributor

Adds a compiled order-shapes receipt to every generated strategy. The live runner can then decide, from facts, which closing-time order processing (process_orders_on_close) shapes it can run identically in a confirmed-bar stream. Codegen only records facts; the runner owns admission. The generated trading code is unchanged.

What is emitted

  • A new export pair, emitted for every strategy:
    • strategy_order_shapes_api_version() returns 1;
    • strategy_order_shapes_receipt(...) uses the same buffer protocol as the checked-settings receipt and returns canonical JSON with sorted keys and no NaN.
  • One descriptor per emitted strategy.* order call site, recorded at its lowering branch:
    • parameter classes: one field per lowered parameter, each absent, literal, never_na or maybe_na. "Absent" is defined per parameter by its lowered default (qty_type=-1, oca_type=0, oca_name="", exit qty_percent=100, strategy.order qty=0). A literal na and an omitted leg classify identically.
    • ID forms: literal, empty or dynamic.
    • Placement: direction, call context (straight, or repeatable inside loops and functions) and statement order relative to the bound entry.
  • Relations: exit targets, entry-ID counts and sharing, including strategy.order IDs. No literal ID strings are emitted.
  • host_reads: the host members the generated body reads, recorded at emission through every buffer mutator. A whole-TU token scan is only a cross-check.
  • A settings echo of the emitted constructor statements.
  • unmodeled: every strategy.* call that did not go through a modeled lowering, such as strategy.risk.*.

The existing capability and confirmed-bar receipts are byte-identical, including the frozen orders field.

Evidence

  • Full suite (38 audited batches, -n 16): 5,850 passed, 39 skipped, 1 failed. The failure is missing set_recorded_series in a host-member table; it fails identically on base c1df8a6 and is unrelated.
  • Targeted tests after the review fixes: 245/245.
  • Corpus compile: 314/314.
  • Trading-output identity: 325/325 corpus sources and all codegen fixtures are byte-identical to base once the two new exports are stripped. A fresh-process control is included, because warm-process nondeterminism also exists on the base.
  • host_reads superset check: 0 missing members across 2,644 generated TUs.
  • POOC receipts: the five corpus POOC sources' receipts were verified through the real export (version, sizing query, exact buffer, canonical JSON).
  • Independent review: merge with fixes, no P0 or P1. Both P2s are fixed in 45ff165 and a62253a.

The runner-side policy that reads this receipt ships in a separate engine change.

🤖 Generated with Claude Code

@luisleo526
luisleo526 force-pushed the lv/fu20-pooc-admission branch from a62253a to d04248d Compare October 5, 2026 23:54
@luisleo526
luisleo526 merged commit d1220bb into main Oct 6, 2026
8 checks passed
@luisleo526
luisleo526 deleted the lv/fu20-pooc-admission branch October 6, 2026 01:24
luisleo526 added a commit that referenced this pull request Oct 6, 2026
* docs: changelog and version scoping for 1.3.0

1.3.0 pairs only with engine v1.3.0. The changelog section takes in the
Unreleased note and covers #173, #178, #179, #177, #174 and #175: the
confirmed-bar receipt and what engine v1.3.0's live runner does with it,
the capability receipt's request entries now read from the lowering, the
order-shapes receipt, which no engine reads yet, the checked settings fix
for string dropdowns with built-in constants (now supported=false where
1.2.0 wrote an integer code or published the input as supported), the
PineForge Source License 1.2, and the pairing and migration steps. The
Python and JSON contract is unchanged; the engine's report harness is the
same file as in v1.2.0, so no report key changes.

The README, AGENTS.md / CLAUDE.md, CONTRIBUTING.md, LEGAL.md,
docs/PUBLIC_CONTRACT.md, docs/pine-cap-activation.md and npm/README.md
name 1.3.0 where they named 1.2.0 as the current release or pair, the
pairing table gets a 1.3.0 row, the "unreleased (after 1.2.0)" markers
name 1.3.0, and the license badge reads 1.2. The release scoreboard
sentence and the pf markers are left to the release lane.

Measured for 1.3.0: the engine's 325 corpus sources and the 277 gate
fixtures, each in a fresh process, transpile to 1.2.0's C++ byte for byte
once the confirmed-bar and order-shapes functions are removed (13
refusals, same messages), with transpile_full results and transpile_json
envelopes without cpp equal to 1.2.0's, each in under 0.1 s on CPython
3.14.6 on an Apple M4 Max. The tutorial run of the quick-start C++
against engine main 7a1f01c0 (Linux x86_64, GCC 13) prints 9 trades and
+738.20, and 13 trades with the old sizing declared, as 1.2.0 with engine
v1.2.0 does.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* docs: release 1.3.0's grades in the README and the changelog, from the facts tokens

The README's release sentence moves to the releases[1.3.0] tokens and its
main-scoreboard lines re-render, and the 1.3.0 changelog says which registry
baseline grades the release and why that baseline is the release's code,
all rendered from pineforge-release facts/facts.json at ff21de0 (#32).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant