spec: an entity's immutability covers the collections composed into it

[delchev]

1.2 already made the default normative — "locksWithMaster defaults to true, so a child that says nothing keeps freezing with its master" — but it only ever spelled out what freezing means for the child declared locksWithMaster: false, where it is normative that the affordances must stay alive and not merely the writes. The default was left to be read as the affordances alone.

One implementation read it exactly that way: the child's own endpoint went on accepting creates, edits and deletes against a locked master, while its UI withheld them.

That is not a cosmetic gap. A child write maintains the master's derived values — a line resums the document's totals — so it reaches precisely what the lock protects, after the number was stamped, the frozen copy taken and the ledger entry posted from those totals. The lock is undone through a different door, and the document's own page then shows a total that disagrees with the copy it printed.

This says it in both directions instead: the default freezes the child's writes AND its affordances, the opt-out reopens both, and system / workflow writes stay possible throughout — they are what corrects an immutable record. No new keyword; the immutableWhen section gains the normative paragraph and a cross-reference, and the locksWithMaster section's opening no longer claims a locking master "says nothing" about its children.

Implementation that motivated it: eclipse-dirigible/dirigible#6739.

🤖 Generated with Claude Code