You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Goal
Remove
evidenceas 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-rscurrently groups census, conformance, live capture, and real-project support under oneevidencesource 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
evidencelabel 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
evidenceimplementation-domain boundary.Non-goals
evidencenamespace.evidence.Acceptance criteria
evidenceis no longer a standalone implementation-domain concept in the normal library source taxonomy.evidencegrouping.Dependencies / ownership
workshop-rsowns Workshop semantics, WIR, catalog/settings/localization facts, validation, emission, and the corresponding contract tests.