ARCADIA-Studio/harness/issue28-transition-overview-assessment-9e8r6t.md

Issue 28: iterative transitions and computed overview links

2026-09-13. This bounded assessment addresses C1 and C4 of the user's research attachment. Implementation references below are to 9438310715, not an uninspected future integration. It complements the published C3/C5 assessment. This is a source/specification assessment with explicit proposed experiments; no new build, native workflow, interchange or performance result is claimed.

Primary-source check

The report's C1 description is supported by Capella's pinned iterative transition guide. Trace links support repeated transformation and a candidate merge view. Its examples retain a target after source deletion, but can move a target or recreate a deleted target on rerun; rules may differ by transformation. Thus “conservative” is not a universal promise to leave every target edit untouched. Studio needs explicit policies and refusal/review behavior, not just that adjective.

For C4, Capella's functional-analysis rationale describes non-leaf functions as grouping constructs and displaying detailed dependencies at higher levels. This page compares historical SysML v1; it cannot establish a limitation of SysML v2. The official computed-links description independently confirms that simplified diagrams derive higher-level links from lower-level exchanges. These sources support a modeling workflow benefit, not a measured productivity claim or a requirement to materialize additional flows.

C1: iterative transition assessment

Existing capability. The ordinary transition planner reuses a single traced counterpart, reports multiple-counterpart ambiguity, supports explicit existing/new-target choices, and reviews name/description changes against separate baselines. Its public contract deliberately preserves existing typed bodies. That does not imply structural review is absent: the newer typed semantic interface includes Parent/Child facets, explicit correspondence, Keep/Take/candidate decisions, agreement checks and review of induced cleanup. Both apply paths reject stale plans and preserve planned generated IDs. Existing workflows, review_regressions and r3_semantic tests exercise these distinctions; child_membership_and_parent_resolutions_agree_by_actual_child_slot specifically checks compatible structural changes and rejects conflicting parent choices.

Deletion needs precise language. Reference cleanup removes a trace when either endpoint is deleted; it does not traverse that trace to delete the other endpoint. workflows::deleting_source_cascades_owned_records_but_keeps_other_layer_counterpart checks retained counterpart existence and exact Undo. Thus source deletion preserves downstream existence but removes the pair's trace and review baseline. This differs from a deleted historical member ID retained inside a surviving trace, which the typed contract explicitly permits. The existing deletion test is not an exact comparison of a richly populated retained counterpart.

Static retry consequence. After target deletion, a fresh implicit plan can create another target because the original trace is gone. An explicit mapping to the deleted target conflicts, and an old plan is stale. After source deletion and recreation under a new UUID, an old retained target has no automatic correspondence to that new source. An implicit plan can create a second target; explicit mapping can relink the retained one. Name matching must not replace identity. Whether to retain deleted-endpoint provenance is an open lifecycle/UX decision, not evidence that the current engine deletes downstream design work.

Next acceptance cases. These are proposed evaluations, not newly executed results:

1. Create an isolated traced Activity/Function pair with target children, ports, relations, placement and artifact. Delete the source and compare the entire retained target subgraph, with source-owned removals and trace removal stated explicitly. Undo restores the complete original project/source. Repeat in the reverse direction.
2. In a separate branch of that fixture, delete the target and replan implicitly: create one new counterpart, then replan unchanged without duplicating it. Check old-plan rejection, an explicit mapping to the deleted target, exact save/reopen and API retry preconditions. An intentional explicit request for another new counterpart is a separate valid operation.
3. Delete and recreate the source under a new identity; compare implicit creation with explicit reuse of the retained target. Observe whether an engineer can understand trace loss, discover the retained target and relink it. Establish this workflow before selecting tombstones or any automatic matching rule.
4. Change upstream ownership and edit target content. Verify that prose review preserves structure, while explicit typed Parent/Child review presents the agreed change, respects Keep and refuses contradictory proposals. Reuse the existing structural oracles; a realistic GUI task must separately establish usability.

The inspected suites contain useful component tests but do not establish the whole endpoint-deletion→retransition workflow above. The report's later logical/physical levels remain future layers by the user's explicit release scope; OA↔SA conservation and understandable review are current requirements. C1 supports improving these lifecycle checks and explanations, not replacing a transition engine that already exists or blindly importing Capella's target-relocation rules.

C4: existing preservation and the remaining overview boundary

Existing contract. Language section 8 distinguishes functional reparenting, performer allocation and moving a diagram placement. Reparenting must not silently change the performer. The allocation rule forbids treating a computed parent summary as another semantic allocation. Section 5 permits collapsed links to end at an ancestor without creating a new port or exchange. These distinctions already address an important part of C4; they should be preserved through later extensions.

Existing implementation. projection.rs::parents derives visual nesting from containment or allocation, while ProjectedEdge.id remains the original relation ID. project_diagram_impl promotes a placed but folded endpoint through its visible ancestor chain; edges.push retains that relation ID. The desktop diagram's selection-context path passes the same edge ID to object actions. A projected link therefore has an existing semantic identity to inspect. This is source evidence of that connection, not native proof that every crowded edge can be selected conveniently.

