[M13] Integrate the accepted OSTW semantic surface with Wright tooling services

[Teakowa]

Parent: #90
Depends on: #118

Goal

Make the accepted native OSTW semantic surface a first-class input to Wright's tooling-first workflows, reusing existing compiler/session/analyzer/language-service contracts rather than introducing an OSTW-specific tool stack.

Context

#118 lowers the first accepted OSTW corpus slice into Wright HIR. Wright's product priority is diagnostics, lint/static analysis, inspect/semantic query, safe source tooling, agent tooling, and CI/embedding; native OSTW support is incomplete if it only compiles.

This issue may proceed in parallel with forward Workshop emission once #118's HIR contract is stable.

Scope

• Route .ostw / OSTW project inputs through existing check, lint, analyze, and inspect command/session paths.
• Ensure shared analyzer findings, symbols, references, CFG/semantic queries, and lint infrastructure operate on OSTW-produced HIR without language-specific semantic forks.
• Preserve root-relative multi-file source paths, spans, and provenance through structured wright-result/v1/tool responses.
• Integrate the accepted OSTW surface with existing agent/tool request APIs so consumers do not need an OSTW-specific transport or upstream language server.
• Add the editor-neutral language-service behaviors that naturally fall out of the accepted HIR boundary (at minimum diagnostics/symbol classification and other already-shared services where supported).
• Add cross-input regression tests proving equivalent shared services work for OPY, Workshop, and the accepted OSTW slice.
• Document any intentionally unsupported source-edit/refactoring operations rather than regenerating whole OSTW source.

Non-goals

• Full upstream OSTW LSP feature parity.
• Binding Wright to upstream LSP protocol types or requiring the pinned language server at runtime.
• Full-source pretty-printing/comment-preserving OSTW regeneration.
• Advanced OSTW classes/generics/lambdas/pattern matching outside the accepted corpus boundary.
• Workshop -> OSTW reconstruction.
• A new plugin/extension ABI.

Acceptance criteria

• check, lint, analyze, and inspect accept the declared OSTW project/source boundary and return the same structured result contracts used by existing inputs.
• Existing analyzer/lint/semantic-query implementations consume OSTW-produced HIR rather than duplicate OSTW-specific analysis logic.
• Multi-file diagnostics/findings identify the correct OSTW source path/span/provenance.
• Agent/tool APIs can inspect the accepted OSTW surface through shared session/services without an upstream runtime dependency.
• Shared language-service capabilities remain frontend-neutral; missing advanced LSP functionality is explicitly documented rather than emulated through upstream runtime calls.
• Cross-language regressions protect shared semantic-service behavior and current CI remains green.

Relationships

• Tooling-first implementation child of [M13] Source-language interoperability and OSTW compatibility #90.
• Depends on [M13] Resolve and lower the accepted protect-ban OSTW semantic slice into HIR #118 semantic HIR lowering.
• May proceed in parallel with [M13] Compile the accepted OSTW corpus slice to Workshop with reference differential validation #119 once the HIR contract is stable.
• Safe source edits/refactoring can be decomposed later from concrete OSTW source-edit evidence; this issue does not require a whole-file emitter.

[Teakowa]

M13 tooling integration evidence (#120)

Implementation of the #120 scope is complete and verified locally (no CI trigger from this environment; CI runs once the changes land). Evidence captured in the implementer scratch dir; the key observations below are reproducible with the committed tests.

Cross-language shared-service regression

crates/wright-driver/tests/service.rs — cross_language_shared_service_behavior_is_frontend_neutral runs the same in-process tool-service assertions (project/rules/symbols/findings/lint) over OPY (synthetic/control-flow), Workshop (synthetic/declarations-rules), and OSTW (protect-ban main.ostw). The shared session lowers the #118 semantic HIR through the shared validate→lower→validate path; no OSTW-specific analyzer/semantic stack exists (the analyzer crate has no OSTW branch).

Local run results

• cargo test --workspace: 506 passed, 0 failed (all crates, incl. the new OSTW driver/service/language regressions and the cross-language test).
• CLI (wright check|lint|analyze|inspect compatibility/ostw/corpus/protect-ban/main.ostw --format json, run twice each, byte-identical): every envelope is wright-result/v1 with populated results — inspect: 40 rules / 128 symbols / 128 references; lint: 5 rule metadata entries + 18 findings; analyze: program summary + 18 findings; check: project summary (entry main.ostw, 8-file closure). The ostw-unsupported workflow fork is gone; the 26 ostw-unsupported + 3 ostw-unknown-value + 3 ostw-missing-import diagnostics are the [M13] Resolve and lower the accepted protect-ban OSTW semantic slice into HIR #118 semantic/project boundary surface (envelope ok=false is expected per the [M13] Integrate the accepted OSTW semantic surface with Wright tooling services #120 plan risk note).
• Malformed OSTW negative case: ostw-parse-error, exit 1 (SOURCE_ERROR), span main.ostw:1:22-23.
• Provenance: missing-import diagnostics resolve to interface/HeroSelect.del; imported-file boundary diagnostics resolve to interface/… project-relative paths.
• Tool service over an OSTW session advertises ostw in capabilities and answers project/rules/symbols/findings/lint.
• Language service: OSTW documents produce source-aware diagnostics (incl. [M13] Resolve and lower the accepted protect-ban OSTW semantic slice into HIR #118 boundary codes) and semantic tokens through the shared index; rename/whole-source regeneration remains documented as unsupported for OSTW.

New/updated tests

• wright-driver/tests/driver.rs: ostw_compile_is_unsupported_but_shared_workflows_run, ostw_analyze_lint_inspect_run_the_shared_semantic_service, ostw_multi_file_provenance_survives_through_shared_workflows, updated ostw_projects_load_through_the_shared_session_path.
• wright-driver/tests/service.rs: ostw_sessions_serve_the_shared_queries_through_the_tool_service, cross_language_shared_service_behavior_is_frontend_neutral.
• wright-language/tests/service.rs: ostw_documents_get_shared_diagnostics_and_symbol_classification.
• Shared lowering (wright-ir): OSTW-only statement/expression forms (foreach/cfor/switch/break/return, user enums/functions/ternaries/casts/constants, indexed assignment) lower through the shared HIR→WIR path; bounded-recursion guard added.

CI note

The shared working tree also carries the in-flight #119 emission work (uncommitted at evidence time); CI verification of #120 runs once the #120 commit lands on the default branch.

[Teakowa]

PM acceptance

Accepted against current main (8964657).

Although the #120 implementation was ultimately committed together with the adjacent #119 work rather than as a separate #120 commit, the resulting repository boundary satisfies this issue:

• OSTW semantic HIR now enters the shared session validate -> lower -> validate path;
• check, lint, analyze, and inspect run over OSTW inputs through the same structured workflow contracts;
• ToolService advertises ostw and serves the shared project/rules/symbols/findings/lint queries;
• cross-language regression cross_language_shared_service_behavior_is_frontend_neutral applies the same assertions to OPY, Workshop, and OSTW;
• OSTW diagnostics and findings retain multi-file/project-relative provenance;
• shared language-service diagnostics/semantic classification are covered, while unsupported source regeneration/rename remains explicit;
• no upstream OSTW runtime or OSTW-specific analyzer/tool stack was introduced.

Current main CI is fully green, including stable/MSRV Rust quality, OSTW reference/compile differential, and all distribution legs.

The commit-history mixing with #119 is a process/handoff imperfection, not a correctness or architecture blocker.