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
Command-Only Operations
The following are required as Commands (available to TS Client), but no longer needed as dances.
WritableHolon mutation operations:
Staging Operations
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
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:
Drop Descriptor Adapter Dances
Command-Only Operations
The following are required as Commands (available to TS Client), but no longer needed as dances.
WritableHolonmutation operations:remove_propertieswith_propertiesadd_related_holonsremove_related_holonsStaging Operations
abandon_staged_changesnew_holon_dancestage_new_from_clone_dancestage_new_holon_dancestage_new_version_danceThese 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
WritableHolonoperations were introduced before the execution/runtime architecture had fully stabilized. With the current model, these operations: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)
HolonReferenceWritableHolonmethods5. Scope and Impact (Required)
What does this impact?
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?)
7. Definition of Done (Required)
This enhancement is complete when:
WritableHolonmutation APIsOptional Details (Expand if needed)
8. Alternatives Considered
These were rejected in favor of a clearer separation between local mutation and distributed execution.
9. Risks or Concerns
10. Additional Context
This aligns with the emerging architectural distinction: