Ship a first-party LPP provider for real OPY project workflows

[Teakowa]

Product milestone: wrightkit/wright#242
Depends on distribution design: wrightkit/wright#240
Coordinates with product boundary: wrightkit/wright#243
Protocol dependency: wrightkit/language-provider-protocol#16

Goal

Expose opy-rs as the first-party LPP provider used by Wright for real OverPy project checking and compilation, while keeping all OPY project loading, preprocessing, source semantics, diagnostics/provenance, and compiler behavior owned by opy-rs.

Context

Wright's current milestone requires check, lint, compile, and analyze to work on real OverPy projects such as OWBastion/Bastion and Teakowa/Overwatch-AI-PVE. The provider is the owner-side delivery boundary that lets OPY implementation releases advance independently from Wright releases.

The provider must be a thin process surface over existing opy-rs owner capabilities. It must not create a second OPY implementation or expose owner-internal AST/HIR/WIR through LPP.

The approved Wright boundary is entry-based: Wright resolves the user-selected path from the invocation cwd and delegates OPY project discovery to opy-rs. opy-rs therefore owns #!mainFile, #!include, preprocessing/macros, and the source closure. language-provider-protocol#16 owns the narrow wire change required so this owner-side filesystem loading does not require Wright to construct the full project DocumentSet.

Scope

• Provide a spawnable first-party LPP process owned and released by opy-rs.
• Implement the LPP capabilities required by the current Wright milestone, beginning with check and compile.
• Accept the selected OPY entry through the approved LPP entry/project-loading contract and load the real project through opy-rs ownership.
• Handle #!mainFile, reachable includes, preprocessing/macros, project/source closure, and locale/options required by the supported workflow inside opy-rs.
• Preserve structured owner diagnostics and source-file identity across the LPP boundary.
• Produce the approved Workshop artifact for successful compile requests without exposing Rust/compiler implementation types on the wire.
• Participate in the source/provenance handoff required by the approved Wright contract for Wright-owned lint/analyze; do not invent provider-private wire semantics.
• Package/release the provider artifact according to the approved convention from wright#240 so Wright can resolve it independently.
• Use pinned real revisions of Bastion and Overwatch-AI-PVE as end-to-end owner evidence in addition to focused regression/contract evidence.

Non-goals

• Implementing Wright lint/analyze rules inside opy-rs.
• Moving canonical Workshop semantics, WIR, validation, catalog, localization, or emission ownership out of workshop-rs.
• Exposing OPY AST/HIR/compiler internals over LPP.
• Requiring Wright to scan OPY files, interpret #!mainFile, or resolve #!include.
• Implementing a package registry, dependency solver, provider installer, or Wright cache policy.
• Implementing DEL/OSTW support.
• Weakening source/compiler conformance expectations to make real projects pass.
• Requiring generated Workshop text identity with upstream OverPy when observable/canonical semantics are equivalent.
• Adding generalized LSP workspace synchronization or unsaved-document overlays in this milestone.

Acceptance criteria

• The provider initializes through the published LPP contract and advertises only capabilities it actually supports.
• The provider can receive a selected OPY entry without requiring Wright to preload the complete OPY source closure.
• lpp/check operates on supported real multi-file OPY projects through opy-rs project loading and returns structured diagnostics associated with the correct original source documents.
• lpp/compile operates on the same project model and returns no Workshop artifact when error-severity diagnostics prevent compilation.
• Successful compile requests return the Workshop artifact format approved by the cross-repo design without leaking owner-internal AST/HIR/WIR or Rust types.
• Project entry/root, #!mainFile, includes/reachable files, preprocessing/macros, and supported locale/options needed by the pinned Bastion and Overwatch-AI-PVE workflows are handled by opy-rs, not reconstructed in Wright.
• Provider stderr/logging never corrupts the stdio protocol stream, and process lifecycle/shutdown conforms to LPP.
• Provider artifact/release metadata follows the approved first-party distribution convention and can be consumed without a Wright release.
• Any blocker demonstrated to belong to OPY source semantics or compiler/lowering is fixed in opy-rs; canonical Workshop blockers are reassigned to workshop-rs rather than bypassed.
• Pinned Bastion and Overwatch-AI-PVE provider check / compile workflows are independently rerun after implementation.
• Implementation ablation that disables the provider project-loading or owner compile path causes the relevant real-project evidence to fail again.

Dependencies / ownership

• wrightkit/wright#240: approved first-party provider distribution convention.
• wrightkit/wright#243: approved entry-based Wright product/provider seam.
• wrightkit/language-provider-protocol#16: narrow process/wire contract for provider-owned filesystem project loading from an entry target.
• opy-rs#157: owner for residuals proven to belong to OPY compiler/lowering/canonical-WIR convergence.
• workshop-rs: canonical Workshop semantics.

Readiness

Ready. Distribution and product ownership decisions are resolved. Implementation may proceed in parallel with language-provider-protocol#16, but must consume that owning wire contract rather than inventing an OPY-private protocol or moving project discovery into Wright.

[Teakowa]

Current reality correction (2026-09-03): reopening the issue for the remaining owner-side shipping gate.

The provider implementation, project-loading/compiler workflow, contract coverage, and owner-side real-project fixes are on main. However, this issue's Scope/Acceptance Criteria also require the first-party provider to be packaged/released according to the approved distribution convention so it can be consumed independently from a Wright release.

That shipping evidence is not true yet: the current latest GitHub Release is v0.1.12 and has no opy-provider-* assets. The provider-enabled v0.1.13 release PR is #169.

Keep #170 open only for this remaining release fact: merge/publish the provider-enabled release, observe the target archives and .sha256 assets on the actual GitHub Release, and verify that Wright can consume that release surface. Do not reopen the already-completed provider/project-loading architecture or compiler work.

[Teakowa]

Current release evidence after merging #169: v0.1.13 was created, but the provider artifact workflow failed before publish. The aarch64-apple-darwin build itself succeeded; the archive step failed because sha256sum is unavailable on the macOS arm64 runner, so the publish job was skipped and the GitHub Release still has no provider assets.

This keeps the packaging/release AC open. Fix the owner release workflow with a checksum path that works on every supported runner, then verify a subsequent tagged release actually publishes all target archives plus checksums. Do not treat the crate release/tag alone as provider delivery evidence.

[Teakowa]

Current release evidence after v0.1.14: PR #175 fixed the macOS checksum failure successfully. All four target jobs now build, archive, checksum, and stage their provider artifacts. The remaining failure has moved to the publish job: gh release view "$GITHUB_REF_NAME" waits for 30 attempts and exits with release v0.1.14 was not created, even though the GitHub Release exists. The publish job does not check out the repository and does not pass an explicit repository to gh, so the next fix should keep this scoped to release upload/repository context (for example GH_REPO=${{ github.repository }} or explicit --repo), then verify the actual Release contains all archives and checksums. Keep #170 open until that shipping fact is true.