Add direct diagram connections, movable ports, and contextual authoring

docs/api.html

@@ -775,8 +775,8 @@ envelope allows both bounded representations plus small framing overhead.
 Compressed or encoded request bodies and browser Origin requests are
 not supported.</p>
 <p>Model admission permits at most 5,000 elements plus relations, 20,000 total
-persistent records (including the project, views and placements), and 50,000
-ordered step references. Source declaration counts and decoded JSON record
+persistent records (including the project, views, placements, routes and manual
+port anchors), and 50,000 ordered step references. Source declaration counts and decoded JSON record
 counts are checked before structural validation. Legacy import counts the
 occurrences and placements migration will generate before validating or
 migrating that model. Exceeding these budgets returns <span class="docutils literal">422 model_limit</span>;
@@ -910,6 +910,30 @@ nor reserves IDs. A committed response omits the proposed model and source
 project. Commit must check the revision again. A no-op is successful with
 <span class="docutils literal">changed: false</span> and the original ETag.</p>
 </section>
+<section id="diagram-port-positions">
+<h2>Diagram port positions</h2>
+<p><span class="docutils literal">NodePlacement.port_anchors</span> is an optional list of
+<span class="docutils literal"><span class="pre">{&quot;port&quot;:&quot;&lt;port</span> <span class="pre">UUID&gt;&quot;,&quot;side&quot;:&quot;Top&quot;,&quot;offset&quot;:0.25}</span></span> records. Side is
+Left, Right, Top, or Bottom; offset is a finite fraction from 0 through 1,
+measured from top on vertical edges and from left on horizontal edges.
+The port must be a direct child of the placement's semantic element and occur
+at most once in its anchor list. Placement is presentation state; it changes
+neither semantic ownership nor port direction. Other diagrams are independent.</p>
+<p>The existing transaction endpoint accepts:</p>
+<pre class="literal-block">{&quot;commands&quot;:[{&quot;SetPortAnchor&quot;:{
+  &quot;diagram&quot;:&quot;&lt;diagram UUID&gt;&quot;,&quot;node&quot;:&quot;&lt;placement UUID&gt;&quot;,
+  &quot;anchor&quot;:{&quot;port&quot;:&quot;&lt;port UUID&gt;&quot;,&quot;side&quot;:&quot;Top&quot;,&quot;offset&quot;:0.25}
+}}]}</pre>
+<p><span class="docutils literal">SetPortAnchor</span> upserts by port UUID. <span class="docutils literal">RemovePortAnchor</span> takes
+<span class="docutils literal">{diagram,node,port}</span> and restores automatic positioning. Repeating a reset
+is a no-op only while the referenced port still belongs to that placement's
+element; missing or stale owners are rejected. Remove old anchors before
+reparenting in the same atomic batch. Both commands support ordinary dry run,
+ETag checks and source-project writeback. Rejected batches preserve the model,
+authored files and revision. JSON/source imports may omit <span class="docutils literal">port_anchors</span>;
+it defaults to <span class="docutils literal">[]</span> and empty lists are omitted on export. The normative
+diagram semantics and source spelling are in <span class="docutils literal">language.rst</span> section 5.</p>
+</section>
 <section id="contextual-process-and-chain-topology">
 <h2>Contextual process and chain topology</h2>
 <p>Operational processes and system functional chains can combine work

docs/api.rst

@@ -136,8 +136,8 @@ Compressed or encoded request bodies and browser Origin requests are
 not supported.
 
 Model admission permits at most 5,000 elements plus relations, 20,000 total
-persistent records (including the project, views and placements), and 50,000
-ordered step references. Source declaration counts and decoded JSON record
+persistent records (including the project, views, placements, routes and manual
+port anchors), and 50,000 ordered step references. Source declaration counts and decoded JSON record
 counts are checked before structural validation. Legacy import counts the
 occurrences and placements migration will generate before validating or
 migrating that model. Exceeding these budgets returns ``422 model_limit``;
@@ -291,6 +291,34 @@ nor reserves IDs. A committed response omits the proposed model and source
 project. Commit must check the revision again. A no-op is successful with
 ``changed: false`` and the original ETag.
 
