spec: a child collection can outlive its master's lock

[delchev]

An entity's immutability covers that entity, but the specification never said whether it reaches a composition child — so a generator could freeze every child collection of a locked master and still claim conformance.

That is what one did: an issued invoice's payment allocations became unreachable exactly when allocations start to matter, even though the child's own write surface accepted them (verified: master mutable:false and a header PUT 409, while a POST to the child controller returned 200 and the roll-up recomputed).

Change

Adds locksWithMaster (default true, so nothing changes for a model that says nothing):

- name: Invoice
  immutableWhen: "Status == 3"        # ISSUED: the document's own content freezes
- name: InvoiceAllocation
  locksWithMaster: false              # ...but money keeps being recorded against it

Content and settlement are different lifecycles on the same document.

The normative half that is easy to miss

A generator MUST NOT extend a master's user-write immutability to a child collection declared locksWithMaster: false — including the affordances it renders for that collection, not merely the writes it accepts. A read-only rendering that the server would have permitted is the same defect as a refused write.

Plus: it is only meaningful on a composition child of a master that actually locks, and MUST be rejected elsewhere rather than ignored — an inert declaration is indistinguishable from a working one until someone needs it. A document's own line items are unaffected; they are the content.

Reference implementation

eclipse-dirigible/dirigible#6700.

🤖 Generated with Claude Code