ARCADIA-Studio/harness/experiments/behavior-navigation-review-20260912/free-behavior-canvas-design-20260912.md

Freely editable process and scenario canvases — design investigation

2026-09-12. Read-only investigation by delegated reviewer /root/diagram_membership_map for Codex-ytr83r. Source inspected in C:/Users/User/Documents/Git/ARCADIA-Studio/.local/diagram-usages-ytr83r-20260912, branch codex/diagram-usages-ytr83r-20260912, base 7aa007b0777aa182a99f46e90eeb9b2558f3ad2a plus root's uncommitted navigation/prerequisite integration. This is a proposal, not an implemented feature or an acceptance result. No source modifications, build, GUI operation, or Gitea claim was performed. Root owns compilation and native inspection; peer Codex-956atf owns #16 resize foundation and #3/#15 work.

Required outcome and evidence boundary

The user's #2 clarification608 explicitly rejects the camera/repair preview as satisfying free behavior editing. Process and scenario diagrams must support ordinary direct manipulation comparable to architecture/state diagrams. The earlier comment250 about sequence constraints does not authorize retaining rigid automatic-only layouts after that clarification.

Concrete requirements are #20: spread lifelines to expose labels, move arrows, resize objects, replace strange draggable rectangles with understandable controls; #22, including comment606: process movement, resizing, and connection bends; #24: replace the Details-menu interaction; #25: canvas available without an activation button. The user-owned specification also requires graphical/text parity, an unambiguous reST specification, REST automation, readable source, and maintainable architecture. Cosmetic movement is not authorization to change behavioral ordering.

The peer resize foundation at full commit f7d84faf30cdb5e3695c2dc16ee0a5f2eac91e71 was read, including its executed falsifiers and unresolved questions. Its verified contract is eight handles, fixed opposite edges, unchanged authored child placements/semantic ownership, one Undo transaction, preservation of inactive authored fields, and exact projected preview/reopen equality. It rejects copying every visible dimension back into storage: stored224×160 projects224×232, copying224×232 can project232×232, while preserving authored height permits214×232. It also rejects a universal preferred minimum on an inactive axis. Those are resize-planner requirements, not reasons to omit handles. Process/scenario persistence is explicitly a separate dependency. No new resize-gesture implementation is claimed here.

Existing native Capella benchmark demonstrates point creation, a drag-created LOOP/operand, and distinct occurrence/definition identities at1010×760. It does not establish resize, message movement, routing, or nested activation behavior. Root's current native capture attempts timed out, so no new native evidence is claimed.

Current implementation: the missing persistence boundary

Surface	Actual geometry and interaction	Consequence
Persisted architecture/state	Diagram, NodePlacement, EdgeRoute provide stable view/placement identities, absolute coordinates, authored size, routes and labels. ProjectionKind has StateMachine but no Process/Scenario owner variant.	Existing source/history/API mechanisms are reusable. Adding process/scenario enum labels alone cannot make their desktop renderers consume saved geometry.
Process	Graph::expanded_qualified derives columns from SequenceLinks/legacy order and places every contribution at x=24+rank*420, initial size270×104. Reuse cards get automatic preview height; expansion chooses4 or up to512 tiles. State stores ephemeral camera/expansion/draft state, no persisted layout.	Every render reconstructs positions and routes. No user-authored movement survives because no such geometry exists in the model. Source owner steps determines included occurrences, not coordinates.
Process input	direct::Graph::input selects from node bodies. A separate handle starts Press::Reorder; release publishes Reorder, not Move. The planner rejects cross-column reorder because links define columns. Reconnect handles alter semantic links; there is no bendpoint drag.	The strange rectangle is a semantic reorder affordance, not a misplaced implementation of free movement. Renaming it or making it larger cannot satisfy #22.
Qualified process reuse	contextual::preview and GraphNode.preview retain caller paths plus occurrence IDs. Direct ContextualLinks retain relation IDs; preview links currently reduce callee links to endpoint pairs.	Two appearances of one callee occurrence must have independent layout. Saving by represented work ID or callee occurrence ID alone will alias them. Preview routes need the complete caller path plus callee relation ID before they can be authored.
Scenario	Scene::sequence gathers direct lifelines, places them at automatic x positions (160+i*240), creates fixed204×70 headers, and occurrences walks semantic sequences/operands to build fixed row spacing, boxes, arrows and frames. Lines are keyed by exchange occurrence ID. Presentation stores only identity, viewport, focus/shelf and camera.	Lifeline spacing, event y, box/frame dimensions and route bends are not model data. Reopening cannot restore manual layout. Repeated messages using one exchange still require separate presentation.
Scenario input	Scene::reorder_handle creates a22×24 rectangle at x6 beside the selected row. scenario::reorder changes SetSteps within the current owner/operand only.	The existing drag is an ordered-list edit. It does not represent free line movement, independent whitespace, or shape sizing.
Scenario lifetime/activation	scenario_lifecycle derives birth/death/call semantics, with rendering consuming occurrence rows/sequence bounds. ScenarioUse is currently an opaque card; bindings do not produce inlined callee rows.	Geometry must consume semantic lifetimes and ordering; it must not derive new semantic call/death relations from drawn coordinates. Nested activation #21 remains a separate semantic/rendering dependency.
Shared shell	controls has Details and Canvas buttons; keyboard_enabled and Scope::input_owner gate draft/modal contexts. host overlays a300px editor over the viewport.	Replace the activation/Details UX, but preserve actual keyboard ownership and stale-context protections. Always-active pointer editing is compatible with text inputs owning their keyboard.

