spec: event-driven creation - a create-from may run on a source event

[delchev]

The gap

generates: (create-from) was strictly a user action: a button on the source view. There was no way to say "when the source reaches this state, create the follow-up document".

The shape that keeps coming up: a record is completed by an earlier automated or human step, and a document must be minted from it without another click. A fine arrives by webhook; once the responsible person is identified on it (a status transition), a declaration document must be created from the fine and that person. The expressible options were all wrong:

• a generates button plus a wait step — the automation degrades to a person remembering to click, and an unclicked record parks its process instance indefinitely;
• posts — event-driven and idempotent, but it emits flat mapped rows and cannot mint a header-and-items document (the item rows need the id of the header it would have to create first);
• hand-written code.

The 1.1 "Planned" list named this gap; this PR closes it and removes the entry.

What it adds

versions/1.2.md gains #### Event-driven creation — event:` under generates — create-from, plus an Appendix A row and a "what this version adds" bullet.

generates:
  - name: declaration-from-fine
    from: Fine
    to: Declaration
    event: { onTransition: Fine, when: "Status == IDENTIFIED" }   # or { onCreate: Fine }
    map:
      Fine: id                       # REQUIRED with an event — the back-reference, i.e. the guard
      Vehicle: Vehicle
    defaults: { declaredAt: now }
    items:
      - { name: "Fine {number}", amount: Amount }

Three normative rules, each answering a way this could go quietly wrong:

• The event says WHEN, never what. It names the entity from: already declares, and never repeats the owning model (fromUses: owns that). Two ways to name one source could only drift. The guard is evaluated against the source re-read at delivery, never the payload — which is as-of the event and lacks anything a later step wrote.
• At most once. map must copy the source's primary key onto the target's to-one back to the source, and the creation must return the target that already back-references it. Without that back-reference a redelivery mints a duplicate document, so a declaration lacking it is rejected. A create-from with no event keeps no such guard — producing several targets from one source by clicking twice is a legitimate manual act.
• Declaring an event drops the button unless button: true asks for both; button: false with no event is rejected (the action would have no trigger at all). When both triggers exist they must share one creation path, and therefore one guard.

Reference implementation

Eclipse Dirigible: eclipse-dirigible/dirigible#6711 — the listener is generated as a message handler on the source's -transitioned (or create) topic that re-reads the source, applies the guard and calls the same create-from a button would, carrying no mapping of its own. Verified at the outermost layer: posting the source mints the whole document, line items included, with nobody calling the create-from, and a click afterwards returns that same document.