Make Wright CLI CI-ready for real Workshop and OverPy projects

[Teakowa]

Goal

Make the Wright CLI reliable enough to replace the existing OverPy compile gate in real projects by supporting check, lint, compile, and analyze for declared raw Workshop and OverPy project workflows.

This is a product milestone. Completion is defined by real-project behavior, not by the existence of command surfaces or isolated fixtures.

Context

Wright exposes the four target commands and stable CLI/CI rendering contracts. This milestone proves that source-language ownership, provider delivery, project loading, diagnostics/provenance, and Wright-owned canonical tooling remain correct on real projects.

The first OverPy validation targets are:

• OWBastion/Bastion, using its real src/main.opy project workflow and locale/root requirements;
• Teakowa/Overwatch-AI-PVE, using its real src/main.opy project workflow and project root.

After this issue is complete, those projects can separately replace their existing OverPy CI gate with Wright and provide the next round of product evidence.

Scope

• Make raw Workshop wright check, wright lint, wright compile, and wright analyze reliable within the declared supported surface.
• Make the same four workflows reliable for real OverPy projects through the source-language owner boundary.
• Use a first-party OPY LPP provider as the delivery path so ordinary opy-rs implementation releases do not require a Wright release.
• Preserve source diagnostics and provenance needed by Wright-owned lint/analyze reporting.
• Keep CLI behavior deterministic and CI-safe, including exit codes and machine-readable output.
• Drive missing semantics back to the owning repository rather than adding Wright-side OPY or Workshop semantic fallbacks.
• Validate the completed stage against pinned real revisions of Bastion and Overwatch-AI-PVE, plus representative raw Workshop evidence.

Non-goals

• Migrating Bastion or Overwatch-AI-PVE CI in this issue; that happens after this milestone is independently verified.
• DEL/OSTW provider implementation for this stage.
• New generic plugin, registry, dependency solver, or provider marketplace architecture.
• New LSP, agent, semantic-edit, conversion, or unrelated CLI features.
• Adding new lint rules solely to increase feature count.
• Requiring generated Workshop text identity with upstream OverPy when observable/canonical semantics are equivalent.
• Implementing source-language semantics in Wright.

Acceptance criteria

• Representative raw Workshop projects successfully run wright check, wright lint, wright compile, and wright analyze within the declared supported surface.
• Pinned real revisions of Bastion and Overwatch-AI-PVE successfully run the four target Wright workflows with their real project structure, includes/preprocessing, root, and locale requirements.
• wright compile produces valid Workshop output with declared observable/canonical semantic compatibility for the supported OverPy surface; text/temporary/helper identity is not required unless separately contracted.
• wright check preserves owner diagnostics and source identity for project files.
• wright lint and wright analyze remain Wright-owned and report evidence against original source provenance where the approved provider contract can map it; unmappable provenance is explicit rather than fabricated.
• Raw Workshop workflows do not resolve, install, or contact OPY/DEL providers.
• First use of a missing first-party OPY provider can bootstrap through the approved distribution design; an installed provider is reusable offline and failures are explicit.
• Provider/process failures are distinguishable from source diagnostics through machine-readable contracts.
• Text, JSON, generic CI, and GitHub Actions modes remain deterministic and preserve the documented stdout/stderr and exit-code contracts.
• Any real-project blocker is fixed in its owning repository and then reverified through Wright; no Wright-side semantic workaround is introduced.
• Independent verification reruns the real-project workflows after implementation.
• Implementation ablation disables/removes the key provider/project integration path and demonstrates that the relevant real-project regression evidence fails again.

Delivery graph

• Design lightweight first-party language provider distribution and lazy loading #240 owns the lightweight first-party provider distribution contract.
• Converge source-language workflows on an explicit provider boundary #243 owns the entry-based Wright product/provider seam and source/diagnostic/canonical-provenance boundary.
• wrightkit/opy-rs#170 owns the first-party OPY provider and owner-side project loading/check/compile behavior.
• Bootstrap and resolve the first-party OPY provider #244 owns Wright-side OPY provider resolution/bootstrap/integrity/offline reuse.
• Run real OPY check and compile workflows through the first-party provider #245 owns real provider-backed OPY check / compile product verification.
• Preserve Wright lint and analyze semantics across the OPY provider boundary #246 owns real provider-backed OPY lint / analyze with truthful canonical/source provenance.
• Remove residual static OPY implementation after provider cutover #155 removes residual static OPY implementation/dependencies only after the provider-backed replacement is proven.

Owner work is created only from demonstrated failures:

• wrightkit/opy-rs#157 for residuals proven to belong to OPY compiler/lowering/canonical-WIR convergence;
• workshop-rs for demonstrated canonical Workshop defects;
• language-provider-protocol only when a real product workflow demonstrates a missing process/wire contract.

Do not create DEL/OSTW provider implementation work during this milestone.

Dependencies / ownership

• wright: product CLI, provider resolution/integration, Wright-owned lint/analyze, rendering, orchestration, and final real-project verification.
• opy-rs: OPY project discovery, preprocessing/macros, source semantics, diagnostics/provenance, compiler behavior, and first-party provider executable.
• workshop-rs: canonical Workshop parsing, semantics, validation, WIR, catalog, localization, and emission.
• language-provider-protocol: process/wire contract only.

Near-term work remains limited to this delivery graph. New infrastructure, cleanup, protocol, or tooling work requires a demonstrated dependency on this milestone.

[Teakowa]

Current phase acceptance update (2026-09-03): not complete yet.

Verified current reality:

• The Wright-owned entry-based SourceProvider seam and first-party OPY resolver are on main.
• opy-rs now owns and implements the first-party LPP provider/project-loading path, and the real Bastion / Overwatch-AI-PVE work has driven owner-side compiler fixes.
• The current latest OPY GitHub Release is still v0.1.12 and has no opy-provider-* assets, so a clean Wright install cannot exercise the approved lazy-bootstrap path yet. The current release vehicle is wrightkit/opy-rs#169.
• The production Wright CLI has not cut over to the provider source backend. SessionConfig::default() still selects SourceBackend::Native; the ordinary CLI records --opy-provider but constructs CompilerSession::new(config) without switching the backend or injecting a concrete SourceProvider. Therefore ordinary .opy check / compile / lint / analyze are not yet evidence for the provider-backed milestone.
• Existing driver tests prove the abstract source-provider seam with a recording provider, and generic LPP tests prove the transport/provider registry separately; they do not substitute for the production OPY CLI workflow.

Execution order remains evidence-driven:

1. Publish and observe the first provider-enabled OPY release artifact/checksum.
2. Finish Bootstrap and resolve the first-party OPY provider #244 clean bootstrap/offline/update/ablation verification against that real release.
3. Implement Run real OPY check and compile workflows through the first-party provider #245 production CLI cutover with no hidden native/static fallback; independently rerun pinned Bastion and Overwatch-AI-PVE wright check / wright compile.
4. Implement/verify Preserve Wright lint and analyze semantics across the OPY provider boundary #246 wright lint / wright analyze over provider-produced canonical Workshop evidence without fabricating authored OPY source spans.
5. Independently rerun raw Workshop + pinned Bastion + pinned Overwatch-AI-PVE through all four production CLI commands, including machine output/exit contracts and ablation.
6. Only after that acceptance pass, replace the existing OverPy build jobs in the two real project CIs.

Do not close #242 or migrate CI before those gates are observed on the production binary.

[Teakowa]

Current reality (2026-09-05): the milestone has moved from provider architecture into product convergence.

• Design lightweight first-party language provider distribution and lazy loading #240 and Bootstrap and resolve the first-party OPY provider #244 are complete.
• language-provider-protocol#16 and opy-rs#170 are complete; the owner now exposes the entry-based first-party LPP provider and released provider artifacts.
• Wright PR feat: route OPY workflows through first-party provider #252 moved ordinary OPY check / compile onto the first-party provider path with no native semantic fallback. Bastion provider check is green; real-project compile evidence exposed remaining owner-side artifact/semantic failures rather than a Wright project-loader gap.
• Run real OPY check and compile workflows through the first-party provider #245 therefore remains open for owner-fix -> Wright rerun closure, not for initial provider plumbing.
• Preserve Wright lint and analyze semantics across the OPY provider boundary #246 is now the next Wright-owned integration frontier: provider-backed lint / analyze still need a truthful canonical semantic/provenance handoff.
• Remove residual static OPY implementation after provider cutover #155 remains post-cutover cleanup and must wait until Run real OPY check and compile workflows through the first-party provider #245/Preserve Wright lint and analyze semantics across the OPY provider boundary #246 replacement evidence is complete.

The issue body has been rebaselined to keep only the durable delivery graph; current progress should continue to be derived from issue/PR/release evidence rather than maintained as a checklist in the body.