The authoritative existing presentation specification is language.rst section5. Ordinary node coordinates are absolute diagram coordinates and do not alter containment/allocation. routes.edge currently accepts a Relation or Trace, never a scenario exchange occurrence. Route list order/comments are retained by identity; endpoints and automatic elbows are deliberately not saved. Command already has Create/EditDiagram, Create/EditNode, MoveNode, Set/RemoveEdgeRoute, SetSteps, Batch and Layout. Document::execute prepares a complete candidate, updates source with the identity map, and commits the accepted model/source pair together. Server routes expose conditional project transactions; adding layout must use this pathway, not a second desktop-only store.

Alternatives and proposed choice

Criteria: satisfy manual placement/resizing/bends; preserve behavioral semantics during cosmetic edits; exact source/API/Undo/reopen parity; retain existing authored architecture/state geometry; use stable identities for repeats; keep the interaction understandable; avoid a broad rewrite before a useful end-to-end workflow exists.

Candidate	Advantages	Material failure or cost	Decision
More camera controls, auto-layout spacing sliders, wider fixed cards	Small desktop diff; preserves current generator	Still cannot place individual objects/routes; explicit user rejection already falsifies sufficiency	Reject as the feature; optional layout assistance only
Desktop/session position overrides	Fast visual prototype	Loses source/REST/save parity; undo splits between model and view; stale/reused identities become ambiguous	Reject production storage; transient drag preview is its only role
Put all behavior in an unconstrained generic graph, with free x/y treated as semantic order	Broad shape reuse	Cosmetic drags can change execution; sequence endpoints, lifecycle, operands and nested calls require special treatment anyway	Reject semantics-by-coordinate; reuse primitives only
New independent BehaviorDiagram top-level aggregate	Clean domain separation and typed layouts	Duplicates view naming/identity/source ownership/artifacts/navigation/server inventory; more migration and integration than needed	Viable if Diagram becomes unmaintainable, but not smallest coherent first choice
Extend existing Diagram with owner-bound Process/Scenario projections and typed domain layout	Reuses stable saved-view lifecycle and source transactions; direct process nodes/routes fit existing records; scenario-specific anchors stay explicit	Requires real core/source/API work, and pure geometry extraction from desktop	Proposed choice, with the type partition below

Reuse direct process NodePlacement and existing relation EdgeRoute records. Do not distort scenario arrows into fake semantic relations just to use EdgeRoute. Do not force every scenario representation into a generic rectangle with meaningless fields. Add typed scenario presentation keyed by occurrence/lifeline identity and typed qualified-process presentation keyed by full call path. These records remain inside the same Diagram, with the same history/source owner. This is a deliberate domain distinction, not separate persistence technology.

Proposed persistence contract

This section is an implementation candidate requiring specification review, not a declaration of existing syntax. The current schema/source version is7. Reserve a new version during integration; examples below use8 provisionally. Coordinate the version with other schema owners before editing it.

