84 lines
5.1 KiB
Markdown
84 lines
5.1 KiB
Markdown
# Direct Allocation drawing — issue 30
|
|
|
|
Branch-specific design above `17f1f89fef4a6bf520f4b09a2116548b967d030e`,
|
|
on `codex/allocation-drawing-ytr83r-20260923`.
|
|
[Issue 30](http://217.177.34.108:3000/sorokin.oleg.edu/ARCADIA-Studio/issues/30)
|
|
holds live scope and acceptance. This note records the intended interaction and
|
|
verification criteria, not completed tests, native acceptance or integration.
|
|
|
|
The user reports that Allocation cannot be drawn from the tools menu in
|
|
Containment. Core semantics and the existing relationship form already support
|
|
the relationship there; the direct canvas tool is the missing affordance.
|
|
Adding that tool follows the same source/target workflow as neighboring tools.
|
|
A form shortcut alone would still require a dropdown instead of clicking the
|
|
visible endpoints, leaving the reported drawing task unresolved.
|
|
|
|
## Interaction and scope
|
|
|
|
Choose Allocation in the diagram palette, click any visible eligible performer,
|
|
then click compatible unallocated leaf work in the same semantic layer as that
|
|
performer. The performer's layer need not match a mixed traceability view's owner
|
|
layer. OA uses an Entity or Actor and an
|
|
Activity; SA uses a System or Actor and a Function. Highlighting and the current
|
|
source identify the proposed semantic direction: performer to work, independent
|
|
of where their cards are drawn. Escape cancels the unfinished connection.
|
|
The existing Create relationship form remains an alternative for explicit
|
|
relationship entry; no new Activity or Function is created by this tool.
|
|
|
|
Projection eligibility requires support for both performer and work cards:
|
|
Containment, All relationships, OA ↔ SA traceability and Architecture · allocated
|
|
work offer Allocation; Functional dataflow, Missions & capabilities and dedicated
|
|
State-machine views do not. Containment and All relationships can display the resulting Allocation line
|
|
when its placements and filters permit. Architecture · allocated work represents
|
|
the same responsibility through nesting, not an additional Allocation arrow.
|
|
OA ↔ SA traceability can contain both layers, but Allocation endpoints must
|
|
still belong to the same layer as each other. Selecting an opposite-layer source
|
|
retains the captured mixed diagram and prior application perspective; cancellation
|
|
also preserves that perspective. After successful creation, the ordinary model
|
|
synchronization sets the application perspective to the captured diagram's owner
|
|
layer while keeping that diagram open. A projection that omits one endpoint category
|
|
must not offer an unusable drawing workflow. Existing filters remain unchanged;
|
|
successful creation does not promise that a filtered line is visible.
|
|
|
|
## Preservation rules
|
|
|
|
- Allocate only eligible leaf work with no existing direct performer. Reject
|
|
duplicate, occupied, composite, cross-layer and Port endpoints; do not treat
|
|
drawing a new relation as permission to reassign existing work.
|
|
- Core validation is authoritative at completion, in addition to candidate
|
|
highlighting. Candidates must be actual projected endpoints, not hidden
|
|
children or computed parent summaries.
|
|
- Create one Allocation in one document transaction. Preserve semantic parents,
|
|
elements, other relationships, traces and every saved placement, route and
|
|
view option. Derived projection geometry may change because responsibility
|
|
changed; that is distinct from rewriting stored layout.
|
|
- Arming, choosing only a source, refusal and cancellation do not alter model
|
|
history. Stale document/revision/diagram, navigation and pending property or
|
|
source edits must prevent delayed completion without discarding those drafts.
|
|
- Moving cards in Containment remains ordinary arrangement. Assignment-changing
|
|
drag and Arrange next drag retain their existing allocated-work-view scope.
|
|
|
|
No general relationship browser, new reassignment policy, port generation or
|
|
change to ownership semantics is introduced. The existing connection lifecycle
|
|
and ordinary validated command boundary are preferred over a parallel gesture
|
|
framework. Broader form-only relationship kinds are outside this bounded fix.
|
|
|
|
## Acceptance criteria
|
|
|
|
Exercise real connection events for valid OA and SA endpoint pairs, rejected
|
|
endpoint classes, cancel/retry, hidden endpoints, stale captures and pending
|
|
drafts. Compare the complete Project so the only semantic difference is the new
|
|
Allocation; bind its fresh identity explicitly. Check exact source Undo/Redo
|
|
and unchanged stored reference-view records. Verify projection eligibility for
|
|
the new tool without regressing the existing four connection tools.
|
|
|
|
In the actual application, find Allocation in Containment's palette, choose a
|
|
performer and existing leaf work directly, inspect the resulting relation,
|
|
Undo/Redo, Save, close normally and reopen. Confirm feedback explains nesting
|
|
when using the allocated-work projection, rather than promising a new line.
|
|
Inspect nested-card hit selection and filtered-result feedback. Native evidence
|
|
must distinguish observed interactions from automated coverage and bind source,
|
|
binary, process and predeclared full-Project expectations. No successful result
|
|
is asserted here. Linux remains user-paused; combined release acceptance belongs
|
|
to the integration owner.
|