LOD-WIRE-2: carry clean ports and buses into detailed item wiring

The owner's 2026-10-28 direction is harness/PCB-style organization throughout GraphDone: readable ports, wires and buses; no tangled balls at intermediate or item zoom. Group hierarchy, schematic overview, exact relationship lists and bounded group traces were accepted through merged #216; #215/#218/#219 are closed. Coordinator #193 remains open. The shared item path/hitbox/arrow/sliding-label foundation #221 is merged and fully accepted on dev058aaa7. This follow-up is specifically detailed item/neighborhood wiring, which still uses the existing straight-line D3 renderer.

This item-routing slice remains owned by the active GraphDone work. Readability PR223, priority PR224 and inspector PR226 are accepted. Coordinate with active topology PR234 and render-budget PR236 before touching the renderer; integrate those exact reviewed sources first. Record the next branch/worktree and exact accepted starting source before editing; do not open an overlapping implementation of semantic overview/navigation. CodeGraph ideas are welcome; no shared library or CodeGraph mutation is requested.

Implementation/acceptance path:

Audit InteractiveGraphVisualization edge lines, clickable hitboxes, directional arrows, edge labels/sliding, drag/update paths and viewport culling. Record what owns geometry and when it recomputes. Do not put an all-pairs router or DOM measurements in every simulation/pan tick.
Define a bounded visible neighborhood and named boundary ports/buses. Preserve exact source IDs, directed types, parallel/antiparallel/self links, selected endpoints and complete accessible connection lists. All unloaded/outside/deferred connections need honest denominators; hiding every edge cannot pass.
Use organized ports and obstacle-aware orthogonal lanes around actual item cards, labels and controls. Share only intentionally related trunks, mark junctions, and keep original arrow direction. Preserve stable lanes during camera gestures. Document behavior while dragging and after settling.
Preserve editing, Grow/connect, selected-node inspection, edge hitboxes, label interactions and durable layout save/reload. Display routing must never enter canonical graph data or saved positions.
Add small deterministic chain/hub/cycle/parallel/long-label/phone regressions plus a deliberate spaghetti negative. Enroll actual rendered-item geometry/paint checks and screenshots in the existing strict CI journeys. Prove visible useful routes, exact conservation, no through-card paths and no unrelated overlaps. Review pictures as well as numbers.
Validate locally with small serial pure/component tests only. The owner's desktop crashed during prior broad local work; full browser/database/image matrices belong in CI. Do not restart the former test stack or change the original localhost graph. Exact-source independent review and the existing dev integration playbook remain required.

Group routing and the item geometry foundation are accepted; obstacle-aware item routing and buses are still unfinished. Large-data loading/1k–10k capacity, hosted parity and release/deployment retain their own gates. The owner offered to call in another agent when a concrete help issue exists; this scope avoids the active group-view implementation while addressing the remaining visible wire-ball risk.

Current handoff,2026-10-29:223/224/226/228/230 are accepted;222/225/227/229 are closed. PR232 interaction source is merged into dev17acc25, but231 remains open because actual post-dev zoom took5.119s against5s. Dedicated235/PR236 corrects hidden item-render work in overview; its author/source review/hosted gates are active. Do not relax the timing limits or count the failed post-dev run as acceptance.

Topology233/PR234 at6ba55f2 adds measured margins, central hub/radial/chain/cycle/component placement, explicit organization/save/reload and truthful drawn/eligible overview counts. Small actual desktop/phone scenes are visually accepted, with all9/5 cards complete/painted and stable after reload.301overview shows101/361 external links across8desktopgroups; improvedphone phase admits3fullcards/45external links.72-item nested desktop/phone journeys pass2/2 in54.6s. Independent review found and corrected low-zoom membership, persisted Hierarchical override and heterogeneous slot-swap clearance. A newly verified delayed-Organize minimap publication correction is in progress. Final hosted2k/5k, source composition and actual post-dev acceptance remain pending. This placement work does not solve detailed item wiring.

