19 KiB
Independent review of the Focus optical proposal
Review date: 2026-10-01 PDT. This is a design/source review, not implementation or optical acceptance. I know the mixed-diagram answer key and cannot provide a fresh-reader pass. I read the proposal, the earlier next-action note, the newly committed experiment plan and the actual Iced/application seams. I did not run Cargo, native UI, Gitea, or any experiment. Only this report was written.
The checkout moved from e144e32e99 to bc69c6d449 during the review. The latter was clean when inspected. A direct diff confirmed no changes to the reviewed main.rs, app.rs, views.rs or diagram.rs between those commits. The later commit also contains the frozen experiment plan and eight-card input, in addition to delivery documentation. Parent owns implementation and #38; this review does not revise #43 ownership.
Recommendation
Proceed with a small, isolated read-only comparison, subject to the measurement and admission corrections below. Prefer the parent's revised header-only controls seam plus inert existing body to controls overlaid on real Save actions. Reusing production DiagramCanvas::draw through an adapter that never calls its update is the right boundary. A private runner must not call App::update or its subscriptions; the experiment needs no new production message, routing behavior, document operation or preference.
This is proportionate only while it remains a few local presentation seams and an optical harness. Do not build editable Focus, generalized inert/hidden-pane infrastructure, persistence, tool restoration or navigation integration to answer this question. Focus may demonstrate a useful larger reading surface without solving ownership ambiguity. It cannot erase the existing foreign-stroke/label intersection, disentangle shared strokes, or retroactively accept A/B/E/F.
Material findings and required changes
1. A measured viewport does not establish that the corresponding fitted frame was drawn
The proposal's matching generation/positive size condition is necessary but insufficient for capture readiness. Sensor publishes on_show/on_resize while handling RedrawRequested (vendor sensor.rs:198-264). That event reports layout size; it is not an acknowledgment that a newly computed camera has already been drawn or presented. A control click can otherwise save a correct new camera record beside an older screenshot. A resize can cause this within a single variant, without changing the variant generation.
Define readiness around an exact tuple: fixture/diagram, variant, layout generation, accepted viewport measurement sequence, zoom and pan. Every new size and every transition invalidates readiness, even if the variant name is unchanged. Stamp the sensor callback when constructing that view; do not attach the current generation only after receiving an old unstamped message. A stamp added at receipt can turn an old event into an apparently current one. Sensor.key can request a fresh on_show on a transition; it is not a draw barrier.
A small adapter-owned last-drawn record, written after delegating the actual production draw with its actual bounds, is a defensible local mechanism. Capture must compare it to the current intended tuple and refuse pending/mismatched states. Do not add this bookkeeping to production DiagramCanvas. A matching draw record still does not prove OS presentation or screenshot freshness: the native observer must wait for the settled visible state, associate the screenshot with that measurement, and retain its ID/hash. Alternatively use an equally explicit externally verified settled-frame protocol; do not label a sensor event itself as rendered. Test capture attempted immediately after switch and during resize, plus Baseline→Focus→Baseline with an old callback queued.
There is no need to reroute per pointer event or continually hash the Project in draw. The model is fixed. Admission/capture/exit conservation checks and a cached fixed geometry bound are enough, with the exact draw using its ordinary cache. Measure once per genuinely changed viewport, reject zero/nonfinite sizes, and avoid a refit/redraw feedback loop.
2. Admission must require Architecture and coherent presentation state
Reject every projection for which projection.is_architecture() is false, not just Scenario. The existing classifier in oa-core model.rs:1458 expressly excludes both StateMachine and Scenario. App::with_project chooses a default diagram and calls route_state_diagram_workspace; that helper can move the application to Page::Behavior. A later assignment to active_diagram alone cannot establish the claimed Architecture Baseline.
The constructor also builds explorer_index and create_kind for its initially chosen layer. In a mixed OA/SA Project, simply overriding layer to SA leaves an OA explorer index; explorer_view consumes the stored index while naming groups with app.layer. This is a concrete likely mismatch for the proposed routing-workshop SA case. Explicitly prepare and assert the fixture's Page::Diagram, layer, selected project ID/project draft, active diagram, correct explorer index and neutral tool/navigation/pending state. The constructor's hardcoded Coastal rescue status is also misleading for unrelated fixtures: use a common neutral experiment status in both variants and disclose this text deviation. Do not implement admission by sending normal navigation messages to the production reducer.
Keep complete Project equality after Document construction. Exact input bytes and full structured Project are different invariants, both needed. Rendering through Document's view_index and independent projection/routing should agree; retain a full comparison rather than counts alone. Validate the fixed fixture hash and exact expected diagnostics before launch. The output path should be create-new and must not alias the fixture. Retain pre/post input bytes or hashes at normal exit. These requirements do not need a new general admission API.
3. Prefer a header-only seam; name the Baseline deviation precisely
The existing header (views.rs:69-103) has ordinary New/Open/Save controls; the body includes task navigation, docks, multirow diagram controls, palette and footer. Replacing just the header action group is simpler to understand and verify than placing live rig controls over inert but still visible Save buttons. Let only those replacement controls be interactive; block input before dispatch into the remaining existing chrome. Keep its normal active-looking styling for the optical comparison, with a visible read-only notice. Disabling every child button through on_press removal would change colors and would be a weaker visual comparator.
A same-height claim must be measured at the tested client size/DPI. The header height is derived from its children and padding, not an explicit constant. Replacement labels can wrap or change the maximum child height. Compare the original and replacement header/canvas rectangles once in native QA; preserve the exact body/task/footer rows and palette state. Name the result "Baseline layout with experiment header actions" unless pixel equivalence has actually been established. Do not label the entire application chrome exact.
A body-level pre-dispatch wrapper can delegate layout/draw while excluding input, focus operations and overlays. It need only admit RedrawRequested for the embedded sensor, with Cursor::Unavailable. The outer allocation_input wrapper normally forwards operations and mutates pointer state on redraw; the optical seam should either avoid mounting that interactive root or make clear exactly where the inert barrier sits. No production reducer may be reachable even if an unexpected child message occurs. Unknown messages should be observable as a harness fault/rejected event, rather than silently treated as successful input isolation.
App::view also adds context menus, hosted/reference/usage overlays and focus/escape wrappers around views::view. The neutral fixture should assert these states absent. Calling views::view directly is therefore a deliberately scoped passive comparison, not a claim of identical production event architecture. Do not widen this experiment to test all those production modal behaviors.
4. Keep the optical conclusion narrower than the intervention
The Focus variant removes both chrome and palette while increasing the canvas. It jointly changes scale, distraction and available semantic hints. Even correct fresh reading would not isolate magnification as the cause. It also measures an upper bound for a stripped read-only workspace; a later editable Focus retaining palette/status/access controls can have a smaller canvas. Report actual removed elements and achieved dimensions. Do not promise that an editable Focus gets the same gain.
My earlier next-action note calls 1442×932 a client size in an arithmetic upper bound. That was not established by a client measurement and should remain only a hypothetical rectangle. Production main.rs requests 1440×900 logical content; a 1442×932 native capture could include window decorations. Do not derive DPI or client size from that outer rectangle. Record sensor viewport, logical content size and observed physical/window rectangle separately, with how each was measured. Match style::theme, renderer backend, font environment, application scale and build/runtime between variants. Using the same draw function alone does not pin these.
The old 1506×814 geometry and supplied 1566×874 rectangle must not be interchanged. Recompute the current fixture's full projected/routed bounds, including its labels/end geometry, and independently verify Fit with the actual viewport. The production arithmetic uses f32 left/right subtraction, max(1), 48 total margin, clamp 0.0001..1.5 and the nonzero-origin centering formula. A local copy should mirror that operation order, not only its algebraic intent. Empty-scene behavior is keyed to projected nodes being empty. No window-size fallback is appropriate for a measured experiment.
Proportional alternatives and smallest source boundary
| Alternative | What it can establish | Why choose or reject now |
|---|---|---|
| Existing viewport/geometry arithmetic only | Whether height limits width-only recovery; required canvas dimensions for a chosen scale | Already sufficient for rejecting width-only as the strong test. Cannot determine native legibility/ownership; no further arithmetic study is needed. |
| Existing production zoom/pan | Whether a particular name/port becomes readable when enlarged | Cheap local diagnostic but loses complete-scene containment. Useful only as separately labeled assisted evidence, not the chosen whole-scene question. |
| Exported SVG or enlarged old screenshot | Approximate geometry/text positions or scaled old raster | Does not use the same native glyph/raster/compositing path; inappropriate primary comparator. Do not repeat E/F's record-equality-to-perception inference. |
| A minimal full-canvas native runner plus separately captured production Baseline | Same native drawing at larger scale with a real external Baseline | A defensible cheaper fallback if reproducing inert real chrome grows large. Requires carefully matched client/DPI/source/input/neutral state and separate baseline viewport measurement. Less convenient switching is acceptable. |
| Proposed runner with reused Baseline body and replacement header actions | Direct native same-process viewport/reading comparison with controlled fixed model | Preferred while the seam remains small. Actual body preserves wrapping/toolbar/palette constraints and makes repeat measurements simpler. Do not require a reusable UI framework for it. |
| Editable Focus now | Full workspace usability and retention behavior | Premature. Much greater draft/caret/IME, gesture, navigation and camera risk, overlapping #43 dependencies. Optical evidence should precede it. |
The smallest reasonable implementation consists of the private runner module (including its adapter, input barrier, measurements and local tests), minimal opt-in dispatch in main.rs and private view construction seams for the canvas and header actions. A small fixture-construction helper may be needed at the App boundary only if existing field visibility makes the coherent admission state otherwise inaccessible. Do not export private fields indiscriminately or put Focus decisions into the production reducer. Reuse the unchanged DiagramCanvas::draw and production SVG function; no diagram/core changes are justified by this question. Keep flag-free construction unchanged. The branch is an experiment, not a package candidate.
Prefer a private RigMessage type. The optical canvas adapter can call the production Programapp::Message::draw and return its geometries while itself implementing Program; drawing does not need to emit App messages. Existing body widgets may remain typed with App messages behind a narrow translation barrier which accepts only the known sensor receipt and rejects everything else. Avoid adding a new App::Message variant merely to carry optical controls. This is a source boundary recommendation, not an assertion that an unimplemented signature has compiled.
No general clipboard, history or recovery machinery is needed. A focused spy-widget test of the real wrapper should establish that mouse/buttons/wheel, keyboard/modifiers, touch/IME and focus operations do not reach children while redraw still produces measurement. The default no-update adapter and immutable fixture substantially reduce the state space; do not recreate the full desktop regression suite inside this disposable harness. Normal launch still deserves its ordinary smoke check.
Bounded evaluator and decision gates
Before native reading, freeze binary/source/input identities, selected diagram IDs, exact diagnostics, question set, answer key and rejection rubric. Admission receipts must record actual projected counts and kinds; authored node counts are not projected nested contents. The four planned cases use three fixed Projects. They contain no named DataAssociation ends. This missing native coverage does not block running or archiving the bounded optical experiment. It blocks claims that association-end readability or general OA/SA layout has been exercised. Do not create another special fixture just to enlarge the initial claim. Add that coverage if a later product decision needs it.
Run one native QA sequence per saved diagram: Baseline Fit → Focus Fit → Baseline Fit, then a bounded resize/return. Capture only settled matching frames. Check exact model/input conservation, full projections/routes/labels/ownership/authored metadata and exact SVG equality. Check source/output hashes and visible full-scene containment, rather than assuming Fit bounds include every painted pixel. Matching logical output is not glyph/raster parity. Read-only input attempts and expected normal exit logs complete the harness check; neither proves editable-workspace safety.
The updated plan's Focus-first fresh reader plus separately scoped historical Baseline results is honest and cheaper than pretending one reader can be fresh twice. It permits a case-level fresh Focus result, not a causal Baseline-to-Focus improvement estimate. Do not show that reader the old images, target label, known wrong association or answer key first. Ask neutral identification questions for the declared complete mixed diagram, including unoriented conversation participants, without implying an arrow direction exists. Preserve verbatim wrong/uncertain answers, competing ownership and illegible names; a guess eventually corrected after discussion is not an unassisted pass. One model reader is not a population of system engineers.
Stop or reject the experiment's validity if input/geometry changes, admission shows the wrong layer/page, the camera receipt does not match the captured frame, content is clipped, hidden interaction occurs, or runtime/font/DPI differs without accounting. Correct the specific harness defect before interpreting reading; do not average it away.
Reject Focus as a sufficient #38 remedy on any declared critical wrong association or unresolved competing ownership even if names become larger and Fit exceeds 0.85. Preserve a possible ergonomic space benefit separately. A correct Focus reading with conserved geometry justifies considering the next bounded workspace step; it does not accept editable Focus, establish generic usability, or close #38. If ownership remains ambiguous at useful scale, the next materially different question is semantic distinction/shared-route ownership, not more chrome polishing or fixed label offsets.
Reviewed identities and limits
SHA-256 values below were computed from the actual bytes read. Paths are relative to C:/ar-focus-01a0d717 except the earlier note.
| Input/source | SHA-256 |
|---|---|
| .local/focus-optical-seams.md | 4616c63feb707c973d59483b70c62c26b7a5226e475e9cf29f25298431fe8a92 |
| C:/ar-diagram-01a0d717/.local/diagram-next-action-design.md | fb251fe1de186b559559f1874763b1d7027bee9b2dcd13cc4dc653a432571d82 |
| harness/experiments/focus-optical-20261001/plan.md | ee463a9f46229bda75596faeddc4c14cf2164da99927a47c90addde6e73f8328 |
| harness/experiments/focus-optical-20261001/eight-card.json (hash only) | 9db1015369f450d5810c96a01fddb8a009d57f6aafbda5182703f15ded23d9c8 |
| crates/oa-desktop/src/main.rs | df6c70df05dbfd769cddfa42e45b70a6080e1172a721b3656b4b7efdfa3cb203 |
| crates/oa-desktop/src/app.rs | 4e470c5ba93d85f122b62b48cf27a6faa4c005abcab0d7180e6db598506e1c83 |
| crates/oa-desktop/src/views.rs | 774f68523df85850d95af11f1792057a9eee5234ca98a46c3a6eb5ae7bf50bf0 |
| crates/oa-desktop/src/diagram.rs | 3170397b82236d6db2a57a1bb860c3c44fd8ec16172701e6784d4bf1314d140f |
| crates/vendor/iced_widget/src/sensor.rs | cb95d1220fa5663b7a148d6b159081da2200debe6fea982a04f48e27dd072973 |
| crates/oa-desktop/src/style.rs | 28b9527137d03850b617e3c248828e8111743e3b2d0ca8def31d8f381889ddd2 |
| crates/oa-desktop/src/app/state_diagram.rs | 0e55b99a4e2e3558f55df7c013ee14f138d99779a8afa82503dffa026f783110 |
| crates/oa-desktop/src/explorer_view.rs | a720d7484bcc3a24729332a00e005d1cc6f5f945a9cc3965134e0024dffb581f |
| crates/oa-desktop/src/allocation_input.rs | 7ceb868b158e4384b217b2b2b118c3714fc6d851fa2c89c2a61236cae125ffda |
| crates/oa-desktop/src/diagram/port_labels.rs | f66b5ecd2dc64174324b34b4b5ebeb9c303ead25ebbb43304cecff0336cf3d15 |
| crates/oa-core/src/model.rs | 05a6bd5eef14c77e7cafd2bc72eb3bb6b19f33c6d06184b4e7d21173a2684078 |
This review reads selected relevant implementation paths, not every desktop subsystem. It establishes no implementation/test/native result and no exact future Fit gain. Primary Capella research is unnecessary to decide this bounded viewport experiment; any later semantic stroke/port notation decision needs its own semantic review. Prior publication and negative experiment packets remain unchanged.