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.

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, Interaction schema.

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, original release audit, integrated branch audit, current native priorities.