Complete OverPy source-language compatibility within 10 implementation PRs

[e54-bot]

Goal

Complete the declared OverPy source-language compatibility target in at most 10 non-release implementation PRs, using category-level capability work rather than one-gap-per-issue execution.

Compatibility target

For this program, source-language compatibility means that the pinned OverPy surface can be:

source -> lex/parse -> preprocess/macros/project composition -> semantic HIR -> builtin/member/enum resolution -> canonical WIR lowering

with structured diagnostics and preserved provenance.

Compatibility is based on observable source/compiler semantics, not upstream implementation architecture or compiler-output identity.

Execution model

Corpus and differential failures are discovery/verification evidence, not roadmap units. A newly exposed name, directive, parser form, or lowering residual must be assigned to its owning category instead of becoming a standalone implementation issue unless it proves a genuinely independent architecture/public-contract decision.

The execution workstreams are:

1. Complete the OverPy lexical and grammar surface #141 — complete the OverPy lexical and grammar surface.
2. Complete OverPy preprocessing, macros, directives, and project composition #142 — complete preprocessing, macros, directives, and project composition.
3. Complete the OverPy semantic HIR surface #143 — complete the semantic HIR surface.
4. Complete the OverPy builtin, member, enum, and alias surface #144 — complete the builtin, member, enum, and alias surface.
5. Complete OPY-to-canonical-WIR lowering for the supported source language #145 — complete OPY-to-canonical-WIR lowering for the supported source language.

Each workstream targets one implementation PR and may use at most two when a coherent review boundary requires a split. Across #141-#145, the hard budget is 10 non-release PRs total. Release/release-plz PRs do not count.

Scope

• Audit the pinned OverPy implementation/spec evidence by functional category so compatibility claims are based on a complete declared inventory rather than current corpus visibility.
• Close all in-scope syntax, preprocessing, source semantic, builtin-overlay, and lowering gaps through the owning category.
• Preserve source spans/provenance and recoverable diagnostics required by tooling.
• Re-run category-level conformance plus the full real-project corpus as each capability block closes.
• Keep OPY semantics in opy-rs and canonical Workshop semantics/catalog/WIR/validation/emission in workshop-rs.

Non-goals

• One issue or PR per corpus first failure, builtin name, directive, syntax form, or fixture.
• Wright-side compatibility fallbacks.
• Duplicating canonical Workshop semantics in opy-rs.
• Matching optimizer shape, temporary variables, formatting, or byte/text-identical Workshop output unless an observable semantic contract requires it.
• Workshop -> OPY reconstruction; that remains a separate design lane.
• Retiring the compatibility harness before it stops providing discovery value.

Acceptance criteria

• Complete the OverPy lexical and grammar surface #141-Complete OPY-to-canonical-WIR lowering for the supported source language #145 are complete within the 10 non-release PR budget.
• The declared pinned OverPy feature inventory is auditable by category and no longer depends on real-project first failures to define supported syntax/language surface.
• In-scope valid OverPy source reaches canonical WIR lowering with preserved observable semantics and source provenance, or reports an explicit external owner blocker.
• Invalid/reference-rejected forms produce structured diagnostics without panics or silent acceptance.
• A final full-corpus convergence pass exposes no unowned OPY source-language capability inside the declared compatibility target.
• Remaining differences are explicitly classified as external-owner blockers, accepted non-semantic output differences, incomplete fixture/oracle evidence, or later out-of-scope work.

Relationships

• Parent engine goal: Build an independent OverPy-compatible engine with canonical Workshop integration #1.
• Workshop -> OPY reconstruction: [design] Re-evaluate Workshop → OPY reconstruction scope after workshop-rs rebaseline #53.
• Compatibility-harness retirement planning: Plan the long-term retirement of the compatibility harness #117.
• Narrow residual issues superseded by Complete the OverPy lexical and grammar surface #141-Complete OPY-to-canonical-WIR lowering for the supported source language #145 retain regression/provenance value but are not independent roadmap units.