Skip to content

Replace standalone evidence domain with contract tests and acquisition tooling #152

Description

@Teakowa

Goal

Remove evidence as a standalone implementation-domain abstraction and place correctness knowledge where it is actually owned: executable contract/regression tests, provenance-linked fixtures/corpus, and acquisition/tooling support.

For Workshop behavior that is already defined by official behavior/documentation, upstream/reference implementations, or provenance-linked real projects, tests may serve as the executable specification of that external contract. A separate in-crate evidence layer must not be treated as stronger proof of correctness.

Context

workshop-rs currently groups census, conformance, live capture, and real-project support under one evidence source tree. These components have different responsibilities and are grouped primarily by why they help establish confidence rather than by what they do.

That boundary can also blur an important distinction: an expectation derived independently from an external Workshop contract can validate an implementation, while a snapshot or fixture derived from the implementation itself mainly protects regression. Moving both behind an evidence label does not make them equally independent.

Correctness should remain grounded in external Workshop contracts and represented directly by the tests, fixtures, and tooling that exercise those contracts.

Scope

  • Remove the standalone evidence implementation-domain boundary.
  • Treat externally grounded tests as executable Workshop contracts where appropriate.
  • Keep implementation-derived snapshots/expectations identifiable as regression protection rather than independent language facts.
  • Place conformance and real-project verification with the test/integration surfaces they protect.
  • Place census, capture, and similar acquisition responsibilities with tooling or data-generation support rather than semantic implementation.
  • Preserve provenance for external fixtures, corpus cases, reference revisions, and real-project regressions close to the corresponding test/data.
  • Preserve existing meaningful conformance, corpus, and real-project verification coverage and CI gates.

Non-goals

  • Changing Workshop semantics, accepted syntax, WIR, diagnostics, emission, catalog facts, or supported behavior.
  • Weakening or deleting existing verification because it no longer lives under an evidence namespace.
  • Claiming that green tests alone prove the Workshop contract inventory is complete.
  • Introducing a new verification framework or replacement abstraction for evidence.
  • Reorganizing unrelated semantic domains or public APIs.

Acceptance criteria

  • evidence is no longer a standalone implementation-domain concept in the normal library source taxonomy.
  • Externally grounded language facts are represented by executable contract tests and/or provenance-linked fixtures without a duplicate evidence layer.
  • Implementation-derived expectations remain distinguishable from independent contract/reference expectations.
  • Conformance and real-project checks remain regression-green and retain their relevant provenance.
  • Acquisition/census/capture support is clearly tooling/data-support code rather than a semantic source domain.
  • No meaningful verification is weakened, duplicated, or replaced with self-derived expectations.
  • No new abstraction or dependency is introduced solely to replace the removed evidence grouping.

Dependencies / ownership

  • workshop-rs owns Workshop semantics, WIR, catalog/settings/localization facts, validation, emission, and the corresponding contract tests.
  • External Workshop/runtime behavior and reviewed upstream/reference behavior remain the source for externally grounded expectations.
  • This is a structural/testing-boundary follow-up to Reorganize workshop-rs internals around discoverable Workshop domains #149 and does not reopen its completed domain-locality work.

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