ARCADIA-Studio/harness/release-scope-reconciliation-20260906.md

# OA/SA scope reconciliation — 2026-09-06

Read-only production/specification review against the current user objective,
prior primary-source research and integrated branch evidence. No Cargo or native
input. Live reference checks used official Arcadia/Capella pages and the Eclipse
repository, not forum assertions or third-party feature lists. This is a bounded
requirements assessment, not certification of full Capella conformance.

## Controlling interpretation

The user requests a first release with “fully feature complete Operation Analysis
+ System Architecture, according to this application specification,” also asking
for **most** Arcadia semantics, a modern general systems tool, equivalent editable
graphical/text representations, deployable REST, artifact traceability and usable
built-in guidance. Later Arcadia layers are explicitly future work. The user does
not request every Capella implementation class, Eclipse extension, simulator,
native Capella file importer, or the full SysML metamodel.

Consequently, `docs/scope.md` can document intentional semantics and limitations;
its “Studio profile” cannot itself authorize removing a material OA/SA workflow.
Conversely, an Ecore class without a discriminating engineering use case is not
automatically a new release requirement. Judge representation alternatives by
whether they preserve identity, context, editing and downstream meaning.

R1–R6 of the original audit are substantially implemented: contextual topology,
mission/capability relations, iterative typed review, scenario reuse/correlation,
typed states/events and data/interface contracts. Source6 also supplies CM,
categories/selective views and coverage checks. The integrated branch audit and
current tests/reports supersede their original absence claims. Native and Linux
acceptance gaps remain gates; they are not missing metamodels.

## Material unresolved semantics, in priority order

### S1 — contextual assembly inside reused processes/chains