+Diagram port positions
+----------------------
+
+``NodePlacement.port_anchors`` is an optional list of
+``{"port":"<port UUID>","side":"Top","offset":0.25}`` records. Side is
+Left, Right, Top, or Bottom; offset is a finite fraction from 0 through 1,
+measured from top on vertical edges and from left on horizontal edges.
+The port must be a direct child of the placement's semantic element and occur
+at most once in its anchor list. Placement is presentation state; it changes
+neither semantic ownership nor port direction. Other diagrams are independent.
+
+The existing transaction endpoint accepts::
+
+    {"commands":[{"SetPortAnchor":{
+      "diagram":"<diagram UUID>","node":"<placement UUID>",
+      "anchor":{"port":"<port UUID>","side":"Top","offset":0.25}
+    }}]}
+
+``SetPortAnchor`` upserts by port UUID. ``RemovePortAnchor`` takes
+``{diagram,node,port}`` and restores automatic positioning. Repeating a reset
+is a no-op only while the referenced port still belongs to that placement's
+element; missing or stale owners are rejected. Remove old anchors before
+reparenting in the same atomic batch. Both commands support ordinary dry run,
+ETag checks and source-project writeback. Rejected batches preserve the model,
+authored files and revision. JSON/source imports may omit ``port_anchors``;
+it defaults to ``[]`` and empty lists are omitted on export. The normative
+diagram semantics and source spelling are in ``language.rst`` section 5.
+
 Contextual process and chain topology
 -------------------------------------
 

docs/language.html

@@ -1296,7 +1296,7 @@ capabilities with their involvement, exploitation, include, extend and
 generalization links. Decomposition and Overview retain general containment;
 Overview also exposes all relationships. Changing the projection hides
 inapplicable placements without deleting them or changing semantic records.</p>
-<p>Ports are calculated boundary anchors of visible owners, with their existing
+<p>Ports are boundary anchors of visible owners, with their existing
 semantic identity. An explicitly placed port is not rendered as a separate
 large node. Functional exchanges use their declared source/target ports;
 boundary exchanges attach to their participant ports even if those ports have
@@ -1305,13 +1305,45 @@ may terminate at a visible ancestor without creating a new port or exchange.</p>
 <p><span class="docutils literal">node</span> has an alias and identity but no display-name string. Required fields
 are <span class="docutils literal">diagram</span> and <span class="docutils literal">element</span> references. Optional fields are <span class="docutils literal">position</span>
 (record with x/y, default 0/0), <span class="docutils literal">size</span> (width/height, default 224/94), and
-<span class="docutils literal">collapsed</span> (false). Node identity is independent of its semantic element.
+<span class="docutils literal">collapsed</span> (false), and <span class="docutils literal">port_anchors</span> (empty list). Node identity is
+independent of its semantic element.
 Coordinates are absolute diagram coordinates. Placement does not alter parent,
 allocation, or realization. Hiding an element from a diagram must remain
 distinguishable from deleting it from the model.
 Changing a node's diagram preserves the placement identity, alias, coordinates,
