docs: realign blueprint with shipped state + add feature/journey/ideas docs

- PROJECT.md, README.md, TEST_GUIDE.md: status line refreshed; rate-limiter
  doc-vs-code drift fixed; HTML export section rewritten for the SvelteKit-
  static viewer; SSE event names + new events documented; config seed block
  extended with planned toggles + privacy_note; decision log entries added.
- docs/CONCEPT_HTML_VIEWER.md, docs/CONCEPT_MOBILE_UI.md: banner the design
  intent as shipped; point at the source-of-truth code paths.
- docs/CONCEPT_DIASHOW.md: planned-then-shipped design for the live diashow
  (two-queue policy, pluggable transitions, data-mode aware).
- docs/FEATURES.md: capability matrix by role (Guest / Host / Admin) plus
  prose per area (auth, posting, feed, moderation, admin, export, gestures,
  data mode, quotas, privacy note, extensibility).
- docs/USER_JOURNEYS.md: step-by-step flows for every supported scenario,
  including PIN reset by host, data mode, privacy note, gestures, and the
  admin toggles.
- docs/IDEAS.md: speculative extensions (global diashow, reactions,
  multi-tenancy, animation pack, etc.) — explicitly out of v0.16 scope.
- backend/migrations/README.md, frontend/src/lib/README.md: codify the
  "never edit a shipped migration" rule and the lib/ conventions
  (one store per concern, gestures via actions, sheets via ContextSheet,
  transitions as drop-in components).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
MechaCat02
2026-05-16 14:31:06 +02:00
parent 1685bf105c
commit 9a0ceeced7
11 changed files with 1241 additions and 106 deletions

199
docs/IDEAS.md Normal file
View File

