Isolate SOP/WP data per project (namespaced localStorage)

SOP and Work Package localStorage keys are now namespaced by the active
project via ProjectData.key(base) -> base+'__'+<projectId> (SK() in the
suite, wpKey() in the creator), so switching projects shows that project's
own SOP and packages. project-data.js runs a one-time discard of the legacy
un-namespaced keys (guarded by wp_ns_migrated_v1), per the chosen approach.

Active project is resolved before the store loads in both the suite and the
creator so namespaced keys resolve correctly, including standalone deep-links.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-15 15:46:59 -07:00
parent 3c40b58ff8
commit e5c450597a
5 changed files with 75 additions and 33 deletions

View File

@@ -158,13 +158,20 @@ SOP and Work Package belongs to one.
empty. Passes `&project` into the WP-creator iframe.
- **WP creator:** stamps `projectId` onto every saved package (for API sync).
**Not yet done (the next fork):** SOP/WP *localStorage* is still global, not
namespaced per project — selecting a different project locally still shows the
same `wp_suite_sop` / `wp_iwp_v1` data. The intended end state is per-project
data via the API (`GET /api/sops/latest?project_id=…`, `GET /api/wps?project_id=…`).
Decide whether to (a) namespace the local keys by project id with a migration of
existing un-namespaced data into a "default" project, or (b) jump straight to the
API for SOP/WP reads. See the open question below.
**Per-project isolation (done, local):** SOP/WP localStorage keys are now
namespaced per active project via `ProjectData.key(base)` →
`base + '__' + <projectId>` (`SK()` in the suite, `wpKey()` in the creator).
So each project keeps its own `wp_suite_sop` / `wp_suite_state` /
`wp_suite_sop_complete` / `wp_iwp_v1`. On first load after this change,
`project-data.js` runs a **one-time discard** of the legacy un-namespaced keys
(guarded by `wp_ns_migrated_v1`) — chosen over migrating, since the local data
was throwaway demo content.
**Still ahead (true Phase 2):** move SOP/WP reads+writes to the API filtered by
`project_id` (`GET /api/sops/latest?project_id=…`, `GET /api/wps?project_id=…`)
so projects are shared across users, not just isolated per browser. The
endpoints already accept the `project_id` filter; the front end still reads
localStorage.
**Pending — Phase 2: wire the front end to the API**
- SOP: on *SOP Complete*, `POST /api/sops`; on load, `GET /api/sops/latest` to hydrate the Creator (currently uses `localStorage` key `wp_suite_sop`).