[M13] Source-language interoperability and OSTW compatibility

[Teakowa]

Goal

Extend Wright's tooling-first semantic platform to first-class OSTW compatibility and source-language interoperability, with Workshop remaining the canonical hub.

M13 should make supported OPY, OSTW, and raw Workshop projects independently processable by one Wright toolchain without requiring upstream language runtimes for supported workflows.

Context

Wright already owns native Workshop semantics/I/O and a corpus-driven OPY semantic frontend. The architecture rebaseline in #88 defines compiler-grade semantic frontends as enabling infrastructure for tooling rather than as the product identity.

The next source-language expansion should therefore be evidence-driven: first establish the actual OSTW semantic/reference boundary and conversion requirements, then implement only the minimum frontend/emitter contracts justified by real projects and tooling use cases.

Depends on #88. Detailed decomposition should wait until M12 and an OSTW reference/corpus investigation provide current evidence.

Scope

• Investigate the current OSTW compiler/language-service implementation, observable language semantics, licensing/provenance constraints, and viable reference/oracle machinery.
• Establish an OSTW real-world corpus and compatibility/support matrix before declaring implementation breadth.
• Implement a Wright-owned OSTW semantic frontend sufficient for the declared corpus and standalone check/lint/analyze/inspect/compile workflows.
• Lower supported OSTW semantics through Wright-owned semantic representations/WIR and emit valid Workshop.
• Add Workshop -> OPY source reconstruction for the declared Workshop surface.
• Add Workshop -> OSTW source reconstruction for the declared Workshop surface.
• Define reconstruction quality criteria that preserve semantics and useful structure without promising original formatting/comments or source-level abstractions that cannot be recovered from raw Workshop.
• Preserve source provenance and structured diagnostics through the same compiler/session/tooling contracts used by existing inputs.
• Keep upstream OverPy/OSTW compilers and language services as compatibility/reference infrastructure rather than runtime dependencies.
• Evaluate direct OPY <-> OSTW conversion only after both frontends and Workshop-backed emitters are proven; it is optional and not an M13 release gate.

Non-goals

• Wright-only OPY or OSTW syntax/extensions.
• Reimplementing upstream internal compiler architecture for implementation parity.
• Requiring direct OPY <-> OSTW conversion.
• Perfect recovery of original comments, formatting, macro structure, or lost high-level abstractions from raw Workshop.
• Full-source regeneration as the default agent/refactoring edit model.
• Expanding language surface without corpus or concrete tooling evidence.
• Coupling Wright core to upstream LSP protocol types or requiring an upstream language server at runtime.

Deliverables

• OSTW reference/corpus/compatibility investigation with a bounded support matrix.
• Wright-owned OSTW semantic frontend for the accepted corpus.
• Standalone OSTW -> Workshop pipeline integrated with existing tooling.
• Workshop -> OPY and Workshop -> OSTW source emit/reconstruction paths for the declared surface.
• Cross-format semantic validation proving Workshop remains the interoperability boundary.
• Updated user/tooling documentation for supported directions and known reconstruction limits.

Acceptance criteria

• Supported OSTW projects can be parsed, semantically understood, analyzed, and compiled by Wright without a .NET/upstream OSTW runtime in the supported production path.
• The OSTW compatibility claim is corpus-defined and compares observable semantics rather than internal/compiler-text identity.
• Raw supported Workshop can be converted to valid OPY and valid OSTW source that recompiles to semantically equivalent Workshop under the declared validation boundary.
• OPY -> Workshop and OSTW -> Workshop converge on Wright-owned canonical Workshop semantics/WIR rather than separate analyzer paths.
• Existing check/lint/analyze/inspect/agent APIs work across the newly supported inputs without transport- or language-specific semantic forks.
• Upstream language implementations remain references/oracles, not mandatory supported-workflow dependencies.
• Direct OPY <-> OSTW conversion is either demonstrated as a safe composition over proven boundaries or explicitly deferred; it is never required merely for matrix symmetry.

Planning notes

Keep this milestone intentionally coarse. Do not create parser/type-system/emitter sub-issues until an Architect/QA investigation has inspected the current OSTW implementation and a PM-approved corpus demonstrates which constructs matter. M12 tooling evidence may also change which source-level semantics provide the highest product value.

[Teakowa]

The architecture rebaseline in #88 (commit c96fd08) is now recorded. ADR-0008 decision 2 confirms OSTW as a future first-class semantic frontend introduced only through an evidence-backed milestone, consistent with M13's scope. The conversion matrix (decision 6) records OPY→Workshop, OSTW→Workshop, Workshop→OPY, Workshop→OSTW as required long-term capabilities; direct OPY↔OSTW is optional and must not drive the core architecture prematurely.

[Teakowa]

PM priority note (post-M12 reassessment, see #100)

Per the post-M12 reassessment recorded on #100: #106 is a prerequisite for decomposing/implementing this milestone. The read-only OSTW reference/corpus investigation may begin in parallel once #106's upstream-reference document and machine-readable support contract exist (the same document is extended for OSTW per #106); #90 implementation/decomposition is gated on that investigation plus the #106 baseline. Direct OPY↔OSTW conversion remains a non-goal.

[Teakowa]

PM reassessment after accepted #115 baseline

The evidence gate for M13 implementation is now satisfied. #115's stabilized oracle (cba9faa) materially changes the first support boundary:

• protect-ban at f8c2353e… is the first accepted corpus project and produces a stable 79-element Workshop artifact under pinned OSTW v3.4.0.
• MOBAwatch at b9b1ac3b… is rejected by the pinned canonical reference/runtime. It remains structural/corpus evidence, but it is not a compile-success acceptance target.
• Therefore classes/advanced semantics observed mainly through MOBAwatch remain evidence-prioritized and are not part of the first frontend milestone by symmetry.

Approved first implementation decomposition

1. [M13] Establish native OSTW project and syntax frontend foundation #117 — native wright-ostw project/syntax frontend foundation and SourceKind/session integration.
2. [M13] Resolve and lower the accepted protect-ban OSTW semantic slice into HIR #118 — semantic resolution + HIR lowering for the accepted protect-ban surface.
3. After [M13] Resolve and lower the accepted protect-ban OSTW semantic slice into HIR #118 stabilizes, [M13] Compile the accepted OSTW corpus slice to Workshop with reference differential validation #119 and [M13] Integrate the accepted OSTW semantic surface with Wright tooling services #120 may proceed in parallel:
   • [M13] Compile the accepted OSTW corpus slice to Workshop with reference differential validation #119 — OSTW -> Workshop forward compilation with pinned-reference differential validation.
   • [M13] Integrate the accepted OSTW semantic surface with Wright tooling services #120 — tooling-first integration (check/lint/analyze/inspect/agent/shared language services).

Deliberately not decomposed yet

Workshop -> OSTW reconstruction and Workshop -> OPY reconstruction remain M13 deliverables, but PM will decompose those only after #119 proves the forward OSTW semantic boundary and its canonical HIR/WIR mapping. This avoids designing source emitters against an unproven frontend contract.

Direct OPY <-> OSTW remains explicitly deferred/non-required. #96 remains deferred; the current OSTW work should consume existing Wright-owned Workshop catalog/signature semantics rather than trigger a runtime content-registry redesign.

The unrelated #116 Rust-1.85 clippy regression is not part of the OSTW semantic scope, but implementation agents should not misattribute that existing CI failure to M13 changes.