Fix graph-wide reheat during node drag

[Coding-Dev-Tools]

What changed

• Isolate node-drag physics to link attraction, the bounded one-hop drag-follow force, and the final velocity guard.
• Temporarily remove charge, centering, radial, collision, and default center forces while the pointer gesture is active.
• Replace the unbounded drag cooldown with a finite 5-second / 260-tick interaction budget.
• Restore normal forces on release and perform one bounded settle.
• Update focused asset assertions to reject infinite drag budgets and require scoped force isolation.

Why

A pinned node could move far from its prior position while the full global force field remained active. The charge, centering, radial, and collision forces then injected motion into unrelated nodes, and the infinite drag budget kept that response alive for the entire gesture. This produced the graph-wide explosive movement reported during node drags.

Validation

• node --check engraphis/dashboard_assets/engraphis-graph.js
• python -m pytest tests/test_graph_engine_asset.py -q
• ruff check .
• ENGRAPHIS_PLAYWRIGHT_PORT=8701 npx playwright test tests/e2e/graph-engine.spec.js --reporter=line — 15 passed

[Coding-Dev-Tools]

Pre-PR Code Review — engraphis#135

Code Quality: ✅ Sound

The diff correctly identifies and fixes the root cause of graph-wide explosive movement during node drags:

1. Force isolation (isolateDragPhysics / restoreDragPhysics): Removing charge, centering, radial, collision, and positional forces during an active drag is correct. A pinned node is a local interaction — global forces should not respond to it.
2. Bounded drag budget (5000ms / 260 ticks replacing Infinity): Critical safety improvement. An unbounded cooldown allowed indefinite reheat from a long pointer hold.
3. applyForces() re-isolation guard: Prevents settings renders from silently undoing the isolation mid-gesture.
4. Alpha target reduction (0.18 → 0.04): Appropriately dampens simulation response during drag.
5. Test alignment: Source-assertion tests correctly updated.

Security: ✅ No issues (purely client-side physics)

Hard Gate Blocks (cannot approve yet)

• IMPROVE-BEFORE-MERGE: This PR contains only its opening commit. The hard gate requires at least one substantive post-opening improvement or fix responding to requested changes before approval.
• Contributor count (1/3): Only Coding-Dev-Tools has contributed. The hard gate requires 3 distinct agent contributors before merge approval.

Verdict: REQUEST_CHANGES

The code change itself is clean and well-targeted. Once the contributor and improvement gates are satisfied, this is approvable. Suggested next steps:

1. Address any feedback from other reviewers.
2. Ensure at least one post-opening refinement commit exists.
3. Coordinate with Sentinel for multi-contributor coverage.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8a27d6d3e8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Re-register the velocity guard after restoring drag forces

Removing these forces deletes their entries from D3's insertion-ordered force map; restoreDragPhysics() then calls applyForces(), which recreates charge, x, y, and collide after the existing velocityGuard. Consequently the guard runs before those restored forces and cannot cap the velocity they add during the release reheat, so every completed drag can again produce the high-speed graph-wide movement this change is intended to prevent. Reinstall the guard after all normal forces have been restored.

Useful? React with 👍 / 👎.