1. Add ProjectionKind::Process { process: Id } accepting a Process or FunctionalChain owner, and Scenario { scenario: Id } accepting a Scenario, each in the diagram's layer. A diagram has one explicit owner. Multiple saved views of that owner are legal and independent. Owner identity and diagram identity are distinct.
2. Process direct occurrence boxes use ordinary Diagram.nodes: one placement per included occurrence in a view, positioned independently of its represented work/exchange. Explicit SequenceLink and ContextualLink geometry uses ordinary Diagram.routes. Moving any process node changes only its placement; it does not edit links, parent, steps, represented element, or allocation. Automatic rank is only a seed/explicit Arrange result.
3. A typed optional process presentation block holds context_nodes and context_routes. A contextual node key is OccurrenceEndpoint { references: Vec<Id>, occurrence: Id }. A contextual route key is { references: Vec<Id>, edge: Id }, where the edge belongs to the resolved called process. Direct ContextualLink edges still use their own relation ID in normal routes. Each key is unique per view. Retain full IDs in the scene, including preview links; never use labels, tile indices or abbreviated paths as keys.
4. A typed optional scenario presentation block has separate records for lifeline headers (lifeline, x, width, height), message anchors (occurrence, desired y), boxes/frames (occurrence, desired rectangle), operand presentation extents, and message routes (occurrence, pinned waypoints, optional EdgeLabel). Types reject inapplicable fields. Lifeline x is presentation order: the present metamodel does not contain Sirius's explicit semantic instance-role ordering, so do not invent one. Normalized route-label fractions/offsets and finite coordinate/size limits reuse existing primitives.
5. Scenario box/frame time anchors have one canonical derivation from their rectangle (specified per kind, e.g. top event/header anchor); no competing stored y values for one occurrence. Birth/death ends and execution intervals remain derived semantic attachments. Header x/size is authored; creation timing determines its vertical attachment. A box attached to a lifeline may have a presentation x offset/leader while retaining the same lifeline reference. A cosmetic horizontal move must never rebind its participant.
6. Persisted process child coordinates are absolute, matching normal nodes. Moving a reused group translates its visible descendant presentation records in one batch if group movement is selected; resizing a containing frame preserves child authored coordinates, consistent with #16. Scenario frame resizing changes frame geometry and available space; it does not silently add/remove covered events, change operands or move semantic ownership.
7. Valid, feasible authored geometry is used exactly. Missing records use deterministic initial geometry. Passive rendering/navigation never creates records, marks dirty, saves, or resets authored geometry. Existing records survive collapse, temporary invisibility, filters and owner renames. Delete/reidentify/reparent/view-owner changes must explicitly clean or transform dependent references in the core transaction; stale path records cannot silently bind to a new same-named object.
8. New records count against parse/model limits; route points retain a bounded per-route limit. Resolve caller paths with existing cycle/depth defenses and a bounded visible expansion budget. An explicit partial expansion is not permission to discard invisible authored records. Large stored layouts should not be rebuilt in App.update per pointer move.

Example candidate source, following existing constructor/record conventions:

arcadia 8;
// Existing semantic declarations omitted for brevity.
diagram response_view "Response workflow" {
    layer Oa;
    projection { Process { process @oa_response; }; };
    routes [{ edge @oa_confirm_path;
              waypoints [{ x 580; y 110; }, { x 580; y 360; }];
              label { fraction 0.5; offset { x 0; y -16; }; }; }];
    process_layout {
        context_nodes [{ endpoint { references [@oa_assess_step];
                                    occurrence @oa_assessment_action; };
                         position { x 95; y 185; };
                         size { width 210; height 85; }; }];
    };
}
node confirm_view {
    diagram @response_view; element @oa_confirm_step;
    position { x 710; y 350; }; size { width 320; height 125; };
}
diagram conversation_view "Conversation" {
    layer Oa;
    projection { Scenario { scenario @oa_conversation; }; };
    scenario_layout {
        lifelines [{ lifeline @oa_caller; x 180; width 240; height 90; },
                   { lifeline @oa_responder; x 660; width 280; height 90; }];
        messages [{ occurrence @oa_call; y 210; },
                  { occurrence @oa_reply; y 390; }];
        message_routes [{ occurrence @oa_call;
                          waypoints [{ x 430; y 240; }];
                          label { fraction 0.55; offset { x 0; y -20; }; }; }];
    };
}

oa_call and oa_reply intentionally have independent anchor/route records although the release fixture uses the same underlying oa_contact exchange for both. oa_confirm_path is the fixture's explicit link from oa_merge to oa_confirm_step. Exact grammar, diagnostics and canonical formatting must be specified and round-tripped before UI depends on this candidate.