The next visible item presentation gaps remain specific: the small phone ring can have zero type labels, while desktop repeats eight angled Blocks badges. A readable shared hub/bus annotation should carry that repeated meaning without hiding original relationships. The current item renderer rebuilds straight parallel routes in updateEdgePositions; it does not route around unrelated cards. Do not call a clean star proof of arbitrary mixed-network wiring.

The next implementation should consume relationshipPriority.ts output and graphSymbolLayout.ts measured card bounds, then feed one EdgeRouteGeometry to the existing path/hitbox/arrow/label consumers. schematicRouting.ts is the in-repo orthogonal/bus reference; its group renderer is not proof of item-level integration.

Concrete continuation after those PRs are accepted:

Establish a bounded visible-item neighborhood plus named connections to off-screen groups. Selected/search-focused nodes and blocking pairs get first admission; retain useful coverage of other connected pairs. Count and expose all originals even when finite geometry requires deferral. Do not create a bare “missing wire” by treating an off-screen endpoint as deleted.
Route in screen space around measured cards and controls, with stable deterministic ports and deliberately shared trunks. Convert the resulting points once into the common route object. Cache by data/layout/detail/viewport admission; camera motion reuses accepted lanes, and bounded invalidation handles drag/resize instead of rerouting every edge each frame. Preserve authored world coordinates.
First prove small chain, hub, cycle, opposite/parallel edge, self-link, clipped-viewport and phone fixtures. Actual paint, endpoint direction, full hitboxes, label drag, label/card clearance, exact counts and a deliberately tangled negative belong in the existing item-wire harness. Require an actually drawn useful connection; hidden paths cannot make the metric pass.
Then extend the existing2,000/5,000 gate to item routing through zoom/pan/detail changes, with the current no-write, timing and bounded-work assertions intact. Audit the pictures. Only after independent review, strict artifacts and post-dev acceptance should LOD-WIRE-2: carry clean ports and buses into detailed item wiring #220 close. Broader10k/50k loading/render budgets and hosted parity stay in Coordinate open-issue resolution and dynamic LOD completion #193.

CodeGraph techniques to carry forward remain parent fallback, per-region admission, retained camera/renderer identity and generation-bound loading. No shared package or CodeGraph source mutation. Do not copy its smaller text floors: current GraphDone working/secondary text baseline is14px, full graph titles18px, and body/control weights500/600.

Read-only implementation audit at #216 source 88d0115db3e7c26a7b9416d94fe4bf23dd43c1fa (no item-renderer edits):

InteractiveGraphVisualization.tsx:2175 creates visible .edge line elements from visibleEdges; 2255 creates matching transparent line hitboxes. 3356 creates arrows from validatedEdges; 3381 creates labels from visibleEdges. Preserve/adapt the admission boundary consistently across all four consumers; do not leave an arrow/hitbox for a deferred branch.
updateEdgePositions at 3822 is the geometry owner. It currently stores _ep border-to-border endpoints on source edge data, positions lines/hitboxes, rotates arrows from the straight endpoint vector, and places labels on the original straight span. It runs on simulation ticks (4134), label drag (3988), initial/late settled passes (4285–4287), and through the retained runLabelAvoidanceRef callback. Putting a full router here would multiply work across these callers.
Label dragging (3973) assumes clearSegment/slideTFromPointer on a straight line. Orthogonal paths need an intentional arc-length/segment policy; simply changing .edge to path leaves labels and clickable regions inconsistent. Arrow direction should use the final route segment while preserving canonical source/target.
clearCull/applyViewportCull (4044–4076) explicitly reset display for line, hitbox, arrow and label. A routed/deferred visibility decision must survive those resets. The force simulation and position queue remain owners of node positions; display routes do not belong in persistence.

