Build an independent OverPy-compatible engine with canonical Workshop integration

[Teakowa]

Goal

Build opy-rs into an independent, corpus-backed implementation of OverPy source-language semantics and connect it to canonical Workshop semantics without duplicating Workshop ownership.

Current status

The independent source-language implementation is established. Compiler convergence is the active product-enabling work.

Completed integration slices:

• Establish the versioned OPY-to-Workshop integration boundary #35 — versioned OPY→Workshop integration boundary
• Lower OPY program structure into canonical Workshop WIR #40 — program structure
• [integration] Rebaseline opy-compiler on current workshop-rs release #52 — Workshop dependency rebaseline
• Lower OPY assignment and expression primitives into canonical Workshop WIR #46 — assignment/expression primitives
• Lower OPY control flow into canonical Workshop WIR with oracle evidence #47 — control flow, merged via PR feat(opy-compiler): lower control flow into canonical WIR #61 against workshop-rs 0.1.11
• Lower OPY statements and expressions into canonical Workshop WIR #41 — statements/expressions acceptance gate

Active compiler convergence:

• Integrate OPY lowering and end-to-end compatibility with workshop-rs #8 — OPY→Workshop integration
  • Lower the declared OPY semantic surface into canonical Workshop WIR #36 — semantic lowering
    • Lower OPY statements and expressions into canonical Workshop WIR #41 — statements/expressions
    • Close catalog-backed OPY lowering and corpus evidence #42 — catalog-backed builtin/member/enum lowering and corpus closure (active edge)
  • Integrate Workshop-dependent settings, locale, directive, and hook behavior #37 — settings/locale/backend-directive/post-hook integration
  • Expose OPY compilation and close the end-to-end compatibility gate #38 — public compile API/CLI and end-to-end corpus gate

Current primary order:

#42 → close #36 → #37 → #38 → close #8

The durable data flow is:

OPY source -> parse/preprocess -> semantic resolution/HIR -> OPY compiler -> workshop-rs WIR -> Workshop text

Separate/non-gating work

• [design] Re-evaluate Workshop → OPY reconstruction scope after workshop-rs rebaseline #53 — scoped Workshop→OPY reconstruction design lane.
• Audit the complete OverPy surface and establish the authoritative support matrix #57 — externally audited OverPy support contract; useful for truthfulness but not a substitute for compiler execution evidence.
• Track OverPy null-initializer default semantics #58/Add bounded OverPy increment and decrement assignment support #59/Define bounded multidimensional indexed-assignment lowering #60/Support player-variable range-for binders #65 and wrightkit/workshop-rs#95 — bounded follow-ups discovered by compiler work; keep off the critical path unless real-project evidence proves otherwise.
• Retire frontend as an architecture boundary and consolidate the OverPy language implementation #62 — retire frontend terminology/crate identity. Coordinate with compiler work, but do not let architecture cleanup outrank semantic blockers.

Ownership

• opy-rs owns OverPy syntax, preprocessing/macros, semantic resolution, HIR, diagnostics/provenance, tooling APIs, compiler behavior, and any scoped reconstruction contract.
• workshop-rs owns canonical Workshop semantics, catalog, WIR, settings/localization, validation, emission, and target-owned operation contracts.
• Do not copy canonical Workshop data or semantics into opy-rs.

Acceptance criteria

• The OPY language/tooling implementation remains independently useful and evidence-backed.
• Supported OPY programs compile through canonical WIR and Workshop emission with structured diagnostics and preserved provenance.
• Representative real-world/corpus cases justify user-facing compilation support; issue/test counts alone are insufficient.
• No authoritative Workshop ownership is duplicated in opy-rs.
• Reconstruction, if pursued, uses a separately reviewed semantic-equivalence/useful-source contract rather than promising literal recovery.

[Teakowa]

Status — Workshop-independent roadmap advanced

Draft PRs (all CI green on their head SHAs):

• PR feat(compatibility): OverPy feature inventory and corpus (#2) #10 (feat/evidence-base) → Establish the OverPy feature inventory and compatibility corpus #2: pinned OverPy 9.7.10 @ 889d974, tiered baseline, machine-readable support matrix, 26-fixture provenance corpus, oracle harness (26/26 snapshots PASS).
• PR feat(frontend): standalone OPY frontend extraction #9 (feat/frontend-bootstrap) → Bootstrap the OPY source frontend and syntax model #3/Implement OPY semantic resolution and language model #4/Implement OPY preprocessing, directives, and macro expansion #5: standalone opy-frontend crate (lexer/CST/parser/diag/preprocess/settings/manifest/lower + Opy HIR), zero wright/workshop-rs deps; trivia-retention policy documented.
• PR feat(runtime): JavaScript macro and hook runtime (#6) #11 (feat/js-macro-runtime) → Implement JavaScript macro and hook runtime compatibility #6: QuickJS-NG macro/hook runtime with upstream ABI, resource limits, 33 fixtures; CI OOM defect fixed.
• PR feat(tooling): OPY check/inspect CLI and library APIs (#7) #12 (feat/tooling) → Reach Workshop-independent OPY frontend completeness and expose tooling APIs #7 part A: check/inspect tooling API, semantic queries, support-metadata accessor, opy-cli (check/inspect/support/version), diagnostics contract.
• PR feat(completeness): differential parity suite and JS macro integration (#7) #13 (feat/frontend-completeness) → Reach Workshop-independent OPY frontend completeness and expose tooling APIs #7 part B: differential suite over all 26 corpus fixtures (14 resolve, 12 expected-diagnostic, 7 documented reference gaps), script/postCompileHook frontend integration with runtime execution, support matrix advanced (frontend-supported 14, semantic-supported 5).

Remaining work is classified, none unclassified:

• lowering-dependent (all Integrate OPY lowering and end-to-end compatibility with workshop-rs #8-linked): Workshop emission/lowering, settings/locale emission, post-compile hook wiring to emitted content, decompilation.
• Documented reference gaps (issue Reach Workshop-independent OPY frontend completeness and expose tooling APIs #7 evidence): santa do-loops, cronch ++, crosshair b-strings, broken-weapons float ranges, client-to-server chained ternary, inputhud multiline parens, parabola Team.2 — inventory-classified, no blocker.
• Planned matrix rows: full builtin/enum/receiver surfaces beyond the manifest-declared evidence, advanced directives (#!mainFile etc.), translations, optimization controls — evidence-prioritized.

#8 remains blocked on workshop-rs public contracts as designed.

[Teakowa]

Merge-blocker fix batch complete (QA READY)

All five PRs reviewed by QA (independent verification, fresh checkouts, full gates): #9/#10/#12/#13 READY, #11 merged by maintainer. No unresolved blockers in ownership, semantics, licensing/provenance, or branch history.

Final stacking: main ← #9 (frontend) · main ← #10 (evidence) · feat/stack-base (bc1d9e8) ← #12 (tooling) · feat/stack-base ← #13 (completeness). Merge order: #9 → #10 → #12 → #13 (if #12 lands first, rebase #13 onto the new base — QA noted the standard stacked-PR sequencing).