ai(project): bind asynchronous image and interview side effects to originating project

[qnbs]

Context

Follow-up from #704 Wave 0B / PR #707.

PR #707 correctly closed the known cross-project mutation races in character/world profile generation, field regeneration, template application, outline generation/application, and snapshot restore. Review convergence also added same-ID project-incarnation tracking, fail-closed identity comparison, stale-outline-preview rejection, and regression coverage.

A final post-merge completeness sweep shows that #707 did not modify the remaining asynchronous AI paths below. They therefore still require an explicit mutation-authority audit rather than being implicitly considered closed by Wave 0B.

Residual surfaces to audit

1. Character portrait generation / refinement

generateCharacterPortraitThunk performs asynchronous AI image generation and then calls:

await storageService.saveImage(characterId, base64)

The thunk later fulfills with { characterId }, and projectSlice applies hasAvatar: true to the then-current project state.

Audit both portrait entry points in useCharacterView:

• initial portrait generation;
• portrait refinement.

2. World image generation / refinement

generateWorldImageThunk follows the analogous pattern:

await storageService.saveImage(worldId, base64)

The fulfilled reducer updates hasAmbianceImage in the then-current project state.

Audit both world-image entry points in useWorldView:

• initial image generation;
• image refinement.

3. Asset-storage ownership

storageService.saveImage(id, base64Data) is keyed by entity id and does not carry an explicit project id at this boundary.

Determine, for both IndexedDB and filesystem backends, whether a late image result originating under project A can overwrite, alias, or otherwise affect an asset later observed under project B when entity ids collide or project state changes while generation is in flight.

Do not assume Redux protection alone proves asset safety; prove the storage ownership semantics separately.

4. Character interview streaming

Audit the project/streamInterviewChunk path and its streaming producer(s). The reducer resolves characterId / interviewId against the currently active state.data.characterInterviews.

Determine whether a stream originating in project A can continue dispatching chunks after project B becomes active and mutate project-B-owned interview state.

Required invariant

For every asynchronous AI operation or streamed chunk that can mutate project-owned state or project-owned assets:

origin = project A
        ↓
async work / streaming
        ↓
active project becomes B
        ↓
late result/chunk MUST NOT mutate B
late asset write MUST NOT become owned/visible as B's asset

Use the shared project-identity authority introduced by #707 where appropriate. A request/generation token may supplement identity checks but must not replace originating-project identity.

Acceptance criteria

• Character portrait generation cannot apply state or asset side effects to a different project after a project switch/reset/import/restore.
• Character portrait refinement has the same guarantee.
• World image generation cannot apply state or asset side effects to a different project after a project switch/reset/import/restore.
• World image refinement has the same guarantee.
• Asset-storage ownership is proven safe for both IndexedDB and filesystem backends, including entity-id collision scenarios; if not, the smallest project-scoped fix is implemented.
• Character-interview streaming cannot mutate a project different from the one that originated the stream.
• Focused regression tests cover every confirmed gap, including same-id/new-incarnation cases where applicable.
• Existing fix(project): guard AI-generation results against a stale/switched active project #707 identity semantics remain fail-closed and are not weakened.
• pnpm run ci:prepush, exact-head CI/CD and CodeQL are green before merge.

Scope boundary

This issue is about cross-project mutation / asset authority only.

Do not broaden it into the general Wave 0C cancellation/AbortController redesign unless cancellation is strictly required to enforce mutation authority. General cancellation lifecycle work remains owned by #704 Wave 0C.

Do not perform provider/model-catalog, capability-matrix, connection-test, or broader AI architecture work here.

Severity

Treat as a data-integrity follow-up to Wave 0B. P1 until the audit proves or disproves a direct reproducible cross-project overwrite; elevate if a deterministic corruption path is confirmed.

[qnbs]

Downstream functional-E2E owner

Source correctness in this issue remains the prerequisite. The corresponding product-level deterministic browser qualification is now tracked in #710 (test(ai-e2e): qualify Copilot, Character Interviews, ProForge and mutation-capable AI user flows).

For this issue's scope, #710 should consume the final admitted contract after source fixes land, especially:

Character Interview stream under project A
→ switch/reset/import/restore to B
→ late chunks arrive
→ B remains unchanged

