SpeakTrue

M004 Storage Revisit Decision

Reader and post-read action

This note is for an engineer or reviewer closing M004 or planning the next storage-related slice. After reading it, they should be able to explain why M004 does not execute a broad Supabase/GCS storage migration, identify the live provider/storage smoke follow-up that remains, and know what evidence would trigger another storage revisit.

Decision

D019 defers broad Supabase/GCS storage migration execution for M004 closure.

M004 should close on the deterministic generate speech to Soundboard workflow evidence already collected for the legacy web path, the hardened speech contract, Android native contract parsing, Android native/server artifact_path Soundboard save parity, and the S05 validation pack. The next storage-related work is not a broad provider migration. It is provider smoke evidence against deployed Supabase/ElevenLabs/storage behavior before any broad migration rollout.

Evidence that supports the decision

S02: product workflow target

S02 selected the legacy web main TTS screen and Soundboard workflow as the first product-visible path for R045 and R046. That surface already had generation, save, category reload, playback, download, reuse, and storage-provider seam coverage. S02 also made storage-provider migration execution an explicit non-goal for the first workflow target.

S03: hardened workflow contract

S03 established the stable request, success, and error semantics for generated speech artifacts. The contract requires clients to retain artifact_id, artifact_path, audio_path, and download_path, prefer artifact_path for save requests, and keep privileged storage writes server-side. It also defines structured failures with error_code, operation, status, and retryable so web, native, and server callers can branch without prose parsing.

S04: native parity anchor

S04 proves Android native generation parsing, stale-artifact clearing, unsafe path rejection, structured diagnostics, retry-preserving save failure state, and server-side native artifact_path Soundboard save parity. Full playback generation requests server artifact mode, then Android forwards artifact_path, artifact_id, audio_path, download_path, category, clip name, and original text to soundboard-save-generated. The local-upload path remains compatibility behavior when no canonical artifact is available.

S05: validation and UAT pack

S05 gathered deterministic local evidence for the browser VM handoff, Flask workflow contracts, Supabase Edge handler semantics, Android native parity state, and validation-pack structure. It deliberately separates deterministic local proof from prerequisite-gated live provider/storage smoke. That separation prevents M004 from claiming production Supabase, GCS, ElevenLabs, billing, or user-media persistence proof without safe credentials and a disposable test account.

Why broad migration remains deferred

Broad storage migration is broader than the risk exposed by M004. The completed evidence shows the legacy web generate speech to Soundboard path can save and reload generated artifacts through server-side storage boundaries, and Android now proves native handoff to a server-side artifact_path Soundboard save function. The main remaining risk is live provider/storage behavior under deployed Supabase/ElevenLabs/storage conditions.

Executing a broad migration now would mix three separate questions:

1. Does the product workflow save and reuse generated speech? M004 deterministic evidence says yes for the legacy web path.
2. Do native clients preserve the same generated artifact contract? Android local evidence says yes for generation parsing, diagnostics, and server-side save parity.
3. Do live providers and storage backends behave safely under rollout and rollback? That still requires prerequisite-gated provider smoke evidence.

Keeping these questions separate makes the next slice smaller and safer. It also preserves rollback and fallback discipline: provider smoke should exercise the existing storage-provider gates before any broad Supabase/GCS migration rollout is scheduled.

Focused follow-up boundary

The follow-up should be scoped to provider smoke evidence for the deployed tts-generate artifact mode plus soundboard-save-generated path.

In scope:

• Exercise the native/server save path that forwards the canonical generated artifact fields to server-side Soundboard save logic.
• Preserve compatibility for existing native local-upload save behavior unless a later decision explicitly retires it.
• Verify structured failures for missing, unsafe, or unresolved artifact references.
• Verify Soundboard category reload/reuse metadata after server-side save.
• Run provider smoke with safe credentials and a disposable account before any broad storage migration rollout.
• Re-run migration regression gates that cover provider rollback and fallback behavior.

Out of scope for this follow-up:

• Replacing the entire storage provider layer.
• Moving privileged storage writes into browser or native clients.
• Claiming production Supabase, GCS, ElevenLabs, billing, or user-media persistence proof from local deterministic tests alone.
• Treating Android generation parsing evidence as completed server-side native save parity.

Revisit triggers

Revisit the deferral before broad rollout only if one of these events occurs:

• Provider smoke finds a live Supabase, GCS, or speech-provider failure that cannot be handled by the focused native/server save parity work.
• Migration regression gates expose rollback, fallback, or provider-path failures that invalidate the current storage-provider seam.
• Deployed native/server artifact_path Soundboard save parity fails in a way that cannot be fixed without changing the storage provider contract.
• A production requirement appears that requires broad Supabase/GCS migration before the generate speech to Soundboard workflow can ship safely.
• S05 validation evidence loses R045 or R046 traceability, or begins to depend on unsafe secrets, direct client storage writes, absolute paths, or ignored local artifacts.

Operational check

Future agents should run the storage decision verifier before changing this boundary. The verifier reports missing D019 linkage, missing R045/R046 mapping, ambiguous defer/schedule wording, missing native/server artifact_path parity evidence, missing provider smoke prerequisite, missing docs links, and unsafe content.

No conflict is currently documented between the storage-provider regression gates and the native parity anchor. The native anchor narrows the remaining gap to deployed provider/storage smoke; the provider regression gates remain the rollback safety checks for any later migration rollout.