117 lines
7.3 KiB
Markdown
117 lines
7.3 KiB
Markdown
# 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.
|