deterministic-scenario-engine 1.0.0__tar.gz → 2.1.0__tar.gz

{deterministic_scenario_engine-1.0.0 → deterministic_scenario_engine-2.1.0}/MANIFEST.in

@@ -4,6 +4,7 @@ include pyproject.toml
 recursive-include src *.py
 recursive-include docs *.md
 recursive-include examples *.yaml
+include examples/phase3_ecommerce_evidence.py
 recursive-include tests *.py
 global-exclude *.py[cod]
 global-exclude __pycache__

{deterministic_scenario_engine-1.0.0/src/deterministic_scenario_engine.egg-info → deterministic_scenario_engine-2.1.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: deterministic-scenario-engine
-Version: 1.0.0
+Version: 2.1.0
 Summary: Reproducible, state-consistent business scenarios with deterministic ground truth
 License-Expression: Apache-2.0
 Keywords: deterministic,scenario,testing,fixtures,replay
@@ -33,8 +33,13 @@ Dynamic: license-file
 
 **Generate test scenarios, not just test records.**
 
-Deterministic Scenario Engine creates reproducible, state-consistent business
-histories with deterministic ground truth for testing.
+Deterministic Scenario Engine (DSE) creates reproducible, state-consistent
+business histories and deterministic scenario suites with ground truth for
+testing. The published distribution is `deterministic-scenario-engine` 2.0.0.
+Phase 3 evidence-interchange capabilities are implemented on `main` and the
+current source release candidate reports distribution version 2.1.0, while 2.1.0
+is not published. Its deterministic compatibility version remains
+`ENGINE_VERSION == "1.0.0"`, and its DSL version remains integer 1.
 
 ## Why it exists
 
@@ -58,9 +63,22 @@ make expected behavior explicit.
 - an explicit, versioned plugin boundary and a reference ecommerce plugin pack
 - a JSON-file adapter
 - optional pytest, SQLAlchemy Core, Hypothesis, and Schemathesis integrations
+- secure, explicit local-file composition with namespaced modules
+- ordered Cartesian matrices with stable case IDs and original indexes
+- immutable ordered batch plans and worker-independent results
+- structured, redacted inspect/explain evidence and typed RFC 6901 semantic diff
+- twelve-command `scenario` CLI for local and CI workflows, including bounded
+  local evidence export, verification, and lossless migration
+- explicit immutable Domain Pack registries and pure Oracle Assertions
+- canonical evidence bundles, ordered JSON/JSONL export, compatibility reports,
+  explicit adapters, closed lossless migrations, and fixture-directory export
 
 Core execution does not require a database, network service, plugin, or property
 testing framework. See [security assumptions and non-goals](docs/security-and-non-goals.md).
+Neither Phase 2 nor Phase 3 adds hidden discovery, network, randomness,
+wall-clock, or ambient environment semantics. The historical Phase 2 contract
+is frozen in the [Phase 2 public contract](docs/phase2-public-contract.md); the
+additive evidence surface is frozen in the [Phase 3 public contract](docs/phase3-public-contract.md).
 
 ## Installation
 
@@ -80,7 +98,7 @@ Install only the named optional integrations you need:
 /tmp/scenario-engine-docs-venv/bin/python -m pip install '.[schemathesis]'
 ```
 
-The distribution is `deterministic-scenario-engine` 1.0.0. Install the package
+The published distribution is `deterministic-scenario-engine` 2.0.0. Install the package
 with `pip install deterministic-scenario-engine`, or select an optional integration
 with a command such as `pip install 'deterministic-scenario-engine[pytest]'`.
 
@@ -139,8 +157,14 @@ Unsupported cross-version replay fails explicitly. See the [determinism model](d
 - [Public Python API](docs/api.md)
 - [Security assumptions and non-goals](docs/security-and-non-goals.md)
 - [Compatibility contract](docs/compatibility.md)
+- [Phase 2 public contract, CLI, and hard bounds](docs/phase2-public-contract.md)
+- [Phase 3 public contract and evidence interchange](docs/phase3-public-contract.md)
 
 ## Status
 
-The distribution and engine compatibility version are both 1.0.0. The project is
-licensed under Apache-2.0.
+Distribution release identity and deterministic engine compatibility are
+separate contracts. Version 2.0.0 has been published to PyPI and as a GitHub
+Release. This source tree reports the unpublished 2.1.0 release candidate;
+generated core manifests retain `ENGINE_VERSION` 1.0.0 and DSL 1. No 2.1.0 tag,
+GitHub Release, or package-index publication exists. The project is licensed
+under Apache-2.0.

{deterministic_scenario_engine-1.0.0 → deterministic_scenario_engine-2.1.0}/README.md

@@ -2,8 +2,13 @@
 
 **Generate test scenarios, not just test records.**
 
-Deterministic Scenario Engine creates reproducible, state-consistent business
-histories with deterministic ground truth for testing.
+Deterministic Scenario Engine (DSE) creates reproducible, state-consistent
+business histories and deterministic scenario suites with ground truth for
+testing. The published distribution is `deterministic-scenario-engine` 2.0.0.
+Phase 3 evidence-interchange capabilities are implemented on `main` and the
+current source release candidate reports distribution version 2.1.0, while 2.1.0
+is not published. Its deterministic compatibility version remains
+`ENGINE_VERSION == "1.0.0"`, and its DSL version remains integer 1.
 
 ## Why it exists
 
@@ -27,9 +32,22 @@ make expected behavior explicit.
 - an explicit, versioned plugin boundary and a reference ecommerce plugin pack
 - a JSON-file adapter
 - optional pytest, SQLAlchemy Core, Hypothesis, and Schemathesis integrations
+- secure, explicit local-file composition with namespaced modules
+- ordered Cartesian matrices with stable case IDs and original indexes
+- immutable ordered batch plans and worker-independent results
+- structured, redacted inspect/explain evidence and typed RFC 6901 semantic diff
+- twelve-command `scenario` CLI for local and CI workflows, including bounded
+  local evidence export, verification, and lossless migration
+- explicit immutable Domain Pack registries and pure Oracle Assertions
+- canonical evidence bundles, ordered JSON/JSONL export, compatibility reports,
+  explicit adapters, closed lossless migrations, and fixture-directory export
 
 Core execution does not require a database, network service, plugin, or property
 testing framework. See [security assumptions and non-goals](docs/security-and-non-goals.md).
+Neither Phase 2 nor Phase 3 adds hidden discovery, network, randomness,
+wall-clock, or ambient environment semantics. The historical Phase 2 contract
+is frozen in the [Phase 2 public contract](docs/phase2-public-contract.md); the
+additive evidence surface is frozen in the [Phase 3 public contract](docs/phase3-public-contract.md).
 
 ## Installation
 
@@ -49,7 +67,7 @@ Install only the named optional integrations you need:
 /tmp/scenario-engine-docs-venv/bin/python -m pip install '.[schemathesis]'
 ```
 
-The distribution is `deterministic-scenario-engine` 1.0.0. Install the package
+The published distribution is `deterministic-scenario-engine` 2.0.0. Install the package
 with `pip install deterministic-scenario-engine`, or select an optional integration
 with a command such as `pip install 'deterministic-scenario-engine[pytest]'`.
 
@@ -108,8 +126,14 @@ Unsupported cross-version replay fails explicitly. See the [determinism model](d
 - [Public Python API](docs/api.md)
 - [Security assumptions and non-goals](docs/security-and-non-goals.md)
 - [Compatibility contract](docs/compatibility.md)
+- [Phase 2 public contract, CLI, and hard bounds](docs/phase2-public-contract.md)
+- [Phase 3 public contract and evidence interchange](docs/phase3-public-contract.md)
 
 ## Status
 
-The distribution and engine compatibility version are both 1.0.0. The project is
-licensed under Apache-2.0.
+Distribution release identity and deterministic engine compatibility are
+separate contracts. Version 2.0.0 has been published to PyPI and as a GitHub
+Release. This source tree reports the unpublished 2.1.0 release candidate;
+generated core manifests retain `ENGINE_VERSION` 1.0.0 and DSL 1. No 2.1.0 tag,
+GitHub Release, or package-index publication exists. The project is licensed
+under Apache-2.0.

{deterministic_scenario_engine-1.0.0 → deterministic_scenario_engine-2.1.0}/docs/api.md

@@ -1,12 +1,15 @@
 # Public Python API
 
-This is the canonical top-level Phase 1.0 contract. Importable implementation
-symbols not listed here are not implicitly promoted to top-level public API.
+This is the canonical top-level Phase 1.0 contract, preserved unchanged by the
+Phase 2 and Phase 3 freezes. Importable implementation symbols not listed here
+are not implicitly promoted to top-level public API. Specialized APIs are public
+through the explicit subpackages documented below, not package-root convenience
+exports.
 
 ## Constants and value objects
 
 - `ENGINE_VERSION` — engine compatibility version recorded in manifests; for
-  the 1.0 release candidate it intentionally equals distribution version 1.0.0.
+  current manifests it remains 1.0.0 independently of distribution version.
 - `MISSING` — singleton semantic missing value, distinct from null.
 - `LogicalID(value: str)` — deterministic logical identifier value; users
   normally receive it from `$id` generation.
@@ -151,3 +154,70 @@ These are explicitly separate from the top-level contract:
 
 Internal dataclass field layouts beyond frozen normalized result/manifest schemas
 are not promised. See [compatibility](compatibility.md).
+
+## Phase 2 public subpackages
+
+The complete machine-frozen names are each subpackage's `__all__`; these import
+paths are stable while helpers outside `__all__` are intentionally internal.
+
+- `scenario_engine.suite` — versioned run/suite/matrix/batch manifests and
+  bounded non-executing v1 result/manifest readers.
+- `scenario_engine.composition` — `ComposedSuite`, `load_composed_suite()`,
+  `execute_composed_suite()`, hashes, frozen bounds, and composition errors.
+- `scenario_engine.matrix` — `MatrixDimension`, `MatrixPlan`, expansion,
+  selection and execution with ordered Cartesian semantics, stable case IDs,
+  and retained original Cartesian indexes.
+- `scenario_engine.batch` — immutable `RunRequest`/`BatchPlan`, ordered
+  `execute_batch()`/`stream_batch()` results, stable failures, and bounds.
+- `scenario_engine.inspection` — immutable inspection/explanation documents,
+  read-only normalization, canonical serializers, and default secret redaction.
+- `scenario_engine.diff` — typed `SemanticDiff`/`DiffRecord` values using RFC
+  6901 paths, deterministic `first`/`complete` modes and prefix truncation.
+- `scenario_engine.cli` — `CLIExitCode` and `main`; command behavior is in the
+  [Phase 2 public contract](phase2-public-contract.md#cli-contract).
+- `scenario_engine.domain_packs` — immutable declarative `DomainPack` values,
+  caller-created `DomainPackRegistry`, exact deterministic resolution, semantic
+  identity, and declarative plugin requirements. There is no discovery, global
+  registry, or pack dependency mechanism.
+- `scenario_engine.oracle_assertions` — pure post-result structured assertion
+  models, evaluation, serializers, outcomes, and bounds; evaluation never reruns
+  or replays a scenario.
+
+The schema/version constants and all exact export manifests are executable
+contract tests. See the [complete Phase 2 contract](phase2-public-contract.md).
+
+## Phase 3 evidence APIs
+
+Phase 3 adds no package-root names. Its stable APIs are the names in `__all__`
+of `scenario_engine.evidence` and `scenario_engine.reference_packs`; helpers in
+their implementation modules are intentionally internal. Typical imports are:
+
+```python
+from scenario_engine.evidence import (
+    ArtifactDescriptor,
+    EvidenceBundle,
+    EvidenceEntry,
+    EvidenceProvenance,
+    EvidenceRelationship,
+    EvidenceType,
+    compatibility_report,
+    export_evidence_bundle,
+    plan_migration,
+    read_evidence_bundle,
+)
+from scenario_engine.reference_packs import (
+    EcommerceEvidenceWorkflow,
+    ecommerce_domain_pack,
+    export_ecommerce_evidence,
+)
+```
+
+The evidence subpackage exposes immutable bundle/entry/relationship/provenance
+models and canonicalization; bounded local reading and atomic export; canonical
+JSON/JSONL records; explicit adapter capability/publication/receipt contracts;
+finite compatibility reports and metadata-only migration plans; six closed,
+lossless executable wrapper routes; and deterministic fixture-directory export.
+`scenario_engine.reference_packs` exposes the ecommerce demonstrator and its
+existing registry factory, not a generic workflow framework. The exact public
+names, errors, schemas, limits, and compatibility posture are normative in the
+[Phase 3 public contract](phase3-public-contract.md).

{deterministic_scenario_engine-1.0.0 → deterministic_scenario_engine-2.1.0}/docs/determinism.md

@@ -71,5 +71,27 @@ declarative derivations are dependency-resolved rather than source-key ordered.
 Canonical JSON uses sorted mapping keys. Do not use mapping insertion order to
 encode business sequencing; use an ordered DSL list.
 
+Phase 2 composition resolves modules by explicit alias and hashes semantic
+content without physical paths. Matrix order is declaration-order Cartesian
+order with the last dimension changing fastest; retained cases keep their
+original pre-filter index. Batch members have independent execution contexts and
+results are emitted in plan order regardless of worker completion. Inspection,
+diff, and assertion evaluation are pure consumers of immutable normalized
+evidence. Worker scheduling, filesystem enumeration, host paths, locale defaults,
+environment variables, network responses, and process history are not semantic
+coordinates.
+
+Phase 3 evidence identity is the SHA-256 of canonical bundle index bytes. Entries
+bind explicit artifact paths, sizes, schemas, and content SHA-256 values;
+canonical export preserves those bytes and publishes an absent destination
+atomically. JSONL records follow caller order. Compatibility reports and
+migration plans use finite tables and deterministic canonical bytes; migration
+results bind source/target hashes and an ordered transformation tuple. Fixture
+IDs are explicit and stable, adapter receipts retain submission ordinal, and the
+ecommerce reference bundle identity is independent of destination path and
+worker scheduling. None of these downstream identities changes Phase 2 result
+or manifest semantics.
+
 See [reproducibility](reproducibility.md) for recorded context and
-[compatibility](compatibility.md) for the normative replay contract.
+[compatibility](compatibility.md) for the normative replay contract, and the
+[Phase 3 public contract](phase3-public-contract.md) for evidence identity.