-size, collapse state, and attached artifacts. The destination must accept the
-element's layer and must not already contain another placement of that element.</p>
+size, collapse state, manual port anchors, and attached artifacts. The destination
+must accept the element's layer and must not already contain another placement
+of that element.</p>
+<p>Each <span class="docutils literal">port_anchors</span> entry is a PortAnchor record with required <span class="docutils literal">port</span>
+reference, <span class="docutils literal">side</span> (Left, Right, Top, or Bottom), and <span class="docutils literal">offset</span> (finite
+binary32 from 0 through 1). It has no separate identity or alias. The port MUST
+be an existing Port directly owned by the placement's <span class="docutils literal">element</span>. A port MAY
+have one manual anchor per placement; different diagrams MAY position it
+independently. List order is preserved but has no positional meaning.</p>
+<p><span class="docutils literal">offset</span> measures a fraction of the complete projected owner edge, from top
+on Left/Right or from left on Top/Bottom. Zero and one denote its corners.
+The side is presentation data and MUST NOT change the port's contract,
+orientation, ownership, allocations, or connected exchanges. Absent anchors use
+automatic positioning. Empty lists are omitted in canonical JSON/source;
+earlier schema-3 input without this field hydrates as <span class="docutils literal">[]</span>.</p>
+<pre class="code text literal-block"><code>node actor_view {
+    diagram &#64;architecture; element &#64;vessel;
+    port_anchors [{ port &#64;communication; side Top; offset 0.25; }];
+}</code></pre>
+<p><span class="docutils literal">SetPortAnchor { diagram, node, anchor }</span> upserts by port identity and retains
+unrelated entries. <span class="docutils literal">RemovePortAnchor { diagram, node, port }</span> restores
+automatic positioning; it is a no-op only for an existing direct child port
+of that placement. Unknown fields, duplicate port references, non-port or
+foreign-owner references, and invalid offsets are structural errors. Each
+anchor counts as one record against <span class="docutils literal">ParseLimits.max_records</span>.</p>
+<p>These commands use the same atomic history, conditional REST transactions, and
+source writeback as other presentation edits. Source references resolve across
+files, and anchor comments follow port identity. Reidentifying a port updates
+anchor references; deleting it removes its anchors. Reparenting MUST repair
+old-owner anchors in the same transaction, for example by removing them before
+the Reparent command. Moving, resizing, arranging, or folding an owner retains
+its authored sides and fractions. Frozen schema-1/schema-2 readers do not accept
+<span class="docutils literal">port_anchors</span>; their explicit migration supplies an empty list.</p>
 <p>Each <span class="docutils literal">routes</span> entry is an EdgeRoute record with a required <span class="docutils literal">edge</span> reference
 to an existing Relation or Trace, <span class="docutils literal">waypoints</span> (default <span class="docutils literal">[]</span>), and <span class="docutils literal">label</span>
 (default <span class="docutils literal">none</span>). Route records have no separate UUID or alias. An edge occurs
@@ -1615,7 +1647,8 @@ preserve authored comments and whitespace on Apply while inserting missing
 identities. Explicit canonical export remains a separate operation. Project
 update/export distinctions are described below.
 Camera position, selection, source cursor, and undo history are not stored
-model fields. Layout and collapse state inside NodePlacement are model data.</p>
+model fields. Layout, collapse state, and manual port anchors inside
+NodePlacement are model data.</p>
 <p>The pure <span class="docutils literal">format_bundle</span> exporter uses the same typed declaration writer as
 <span class="docutils literal">format</span>. It creates a small entry file, layer/category modules, separate
 activity/function roots and behavior contexts, and separate diagrams with their

docs/language.rst

@@ -638,7 +638,7 @@ generalization links. Decomposition and Overview retain general containment;
 Overview also exposes all relationships. Changing the projection hides
 inapplicable placements without deleting them or changing semantic records.
 
-Ports are calculated boundary anchors of visible owners, with their existing
+Ports are boundary anchors of visible owners, with their existing
 semantic identity. An explicitly placed port is not rendered as a separate
 large node. Functional exchanges use their declared source/target ports;
 boundary exchanges attach to their participant ports even if those ports have
@@ -648,13 +648,52 @@ may terminate at a visible ancestor without creating a new port or exchange.
 ``node`` has an alias and identity but no display-name string. Required fields
 are ``diagram`` and ``element`` references. Optional fields are ``position``
 (record with x/y, default 0/0), ``size`` (width/height, default 224/94), and
-``collapsed`` (false). Node identity is independent of its semantic element.
+``collapsed`` (false), and ``port_anchors`` (empty list). Node identity is
+independent of its semantic element.
 Coordinates are absolute diagram coordinates. Placement does not alter parent,
 allocation, or realization. Hiding an element from a diagram must remain
 distinguishable from deleting it from the model.
 Changing a node's diagram preserves the placement identity, alias, coordinates,
-size, collapse state, and attached artifacts. The destination must accept the
-element's layer and must not already contain another placement of that element.
+size, collapse state, manual port anchors, and attached artifacts. The destination
+must accept the element's layer and must not already contain another placement
+of that element.
+
+Each ``port_anchors`` entry is a PortAnchor record with required ``port``
+reference, ``side`` (Left, Right, Top, or Bottom), and ``offset`` (finite
+binary32 from 0 through 1). It has no separate identity or alias. The port MUST
+be an existing Port directly owned by the placement's ``element``. A port MAY
+have one manual anchor per placement; different diagrams MAY position it
+independently. List order is preserved but has no positional meaning.
+
+``offset`` measures a fraction of the complete projected owner edge, from top
+on Left/Right or from left on Top/Bottom. Zero and one denote its corners.
+The side is presentation data and MUST NOT change the port's contract,
+orientation, ownership, allocations, or connected exchanges. Absent anchors use
+automatic positioning. Empty lists are omitted in canonical JSON/source;
+earlier schema-3 input without this field hydrates as ``[]``.
+
+.. code-block:: text
+
+    node actor_view {
+        diagram @architecture; element @vessel;
+        port_anchors [{ port @communication; side Top; offset 0.25; }];
+    }
+
+``SetPortAnchor { diagram, node, anchor }`` upserts by port identity and retains
+unrelated entries. ``RemovePortAnchor { diagram, node, port }`` restores
+automatic positioning; it is a no-op only for an existing direct child port
+of that placement. Unknown fields, duplicate port references, non-port or
+foreign-owner references, and invalid offsets are structural errors. Each
+anchor counts as one record against ``ParseLimits.max_records``.
+
+These commands use the same atomic history, conditional REST transactions, and
+source writeback as other presentation edits. Source references resolve across
+files, and anchor comments follow port identity. Reidentifying a port updates
+anchor references; deleting it removes its anchors. Reparenting MUST repair
+old-owner anchors in the same transaction, for example by removing them before
+the Reparent command. Moving, resizing, arranging, or folding an owner retains
+its authored sides and fractions. Frozen schema-1/schema-2 readers do not accept
+``port_anchors``; their explicit migration supplies an empty list.
 
 Each ``routes`` entry is an EdgeRoute record with a required ``edge`` reference
 to an existing Relation or Trace, ``waypoints`` (default ``[]``), and ``label``
@@ -986,7 +1025,8 @@ preserve authored comments and whitespace on Apply while inserting missing
 identities. Explicit canonical export remains a separate operation. Project
 update/export distinctions are described below.
 Camera position, selection, source cursor, and undo history are not stored
-model fields. Layout and collapse state inside NodePlacement are model data.
+model fields. Layout, collapse state, and manual port anchors inside
+NodePlacement are model data.
 
 The pure ``format_bundle`` exporter uses the same typed declaration writer as
 ``format``. It creates a small entry file, layer/category modules, separate

docs/openapi.json

@@ -3615,6 +3615,32 @@
         ],
         "additionalProperties": false
       },
