User Feedback and Experience.

[schutera]

Let users at least see their own module images (this would require authentication)... which we do not want to have.
.. but we need to give users something.

So maybe we make a hole detection early on. And show the hole snips in the frontend?
Users need to be more engaged...

[cofade]

@schutera — proposal: split this user story into three phases; the first is already implemented.

Why split: "show users something" and "hole detection" are different sizes of work with different risk. Showing imagery unblocks engagement now with zero new infrastructure (image reads are already public per ADR-019 — GET /api/images* has no auth gate); detection deserves its own design round (CV approach, snip storage, classification heuristic).

Phase 1 — latest capture in the module panel: PR #164. The public dashboard's module panel now renders the module's newest upload as a "Latest capture" card with a full-size lightbox. Frontend-only; covered by vitest + a Playwright spec that proves real pixels render end-to-end.

Phase 2 — hole detection + per-nest snips: #165. Your snips idea, with a twist worth calling out: cropping is the privacy mechanism — a snip of just the nest hole shows no garden/balcony background, so per-nest imagery can be public without authentication. There's prior art already in the repo (dev-tools/circle.txt, dev-tools/montage*.png, the mock_cutouts.png sketch), and since the holes get located anyway, replacing the random stub_classify() with a real empty/sealed brightness heuristic comes nearly free — the existing sealed-% bars would show real data for the first time.

Phase 3 — engagement features on top: #166. Per-nest time-lapse ("watch your hole get sealed"), a "recently sealed" feed, optionally a weekly email digest (modules already store a registration email — no auth needed). Blocked on phase 2.

Suggest keeping this issue open as the umbrella until phase 2 lands, or closing it in favour of #165/#166 once you've reviewed the split — your call.