Independent resize port-policy source review — 2026-09-12

Reviewer: /root/nested_call_design, which did not implement this policy. Target: experimental commit 7e25b3d3907693cbbf03bb51b5e08b01d743a934 in .local/resize-port-policy-20260912, its comparison report and source handoff. Read applicable AGENTS and relevant projection, allocator, routing and evaluator sources. No compilation, tests, native interaction, Git/Gitea action, or implementation edits. Only this report is written. All numerical counterexamples below are source-derived predictions awaiting actual-core execution.

Recommendation: keep the experiment isolated. Freezing node bounds before side assignment addresses the identified feedback problem cleanly, and the allocator's alternating reassignment is a reasonable bounded capacity-matching algorithm. However, the current candidate has concrete side-churn and blocked-route falsifiers that matter to the user's ergonomic direct-resize objective. Passing its existing eight comparison tests would not justify adoption.

Findings

P2 prospective ergonomic regression: a tiny resize can flip most ports between sides

Paths: crates/oa-core/src/projection/port_capacity_experiment.rs:34–52,56–70,93–101; projection/port_layout.rs:214–242,245–261 within the experimental worktree.

The allocator fills the preferred side first, then assigns overflow to least-used remaining sides in L/R/T/B tie order. It recomputes from the first stable port ID for every rectangle. Gaining one preferred-side slot therefore shifts the phase of the entire fallback allocation. This is not necessary movement of just the port occupying the newly available slot.

Concrete all-clear, no-manual-anchor case: use 100 Standard/Unset ports on one owner, each connected to the same distant right-hand peer (the existing hundred_ports fixture already supplies this shape). Keep width 728. Compare authored heights 819.9 and 820.0; both exceed the semantic minimum 804.

At 819.9, each vertical side has capacity 28. The first 28 IDs take Right; the remaining 72 take Left, Top, Bottom repeatedly.
At 820.0, each vertical side has capacity 29. The first 29 IDs take Right; IDs 30 onward restart the same Left, Top, Bottom sequence.
Thus IDs 29–100 all change sides: 72 of 100 ports for a 0.1-unit height change. Their attached exchanges can reroute across the frame and labels can move substantially. Stable UUID order makes this deterministic, not ergonomic.

A smaller realistic falsifier is 20 ports, width 224, heights 259.9 → 260.0. Vertical capacity changes 8 → 9; 12 of 20 ports flip sides by the same mechanism. For eight ports, heights 175.9 → 176.0 predict three side flips. Use one far-right peer, not the existing eight-port fixture's two above/below peers, so the peer-facing preference remains Right on both sides of the threshold.

For the 20-port comparison, the entire preceding side assignment remains capacity-feasible at the larger height: zero side changes are required merely to preserve the nominal gap. If the policy elects to occupy the newly available preferred Right slot, moving one former Left port to Right is sufficient; the other eleven predicted flips are not required for that improvement. This is a comparison of 12 changes versus zero/one justified changes, not a requirement that resizing never move ports. Exact authored rectangles remain mandatory; refusing the requested rectangle would not resolve this finding.

The design report permits some threshold side changes but explicitly excludes pathological route/label churn. This counterexample makes that criterion measurable. Keep stateless projection/source parity and manual-anchor stability, but compare a more stable deterministic assignment before choosing the policy. Do not fix it by silently persisting automatic anchors or adding a gesture-only frozen layout.

P2 prospective routing regression: capacity spillover can create a new unavoidable blocked port exit

Paths: projection/port_layout.rs:80–119,213,239,329; routing.rs:377–390,627–645,735–747.

clear_exit tests a side midpoint against connected peers only. Capacity assignment may use an unpreferred side that the spacing-only control never uses. The router subsequently treats the actual port position and its 18-unit outward stub as fixed, checks all visible obstacles with 12-unit clearance, and rejects a blocked stub before route search. A better path search cannot repair the port choice.

Concrete model fixture:

