Skip to content

Support Schema-First Domain Fixtures in Sweetests #447

@evomimic

Description

@evomimic

1. Summary (Required)

What is the enhancement?
Add support for schema-first domain fixtures in sweetests by introducing a first-class zero-argument preset step for a known test domain schema.

This will let schema-sensitive fixtures load small domain schema artifacts through the existing loader-client/import path instead of manually constructing descriptor and relationship topology in Rust fixture code.


2. Problem Statement (Required)

Why is this needed?
Schema-sensitive sweetests currently rely too heavily on Rust-side graph assembly for mini domain schemas.

This creates several problems:

  • Descriptor topology, declared relationships, and inverse relationships are hand-built in Rust instead of expressed as schema artifacts
  • Fixtures become harder to read because schema intent is mixed with imperative setup mechanics
  • Tests validate runtime behavior against synthetic fixture graphs rather than imported schema inputs
  • There is no idiomatic way for a fixture author to say:
    • “load this known test domain schema before running the rest of the case”

After LoadCoreSchema, the next gap is small domain schemas. Without a schema-first pattern for those, descriptor-sensitive and relationship-sensitive tests will continue to depend on handcrafted setup.


3. Dependencies (Required)

Does this depend on other issues or features?
Yes.

This issue depends on the completion of #446 because it is intended to build on the same internal loader-client/import helper path and preset-step pattern.

Specifically, this follow-on work assumes:

  • a first-class zero-argument schema preload step exists
  • schema artifact resolution is encapsulated by internal helper/preset infrastructure
  • expected loader metrics are owned by the step/preset rather than by fixture authors
  • domain-schema preload steps can compose cleanly with LoadCoreSchema

This issue should not depend on descriptor abstraction work in production runtime code.


4. Proposed Solution (Required)

How would you solve it?
Introduce a first-class zero-argument preset step for a specific test domain schema.

The initial domain schema should be a small Book/Person relationship schema suitable for declared and inverse relationship tests. It should represent the schema intent currently hand-built in Rust fixtures: Book/Person types, a declared authored-by-style relationship, and its inverse relationship.

Examples of intended authoring experience:

test_case.add_load_core_schema_step(None)?;
test_case.add_load_book_person_test_schema_step(None)?;

High-level behavior:

  1. Define a standard repo location and format for small test domain schema artifacts
  2. Add internal preset/import helpers that:
    • resolve the import files for the known test schema
    • build the ContentSet
    • own the expected loader metrics for that schema import
  3. Add a first-class sweetest step variant and adder for the test schema
  4. Add a corresponding executor that reuses the existing loader-client/import path
  5. Replace or mirror at least one representative Rust-built schema setup with imported schema artifacts

Design constraints:

  • public test steps should be zero-argument presets for known test schemas
  • fixtures should not supply raw file paths, file contents, or manual expected load counts
  • schema loading and test data loading should remain separate steps
  • domain schema loading should be intended to run after LoadCoreSchema, since domain schemas may reference MAP core schema holons
  • the step should reuse existing loader-client/import infrastructure rather than introducing a second schema-loading mechanism
  • this issue should stay focused on a small preset test schema, not a generic public “load arbitrary schema files” step

5. Scope and Impact (Required)

What does this impact?
Primary impact areas:

  • sweetest step vocabulary
  • fixture-phase adders and execution-phase executors
  • internal schema/import helper infrastructure
  • organization of test domain schema artifacts
  • authoring patterns for schema-sensitive fixtures

Expected benefits:

  • schema-sensitive fixtures become clearer and more declarative
  • domain schema intent lives in import artifacts rather than imperative Rust setup
  • inverse and descriptor-sensitive behavior is tested against imported schema inputs
  • future schema-backed fixture migrations become easier and more consistent

Out of scope:

  • full migration of all existing schema-sensitive fixtures
  • a generic public arbitrary-schema-loading test step
  • descriptor abstraction changes in production runtime code
  • changing MAP schema semantics
  • converting non-schema-sensitive fixtures unless they need schema-specific assertions

6. Testing Considerations (Required)

How will this enhancement be tested?

  • Add at least one small imported domain schema artifact used by a sweetest fixture
  • Add or update at least one schema-backed fixture covering declared relationship behavior
  • Add or update at least one schema-backed fixture covering inverse relationship behavior
  • Confirm the new preset step reuses the existing loader-client/import path successfully
  • Confirm LoadCoreSchema and the domain-schema preset step compose cleanly in the same fixture and in the intended order
  • Validate deterministic file discovery/order for multi-file test domain schemas, if the initial schema uses multiple files
  • Confirm existing non-schema-sensitive sweetests remain unaffected

Regression considerations:

  • schema-backed fixtures should preserve the behavioral expectations currently covered by Rust-built schema setup
  • expected loader metrics for the preset schema should be centralized so schema changes are easy to diagnose
  • if a domain schema requires core schema holons, missing or misordered core-schema loading should fail clearly

7. Definition of Done (Required)

When is this enhancement complete?
This enhancement is complete when:

  • a first-class zero-argument preset step exists for a specific test domain schema
  • the step has a corresponding fixture-phase adder
  • the step has a corresponding execution-phase executor
  • the step reuses the same internal loader-client/import helper path established for LoadCoreSchema
  • the step owns its own import artifact resolution and expected loader metrics
  • fixture authors do not provide raw file paths or manual expected counts
  • a small Book/Person relationship test schema artifact is added in a standard location/format
  • the intended composition with LoadCoreSchema is documented or demonstrated in a fixture
  • at least one current Rust-built schema-sensitive setup is replaced or mirrored by a schema-backed equivalent
  • declared relationship behavior is covered by a schema-backed fixture
  • inverse relationship behavior is covered by a schema-backed fixture
  • existing sweetest behavior remains stable outside schema-aware fixtures

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions