Lifecycle-aware Dance Test Infrastructure for Transaction Semantics (Phase 1.3 Follow-up)

[owleyeview]

1. Summary

Harden the Dance Test Framework's commit and load_holons paths to correctly handle expected failures, and introduce lifecycle tracking so that Open → Committed transitions can be modeled and asserted.

---

2. Problem Statement

Phase 1.3 introduced explicit transaction lifecycle semantics (Open → Committed), but the sweettest framework has concrete defects that prevent testing lifecycle correctness:

Commit adder mints Saved tokens unconditionally. add_commit_step calls fixture_holons.commit() (which mints Saved tokens and advances heads) before the expected_status is ever consulted. If a test expects commit to fail, the fixture still transitions all Staged holons to Saved — diverging from what the executor will actually observe. (adders.rs:270, fixture_holons.rs:180-218)

Commit executor parses response body before branching on status. Lines 34-39 of commit_executor.rs unconditionally match the response body as HolonReference::Transient and panic on any other variant. The if response.status_code == OK guard doesn't start until line 43. If a failed commit returns a different body shape, the executor panics before the status check has any effect.

Commit executor panics on dance-level errors. Line 22 uses .expect("dance should succeed"), which panics if initiate_dance returns Err — even when the test expects failure.

Load_holons executor has no failure mode at all. execute_load_holons unconditionally parses the response body (line 194), reads all properties (lines 207-224), and asserts them with assert_eq! (lines 257-286). There is no expected-status parameter, no early return on failure, and no way to test a load that should be rejected.

No transaction lifecycle tracking. Neither FixtureHolons nor TestExecutionState tracks whether the transaction has been committed. The framework cannot model that mutations should be rejected after commit, or that a second commit should fail. Multiple commits work today only because guest-side code is idempotent — the test framework has no opinion about it.

---

3. Dependencies

• Depends on Phase 1.3 transaction lifecycle semantics being stable.
• May interact with future multi-transaction support.
• Does not require changes to production lifecycle APIs.
• Does not require host-ingress execution mode (Runtime/MapIpcRequest testing is a separate effort).

---

4. Proposed Solution

Address the concrete defects, then layer in lifecycle awareness.

4.1 — Fix commit adder failure-path handling

The commit adder must branch on expected_status before mutating fixture state. When failure is expected, fixture_holons.commit() should not be called — no Saved tokens minted, no heads advanced. The DanceTestStep::Commit variant should carry an empty saved_tokens vec for expected-failure steps.

4.2 — Fix commit executor body-parsing order

Move the response body match (lines 34-39) inside the if response.status_code == OK block. Replace the .expect("dance should succeed") with proper error handling that validates against expected status.

4.3 — Add expected-status support to load_holons

Add a ResponseStatusCode parameter to the load_holons adder and executor. On non-OK expected status, skip body parsing and property assertions. The adder should also skip any fixture state mutation on expected failure.

4.4 — Introduce fixture-level transaction lifecycle tracking

Add a lifecycle state (Open / Committed) to the fixture context or FixtureHolons. The commit adder should transition this state on expected-success commits. Subsequent mutation adders can then validate that the fixture transaction is still open, catching test-authoring errors at fixture construction time rather than at execution time.

4.5 — Add lifecycle assertion test fixtures

New fixtures that exercise:

• Commit with OK status → transaction becomes Committed
• Mutation step after commit → expected failure
• Second commit after first succeeds → expected failure
• Failed commit does not advance fixture state

---

5. Scope and Impact

What changes:

• adders.rs — commit and load_holons adder failure-path branching
• commit_executor.rs — body-parsing order, error handling
• load_holons_executor.rs — expected-status support
• fixture_holons.rs — conditional commit token minting
• Fixture context or FixtureHolons — lifecycle state field
• New test fixture(s) for lifecycle scenarios

What does not change:

• Production transaction lifecycle logic
• Existing sweettest fixtures (they all expect OK, so the branching is a no-op for them)
• The load_holons guest executor or dance implementation

---

6. Testing Considerations

Existing sweetests must pass unchanged — all current commit and load steps expect success, so the new failure-path branching should be inert for them.

New lifecycle fixtures should validate:

• Successful commit transitions fixture state to Committed
• Expected-failure commit leaves fixture state as Open and mints no Saved tokens
• Mutation adders reject steps when fixture transaction is Committed
• Commit executor handles non-OK status without panicking
• Load_holons executor handles non-OK status without panicking

---

7. Definition of Done

• Commit adder does not mint Saved tokens or advance heads when expected status is non-OK
• Commit executor handles non-OK responses without panicking (body parsing gated on status)
• Commit executor handles initiate_dance errors without panicking
• Load_holons adder/executor accept expected status and skip body parsing on non-OK
• Fixture-level transaction lifecycle state is tracked and transitions on successful commit
• Mutation adders validate that fixture transaction is still Open
• New lifecycle fixtures pass
• Existing sweetests pass unchanged

---