Skip to content

feat: route OPY workflows through first-party provider - #252

Merged
Teakowa merged 5 commits into
mainfrom
codex/issue-245-provider-workflows
Sep 5, 2026
Merged

feat: route OPY workflows through first-party provider#252
Teakowa merged 5 commits into
mainfrom
codex/issue-245-provider-workflows

Conversation

@e54-bot

@e54-bot e54-bot commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • route ordinary .opy check and compile workflows through first-party LPP 1.1 project loading;
  • keep raw Workshop in-process and non-check OPY workflows explicit until a canonical provider WIR handoff is available;
  • preserve owner diagnostics and source identities, and reject provider failures without native fallback;
  • avoid caching check-only results as an empty WIR; provider WIR is reusable only after canonical compile;
  • enable ureq native certificate loading so clean packaged installs can acquire the OPY provider through platform trust stores without weakening HTTPS verification.

Verification

  • cargo fmt --all
  • git diff --check
  • cargo test --workspace — all tests passed, 2 external-corpus tests ignored
  • cargo clippy --workspace --all-targets --all-features -- -D warnings
  • compatibility evidence tests — 2 passed
  • CLI tests — 22 unit tests and 43 integration tests passed
  • provider-backed N-level gate — 6/6 fixtures passed, including real-world/overpy-cake; recorded snapshots unchanged
  • the gate normalizes only the documented semantic alias UpVector(0, 1, 0)
  • entry-forwarding ablation caused both Bastion and OW1 provider checks to fail closed with ablation-entry-disabled and exit 4
  • python3 scripts/test-npm.py --binaries-dir target/debug — clean isolated npm install, npx wright compile, npx wright check, Node API, and multi-platform archive packaging checks passed

Real-project status

  • Bastion src/main.opy provider check passes with zero diagnostics.
  • Bastion compile currently exposes an opy-rs owner artifact issue: #!define symbols remain in settings and Wright rejects the resulting non-canonical Workshop artifact.
  • OW1 ow1-emulator/src/1v1_main.opy currently exposes opy-rs owner diagnostics for an unsupported append receiver and an owner warning surfaced as an error.

These owner-side blockers remain explicit; Wright does not add a semantic workaround or fallback. The remaining #245 acceptance work is to fix those owner issues and rerun the real-project workflows.

Refs #245

@Teakowa Teakowa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See inline findings.

Comment thread crates/wright-cli/src/main.rs Outdated
Comment thread crates/wright-driver/src/session.rs

@Teakowa Teakowa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Major — The provider cutover fixes the two previous findings, but the new head introduces a required CI regression: OPY integration (N-level + owner) now fails in scripts/v1-gates.py because real-world/overpy-cake diverges after normalization, while the previous head was green. Fix the post-cutover OPY gate/workflow so it validates the intended provider-backed contract and returns green without weakening the compatibility expectation or simply accepting a changed snapshot.

@Teakowa Teakowa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Major — The provider-backed N-level regression is fixed, but the cutover still breaks the clean installed CLI path required by #245. In the current CI, the isolated npm package installs successfully, then npx wright compile compatibility/fixtures/synthetic/basic-rule/source.opy --profile compat exits 4 on macOS (and the Windows distribution smoke fails at the same stage), while Ubuntu passes. Fix the provider acquisition/resolution path for packaged clean installs so ordinary OPY compile/check works without a preinstalled/manual provider, and restore the distribution matrix without falling back to native OPY semantics.

Select the first-party provider for ordinary OPY check and compile workflows, and refuse check-only provider loads for WIR consumers.

Refs #245
Normalize the provider's explicit unit-up vector against the pinned oracle alias while keeping the compatibility snapshot unchanged.

Refs #245
Load platform certificate stores for first-party OPY provider downloads so packaged clean installs bootstrap on macOS and Windows without weakening HTTPS verification or falling back to native OPY semantics.

Refs #245
@Teakowa
Teakowa force-pushed the codex/issue-245-provider-workflows branch from a8eb4c5 to f9cd080 Compare September 5, 2026 06:34

@Teakowa Teakowa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Major — Current head f9cd080 fails the required Rust quality gate on cargo fmt --check for both stable and 1.85.0. main is green, so this is branch-specific after the rebase. Fix the formatting regression and rerun CI; the downstream OPY/native distribution checks are currently skipped, so the remaining provider-bootstrap evidence cannot yet be reverified.

Restore cargo metadata and cargo fmt checks after rebasing the provider workflow branch onto main.

Refs #245

@Teakowa Teakowa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Major — The fmt/rebase fix is resolved, but the new native distribution evidence now shows a real Windows regression on this head: Distribution validation (install.ps1, windows-latest) fails in Run install.ps1 channel validation, and Distribution validation (WinGet, windows-latest) fails in Run WinGet channel validation, after build/metadata validation succeeds. The same channel-validation steps are green on current main (e3c802a). Fix the Windows installed-native Wright path exposed by #252 so the supported Windows channel validations return green; do not weaken or skip the post-install runtime checks or add installer-specific OPY fallback.

@Teakowa Teakowa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

2 participants