Suggested first reviewable substep: one pure item-route/admission result consumed consistently by path, hitbox, arrow, label and counts, with a deliberately bounded update cadence and drag behavior. Prove that boundary with small tests before changing the default detail view. Do not solve clutter by fading every edge or leaving hidden interactive hitboxes. Group-level routeSchematicConnections now supports source or target trunks, but its screen-space grid budget is not evidence that it is suitable for every simulation tick.

CodeGraph transfer remains design/test ideas: retained camera/world identity, parent fallback, coalesced expensive work, meaningful visible coverage and exact IDs. Its canvas/loading implementation is not a drop-in replacement for this D3 editing model.

Claiming the first detailed item-wiring implementation in owned branch feat/item-schematic-wiring-20261028, worktree .worktrees/core-item-wiring-20261028, starting from merged dev 007148f1a526b8ef028222a429b346a67e5c3c2c. #216 pre-integration evidence is accepted; its post-dev CI remains running and related issues are still open.

First clean chunk: establish one pure polyline geometry contract for visible paths, clickable paths, target arrows and sliding labels, then adapt the D3 consumers together. Next chunk: bounded obstacle-aware admission/routing, explicit deferred counts and exact relationship access. Preserve canonical IDs/positions, editing/Grow and drag/settle behavior. Do not put routing searches or DOM measurements into camera/simulation ticks.

I will commit/push coherent increments and link the draft PR before broad CI. Small serial pure tests only on this workstation; browser/database/image acceptance stays in GitHub Actions. The geometry foundation alone will not close this issue or be described as completed item routing.

Please coordinate before editing InteractiveGraphVisualization.tsx, shared routing or label geometry. #217 remains available for independent transfer/MCP help with the source audit already posted.

First clean checkpoints are committed and pushed in draft #221: geometry foundation eee4063, offset-label correction 1d2d9f8, and shared D3 consumers d9a0a5855612290b7c765999440b0d1d55b36333. Branch feat/item-schematic-wiring-20261028 starts from dev007148f. Owned worktree is clean; another computer can resume from the branch and PR.

The first helper review was clear with integration constraints. Its requested close-return-label negative reproduced the wrong leg (fraction100/440 instead of340/440); the correction and all10 passing cases are recorded in the repo lesson/index. Full consumer source review and CI are now requested on #221. Local checks remained serial/lightweight; no browser/database/image stack restarted.

This is a geometry/interaction foundation: visible and clickable paths, final-segment arrows, cached fitting labels, offset-aware drag and culling share the route result. Actual generated paths are still straight. Next work is strict real path/hitbox/label/drag acceptance, then bounded obstacle-aware item routing/boundary buses and complete original relationship access. #220 remains open; this draft does not claim the user's no-spaghetti requirement is complete at item detail.

Pushed clean checkpoint 9931b3ce70c4c0a49d596c9aa1f32398216abf93 to feat/item-schematic-wiring-20261028, draft #221, based on accepted dev007148f. This fixes hidden SVG-label measurements, separates opposite-direction lanes, aligns wire/label editing and updates path diagnostics. Two real-browser regression cases are enrolled early in the blocking CI sequence, one worker/zero retries, with PNG/JSON and owned cleanup.

Local partial-probe evidence only:11 geometry cases,32 CLI cases, scoped types passed; lint0 errors/314 warnings. Browser discovery found2 cases, not execution. Independent corrected-source review requested. CI40645861949 and Comprehensive40645861980 are pending/running; inspect actual artifacts before integration. No local browser/DB/image suites restarted.

Recovery: fetch the branch, read PR221, docs/architecture/schematic-connections.md, and .agents/inbox/2026-10-28-hidden-labels-need-valid-measurement.md. This worktree is clean. Item paths are still straight: #220 remains open for bounded obstacle routing/buses/admission/exact deferred links. Full LOD remains #193.

PR #221 is merged by the authorized native administrative dev operation. Actual dev 058aaa70befa17a45b5a6b864c1c674ea8a173c1 has parents 007148f1a526b8ef028222a429b346a67e5c3c2c and 6ac0f4836e5a20aa7834a722bd03a48b830b1b54; its complete tree 873a61947954b9e371d4ef3c849440ab4c71eb67 exactly matches the reviewed/tested composition.

