Commit graph

2 commits

Author SHA1 Message Date
Daniel
500fe2c12a fix: image Done state, chat titles that keep whole words, and readable extension cards
The Create image popup showed "Generating image…" forever even after the job
finished. The status poll called fetchAssistantImageJob, which was never
imported, so every tick threw ReferenceError — and the catch treated that like a
transient network failure and rescheduled, permanently. The import is added, a
test now asserts that every api.js function the assistant calls is actually
imported, and the poll distinguishes a programming error (surface it) from a
transient one (retry, but not forever).

Chat titles were hard-cut at 60 characters mid-word, so "Rickets Radiographic
Fea" was all the Create image picker could ever show. The server already allows
160, so titles now keep whole words up to that, and each view decides its own
visible length from the width it actually has rather than inheriting one cut made
at save time. A single very long token still falls back to a hard cut.

Extension cards led with the number at 20px with word-break:break-all, so
"5616/3764/5619" wrapped as "5616/3764/56 19" — unreadable, and unsafe to dial
from. The name leads now, since that is what the eye hunts for in a list of
fifty; the number follows in tabular figures and may only break between groups,
never inside a run of digits. Cards share a minimum height so a grid reads as
rows rather than a ragged mosaic.

The collapsed rail's brand kept its expanded margin-right:auto, which pushed the
stethoscope off the axis the two buttons sat on. Every child of the collapsed
head is now the same centred fixed-size box.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018e1PLqrKgAM9jQhFKRnbLd
2026-09-10 06:44:22 +02:00
Daniel
2f7233f317 perf: store real image previews in MinIO, generated at creation and on demand
Gallery tiles are 56px but were downloading the full ~280kB original. Previews
are now rendered with sharp and stored beside the originals in the same MinIO
bucket under a thumbs/ prefix, so nothing about credentials, lifecycle or backup
changes. Measured on live assets: 216-294kB originals become 13-19kB at 256px,
about 16x smaller; 640px is about 4x.

Both paths, as asked:
- Rendered when a job completes, so the first viewer never waits for a resize.
  A preview failure never unmakes a finished job.
- Rendered on demand for anything that has none — the existing 26 images work
  immediately with no backfill required, and the result is stored for next time.

Boundaries that matter more than the speed:
- Only 256 and 640 are honoured. An open width parameter would let a caller
  drive arbitrary resizes.
- Permission is checked against the ORIGINAL before a preview is served, so a
  preview can never widen who can see an image.
- Previews carry their own SHA-256 and owner headers, because the client
  verifies both on every asset; sending the original's checksum would be
  rejected as tampering, which is that check working correctly.
- Still private, no-store. The client asset pattern was widened to exactly
  ?w=256 and ?w=640 and nothing else.

Client-side downscaling stays as the fallback when a preview cannot be produced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018e1PLqrKgAM9jQhFKRnbLd
2026-09-10 06:39:30 +02:00