Core Schema Test Bootstrap

[evomimic]

Add LoadCoreSchema Test Step to the Dance Test Framework

1. Summary (Required)

What is the enhancement?
Add a first-class zero-argument LoadCoreSchema test step to the Dance Test Framework so schema-sensitive sweetests can declare MAP core schema as a standard precondition instead of hand-building schema topology in Rust fixtures.

This step should encapsulate both core schema artifact resolution and expected loader outcomes behind the test language.

---

2. Problem Statement (Required)

Why is this needed?
Schema-sensitive sweetests are currently too close to handcrafted Rust-side object graphs and too far from the way MAP is intended to operate in practice: with core schema loaded, descriptors present, and runtime behavior driven from imported schema artifacts.

This creates several problems:

• Fixtures that depend on descriptors or declared relationships must either:
  • wire schema graphs manually in Rust, or
  • duplicate loader/setup boilerplate
• Tests of inverse relationships and future descriptor-based behavior risk validating runtime code only against synthetic setup graphs
• There is no single, idiomatic way for a fixture author to say:
  • “this test should run with MAP core schema loaded first”

A dedicated LoadCoreSchema test step would make schema-aware setup part of the test language itself and create a consistent foundation for migrating schema-sensitive fixtures.

---

3. Dependencies (Required)

Does this depend on other issues or features?
This issue does not depend on descriptor abstraction work and should be able to proceed independently.

However, it is intended to support and unblock follow-on schema-aware test work, including:

• migration of schema-sensitive sweetest fixtures
• future first-class preset steps for specific test domain schemas
• future descriptor-sensitive runtime features that should be tested against imported schema rather than handcrafted topology

This issue should remain narrowly scoped to LoadCoreSchema, while laying internal groundwork for future schema-first preset steps.

---

4. Proposed Solution (Required)

How would you solve it?
Introduce a new global/precondition-style Dance Test step:

• LoadCoreSchema

This step should:

• be added to the DanceTestStep vocabulary as its own first-class variant
• have a corresponding fixture-phase adder
• have a corresponding execution-phase executor
• load MAP core schema through the existing loader-client/import path
• encapsulate the location of the core schema artifacts and the expected load metrics
• require no fixture-supplied file paths or manual expected counts

Expected authoring experience:

test_case.add_load_core_schema_step(None)?;

High-level behavior:

1. During execution, build the ContentSet needed to load MAP core schema
   • bootstrap import schema
   • all core schema JSON files
2. Execute the existing loader-client path through the harness/runtime
3. Validate known expected outcomes for the core schema load
   • staged holons
   • committed holons
   • links created
   • errors
   • bundle count
   • loader holon count

Internal design direction:

• keep the public step zero-argument and preset-specific
• keep file resolution and ContentSet construction in execution-side/internal helper code rather than fixture authoring code
• add internal reusable helper infrastructure for:
  • file/path resolution
  • ContentSet construction
  • centralized expected loader metrics
• structure that internal helper layer so future preset steps for specific test domain schemas can reuse it without introducing a generic public arbitrary-file-loading step

Design constraints:

• LoadCoreSchema should be zero-argument
• it should reuse existing loader infrastructure rather than invent a new schema-loading mechanism
• it should behave as a global environment/precondition step, not as a holon-targeted mutation step
• it should make schema-aware setup easier without forcing all sweetests to load schema by default
• fixture authors should not perform file I/O or build ContentSets directly for this step

This issue intentionally does not include public domain schema loading steps. That should be handled in a follow-on issue.

---

5. Scope and Impact (Required)

What does this impact?
Primary impact areas:

• sweetest harness step vocabulary
• test step adders and executors
• internal schema/import helper infrastructure
• schema-sensitive fixture authoring patterns
• migration path for descriptor-sensitive and relationship-sensitive sweetests

Expected benefits:

• fixture authors get a standard way to declare core schema as a test precondition
• schema-sensitive tests become more realistic and less reliant on Rust-side graph assembly
• core schema artifact resolution and expected metrics become centralized
• future migrations to schema-backed preset steps become easier

Out of scope for this issue:

• public domain schema import steps
• migration of all schema-sensitive fixtures
• descriptor abstraction layer implementation
• changes to production runtime schema-loading behavior outside the harness path already used by loader-based tests
• a generic public arbitrary-schema-loading test step

---

6. Testing Considerations (Required)

How will this enhancement be tested?

• Add at least one sweetest fixture that uses LoadCoreSchema successfully
• Validate that the step loads the expected core schema content and asserts the expected loader metrics
• Confirm that the step reuses the existing loader-client/import path successfully
• Confirm that existing non-schema-sensitive fixtures remain unaffected
• Validate that core schema file discovery/order is deterministic

Regression considerations:

• the new step should reuse the same loader-client behavior already exercised by existing loader-based tests
• expected core schema metrics should be centralized clearly so schema updates are easy to diagnose
• this step should serve as the precondition foundation for schema-first follow-on work

---

7. Definition of Done (Required)

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

• DanceTestStep includes a LoadCoreSchema variant
• a fixture-phase adder exists for LoadCoreSchema
• an execution-phase executor exists for LoadCoreSchema
• the step uses the existing loader/import path rather than a new schema-loading mechanism
• fixture authors can add core schema as a precondition with a single zero-argument step
• the step owns its own core-schema import artifact resolution and expected load metrics
• internal helper infrastructure exists for ContentSet construction and centralized expected metrics
• at least one sweetest case exercises the new step successfully
• existing sweetest behavior remains stable outside schema-aware fixtures

---

Optional Details (Expand if needed)

8. Alternatives Considered

What other solutions did you think about?

1. Add only a fixture helper, not a first-class step
   This would be quicker, but it would keep schema-aware setup as a convention rather than part of the Dance Test Framework vocabulary.

2. Make core schema implicit for all sweetests
   This would reduce fixture boilerplate, but it would broaden scope unnecessarily and impose schema-loading cost on tests that are not schema-sensitive.

3. Introduce a generic public schema-loading step immediately
   This would make the API more flexible up front, but it would push file-path and expected-metric concerns back toward fixture authors and make it harder to keep the test language simple.

4. Combine core schema and domain schema loading into a single parameterized public step immediately
   This is a possible long-term direction, but splitting LoadCoreSchema first keeps the first issue narrow and stable while still allowing shared internal groundwork.

---

9. Risks or Concerns

What could go wrong?

• Core schema counts may change over time, making the step brittle if expected values are not well centralized
• If implemented as a separate loading mechanism rather than a thin wrapper over existing loader-client behavior, harness complexity will grow unnecessarily
• If execution-time artifact discovery is not deterministic, failures may be confusing or environment-sensitive
• If the internal helper layer is made too generic too early, it may become harder to keep fixture authoring simple

---

10. Additional Context

Any supporting material?

This issue is intended as the first step in shifting schema-sensitive sweetests toward a schema-aware setup model:

• load core schema
• load specific test domain schema presets
• assert runtime behavior

A likely follow-on issue is:

• Support Schema-First Domain Fixtures

That later step would add first-class zero-argument preset steps for known test domain schemas using the same internal import/helper path established here.

---