Independent COMMENT review found no foundation blockers; this is not a non-author GitHub approval. Final source CI40648634230 and Comprehensive40648634238 passed; earlier failures remain recorded.

Post-dev CI40705480289 is running; Comprehensive40705480276 passed. Closeout awaits the actual post-dev artifacts. #220 stays open for its unfinished obstacle routing/buses; the current readable-symbol slice remains one draft #223 under #222. Core now has two open PRs: this active visual slice and the explicitly parked main-promotion #191.

Foundation #221 closeout is complete. Final dev058aaa7 CI40705480289 and Comprehensive40705480276 passed. Independent post-dev audit inspected all6 artifacts,10 strict clean unchanged reports (104pass,0fail/warn/skip/evidence errors),27 referenced attachments, runtime image contracts/provenance and exact composition. Review: #221 (comment) . Owned feat/item-schematic-wiring-20261028 branch and worktree are removed.

#220 remains open for actual obstacle-aware detailed wiring, ports and buses. #223/#222 is the sole active visual slice, now at5b16ce9 with readable geometry and an explicit2000/5000 gate still pending. Start the next item-routing chunk from accepted final dev after that slice; do not fork a competing renderer implementation. The existing acceptance checklist here remains the scope; no new overlapping issue is needed.

Owner steering,2026-10-28: prioritize relationships and let the user choose the visible level, retaining at least one when high-priority types are absent. This belongs in the existing item-wiring scope, not a separate overlapping renderer issue.

Published design at PR#223 a378dce, docs/architecture/schematic-connections.md, “Relationship priority with connection fallback”:

Separate Detail from a readable Relationships control (proposed Essential / Dependencies / All). Manual choice persists through zoom/Back.
Apply fallback per original connected endpoint pair. Admit the selected tiers, or its highest available tier when none qualify. Keep distinct tied types/directions represented; preserve exact IDs and expose aggregate counts.
Blocks takes visual precedence over the equivalent reverse Depends On; same-direction records are not declared semantically equivalent. Never rewrite canonical arrows/types, use transitive reduction, or confuse node priority/edge weight with relationship meaning.
Apply pair selection before group aggregation so a blocker on one member pair cannot erase unrelated reference-only pairs. Route/label priorities still respect readability and truthful geometry-deferred counts.
Regression matrix covers references-only fallback, winner removal, ties/cycles/self-links, unknown imported types, input reorder, monotonic detail, group coverage, exact editing/inspection and zero viewing writes, plus headed small and actual2000/5000 cases.

This is a proposed implementation contract, not a shipped feature. Finish the current reviewed readability/scale slice#222/#223, then implement this bounded priority/admission slice in#220 before spending routing budget on redundant labels. No shared CodeGraph library.

Implementation boundary reviewed while #223 completes final CI:

Keep the complete workItemEdges / validated edge set in validation, force links, saving and exact relationship browsing. Apply the priority projection only to painted paths, hit targets, arrows, labels and overview bundles. Changing a presentation level must not rebuild physics or move saved nodes.
InteractiveGraphVisualization.tsx already centralizes route/cull visibility in edgeDisplay / applyEdgeDisplays; compose priority eligibility there and in placeItemLabels admission so zoom, culling and held pans cannot resurrect suppressed links or spend label slots on them. Recompute parallel lane counts from the represented set, preserving source/target direction.
SemanticGraphOverview.tsx builds containment from canonical edges. Keep that hierarchy complete, apply per-original-pair priority before bundle routing, and retain a separate canonical relationship index for exact inspection. Report priority summarization separately from internal, missing-endpoint and geometry-deferred records.
The next control must use the same readable typography and measured obstacle treatment as Detail. Persist its explicit choice through zoom and inspection/Back; use a safe default when storage is unavailable.
Add exact directed-pair, live removal and no-position-write negatives before enabling the UI; extend the existing small browser and 2,000/5,000 gate rather than creating a competing harness.