API candidate: existing CreateDiagram/CreateNode/MoveNode/EditNode/SetEdgeRoute remain ordinary direct-process operations. Add typed upsert/remove operations for contextual nodes/routes and scenario lifelines/items/message routes, or one EditBehaviorLayout { diagram, patch } with a strictly tagged list of those operations. Prefer bounded per-record patches for scripting and safe comment retention; retain full EditDiagram replacement for existing generic clients. Do not make full-diagram replacement the only geometry API. A scenario message move changes its anchor and any explicitly previewed affected neighbor anchors in one Batch; an explicit reorder adds SetSteps to that same batch. REST uses the existing conditional transaction route and concurrency rules. Source writeback updates only the owning diagram declaration/file and matches nested comments by full typed key.

Scenario drag policy: compare before deciding

The user requested movable arrows, not implicit behavioral mutation. In the current model, ordered occurrences and operand membership carry sequence meaning independently of their visual y. There are two materially different policies:

Policy	Benefit	Risk	Assessment
Ordinary drag crossing another event commits SetSteps	Closest to Sirius event reorder; quick behavioral edits	An engineer making room for a long label can change execution; a few pixels of overshoot is consequential; source diff mixes geometry with semantics	Do not make this the default without direct user-workflow evidence
Ordinary drag edits presentation; explicit Reorder changes steps	Cosmetic operations preserve semantics; source diff/Undo intent is clear	Need an understandable constraint/ripple preview and an accessible reorder command	Recommended default

Within the second policy, a hard tiny-gap clamp would remain frustrating and could repeat the rigid-canvas failure. Prefer a local spacing planner: drag within available space moves the chosen anchor; dragging farther proposes moving the affected following/preceding event block while retaining semantic order. Show every moved row in the preview. The user can insert/remove vertical space directly, spread lifelines freely, move labels/bends independently, and resize boxes/frames. A selected arrow itself is the handle for movement; no left-margin rectangle is required. A pointer cursor/status can say “Move message” or “Reorder message” according to the active action. Do not silently fall back from a blocked layout move to semantic reorder.

Provide named Reorder in the common context menu/Properties actions and keyboard accessibility. An optional modifier may invoke the same action after it is discoverable; the modifier is not the sole route. Reorder shows a before/after insertion marker in the actual operand and previews lifecycle/activation changes. Cross-operand movement remains a separately named semantic action until its valid rules are implemented. Complete reorder in one atomic semantic+layout transaction, not a SetSteps commit followed by a best-effort geometry save.

Two storage choices for constrained y require an early evaluator:

• Absolute desired anchors are easy to understand in text and support precise coordinates. When source editing changes steps without adjusting layout, the pure projector must resolve only actual order/containment conflicts, retain authored values and report displaced anchors; it must not allow a contradictory rendered sequence or rewrite source during render. GUI reorder should persist its previewed resolved anchors, so reopen matches exactly.
• Nonnegative gap-before records naturally survive order edits and make blank-space insertion simple. They are less direct for exact coordinates; box-height changes move downstream events by construction, and frame/nested-call constraints still need a solver. They also risk recreating an automatic-only layout if exposed as the only UI freedom.

Recommend absolute desired anchors plus a deterministic, explicitly tested local conflict resolver, subject to falsification on source reorder/nesting fixtures before commitment. A conflicting source layout is a presentation diagnostic, not grounds to reject a semantically valid model or silently mutate its order. The renderer must distinguish stored geometry from resolved geometry. No broad layout run occurs on selection, property inspection, camera changes, label edits that still fit, or switching views. If the resolver cannot meet hard semantic anchors, it produces a clear bounded conflict result; it does not claim that an unsearched resize/move is impossible.

Connection bends are presentation-only. Process edges attach to their existing source/target occurrences; route handles move/add/remove pinned points and labels use existing fraction+offset behavior. Scenario message ends remain attached to the existing sender/receiver and event anchor; interior bendpoints/label offsets do not encode send/receive order. Self-message loops must be resizable/routable while preserving their occurrence identity. Reconnection is a different visible handle/action and uses semantic validation. Derived legacy process adjacency lacks a stable relation ID: either give its presentation a typed {source_occurrence,target_occurrence} key with lifecycle rules, or require an explicit link before authoring its route. Never create a hidden SequenceLink as a side effect of dragging an elbow. This is a concrete remaining route-coverage decision for legacy fixtures.

Interaction and architecture boundaries

Extract pure process/scenario geometry projection into oa-core (or an existing UI-free shared crate if the core layering demands it). Inputs are project, explicit view identity/presentation, and bounded expansion state. Outputs have stable typed representation targets, actual hit bounds, attachment anchors, routed polylines, constraints and diagnostics. Fonts/text measurements need a deterministic shared interface or conservative documented metrics; do not put Iced types into persisted data. Keep initial layout and explicit Arrange as planners separate from projection. The same candidate projector must drive drag preview, committed render, navigation bounds, export and geometry tests.