Existing reusable tests. release_diagrams::port_identity_collapse_and_group_movement_do_not_invent_semantic_edges checks collapsed endpoint promotion, absent invented ports and unchanged semantic relations. unplaced_work_parent_cannot_detach_a_leaf_from_its_visible_performer checks allocation summary placement. language::nesting_tests::checked_in_example_supports_cross_file_reparent_without_changing_allocations checks exact relation preservation, declaration/comment movement and untouched bundle files. All three are named PASS in the already published full-core evidence, whose relevant production code is unchanged here. They do not exercise the parent-only overview case below.

Source-level limitation. At projection.rs:355, endpoint anchoring begins with placed.get(&owner). If the leaf owner has no placement, traversal never starts, even if its semantic ancestor is shown. This differs from hiding a placed leaf by collapsing its parent. A parent-only diagram therefore does not obtain descendant exchange links through this mechanism. edge_availability can report EndpointNotShown; it does not derive a replacement summary. This is a precise boundary in the inspected code, not a runtime observation or a claim that all computed links are absent.

The current ProjectedEdge represents one original relation, not a multi-relation summary. Several promoted exchanges can remain distinct. Lack of a contributor-set type alone does not prove a defect: a bundle is only needed if the chosen interaction combines those exchanges into one displayed object. The required invariant is that every displayed summary can identify all contributing original exchanges without introducing additional communication or control semantics.

C4 acceptance experiment and candidate choice

Use stable semantic identities G1, G2, G3, leaf functions A, B, typed input/output ports AI/AO and BI/BO, and exchange E directed from AO to BI. Fix performers P (System) and Q (SystemActor), with allocation relations PA=(P,A) and PB=(Q,B). Initially A.parent=G1 and B.parent=G2; the grouping parents are not directly allocated. Create a functional-dataflow diagram containing placements only for G1/G2/G3. This small fixture isolates the behavior before scaling to the report's 200-function workflow.

1. In an explicitly selected computed-overview mode, the G1→G2 displayed link identifies E and its real ports. No placements for A/B and no additional semantic relations are required merely to obtain the overview.
2. Reparent A into G3. A, its ports, E, PA and PB keep their identities and meanings. The overview becomes G3→G2. Source/JSON/REST round trips preserve the complete model; Undo restores the original parent and view result together.
3. Using the initial hierarchy as a control, place A/B and collapse G1/G2. Existing folded-link behavior remains unchanged. In both ordinary and computed-overview modes, adding E to hidden_edges suppresses E; removing that explicit exclusion restores it. Its explanation differs from missing placements or internal folded connections.
4. Add E2 directed from BO to AI, plus new leaves C/D in G1 with typed ports connected by E3. The contributing directions are exactly A→B and B→A; after reparenting, their displayed directions are G3→G2 and G2→G3. Preserve them as separate direction groups or explicitly show both directions, never silently replace them with an undirected flow. If links are visually bundled, selecting the bundle exposes exactly its eligible contributors; E3 is represented as internal detail, not invented as an external flow. Selection filters and categories must not silently lose provenance. An ordinary detailed view may continue displaying separate edges.
5. Repeat the corresponding ownership/interaction case in OA. Observe the actual GUI and exported SVG, including selection, drill-down, undo/reopen and dense labels. Then use 200 leaf functions to assess editing burden and responsiveness. This document contains no execution result for these proposed cases.

Candidate	Benefit and cost	Assessment
Pre-place all leaves, then collapse	Reuses existing projection; requires view membership and placement work proportional to hidden detail	Retain as the existing workflow and control, not proof of parent-only overview support
Explicit semantic overview projection	Resolves original endpoints to selected visible ancestors without creating semantic exchanges; needs clear membership/filter/selection rules	Preferred experiment for reducing view maintenance while preserving the existing model
Materialize extra parent-to-parent exchanges	Easy to draw but adds relationships that can be counted, exported or maintained inconsistently	Reject as the default representation of computed links

The preference is a scoped engineering proposal for the shared team, not an adopted schema change or ownership of the canvas implementation. Evaluate it with the fixture before adding a new persistent option, cache or abstraction. Preserve ordinary view behavior and coordinate any persisted option with graphical/textual/API parity.

Open interaction decision: existing “Hide from this diagram” removes a placement (model_menu.rs); the proposed mode deliberately includes exchanges of unplaced leaves. It must distinguish absent placement from an explicitly excluded semantic branch. Preserve ordinary Hide behavior and evaluate an understandable branch-exclusion workflow before selecting any new exclusion schema. Missing placement alone cannot encode both meanings. This is a prerequisite of the proposed experiment, not a reason to change all current diagrams implicitly.

Decision boundary

C1/C4 should become concrete regression and workflow criteria. The identified C4 extension primarily concerns projection and interaction; these two cases do not establish that a complete metamodel replacement is necessary. They also cannot settle the report's other SysML v2 proposals. Definitions/usages, invariant bindings, quantities, constraints, libraries, temporal concepts and broader interchange require their own mappings and acceptance decisions. Old scope-document omissions cannot narrow the user's full OA/SA goal.

Live ownership and prioritization remain in Gitea issues 28, 3 and 27. This assessment neither closes those issues nor substitutes for #11's pending native checks. Linux remains user-paused.