This is the next #220 implementation boundary, not shipped priority filtering. #223 remains the only active visual implementation PR; start the next branch from its accepted dev composition after closeout.

Starting the next #220 increment on published branch feat/relationship-priority-20261028, owned worktree core-relationship-priority-20261028. It is stacked on #223 source b33febb8c80fe28ef2960d3b799b7c9a311b4c25 while that frozen predecessor completes CI; no changes to #223 source. A focused draft will target the predecessor branch, then retarget dev after #223 acceptance. Do not merge this slice before predecessor acceptance.

Implement the published Essential / Dependencies / All policy with per-original-connected-pair fallback, exact directions/IDs/counts and missing-endpoint handling. Keep canonical simulation, hierarchy and relationship inspection complete. Add a readable manual priority control and strict pure/browser conservation checks; extend the existing 2,000/5,000 gate. Actual obstacle-aware item buses remain a separate unfinished part of this issue.

Local checks stay small and serial; one headed preview remains available. Heavy matrices stay in CI. Resume from the branch and this issue; no shared CodeGraph library is introduced.

Checkpoint: draft #224 now publishes the UI in 83ca79d on feat/relationship-priority-20261028, stacked on PR #223. Links offers Essential/Dependencies/All, retains each original endpoint pair through fallback, persists the choice, uses priority before group aggregation, and exposes the original records behind “Blocks +2”. Canonical data and camera stay unchanged during level changes. Scoped41 component/helper tests,10 routing tests and types passed; actual1440/390 headed journeys passed23.1s including explicit winner deletion/fallback and original API identities. The first headed run exposed the panel-click bug now corrected by #223; retained failures are documented.

Next: bring in the reviewed #223 control-layout correction, extend the existing2000-item/5000-edge headless case across priority levels with pair coverage and exact accounting, validate existing item/group journeys, obtain independent review and full strict artifacts. Do not merge before #223 is accepted; retarget to dev afterward. This slice does not close #220: obstacle-aware item routes/buses remain. Local checks use one headed browser/worker; full scale CI runs remotely.

A small read-only probe identified an important constraint for the next item-routing implementation. The accepted overview router must not be dropped unchanged into arbitrary authored item positions. Its grid takes five coordinate lines per obstacle on each axis; the Cartesian grid guard can therefore reject every branch before searching.

Using the current schematicRouting.ts at source377f5a3, a 1,360×850 viewport, 160×72 cards, six columns with 215px horizontal/175px vertical spacing, and tiny per-item x/y offsets (0.13/0.17) to represent non-aligned authored positions:

Cards	Chain connections	Routed	Deferred	Search states
4	3	3	0	79
8	7	7	0	3,804
12	11	5	6	6,000
16	15	0	15	0
24	23	0	23	0

This is an intentional bounded-search guard in the group implementation, not a newly established defect in its accepted structured overview. It is a concrete reason to design item admission and lane geometry before connecting that router to the item renderer. The probe ran once in a small serial process; no browser, database or shared data changed.

For the next #220 slice, evaluate a bounded screen-space lattice with explicit card-to-lane stubs, or a bounded sparse visibility graph, against these non-aligned authored cards. Keep the current true obstacle/clearance checks and invocation-wide work limits. Do not “fix” this by raising the Cartesian limit or silently hiding every branch. Incoming/outgoing bus sharing, opposite-direction endpoints and self-links need explicit fixtures: the current router has four fixed ports, one global shared-endpoint policy, and explicitly defers self-links. Preserve stable camera/ports and exact original-ID accounting when introducing the item-specific adapter.

Reproduction inputs are deterministic: item i has id n, x=40+(i%6)215+i0.13, y=40+floor(i/6)175+i0.17, width160,height72; connect each i to i+1 with one DEPENDS_ON original. Call routeSchematicConnections(cards, connections, 1360, 850) with default budgets. Existing group acceptance and the frozen #224 candidate remain unchanged.

