The welcome image was inlined as a ~2.6MB data URL in the card, bloating every
public-profile fetch. Now it's uploaded to S3-compatible object storage and the
profile carries just a URL (profile JSON dropped ~2.6MB -> ~575 bytes).
- ObjectStore: add put_object(key, bytes, content_type) + public_url(key).
R2Store uploads via a presigned PUT; InMemoryStore keeps bytes for tests.
- R2Config: add public_base (R2_PUBLIC_BASE); falls back to endpoint/bucket.
- card_service::set_welcome: decode the generated image, upload to
welcome/<id>.<ext>, store its public URL as welcome.imageUrl.
- docker-compose: add MinIO (S3-compatible, drop-in for R2) + a one-shot that
creates a public-read cardclaws-assets bucket for local dev.
- web: PublicProfile.welcome.imageUrl (renamed from imageDataUrl); WelcomeHero
unchanged. astro check clean.
Verified live against MinIO: real Gemini image uploaded, served publicly
(HTTP 200, image/png, 1024x1024), profile payload now tiny. Same code path runs
against Cloudflare R2 in production (endpoint/creds/public_base only). Gate green
(118 tests).
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Server-side proxy so the Google API key (from Infisical) never reaches the
client. Behind an AiClient trait with a fake for headless tests.
- ai.rs: GeminiClient — refine prompt (gemini-2.5-flash), generate image
(gemini-2.5-flash-image / "nano-banana"), and async video (veo-2.0:
predictLongRunning → poll → proxy the redirecting download). DisabledAiClient
when no key is configured.
- POST /v1/ai/refine, /v1/ai/image (rate-limited 60/h, 20/h)
- POST /v1/ai/video (submit, 5/h) + /v1/ai/video/status (poll → base64 mp4)
- config: GEMINI_API_KEY via SecretSource
- 5 endpoint/parse tests; full workspace gate green (114 tests)
Live-verified: refine + nano-banana return through the proxy; Veo submits,
polls to done in ~60s, and streams back a valid mp4.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
