Improve behavior authoring and typed trace history (untested checkpoint)

harness/release-behavior-audit-20260910.md

@@ -0,0 +1,280 @@
+# Behavior authoring audit — 2026-09-10
+
+Author: Codex-956atf `/root/behavior_audit`. Initial bounded read-only source and
+domain review, followed by root's separately assigned B2 implementation below.
+The audit locations/findings describe the pre-edit snapshot. No Cargo,
+application input, or new runtime acceptance was performed. Read repository
+AGENTS.md, Gitea issue #1 and
+its comments, Wiki Home, and open PR inventory (none). Coordination is in issue
+#1. Source was inspected in the shared continuation checkout while other workers
+handled architecture authoring/builds; HEAD at the final inspection was
+`1797516f460ce27f7bc92e50ea2478ec51dd49b9`.
+
+The current implementation is substantially beyond static behavior diagrams.
+The remaining high-value work is making direct authoring consistent across the
+first process contribution and the non-message scenario tools. Historical
+absence claims in the early semantics audit are superseded by source7 code and
+its scoped evidence.
+
+## Ordered findings
+
+### B1 — A first exchange switches a new process into a less editable surface
+
+**High workflow impact; source-confirmed, fresh native reproduction required.**
+
+An empty Process/FunctionalChain opens the editable topology Graph. Draw its
+first Exchange contribution and it becomes a nonempty exchange-only ordered
+path. `uses_explicit_topology` now returns false, so the view changes to a
+sequence Scene without topology interaction. Tools for drawing contributions,
+connecting, reconnecting, zooming and reordering disappear. A one-contribution
+path has no link to convert, so the user must use Append exchange or separate
+Add work/control/reuse form buttons to return to the graph. Existing multi-step
+ordered paths likewise require the conversion/menu route.
+
+Evidence: `behavior.rs:753` defines the inferred legacy/explicit distinction;
+`behavior/topology/view.rs:89` selects the explicit surface, `:380` begins the
+legacy branch, and `:421` builds `Scene::sequence` without an interaction
+context. `behavior.rs:887` initializes `interaction: None`.
+`app/process_canvas.rs:316` already tests first/second exchange creation and
+exact history, but that test does not assert a continuous editable surface.
+
+**Reproduce:** Create an empty OA process (repeat in SA), choose Exchange and
+click the canvas, select an existing exchange and Create. Try to draw a Work
+contribution or connect from the newly created contribution without entering a
+different workflow. Repeat with an old ordered exchange-only process.
+
+**Bounded next fix:** retain one interactive process surface for empty, single
+and legacy ordered paths. Preserve the legacy implied order; when a pointer
+mutation needs explicit links, include the existing `preserved_order` proposal
+in that same atomic command. Do not invent a self-link merely to force the view
+predicate, and do not migrate a document merely by opening it.
+
+**Acceptance:** first and subsequent contributions remain directly editable;
+opening/selecting remains read-only; OA and SA preserve all old exchange IDs
+and implied order; insertion/connection uses one exact source/model Undo step;
+redo and save/reopen retain the result. Verify the actual viewport and visible
+tools at 1100×700 and a normal desktop size.
+
+### B2 — Most scenario objects still require detached append forms
+
+**High workflow impact; source-confirmed, fresh native evaluation required.**
+
+Scenario canvas tools are only Select and Message. Lifeline, reuse, fragment,
+action and state-observation buttons directly start a form. Every such Start
+sets the parent to the main scenario and the insertion position to append,
+even when an operand is selected. Consequently adding an action at a visible
+operand position or inserting a reference/fragment between existing messages
+requires manually choosing an operand, creating at its end, then reordering.
+Fragments cannot be drawn around a visible sequence range. The semantics and
+generic property editing exist; the missing part is contextual canvas authoring.
+
+Evidence: `behavior/scenario.rs:69` (`CanvasTool`), `:327` (Start initializer),
+`:1436` (form-launch controls), `:1565` (manual destination), `:1777` (fragment
+form). `behavior.rs:1564` handles only message drawing and selected-occurrence
+reordering. Reordering deliberately refuses operand changes at
+`behavior/scenario.rs:636`; this invariant should remain explicit.
+
+The scenario shell also retains three permanent control rows, an outer page
+scroll and a separately scrolled canvas; pending forms add another scroller.
+The canvas is capped at 340 px normally and 190 px while pending (`:1535`),
+unlike the newer process remaining-height layout. This is a source-established
+space allocation; clipping or interaction failure on the current binary is
+not claimed without native observation.
+
+**Reproduce:** In the teaching scenario select an ALT operand and a middle
+message. Add Action or Reuse. The form says Main scenario sequence / append,
+rather than retaining the selected operand and visible insertion point. Try
+the same task by selecting a tool and clicking the intended canvas position.
+
+**Bounded next fix:** extend the existing scenario gesture/Slot adapter for
+Action, State, Reuse and Fragment; capture the exact owner, operand, before-ID
+and optional lifeline before opening its compact contextual editor. Reuse the
+existing core commands, validation, draft recovery and atomic history. Give
+scenario controls the compact, stable remaining-height shell used by processes.
+Range wrapping and cross-operand movement need a distinct explicit transaction;
+they should not be silently smuggled into ordinary reorder.
+
+**Acceptance:** create each supported non-message occurrence at the clicked
+root/operand slot; select its semantic identity afterwards; Escape, scroll,
+resize, document change and rejected Apply cannot commit a stale slot; invalid
+draft text survives repair/recovery; Undo/Redo restore complete source bundles.
+Native users must complete an ALT + action + reuse task at 1100×700 without
+losing the target region or searching for offscreen submission controls.
+
+### B3 — Opening a reused scenario does not retain an explicit caller return
+
+**Medium workflow impact; source-confirmed.**
+
+Scenario references have real identity and bindings, and an Open action works.
+However it is placed in the full sequence listing below the canvas and sends
+only `Message::Select(target)`. Selection replaces the active scenario. There
+is no scenario caller stack/Back action to restore the particular use and its
+viewport, unlike process reference navigation. The Connections inspector can
+find users manually; that does not preserve which of several callers was open.
+
+Evidence: `behavior/scenario.rs:1841` / `:1893` (listing/Open),
+`app.rs:961` / `:982` (selection changes active behavior),
+`behavior/scenario.rs:155` (State has no return context). Compare existing
+`behavior/topology/direct.rs:191` (remember/back) and
+`app/process_canvas.rs:161` / `:183` (guarded Open/Back).
+
+**Reproduce:** Open caller A containing two uses of the same scenario, select
+its second use in the canvas, open the definition through the listing, then
+return to that exact use and viewport. The user must reconstruct the return
+through owner selection/Connections.
+
+**Bounded next fix:** selected-reference Open and Back to caller controls with
+document/owner/use identity and viewport context, using the same draft guards
+as process navigation. This is transient navigation state, not model history.
+
+**Acceptance:** A→B→C and two uses of B return in order to the exact initiating
+use; renamed/deleted callers are handled safely; pending invalid edits block
+navigation without loss; no model/source/Undo entry is added by navigation.
+
+### B4 — Create/Delete message semantics are not reflected in lifeline geometry
+
+**Medium visual-semantic impact; source-confirmed.**
+
+The core validates creation/destruction ordering, and message names distinguish
+Create and Delete. The renderer nevertheless draws every lifeline from its
+top header to the bottom of the whole scenario; lifecycle kinds only affect
+the message label. There is no birth anchor or destruction mark, so a reader
+sees the same apparent existence interval for an ordinary participant and one
+that is explicitly created and destroyed during the interaction.
+
+Evidence: `behavior.rs:1016` always builds the full-height lifeline;
+`:1165` selects only a textual message-kind prefix. Core lifecycle coverage is
+in `oa-core/tests/release_scenarios.rs:459` and its loop/branch variants. This
+finding is about visualization, not missing core lifecycle validation.
+
+**Reproduce:** Use a valid root sequence with Create(B), a call/reply involving
+B, and Delete(B). Inspect B before Create and after Delete; its lifeline still
+runs through both regions.
+
+**Bounded next fix:** derive birth/death anchors and a destruction glyph from
+the existing occurrence identities. Handle branch-local lifetime explicitly;
+an event in one ALT operand must not falsely terminate all other alternatives.
+No persistent execution engine is needed.
+
+**Acceptance:** root-sequence Create/Delete, ordinary lifelong participants,
+ALT-specific events and LOOP lifecycle warnings are distinguishable; hit tests
+still return the actual occurrence; direct insertion continues to reject invalid
+before-birth/after-death uses through the shared core boundary.
+
+## Semantics and history findings that must not be reported as missing
+
+- Scenario occurrences and referenced engineering definitions are distinct;
+  repeated exchange uses have distinct names/IDs. Direct Call+Reply creates
+  correlated occurrences in one transaction. Execution bars are derived from
+  correlation and operand boundaries (`behavior.rs:1304`), not persisted proof
+  of simulated execution. `scenario.rs:1026` and direct tests cover the adapter;
+  the earlier scoped native results are in `release-scenario-editing.md`.
+- Source7 already provides caller-qualified process addresses, distinct repeated
+  reference uses, precedence versus exchange/common-work incidence, and explicit
+  interface-operation allocation identity. See `oa-core/src/model.rs:534`,
+  `behavior/topology/contextual.rs`, `scenario_operation_tests.rs`, and
+  `release-source7-native-acceptance-20260907.md`. The original S1/S2 absence
+  findings are stale. Remaining purpose/native cases are acceptance work.
+- Shallow/deep history vertices, scope validation, creation tools and documented
+  semantics already exist (`oa-core/src/state_validation.rs:187`,
+  `oa-core/tests/release_states.rs:466`, `behavior/state_view.rs:111`,
+  `docs/language.rst:860`). Shallow history restores the immediate substate;
+  deep history restores nested configuration. Studio explicitly uses history
+  per Region and does not persist running execution state. The primary Capella
+  metamodel describes the corresponding containing-state behavior; this is a
+  documented profile distinction, not grounds to require a simulator.
+  [CapellaCommon schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/CapellaCommon.ecore).
+- Capella has distinct start/finish duration constraints and execution objects.
+  Studio's local timer is not an equivalent named duration relation. It does
+  have maintained generic constraints over semantic IDs. This audit did not
+  falsify that alternative for a required user workflow, so it does not reopen
+  a metamodel expansion already assessed in `release-scope-reconciliation-20260906.md`.
+  [Capella Interaction schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore).
+
+## Comparison and next action
+
+The existing native Capella benchmark actually exercised palette→canvas chain
+reference/control/sequence-link creation, a scenario reference region and Open,
+and call/return insertion reusing an existing exchange. It separates observed
+controls from executed actions (`release-capella-workflow-benchmark.md:51–69`).
+These support B1–B3 as engineering-workflow comparisons rather than a demand to
+copy the Eclipse UI. Capella's official overview independently distinguishes
+functional, exchange and interface scenario perspectives, all now represented
+by Studio's typed scenario viewpoints.
+[Official feature overview](https://mbse-capella.org/features.html).
+
+Prioritize B1 and the bounded slot-based part of B2; native-check those exact
+first-use tasks after root's current compilation/runtime gates. B3 is a small
+navigation follow-up. B4 should receive branch-aware visual acceptance. None
+of this report certifies current Windows/Linux behavior or transfers historical
+test/native evidence to a changed executable.
+
+## Authorized B2 implementation follow-up
+
+Root subsequently assigned `behavior.rs`, `behavior/scenario.rs` and only the
+ScenarioCanvas event arm in `app.rs`; Gitea #18 records this ownership under
+Codex-956atf. The separate topology worker owns B1. Current changes:
+
+- A compact selector replaces the three permanent scenario tool rows. Action,
+  Observe state, Reuse and empty Fragment use the same choose-tool/click-position
+  workflow as messages; lifeline creation remains explicit because persistent
+  horizontal placement is outside the existing schema.
+- Press captures the exact root/operand/before identity and an optional clicked
+  lifeline for Action/State. Release opens the existing draft; no model mutation
+  occurs until Create. The selected position remains marked in the pending
+  canvas. Clicking away from a lifeline leaves it unresolved for explicit choice.
+- Existing context, scroll/bounds, Escape and pending-edit guards apply to this
+  new press variant. The draft adapter validates slot and lifeline ownership
+  before starting. Existing command admission handles the complete semantics;
+  no separate model, schema, fragment wrapping or cross-operand reorder was added.
+- Added `direct_clicked` tests: real Scene callbacks through App for all four
+  tools, root and nested slots, on/off-lifeline clicks, exact full source/model
+  Undo/Redo; invalid/cross-scenario capture, all context dimensions, scroll
+  invalidation, incomplete raw-draft recovery/repair; all four tools against
+  nine pointer cancellation cases. These tests are written, not yet run.
+- Applied root's coordinated process-header predicate change so every
+  Process/FunctionalChain uses the compact header with the topology worker's
+  unified renderer. The semantic legacy/explicit predicate is unchanged.
+
+Whitespace verification passed for this worker's source changes. Another worker
+read the clicked-slot adapter and reported no confirmed blocker, while requesting
+the now-added off-lifeline/cancellation cases. Formatting/build/tests await root's
+toolchain and serialized Cargo lease. No native pass is claimed: test actual
+root/operand selection, current tool visibility, pending marker/viewport and
+Create/Cancel reachability at 1100×700 and normal size, including crash recovery,
+save/reopen and exact Undo/Redo. B2's larger remaining-height shell, fragment
+range wrapping and B4 lifecycle rendering are not part of this bounded
+implementation. B3 followed as the separately assigned slice below.
+
+## B3 implementation follow-up — candidate ready, execution pending
+
+The selected ScenarioUse exposes **Open definition**; the target scenario exposes
+**Back to caller**. Detailed sequence-list Open uses the same guarded adapter.
+Navigation retains document, caller scenario, exact use occurrence, target,
+selected tool and independent canvas/page offsets in at most 32 transient frames.
+Nested A → B → C and distinct uses of B return to their initiating occurrence.
+Renaming retains identity; deleted or repointed uses are rejected on return.
+Property, source and behavior drafts block both directions without applying them.
+
+The existing scroll observer restores only its matching document/scenario/token,
+directly in the mounted root Scrollable. It observes natural viewport clamping,
+consumes a request once and sends a correlated receipt to the App. It does not
+use a delayed global scroll task or traverse into nested scrollables. This adds
+one passive Restored variant beside the existing Scrolled early App handler; all
+other App changes remain in ScenarioCanvas. Caller navigation is neither model
+content nor recovery data and creates no model/source/history command.
+
+Added regressions cover nested and distinct-use App navigation, exact unchanged
+model/source/revision/history, invalid pending drafts, four stale context axes,
+non-use targets, renamed/deleted/repointed caller references, and real mounted
+Scrollable → App flow for both scroll areas including clamping, subsequent wheel
+input, repeated receipts and changed page. Foreign document/owner and process
+views reject restoration. These tests have not run yet; root will format and
+compile the coherent candidate before acceptance.
+
+Native acceptance remains: select a root or operand reference, Open definition,
+open a second reference there, return twice and inspect exact selected occurrence,
+tool and both scroll positions. Repeat from the detailed list with two uses of
+one target, a resized window and an invalid draft. Verify no dirty/history change
+from navigation. The separate remaining-height layout slice must retain these
+events and observer restoration when moving the scenario workspace.