Roadmap to v1.0: stable Workshop tooling platform

[Teakowa]

Goal

Define Wright's pre-1.0 roadmap by user-visible product readiness and real workflow evidence rather than internal migration phases.

Current execution state

Raw Workshop convergence is complete:

• wrightkit/workshop-rs#65 — completed
• wrightkit/wright#191 — completed via PR fix(workshop): converge on released workshop-rs 0.1.9 #225 against released workshop-rs 0.1.9

The focused source-language convergence lane is now OPY. Current owner-side progress:

• opy-rs#52 — dependency rebaseline complete
• opy-rs#46 — non-control-flow primitive lowering complete
• opy-rs#47 — control-flow lowering complete via PR [M9] Validate external consumer integrations and API versioning #61 against released workshop-rs 0.1.11
• opy-rs#41 — statements/expressions acceptance gate complete
• opy-rs#42 — catalog-backed builtin/member/enum lowering and corpus closure is the active semantic edge

Current OPY execution chain:

#42 → close #36 → #37 → #38 → close #8

Do not move bounded follow-ups such as opy-rs#58/#59/#60/#65 or workshop-rs#95 onto the critical path unless representative real-project/end-to-end evidence proves they block the declared compiler baseline.

Tooling-first product order

Wright remains the unified tooling/product layer over independently owned language implementations. Product priority remains:

1. check / diagnostics
2. lint / static analysis
3. inspect / semantic query
4. validated source edits / refactoring
5. agent / embedding workflows
6. CI / language services
7. Workshop stability / cost analysis
8. compilation / conversion as required by real workflows

Compiler work is product-enabling infrastructure, not the sole progress metric. Wright must not claim source-language behavior beyond what the owning implementations actually support.

Ownership and dependency rules

• Raw Workshop semantics/catalog/settings/WIR/emission gaps belong to workshop-rs.
• OPY syntax, preprocessing/macros, semantic model/HIR, compiler behavior, and scoped reconstruction belong to opy-rs.
• DEL/OSTW source/runtime semantics belong to del-rs.
• Wright owns orchestration, diagnostics aggregation, lint/analyze/inspect, source-edit product behavior, LSP/CLI/agent surfaces, and cross-language integration.
• language-provider-protocol is an integration/process protocol, not a language-semantic owner.
• Missing semantics must be fixed in the owning repository rather than compensated for in Wright.

Current integration note

opy-rs PR #61 introduced wright/opy-hir@2.0.0 for the ordered switch-arm HIR contract and explicitly rejects v1 payloads. Wright-side OPY consumer cutover must adopt the owner contract rather than adding compatibility semantics back into opy-rs. Coordinate this with the active ownership/terminology cleanup (wright#227, opy-rs#62) without letting architecture cleanup outrank #42 semantic convergence.

Compatibility and conversion direction

• Target observable/canonical semantic equivalence, not generated-text, temporary-variable, formatter, or optimizer-internal identity.
• Workshop remains the canonical normalization hub for source-language compilation and reconstruction workflows.
• Source-preserving edits follow semantic understanding → validated source edits → original source; full-file regeneration is not the default mutation model.
• Workshop→OPY/DEL reconstruction, where pursued, targets useful semantic reconstruction with explicit information-loss boundaries rather than literal source recovery.

Near-term direction

• complete opy-rs#42, then close [M5] Integrate native Workshop input with semantic analysis and tools #36 if its corpus/evidence gate is satisfied;
• proceed to [M6] Define compiler/session driver contract #37 and [M6] Establish wright CLI and core workflows #38 to establish a public standalone OPY→Workshop compile workflow;
• keep Wright's OPY consumer integration aligned with the owner-side API/HIR contract as that implementation stabilizes;
• keep DEL compiler expansion secondary while OPY remains the focused convergence lane unless real-project evidence justifies reprioritization.

v1.0 product contract

Wright 1.0 is ready when users can rely on it as a stable Workshop tooling platform with:

• cross-platform installation/update;
• stable declared check, lint, analyze, inspect, source-edit/fix, conversion, and agent/embedding surfaces;
• canonical raw Workshop parsing/validation/emission through workshop-rs;
• evidence-backed OPY and DEL/OSTW workflows through independently usable owning implementations without hidden upstream runtime fallback for declared first-party support;
• validated source-oriented mutation with semantic refusal for unsafe operations;
• corpus-defined support claims and reproducible implementation/catalog identities;
• stable CI and machine-readable diagnostic/tool contracts;
• reviewed licensing/provenance/distribution boundaries;
• documentation sufficient for users without knowledge of internal compiler architecture.

Planning rules

• Real user workflows are the primary progress metric.
• Unit tests, snapshots, minimized fixtures, support matrices, and issue state are regression/planning evidence, not substitutes for rerunning motivating real projects.
• Keep near-term work concrete and evidence-driven; keep distant work coarse.
• Do not split catalog-scale work into per-symbol issues.
• Do not let architecture cleanup, protocol work, CLI polish, or documentation volume outrank missing engine semantics that block real tooling workflows.
• Repository code, living docs, issues, PRs, and public interfaces should use concrete capabilities/versions rather than temporary internal phase labels.