@@ -0,0 +1,199 @@
# EventSnap — Ideas & Future Extensions
A dumping ground for design ideas that are **not yet on the roadmap**. Everything here is a
v2+ candidate, brainstormed once the core experience is stable. For shipped or actively
planned scope see [FEATURES.md](FEATURES.md) and the `CONCEPT_*.md` design docs.
The bar to land here is low: "would be cool one day" qualifies. The bar to graduate to a
`CONCEPT_*.md` is much higher (design committed, ready to build).
---
## Diashow extensions
### Global / synchronised diashow
Multiple devices show **the same slide at the same time** (e.g. a projector in the main
hall plus tablets behind the bar plus a screen by the photo booth).
Sketch:
- Server holds a single authoritative "current slide" cursor for the event.
- New SSE event `diashow-tick` broadcasts `{ slide_id, started_at, next_at }`.
- Each subscribed client renders locally — server only chooses ordering and pace.
- Live-queue / shuffle-queue logic (see [CONCEPT_DIASHOW.md](CONCEPT_DIASHOW.md)) lives
server-side instead of client-side.
- A "leader device" can claim the diashow, or the server runs it head­lessly. Host UI lets
Host start / stop the global diashow.
- Plays well with venues that already have multiple displays — no need for HDMI splitters
or chromecast hacks.
### Audio bed
- Host uploads or selects a background track (per-event).
- Videos in the diashow auto-mute so they don't fight the music.
- Optional ducking when a video has speech.
### Curated diashow mode
- Diashow filtered by a hashtag (`#highlights`) or to a Host-pinned set ("Story" feature).
- Useful for the end-of-evening recap reel.
### Animation pack
- More transitions out of the box: zoom, slide, mosaic, dip-to-black, push.
- Per-event "theme" preset — wedding-elegant, party-energetic, minimal, gallery-classic.
- Builds on the maintainability principle below: each transition is a drop-in Svelte
component, so growing the pack is trivial.
### Lower-third metadata
- Subtle chyron at the bottom of each slide: uploader name + timestamp + caption.
- Off by default; toggle in the diashow settings popover.
### Smart pacing
- Detect video duration and let videos play their full length (with a cap), pause stills
for the remainder. Avoids choppy 6-second cuts on a clip with key content at 0:08.
- "Action density" heuristic — slow down for portraits, speed up for landscapes.
---
## Social
### Per-guest gallery
A first-class "All posts by Anna" view, navigable from a guest's avatar — not just a
filter chip. Doubles as a personal "what did I post?" page.
### Story-style highlights
Host curates a best-of timeline pinned at the top of the feed (already in PROJECT.md's
"Should Have"). Tap-through, fullscreen, ~5 s per story, like Instagram. Could double as
the source for the curated-diashow mode above.
### Reactions beyond like
Multiple emoji reactions (❤️ 😂 😍 🎉 🥲) instead of just like. The DB design already keys
the `like` table on `(upload_id, user_id)` — generalising to `(upload_id, user_id, kind)`
is a small migration.
### Mentions and reply-threads in comments
- `@anna` in a comment becomes a tap-through to her profile / posts.
- Threaded replies under each top-level comment.
- Combined with PWA push, drives engagement.
### Collaborative captions
Co-authored captions when multiple uploaders are in the same photo — second tagger
contributes their `#hashtags` to the same post.
---
## Notifications
- PWA push for new comments on a guest's own posts.
- Per-user opt-in; granular per-event preference (mute event, mute uploader, etc.).
- Email digest after the event (1 message per guest) — optional, controversial vs. the
"no email" identity model. Could be opt-in only.
---
## Capture & posting
- **Live-photo mode** — capture a 12 s clip alongside each still (Apple-style). Diashow
could animate stills using the live clip as the Ken Burns source.
- **Boomerang / GIF capture** — short looping clips.
- **Client-side filters and stickers** — Instagram-style.
- **Voice notes** attached to a photo — "first dance" voice memo + the photo.
- **Bulk-upload presets** — pre-fill a caption for a batch ("Photos from the ceremony").
---
## Privacy & moderation
- **Per-post visibility** — "only visible to people with this hashtag" or
"private to my friend group".
- **Pre-moderation queue** — Host approves posts before they hit the public feed (default
off; for sensitive events).
- **Auto-blur** of detected faces of non-guests, or NSFW detection.
- **Per-uploader watermark** on full-quality downloads.
---
## Multi-tenancy
- **Multiple events per instance** — picked by URL slug. Today the binary is single-event.
- **Org accounts** — a wedding photographer running 4 weddings a month against the same
deployment.
- **Per-event admin** vs. **instance admin** roles.
---
## Internationalisation
- Localisation beyond German — English, French, Spanish, ...
- Admin picks UI language during setup; per-user override.
- Strings extracted into a small JSON catalogue — works well with `svelte-i18n` or similar.
---
## Export
- **Year-in-pictures PDF** — host-curated layout, printable.
- **ICS calendar attachment** of the event, included in the export ZIP.
- **Direct upload to a guest's chosen cloud** (iCloud, Google Photos) — needs OAuth, adds
a third-party integration where today there are none.
---
## Resilience / infrastructure
- **Distributed rate limiting** (Redis) for multi-instance / multi-event deploys.
- **Object-storage backend** (S3 / MinIO) behind a feature flag — out of scope for the
single-VPS use case but easy to add if multi-tenancy is ever pursued.
- **Read replicas** for very large events.
---
## Maintainability principles to keep adding features cheap
The codebase is small today and should stay friendly to extension. A few patterns to lean
into as the surface grows:
- **Diashow transitions as drop-in components.** Each transition implements a tiny
interface (`enter`, `leave`, optional `duration`). Adding a new animation is one file in
`frontend/src/lib/diashow/transitions/` and one line in a registry. Same idea for
hashtag-filter operators.
- **Per-feature toggle flags in the `config` table.** Today rate limits and quotas are
individually toggleable (see [FEATURES.md](FEATURES.md)). The same pattern fits for any
future opt-in feature — no need to redeploy to flip behaviour.
- **Background-task trait on the server.** Export, compression, and (future) analytics
jobs would all share a `BackgroundJob` interface that wires into the existing
`export_job` progress + SSE pipeline. New long-running work plugs in by implementing the
trait — no bespoke worker code per feature.
- **One Svelte store per cross-cutting concern.** Auth, upload queue, SSE, data mode,
diashow state — each lives in its own store under `frontend/src/lib/`. New UI features
consume the stores; cross-feature behaviour is composed, not copy-pasted.
- **DTOs in one file** ([frontend/src/lib/types.ts](../frontend/src/lib/types.ts)),
mirrored to the Rust DTOs. Changing a contract is exactly two edits.
- **Migration-first schema evolution** — never edit an old migration; always add a new
`0NN_*.up.sql` / `.down.sql` pair. Already the discipline; just keep it.
---
## Speculative / "would be cool"
Lower bar of plausibility — keep these around as conversation seeds:
- **AI-generated event summary** at release time (3-paragraph recap, key moments,
funniest comment).
- **AI auto-tagging** — suggested hashtags based on image content, opt-in per upload.
- **Guest-of-honour mode** — special UI for the couple / birthday person showing
*everything they're in*, prioritised by face detection.
- **Live caption translation** for international weddings — auto-translate comments
inline.
- **Sound-reactive diashow** — slides advance in sync with music BPM picked up via the
device mic.
- **Photo-booth integration** — a fixed iPad at the venue posts to the feed with a single
tap, no PIN.