docs(store): record the live-capture attempt and Jan's debug-command call

testCaptureNewPhotosCard timed out against a static, unchanging
framecontent album - RotationReconciler's "new" is relative to what
start() already saw, so a pre-populated album can never look like an
arrival no matter how long the test waits. Jan's call: next session
adds a debug command that raises the toast directly against the
already-playing live slideshow, no live content change or timing
coordination required.

Claude-Session: https://claude.ai/code/session_01FSMU2G3JXpeRqF61zHdjwS

Author: kipp-ing

docs/handover-store-slots.md

@@ -144,6 +144,42 @@ album to trigger a real arrival, then a capture over a real photo. That means ac
 before a session does it, and worth deciding whether a separate scratch album is safer than
 reusing `framedemo`.
 
+### Later same session: a live-capture rig was built, then Jan called it — supersede it next time
+
+Jan pointed at a **separate, dedicated content album** for this: `https://frame.kippings.de/s/framecontent`
+("frameContent", reachable from this machine — confirmed with a plain `curl`, `assetCount: 3` as
+of 2026-09-11). Built against it: `testCaptureNewPhotosCard` in `AppStoreScreenshotUITests.swift`
+(onboards through that link, never touches the hero-photo `demoLink`), plus two **DEBUG-only,
+env-var-gated levers** (`OwnFrameApp.swift`, compiled out of Release entirely) —
+`SCREENSHOT_CAPTURE_NEW_PHOTOS_CARD=1` forces the setting on without navigating Settings, and
+`SCREENSHOT_CAPTURE_REFRESH_SECONDS` shortens FR-310-06's fixed 60-minute interval to a few
+seconds. Both are legitimate, harmless scaffolding — kept, not reverted.
+
+**It didn't work in one live attempt, and the reason is instructive.** The test polled for a
+card that never appeared. Checking the album directly (`GET
+/api/shared-links/me?slug=framecontent`, the same read-only endpoint the app itself calls, no
+credentials needed) showed exactly why: the album has held a static 3 assets since it was
+created — nothing changed *during* the test's run, so the refresh had no delta to notice.
+`RotationReconciler`'s "new" is relative to whatever `start()` already saw; a pre-populated,
+unchanging album can never look like an arrival, no matter how long a test waits or how short the
+refresh interval is. This is real-time-coordination-dependent by construction: someone has to add
+an asset *after* the slideshow is already playing and *before* the wait times out — awkward to
+choreograph over chat, doubly so across a background task and a live person.
+
+**Jan's call, to action next session:** stop trying to manufacture a genuine server-side arrival
+for the capture. Instead, **add a debug command that raises the toast directly** — a DEBUG-only
+trigger (hidden gesture, or an App Intent alongside the existing Shortcuts support from topic
+800, or similar) that calls straight into a new debug-only `SlideshowViewModel` method to publish
+a `NewArrival` on demand, with no dependency on `RotationReconciler`, no live content change, no
+polling, no timing coordination. The photo behind the card still has to be real (FR-9010-04) —
+so the command fires against the **already-playing live slideshow** (any real source, e.g.
+`framecontent` or `framedemo`), forcing only the *card*, never faking the photo. Once that
+command exists, capturing slot 5 becomes as deterministic as slots 1/2/6: start the real
+slideshow, invoke the command, capture, done — no more of this session's live-arrival dance.
+`testCaptureNewPhotosCard` and its two env-var levers can stay as a fallback/regression check
+against the real refresh contract, but the debug command is what next session should actually use
+to generate the picture.
+
 ---
 
 ## 2026-09-10 (later) — four questions from Jan, answered empirically