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

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.

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.