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

Behavior workspace gap audit — 2026-09-10

Author: Codex /root/behavior_audit. Bounded investigation requested by root; no implementation, Cargo command, native input, shared-ledger edit or commit was performed. Owns this report only. Reviewed local 1797516f460ce27f7bc92e50ea2478ec51dd49b9 plus the working tree while the separate palette worker edited architecture files. Relevant behavior files were unchanged during inspection.

Read repository AGENTS.md, Gitea issue #1 and all then-current comments, open PR inventory (empty), and Wiki Home before review. The Wiki describes the older publication snapshot; the local commit above is this report's source baseline. Historical test/native records retain their original scope. This is code/evidence review, not a fresh test pass or native acceptance.

Result

The existing Behavior workspace has real authoring capabilities. Rebuilding its domain from the older “static projection” audit would duplicate integrated work. The highest-priority remaining change is to make the scenario workspace use an editable, remaining-height canvas with compact tools and contextual insertion, then provide a local way to start a behavior. Native inspection of the current executable should confirm the resulting interaction priorities before implementation.

Implemented functionality to preserve

Area	Current evidence	Actual scope
Process/functional chain	behavior/topology.rs, topology/direct.rs, topology/view.rs, app/process_canvas.rs	Existing work/exchange involvement, repeated source use with distinct occurrence IDs, Choice/Merge/Fork/Join/Loop, guarded links, link insertion and reconnection, same-column presentation reorder, legacy append/conversion, reusable definitions with expand/open/back.
Nested process instances	topology/contextual.rs, topology/contextual_routing.rs; oa-core/src/model.rs:533–546	Qualified occurrence paths, nested reusable instances and caller-owned Precedence/Exchange/CommonWork links are implemented in source7. The older statement that inner-chain linking is absent is stale.
Scenario	behavior/scenario.rs:13–146, 988–1189, 1413–1901; behavior.rs:1477–1658	Viewpoint-compatible lifelines, existing exchange reuse, click-click/drag message drawing at a captured sequence slot, paired call/reply, async/create/delete/timer messages, action/state observations, ALT/PAR/LOOP/OPT operands, explicit scenario-use lifeline bindings, same-parent reordering, execution bars, qualified payload values and exact interface-operation allocation.
State machine	behavior/state_view.rs, state_canvas.rs, state_edit.rs, states.rs; app/state_diagram.rs	Explicit state diagrams with persistent placements, nested regions, state/mode/pseudostate creation, move/pan/zoom/fit, transition draw/reconnect/details, typed time/change/signal events, work triggers and entry/do/exit work links. These are not static diagrams.
Shared editing boundary	Document::execute; typed Command::Batch; scenario tests at scenario.rs:1963, 2646; process tests at topology/direct_tests.rs:126, 460; state tests at app/state_diagram_tests.rs:466, 504	Existing tests exercise atomic history and exact model/source identity. REST accepts ordinary shared commands; no separate desktop-only semantic model is needed for the proposed UX work. Tests were inspected, not run in this audit.

The native benchmark already operated Capella chain involvement/reference/control, repeated scenario call+reply/reference, and state/time-trigger workflows. The historical Studio direct-editing reports also contain bounded Linux/Windows trials. Preserve that evidence rather than calling everything unverified; it does not establish current full-release acceptance. See Capella benchmark, scenario editing, process editing, and source7 native acceptance.

Official Capella distinguishes global dataflow from contextual chain paths, and supports functional, exchange and interface scenarios plus state/function relationships. This supports the current separate occurrence and shared-definition identities; it does not require identical screen chrome. Official feature description. The source metamodel also defines distinct chain involvements, chain references, controls and sequence links. Official FunctionalAnalysis model.

Ranked actionable findings

1. P1 usability — scenario authoring still gives the diagram a small fixed strip

Evidence: behavior/scenario.rs:1435–1519 builds three tool rows and guidance above the diagram. At 1541–1545, the canvas is capped at 180–340 px normally and 110–190 px while a form is open; a 700 px window receives 290 px normally and 110 px pending. The form fields separately receive 110–240 px at 1825. The entire page still scrolls at 1839, with a recursively expanded sequence-button list below at 1841–1901. Scenario CanvasEvent/State at 75–91, 154–160 have no zoom, viewport or focus controls. This is a source-level layout limit, not a claim about measured pixels in the current native window.

User task today: draw a call in an ALT operand, fill its values and inspect the reply. The tool rows, small nested canvas and page/form scroll compete with that task. By contrast, process topology/view.rs:270–375, 620–686 already has Tools/Selection shelves, focus, zoom and remaining-height panes.

Proposed next change: port the layout pattern, preserving scenario semantics. One compact header with owner, focus, Tools/Selection, Fit/100% and zoom; default closed shelf; independently scrolling tools/details; stable canvas occupying remaining height; independent pending form with always-visible Create/Cancel. Put the full sequence list in an optional outline shelf, not permanently beneath the canvas. Show only the active tool's concise guidance.