Placement	Bounds	Meaning
Owner	`(0,0)`, `224×160`	One System with eight Standard/Unset ports.
Far-right peer	`(1908,336)`, `184×132`	SystemActor with one port; each owner port has a BoundaryExchange to it.
Unrelated obstacle	`(0,-150)`, `224×132`	Separate visible SystemActor, with no exchange to the owner. No nesting/visual parent.

All eight owner demands prefer Right and report all sides clear, because the unrelated obstacle is absent from peers.owners. Under CapacityAware, Right has five slots, so the three overflow ports go to Left, Top and Bottom. The lone Top port is placed at (112,0) with outward stub ending (112,-18).

The unrelated obstacle occupies y [-150,-18]; after routing clearance inflation it occupies x [-12,236], y [-162,-6]. The fixed Top stub crosses this inflated obstacle over y [-18,-6]. route_edge has only this port endpoint candidate, so the expected result is NoClearPath with a recoverable fallback. The spacing-only control keeps all eight ports on Right; those outward stubs are clear. Current also keeps Right, enlarging owner height to 232; its right exits remain clear. This is a new warning introduced by capacity spillover, not merely an existing difficult routing example.

The comparison report already acknowledges midpoint/obstacle limitations, appropriately. The counterexample turns that acknowledged limitation into a compact candidate-versus-control test. Before adoption, side/position choice must account for actual possible exit positions and relevant obstacles while preserving authored anchors and frozen owner bounds. Expanding owner geometry or moving ports inside the router would violate the proposed boundary.

Even when every obstacle is a connected peer, a clear midpoint does not prove clearance at the other automatic offsets. For example, a peer overlapping only the top-right corner can leave the Right midpoint clear while blocking the first Right port's y=18 stub. That weakness predates the policy, but distributing ports to new sides increases its practical impact.

P2 acceptance gap: the current geometry tests establish representability, not the resize workflow or a general inverse

Paths: tests/experimental_port_policy.rs:172–263,266–294,374–432,435–459; projection.rs:252–299.

The forbidden-rectangle test usefully proves that three directly authored rectangles become representable. The eight-handle test precomputes an edited rectangle in a flat eight-port fixture, sends an EditNode, and compares projection with that same rectangle. It does not call the desktop resize planner/gesture, exercise inward movement, zero motion, cancellation, stale input, minimum clamping, child enclosure, folded nodes or state boundary geometry. It therefore cannot establish the user's opposite-edge/captured-axis behavior for actual editing. The source handoff correctly lists those remaining gates; retain that distinction when publishing results.

The 100-port test measures same-side center gaps only. It does not route the 100 exchanges, inspect glyph/text bounds, count warning regressions or quantify adjacent-frame side churn. The one-edge narrow-gap test never exercises a capacity spill, so it does not cover the new allocator's principal route risk.

The explicit-Current-equals-default test is useful for ensuring the default entrypoint selects Current. Both calls ultimately enter the same new project_diagram_impl, however; this comparison alone cannot prove historical Current geometry remains unchanged. Keep the selected historical geometry controls and compare identified pre-experiment projection snapshots before claiming upgrade compatibility. Likewise, candidate_geometry_is_deterministic_and_independent_of_peer_motion_and_names edits aliases, not display names or construction order; its executed claim should match that narrower action.

Allocator correctness assessment

No concrete capacity-matching completeness defect was found in try_assign. With static clear masks and integral capacities, visiting a full side bin once while examining its occupants is a conventional augmenting-path strategy. Failed recursion changes no assignments; a successful chain relocates occupants into a free bin and unwinds. Manual anchors are deliberately excluded from shadow demands, preserving the stated unrelated-side stability contract.

The 343-case three-port/three-side exhaustive oracle is a useful small check, and the 20-demand scarce-capacity test probes capacities greater than one. Neither checks the fourth side, larger random masks/capacities, practical assignment churn or actual geometric realizability of clear masks. Do not confuse a correct capacity matching with a good port layout: the two prospective regressions do not require a matching error. They are normal-priority experimental findings to verify before adoption, not production incidents or a reason to abandon exact authored-rectangle resizing.