+      "PortAnchorSide": {
+        "type": "string",
+        "enum": ["Left", "Right", "Top", "Bottom"],
+        "description": "Presentation side of the owner placement; independent of semantic port direction."
+      },
+      "PortAnchor": {
+        "type": "object",
+        "description": "Manual position of a direct child Port on one owner placement. Each port occurs at most once per placement; this record has no separate identity.",
+        "properties": {
+          "port": {
+            "type": "string",
+            "format": "uuid"
+          },
+          "side": {
+            "$ref": "#/components/schemas/PortAnchorSide"
+          },
+          "offset": {
+            "type": "number",
+            "minimum": 0,
+            "maximum": 1,
+            "description": "Finite binary32 fraction of the complete owner edge, measured from top on Left/Right and from left on Top/Bottom."
+          }
+        },
+        "required": ["port", "side", "offset"],
+        "additionalProperties": false
+      },
       "NodePlacement": {
         "type": "object",
         "properties": {
@@ -3639,6 +3665,14 @@
           },
           "collapsed": {
             "type": "boolean"
+          },
+          "port_anchors": {
+            "type": "array",
+            "items": {
+              "$ref": "#/components/schemas/PortAnchor"
+            },
+            "default": [],
+            "description": "Per-placement manual port positions. Omitted and empty both select automatic positioning; empty lists are omitted on serialization. Duplicate port references are invalid."
           }
         },
         "required": [
@@ -4734,6 +4768,42 @@
             ],
             "additionalProperties": false
           },
