docs(research): Vimeo + Whisper transcript feasibility findings

Vimeo texttracks API is owner-only (worse than YouTube, no public timedtext) → defer.
Whisper viable as a no-caption fallback; berget/whisper-large-v3 already on the gateway
(cloud), local options on iguana/koala carry setup+GPU-contention cost (ADR-007). Both
investigated inline (session sub-agents are network-sandboxed).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/research/vimeo-captions-feasibility.md

@@ -0,0 +1,52 @@
+# Vimeo — captions/transcripts feasibility for tapir (research, 2026-06-02)
+
+Researched by the Conductor (sub-agents were network-sandboxed). Mapped to tapir's
+`VideoSource` port (`ListSubscriptions`, `NewVideos`, `FetchTranscript`).
+
+## Verdict: SAME owner-only wall as YouTube, and WORSE fallback options.
+
+### Q3 (the gating question) — text tracks for videos you DON'T own
+- **Official API is owner-only.** Vimeo Help Center: *"You must use a personal token
+  generated as the account owner of the video in order to access your video's transcripts
+  via API."* So `GET /videos/{id}/texttracks` returns tracks only for videos the
+  authenticated account owns — identical to YouTube `captions.download`.
+  Source: https://help.vimeo.com/hc/en-us/articles/17480150130833
+- The text-track `link` points to `captions.cloud.vimeo.com/....vtt?token=...` — a
+  **token-gated** URL, not a clean public file.
+  Source: https://developer.vimeo.com/api/reference/response/text-track
+- The API is also widely reported flaky (vimeo/openapi#16 "Texttracks API doesn't work as
+  advertised"). Source: https://github.com/vimeo/openapi/issues/16
+
+### Unofficial fallback — weaker than YouTube's timedtext
+- Captions are loadable via the embed player, yielding `[n].vtt?token=...` requests, and
+  yt-dlp can pull Vimeo subs with cookies. But every documented method needs a
+  **registered/logged-in viewer** ("you need to be registered in Vimeo to retrieve
+  subtitles"). There is **no clean unauthenticated public timedtext equivalent** like
+  YouTube's `captionTracks[].baseUrl`.
+  Sources: https://gist.github.com/pjmartorell/384aa1d019f919af6b84894038bf29aa ,
+  https://github.com/vimeo/openapi/blob/master/api.yaml
+- **Needs live verification:** whether `player.vimeo.com/video/{id}/config` returns a
+  `text_tracks[]` with usable token'd URLs for arbitrary PUBLIC videos without owner auth.
+  Likely partially works for public/embeddable videos but is undocumented and brittle.
+
+### Subscriptions / new videos (the easy part)
+- "Following" exists: `/me/following` (users), plus channels/groups feeds; per-user video
+  lists via `/users/{id}/videos` sortable by date. Maps to `ListSubscriptions`/`NewVideos`.
+  Source: https://developer.vimeo.com/api/reference
+- Auth: OAuth2; many endpoints/scopes and higher rate limits require **app review**, and
+  some metadata is gated behind paid plans. (Tier/plan gating: needs-verification.)
+
+## Feasibility for tapir
+- A Vimeo adapter could do subscriptions + new-video detection fine.
+- **Transcripts are the blocker, same as YouTube but harder**: official path owner-only,
+  unofficial path requires a logged-in viewer (cookie/token), no public timedtext.
+- Realistic Stage-0 stance: **defer Vimeo.** YouTube via the timedtext path (ADR-010)
+  covers the maintainer's actual subscriptions; Vimeo adds a second brittle, auth-gated
+  caption path for a smaller share of content. If pursued: the cookie'd player-config
+  method or yt-dlp-with-cookies, behind the same "ToS-grey, opt-in" framing — a future ADR.
+- This is consistent with the port design: Vimeo is just another adapter; nothing in the
+  engine changes when/if it's added.
+
+**Biggest risk:** there is no public, unauthenticated caption path on Vimeo — any
+third-party transcript fetch needs a logged-in session/cookie, which is more fragile and
+more ToS-exposed than YouTube timedtext.