The browser path helper briefly acted as a type predicate, which made existing non-browser path branches narrow to never under the production build. The callers now guard nullable paths explicitly while the helper stays a plain boolean check.
Constraint: ProjectSetupModal depends on checking both browserfs paths and regular filesystem strings in the same helper flow.
Confidence: high
Scope-risk: narrow
Tested: npm test -- --run src/components/__tests__/GenerateImageNode.test.tsx src/store/execution/__tests__/nanoBananaExecutor.test.ts src/components/__tests__/GenerationComposer.test.tsx
Tested: npx tsc --noEmit --pretty false filtered to touched browser path files
Not-tested: Full tsc remains blocked by existing test typing errors outside this change scope
Browser-local projects were deriving a null generations path, so carousel entries that only retained an image id could not resolve media during previous/next navigation. Generated images are now written into the browser-selected generations folder, project metadata keeps that browserfs generations path, and the image node can read browserfs generation files directly before falling back to the server load endpoint.
Constraint: Browser-selected folders cannot be read through server API routes.
Rejected: Keep relying on inline image history only | saved or migrated workflows can contain id-only history entries.
Confidence: high
Scope-risk: moderate
Directive: Browser-local media paths must stay on the File System Access API path, not server /api/load-generation.
Tested: npm test -- --run src/components/__tests__/GenerateImageNode.test.tsx src/store/execution/__tests__/nanoBananaExecutor.test.ts src/components/__tests__/GenerationComposer.test.tsx
Tested: npx tsc --noEmit --pretty false filtered to touched files
Not-tested: Full tsc remains blocked by existing test typing errors outside this change scope
The hosted app should not save each operator's project into the shared test server filesystem when the browser can grant local folder access. Project creation now requires a browser-selected local folder in supported browsers, remembers that folder as the project browser root, and the workflow browser can list and load projects from File System Access handles. Server filesystem APIs remain as a fallback for unsupported browsers.
Constraint: Hosted users need per-operator local project storage instead of shared server paths.
Rejected: Keep manual absolute path entry on supported browsers | it can silently target the server filesystem in the deployed app.
Confidence: high
Scope-risk: moderate
Directive: Do not re-enable server path entry for hosted browsers without adding per-user isolation and auth boundaries.
Tested: npm test -- --run src/components/__tests__/ProjectSetupModal.test.tsx src/components/__tests__/QuickstartTemplatesView.test.tsx src/store/utils/__tests__/localStorage.test.ts
Tested: npx tsc --noEmit --pretty false filtered to changed files
Server-side native folder pickers cannot select a Windows user's local directory when the app is deployed remotely. This adds a browser File System Access path for supported browsers so the user can choose a local folder, create the project subfolder, and save the workflow JSON directly from the client.
Constraint: File System Access handles are browser-only and cannot be passed to server filesystem APIs
Constraint: External media folder storage still depends on server filesystem endpoints, so browser-local projects keep media embedded or remote in the workflow JSON
Rejected: Make /api/browse-directory choose the user's Windows folder | that endpoint runs on the server, not in the browser
Confidence: medium
Scope-risk: moderate
Directive: Extend the browser filesystem utility for local media inputs/generations before enabling external media storage for browserfs paths
Tested: npx vitest run src/components/__tests__/ProjectSetupModal.test.tsx src/components/__tests__/Header.test.tsx
Tested: npm run build
Not-tested: Manual Chrome/Edge File System Access flow on Windows test server
jiajia