Acceptance: at 1440×900 and 1100×700, a four-lifeline ALT fixture remains usable with a pending call/value form, without scrolling the entire workspace to reach the canvas or actions. Use the process layout as the sizing baseline: actual remaining height, not constants derived from total window height. Opening/cancelling Tools, Selection and forms preserves the current canvas scroll position and manual scale. Focus expands the canvas and restoring panels returns the same selection. Fit is an explicit overview; it must not silently replace the working scale when choosing a tool. The diagram, form and outline scroll independently.

Partition: scenario view/layout helpers and scenario-specific state/events; narrow root-owned App/focus plumbing. No architecture palette files or core/schema edits.

2. P1 usability — behavior entry and creation are still routed through the global catalog

Evidence: behavior.rs:691–728 creates one unsearched pick list of every same-layer process, chain, scenario and machine. The empty view at 711 only instructs “using Create element”. The actual creation catalog is views.rs:128–162, with all supported kinds and global At root/In selected operations. There is no New scenario/process/machine action in the behavior header, and scenario viewpoint is not part of a local startup action.

User task today: start the first OA process or a new SA interface scenario. The user must find the generic creator, choose a kind, choose ownership, then edit the owner/viewpoint before the specific tools become useful. A large list of existing behaviors is also hard to navigate by purpose.

Proposed next change: a compact New action with layer-correct Process/Functional chain, Scenario and State machine choices. Name and valid owner are explicit; scenario viewpoint is explicit in the same draft. Create selects and opens the new behavior; a machine can offer creation of its first view in the same validated operation. Provide searchable, named behavior navigation grouped by family, retaining UUID selection. Keep creation of an owner distinct from reuse/involvement of an existing one.

Acceptance: from a new project, create a named OA process and a named SA functional/interface scenario without using the generic kind catalog. Escape creates nothing; Create is one Undo step; Undo/Redo, source Apply and save/reopen retain IDs and viewpoint. Changing family/layer while the draft is pending follows existing draft guards. An engineer can find a named behavior among 100 mixed owners by search.

Partition: behavior.rs header plus a dedicated owner-creation module; root integrates App events and recovery. This can follow the scenario pane without touching architecture authoring.

3. P2 usability — form tools ignore the selected sequence position, and creation dominates editing

Evidence: scenario::Event::Start at 327–357 always sets parent = owner, before = None, and clears sender/source, regardless of the selected operand or occurrence. Only drawn messages use a captured Slot (64–90, begin near 278). Toolbar Add Action/Observe state/Fragment/Reuse therefore start at the main scenario's end; the user must change the destination picker at 1581–1586. CanvasTool has only Select and Message. Reorder explicitly rejects crossing operands at 636–661. Generic properties can edit occurrence bodies and parent ownership (forms.rs:1122–1178); this is not missing model capability.

User task today: select an ALT operand and add an observed state, or add a third alternative and move an existing message into it. Selection does not seed the Add form. There is no scenario-local Edit occurrence/Add operand/Move to operand command, and no graphical fragment-creation slot tool. Existing properties/source workflows remain available but obscure the engineering operation.

Proposed next change: in Selection details, show the selected occurrence, represented source and owner/operand, with Edit, Add before/after, Add inside operand, Add operand for ALT/PAR, explicit Move to operand and Open referenced scenario. Seed the existing typed draft from this context. Keep ordinary drag reorder within the same parent; changing operands is an explicit validated operation. Expose scenario-reference Open in this shelf and retain a caller breadcrumb/back action as the process editor does. Defer free-form fragment rectangle drawing until these basic operations are usable.

Acceptance: selecting an operand and choosing Add Action defaults to that operand. Selecting a message and Add before records that exact ID as the insertion anchor. Add a third ALT operand without constructing a generic Occurrence manually. Move a call+reply pair explicitly into one operand in a single validated batch, preserving IDs and source exchange; reject moving only a reply if dominance becomes invalid. Reordering never silently reparents. Referenced-scenario navigation returns to the same caller occurrence.

Partition: scenario selection shelf/draft entry points and ordinary Batch planners, with production event tests. Root coordinates behavior.rs/App changes; no new domain records required.

4. P2 usability — missing shared sources produce a cancel-and-rebuild detour

Evidence: scenario lifeline/action/observation sources are existing model elements only (672–703); exchange choices are existing relations only (704–771); the no-match message ends with “or cancel” (1380–1381). In reuse, missing local lifelines produce “Add a compatible local lifeline before binding” (1758–1762), but the pending draft prevents starting another tool (323–325). Process targets at topology.rs:326 also involves existing sources by design. The observed Capella message dialog offered creating a named exchange or reusing a compatible one; see the native benchmark's scenario section.

User task today: draw between two valid lifelines and discover no exchange, or reuse a scenario whose represented participant lacks a local lifeline. The first operation requires cancelling to author the shared exchange elsewhere. The second requires cancelling, adding a local lifeline, then rebuilding the use/bindings. This is a workflow gap, not a reason to invent exchanges automatically.

