# dailysplice — brief

**What:** A personal radio show that rebuilds itself. DailySplice interleaves
music from the listener's own streaming subscription with **generated spoken
segments** — a DJ that introduces tracks, offers a tidbit, and relays context
from people the listener is connected to ("your dad has been listening to Nick
Cave, and here is why"). A second, timeless variant is the **appreciation
splice**: a curated journey through a genre or an artist ("understanding jazz",
"a lifetime of Nick Cave") built to be shared.

**Why:** An algorithmic daily mix is a commodity; Spotify ships one. What no
algorithm does is tell you *why* this song matters to someone you love, or walk
you into a genre you have never understood. The interesting part is the splice —
what is said between the tracks, and who it comes from.

**Who:** Rian (owner, builder, super admin). A small invited group of users to
start — invite-only, no self-serve signup. Self-serve account creation is a
later, deliberate step.

**Status:** **Foundation.** The workspace, the stack, and authentication are
built and deployed; the product itself is not. What exists today: a public
landing page at <https://dailysplice.com>, "Sign in with BW" (Pattern B) with
invite-only admission, a signed-in shell, and the Postgres/Alembic substrate.
No Spotify integration, no podcast handling, no playlist generation yet. Current
state and what is next: [`.logs/handoff.md`](.logs/handoff.md).

## Where everything is
| Role | Lives in |
|---|---|
| Build plan, milestones, gates | [`.logs/planning/dailysplice-2026.md`](.logs/planning/dailysplice-2026.md) |
| Session handoff (what next) | [`.logs/handoff.md`](.logs/handoff.md) |
| Session summaries | [`.logs/diary.md`](.logs/diary.md) |
| Project constitution | [`agents.md`](agents.md) |
| Substrate friction (compiles into the server plan) | [`.logs/v8-feedback.md`](.logs/v8-feedback.md) |
| The app itself | `main/` (code only) |
| Human reference material | `notes/` |
| Coding standards | `/srv/projects/standards/` (coding.md → react.md → frontend.md) |

## Stack

FastAPI + SQLAlchemy 2 / Alembic + Postgres 17 sidecar, serving a Vite + React
19 SPA as static files from the same single Python process. Per
`/srv/projects/standards/react.md` — the server's standard stack for an app that
needs a real database, genuine app-like UI, and a plausible path to being a
product. No Node at runtime; no service worker (see `agents.md` for why).

**Auth is BW Auth Pattern B in PUBLIC domain mode.** The host is not gated, so
the public landing page is genuinely public; users sign in with a BW account
(optionally via Google) and the app keeps its own session. **Admission is
invite-only and enforced in the app** — signing in with a BW account is not the
same as having access. See `agents.md`.

## Not doing

- **No hand-rolled login, password store, or user credentials.** Identity comes
  from id-auth (`coding.md`). This is not revisitable.
- **No self-serve signup yet.** Invite-only until the product is worth opening.
  When it opens, it opens through the invite table, not by weakening admission.
- **No service worker** (see `agents.md` — it silently breaks the OAuth
  callback). A native mobile app is no longer ruled out: plan §3c notes iOS
  gives materially more control over DRM playback than the web does.
- ~~**No music playback in-app.**~~ **REVERSED 2026-08-05.** This said the app
  builds playlists and never plays audio. Plan §3c overturned it: per-user
  spoken segments cannot be delivered through Spotify at all, so DailySplice has
  to be its own player, interleaving streamed music with generated speech. Kept
  visible rather than deleted — it was a reasonable constraint that a real
  finding invalidated, and knowing it was considered is worth more than a clean
  list.
- **No recommendation ML** until the deterministic splice rules are proven
  boring and correct.

## Known gaps

- **The splice rules are unspecified.** What is said, when, and how often is
  still `TBD`. The plan's §3 holds the open questions; question 1 (what a
  "podcast episode" is) was answered 2026-08-05.
- **The delivery architecture is decided but unproven.** RSS-into-Spotify is
  impossible for per-user content (plan §3c), so DailySplice must be its own
  player. **Interleaving DRM-protected music with generated speech in a seamless
  queue is not a documented operation** — it is the single biggest technical
  unknown and nothing should be built on top of it before it is prototyped.
- **Platform concentration.** For the full player experience **Apple Music is
  the only viable host** (plan §3d): Spotify is capped at 5 users forever,
  and YouTube's API terms forbid a custom player, alternate audio tracks, and
  background play. That is a single point of failure of exactly the kind Spotify
  just demonstrated.
- **No Spotify app registered yet.** Spotify's own OAuth (separate from BW Auth)
  and the per-user token storage that comes with it are unbuilt; the security
  shape of storing third-party refresh tokens is decided in the plan before any
  code lands.
- **No backup substrate.** Server-wide backups are v8 T4.8, not started. The
  Postgres volume is unbacked today. Fine for a foundation with no user data;
  resolve before anyone's playlists matter.
- **Not load-tested, no test suite beyond the auth boundary.** The auth gate is
  the only thing worth testing so far, and it is what is tested.