7.3 KiB
Saved Architecture and State aggregate model removal
Development policy under issue 29,
derived from the multiple-selection contract
and docs/language.rst section 8.1. Implementation and verification must be
identified separately; this document does not establish App/native acceptance.
User operation and identity
Keep Hide selected placements and plain Delete placement-only. An explicit Delete selected from model… action, also available through focused Shift+Delete, requests one semantic operation for the complete current group. Adding a port, relation or State row must never turn plain Delete into model deletion. Unsupported Hide mixtures explain the refusal without changing any member. Existing singleton behavior remains governed by section 8.1.
Every original typed target must be unique, structurally current and actually visible in the captured saved projection before deduplication or cascade normalization. A hidden, stale or unsupported member refuses the whole request, even if a selected ancestor would otherwise delete it. Pointer focus, current tool, revision, exact selection generation/primary and pending drafts remain App admission requirements, beyond this pure model planner.
| Selected visual target | Semantic deletion subject | Required identity evidence |
|---|---|---|
| Placement | Its referenced model element | Exact placement belongs to captured diagram and current projected node |
| Port | The semantic port itself | Exact visible port and its owner placement, not a promoted owner node |
| Stored edge | Its relation or trace record | Exact visible edge with corresponding stored identity; inferred edges are not deletable objects |
| State action/internal-transition row | Its StateAction or StateTransition relation | Exact visible row and state placement, not its referenced activity/function |
Whole-diagram targets, navigation-only Allocation groupings, Process/Scenario
targets and unsupported synthetic identities refuse this saved-view operation.
Saved Scenario presentations retain their dedicated local-occurrence adapter.
Admit each visual identity first, then delete each semantic subject once.
Current model validation forbids two placements of the same element in one
diagram (duplicate_placement); semantic deduplication must not admit such an
invalid project. The same element can appear in different diagrams, all of
which participate in deletion impact. Selecting both a state and one of its
rows is valid if both are visible.
Candidate and impact
Validate the accepted input project, resolve the complete subject set, then normalize only redundant Delete commands covered by existing core cascades. Ancestry alone is insufficient: selected owners, ports, incident relations, traces and action rows can overlap through dependencies. Deterministic normalization must not depend on click order or primary selection. Do not run separate validated singleton transactions; an intermediate candidate may be invalid even though the full group deletion is valid.
Execute one final Batch candidate using the existing core deletion semantics. The final candidate is authoritative for actual removed identities and changed surviving records. Assert every selected semantic subject was removed and no identity was created. Include elements, relations, traces, artifact links, diagrams and embedded placements in impact accounting. Do not estimate union impact merely by summing individual deletion counts; conditional allocation dependents and global view/reference pruning require the combined result.
The foundation chooses original core deletion-impact coverage to suppress redundant selected commands, with deterministic subject ordering. Coverage is only command normalization, never the final impact report. Compared with mutating a scratch project after every root, this keeps admission and coverage bound to the same accepted input and avoids treating immediate scratch cleanup as identical to the engine's deferred allocation cleanup. The final Batch and complete selected-subject removal check remain mandatory. Tests cover two endpoint allocations whose deferred cascades overlap, together with a direct exchange deletion. An attempted alternate-support counterexample was invalid: the current unique allocation, single performer and distinct boundary-owner rules exclude simultaneous direct/reverse mappings. Preserve those rules and test refusal of the invalid fixture; do not claim a union-only cascade case.
Show the number of visual targets separately from unique semantic subjects, then actual removed/updated records with searchable names, aliases and kinds. All placements of deleted elements across views are affected. Referenced work survives removal of a State action relation; trace endpoint counterparts survive deletion of a trace. A counterpart may itself be deleted when it was explicitly selected, but a trace must not cause implicit counterpart deletion. Do not invent replacement links, activities or state transitions.
Deleting an exchange can remove Process occurrences and alter implicit order or a reused definition's interpretation. Changed owner records must be shown; unchanged stored caller records do not prove unchanged caller behavior. Before App acceptance, compare derived effects on reused callers using the Process review approach, or explicitly resolve that review requirement.
The App must confirm the captured candidate through one Document transaction, which includes source synchronization. A failed source update, cancelled review or stale token must not partially change model, source, selection, camera or history. Success removes transient deleted selection, chooses a surviving inspection context and supports one exact model/source Undo and Redo. The review footer remains reachable while impact content scrolls or is filtered.
Verification obligations
- OA and SA; exact placement-to-subject mapping and other-view occurrences; invalid duplicate placements; nested semantic ownership; selected ancestors with selected descendants and incident connections.
- Exact ports with owner/edge mixtures, allocation dependency interactions, State rows and transitions preserving referenced work, and trace deletion preserving endpoints/counterparts.
- Wrong placement/port/row association, foreign/hidden/synthetic members, duplicates and cross-family inputs refuse before normalization. Selected ancestor coverage must not make an invalid descendant admissible.
- Independently construct the complete expected Project; inspect final Batch effects and exact source/history rather than comparing two calls to the same planner. Preserve unrelated views, authored metadata and surviving records.
- App stale/ABA/private-gesture/draft/tool/modal admission and failure recovery; actual Windows build plus native group review, Cancel, confirmation, Save, Undo/Redo/reopen. Bounded planner checks do not satisfy these later gates.
Rejected UI approach: overloaded plain Delete changes destructiveness when a row or edge joins a placement group. Explicit model deletion preserves a stable meaning and still supports a clear mixed semantic selection. Rejected planner approach: only removing selected ancestor duplicates misses non-ownership cascade dependencies; repeated validated singleton deletes can reject a valid union or create partial history.