Creative Workbench v1 post-deployment QA and copy alignment

[DHCross]

Context

Creative Workbench v1 is reported deployed successfully in Shipyard with:

• /creative page migrated to v2 implementation
• original backed up as page-legacy.tsx
• /api/creative/chat route using Gemini 2.0 Flash
• Firebase auth integration
• ScratchpadEditor with localStorage auto-save
• CreativeActionBar quick actions
• CreativeChatPanel with markdown rendering
• responsive CreativeWorkbench layout
• TypeScript typecheck passing
• production build passing

This is good progress, but the deployment summary has a few wording/product alignment issues that should be cleaned up before treating this as final user-facing release language.

QA concerns

1. Backend/model copy mismatch

The summary says:

Type in chat → get Claude-powered responses (currently Gemini backend)

This is contradictory. If the backend is Gemini, do not call responses Claude-powered in product docs, UI text, README copy, or release notes.

Use:

Type in chat → get creative drafting responses powered by the configured backend model.

or:

Type in chat → get Gemini-powered creative drafting responses.

2. Quick action scope needs verification

The summary says all 6 quick actions are supported:

• rewrite
• condense
• expand
• outline
• lyrics
• send-to-scratchpad

Verify each action has:

• UI affordance
• correct request payload
• correct backend handling
• safe empty-selection behavior
• loading state
• error state
• useful output placement

send-to-scratchpad may not belong in the same category as model transformations because it is a local placement action, not a generation action. Consider visually separating it.

3. Auth and null-safety are not enough for UX safety

Reported auth/null-safety is good, but confirm user-facing behavior for:

• signed-out access
• expired auth token
• Gemini/API failure
• empty message
• selected text too long
• localStorage unavailable/private mode
• malformed markdown response

4. Scratchpad persistence needs visible trust cue

If scratchpad autosaves to localStorage, the UI should show a small autosave state such as:

• Saved locally
• Saving…
• Could not save locally

Without that, users may not trust the scratchpad for actual writing work.

5. Visual identity should be documented as product logic

Amber vs emerald is not just cosmetic. It signals a hard product distinction:

• Raven diagnostic engine = symbolic / interpretive / Clear Mirror
• Creative Workbench = drafting / making / transformation / scratchpad

Make sure the creative page does not reuse Raven diagnostic language or imply it is doing chart-based interpretation.

6. BFL status appears unrelated

The deployment report ends with:

BFL status: Separately ready with real ephemeris data, lock hash sealed, draw timestamp 2026-04-30T02:59:00Z.

That may be true, but it is unrelated to Creative Workbench deployment. Keep it out of Creative Workbench release summaries unless there is a direct integration reason.

Acceptance criteria

• Build/typecheck remains green.
• Release summary no longer says Claude-powered if Gemini is the backend.
• All 6 quick actions are manually tested and documented.
• send-to-scratchpad is confirmed as local placement, not model generation.
• Signed-out and API-failure UX are verified.
• Scratchpad shows autosave state or at least a clear local-save note.
• Creative Workbench copy stays distinct from Raven diagnostic copy.
• BFL/ephemeris status is removed from Creative Workbench deployment notes unless directly relevant.

Product principle

Creative Workbench should feel like a drafting bench, not another Raven readout.

It should help the user write, reshape, test, and collect material with low friction.

[github-actions]

This issue has had no activity for 14 days, so it's been marked as stale. Comment, push updates, or remove the stale label to keep it open. Otherwise it will be closed in 7 days as part of repo housekeeping.