Roadmap to v1.0: stable Workshop tooling platform

[Teakowa]

Goal

Define Wright's pre-1.0 roadmap by user-visible release capabilities rather than internal phase numbers.

Release model

v0.1 — semantic/tooling baseline

Current implementation proves the core semantic/tooling model: Workshop/OPY/DEL-compatible workflows, conversion, language services, diagnostics, analysis, and validated source edits. This is an engineering baseline, not the 1.0 product contract.

v0.2 — provider boundary + canonical Workshop core

• wrightkit/language-provider-protocol owns a versioned LPP v1 contract and conformance suite.
• wrightkit/workshop-rs owns canonical Workshop semantics/catalog/WIR and standalone raw Workshop tooling.
• First declared multi-locale gate supports raw Workshop en-US <-> zh-CN conversion.
• Wright consumes the independent repositories through explicit versioned dependencies/contracts rather than keeping their canonical implementations solely in-tree.
• Wright proves provider-backed tooling through LPP without requiring a production OPY/DEL provider cutover yet.

Execution: #135.

v0.3 — OPY provider cutover

• wrightkit/opy-rs is a separately versioned first-party OPY implementation/provider.
• Standalone OPY CLI and LPP provider mode are usable.
• Wright production OPY workflows use the provider boundary instead of direct compiler-crate ownership.
• Existing declared compile/check/query/rename/edit behavior remains corpus-gated.

v0.4 — DEL/OSTW-compatible provider cutover

• wrightkit/del-rs is an independently implemented, provenance-audited DEL/OSTW-compatible provider.
• No mechanical translation or dependency on unlicensed compiler internals.
• Declared compile/query/refactoring capabilities are exposed through LPP.
• Wright production DEL workflows use the provider boundary.

v0.5 — architecture/licensing cleanup

• Wright no longer owns OPY/DEL compiler implementation crates in its production dependency graph.
• workshop-rs, LPP, source-language providers, and Wright have explicit independent version/license identities.
• Licensing/provenance documentation matches the actual repository/process boundaries.
• Provider conformance demonstrates that LPP is not hard-coded to OPY/DEL assumptions.

v0.6–v0.9 — product hardening

Do not pre-allocate architecture phases. Each release must deliver a user-visible improvement driven by real usage: lint/stability/cost analysis, semantic fixes, agent workflows, installation/update/distribution, performance, locale/catalog coverage, documentation, or compatibility-corpus growth.

v1.0 product contract

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

• cross-platform installation/update;
• stable declared check, lint, analyze, inspect, source-edit/fix, conversion, and agent/embedding surfaces;
• canonical raw Workshop parsing/validation/emission and supported cross-client-locale conversion through workshop-rs;
• OPY and DEL source workflows through first-party providers without upstream compiler runtimes for declared production workflows;
• documented/versioned LPP suitable for additional providers;
• validated atomic source-oriented mutation with semantic refusal for unsafe operations;
• corpus-defined support claims and reproducible content/provider identities;
• stable CI and machine-readable diagnostics/tool contracts;
• reviewed licensing/provenance/distribution boundaries;
• documentation sufficient for users without knowledge of internal compiler architecture.

Planning rules

• Repository code, living docs, new issues, PRs, and public interfaces use concrete capability names or release versions, not internal phase-number labels.
• Historical commits and closed discussions do not need rewriting solely for terminology.
• Version numbers are readiness gates, not a fixed quantity of internal work.
• Architecture-only work must be tied to the capability it enables.
• Compatibility/refactoring breadth is driven by real projects, tooling blockers, conformance, and declared semantic contracts—not symmetry.