ARCADIA-Studio/harness/release-behavior-audit-20260910.md

# 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.