Additional manual headed review used a private local copy of the current localhost graph: 301 items and 370 relationships, with fresh destination IDs. Text, metadata, directions, weights and starting positions were verified during copying. The original source was accessed only through read queries; all301 original item records were re-read unchanged. User graph contents/screenshots remain local, not attached publicly.

The copy exposed an important existing layout-policy boundary: first display repaired and persisted164 copied positions. The separateCards repair-and-save policy predates #223 (4bff35c); #223 supplies newly measured card dimensions, which can change its repair set. Fresh IDs also change the stable ID ordering. This is not evidence that all164 moves would occur under the old geometry. It is not an unchanged-position preview result. The source graph remains unchanged.

The settled copied graph shows13 overview groups with readable labels and organized group wires. This is bounded manual evidence; it does not replace the strict2,000-node gate or establish complete item wiring. The next #220 routing work must distinguish authored world coordinates, display geometry and deliberate layout repair, and must document initial-repair behavior rather than assuming every loaded layout is already clear. Independent review explicitly retained this boundary.

Copy recovery: the interactive tool timed out after recording220 nodes; destination readback found240 already created. The durable owned manifest was reconciled before continuing, avoiding a duplicate batch. The completed owned preview graph is recorded in the local fixture manifest; future cleanup must remain edge-first and scoped to that owned ID.

Correction pushed as588a2c6faf4fedf153b4b20215699f2061bae0b1 on PR224, now targeting accepted dev4a6d75d. Issue222 closed and its owned branch/worktree removed.

CI40751802514's two nested failures are corrected by direction-scoped member-pair fallback and a compact readable phone group counter. The new component regression failed on377, then19 scoped cases passed. Final nested desktop/phone headed2/2,51.51s,0retry/errors; types and targeted lint pass. Actual geometry retains2cards/painted incoming dependency and exact183=1drawn+132internal+50deferred, no overlap/crossing/small text. Intermediate green nested17 was rejected after screenshot control overlap; final regression checks top controls. New canonical lesson contains cause, correction and evidence.

Running: fresh full GitHub CI and independent review on588a2c6. Next: address findings, audit actual final strict artifacts, dev-only integration and post-dev CI before priority acceptance. Detailed item obstacle routing remains this issue; do not close220 for priority alone. One headed owned preview remains available; original localhost graph untouched.

Checkpoint, 2026-10-28: PR #224 source 588a2c6faf4fedf153b4b20215699f2061bae0b1 is pushed and clean. Full CI40757794024 and Comprehensive40757794023 passed. Independent source review5688816017 is clear and all review threads are resolved. The final archive has 11 strict reports, 110 passing cases and 93 nonempty retained attachments; final screenshot/accounting review is finishing before merge clearance.

Reviewed composition: live dev 4a6d75d24ee664a0357aa124168f39c410625902 plus source588; synthetic merge 31f4a1c92c44ac025fc3d0a49393be21dc2fe4b0, complete tree f2b29082be5884c76cb797230232b4abd52322a7. Recheck live refs immediately before integration. Then use the standing native dev-only admin operation, verify actual parents/tree, and wait for full post-dev checks and artifact acceptance. The earlier377 failures and rejected intermediate phone screenshot remain retained. No local duplicate matrix is running; one owned headed preview remains open.

Priority is only one part of #220. Actual item obstacle routing and buses remain the next implementation; #225 is the separate inspector readability help request. Do not close220 from this priority integration.

Readability checkpoint for the next routing slice,2026-10-28: inspector PR226 is now pushed atbcf3946521bc79d6eca7140c2878ae7826718e14. Independent exact-source review5690590212 and runtime/composition review5690602182 are clear; full browser/post-dev acceptance is still pending. Do not start overlapping renderer edits before that checkpoint is accepted.

Two concrete contracts to carry into item routing:

updateEdgePositions currently builds each _route first, then both visible and clickable paths consume it; arrows and label placement also consume the same geometry. Preserve this boundary. Put bounded route admission/cache computation before assigning _route; do not add a second visual-only path that diverges from hitboxes, arrow direction or draggable labels. The current function runs during simulation/gesture updates, so a new obstacle search cannot simply replace createParallelEdgeRoute in its per-edge loop.
The wider-system-font negative in226 exposed29px mode-row overflow even when a local default-font screenshot looked acceptable. Reserve geometry for measured text and controls at the current14px/500 supporting-text and18px graph-title floors. Use explicit readable hover/focus captions for icon controls; shrinking labels to make routing fit is not acceptable. This negative-control technique is worth carrying back to CodeGraph in its own harness, without shared code.

The existing CodeGraph reuse document still quotes the original proposed12px item floor, and the main LOD/schematic documents retain historical pending checkpoints. Refresh those status/floor passages with the next reviewed220 design/implementation chunk; the current accepted baseline is the14px supporting/18px graph-title contract from223. Preserve their dated original observations as history. This note is a continuation handoff, not a claim that item routing,10k/50k loading or hosted acceptance is complete.

Concrete item-routing evidence from the current417e349 showcase: run40786117644, artifact12859572976, laptop-1080p/02-graph-overview.png and ipad/02-graph-overview.png. Both the reviewer and root inspected the actual images. This capture has4items/3relationships; prior4item/0edge captures did not exercise this failure.

The direct green connection from “Connect work items together” to “Explore different views” crosses the unrelated “Create your first work item” card. The readable title/control changes fit, but they do not fix this existing item-routing class. Do not claim that the showcase or group-schematic metrics establish zero detailed-item card crossings.

Use this as the first small actual-renderer negative for220: place a third card between connected endpoints, preserve saved positions, require a useful visible route around the measured card and its controls, and require its hitbox/arrow/label to use the same geometry. Hiding the route, making the card opaque, or moving the user's stored layout is not obstacle routing. Keep exact original relationship accounting and a visible route requirement before broadening to hubs/parallel/opposite/self links and the2000/5000 fixture.

Current225/226integration remains under final CI; this is retained follow-up evidence for the already-owned220, not a new issue or a claim of a new inspector regression.

2026-10-28 owner feedback adds a concrete overview problem: connections cannot be hovered, do not emphasize their endpoints, and routing space is too tight. Verified source findings at dev 00f0211: SemanticGraphOverview inherits pointer-events:none for its bus SVG/paths and exposes only SVG titles; overviewSlots uses fixed 16px horizontal / 24px vertical gaps, and placeOverviewLabels assigns nearest free slots without considering connections.

Next reviewed slices: (1) accessible bus pointer/keyboard targets with endpoint emphasis and an exact-original relationship drill-down, preserving selection/camera/positions; (2) connection-aware presentation placement with explicit wire clearance and bounded deterministic improvement, respecting exclusions/capacity/parent fallback and preserving authored positions; (3) detailed item obstacle routing already scoped here. Use visible geometry and actual interaction tests, including thousands of nodes, not only source checks. Keep route computation bounded and outside camera/tick loops. Do not claim PCB-like organization complete from hover styling alone.

Read-only continuation plan at PR234 source 41c1fa0,2026-10-29. PR234's final hosted/runtime and post-dev acceptance is still pending; no overlapping renderer implementation has started.

What remains after234

The new local cut activates for at least20loaded unique neighbors (localItemLayout.ts:112). Lower-degree mixed graphs can therefore remain native even when their actual geometry is congested. The earlier four-item showcase connection through an unrelated card is still the right first actual-renderer negative; a clean107-neighbor projection does not accept it.
Native updateEdgePositions:3597 still constructs a two-point createParallelEdgeRoute. The common path/hitbox/final-segment-arrow/arc-length-label contract is already present and should be retained. This is a source finding, not a new quantitative browser claim.
Editing saved board positions deliberately bypasses the local projection; edgeDisplay:3741 suppresses board edges with an offscreen endpoint but does not route around visible unrelated cards. Canonical board editing needs its own clean-wire acceptance.

Recommended next bounded PR: “Route native item connections around cards without moving them.” Start from the actual accepted dev composition after234, recording its SHA. Keep all work in220; no new umbrella issue is needed.

Introduce one pure native-route plan/cache boundary before assigning _route. Use measured graphItemLayout rectangles and current control obstacles, preserve authored coordinates, and adapt accepted orthogonal points into createEdgeRoute. Paths, transparent hit targets, arrows, draggable labels and route visibility must consume that same result. Make deferral explicit and retain exact original IDs/directions/types/parallel identities. Do not turn an obstructed edge into an unexplained missing connection.
Recompute expensive search only for changed data/layout/presentation scale/control geometry or changed admission, coalesced after settling; hold accepted lanes during ordinary camera motion. A small pan, hover or label drag must not restart searches across the graph. During an actual item drag, update/invalidate only affected routes with an explicit preview policy and reroute on settlement; do not silently revert every path to crossing straight lines. One acceptance result must also survive clearCull/applyViewportCull and return from overview/local Items.
Bound obstacle discovery and grid work before invoking a router. The existing schematicRouting.ts:358 caps routes/attempts/states and refuses grids over4000cells or self endpoints. Passing every visible native card into it, raising the guard blindly, or calling it from the simulation tick is not an integration design. A finite routing region/coordinate set must still collision-check all relevant obstacles; budget exhaustion stays counted. Add a deliberate self-loop path using distinct ports, since the current schematic router defers those.
First prove the pinned three-card obstruction below the20-neighbor threshold: A→B must take a visible route around C without moving any original. Require actual3px paint, zero card intersections,20px unrelated-card clearance, consistent visible/hit path, target direction and readable14px label. Then cover chain/cycle, long cards, opposite/parallel edges, self link, clipping, actual label drag, item drag/save/reload, phone and the saved-board bypass. Retain a through-card/hidden-hitbox negative. Require useful routed coverage per feasible fixture; hiding every route cannot pass. Compare original API data and live x/y/fx/fy, with only the deliberate user's item drag allowed to change its own saved position.

This first PR may fix the native obstacle class, but must not close220 merely for passing a three-card scene. Named offscreen boundary buses, congested low-degree cross-net admission, shared type/count annotations and full original access remain the completion stage. Trigger direct-versus-summary choices from available geometry as well as degree; retain at least the highest-value feasible context. That stage needs zero unrelated crossings/overlaps and16px wire clearance, explicit all-original partitions/coverage, actual pointer/keyboard/edit behavior, and the existing2k/5k zoom/pan/no-write gate without weaker timing or text limits. Close220 only after those actual artifacts, exact-source independent review, dev integration and actual post-dev acceptance.

CodeGraph techniques worth transferring, ideas only. Fresh read-only verification found live Valpatel/graphlings dev at c5fb0089f4672d1d33c4fbf6c54bef63feab2636: screen-space child admission, navigation-first collision labels, directed selected/hover threads with duplicate suppression, and settled bounded work with scope/generation guards. Its all-files control unions actually painted original IDs over navigation; adapt that to prove every linked GraphDone original eventually becomes readable across pages/zoom, rather than checking counters alone. CodeGraph uses curves/straight beams, not a verified PCB port/bus router; do not claim otherwise or copy its smaller font floors. No shared package, CodeGraph changes, local browsers or heavy tests were introduced for this audit.

Navigation Menu

Repository navigation

LOD-WIRE-2: carry clean ports and buses into detailed item wiring #220

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

LOD-WIRE-2: carry clean ports and buses into detailed item wiring #220

Description

Activity

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 28, 2026

mvalancy commented on Oct 29, 2026

mvalancy commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions