Render explicit scenario lifetimes and preserve marker selection

docs/language.rst

@@ -120,7 +120,7 @@ lists all additional fields. ``ref`` means ``@alias``; ``ref?`` also accepts
      - No implicit contract; ``legacy`` defaults none. OA admits Legacy only.
    * - ``oa_scenario``, ``sa_scenario``
      - ``viewpoint``: ScenarioViewpoint; ``context``: ref?; ``precondition``, ``postcondition``: strings; ``steps``: occurrence refs
-     - MixedLegacy for omitted schema-2 source; none; ``""``; ``""``; ``[]``
+     - MixedLegacy when viewpoint is omitted, including newly authored source 7 (see section 4.3); none; ``""``; ``""``; ``[]``
    * - ``oa_lifeline``, ``sa_lifeline``
      - ``represented``: participant, work, or role ref?
      - none
@@ -155,37 +155,60 @@ An Enumeration contains unique string literals. For example:
     type_ref { Named @weather_classification; };
 
 These are typed constructors with named fields, not embedded JSON documents.
-Constructor field names and enum spellings are case-sensitive. When replacing
-a constructor, all of its fields MUST be supplied; the containing declaration
-defaults do not silently fill a different constructor's missing fields.
-During schema-2 compatibility, the new Exchange fields ``message_kind``,
-``reply_to`` and ``values`` are exceptions: omitted values hydrate as
-Asynchronous, none and [] respectively. Canonical output writes them explicitly.
-This preserves older schema-2 source/JSON without inventing call correlation or
-value annotations. It is not a rule for an unspecified future schema.
+Constructor field names and enum spellings are case-sensitive. A selected
+constructor uses its own field contract; it does not inherit the payload of a
+different constructor from the declaration default. Required fields MUST be
+supplied. Nullability and omission are separate properties: ``?`` denotes a
+value that can be ``none``; a constructor's omission contract determines whether
+the field may be absent. There is no general all-constructor-fields-required
+rule. Other typed constructors use their contracts in the corresponding
+sections; the occurrence rules below do not establish defaults for them.
+
+The following table records the source-7 OccurrenceBody contracts. Optional
+references may be omitted and then mean ``none``. Exchange also admits omitted
+``message_kind`` and ``values``, meaning Asynchronous and ``[]`` respectively.
+These omissions are accepted in newly authored source 7, not only in schema-2
+compatibility input. Earlier schema admission of constructors and fields is
+still governed by its version rules.
+
+Canonical formatting writes the hydrated occurrence references and default
+``message_kind``, ``reply_to`` and ``values`` explicitly. An absent
+``operation`` remains omitted in canonical output. Lossless no-op updates and
+unrelated name edits retain authored omissions; canonical formatting is a
+different operation. An admitted incomplete occurrence can still produce model
+checks requesting its missing work, exchange, lifeline or referenced scenario.
 
 .. list-table:: Occurrence body constructors
    :header-rows: 1
-   :widths: 22 78
+   :widths: 18 36 46
 
    * - Constructor
      - Required fields
+     - Fields that may be omitted, with their resulting values
    * - Exchange
-     - ``exchange``: exchange relation ref?; ``sender``, ``receiver``: lifeline refs?; ``message_kind``: MessageKind; ``reply_to``: occurrence ref?; ``values``: MessageValue records
+     - None
+     - ``exchange``: exchange relation ref?, ``sender``, ``receiver``: lifeline refs?, ``reply_to``: occurrence ref?, ``operation``: OperationUse? → ``none``; ``message_kind``: MessageKind → Asynchronous; ``values``: MessageValue records → ``[]``
    * - Action
-     - ``action``: activity/function ref?; ``lifeline``: ref?
+     - None
+     - ``action``: activity/function ref?, ``lifeline``: ref? → ``none``
    * - Control
      - ``kind``: Choice, Merge, Fork, Join, Loop
+     - None
    * - SequenceReference
-     - ``sequence``: process/functional-chain ref?
+     - None
+     - ``sequence``: process/functional-chain ref? → ``none``
    * - ScenarioUse
-     - ``scenario``: scenario ref?; ``bindings``: LifelineBinding records
+     - ``bindings``: LifelineBinding records
+     - ``scenario``: scenario ref? → ``none``
    * - State
-     - ``state``: state/mode ref?; ``lifeline``: ref?
+     - None
+     - ``state``: state/mode ref?, ``lifeline``: ref? → ``none``
    * - Fragment
      - ``operator``: Alternative, Parallel, Loop, Optional; ``branches``: branch occurrence refs
+     - None
    * - Branch
      - ``guard``: string; ``occurrences``: occurrence refs
