8.9 KiB
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, 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.