Skip to content

Drop Obsolete Dance Implementations methods #388

@evomimic

Description

@evomimic

1. Summary (Required)

Under our new Conductora/Tauri architecture, it no longer makes sense to push any HolonReference or staging operations to the Guest. These can (and should) all be done locally within the host. This enhancement simplifies our code base and reduces on-going maintenance burden by deleting the dance implementations for obsolete dances.

NOTE:

  • we still need Commands for these functions and native implementations
  • this enhancement is ONLY deleting the dances, NOT the underlying native functionality.

Drop Descriptor Adapter Dances

  • Drop "load_core_schema" -- we now just use standard holons loader to load BOTH schema and holons

Command-Only Operations

The following are required as Commands (available to TS Client), but no longer needed as dances.

WritableHolon mutation operations:

  • remove_properties
  • with_properties
  • add_related_holons
  • remove_related_holons

Staging Operations

  • abandon_staged_changes
  • new_holon_dance
  • stage_new_from_clone_dance
  • stage_new_holon_dance
  • stage_new_version_dance

These operations should be performed directly as context-local mutations on staged holons rather than modeled as top-level dances.


2. Problem Statement (Required)

Dances for WritableHolon operations were introduced before the execution/runtime architecture had fully stabilized. With the current model, these operations:

  • Do not cross trust boundaries
  • Do not require routing, orchestration, or promise semantics
  • Operate purely on already-staged, locally-held holons

Modeling them as dances adds unnecessary ceremony, misleading request/response contracts, and test complexity (e.g., unused fields, fabricated values).


3. Dependencies (Required)

Does this depend on other issues or features?


4. Proposed Solution (Required)

  • Deprecate and remove the listed dances.
  • Update callers (tests, fixtures, executors) to:
    • Resolve the staged HolonReference
    • Apply mutations directly via WritableHolon methods
  • Retain dances only for operations that:
    • Cross execution boundaries
    • Require routing, persistence, or promise enforcement

5. Scope and Impact (Required)

What does this impact?

  • Dance APIs and request/response types for the listed operations
  • Test harness executors and fixtures that currently invoke these dances
  • Documentation around supported dance operations

No impact on core holon data model or persistence semantics.


6. Testing Considerations (Required)

TBD -- consider implications on existing dance test language (e.g., can these steps simply be dropped?)

  • (Remaining) existing tests should continue to pass after being updated to use direct mutations.
  • No new behavioral tests required; this is a refactor/simplification.
  • Test coverage should confirm:
    • Mutations still occur correctly on staged holons
    • Commit behavior remains unchanged

7. Definition of Done (Required)

This enhancement is complete when:

  • The listed dances are removed or fully deprecated
  • All internal callers and tests use direct WritableHolon mutation APIs
  • No test requires fabricating unused values for mutation operations
  • Documentation reflects the reduced dance surface

Optional Details (Expand if needed)

8. Alternatives Considered

  • Retaining dances with redesigned request shapes (e.g., name-only).
  • Keeping dances for symmetry with other operations.

These were rejected in favor of a clearer separation between local mutation and distributed execution.


9. Risks or Concerns

  • Temporary churn in test code during migration.
  • Need to ensure no external callers rely on these dances.

10. Additional Context

This aligns with the emerging architectural distinction:

  • Dances = cross-boundary, promise-mediated operations
  • WritableHolon methods = local, staged mutations

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions