Unscoped pkill killed a sibling project's dev server; dev server bound an already-occupied port without scanning

What happened

Two related destructive-action failures in one session, on a workstation running six sibling project directories concurrently.

1. The model started a Next.js dev server with a bare next dev, binding *:3000, without scanning first. Port 3000 was already bound by Docker on 127.0.0.1:3000 and 100.91.205.49:3000.
2. To restart it, the model ran pkill -f "next-server" — a machine-wide pattern kill intended to stop only its own server. It matched any Next.js server on the host. A sibling directory's server (declared port 3333) is now a process started after the pkill ran, which is consistent with it having been killed and restarted. A second sibling on port 3100 survived only incidentally, because its process name was vinext and did not match the pattern.

What the user said

"you need to scan tcp ports before arbitrarily taking them"

Repro

In a directory tree where several sibling projects each run their own dev server, ask the model to start a dev server and later restart it. It binds the framework default port without an lsof check, and reaches for pkill -f <process-name> to stop it rather than resolving the PID from the port it owns and verifying that process's working directory.

Evidence

• Ports observed via lsof -nP -iTCP -sTCP:LISTEN: docker on 127.0.0.1:3000 and 100.91.205.49:3000; sibling servers on 3100 and 3333.
• One sibling had already shipped a scripts/preflight-ports.sh whose header states "Port 3000 is commonly occupied on this workstation and must not be silently reused." The convention existed in the tree and was not discovered before acting.

Cause (verified in-session)

Two missing habits:

1. No port scan before binding a well-known default.
2. Process termination by name pattern rather than by PID resolved from an owned port plus a working-directory check.

Suggested guidance

The correct unit of "my process" is the port plus the working directory, never the process name. pkill -f <name> asks "what is this process called?" — a question whose answer is shared by every sibling project on the machine.

Both were fixed in-session with a preflight scan and a scoped stop script; the scoped stop was then observed killing only the owned PID while leaving Docker's listener and both sibling servers running.

Environment

• Claude Code, model claude-opus-5
• Platform: darwin (macOS)