Roadmap to v1.0: stable Workshop tooling platform #134

Goal

Define Wright's path to 1.0 by stable product capabilities, ownership boundaries, and evidence-backed user workflows rather than internal migration phases or a manually maintained progress ledger.

Product direction

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

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 where required by real workflows

Compiler and conversion work are product-enabling infrastructure, not the sole progress metric. A Wright surface must not claim language behavior beyond what its owning implementation actually supports.

Ownership and dependency rules

• Raw Workshop semantics, catalog, settings, WIR, localization, validation, and emission belong to workshop-rs.
• OPY syntax, preprocessing/macros, semantic HIR, diagnostics/provenance, lowering/tooling, and scoped reconstruction belong to opy-rs.
• DEL/OSTW project loading, syntax/type/runtime semantics, semantic HIR, diagnostics/provenance, lowering/tooling, and scoped reconstruction belong to deltin-rs.
• Wright owns cross-language diagnostics, lint/analyze/inspect, validated edit product behavior, CLI/LSP/agent surfaces, embedding, CI, and orchestration.
• language-provider-protocol owns process/wire integration contracts, not source-language semantics.
• Missing semantics must be fixed in the owning repository rather than compensated for in Wright.

For cross-repository work, use:

owning repo -> owner contract/tests -> consumable contract/release -> consumer integration -> boundary/real-workflow verification

Compatibility and source transformation

• Target observable/canonical semantic equivalence, not generated-text, temporary-variable, formatter, optimizer, or internal-IR identity unless one of those is an explicit contract.
• Workshop is the canonical normalization hub for source-language compilation and reconstruction workflows.
• Source mutation follows semantic understanding -> validated source edits -> original source; full-file regeneration is not the default model.
• Workshop -> OPY/DEL reconstruction targets useful semantic equivalence with explicit information-loss boundaries rather than literal source recovery.
• Known gaps remain explicit; the existence of a command or integration surface does not imply unsupported owner semantics are available.

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 and update;
• stable declared check, lint, analyze, inspect, source-edit/fix, conversion, and agent/embedding surfaces;
• canonical raw Workshop parsing, validation, and emission through workshop-rs;
• evidence-backed OPY and DEL/OSTW workflows through independently usable owning implementations, without Wright-side semantic fallbacks 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, and distribution boundaries;
• user documentation that does not require knowledge of internal compiler architecture.

Planning rules

• Real user workflows and provenance-linked corpus evidence drive priority.
• Fix root capabilities in the owning implementation before integration-layer workarounds.
• Unit tests, snapshots, minimized fixtures, support matrices, issue state, and PR state are evidence/planning inputs, not substitutes for rerunning motivating workflows.
• Keep near-term executable work in child issues; keep this roadmap focused on durable product and prioritization contracts.
• Do not split catalog-scale work into per-symbol issues.
• Do not let architecture cleanup, protocol work, CLI polish, documentation volume, or dependency churn outrank missing engine semantics that block real tooling workflows.

Non-goals

• Maintaining a current-progress dashboard in this issue body.
• Encoding transient release versions, active blockers, current child-issue state, or near-term execution ordering here.
• Using roadmap completion as evidence that an owning implementation or user workflow is actually supported.

Current execution state should be derived from GitHub Issues/PRs/releases, CI, corpus evidence, and real-workflow verification rather than copied into this roadmap.