Problem
FsProjectStore.deleteProject() removes a project's own directory (appData/projects/<id>/, including its binder assets and codex), but does not know about the project-qualified image namespace directory introduced in #708-A (appData/images/<projectNamespaceSegment>/, keyed by a SHA-256 digest of the project id, not the project id's own directory name). Deleting a project therefore leaves every qualified image for that project as an orphaned, unreachable directory under appData/images/.
This is a disk-space/storage-hygiene leak, not a correctness or security issue: the images are unreachable (no code path can construct their namespace segment without the original project id), not incorrectly exposed to another project.
Invariant
Deleting a project should also remove its project-qualified image namespace directory, while preserving the existing legacy-flat-image safety rules established in #708-A (ownership-marker-gated deletion of the unqualified/pre-qualification appData/images/*.png files, and the .legacy-owner marker itself).
Scope
FsProjectStore.deleteProjectUnlocked() (or a sibling helper in FsAssetStore) computes the same project-namespace segment saveImage/getImage/deleteImage use and removes that directory as part of project deletion.
- Must not touch the separate legacy-flat-image ownership logic (
.legacy-owner marker, appData/images/*.png flat files) -- those follow their own, already-implemented preserve-first rules.
- Failure to remove the namespace directory should be logged and non-fatal to the rest of project deletion (matching this method's existing error-handling style), not silently swallowed without a trace.
Non-goals
- No changes to the IndexedDB backend (single-project-at-a-time architecture; this is filesystem-backend-specific).
- No changes to the legacy-image ownership-marker semantics themselves.
- No broader project-lifecycle/cleanup redesign.
Dependencies
Builds on #708-A's project-qualified image namespace (projectNamespaceSegment() in services/fs/assetFsStore.ts).
Regression test
A test proving: save an image for project A, delete project A, assert the qualified image directory for A no longer exists, while a legacy flat image already owned by a different project is left untouched.
Problem
FsProjectStore.deleteProject()removes a project's own directory (appData/projects/<id>/, including its binder assets and codex), but does not know about the project-qualified image namespace directory introduced in #708-A (appData/images/<projectNamespaceSegment>/, keyed by a SHA-256 digest of the project id, not the project id's own directory name). Deleting a project therefore leaves every qualified image for that project as an orphaned, unreachable directory underappData/images/.This is a disk-space/storage-hygiene leak, not a correctness or security issue: the images are unreachable (no code path can construct their namespace segment without the original project id), not incorrectly exposed to another project.
Invariant
Deleting a project should also remove its project-qualified image namespace directory, while preserving the existing legacy-flat-image safety rules established in #708-A (ownership-marker-gated deletion of the unqualified/pre-qualification
appData/images/*.pngfiles, and the.legacy-ownermarker itself).Scope
FsProjectStore.deleteProjectUnlocked()(or a sibling helper inFsAssetStore) computes the same project-namespace segmentsaveImage/getImage/deleteImageuse and removes that directory as part of project deletion..legacy-ownermarker,appData/images/*.pngflat files) -- those follow their own, already-implemented preserve-first rules.Non-goals
Dependencies
Builds on #708-A's project-qualified image namespace (
projectNamespaceSegment()inservices/fs/assetFsStore.ts).Regression test
A test proving: save an image for project A, delete project A, assert the qualified image directory for A no longer exists, while a legacy flat image already owned by a different project is left untouched.