Define Workshop catalog, locale, provenance, and version boundaries

[Teakowa]

Goal

Define the durable data/version boundary for the canonical Workshop core: what is semantic code, what is catalog/content data, how locale coverage is represented, and how provenance/version identities are pinned.

Scope

• Define the boundary between Workshop language semantics and Workshop content/catalog data.
• Define locale-independent canonical identities for actions, values, events, enums, heroes, maps, game modes, settings, and other supported Workshop-defined content.
• Model locale tables as mappings from canonical identities to client spellings, not as separate language semantics.
• Use a strict catalog/allowlist model: supported definitions are explicit; unknown definitions are diagnosed rather than guessed.
• Define independent identities for workshop-rs implementation version, Workshop catalog/content dataset, locale coverage, and target Workshop/runtime evidence where available.
• Define provenance requirements and a reproducible catalog-update pipeline suitable for this repository's licensing policy.
• Define supported content/extension categories and behavior for missing target-locale spellings.
• Ensure tests/tooling can pin the effective catalog identity for reproducible results.

Initial product gate

The first usable multi-locale release should support a complete declared en-US <-> zh-CN raw Workshop conversion surface, then expand locale coverage through evidence-backed catalog updates.

Non-goals

• Wright/LPP/provider version coordination; those components own their own versions.
• Runtime downloading of unreviewed/latest catalog data by default.
• Treating unknown future Workshop tokens as valid semantics automatically.
• A generic plugin ABI or dynamic grammar system.
• OPY/DEL source-language semantics.
• Copying third-party catalog/source data without provenance/license review.

Acceptance criteria

• Semantic implementation and content/localization data have an explicit documented boundary.
• Canonical identities do not depend on client locale or source-language provider naming.
• Catalog/content and implementation versions can evolve independently and are machine-identifiable.
• Locale coverage and missing mappings are explicit and testable.
• Data-only Workshop updates can be added without compiler logic changes when they are genuinely data-only.
• The core implementation can consume this contract without duplicating locale/catalog knowledge in source-language providers.

[Teakowa]

Implemented by PR #3 (merged, commit 74f9667). ADR-0001 defines the durable data/version boundary: semantic-vs-catalog-data boundary, locale-independent canonical identities (actions/values/events/enums/heroes/maps/game modes/settings), locale tables as canonical-id -> client-spelling mappings, strict catalog/allowlist with unknown-definition diagnosis, four independent machine-identifiable versions (implementation/catalog+digest/locale-coverage/target-evidence), MIT-compatible provenance pipeline (OverPy GPL tables excluded), fail-explicit missing-locale behavior with opt-in fallback, test/tooling pinning, and the en-US <-> zh-CN first product gate. QA verified independently: 6/6 criteria. v0.2 acceptance criteria MET.