Skip to content

Route public Workshop operations through the canonical Program API #179

Description

@Teakowa

Parent: #112
Depends on: #177, #178

Goal

Make the canonical public Program API the shared boundary for raw parsing, validation/analysis, conversion/editing, emission, and the CLI, then retire accidental compatibility/storage exposure before the 1.0 freeze.

Scope

  • Make raw Workshop parsing produce the canonical public Program model.
  • Make validation, Workshop-owned analysis, conversion/source-aware editing, and emission consume that same public model.
  • Keep workshop-rs-cli on the ordinary public library boundary.
  • Audit crate/module visibility and remove or explicitly classify compatibility re-exports, arena/storage surfaces, generator/catalog-authoring tables, census/test support, and CLI helper modules that are not intended 1.0 contracts.
  • Review public error/category/source access needed by machine consumers under the canonical API.
  • Add concise public documentation showing both raw Workshop parse/emit use and independent-language construction/lowering into the same Program model.

Non-goals

  • Rewriting parser/emitter algorithms for style or file size.
  • Consumer-specific OPY/DEL/Wright migration.
  • Enabling the post-1.0 semver gate before the candidate surface is accepted.
  • Unrelated repository cleanup.

Acceptance criteria

  • Parse, validate/analyze, edit/convert, and emit operate through one public Program contract.
  • The CLI does not depend on privileged private or compatibility-only library surfaces.
  • Ordinary crate navigation is organized around Workshop concepts and operations rather than repository extraction history.
  • Storage/generator/test-support APIs are no longer accidentally frozen as ordinary public contracts.
  • Public docs demonstrate the canonical program model without requiring knowledge of WIR storage internals.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions