RFC: Unified runtime durability contract for signals, effects, and Bobravoz replay

[lanycrost]

Summary

The current runtime durability model is split across bounded StepRun.status rings, EffectClaim resources, process-local signal sequencing, and Bobravoz replay checkpoints. The result is one platform with several partial authorities instead of one declared durability contract.

Why this needs a discussion

This is not a single-repo cleanup. bobrapet already treats StepRun.status as a small status surface and already has a dedicated durable effect resource in EffectClaim, while the SDK and Bobravoz still carry replay/idempotency behavior that is only partially aligned with those controller-owned authorities.

Current evidence

• StepRun.status.signalEvents and StepRun.status.effects are bounded at MaxItems=256, which makes them summary surfaces rather than a durable replay ledger.
• StoryRun.spec.cancelRequested already exists as the controller-owned graceful stop path.
• EffectClaim already exists as a durable effect/idempotency resource.
• bubu-sdk-go/effects.go can still let completed EffectClaim state get ahead of the StepRun effect summary.
• bubu-sdk-go/signal_sequence.go and signal_replay.go still depend on process-local sequence state plus bounded status replay.
• bobravoz-grpc/internal/hub/stream_manager.go still uses a separate checkpoint model for replay restore instead of the same contract the SDK runtime would need for durable replay.

Proposed decisions

1. StepRun.status is a bounded summary/index surface only. It is not the durable source of truth for replay or idempotency.
2. EffectClaim becomes the durable authority for effect completion/idempotency. StepRun.status.effects remains a bounded operator-facing summary.
3. Signal replay must move to a controller-visible durable cursor/history model. Process-local signal sequence state is not an acceptable long-term contract.
4. Bobravoz replay must converge on the same cursor/retention model as SDK runtime replay instead of keeping a separate ad hoc checkpoint dialect.
5. Because the ecosystem is not released yet, we should not preserve the current truncated-status behavior as a backward-compatibility promise. Consumers should migrate directly to the new durable authorities before release.

Cross-repo scope

• bobrapet: owns the CRD/resource shape for durable cursors, claims, and summary-vs-history boundaries.
• bubu-sdk-go: writes summary status and participates in the durable effect/signal contract.
• bobravoz-grpc: aligns ingress replay/checkpoint behavior to the same durability model.
• core: carries shared contract helpers only; it should not become a second source of truth.

Desired outcome

One declared durability contract and ownership map so follow-up fixes in bubu-sdk-go and bobravoz-grpc land against the same replay/idempotency model instead of today’s mixed local conventions.