fix(aspire): generated fixed host ports defeat 'aspire start --isolated'

[rickylabs]

Summary

netscript init generates explicit host ports for services, which aspire start --isolated cannot randomise. Two NetScript workspaces on one machine collide by construction, and the dashboard advertises a URL that may belong to another instance.

Reproduction steps

1. netscript init two separate workspaces.
2. Run aspire start --isolated in each.
3. Observe the generated aspire/.helpers/register-services.mts in both:

.withHttpEndpoint({ port: 3000, env: 'PORT' });

Expected behavior

Isolated mode isolates the instance. Per the Aspire guidance on parallel development, each instance gets randomised endpoints and service discovery still resolves.

Actual behavior

withHttpEndpoint({ port }) sets the host port. Isolated mode randomises Aspire's own localhost:0 endpoints (dashboard, OTLP, resource service) but cannot randomise a host port the generator fixed. The second instance collides, and the dashboard links to whichever process owns the port.

• GPT-5.6 Sol (blocker) — its dashboard presented localhost:3000 as the rehearsal API while another experiment owned it.
• Grok 4.5 (~30 min) — "default service ports collide hard when multiple AppHosts share a machine".
• Claude Fable 5 (~60 min) — same, across parallel isolated instances.

Related: netscript init also rejects service ports outside [3000, 3099], which narrows the space every workspace competes for.

Environment

0.0.1-beta.11, Aspire 13.4.6, Linux.

Suggested direction

Treat a configured service port as the target port (the port the process listens on inside its own context) and leave the Aspire host port ephemeral by default, so --isolated can do its job. If a fixed host port is genuinely wanted, name the setting HostPort and warn that it weakens isolated mode.

Note targetPort does not currently appear anywhere in packages/aspire/src, so this is a generator change rather than a configuration workaround.

This one gets worse with adoption rather than better: it breaks the first time a developer has two NetScript projects, or one project and a colleague on the same machine, and the failure mode — a dashboard confidently linking to someone else's service — actively misleads.

---

Found by an experiment in which four language models each built a different application with NetScript. Confirmed independently by 3 of 4; the generated line was then verified directly in a pristine scaffold.

[rickylabs]

Related, and probably the same fix: netscript init rejects service ports outside [3000, 3099] (reported by Claude Fable 5). That narrows every workspace on a machine into a 100-port window and makes the collision described above near-certain rather than merely possible. If configured ports become target ports with ephemeral host ports, the range restriction can probably be dropped entirely.