feat(stagewise): support isolated dev instances - #1524

Check if this issue is valid — if so, understand the root cause and fix it. At apps/browser/src/backend/utils/seed-isolated-dev-profile.ts, line 40:

<comment>The one-shot seed copies mutable JSON files from the default dev profile with no atomicity or sync while that profile may be running concurrently, so an isolated instance can permanently inherit a partially-written/corrupt preferences or auth file (the marker then prevents any re-seed). Consider copying via temp-file+rename and re-attempting/clearing partial targets, or accepting this only as a best-effort dev convenience.</comment>

<file context>
@@ -0,0 +1,46 @@
+    const sourcePath = path.join(sourceDataRoot, fileName);
+    const targetPath = path.join(targetDataRoot, fileName);
+    if (!fs.existsSync(sourcePath) || fs.existsSync(targetPath)) continue;
+    fs.copyFileSync(sourcePath, targetPath);
+    copiedFileCount++;
+  }
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/browser/src/backend/utils/seed-isolated-dev-profile.ts, line 44:

<comment>The seed marker `.isolated-dev-profile-seeded` is written unconditionally after the copy loop, even when `copiedFileCount` is 0 because the source files simply didn't exist yet. Since subsequent calls short-circuit on `fs.existsSync(markerPath)`, if the default dev profile's login/preferences/credentials are created after the isolated instance's first run, they will never get copied over. Consider only writing the marker when at least one file was found in the source (or track missing files separately) so seeding can retry until real data becomes available.</comment>

<file context>
@@ -0,0 +1,46 @@
+    copiedFileCount++;
+  }
+
+  fs.writeFileSync(markerPath, '');
+  return copiedFileCount;
+}
</file context>

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/browser/vite.pages.config.ts` around lines 22 - 26, Update the port
derivation around pagesPort and its related Vite server/HMR configuration to use
collision-aware per-instance allocation instead of only applying a modulo 10,000
hash mapping. Ensure the selected server and HMR ports remain identical, and add
coverage for distinct stagewise-dev identifiers that collide under the current
mapping.

Check if this issue is valid — if so, understand the root cause and fix it. At apps/browser/vite.pages.config.ts, line 22:

<comment>The derived port for isolated dev instances is computed as `30000 + (parseInt(hash.slice(-8),16) % 10000)`, which only has 10,000 possible values. Two different worktrees can hash to the same port, and since `strictPort: true` is set, the second instance will fail to start instead of falling back to another port. Consider a collision-aware allocation strategy (e.g., checking port availability and incrementing) or a larger port space to reduce collision likelihood.</comment>

<file context>
@@ -19,6 +19,11 @@ const _appVersion = packageJson.version;
 // Release channel: 'dev' | 'prerelease' | 'release'
 const _releaseChannel = process.env.RELEASE_CHANNEL || 'dev';
 
+const pagesPort = buildConstants.__APP_BASE_NAME__.startsWith('stagewise-dev-')
+  ? 30000 +
+    (Number.parseInt(buildConstants.__APP_BASE_NAME__.slice(-8), 16) % 10000)
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/browser/src/backend/utils/seed-isolated-dev-profile.ts, line 41:

<comment>Existing Windows isolated profiles created before this change still cannot receive the default profile's `Local State`, because the persisted seed marker causes an early return before this copy runs. A versioned one-time migration or a separate missing-`Local State` check would apply the fix to already-seeded profiles without reseeding their data.</comment>

<file context>
@@ -41,6 +38,16 @@ export function seedIsolatedDevProfile(
     copiedFileCount++;
   }
 
+  if (process.platform === 'win32') {
+    const sourcePath = path.join(sourceUserData, 'session', 'Local State');
+    const targetPath = path.join(userDataDirectory, 'session', 'Local State');
</file context>

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/browser/scripts/clean-data.ts` at line 168, Wrap the completion message
template literal in the cleanup flow so each source line stays within the
repository’s 80-character limit, while preserving the existing message content
and interpolation values deletedCount and tempDeletedCount.

Check if this issue is valid — if so, understand the root cause and fix it. At apps/browser/scripts/clean-data.ts, line 144:

<comment>The standard `pnpm clean:browser-data` (no flag) now also deletes every isolated `stagewise-dev-*` profile, not just the production and regular-dev directories it cleaned before. Since the whole point of the isolated feature is to keep per-worktree data (auth, credentials, prefs) separate and persistent across concurrent worktrees, a developer running the conventional dev-cleanup command will unexpectedly wipe all of those scoped profiles. Consider gating the isolated-dir removal behind an explicit opt-in (e.g. only clean `stagewise-dev-*` when passed a flag such as `--include-isolated`), leaving the default `clean-data` behavior unchanged, and keeping `--isolated-only` as the targeted way to clean up isolated profiles.</comment>

<file context>
@@ -103,43 +103,69 @@ async function cleanTempWorkspaces(tempBasePath: string): Promise<number> {
+      if (deleted) deletedCount++;
+    }
+  }
+  for (const dirPath of await getIsolatedDirectories(appDataPath)) {
     const deleted = await deleteDirectory(dirPath);
     if (deleted) deletedCount++;
</file context>