**Recommendation: resolve before an unqualified feature-complete OA/SA claim.**
The official Capella guide explicitly describes assembling reusable chains via
involved functions that need not be the start/end, via a shared function, and
through nested references. This is process/functional analysis, not physical
deployment. [Official guide, Assembling Functional Chains](https://raw.githubusercontent.com/eclipse-capella/capella/master/doc/plugins/org.polarsys.capella.ui.doc/html/05.%20Diagram%20Management/5.5.%20Creation%20of%20Functional%20Chains%20and%20Physical%20Paths.mediawiki).

Current evidence: `OccurrenceBody::SequenceReference` stores only a referenced
sequence ID; `RelationBody::SequenceLink` has direct source/target occurrences.
`validation.rs`'s `sequence_link_context` check requires equal direct owners.
`release_topology.rs::contextual_links_match_work_exchange_endpoints_and_reject_foreign_owners`
pins that restriction. Language section4.2 says the same; the process UI report
explicitly treats expanded reference endpoints as passive previews. This is an
intentional unsupported semantic boundary, not a lost branch implementation.

**Minimal counterexample:** reusable procedure P contains contributions A→B→C.
An outer process reuses P twice, through R1 and R2, and also contains X. It needs
X to precede **B within R1**, while A within R1 may begin before X. R2 and the
shared P definition must remain unchanged. The relationship is contextual to R1.

| Existing alternative | Why it does not preserve this particular intent |
|---|---|
| X→R1 as an outer SequenceLink | Orders the whole reused procedure after X, also delaying A. It cannot identify B. |
| Another outer occurrence referencing the same global work B | Avoids duplicating the work definition, but creates another contribution; it is not the B contribution within R1. |
| Copy A/B/C occurrences and links into the outer process | Can encode the flattened order, but loses reuse of P's occurrence/topology definition and its maintained updates. This is a different model, not an equivalent encoding. |
| Edit P to contain the X dependency | Changes the shared procedure and therefore both uses; the caller-local dependency is lost. |
| Put the condition in guard/prose | No maintained endpoint identity, context-specific reference cleanup, or equivalent structured navigation. |

Two bounded alternatives deserve a contract comparison before implementation:
**(a)** a contextual endpoint containing a finite reference-occurrence path plus
leaf contribution ID, scoped to an outer owner; **(b)** explicitly declared
procedure connection points bound to internal contributions, with per-use
bindings. Both can retain shared definitions; (a) directly serves the inspected
Capella use case, while (b) introduces an abstraction/API authoring burden. Merely
allowing cross-parent IDs is insufficient because R1 and R2 share the same leaf ID.

Pin the example in both OA and SA, including two uses, nested path resolution,
source edit propagation, deletion/reidentification, forward/reverse transition,
semantic review conflicts, exact source/API roundtrip and one Undo boundary.
Define common-function assembly separately: do not guess that two occurrences
execute once merely because they reference the same work. No production extension
is proposed as already accepted; another agent is independently falsifying this
counterexample and the alternatives.

### S2 — operation identity in interface scenarios

**Recommendation: demonstrate an equivalent current encoding or close the typed
reference gap before claiming complete interface-scenario support.** Capella's
official feature description distinguishes participant exchange scenarios from
interface scenarios whose messages identify interface operations. Its
Interaction schema derives a message's exact invoked operation from the message
ends. [Official features](https://mbse-capella.org/features.html),
[Interaction schema](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore).

Studio supports Operation exchange items, interface allocation and participant
Call/Reply, but these are not proof of operation selection per message.
`OccurrenceBody::Exchange` currently has exchange, sender, receiver, kind,
reply_to and parameter values. Validation admits Interaction, FunctionalExchange,
BoundaryExchange or CommunicationMean as that exchange. The `BoundaryInterface`
viewpoint does not introduce a typed InterfaceAllocation/operation selection.

**Counterexample:** one participant boundary channel offers two parameterless
operations, Reset and ReadStatus, through one interface. Two Calls need distinct
operation identities while retaining the same channel and participant pair.
Names alone do not follow operation rename/delete; there are no parameter values
from which to identify these zero-parameter operations. Selecting the entire
channel is ambiguous. A per-operation FunctionalExchange may be a legitimate
encoding **when those global functions/ports/flows already belong to the design**;
it is not generally equivalent if the engineer only specified an interface and
would have to invent a functional refinement or split the channel.

The smallest next step is a core-only identity/lifecycle oracle for that example,
then an explicit operation reference or equally faithful mapping design. Freeze
whether the reference selects an interface allocation or its reusable item, how
provider/receiver and call mechanism validate, and how Reply inherits/correlates
the operation. Do not add a second scenario engine or infer an operation by name.
This is a demonstrated representational limitation; no failing runtime test was
executed in this read-only review.

## Exclusions that do not establish additional blockers

| Exclusion/choice | Assessment and condition |
|---|---|
| LA/PA components, implementation allocation, physical deployment | Explicit future layers. OA nesting and SA functional decomposition remain required and implemented; adding internal SA components would blur the chosen perspective. Prior primary research includes Capella's SA component validation rules. |
| Simulation, executable guards and hydraulic/control analysis | General modeling and descriptive constraints do not imply an execution engine. Keep labels honest; no claim of evaluated guard truth, timing proof or safety analysis. |
| Native `.capella`/`.aird`, full SysML, identical Eclipse metamodel/UI | No explicit interoperability requirement. Equivalent engineering outcomes matter; literal class/file compatibility is not required by “modern clone.” |
| Generic constraints instead of every temporal/configuration class | `SharedBody::Constraint { expression, constrained }` already attaches authored constraints to maintained semantic IDs; typed time/change events and scenario state observations also exist. Separate start/end timing observations and configuration-specific invocation can be richer, but this review has not established a concrete required use case that these existing descriptive facilities cannot faithfully express. Do not call them implemented, or call every Ecore difference a blocker. |
| No cross-layer data/item sharing; explicit traced counterparts | A deliberate identity/ownership choice can still satisfy both-layer modeling and review. Capella permitting upstream reuse does not require Studio to share the identical record across layers. Preserve intentional divergence and make copying/mapping explicit. |
| No semantic Git merge/LSP/autocomplete | Git-friendly commented modular text, syntax highlighting, linting and rejection are required and present. A merge engine or language server is not implied. |
| No collaboration/server history/autoretry/multi-replica service | Deployable querying/editing and conditional writes are required. Local Undo, ETags and explicit review can satisfy that boundary without collaborative merging or distributed storage. Actual Linux/deployment acceptance remains required. |
| No artifact fetching/plugin ABI/CAD execution | Maintained URI/revision/fragment and REST access meet the stated cross-tool traceability model without opening arbitrary resources or embedding plugins. Avoid implying external artifact contents are automatically validated or copied by Save As. |
| No signed installer, exhaustive accessibility/localization/performance promises | Not independently established as release requirements. A genuinely usable portable Windows/Linux distribution and representative supported-size interaction are required; missing runtime/lesson assets are blockers regardless of installer format. |

## F2: behavior SVG export

The user does **not** explicitly require SVG, report generation or faithful export
of every canvas. Exportability is nevertheless useful to systems engineers sharing
behavior with stakeholders. Architecture-only SVG is a defensible bounded product
choice if it is clearly labeled and does not export a different view under a
misleading promise. It is not a newly established OA/SA semantic blocker by itself.

Current implementation evidence: `App::export_to` sends `active_diagram` to
`diagram::export_svg`; the visible Export SVG control is on the architecture view
toolbar, and no corresponding behavior export control was found. It does not
render the scenario/process/state workspace. The broadly worded scope/guide
description needs qualification; the root's F2 deferral is an engineering decision,
not an explicit user waiver and not a faithful behavior-export pass.

If later acceptance demands sharing the visible behavior, compare a shared vector
scene/rendering adapter with an honest raster capture/export. Preserve exact
identity/labels/geometry for the chosen view. Do not silently repurpose the generic
architecture renderer or add behavior export solely to reproduce every Capella
menu. Current interactive behavioral editing and correct navigation remain the
higher-priority explicit requirement.

## Required resolution

Resolve S1 with the independent counterexample review and a bounded identity-path
contract; resolve S2 with an explicit alternative-encoding falsifier before choosing
its API. Correct current scope/help so “complete OA/SA” is not inferred from a
self-selected subset or from historical test totals. Continue the already assigned
native/Linux/package/end-state gates. This report adds no blanket demand for all
Capella variants and does not authorize reducing the user's requirement.

Local evidence: [prior semantics research](../docs/research-v2-semantics.md),
[original release audit](release-semantics-audit.md),
[integrated branch audit](release-branch-integration-20260906.md),
[current native priorities](release-final-native-priorities-20260906.md).