Proposed next change: first implement “Add missing local lifelines” inside a reuse draft with an explicit list and stable reserved IDs, committed together with ScenarioUse. For missing exchanges, either expose a named, endpoint-compatible Create exchange action or a draft-preserving Open source authoring/Return flow. The user must see the shared definition creation and choose it; keep existing reuse as the normal option. Reuse state/source pickers should also gain search/paging, since picker at 1333–1347 remains unbounded for those lists.

Acceptance: reuse into a caller with one missing compatible lifeline without losing its name or existing bindings; one Undo removes exactly the new lifeline and use. Invalid/ambiguous binding does not guess a participant. Creating a shared exchange plus its occurrence is explicit, uses the actual OA/SA endpoint contract and is one atomic command; cancelling creates neither. Existing exchange reuse never duplicates its definition.

Partition: scenario draft and planners first. Shared-exchange creation may reuse existing architecture planner services but requires a separate coordinated patch; do not couple it to the layout work.

5. P2 usability — state naming still follows the placeholder workflow rejected for architecture

Evidence: state CreateAt immediately creates kind.label() as the model name (state_edit.rs:414–439) and commits it through app/state_diagram.rs:203–225. State tools support move/transition and properties, but the only production F2 handler found is in architecture diagram.rs:621. Thus named-state creation still means creating “State”/“Region”, then editing properties. State geometry and semantics themselves are implemented.

Proposed next change: state/mode/region tool → valid owner/point → inline name → one Create+placement batch, with F2 on a selected named state/region and Escape cancelling the draft. Pseudostates may keep their conventional symbol names. This should follow the architecture naming contract while keeping its state-specific context and placement identity.

Acceptance: create named Standby and Operating in the selected region, cancel a third state without a model/history change, F2 rename Operating, then Undo/Redo and save/reopen. No camera shift, ownership change or architecture placement mutation occurs. State transition guards/triggers continue to use the existing details form.

Partition: state view/canvas/edit and root-owned state App routing; separate from scenario files and architecture palette.

Semantic additions: separate release-scope decision

The above findings require no schema expansion. There is a narrower real difference worth recording separately: Capella InteractionFragment has explicit covered instance-role references; Studio OccurrenceBody::Fragment stores only operator and branch IDs (oa-core/src/model.rs:582–589). The current renderer derives a whole-sequence fragment presentation. Therefore the model cannot expressly declare a fragment covering only a subset of otherwise present lifelines. Official Interaction model, InteractionFragment.coveredInstanceRoles and CombinedFragment.

Do not disguise that difference with geometry alone or declare the current supported whole-scenario fragment invalid. If partial-lifeline behavior is required for release, its acceptance should be an ALT covering two of four lifelines with the other two continuing independently, preserved across graphical/source/REST edits and transitions. It needs a separately reviewed contract for coverage, order and call/reply dominance, references/deletion/remapping, grammar migration and rendering. Additional UML operator enumeration and timing constructs should not delay making the already implemented workflows usable without a concrete release task requiring them.

Verification and next handoff

Root should operate the actual scenario workspace first, at 1440×900 and 1100×700, with an ALT operand and nested reuse fixture. Check the finite canvas, opening a pending message/value form, selection of an operand followed by Add Action, empty compatible-exchange result, reference Open, and return/navigation. These source-identified gaps are falsifiable observations, not a claim of a current native failure already witnessed by this agent.

For the first implementation slice, retain and extend the existing meaningful tests:

1. Real Iced tree/layout: keep the same canvas widget slot and actual scrollable state through shelf/form open/cancel, focus and owner changes. Existing seed: scenario.rs:2476 and process topology/direct_tests.rs:1015; do not settle for counting widgets. Measure the canvas and fields at minimum/wide layouts, with Create/Cancel in view.
2. Production input: click-click and drag messages, reordering, scrolled origin, scaled coordinates, stale document/owner/revision/epoch, resize, bounds, Escape and focus cancellation. Zoom or shelf resize invalidates old gesture geometry; same-size passive events do not discard the working camera. Extend existing behavior.rs direct-pointer tests and app/behavior_lifecycle_tests.rs.
3. Atomic semantic/source behavior: preserve the current exact-ID call/reply pair, exact insertion order, branch dominance, unchanged shared source and one-entry Undo/Redo oracles (scenario.rs:1963, 2015, 2060, 2646). Test source-write rejection retaining every new draft value; source/JSON reopen agrees. A layout patch does not warrant new core semantics.
4. Current-source acceptance: rerun the focused affected tests, desktop checks/build and required formatting/lints under the sole Cargo owner's lease, then actual Windows native editing with Save/Undo/Redo/reopen. Linux runtime acceptance remains distinct. Do not transfer historical pass counts to newly changed code.

Recommended order: scenario pane and selection context → local behavior creation → reuse completion → state naming, with a small coherent native acceptance fixture after each slice. Root retains implementation assignments, integration and common Wiki/ledger updates. No release-complete claim follows from this report.