+     - None
 
 For example, ``body { Action { action @assess; lifeline @operator_line; }; };``
 selects an Action occurrence. Processes and functional chains contain Exchange,
@@ -657,18 +680,28 @@ references a Call occurrence in the same scenario. The call MUST precede the
 reply on a guaranteed common sequence/enclosing branch path. Reply lifelines
 reverse the call's sender/receiver; it may reuse the call's exchange in reverse
 or use an explicit reverse-direction exchange. A second reply to the same call
-on that guaranteed path is an error. Missing reply correlation is a draft
+that can follow another reply on a shared execution path, including conditional
+or parallel operands, is an error. Missing reply correlation is a draft
 warning; non-Reply messages MUST NOT have ``reply_to``.
 
-Create identifies the receiver lifeline's creation. An earlier guaranteed use
-of that lifeline is an error. Delete identifies its destruction; a later
-guaranteed use is an error. Ordering checks respect branch ownership; they MUST
-NOT flatten alternative branches into a false unconditional order. A Timer is
+Create identifies the receiver lifeline's creation. Another use that can precede
+its creation on a shared execution path is an error. Delete identifies its
+destruction; another use that can follow it on a shared execution path is an
+error. These checks include conditional and parallel operands but exclude
+mutually exclusive alternatives. Ordering checks respect branch ownership; they
+MUST NOT flatten alternative branches into a false unconditional order. A Timer is
 local to its sender lifeline, has no global exchange or values, and has either
 no receiver or the same receiver as sender. Its nonempty expression describes
 the delay/deadline; an empty expression warns. Conditions and expressions are
 stored engineering annotations, not an executable simulation language.
 
+These ordering checks compare distinct stored occurrences along structural
+paths; they do not simulate repeated loop iterations. Repetition risks use
+``reply_repetition`` and ``lifeline_repetition`` warnings separately. For example,
+a loop containing one Reply to an outer Call can warn about repetition without
+containing two distinct replies; a same-operand Create/use/Delete lifetime can
+repeat without its previous iteration being treated as an earlier stored use.
+
 Each MessageValue is ``{ path [@parameter]; field @data_field; expression "value expression"; }``.
 Its identity is the pair (path, field), so two uses of one Record can have
 different values for the same terminal field. Path contains enclosing DataField
@@ -2039,6 +2072,45 @@ exchanges it references. Cross-layer counterparts are not owned descendants.
 Text edits describe a complete candidate and must remove or repair dependencies
 explicitly before Apply succeeds.
 
+8.1. Scenario lifetime presentation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Scenario lifetime geometry is derived from the stored occurrences and their
+sequence/operand ownership. It adds no model records, source annotations or
+history entries. A lifeline's identity header and neutral editing guide remain
+available before creation, after deletion and when its represented element is
+unfinished. The guide MUST be visually distinguishable from a live interval;
+it is an editing axis, not a statement that the participant exists.
+
+A directly ordered Create starts the receiver's live interval at its occurrence;
+Delete ends that receiver's interval at its occurrence. Create uses a named birth
+marker and Delete an X, each selectable through the original occurrence identity.
+The message's receiving endpoint MUST align with its marker, including self
+messages. A pre-existing lifeline without a creation has a live interval from
+below its header; without deletion it extends to the visible scenario bottom,
+including in an empty scenario. A missing lifecycle receiver MUST NOT be inferred from
+the exchange. An explicit local receiver remains meaningful when its exchange
+reference is unfinished.
+
+Operands MUST be projected independently from their enclosing entry context.
+A lifetime change in an alternative, optional, loop or parallel operand MUST
+NOT imply the same change in its displayed sibling or a definite lifetime
+after the fragment. When local structure does not establish one lifetime across
+the represented paths, the continuation is visually unresolved. A subsequent
+explicit Create or Delete in the enclosing sequence can establish a definite interval.
+Neither guard text, screen order nor a guessed loop count proves execution.
+ScenarioUse remains opaque: opening its definition may show its lifecycle,
+but a callee's geometry MUST NOT create or destroy a caller lifeline.
+
+Call activation is distinct from lifetime. A branch-local Delete clips that
+branch's visible activation at the death marker without inventing a Reply,
+removing an unresolved-call warning or terminating sibling paths.
+Solid activation bars are restricted to definite live intervals; an unresolved
+continuation retains its uncertainty/call diagnostic rather than depicting
+definite survival after a possible deletion. Selection,
+insertion slots, source edits and Undo/Redo retain the same semantic identities
+and validation boundary regardless of the rendered intervals.
+
 9. Persistence and explicit migration
 -------------------------------------