Reuse architecture route math/label projection and peer resize planning rather than copying its algorithms into both behavior renderers. The existing routing::route_diagram is coupled to projected diagrams, so first reuse primitives or adapt typed scene edges; do not pretend it already accepts sequence events. Process graph topology/rank logic remains valuable for initial/selected Arrange. Scenario lifetime/call semantics remain a separate input to geometry.

Interaction state is transient: Gesture { document, diagram, owner, revision, epoch, target, original, candidate }. Pointer-down resolves one exact rendered target, pointer moves only update a candidate, and release revalidates the complete scope before one normal transaction. Escape, focus loss, document/view switch, modal entry, source changes and stale revisions cancel without history. Zero movement retains exact authored data. Camera changes must either transform the captured gesture consistently or cancel it; they cannot replay a saved release against a new view. Peer resize hit arbitration must order visible resize/route handles ahead of overlapping invisible port slop.

Canvas is always present and pointer-active whenever its document is editable. Remove the user-facing Canvas activation button and mode-dependent hiding of editing essentials. F6 may remain ordinary focus traversal; text inputs still own text/navigation keys, and dialogs/drafts retain their existing guards. “Always active” must not make Delete/arrow keys operate behind a focused Properties text field. Keep the stamped control/input protection already introduced in the camera prerequisite.

Use one conventional selection and Properties workflow: click a box/arrow selects it, selected objects display familiar handles, double-click/name action edits its name, context menu offers relevant semantic actions, and the common Properties panel follows selection automatically. Replace the Details shelf with this panel; avoid a second selection editor or tiny reorder controls. Tools remain available in a compact palette. At the minimum supported window, the panel must be collapsible/resizable or use a stable shared inspector region; selection must not shift the canvas coordinate origin mid-gesture. The existing300px opaque overlay is evidence of current behavior, not proof that it is an acceptable final layout. Root needs native evaluation for hit size, palette contrast, long names and keyboard flow.

Saved-view identity must propagate to Scope, process/scenario State identity, camera cache, recovery target and diagram-usage navigation. Current process/scenario usages identify owner-based surfaces; multiple views require the saved Diagram ID as well. Qualified occurrences retain their full paths. Navigation selects/reveals the actual saved appearance without creating a view, resetting geometry or applying drafts. Camera can remain session-local; authored expansion/collapse affecting the saved view must have an explicit persistence policy rather than being conflated with camera focus.

Migration, source edits and lifecycle

• Old version7 source/JSON loads without manufacturing views or geometry. New optional blocks default absent. Frozen old-version readers must reject new fields/owner constructors rather than silently accept and drop them. Update schema gates, serde/parser defaults, formatter, strict reST, API schemas/OpenAPI, source limits and transition/copy/reference walkers together.
• With no saved behavior view, show the current deterministic initial presentation and allow immediate gestures. The first accepted geometry edit creates the saved view and required initial presentation in the same Undo transaction. This is an internal lifecycle, not a new Canvas-enable prompt. View creation must allocate IDs once before preview/source preparation; no render-time random IDs. Merely opening a scenario remains clean.
• Decide whether initial capture is complete or sparse before implementation. Complete capture of the currently rendered direct surface gives stronger protection against unrelated future edits moving objects; sparse overrides create smaller source but leave untouched objects dependent on changing automatic ranks. Recommend complete direct-surface capture on the first layout edit, with unseen qualified expansions initialized lazily. Preserve omitted/invisible semantic objects as omissions; do not turn opening a view into a semantic model synthesis.
• Changing semantic names preserves positions/routes and grows/clips only according to an explicit content-size policy. Show long names through wrapping, handles and Properties; automatic size growth cannot silently overwrite stored dimensions. New objects get a local collision-aware initial position and do not trigger Arrange All.
• Deleting a view removes only presentation; deleting an occurrence removes its direct/qualified layout and route keys; deleting a caller invalidates paths through it; reidentification transforms every reference while preserving geometry/comments. Changing an owner or reparenting must reject or explicitly repair incompatible presentation in the same transaction. Coordinate these dependency walkers with peer Delete ownership before touching them.
• Source reorder and semantic relation edits must preserve all nonconflicting authored geometry. Layout diagnostics/derived conflict resolution must be deterministic and available outside the GUI. Text-only users can fully author the same representation and reset individual routes/placements without opening a window.
• Saving/reopening, REST import/export, copy/transition and undo/redo must preserve distinct repeated occurrences, qualified paths, pinned route points and source comments. A route whose edge is temporarily hidden remains stored, matching existing architecture semantics.