+          {
+            "type": "object",
+            "properties": {
+              "SetPortAnchor": {
+                "type": "object",
+                "description": "Upsert manual port position by port identity on an existing owner placement, preserving unrelated entries. Port must be a direct child of the placement's semantic element.",
+                "properties": {
+                  "diagram": { "type": "string", "format": "uuid" },
+                  "node": { "type": "string", "format": "uuid" },
+                  "anchor": { "$ref": "#/components/schemas/PortAnchor" }
+                },
+                "required": ["diagram", "node", "anchor"],
+                "additionalProperties": false
+              }
+            },
+            "required": ["SetPortAnchor"],
+            "additionalProperties": false
+          },
+          {
+            "type": "object",
+            "properties": {
+              "RemovePortAnchor": {
+                "type": "object",
+                "description": "Restore automatic positioning for an existing direct child Port. No-op when that valid owner placement has no manual anchor for the port; wrong or stale ownership is rejected.",
+                "properties": {
+                  "diagram": { "type": "string", "format": "uuid" },
+                  "node": { "type": "string", "format": "uuid" },
+                  "port": { "type": "string", "format": "uuid" }
+                },
+                "required": ["diagram", "node", "port"],
+                "additionalProperties": false
+              }
+            },
+            "required": ["RemovePortAnchor"],
+            "additionalProperties": false
+          },
           {
             "type": "object",
             "properties": {

docs/scope.md

@@ -1,20 +1,20 @@
-# V2 scope and tradeoffs
+# Current scope and tradeoffs
 
-V2 implements a general systems-engineering workbench spanning Operational Analysis and System Analysis. The normative [language and editing contract](language.rst) defines the supported Studio profile. It does not claim full Arcadia, Eclipse Capella or SysML conformance. [Acceptance](acceptance.md), [validation](validation.md) and [current state](../harness/STATE.md) record what has actually been exercised; implementation and verification are distinct.
+Arcadia Studio implements a systems-engineering workbench spanning Operational Analysis and System Analysis. The normative [language and editing contract](language.rst) defines the supported Studio profile. It does not claim full Arcadia, Eclipse Capella or SysML conformance. The [first-release plan](../harness/PLAN.md) remains incomplete; [current state](../harness/STATE.md) records current implementation and verification. The [V2 acceptance](acceptance.md) and [validation](validation.md) records describe the earlier baseline, not acceptance of every subsequent change.
 
 ## Supported modeling profile
 
 | Area | Implemented semantics and authoring |
 |---|---|
-| Operational Analysis | Entities, actors, roles, activities, capabilities and processes; entity/work decomposition; leaf allocation; role realization/assignment; interactions and capability/process involvement |
+| Operational Analysis | Entities, actors, roles, activities, missions, capabilities and processes; entity/work decomposition; leaf allocation; role realization/assignment; interactions and capability/process involvement |
 | System Analysis | One System of Interest, external Actors, functions, missions, capabilities and functional chains; functional decomposition independent of the system boundary; allocation, functional/boundary exchanges and mission-capability links |
-| Data and interfaces | Information/material/energy/event exchange items, primitive/enum/record data types, typed fields with multiplicity/units, ports, interface contents, provided/required contracts and exchange allocations |
-| Behavior | Stable ordered exchange occurrences, repeated semantic exchanges, scenario lifelines and exchange/action/state occurrences, explicit ALT/PAR/LOOP/OPTIONAL fragments and branches, pre/postconditions |
-| States and conditions | Participant-owned state machines, regions, state/mode/initial/final nodes, trigger/guard/effect transitions, descriptive and linked entry/do/exit work, availability and constraints |
+| Data and interfaces | Information/material/energy/event exchange items, primitive/enum/record data types, typed fields with multiplicity/units, separate function input/output and Standard/Flow component ports, interface provision/requirement, port and exchange allocations |
+| Behavior | Process/chain work and exchange contributions, control topology and sequence reuse; scenario lifelines, correlated calls/replies, timers, action/state occurrences, ALT/PAR/LOOP/OPTIONAL fragments, scenario reuse and pre/postconditions |
+| States and conditions | Participant-owned state machines, nested regions, states/modes and typed pseudostates, signal/time/change events, trigger/guard/effect transitions, linked entry/do/exit work, availability and constraints |
 | Perspectives and evidence | Bidirectional counterpart creation/linking, reviewed name/description updates, many-to-many typed/manual traces, arbitrary artifact URI/revision/fragment references |
-| Views and editing | Multiple independent diagrams, decomposition/allocation nesting, collapse, dragging, pan/zoom/Fit/Arrange, SVG export, model explorer, typed property controls, exact strings, UUID/alias editing, history and source navigation |
-| Text and storage | Canonical `arcadia 2` language, persistent aliases/UUIDs, typed constructors, highlighting/live lint, recoverable invalid drafts, text/JSON equality, deterministic V1 migration and atomic saves |
-| Automation | Rust REST service for project/source/query/validation/transaction/transition/artifact workflows, ETag preconditions, bounded requests and atomic current-revision storage |
+| Views and editing | Independent diagrams, decomposition/allocation nesting, collapse, pan/zoom/Fit/Arrange, editable connection routes and labels, four-side port positioning, direct interaction/functional/boundary exchange tools, contextual menus, SVG export, model explorer and typed properties |
+| Text and storage | `arcadia 3` source projects with relative includes and nested declarations, stable aliases/UUIDs, a source-file tree, per-file drafts and diagnostics, comment-preserving graphical updates, exact model/source Undo/Redo, legacy migration, atomic saves and interrupted source-save recovery |
+| Automation | Rust REST service for project/source-bundle/query/validation/transaction/transition/artifact workflows, ETag preconditions, bounded requests and atomic current-revision storage |
 
 Graphical and textual parity applies to the persistent fields of this profile. Diagram placements are model data; camera, selection, source cursor and undo history are session state. Canvas gestures need not match textual operations one for one: typed inspectors and explicit commands expose precise semantics. Full source replacement must repair dependencies in its candidate, while graphical delete/reidentify commands maintain references automatically.
 
@@ -24,9 +24,11 @@ Graphical and textual parity applies to the persistent fields of this profile. D
 - Work decomposition and performer allocation are independent. Only leaves have direct allocations. A parent drawn within one performer can be a computed leaf summary, not an additional allocation. Role sharing does not create several direct performers for one function.
 - Nesting expresses semantic containment or the selected allocation projection. Placement movement does not change ownership or allocation. Hide and delete have different effects.
 - Counterpart creation copies mapped typed content and required references; existing-target updates compare only names/descriptions against a reviewed baseline. They do not synchronize arbitrary structure, reverse-engineer operational needs or automatically overwrite the other perspective. Scope follows ownership/reference dependencies, not every incident relationship.
-- Processes/chains use ordered exchange occurrences. Rich fragments belong to scenarios. Guards, expressions and state behavior text are descriptive; there is no execution engine. Mixed states and modes are permitted by this Studio profile.
-- OA boundary exchanges are a simplified operational-communication representation. Capability grouping is containment, not include/extend/generalization. Data/item references remain within their layer and can have explicit transitioned counterparts.
-- Stable aliases are retained; comments and formatting normalize on Apply. Artifact references retain author-provided URI/revision/fragment values without fetching or executing resources.
+- Processes/chains use contributions and explicit sequence links; imported ordered exchange paths retain their implied order until topology conversion. Rich fragments belong to scenarios. Guards, expressions and state behavior text are descriptive; there is no execution engine. Mixed states and modes are permitted by this Studio profile.
+- Preserved OA boundary exchanges use Legacy ports. Capability grouping is containment; include, extend and generalization use separate typed relationships in OA and SA. Data/item references remain within their layer and can have explicit transitioned counterparts.
+- Applying a source project preserves authored comments and formatting while assigning missing identities. Graphical updates preserve unaffected source bytes; canonical export is a separate operation. JSON does not preserve comments or source-file organization. See the [source contract](language.rst) for comment ownership and update rules.
+- Port position and connection routing belong to each diagram and do not change semantic ownership or endpoints. Folding may temporarily promote an edge to a visible container; expansion restores its authored route. [Routing verification](../harness/release-routing-verification.md) records accepted behavior and measured limits.
+- Artifact references retain author-provided URI/revision/fragment values without fetching or executing resources.
 
 ## Capella-inspired improvement targets
 
@@ -34,20 +36,24 @@ These are concrete design responses, not claims that every Capella user experien
 
 | Concern | Studio response | Remaining tradeoff |
 |---|---|---|
-| Dense workbench and difficult onboarding | Task workspaces, OA/SA context, focused properties, guided example and explicit relation/transition builders | Broader usability studies, assistive technology and localization remain |
-| Noisy architecture pictures | Nested ownership/allocation views, independent placements and collapse | Manual edge routing and very large diagram optimization remain |
-| Hard-to-review model files | Readable typed source, stable aliases/UUIDs, canonical ordering and one specification | Comment preservation, semantic merges and an LSP are absent |
+| Dense workbench and difficult onboarding | Task workspaces, OA/SA context, contextual menus, direct architecture connections, searchable guidance and relation/transition builders | Direct behavior gestures and Home/recent-project workflows remain release work |
+| Noisy architecture pictures | Nested ownership/allocation views, independent placements, collapse, automatic routing, editable bends/labels and port positions | Dense diagrams may need manual adjustment; routing has a bounded solve budget |
+| Hard-to-review model files | Modular typed source, stable aliases/UUIDs, preserved comments/formatting and source-aware history | Semantic merges, completion and an LSP are absent |
 | Hidden mutation effects | Validated atomic commands, dependency cleanup, identity maintenance, previewed counterpart changes and undo | No distributed editing or automatic structural reconciliation |
 | Platform/plugin overhead | Native Rust/Iced desktop and independent headless service | WGPU has substantial dependencies and needs a working graphics adapter |
 | UI-coupled automation | Renderer-independent core and documented REST commands/queries | Desktop-hosted model editing is absent; transfer uses import/export |
 
+## Required first-release work
+
+Direct state/scenario/process canvas authoring, semantic-content drift and reviewed counterpart reconciliation, expanded data contracts, persistent coverage/filter views, Home/recent-project and unsaved-work recovery, hosted desktop editing, guidance and final acceptance remain in the [release plan](../harness/PLAN.md). These are unfinished requirements, not exclusions from the release. Interrupted source-save recovery restores a save transaction; it does not checkpoint unsaved models or drafts.
+
 ## Remaining boundaries
 
 - Logical and Physical Architecture, deployment semantics, executable behavior, complete SysML or Capella metamodel support, and native `.capella`/`.aird` import/export.
-- Advanced capability include/extend/generalization and complete Capella communication/scenario variants beyond the specified Studio profile.
-- Autosave/crash recovery, recent-project management, semantic diff/merge, comment-preserving source edits, completion and language-server tooling. Local external-file checks do not provide a cross-process transaction lock.
-- Direct desktop connection to hosted models, collaborative editing, server undo/history, retry receipts, multiple service replicas and network-synchronized data directories. The service stores current models under explicit capacity limits.
-- Editable edge routing, production-scale performance guarantees, full screen-reader/keyboard diagram support, high-contrast/localized experiences and signed installers.
+- Complete Capella communication/scenario variants beyond the specified Studio profile.
+- Semantic merge, completion and language-server tooling. Local external-file checks do not provide a cross-process transaction lock.
+- Collaborative editing, server undo/history, retry receipts, multiple service replicas and network-synchronized data directories. The service stores current models under explicit capacity limits; the current desktop transfers hosted data through explicit import/export until the planned client is implemented.
+- Production-scale performance guarantees, full screen-reader/keyboard diagram support, high-contrast/localized experiences and signed installers.
 - Runtime plugin loading or an extension ABI. External tools can use the REST API; additional in-process infrastructure needs a concrete use case.
 
 Windows and Linux builds are supported. Documented Docker/systemd deployment recipes are available for the service, but a recipe is not evidence of a running remote deployment. Platform, package and GUI verification must be reported from the acceptance record rather than inferred from source or CI configuration.