Audit Wright crate boundaries around product and tooling ownership #265

Goal

Establish an evidence-backed current-reality map of Wright's workspace and crate boundaries, then define the smallest durable Wright-owned product/tooling layer model that should guide later implementation work.

This issue is an architecture/current-reality audit. It does not itself move, merge, delete, or rewrite production code.

Context

Wright currently spans multiple crates for core/result contracts, IR/integration types, analysis, orchestration, language adapters, provider/LPP integration, product surfaces, transforms, benchmarks, and consumer support. Some boundaries represent durable responsibilities; others may be historical or migration-era seams.

The audit must distinguish current implementation reality from intended architecture. Current reality comes from Cargo dependency edges, public APIs, concrete consumers, source layout, tests, CI, provider integrations, and product workflows. Current architecture contracts live under docs/architecture/; ADRs record decision history rather than proving current implementation state.

Existing issues such as #155, #182, and #243 already own cutover-dependent removals or provider/source-language convergence. This audit may identify those boundaries as transitional or drifted, but must not bypass their dependencies by treating structural cleanup as authority to complete them.

Scope

• Map every Wright workspace crate to its current public APIs, dependency edges, concrete consumers, runtime/product role, and repository ownership constraints.
• Classify each boundary as one or more of:
  • durable Wright-owned product/tooling responsibility;
  • transitional/cutover-dependent boundary;
  • support/test/benchmark fixture rather than architecture layer;
  • consolidation/removal candidate requiring a separate executable Issue.
• Identify pass-through layers, re-export-only seams, duplicate representations, one-off abstractions, overlapping responsibilities, and dependencies whose continued separation lacks a concrete contract or consumer.
• Establish the intended dependency direction between retained Wright-owned responsibilities without introducing a target crate count.
• Record where current implementation reality conflicts with the current architecture contract, including legacy source-language or canonical Workshop ownership that remains temporarily present in Wright.
• Distinguish changes that can be implemented independently from changes deferred to existing cutover/provider/source-owner Issues.
• Update the current architecture contract only if the audit changes a durable intended boundary or dependency invariant.
• Create separately reviewable follow-up Issues for code changes only after dependency/consumer evidence establishes their scope and ownership.

Non-goals

• Moving, merging, deleting, or rewriting production code in this Issue.
• Continuing the real-project/provider integration milestone under Make Wright CLI CI-ready for real Workshop and OverPy projects #242 /Converge source-language workflows on an explicit provider boundary #243 /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 .
• Removing wright-opy, wright-ostw, wright-ir, or another source adapter/representation solely because its long-term ownership is external; cutover-dependent removals remain owned by their existing Issues.
• Moving OPY, DEL/OSTW, or canonical Workshop semantics into Wright.
• Introducing a generic service/container/plugin/framework layer.
• Redesigning Wright public product APIs without a concrete consumer requirement.
• Mechanical crate-count, file-count, line-count, or dependency-count targets.
• Unrelated product features, CLI polish, release work, or lint-rule expansion.

Acceptance criteria

• Every current workspace crate is mapped to concrete responsibilities, direct dependency edges, and real consumers or support roles.
• Every boundary is classified as durable, transitional, support-only, or a separately actionable consolidation/removal candidate, with evidence for the classification.
• Overlap among core/result, IR/integration, language, driver/orchestration, consumer, transform, analyzer, LPP, and source-adapter responsibilities is explicitly identified rather than inferred from crate names.
• The intended Wright-owned dependency direction is documented and aligned with repository ownership: Wright does not become a second OPY, DEL/OSTW, or canonical Workshop semantic owner.
• Cutover-dependent findings are routed to their owning Issues instead of being silently absorbed into structural cleanup.
• Independently actionable code changes discovered by the audit are represented by separate executable Issues with explicit scope, ownership, preserved contracts, and verification evidence.
• docs/architecture/ is updated only where the audit changes a durable current contract; ADRs are added only when a durable architectural choice requires rationale/history.
• Completing this Issue requires no production-code modification.