and representative Character/World/Scene image user flows after persistent asset/project ownership is proven safe.

Do not expand #708 into the broad E2E programme. Keep the dependency direction:

#708 source/data-integrity authority
        ↓
focused lower-level regression tests here
        ↓
#710 representative complete user-path E2E

The general feature-test governance layer is #709; default-off Settings/admission coverage is #711.

[qnbs]

Scope addendum — Scene image persistent-write authority

Post-merge/source completeness review after #707 confirms that #708's persistent asset-authority scope must also include the Scene visualization image path, not only Character and World images.

Additional production path to audit

Verify the current generateSceneImageThunk / equivalent Scene image generation path end-to-end.

Known risk shape to confirm from live source:

project A active
→ generate scene image asynchronously
→ result becomes available
→ active project changes to B / new incarnation
→ persistent image save executes using scene/section-derived key
→ fulfilled/UI state may be observed against current project

The same invariant already defined by this issue applies:

A late AI image result originating under project A must be rejected before persistent asset commit and before any current-project state mutation after B/new incarnation becomes active.

Required Scene-image checks

• capture originating project-incarnation authority before async image generation;
• re-check authority at the persistent-write boundary, not only later in a hook/UI callback;
• explicitly cover the race where generation resolves while A is active but the project changes before or during the asynchronous storage commit window;
• verify no current-project fulfilled reducer/UI flag can be set by the stale result;
• use identical section/entity identifiers across A/B where reachable so the test cannot pass merely because IDs differ;
• include same nominal project id / changed project generation;
• prove the same-project happy path still writes and renders normally;
• apply to both IndexedDB and filesystem-backed image semantics where the same storage boundary is used.

Storage namespace relationship

The existing #708 asset-storage audit remains authoritative for determining whether global image keys can alias across projects when entity/section identifiers collide. Scene image keys must participate in that reachability analysis.

If project-qualified asset ownership/keys are required, implement the smallest preserve-first correction with explicit legacy-read compatibility and IDB/filesystem parity. Do not perform a broad destructive storage migration.

Boundary with #713

• ai(project): bind asynchronous image and interview side effects to originating project #708 owns: persistent Scene image write/state side effects.
• ai(project): bind Writer, Copilot and deferred AI results to originating project incarnation #713 owns: any stale Scene-image preview/result retained locally after generation that could later be presented/applied/exported under another project.

Acceptance addendum

Before #708 is considered terminal, require evidence that Character, World and Scene image generation/refinement/visualization cannot persist or mark an asset into a project incarnation different from the origin, including same-ID collision fixtures and project changes at the storage-commit boundary.

[qnbs]

Ownership correction — Wave 0C now has dedicated owner #714

The original #708 body states that general cancellation/AbortController lifecycle remains owned by #704 Wave 0C.

That was correct when #708 was opened, but Wave 0C now has a dedicated durable owner:

#714 — ai(lifecycle): unify Stop Generation, cancellation, supersession and duplicate-request semantics

Use the current boundary:

#708
= direct/persistent/stream PROJECT AUTHORITY
  Character / World / Scene image writes
  asset ownership
  Character Interview cross-project mutation safety

#713
= deferred/apply-later PROJECT AUTHORITY
  Writer / Copilot / deferred AI results

#714
= REQUEST LIFECYCLE
  Stop Generation / AbortSignal / cancellation
  supersession / duplicate requests
  timeout/fallback cancellation
  late-event lifecycle admission

Cancellation may be used inside #708 only where necessary to reduce/stop work, but #708 acceptance must not depend on successful physical cancellation. The persistent/stream mutation guard must remain correct when a provider/runtime still produces a late callback/result.

[qnbs]

2026-09-11 live-audit / PR #718 review carry-forward — storage identity, legacy ownership and bounded replacement PRs

A fresh review of the currently open #718 plus CodeAnt/CodeRabbit/Cubic findings adds several verified data-integrity obligations to #708. These are bug-class requirements, not instructions to merge #718 as-is.

#718 disposition

The current PR mixes #708 and #713 ownership and exceeds the repository's hard PR-size ceiling. Treat it as a source/evidence carrier to be corrected and split, not as a candidate for a governance exception.

Preferred bounded sequence after correctness work:

#708-A project-qualified image storage / import / legacy compatibility
        ↓
#708-B async Character / World / Scene image + Interview authority
        ↓
#713-A Writer / Copilot deferred-result authority

Do not relax the <=30-file gate. Prefer headroom rather than opening a replacement PR already at the ceiling.

1. Origin identity must be captured before the first await

Character, World and Scene image operations must capture the matching storage owner + project incarnation immediately from the origin state, before lazy prompt/provider loading or any other awaited setup. Never combine a project ID from A with an identity captured from B after a switch.

2. Authority must survive the persistent-write await

A pre-save check alone is insufficient:

A result ready
→ authority check passes
→ await saveImage(...)
→ A becomes B / same id new generation while write is pending
→ stale fulfilled action must NOT mutate/mark B

Re-check after the storage await before success admission. Also keep the stronger #708 contract: if a stale result can become canonical persistent data during that window, use the smallest authority-aware/staged commit design needed to prevent that rather than relying only on the reducer guard.

3. FileReader/manual-upload and destructive-intent races are in scope

Character/World uploads must bind FileReader work to the originating incarnation and reject before/after persistence if stale. Character/World delete confirmations must not retain an entity from A and later combine it with B's live project ID; destructive intent must carry/invalidate on project incarnation.

4. New image-storage keys must preserve full identity

Both storage backends need a collision-safe physical namespace.

IndexedDB: the new qualified key must not use lossy whitespace/colon substitution or truncation that can map distinct full project IDs to the same key. Encode/digest complete project + entity identity deterministically.

Filesystem: projectPathSegment() remains useful as a validity/legacy-routing primitive, but current source shows it delegates to sanitizePathSegment() and is not itself collision-proof. Do not treat sanitized-only output as unique physical identity. Dot segments / invalid path identities must fail closed, while namespace uniqueness is established separately.

Representative regression inputs include:

alpha beta vs alpha-beta
alpha/beta vs alpha\beta
ids differing only after sanitizer/key truncation
entity ids containing delimiter-like characters
Unicode variants

Do not globally change existing project-directory identity semantics merely to fix image storage unless live consumer analysis proves that migration safe.

5. Import must resolve one authoritative storage owner

Imports with explicit, empty or missing IDs must not write images under one namespace while later project state/read/save uses another. StoryProject is not the logical project-ID authority by itself; resolve the canonical target at the real ProjectData/persistence boundary and propagate it consistently.

Legacy desktop projects that lack data.id may still have an authoritative existing directory identity (for example the current legacy-directory metadata path). Do not collapse distinct proven legacy owners to global default.

Required invariant:

admitted project owner
== imported image storage owner
== later image-read owner
== later project-save owner

Unknown/unprovable mutation identity fails closed.

6. Legacy compatibility is ownership-gated, preserve-first

Unqualified legacy image records/paths do not encode project ownership. Therefore:

ownership provable for this project
→ controlled read/promote/delete may occur

ownership ambiguous
→ preserve record
→ do not expose it as current-project data
→ do not delete it as a side effect of this project's qualified delete

Deletion ordering/failure atomicity is a second requirement, not a substitute for ownership proof. A partial failure must not resurrect a deleted image through fallback, but an ambiguous shared legacy record must also never be destroyed merely to prevent fallback.

Apply this to IDB and filesystem symmetrically.

7. Read lifecycle must use project incarnation, not only nominal IDs

Character/World image hooks must invalidate/reload on project generation change. A reset/import/restore can retain the same nominal project ID, entity ID and hasImage flag; the UI must not continue showing an old incarnation's cached imageUrl.

8. Focused regression matrix

Before #708 can be terminal, focused tests should cover at least:

• switch during lazy setup;
• switch during generation;
• switch during FileReader;
• switch immediately before storage;
• switch while storage is pending;
• switch after storage before fulfilled admission;
• same nominal project ID / new generation;
• same entity/section IDs across projects;
• IDB + filesystem namespace collisions;
• invalid dot-segment filesystem IDs;
• explicit / empty / missing import IDs;
• proven vs ambiguous legacy ownership;
• legacy/qualified deletion failure ordering;
• stale Character/World delete confirmation;
• same-ID/new-generation image read invalidation;
• same-project happy paths.

Boundary conservation

• ai(project): bind asynchronous image and interview side effects to originating project #708 owns direct/persistent/stream project authority and image-storage ownership.
• ai(project): bind Writer, Copilot and deferred AI results to originating project incarnation #713 owns Writer/Copilot/deferred-result authority.
• ai(lifecycle): unify Stop Generation, cancellation, supersession and duplicate-request semantics #714 owns cancellation/Abort/Stop/supersession lifecycle; cancellation may reduce work but must not be required for ai(project): bind asynchronous image and interview side effects to originating project #708 correctness.
• test(ai-e2e): qualify Copilot, Character Interviews, ProForge and mutation-capable AI user flows #710 later consumes the admitted product contract for representative functional browser E2E.

No broad storage rewrite, no destructive legacy migration, no second logical project-identity authority, and no unrelated README/test-count churn are required to close these findings.

[qnbs]

Residuals validated and deferred from #719 (#708-A)

#719 (the storage-namespace slice) converged with the following review findings validated as real but intentionally out of scope for a mechanical storage-namespace PR -- they require the project-incarnation/async-authority work this issue (#708-B) owns, not just a storage-key change. Recording them here as the durable backlog so they aren't lost when the corresponding PR review threads are resolved administratively.

Async identity-capture-timing (project switch during an in-flight AI image/scene generation)

• features/project/thunks/characterThunks.ts -- generateCharacterPortraitThunk/uploadCharacterImageThunk: projectId is captured synchronously at dispatch time but not revalidated after the async generation/FileReader completes, before saving/fulfilling.
• features/project/thunks/worldThunks.ts -- generateWorldImageThunk/uploadWorldImageThunk: same class.
• features/project/thunks/writingThunks.ts -- generateSceneImageThunk: same class.

Stored-image read lifecycle missing project generation

• components/CharacterView.tsx / components/WorldView.tsx -- useStoredImage's effect depends on [id, projectId, hasImage] but not project generation, so a same-id/new-generation project replacement (reset/import/restore) can leave the previous incarnation's image URL displayed until an unrelated re-render.

Delete-dialog stale-project binding

• hooks/useCharacterView.ts / hooks/useWorldView.ts -- confirmDelete pairs whatever projectId is current at confirm-time with characterToDelete/worldToDelete captured at dialog-open time; if the project changes while the dialog is open, confirm can delete a same-id entity/image in the new project.

Pre-existing, non-worsened findings (informational, not #708-B's scope)

• services/fs/assetFsStore.ts -- deleteImage catches and swallows filesystem removal failures (unchanged from origin/main, confirmed via diff) so the entity can be removed from Redux while its image survives on disk. Would need a broader delete-error-propagation change through confirmDelete in the hooks; not caused or worsened by fix(ai): project-qualify image storage and use the real delete API #719/ai(project): bind asynchronous image and interview side effects to originating project #708-B.

None of these are security/data-corruption issues in the sense of leaking one project's data into another via storage keys -- #719 already closes that class (project-qualified + collision-resistant keys, ownership-marker fail-closed legacy fallback on both backends). These are async-authority/staleness gaps: a result computed for project incarnation A being applied after incarnation B becomes active. That is exactly #708-B's stated invariant.

[qnbs]

Terminal resulting-main evidence — 2026-09-12/13 UTC

PR #734 is merged at caebeb3; the later governance merge #737 is resulting main 951a189. Exact PR and resulting-main CI/CD plus CodeQL are green.

The admitted direct project-authority contract is satisfied in resulting main: Character portrait generation/refinement and FileReader upload paths capture and revalidate project incarnation before state/persistent image effects; World image generation/refinement and uploads do the same; Scene image persistent writes and visualization presentation reject stale target/incarnation completions; Character Interview chunks and chunkless completion reject stale streams; same-ID/new-generation stored-image reads invalidate correctly; stale Character/World delete confirmations do not dispatch against a replacement project. Focused tests cover these paths, including IDB/filesystem project-qualified storage ownership and collision-safe legacy admission inherited from terminal #719.

The separate downstream product-E2E qualification remains owned by #710. Deferred-result ownership remains #713 and request lifecycle/cancellation remains #714; neither is imported into #708. #719 storage remains terminal and was not redesigned. #708 is terminal after resulting-main verification.