Milestones and acceptance that can falsify this proposal

1. Contract/core slice first. Choose schema ownership and event-anchor policy; implement one owner-bound process view with ordinary nodes/routes and one two-lifeline scenario view with separately keyed call/reply anchors/routes. Prove parse/format/model equality, JSON/source migration, REST conditional transaction and one-Undo source parity before expanding gestures. Independent tests must use expected coordinates/semantic invariants, not merely call the same planner twice.
2. Shared geometry/resize integration. Extract scene projection and connect the #16 candidate planner. Exercise eight handles, active/inactive axes, port/state counterexamples where shared code applies, collapsed reuse and nested frame bounds. Demand projected preview=commit=reopen, cancellation=no change, child authored coordinates unchanged on resize. Failed bounded search is not proof of a minimum.
3. Direct manipulation and Properties. On the actual minimum window and realistic large model, enter a process/scenario and immediately drag the object itself, resize from each handle, edit a bend/label, select and change a property. No activation button, Details detour, unexplained rectangle or moving viewport origin. Test text focus, Tab/F6/Escape, touchpad/mouse camera, modal entry mid-drag and dirty-source refusal/recovery.
4. Behavior-specific depth. Process cycles/parallel links, repeated callee appearances and expanded nested callers; scenario same-exchange call/reply, self-message, long lifeline labels, create/delete, ALT/PAR/LOOP operands, ScenarioUse and nested activation #21. Verify routing/labels and bounds after every move. Finish all visible object kinds rather than calling the simple fixture feature-complete.
5. Preservation/regression/package. Source comments across included files, two views per owner, hidden routes, reidentify/delete, conditional REST stale revisions, save/reopen, undo/redo, source reorder conflict diagnostics, navigation to the exact saved appearance, and long-model responsiveness. Root must run native workflow review and fresh independent critique, then integrate/publish a versioned milestone with honest remaining issues.

Concrete user-workflow checks:

• In scenario_oa_conversation.arcadia, widen/spread caller/responder until the full call label is readable, move call/reply to separately chosen y positions, edit only the call route, save and reopen. Underlying exchange IDs, reply_to, sender/receiver, steps and lifetime semantics are byte-for-byte unchanged after cosmetic operations. The two appearances retain different geometry.
• Drag the call down across the reply's initial screen row. Default movement preserves semantic order and shows any spacing/ripple adjustment. Invoke Reorder explicitly and verify a valid/invalid preview according to call/reply semantics; there is no automatic SetSteps hidden in ordinary drag.
• In process_oa_response.arcadia, put the confirmation box below/left of its previous rank column, resize it, bend its explicit incoming edge around another object and move its label. Links/steps/represented work do not change. Reopening does not return the box to a rank column.
• Place two references to the assessment procedure, expand each, position/resize one visible inner occurrence and route an inner link where present. Only that caller path changes; opening the callee definition and the other caller is unaffected. Collapse/reexpand retains it.
• Resize a fragment around existing operands, then resize a reuse card: child authored coordinates and semantic membership stay unchanged. Use a separately named semantic action to change membership. New nested activation support must use the same geometry contract rather than regenerate all rows.
• Edit names/steps in source with comments and included files; undo restores both source and geometry. A source reorder that conflicts with authored y produces a deterministic, inspectable presentation result without rejecting a valid model, silently saving, or editing semantics from pixels.

Remaining decisions and limits

The proposed absolute-anchor conflict resolver, local ripple behavior, legacy derived-path route identity, saved expansion policy, and exact Properties layout need early independent evaluators/native evidence. They are explicit design questions, not authorization to defer basic persistence or free manipulation. Capella's behavior is a comparison, not the required product specification.

Official primary references support the distinction: Sirius sequence user documentation describes movable lifelines, stored header height, manual blank-space insertion and order-preserving layout. Its sequence specifier documentation explicitly delegates event/instance reordering to semantic tools when graphical movement changes order. General Sirius diagram documentation supplies ordinary shape movement/resizing, route bendpoint and label interactions. These are useful interaction precedents; they do not prove native Capella's current configuration or justify copying its menu density. Capella's official feature overview distinguishes functional, exchange and interface scenarios; the same presentation architecture should apply across the application's supported scenario viewpoints rather than fixing only one.