Freeze the workshop-rs public API for 1.0

[Teakowa]

Goal

Freeze the supported workshop-rs Rust API so the crate can move to 1.0 with a small, Workshop-domain-first contract that downstream consumers can depend on under normal semver expectations.

Context

The canonical Program boundary has converged around ordinary Workshop concepts (Program, Rule, Event, Condition, Action, Value, variables, subroutines, and settings), while WIR/storage remains an implementation detail for normal consumers.

The repository already protects public API compatibility with cargo-semver-checks, stable/MSRV quality gates, catalog checks, and real-project parser/emitter/locale scenarios. The remaining 1.0 work is therefore not a new stability framework or a broader feature roadmap. It is a bounded review of public surface that is already known to contain migration facades, unsettled analysis identity, superseded verification vocabulary, metadata-shaped semantic details, or externally extensible closed Rust enums.

1.0 should mean that the supported Rust contract is intentionally stable. It does not require every future Workshop feature, seasonal live-client validation run, or downstream product milestone to be complete.

Release gate decisions

• workshop-rs-cli, opy-rs, and Wright must verify the 1.0 candidate through their owned integration/workflow tests before release.
• deltin-rs is a post-1.0 validation lane and does not block the workshop-rs 1.0 release.
• 1.0 stability applies to the entire intentional ordinary public crate surface, not only the core Program API. Public items retained in the candidate are treated as normal 1.x semver contracts unless they are removed or made non-public before release.
• Experimental or migration-only APIs must not remain as ordinary public surface with an informal "unstable" promise.

Scope

• Treat the canonical public Program model and ordinary parse/validate/emit flow as the stable center; do not redesign them without a concrete correctness or consumer requirement.
• Resolve legacy compatibility facades that should not become permanent 1.x contracts.
• Complete Stabilize the per-node element count API for tooling consumers #251 so structured element-count results no longer expose accidental WIR/storage identity as the consumer contract.
• Remove or rename superseded generic evidence/provenance vocabulary from public settings/gameplay APIs where concrete source attribution, source mapping, dataset identity, or licensing facts are the actual contract.
• Audit catalog fields that expose implementation-oriented semantic metadata and retain only public data/behavior consumers actually need.
• Audit public enums and identities whose domain can grow with Overwatch so 1.x can add canonical Workshop concepts without avoidable downstream breakage.
• Verify the resulting candidate with existing public API tests, semantic tests, real-project tests, cargo-semver-checks, and downstream owner workflows before releasing 1.0.

Non-goals

• Redesigning the canonical Program model for architectural elegance.
• Replacing WIR or internal parser/emitter implementation solely for 1.0.
• Completing Establish a tests-first Workshop corpus and seasonal feature census #10 or Establish the seasonal live-client Workshop validation and structured-diff workflow #21 as a prerequisite for Rust API stability.
• Adding a new stability database, API schema, compatibility framework, or release process when existing semver CI is sufficient.
• Moving OPY, DEL/OSTW, or Wright-owned semantics into workshop-rs.
• Freezing every internal module or undocumented implementation detail.

Acceptance criteria

• Every intentionally supported public module/type/function is classified as a durable 1.x contract rather than retained accidentally for migration.
• Stabilize the per-node element count API for tooling consumers #251 is complete and the public element-count contract does not require consumers to understand WIR arena/storage identity.
• Public settings/gameplay terminology matches the current tests-first/source-attribution contract rather than the superseded generic evidence/provenance model.
• Public catalog API does not expose semantic implementation metadata without a demonstrated consumer contract.
• Public externally evolving domains have an explicit 1.x-compatible representation strategy.
• Existing parse/validate/emit, catalog, localization, settings, gameplay, semantic analysis, and real-project tests pass without weakened assertions.
• cargo-semver-checks remains a required CI gate for post-1.0 compatibility.
• workshop-rs-cli, opy-rs, and Wright consume and verify the release candidate through their owned relevant workflows without requiring a new workshop-rs architecture or duplicated Workshop semantics; deltin-rs remains non-blocking post-1.0 validation.
• Every ordinary public item retained in the 1.0 candidate is intentionally accepted as a normal 1.x semver contract; migration-only or experimental surfaces are removed or made non-public before release.

Dependencies / ownership

• Owner: workshop-rs for canonical Workshop public contracts and the 1.0 crate release.
• Existing required work: Stabilize the per-node element count API for tooling consumers #251.
• opy-rs, deltin-rs, and Wright own their downstream integration/workflow verification and must not be reimplemented here.
• Establish a tests-first Workshop corpus and seasonal feature census #10/Establish the seasonal live-client Workshop validation and structured-diff workflow #21 remain independent tests/client-validation work and are not automatically release blockers for the Rust 1.0 API.