Support Schema-First Domain Fixtures in Sweetests

[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 public MAP Commands LoadHolons ingress 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 preset-step pattern established for LoadCoreSchema.

It also depends on the completed #451 TransactionAction::LoadHolons contract change so public schema-import steps can load JSON artifacts through the public ContentSet ingestion path.

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
• public schema imports route through TransactionAction::LoadHolons { content_set }, which in turn uses holons_loader_client

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 dispatches public TransactionAction::LoadHolons { content_set }
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 the same public LoadHolons ingress path used by LoadCoreSchema
• the step should not use the internal LoadHolonsInternal sweetests path, which remains a lower-level guest-loader test surface
• 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
• public schema-import coverage through MAP Commands LoadHolons

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
• public schema loading coverage in sweetests better matches real import behavior

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
• replacing lower-level internal guest-loader tests that intentionally exercise LoadHolonsInternal

---

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 dispatches through public TransactionAction::LoadHolons { content_set } 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
• Keep lower-level LoadHolonsInternal tests separate so public schema-import coverage and internal guest-loader coverage remain clearly distinguished

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 dispatches through the same public TransactionAction::LoadHolons { content_set } path used by 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
• the schema-backed fixture uses the public schema-import route rather than LoadHolonsInternal
• existing sweetest behavior remains stable outside schema-aware fixtures