Plan whole saved-view model deletion from exact visible groups

harness/saved-group-removal-policy-20260925.md

@@ -0,0 +1,116 @@
+# Saved Architecture and State aggregate model removal
+
+Development policy under [issue 29](http://217.177.34.108:3000/sorokin.oleg.edu/ARCADIA-Studio/issues/29),
+derived from the [multiple-selection contract](multiselect-contract-20260923.md)
+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.