harness/release-interface-operation-contract-independent-review-20260906.md

# S2 interface-operation contract — independent critique

Scope: the proposed `release-interface-operation-contract-20260906.md`, its existing-core fixture/probe source and output claims, current interface/port/message-value semantics and primary Capella metamodel. No S2 production edit, Cargo, native action or independent rerun of its probe. The separate App navigation correction is outside this review.

## Assessment

The missing maintained operation identity is real for the demonstrated interface-only model: two parameterless Calls over the same boundary cannot be distinguished by their current typed message fields. Functional refinement can distinguish them, but adds engineering functions/ports/relationships that the original interface-only model does not assert. The proposed bounded addition is appropriate; it does not require channel-free messages or a whole new scenario constructor.

Prefer the final `Option<OperationUse { allocation: Option<Id> }>` shape. None retains ordinary channel-message semantics. Present/unresolved retains explicit operation intent after deletion or incomplete authoring. Present/selected names the maintained InterfaceItemAllocation, retaining its interface/item/protocol context. A plain optional item ID or plain optional allocation ID loses one of those facts. Do not infer a unique operation from channel items or message values, including the parameterless case.

Primary [Interaction.ecore](https://raw.githubusercontent.com/eclipse-capella/capella/master/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore), SequenceMessage lines106–120, describes an invoked AbstractEventOperation derived through the message ends. This supports a maintained operation reference distinct from message prose; it does not require reproducing those metamodel classes in Studio. The specific allocation-based selection is a Studio design choice justified by its already identified InterfaceItemAllocation and protocol semantics, not a claim of exact Capella wire compatibility.

## Corrections required before freezing

| Priority | Concrete risk/counterexample | Required decision/test |
| --- | --- | --- |
| P1 compatibility | Adding `operation: None` to the existing Exchange constructor can serialize `"operation":null` into every old Call/Reply. Current historical fingerprint adapters borrow current element bodies; changing only schema_version would then compute a different source5/6 workflow binding although source migration changed only the version token. | Preserve historical omission exactly (e.g. current serialization omits None plus frozen legacy adapters) and pin literal nonempty source5/source6 Call and Reply model/snapshot examples. Test exact pre-migration fingerprints and raw draft retention, not only empty projects. Explicit source1–6 `operation` fields, including null, must remain rejected. Coordinate this with S1's schema7 migration; no independent bump that leaves old checkpoint restore broken. |
| P1 reply context | A Call goes client→provider; its Reply goes provider→client. Applying the proposed receiver-provides rule to the Reply's receiver would wrongly demand the client provide the operation. Deriving the ID alone is insufficient if validation/picker helpers still resolve roles from the Reply as a fresh invocation. | Resolve allocation, provider, required interface and parameter signature from the **exact correlated Call**. Run existing Reply order/correlation/reverse-pair rules separately. Test a client that only Requires, provider that only Provides, void operation, reverse Call over an unoriented channel, and more than one possible provider port. |
| P2 interface scope | The proposal says “actual receiver provides” without freezing participant-level versus endpoint-port declarations. Studio permits participant interface roles, but `ports.rs:118` explicitly does not inherit them onto ports. A new resolver scanning participant roles could silently assign a participant-wide contract to an unrelated socket. | For this concrete-boundary slice, inspect the actual resolved component ports' explicit roles. Interface inheritance is via `data::interface_satisfies`; participant containment is not interface inheritance. A participant-only declaration is not proof of a port declaration. Either classify that incomplete case explicitly or reject operation selection until the port is declared; do not guess. |
| P2 unresolved signature | Deleting the selected allocation changes Selected→Unresolved while some Call/Reply field references may still exist elsewhere on the channel. Validating against the whole channel union would silently rebind those values; requiring a complete selected signature could instead make the promised deletion-to-unresolved operation impossible. | Preserve all still-live authored value expressions, mark operation-signature checking unresolved, and perform only independent structural/path checks until reselection. Delete only references proven invalid by normal deletion. A later selection must validate the retained values against its exact effective signature, with no implicit pruning/default insertion. Test deletion of allocation separately from deletion of item/fields. |
| P2 return-channel policy | Existing Reply semantics may permit another admissible channel. The proposal does not state whether an operation-derived Reply must use the Call channel or how a separate return channel proves payload compatibility. Parameterless replies will not expose a missing check through field validation. | Do not accidentally narrow existing operation=None replies. For selected operations, freeze whether a separate channel is permitted; if permitted, validate its actual endpoints and carried output contract separately from Call-derived provider/signature identity. Include a void return and a channel carrying unrelated data. |

The recovery proposal currently says reset approvals. That is a safe conservative policy, but must be coordinated with the exact existing source5 adapter behavior and raw intent retention: clear execution-impact approvals if required by the new migration contract, never discard authored Keep/Take/Candidate inputs or accepted source facts. Never accept a saved command/plan merely because an old fingerprint was rebound.

## Allocation identity and inheritance

No defect found in using allocation identity rather than a bare ExchangeItem. `data.rs:75` returns the exact inherited allocation relations base-first; `data.rs:138` defines provider conformance by explicit ancestry. Requiring the selected allocation to be exposed through both the provided interface and an actually required compatible interface avoids silently substituting a same-named or differently allocated protocol contract. A provider's derived-only operation should not become callable through a required base interface that does not expose it. Test the inherited base allocation as accepted, the provider-only local allocation as unavailable through that base requirement, and unrelated interfaces allocating the same item as distinct.

Selecting an allocation whose item has a specialized carried subtype should use the selected operation's effective parameter signature; do not admit arbitrary additional channel fields or silently select the subtype's other allocation. Existing item conformance can prove channel carriage while allocation identity fixes protocol/signature context.

## SA-only slice and transition review

Restricting new operation selection to explicitly chosen SA BoundaryInterface scenarios is a coherent first slice if unsupported selections fail visibly; operation=None Functional/MixedLegacy/OA records must retain their old meaning. The source and API must enforce the same rule as the picker.

Reviewed SA→OA omission is justified because this slice has no equivalent operational allocation/port contract. It must be an explicit per-source occurrence decision with a displayed rationale/impact; missing, irrelevant, duplicate or wrong-direction decisions reject. The mapped scenario/channel/Call/Reply and values still need independent admission. Reply has no duplicate writable operation slot; its omitted operation follows the Call's exact abstraction decision. Ordinary semantic Take must not map a technical allocation into an OA slot that is NotApplicable. Source remains unchanged, and one accepted transition must retain exact source/history behavior.

## Bounded acceptance recommendation

Approve the outer optional OperationUse and allocation identity in principle, contingent on the five clarified boundaries above. Before GUI integration, test the original two-parameterless-operations case, inherited versus provider-local allocation, exact provider/required ports, correlated Reply context, allocation versus item deletion, retained invalid values, explicit reverse omission, and nonempty old5/6 checkpoint fingerprints. Then test readable Call/Reply labels and raw forms on the actual minimum-size canvas, followed by shared source/JSON/REST and Save/Undo/Redo/reopen evidence. A new UUID field alone does not close the workflow.