Audit Wright crate boundaries around product and tooling ownership #265

Activity

1. github-project-automation

   added this to Make Workshop Great Againon Sep 6, 2026
2. github-project-automation

   moved this to Backlog in Make Workshop Great Againon Sep 6, 2026
3. Teakowa

   changed the title [-]Rationalize Wright crate boundaries around product and tooling ownership[/-] [+]Audit Wright crate boundaries around product and tooling ownership[/+] on Sep 7, 2026
4. e54-bot commented on Sep 7, 2026

   

   e54-bot

   on Sep 7, 2026

   Collaborator

   More actions

   Audit status

   Read-only current-reality audit completed against ae5c92998ecfeb220c9aa5436c5c0ef36a1dad98 (remote main, checked 2026-09-07). All 13 workspace crates were inspected. This is an evidence/classification result, not approval to consolidate crates, completion of provider cutover, or closure of this issue.

   The clean local checkout was d66fee19483d4ec2d054de33dfee121f2854ea80. Comparing it with the remote commit showed changes only to AGENTS.md and architecture/document routing; production sources, Cargo files, tests and CI are identical. Current architecture documents were read directly from the audited Git objects. No checkout, branch, source, test, documentation, Cargo or issue-body changes were made. An independent read-only reviewer challenged boundary necessity and consumer claims.

   1. Current reality

   Workspace, dependencies and consumers

   All packages have publish = false. This establishes the current distribution policy, not absence of Git/path consumers or freedom to break the declared embedding API. Release packaging includes wright and wright-lsp; wright-serve and wright-tool are real source-tree binary targets but are not copied into those release archives. wright-bench and wright-consumer are support targets. See workspace manifest, embedding contract, and release packaging.

   In the following map, short names mean wright-<name>. N means a declared normal workspace dependency; D means a declared dev-dependency. These are manifest edges, not assertions that every edge has a caller. The later cleanup findings identify unused edges.

   Crate	Concrete responsibility and public surface	Direct workspace edges; observed production consumers	Support consumers / evidence and classification
   wright-core	hir parses/validates/dumps the serialized wright/opy-hir protocol and converts it to internal HIR; provider exports a synchronous check trait, error and diagnostic/span/severity/status types; signatures only re-exports the canonical owner trait. This is not the product result/envelope home.	N: ir. Driver protocol ingestion uses hir::parse_str -> to_ir; analyzer's wright-tool binary also uses that path. Driver's WorkshopProvider implements the core check trait; driver diagnostic status uses its type. Language and OPY declare core without source references.	core/tests/{hir_ingest,ir_convert,ir_lower}.rs, analyzer legacy-input process tests, driver Workshop-provider tests; OSTW declares a dev edge without references. Mixed transitional HIR boundary + live Wright diagnostic/integration responsibility; not removable wholesale. API bridge raw provider
   wright-ir	Owns arena-based OPY HIR, its validation/dump and HIR→WIR lowering. arena/error/format/ids are forwarding shims to workshop-rs. Canonical WIR is consumed from workshop_rs::wir, not independently implemented here.	N: none. Driver and wright-tool invoke lowering through core conversion. Analyzer, language, driver and transform use canonical infrastructure through the shims. Core consumes the HIR. OPY and OSTW declare IR edges but have no Rust references to it.	ir/tests/models.rs, core conversion/lowering tests and analyzer protocol fixtures. Transitional, explicitly in #155; live legacy input prevents declaring it dead. API lowering driver dispatch
   wright-analyzer	Canonical-WIR semantic index/symbol references, CFG, static findings, lint registry/configuration and SemanticService request/response API; also the wright-tool JSON-lines executable.	N: core, ir. Driver invokes analysis/index/query services; language invokes index/analysis. The library's IR uses are owner infrastructure shims; its core use is in the legacy-input binary, not the library modules.	tests/{analysis,cfg,registry,semantic_index,service,workshop_integration}.rs; CLI dev-dep supports product assertions. Durable Wright analysis/query responsibility, with transitional binary ingress/dependencies. API tool executable driver service
   wright-driver	Reusable CompilerSession, input/config, diagnostics, Envelope and result types, tool service, validated edit transactions/rename, progress, source-provider integration, OPY provider resolution and raw Workshop adapter. This is the actual wright-result/v1 and wright-embedding/v1 facade.	N: analyzer, core, ir, lpp, opy, ostw, transform. CLI/wright-serve invoke session/tool APIs; language reuses edit validation/rename; bench and consumer exercise the same facade.	tests/{driver,service,edit,convert,workshop_contract,workshop_provider,workshop_signature_context,source_provider,lpp,provider_edit}.rs; external-process mock-provider CI. Durable product integration/facade, containing transitional source paths. API results edits
   wright-cli	Binary wright: command/config selection, presentation and CI/JSON rendering, completion, self-update and provider-update UX. Additional binary wright-serve maps JSON-lines/JSON-RPC to driver ToolService. No library target.	N: driver, transform; D: analyzer. Calls driver workflows; direct transform usage is only profile selection, already available as wright_driver::Profile. User-facing process consumers are CLI/CI/install workflows.	tests/{cli,serve,diagnostics_schema,update,workshop_real_projects}.rs, scenario/CLI/distribution gates. Durable product/runtime surface, not semantic ownership. dispatch serve
   wright-opy	Re-exports owner CST/lexer/parser/preprocess/settings/support/tooling/error and reconstruction APIs; wraps manifest enum/signature access and adapts compile outcome/diagnostics. Compilation calls opy_rs::compile_with_overlay_outcome then owner Compiler::compile_hir. It does not itself contain OPY lowering.	N: core, ir (declared but unused). Actual owner edge: opy-rs. Driver native compile/edit/reconstruction and language compilation/lexing/completion consume it; OSTW declares an unused dev edge.	No local Rust test modules or integration-test files found in this crate at this revision. CI's cargo test -p wright-opy therefore must not be mistaken for a local adapter regression suite; substantive callers are tested in driver/language/product suites. Its reconstruction fixtures are also concretely consumed by driver/tests/convert.rs and cli/tests/cli.rs, so fixture-only directories are not automatically dead. Transitional static adapter, #155 after #245/#246. entire adapter
   wright-ostw	Calls owner project loading, semantic checking and WIR lowering; maps project/files/imports/diagnostics to historical Wright shapes; adapts owner lexer tokens and reconstruct API. Public surfaces include diag, lexer, Project/FileRecord/ResolvedImport, OstwOutcome/SemanticOutcome and compile-with-overlay functions.	N: ir (unused); D: core, opy, transform (unused). Actual owner edge: del-rs, Cargo alias for deltin-rs. Driver compilation/edit/reconstruction and language compile/token services are concrete consumers.	No local Rust tests found in the adapter. Driver convert/edit and language service tests exercise it; CI builds/tests the adapter. Residual compatibility/ostw/ infrastructure is separate evidence ownership under #182. Currently required native integration adapter; historical projection boundary is transitional/revisable. No DEL provider cutover or whole-crate removal follows from this audit. entire adapter
   wright-transform	Public Profile, run, Pass, PassStats/PassResult, FoldConstants. Pipeline validates WIR before/after mutation; off selects no passes, compat/aggressive currently select constant folding.	N: ir (owner ID/error/number-format shims). Production execution is in driver session/edit paths; CLI and bench only consume Profile. OSTW's dev edge has no caller.	tests/pipeline.rs and pipeline unit tests; driver/profile and benchmark workflows. Wright-owned profile/validation orchestration responsibility; crate consolidation candidate is conditional, not authorized. Semantics inside folding require the ownership qualification below. pipeline folding
   wright-bench	Binary harness drives sessions/profiles and records reproducible host time/resource measurements and reports. No library API. Host measurements are not in-game Workshop performance guarantees.	N: driver, transform. No incoming workspace edge. Actual consumer is benchmark CI/release validation, not a production library.	CI explicitly builds/runs wright-bench and uploads its report; release gate also runs the harness. Support/benchmark only, with a concrete separate executable role. harness benchmark CI
   wright-consumer	run_consumer/workflow library plus binary exercise compile/check/analyze/query and validated edits using the driver facade.	N: driver. No incoming workspace edge. It is an in-repository consumer fixture, not an independently established external adopter.	tests/consumer.rs drives the workflow; separate Cargo dependency set demonstrates use without direct IR/implementation imports. Support/test only, useful boundary evidence. manifest workflow
   wright-language	Public versioned Document/DocumentStore, UTF-16 editor positions/ranges, LanguageService, diagnostics/hover/locations/completion/rename/tokens and analysis result types. Compiles source via static adapters, builds semantic index/findings, delegates transaction validation to driver.	N: analyzer, core, driver, ir, opy, ostw; core has no references. Only observed production consumer is wright-lsp. Current Analysis exposes OPY error/file types, and OSTW errors are converted to OPY-shaped errors.	tests/{service,overlay,cross_file,perf}.rs; LSP protocol tests. Durable editor-neutral responsibility, transitional source coupling; necessity of a separate Cargo crate is unknown. API implementation
   wright-lsp	Binary LSP JSON-RPC framing/dispatch and mapping between lsp-types and editor-neutral service results. No library API.	N: language. A separately shipped process used by editor clients; release/distribution scripts explicitly package/smoke it.	tests/lsp.rs, native distribution smoke. Durable runtime/protocol boundary; a separate executable does not logically mandate a separate Cargo package. server packaging
   wright-lpp	Public JsonRpcClient/ClientConfig/ClientPhase, ChildProcess, registry/configuration, negotiated LanguageProvider/StdioLanguageProvider, typed LPP requests/results/capabilities and structured failures; stdio lifecycle/framing/correlation/timeouts.	N: none. Driver consumes it through source-provider adapter, generic tool/provider queries and validated provider edits. No source implementation or driver dependency points back from this crate.	tests/{unit,mock_provider}.rs; driver LPP/provider-edit suites; CI builds a pinned external language-provider-protocol mock. Durable Wright client/runtime responsibility; the protocol repository owns the wire contract. API provider trait CI

   For completeness, the direct non-workspace package edges in the crate manifests are:

   Crate	Normal dependencies	Dev dependencies
   core	serde, serde_json, workshop-rs	—
   ir	workshop-rs	—
   analyzer	serde, serde_json, workshop-rs	—
   driver	serde, serde_json, sha2, flate2, tar, ureq, url, workshop-rs	—
   cli	clap, clap_complete, flate2, serde, serde_json, sha2, tar, ureq	insta, jsonschema, workshop-rs
   opy	opy-rs, serde, serde_json, workshop-rs	sha2
   ostw	del-rs (= package deltin-rs), workshop-rs	serde_json, sha2
   transform	serde, workshop-rs	—
   bench	libc, serde, serde_json	—
   consumer	serde_json	—
   language	serde, serde_json, url, workshop-rs	libc
   lsp	lsp-types, serde_json	—
   lpp	serde, serde_json	os_pipe

   These are declared edges, including unused residue. Root owner pins are workshop-rs = 0.1.18, opy-rs = 0.1.18, and deltin-rs = 0.1.2. This is a direct-edge audit, not a claim that their transitive dependency graphs or release cadences are equivalent. Every row is grounded in its crate Cargo.toml.

   Runtime paths and ownership drift

   1. The product cutover is partial, not absent. CLI check/compile pass provider_workflow = true; OPY selection then uses SourceBackend::Provider. Ordinary lint/analyze/inspect/convert pass false and retain native dispatch unless an explicit provider path selects it. SessionConfig::default() is still native. Provider sessions resolve/initialize the OPY process and pass an LPP entry, while raw Workshop uses workshop-rs in-process. CLI session dispatch source adapter

   2. Legacy source semantics remain executable in Wright. Protocol input and the explicitly selected WRIGHT_ADAPTER_PATH route parse the serialized OPY HIR in core, convert to Wright IR, and lower inside Wright. wright-tool --program repeats this ingress independently of driver. This directly differs from the owner contract and integration contract; it is Remove residual static OPY implementation after provider cutover #155 cutover residue, not a durable Wright compiler layer. The native adapter itself delegates semantics to opy-rs; do not confuse its owner compile_hir call with the separate Wright-owned legacy lowerer. bridge path fallback tool

   3. Editor integration is not source-neutral today. LanguageService compiles through OPY/OSTW adapters, dispatches on source token kinds, consults OPY manifest shapes, and stores OPY error/file types for both languages. In particular, ostw_error_to_opy is a second diagnostic projection, not a neutral owner result. Some token presentation is legitimately Wright/editor work; this evidence does not prove every token switch is an illicit parser. It does show that the shared-service/owner-input intent is not fully realized. Any replacement must preserve owner provenance and edit refusal; do not move source semantics into a new Wright language module. language implementation

   4. Three provider abstractions overlap without being interchangeable:

      • core::provider::LanguageProvider: synchronous single-document check, implemented by raw WorkshopProvider and called by session Workshop diagnostics.
      • driver::SourceProvider: selected-entry check/compile, product diagnostics, canonical Workshop text and provenance; LppSourceProvider is its production adapter.
      • lpp::LanguageProvider: negotiated/session-oriented document and entry operations, compile/query/rename/edit-validation/reconstruction and structured transport failures.

      Their similar names/check operations are not proof that a universal provider trait is justified. Keep Converge source-language workflows on an explicit provider boundary #243's entry product boundary separate from process/wire concerns. Generic ToolRequest and provider-edit request APIs currently contain wright_lpp::DocumentSet/Position; this is a remaining product/wire coupling, not proof that the Converge source-language workflows on an explicit provider boundary #243 OPY entry path itself exposes those mechanics. Mutation/editor convergence remains Wire provider-driven mutation through Wright product surfaces #156 and the existing owner chain. core provider source provider tool API provider edit API

   5. Representation duplication has different causes. Serialized OPY HIR in core plus internal OPY HIR/lowering in IR are transitional source-owner duplication. IR infrastructure re-exports and core signatures are forwarding paths with one owner type identity, not duplicate WIR implementations. Diagnostic/span families in core, driver, language and LPP have different contracts: driver uses 1-based source coordinates, language/LPP use editor/wire coordinates, and driver adds origin/stage/result framing. Those mappings cannot be deleted on name similarity. Core's Status also appears in driver serialization. Provider artifacts are currently only SourceProvenance::Unmapped; their generated spans are not authored OPY locations. types diagnostics editor coordinates provenance

   6. Transform ownership needs a narrower decision than “move/keep crate”. Wright can own profile selection, validated transformation orchestration and product metrics. FoldConstants also encodes arithmetic, boolean domination and Workshop call-name rewrites locally. Current evidence does not establish whether every such rule is a justified Wright transformation over owner semantics or a duplicated canonical/source semantic rule. Therefore no promotion of those rules to durable Wright semantic ownership, owner migration, or crate deletion is authorized here. Merely being a WIR pass or matching old OverPy output does not settle ownership. implementation

   The current docs/architecture/ files establish responsibilities and dependency direction, not a mandatory crate inventory. Most differences above are implementation drift from that intent, not a reason to rewrite the intent. No new durable ownership contract is proposed by this audit.

   Evidence limits from CI

   The CI run on the identical-code checkout passed Rust quality, OPY/OSTW integration, LPP integration, Workshop real projects, CLI/scenarios and benchmark jobs, but the overall run failed on macOS install.sh and Windows WinGet distribution jobs. This audit did not rerun builds/tests or reproduce those failures. The current main Release-please success is not a product-test result.

   LPP CI explicitly supplies LPP_MOCK_PROVIDER from a pinned protocol repository and runs client/driver/provider-edit suites; that is real protocol-consumer evidence, not proof of all real OPY project semantics. Adapter-only Cargo test commands likewise do not establish language completeness. LPP CI

   2. Architecture classification and non-mutating ablation

   Retain the responsibility before deciding the packaging.

   Boundary	Removing the crate boundary but retaining a module: what actually breaks or remains unknown?
   driver facade	Folding the facade into a binary-only CLI/LSP package removes the concrete wright_driver checkout embedding surface and breaks the driver-only consumer fixture. Retain this reusable facade/dependency entry. Its internal module split is revisable.
   analyzer	Folding it into driver would make the current language/wright-tool analysis consumers reach through product orchestration, provider resolution and static source adapters. The existing downward analysis dependency and separate tool executable give concrete isolation evidence. Retain the current boundary; do not infer an external adopter for wright-tool from its tests.
   lpp	Moving it into driver could preserve process behavior as a module; a process boundary alone does not prove a Cargo boundary necessary. Current source-language-independent dependencies and directly tested client API justify retaining isolation for now. Public provider types and unfinished cutover make consolidation a contract decision, not an executable cleanup.
   cli / lsp	Removing their runtime identities breaks shipped command/editor/distribution contracts. Combining binaries in a Cargo package could preserve those identities, so mandatory separate-package topology is not proven. No current consumer problem justifies changing it.
   language	A module can preserve editor-neutral types/no dependency on lsp-types. One observed production consumer is insufficient to establish an independent embedding requirement. Retain the responsibility/current layout; separate-crate necessity is unknown, especially while source/provider/edit contracts are unresolved.
   transform	All observed production execution is in driver; CLI/bench need only a type driver already exports. A driver module could keep read-only analysis separate and preserve pre/post validation. This is a locally evidenced consolidation candidate, but public/experimental pass consumers and semantic ownership remain unresolved: stop at candidate/unknown, no consolidation decision.
   core / ir / opy	Live HIR protocol ingestion, legacy adapter and native tooling consumers fail if removed now. Their long-term source-semantic/re-export roles are transitional under #155; retain only demonstrated Wright diagnostic/tooling contracts after that owning cutover, not before it.
   ostw	Driver/language currently call it for native DEL workflows. Removing it loses a working integration path; a module might preserve that adapter but requires projection/API/consumer review. DEL provider design is not part of #242, and #182 concerns evidence infrastructure, not authorization to delete this adapter.
   bench	Support role is concrete. Absorbing its executable into production responsibilities would mix host measurement/libc/reporting concerns; a separate support target isolates them. No deletion candidate established.
   consumer	Absorbing it into driver unit tests loses the distinct Cargo dependency-surface check that forbids direct internal imports. Keep as a support fixture; do not call it a production architectural layer or external adopter.

   Thus durable product responsibilities are retained without freezing today's crate count. No unconditional whole-crate removal is established. Forwarding-only modules are identified, and small unnecessary edges are separately actionable below.

   3. Intended dependency direction

   • CLI/CI presentation, stdio tool adapters, editor/LSP and embedding entry points consume reusable Wright orchestration/query/edit services.
   • Editor-neutral document/version/coordinate handling stays outside LSP-specific types; shared transaction safety remains reusable across surfaces.
   • Session/tool orchestration composes Wright analysis/query and validated-edit responsibilities with narrow source-owner adapters.
   • Wright analysis consumes canonical Workshop and owner-provided semantic/provenance evidence. It must not depend upward on CLI/LSP/process discovery or become a second source compiler.
   • Product source requests identify the selected entry; source owners discover projects and supply diagnostics/compilation. Wright's LPP client handles process/session mechanics while language-provider-protocol owns wire definitions.
   • Canonical Workshop parsing/validation/catalog/settings/WIR/emission remain in workshop-rs. OPY and DEL source/compiler/reconstruction semantics remain in opy-rs and deltin-rs, respectively. No owner repository should depend back on Wright internals.
   • Profile selection and edit/transform validation may remain Wright tooling responsibilities; no blanket reassignment of semantic rewrite rules is implied.

   These directions specify responsibilities and isolation; they do not optimize for a target number of crates.

   4. Deferred work owned by existing issues

   • Remove residual static OPY implementation after provider cutover #155, dependent on 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: residual static OPY dependencies, old OPY HIR/lowering/fallbacks and canonical infrastructure re-export shims. This includes whole-crate decisions about core/IR/OPY residue. Do not implement that cut under a new structural-cleanup label.
   • Converge source-language workflows on an explicit provider boundary #243: entry-based product/provider convergence and result/failure/provenance boundary. Existing code implements a concrete entry path; the issue remaining open does not mean no implementation exists.
   • Run real OPY check and compile workflows through the first-party provider #245: real-project OPY check/compile acceptance. Its live record says the initial provider plumbing landed but canonical real-project compilation still requires owner fixes/verification. Its current dependency graph includes Synchronize Wright's Workshop dependency graph on workshop-rs 0.1.18 #259, opy-rs#188 and workshop-rs#144. This audit does not supersede that evidence or reopen fixed plumbing.
   • Preserve Wright lint and analyze semantics across the OPY provider boundary #246: real provider-backed lint/analyze and truthful authored/canonical provenance. Do not use old native-path success or an unmapped provider artifact as proof of completed source attribution.
   • Track removal of residual OSTW owner-style evidence after deltin-rs migration #182 → Migrate authoritative OSTW reference evidence from Wright deltin-rs#49: authoritative OSTW oracle/corpus/reproduction ownership. Both are currently open. Classify retained artifacts against named integration consumers after the owner handoff; do not delete the tree or assume its adapter is obsolete.
   • Wire provider-driven mutation through Wright product surfaces #156: provider-produced mutation/refusal/validation integration across product surfaces; any overlap found in generic tool/editor paths stays within that existing work.
   • Make Wright CLI CI-ready for real Workshop and OverPy projects #242/Design lightweight first-party language provider distribution and lazy loading #240/Bootstrap and resolve the first-party OPY provider #244 and the above owner chain retain milestone/distribution authority. Open Analyze persistent Workshop object lifecycle and fan-out #262/Analyze ongoing Workshop condition hot paths #263 concern analysis capabilities, not authorization for this audit to expand analyzer features. The only open PRs observed were dependency updates build(deps): bump jsonschema from 0.18.3 to 0.56.0 #236/build(deps): bump ureq from 2.12.1 to 3.4.0 #237; neither establishes an architecture cutover.

   5. Executable follow-ups with already bounded scope

   No follow-up issues were created, as requested. These are scopes suitable for separate executable issues, not changes performed or permission to bundle migration work.

   1. Remove unused non-OPY manifest edges. Source/test scans found no references, includes, macro use or build scripts consuming wright-language -> wright-core, wright-ostw -> wright-ir, or OSTW's dev edges to wright-core/wright-opy/wright-transform/serde_json/sha2. Cut only those unused declarations; preserve all runtime code, public types, owner dependencies and compatibility artifacts. Risk: internal dependency/feature-unification change, so verify affected all-target builds/tests and workspace quality gates; restore/reclassify any edge shown to supply a required feature. No claim is made that removing a manifest edge alone removes a package transitively. OPY's analogous unused edges are recorded in the inventory but left to Remove residual static OPY implementation after provider cutover #155 to avoid splitting its cutover scope.

   2. Have CLI/bench use the existing driver Profile export. Change their wright_transform::Profile imports/references to wright_driver::Profile and remove those two direct transform manifest edges. Driver already exports the identical type; no profile values, pipeline, serialized metrics or CLI behavior should change. Verify CLI profile/result tests and benchmark harness build/execution. This reduces direct consumer knowledge without introducing a wrapper or requiring transform consolidation.

   The transform-as-driver-module observation is not an executable follow-up yet: external/API use and rule ownership must be settled first. Likewise, do not turn a signatures re-export observation into an independently scheduled #155 bypass. Any later whole-crate cut requires its own consumer/contract acceptance evidence.

   6. Unknowns / decisions intentionally not made

   • External Rust/API adopters: repository manifests, current call sites, nearby owner-workspace manifest searches and GitHub code search did not establish an external adopter of these internal packages. Search absence is not proof of non-use; publish=false does not exclude Git/path consumers. No public API removal is authorized on that basis.
   • Language/transform/LPP package necessity: durable responsibilities are established, but current evidence does not prove every separate Cargo package essential. Stop at the qualifications above where consolidation would affect public or unfinished provider contracts.
   • Transform rule ownership/correctness: the current arithmetic/call rewrite implementation was inspected, but no owner-side equivalence analysis or behavioral ablation was run. Structural validation does not prove semantic equivalence. No new semantic owner is selected.
   • Completed OPY cutover/provenance: the owning issues remain open; this audit did not execute pinned Bastion/Overwatch-AI-PVE workflows. Existing real-project acceptance must be resolved in that chain.
   • DEL adapter future: no current DEL-provider cutover contract was established; Track removal of residual OSTW owner-style evidence after deltin-rs migration #182's evidence migration cannot supply one.
   • Independent ablation was conceptual and read-only: the reviewer challenged module alternatives, dependency isolation and concrete consumers. No production code was disabled/moved and no behavioral mutation result is claimed.
   • Audit Wright crate boundaries around product and tooling ownership #265 closure bookkeeping: its original acceptance criteria discuss follow-up issues and conditional documentation updates. The requested deliverable here is one audit comment, with no new issues or document changes. This comment records the audit result and bounded future scopes; it does not assert that those additional issue-management criteria have been executed.
5. Teakowa commented on Sep 7, 2026

   

   Teakowa

   on Sep 7, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   Architect review: the audit is accepted as the current-reality/architecture result for #265.

   The audit establishes the crate/consumer/dependency map, distinguishes durable responsibilities from transitional/support boundaries, preserves the existing repository ownership model, and correctly leaves unresolved packaging questions (notably whole-crate wright-transform, wright-language, and wright-lpp consolidation) as unknown rather than converting them into implementation work.

   Two independently bounded implementation follow-ups were created from the evidence:

   • Remove unused non-OPY workspace dependency edges #266 — remove unused non-OPY workspace dependency edges.
   • Route CLI and benchmark profile selection through the driver facade #267 — route CLI/benchmark profile selection through the existing driver facade and remove their direct transform edges.

   Cutover-dependent findings remain with #155/#182/#243 and their dependency chains. No durable architecture contract changed, so no docs/architecture/ or ADR update is required by this audit.

   With the audit recorded and actionable findings routed to separate Issues, #265's acceptance contract is complete.
6. Teakowa

   closed this as completedon Sep 7, 2026
7. github-project-automation

   moved this from Backlog to Done in Make Workshop Great Againon Sep 7, 2026