Guard patch apply when the target project's dev server is running (Turbopack node_modules churn)

[alamb-hex]

Summary

Applying a patch to a project whose dev server is running breaks that project's dev server. The apply pipeline (/api/projects/[id]/update, and cve-lite --fix via /api/security/cve-lite/[id]/fix) runs pnpm install, which relinks node_modules. A live Turbopack/Next dev server loses its handle to node_modules/next mid-reinstall and panics:

FATAL: An unexpected Turbopack error occurred.
Next.js package not found
- Execution of ... directory_tree_to_loader_tree failed

(The accompanying "inferred your workspace root" message is a misleading symptom — next is still installed; the running process just lost it during the churn.)

When HexOps patches itself (the hexops project in the dashboard is this repo), this is self-inflicted: the dev server you're using to click "Apply" is the one that dies.

How it was hit

Observed while testing the CVE Lite per-finding Apply on the hexops project's qs advisory (see PR #108). The override install churned node_modules while node server.js (Turbopack dev) was live → panic → dev server died. Recovery required rm -rf .next + restart.

Current state

• "Fix all direct" confirm dialog already warns: "You may need to restart that project's dev server."
• Per-finding Apply has no such warning.
• Neither actually prevents the breakage.

Proposed

HexOps already tracks per-project process state (start/stop, metrics). Before an apply:

1. Detect whether the target project has a running dev server (reuse the start/stop/port tracking).
2. If running, guard: either
   • warn + require confirmation ("Applying will reinstall dependencies and restart 's dev server"), or
   • offer stop → apply → restart orchestrated by HexOps (cleanest), or
   • at minimum, surface the warning on the per-finding Apply path too (parity with "Fix all direct").
3. Consider auto-rm -rf .next/dev + restart as part of the orchestrated path so Turbopack comes back clean.

Related

Surfaced during #107 / PR #108 (CVE Lite apply→commit→push). Related to #90 (stop signal propagation) since a clean stop→apply→restart depends on reliable stop.

[alamb-hex]

Confirmed recurrence — 2026-05-24.

Hit this exact failure again while remediating qs (CVE-2026-8723) on hexops itself via the CVE Lite page:

• Clicked Apply on the qs finding → the apply ran pnpm install → churned node_modules → hexops's own live Turbopack dev server lost node_modules/next mid-request and died.
• The browser's in-flight fetch to the apply endpoint failed with "Failed to fetch" (connection dropped, not a 500).
• The apply half-completed: pnpm-lock.yaml got bumped (qs→6.15.2 plus ~145 lines of unrelated in-range churn) but package.json never received the override and no success was shown.

So the symptom set is: "Failed to fetch" + a half-applied lockfile + a dead server. This is hexops patching itself through the very server the patch tears down.

Workaround used: patched from the CLI instead (server was down), producing a clean qs-only diff.

Reinforces the proposed fix: detect a running dev server for the target project and either warn hard or orchestrate stop → apply → restart (+ rm -rf .next/dev). The self-patch case (target project == hexops) is the most dangerous variant and should be special-cased.

[alamb-hex]

Shipped in #123 (squash-merged to main as 68397cb). Dev-server-aware patch guard is live: decideDevServerGuard / isHexopsSelf / runWithDevServerGuard — self-patch refused with 409, tracked managed servers get stop→apply→restart; wired into /update, /security/cve-lite/[id]/fix, and /override-remove. Squash tree verified byte-identical to the branch tip — no commits dropped. Remaining sub-item: /escalate is block-self only today; its orchestrated stop/restart is a separate follow-up (open a new issue if you want it tracked).