11 KiB
Scenario group adapter: independent design critique
2026-09-24. Bounded read-only critique in C:/ar-scenario-9e8r6t, identified by the parent as source 7d3d7b2 on the combined base. Read the working agreement, user specification, multiple-selection contract, Scenario reorder policy, proposed adapter design and relevant actual source. No Cargo, Git, network, GUI or production changes. This file is the reviewer's only output. Findings below concern the proposed adapter; they do not negate or accept the separately tested pure planner.
Assessment
The representation-specific selection Scope plus full Scenario Context envelope is the best-supported part of the proposal. It reuses existing exact-target selection while preserving saved/derived identity and visit admission. The saved-view one-shot reorder arm is not yet justified as the preferred interaction. It separates semantics correctly, but adds an interaction state without solving the more consequential problem: a successful semantic reorder can leave the authored messages visibly in their old positions.
The user's requirements emphasize direct graphical editing, low cognitive load and avoiding a bloated interface (PROJECT_GOAL.md, user-owned general description/UI). The accepted contract preserves saved presentation records during semantic reorder. Both constraints must be satisfied; neither a successful planner nor correct preserved coordinates establishes understandable interaction.
1. Resolve observable success before choosing the saved-view gesture
Material design gap. The proposed arm says “change shared order; saved positions stay unchanged,” but does not specify how the engineer sees the resulting semantic order when saved geometry stays put. scenario_layout.rs:635 restores exact saved send/receive positions; :437 only diagnoses source-order crossings. behavior.rs:1576 puts insertion slots near those painted anchors and :1807 chooses the nearest physical slot. A saved canvas is therefore not necessarily a visual ordering of semantic destinations.
Concrete falsifier: use four independent asynchronous messages with authored Y values A=200, B=300, C=400, D=500 and semantic order [A,B,C,D]. Select C then A, then reorder before D. The planner correctly returns [B,A,C,D] while all four authored Y values remain exact. The principal arrows can remain in the same places; the operation has changed semantics without the visual movement the user may expect. A frozen model comparison is necessary but cannot establish that this interaction is understandable.
There is also concrete misleading copy: scenario/workspace.rs:726 displays “The Scenario order is unchanged” for a SourceOrderCrossing diagnostic. A successful semantic reorder can itself create that diagnostic. Keep action-specific “order stays unchanged” in spacing-preview feedback if accurate, but make the general presentation notice neutral, e.g. “Saved positions differ from Scenario order.” The existing order shelf already distinguishes stored positions from automatically positioned items (workspace.rs:363); reuse that distinction. “Authored positions are preserved” is more precise than promising every painted position stays unchanged.
Required before adapter acceptance: a visible exact destination (“before D in Main sequence”), a preview of the resulting semantic order, and an observable successful result after commit that does not require opening source to infer what happened. Candidate geometry may also become fallback after a valid semantic reorder while saved records remain exact; state whether that is allowed, and show the outcome rather than presenting an unexplained representation change as success. Do not expand the semantic planner into a renderer validator solely to avoid this product decision.
2. Compare a direct handle and operation-local order preview; the arm is not the only bounded alternative
The initial comparison omits an existing affordance: behavior.rs:1827 defines a reorder handle, painted only in Derived mode at :2545. A group-aware, explicitly labelled handle could start semantic reorder directly while ordinary saved message/header drags retain spacing semantics. It avoids an armed interval, an extra click, and the need to remember that the next body drag has changed meaning. It still needs clear group scope and a keyboard/contextual equivalent. Merely enabling the current singleton handle would be incorrect.
| Candidate | Simplicity and result visibility | Recommendation |
|---|---|---|
| One-shot arm followed by saved body drag | Explicit intent, but requires an extra mode and leaves physical/semantic order ambiguity. | Retain as an experiment, not the accepted preference. |
| Explicit group reorder handle in the saved view | One direct gesture and no persistent arm; saved spacing remains familiar. Saved geometry alone still does not show the changed order. | Strong simpler candidate, paired with a semantic order preview. |
| Operation-local automatic/order preview | Captures the current saved Context and exact set, presents resulting sequence order while retaining authored records and the saved view underneath. Makes destination and outcome observable. | Prototype alongside the handle; prefer a compact graphical/neighbor preview over another large homogeneous list. |
| Navigate to Automatic arrangement | Reuses existing interaction, but contractually clears group selection and forces reselection. | Acceptable explicitly limited first delivery, not full saved-view group acceptance. |
An operation preview is a pending command against the captured saved selection, not a silent representation navigation. Keep the actual saved representation/visit and live group intact; use an explicit preview/gesture lifetime, and execute only the exact captured set. Do not change the arrangement picker or transfer a group across surfaces by exception. Derived preview geometry must not retroactively authorize originally hidden or unsupported selected targets. If the chosen preview becomes a separately navigable editor, define its input identity explicitly instead of pretending it is the unchanged saved canvas.
Bounded comparison task: select noncontiguous A/C in the saved view, reorder before D, identify the new sequence without consulting source, and perform the next ordinary spacing operation correctly. Compare handle-plus-preview and arm-plus-preview for errors, unexpected movement, extra recovery steps and discoverability. Verify preserved authored records and exact [B,A,C,D] independently. A reversible prototype can resolve this choice after publishing the pure planner; no production arm is needed to obtain that evidence.
3. Add an explicit gesture-retirement invariant
Missing lifetime contract, not a demonstrated implementation defect. The proposed state list (.local/scenario-group-adapter-design.md:41) captures Context, selection Snapshot and tool/arm state, but does not name an App-admitted gesture identity or specify which retirement advances invalidate delayed packets. diagram_selection.rs:170 detects context and selection-generation changes; it does not identify two gestures on the same unchanged selection. Completing a no-op or cancel followed by rearming can leave all those values equal unless an additional lifetime changes.
Specify exactly one solution: an App-owned token/generation for each admitted gesture/arm, or mandatory captured-context invalidation on every relevant retirement. A boolean “armed” check is insufficient. Rejected old packets must not disarm a newer operation. Distinguish stationary click, changed commit, no-op, refusal, Escape, outside release and focus/camera loss; each consumes only its own matching capability. Retirement may change transient gesture state without changing model/source/history/selection. Existing spacing already provides a useful bounded pattern: spacing/controller.rs:17 plus token-bearing events, and app/scenario_spacing.rs:26 matches the active token before mutation and advances epoch on Finish at :52.
Also strengthen the spacing bridge requirement at design line 56. Refusing Begin only while the live set is a group is weaker than matching captured selection identity: a delayed singleton Begin after a group was created and reduced again can pass that test. Either snapshot-match Begin/Finish, or prove and test epoch retirement for every selection generation change, including add/remove of a secondary member that leaves the legacy primary unchanged. Do not rely only on self.selected or group size.
Falsifiers: cancel A, start B with the same model/selection, deliver A's release/cancel; finish an unchanged A, rearm B, deliver duplicate A; create/remove a secondary selection member before delivering the old spacing Begin. B and the restored exact selection must remain intact, with no command or history effect from A.
4. Make the promised origin-return no-op explicit
The proposed evaluator promises “out/back origin remains threshold-crossed Noop” (design line 71). The planner cannot establish that: group_reorder.rs:138 only receives a Slot and returns no-op for a selected anchor or unchanged transformed list. behavior.rs:2043 latches threshold crossing, while :1807 maps the final physical position to the nearest slot. A press on the body at a row's Y is not generally nearest its own slot, which is offset by 42 at :1582; saved anchors may be arbitrarily close or crossed. Returning to the original pointer can therefore choose an unselected neighbor and compact/move a noncontiguous group.
If origin-return no-op is intended, define it in the gesture adapter before slot planning: preserve the ever-crossed flag for selection behavior, but classify return to the captured origin using an explicit screen-space tolerance/axis policy. Admit the envelope and baseline first, then return no-op without executing. Test actual message-body, label and handle press positions in closely spaced saved geometry. Otherwise remove that stronger promise and document the destination-based behavior; do not assume the selected-anchor rule supplies it.
Sound constraints to retain
Keep full representation/visit in the Scenario envelope and representation identity in the generic Scope; no global generic-context redesign is justified. Use actual presented typed visibility, preserve whole-set refusal and original primary, and close raw order-row/menu/singleton bypasses before showing an operational group. Clear groups on actual surface navigation as required. The current nearest-displayed-slot-then-parent-admission rule is coherent, but a preview must name the semantic destination when physical order differs.
These are source/design conclusions only. Native focus/Shift behavior, preview stability, event ordering, readability, exact history and actual usability remain unverified. The pure planner can be delivered as a bounded milestone while the saved-view interaction remains an explicit open decision.