Existing-call Details trial preparation
Status: valid-intended source fixture, not parsed, admitted, rendered or executed. Parent must admit service-details.arcadia with the compiled current core before any GUI trial. Target source pin: 0409a481c7. This task ran no Cargo/rustc, native input or Gitea write.
The fixture supplies an SA BoundaryInterface scenario, concrete Standard Requires/Provides ports, one channel carrying two distinct synchronous operation items, two exact InterfaceItemAllocation identities, named String/Real/Boolean parameter types, and two separately correlated Call/Reply pairs. A saved Scenario view keeps all four messages identifiable. Parameters are optional (0..1), so an explicitly removed annotation does not invent a mandatory value. Expressions are exact descriptive text, not evaluated/type-checked runtime literals; incompatibility here means a field identity is outside the selected operation signature.
The existing boundary-only probe was inspected. It is schema6 with parameterless calls, no stored operation selections and no Replies. It is useful endpoint/allocation precedent, but cannot by itself evaluate current existing-call operation/payload editing. This new source7 fixture avoids relying on migration or inferring operations from names.
Native tasks and independent oracle
Use an existing occurrence's Details/property form, not the New Message form. If a required existing-record control is absent, inaccessible or unusable, record that observation; do not substitute a creation flow or source edit and claim the original task succeeded. baseline-and-edits.json records exact IDs and allowed semantic changes.
-
Edit one existing payload. Select first_call (Read primary status), confirm ReadStatus allocation and the Scope String parameter, then change its expression from the literal text "primary" to "secondary" and Apply. Only first_call.values[0].expression changes. Re-select first_reply: reply_to remains first_call, operation remains absent, its derived operation remains ReadStatus, and its Status expression remains "READY". The separate SetLimit control pair and all types, relations, order and saved geometry remain exact. One Undo/Redo must restore/reapply the complete accepted Project and source bundle.
-
Reject incompatible operation change without value loss. In first_call's existing Details, select SetLimit allocation while retaining the Scope annotation. Before Apply, the raw expression must remain available for repair; selection is not authorization to prune it. Apply must refuse the whole candidate: both first_call's Scope field and first_reply's Status field belong to ReadStatus, not SetLimit. Accepted Project/source/history remain at task1; do not assert a particular error ordering. Cancel restores the accepted ReadStatus inspection. Core validation is expected to report message_value_field for these incompatible direct field references; operation eligibility itself need not filter the allocation out.
-
Explicitly repair, then change the operation. First remove first_reply's Status value row explicitly and Apply (only that values vector becomes []). Next edit first_call: select SetLimit, explicitly replace/remove the old Scope address and choose Pressure limit, enter expression 18.75, then Apply. This changes only first_call.operation.allocation and its single (path=[], field, expression) record. It must not rename messages, retarget reply_to or choose the other Call. first_reply now derives SetLimit from first_call, still stores no operation, and still has no values. Add its Accepted Return field with expression true and Apply; only first_reply.values changes. Finally change first_call's pressure expression to 19.25 and Apply; re-inspect that exact first_reply and the untouched control pair. These are deliberately separate accepted edits because the property editor edits one occurrence at a time; no silent multi-record migration is expected.
For each successful Apply, compare the full parsed Project with only the explicitly listed change(s), and preserve all UUIDs, names, parameters/types, channel items, scenario.steps, other messages and Diagram layout. A rejected Apply must preserve the accepted snapshot; raw-draft recovery is a separate UI assertion. Save/reopen and Undo/Redo checks concern the accepted source bundle, without requiring the formatter to preserve the handwritten fixture's initial whitespace.
Existing contract and implementation seams
- Operation identity, exact ports, Reply derivation and refusal of incompatible retained values, especially lines743–758. Typed value path/direction and non-evaluated expression contract.
- Core operation resolver: Reply follows its exact Call; lines139–218 prove selected allocation, channel, lifelines and Standard ports. Eligible allocations checks operation context, separately from retained value validation.
- Selected signature validation uses the selected item, not the channel's union; invalid field and empty-expression handling distinguishes errors from warnings.
- Existing-record operation picker, retained address needing review, and explicit array-row removal. These source seams do not establish actual Details discoverability or native usability.
No schema, feature or gesture policy is selected here. Named field types do not mean expression strings are executable or validated as those typed scalar values. Actual admission and each native result remain pending.