The no-growth alternative also has a real positive boundary: after semantic minima/enclosure, port-side assignment no longer changes node rectangles. This supports solving the remaining resize mapping with one coherent projector. It is experimental evidence toward the objective, not a replacement for direct-editing acceptance.

Smallest next executable experiment

Under root's serialized compiler lease, add/run two actual-core comparison cases, preserving the first failures before changing the policy:

Threshold sweep: parameterize the distant-right-peer fixture for 8, 20 and 100 ports with deterministic IDs. For each policy project heights just below/at/above the thresholds above. Record per-port (side,position), number of changed sides, minimum glyph separation, owner bounds, routed warning count, total route length and bends. Start with 20 ports if time is limited. Compare against spacing-only; explicitly retain its crowding result rather than declaring it the winner solely because it is stable. Expect CapacityAware's 20-port threshold to reproduce 12 side flips.
Unrelated-top-obstacle case: use the exact eight-port bounds above. Assert actual owner geometry and actual port positions; call production route_diagram for all policies. Independently test each mandatory port stub against each relevant inflated obstacle, not only route warning text. Expect CapacityAware's Top endpoint (112,0) and NoClearPath; expect clear right stubs for controls. Store route/port output and a compact visual artifact of that returned experimental ProjectedView for later inspection; ordinary export/desktop entrypoints still choose Current.

These two tests resolve substantially more uncertainty than another round of inverse iterations or only expanding abstract mask enumeration. If either prediction fails, preserve the actual Project and explain which projection/route premise differed; do not relax its user-derived criterion to keep the candidate.

Only after the candidate beats the control on these risks should root broaden to real eight-handle drag/Undo/save workflows, enclosure/fold/state inverse gates, manual near-coincident anchors, upgrade footprint and ordinary/minimum-scale native readability. No policy adoption or issue closure is recommended from source review alone.

Source identity and handoff

Source identity is the supplied experimental commit 7e25b3d3907693cbbf03bb51b5e08b01d743a934. SHA-256 hashes below capture the exact on-disk bytes reviewed, before root adds the proposed experiments. Paths in the first five rows are relative to .local/resize-port-policy-20260912; report paths are relative to the root workspace.

Reviewed file	SHA-256
`crates/oa-core/src/projection.rs`	`DE7CA48F0EC56E97E8300E43B5941EEAAE76BAEB7D6D6D0B3ED562ABCEC250C0`
`crates/oa-core/src/projection/port_capacity_experiment.rs`	`098D7C571E0B8442430F4CCCA5AABB93580160E6A0B1A87B7AA7DAC5BB18F910`
`crates/oa-core/src/projection/port_layout.rs`	`395BD3E8323BF1053977B18CAE89612881E19A2132DACEFDA2FF6B9ADD0D9C6A`
`crates/oa-core/src/routing.rs`	`C5EBB350BA76F731F5C48D968BFBBA4B6EF68EC046EB5893D116C4637EF15080`
`crates/oa-core/tests/experimental_port_policy.rs`	`4883EC1B57AC04C37A6CA750C9DE07CE06A2E4BCDA00BE45FDE342F5721DA05D`
`.local/resize-port-policy-20260912.md`	`BF24C7659F3F4FE402CC87EFD4ADCB842ED5EB0C50B118311537ACF7B85BA9A4`
`.local/resize-port-policy-source-handoff-20260912.md`	`7C9C33D3F818FF68E80C36B4982EB6A43A4CB2FA9A4447DD8E9DF43614962FA3`

Root remains the integration and compiler/native acceptance owner. Preserve this review and these source identities before adding the two executable cases; attach actual results to a distinct experiment receipt. Predictions remain unexecuted, the candidate remains unadopted, and this handoff makes no production acceptance claim. No new matching or stateful architecture is selected by this review.

13 KiB Raw Blame History Unescape Escape