chore(ci): remove mirror job (SSH key rotation pending)

Mirror to github.com was failing with 'unsupported in libcrypto' on every run
(OpenSSL 3.6 / OpenSSH 10 dropped support for the existing key format). Removed
rather than leave it polluting the CI signal. Re-add when the deploy key is
rotated to ed25519.

.gitea/workflows/ci.yml

@@ -90,24 +90,4 @@ jobs:
             && echo "Smoke test passed" \
             || echo "Smoke test inconclusive: $OUTPUT"
 
-  # ── 3. Mirror to GitHub (deploy intentionally omitted until manifests exist) ─
-  mirror:
-    name: Mirror to GitHub
-    needs: build
-    runs-on: self-hosted
-    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Push to GitHub
-        run: |
-          mkdir -p ~/.ssh
-          echo '${{ secrets.GH_DEPLOY_KEY }}' > ~/.ssh/id_rsa_gh_mirror
-          chmod 600 ~/.ssh/id_rsa_gh_mirror
-          ssh-keyscan github.com >> ~/.ssh/known_hosts 2>/dev/null
-          GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_gh_mirror -o IdentitiesOnly=yes" \
-            git push git@github.com:mathiasb/tapir.git HEAD:main
-          rm ~/.ssh/id_rsa_gh_mirror
-          echo "Mirrored to GitHub"
+  # ── 3. Mirror to GitHub — skipped for now (SSH key rotation pending) ─

CLAUDE.md

@@ -79,23 +79,33 @@ Skills live in the canonical library `mathias/skills` and are wired into this re
 
 ## Current build state (start here for the first task)
 
-The repo is **scaffolded and intentionally RED**:
+The repo is **green and shipping** — last tag `v0.4.0`. `task check` passes (fmt, vet, lint,
+`go test -p 1 ./...`). Go is `1.26.1` (see `go.mod`).
 
-- Clean Architecture skeleton exists: `internal/domain` (entities), `internal/ports`
-  (interfaces), `internal/usecase` (engine), `cmd/tapir` (entrypoint stub),
-  `internal/adapters` (empty — concrete adapters go here).
-- `usecase.Engine.ProcessNewVideo` returns `ErrNotImplemented`.
-- `test/acceptance/summarize_new_video_test.go` translates the first two Gherkin scenarios and
-  **fails** against the stub. `task check` is therefore red on `test`.
-- **First build task:** implement `ProcessNewVideo` (resolve transcript -> summarize -> deliver to
-  sinks | skip on no-transcript) to make the acceptance tests green, following the `.feature`
-  files. Then add the AI-router `Summarizer` (copy `llm` per ADR-004), the YouTube `VideoSource`
-  adapter (captions-first), and the store + brain sinks.
+- Clean Architecture core is implemented: `internal/domain` (entities), `internal/ports`
+  (interfaces), `internal/usecase.Engine.ProcessNewVideo` (resolve transcript → summarize →
+  deliver to sinks | skip on no-transcript). The acceptance tests in `test/acceptance/` are
+  green against it.
+- Adapters present under `internal/adapters/`: `youtube` (captions-first `VideoSource`,
+  timedtext/InnerTube acquisition per ADR-010), `summarizer` + `llm` (the copied AI router,
+  Primary→Fallback per ADR-004), `store` (Postgres, golang-migrate migrations 001–006),
+  `secrets` (file-backed `SecretStore`). The brain HTTP sink (ADR-005) is the remaining
+  optional sink.
+- Stage 1 is open (ADR-012): multi-user with **DB-enforced** isolation — Postgres RLS `FORCE`d
+  on all user-owned tables (migration 003), two-user isolation test in
+  `internal/adapters/store/rls_test.go`. Registration gate, per-user YouTube web connect, and
+  account management (disconnect / delete, ADR-013) all shipped.
+- `cmd/tapir` subcommands: `list`, `show`, `auth` (interactive host-side OAuth), `run` (batch
+  watch→summarize), `serve` (the HTMX+Templ web reader/writer under `internal/web`, a new
+  transport over the unchanged engine/ports — ADR-003). `tapir env` prints config.
+- **Build/run:** `task check` is the gate; `task build` produces the binary. Local dev uses
+  `StubAuth` (allow-all) and a `TAPIR_DB_DSN` Postgres; the deployed service uses Dex OIDC.
 
-**Unverified setup items** (see `docs/homelab-integration.md`, marked `confirm`): the Go version
-in `go.mod` (1.23 — match the koala runner; estate elsewhere uses 1.26.1), the brain-mcp URL, the
-exact ESO secret-ref naming, and the summarization model alias. Resolve against the live cluster
-before depending on them, and pin answers back into `docs/homelab-integration.md`.
+**Setup facts** (resolved — see `docs/homelab-integration.md` for the live values): LiteLLM is
+off-cluster at `koala:30401/v1/` with `LITELLM_MASTER_KEY` from 1Password; the summarization
+model is config (`TAPIR_SUMMARIZER_MODEL`, default `koala/phi4-mini`), never hardcoded. The
+brain-mcp base URL and ESO ref scheme are pinned in that doc; check it before wiring rather than
+re-deriving.
 
 ## Provenance (where this design came from)
 

DECISIONS.md

@@ -154,6 +154,22 @@ governs advancement. Reversible: if demand appears, a new ADR opens the Future C
 
 ---
 
+## ADR-009 — Trunk-Based Development
+
+**Status:** Accepted (2026-06-02)
+
+**Context.** Platform-wide convention (homelab architecture review invariant; gitea-mcp #27):
+commit directly to `main`, one logical change per commit, every commit deployable.
+
+**Decision.** Tapir follows TBD. Commit directly to `main`. No feature branches or PRs for
+solo/agent work; short-lived `agent/<desc>` branches only when parallel agents are active on
+the repo simultaneously. CI is the quality gate, not branch protection.
+
+**Consequences.** Consistent with the rest of the estate. Depends on the direct-to-main write
+path tracked in gitea-mcp #35 (item #1).
+
+---
+
 ## ADR-010 — Third-party caption acquisition via the timedtext/player baseUrl
 
 **Status:** Accepted (2026-06-02)
@@ -203,22 +219,6 @@ player/timedtext baseUrl) only. ADR-007's captions-first stance and the STT defe
 
 ---
 
-## ADR-009 — Trunk-Based Development
-
-**Status:** Accepted (2026-06-02)
-
-**Context.** Platform-wide convention (homelab architecture review invariant; gitea-mcp #27):
-commit directly to `main`, one logical change per commit, every commit deployable.
-
-**Decision.** Tapir follows TBD. Commit directly to `main`. No feature branches or PRs for
-solo/agent work; short-lived `agent/<desc>` branches only when parallel agents are active on
-the repo simultaneously. CI is the quality gate, not branch protection.
-
-**Consequences.** Consistent with the rest of the estate. Depends on the direct-to-main write
-path tracked in gitea-mcp #35 (item #1).
-
----
-
 ## ADR-011 — Web read-surface at Stage 0: Dex authn (single-user authz), action signal, public ingress + GitOps
 
 **Status:** Accepted (2026-06-02)
@@ -290,6 +290,104 @@ explicit call, with isolation as the guardrail that keeps it safe.
 
 ---
 
+## ADR-013 — Account deletion is Tapir-side only; the Dex identity is left intact
+
+**Status:** Accepted (2026-06-03)
+
+**Context.** Stage 1 (ADR-012) added account deletion. A registered user is two things: a
+`users` row (plus all their data, cascade-linked) in Tapir's Postgres, and a subject identity
+in **Dex** (the homelab OIDC provider, shared across the estate — Tapir does not own it).
+"Delete my account" could mean (a) erase all Tapir-side data and secrets, or (b) that plus
+deprovision the Dex identity. The maintainer chose (a).
+
+**Decision.** Deleting a Tapir account removes **only Tapir-side state**:
+- The `users` row, cascading to all user-owned tables (`videos`, `transcripts`, `summaries`,
+  `sink_deliveries`, `video_connections`, and — via an **explicit delete**, because it has no
+  FK — `summary_actions`). The delete test asserts the cascade reaches every table and leaves
+  other users' rows untouched.
+- All of that user's secrets in the SecretStore (the per-user YouTube refresh-token refs).
+
+The **Dex identity is deliberately left intact.** Tapir does not deprovision, disable, or
+modify the shared Dex directory.
+
+**Consequences.**
+- **Clean re-registration:** a deleted user who logs in again arrives as a Dex-authenticated
+  subject with no `users` row, so they hit the registration gate as a "new" user — no special
+  resurrection path needed. This is a feature of the choice, not an accident.
+- **Right-to-erasure is partial.** The user's *identity* still exists in Dex after deletion.
+  For Future B (trusted friends) this is acceptable: Dex is the maintainer's own directory and
+  the identity carries no Tapir content. **But if Tapir ever moves toward Future C (real
+  external/public users), this is a GDPR-shaped gap** — a true "delete my account" there must
+  also deprovision or anonymise the Dex identity, which is a new ADR and likely a Dex-admin
+  integration Tapir does not currently have.
+- **Blast radius stays small:** Tapir never holds write access to the shared identity provider,
+  consistent with the estate's blast-radius-minimisation posture (ADR-002, architecture review).
+
+**Reversibility.** Adding Dex deprovisioning later is a superseding ADR; nothing about the
+current choice blocks it. Recorded now because "deletion is partial by design" is a deliberate
+semantic that future-Tapir (and any compliance review) must know was chosen, not overlooked.
+
+---
+
+## ADR-014 — Timedtext 429 handling: per-host backoff + honest in-flight UX, before any Whisper reconsideration
+
+**Status:** Accepted (2026-06-03)
+
+**Context.** ADR-010 acquires captions from the unauthenticated `timedtext` baseUrl. Live runs
+show that endpoint **rate-limits per source IP (HTTP 429) under volume** — many videos fetched
+in one pass from one egress IP. Stage 1 (ADR-012) made this sharper in two ways: multiple users
+now drive fetches from the *same cluster egress IP*, and the v0.4.0 "Summarize" button fires an
+**immediate, synchronous-feeling** fetch on click (HTMX polls `/v/{videoId}/status`), so a 429
+now surfaces as a *user-facing stall* rather than a background batch hiccup. A throttle
+(`TAPIR_FETCH_DELAY`) exists but is a fixed inter-fetch delay, not 429-aware, and does not
+coordinate across the concurrent click-path and the `tapir run` batch path.
+
+This ADR is **not** a decision to build Whisper. ADR-007/010 keep STT deferred *pending
+measurement of the sustainable caption rate* — and that rate cannot be measured while the
+client reacts badly to the 429s it already provokes. Fix the backoff and the UX first; the
+clean data then tells you whether Whisper is warranted.
+
+**Decision.**
+
+1. **429-aware backoff at the fetch layer.** On a 429 from the timedtext/InnerTube fetch,
+   respect `Retry-After` when present; otherwise exponential backoff with jitter. This replaces
+   reliance on a fixed `TAPIR_FETCH_DELAY` alone (which stays as a floor/politeness delay).
+2. **A single per-egress-IP rate gate** shared by *both* the `tapir run` batch path and the
+   web click path, so they cannot collectively exceed the sustainable rate. Concurrency into
+   the timedtext endpoint is serialised/limited at this gate regardless of how many users or
+   goroutines are upstream. (The 429 is per *IP*, not per user — so the gate is process-/
+   cluster-egress-wide, not per-`withUser`.)
+3. **Honest in-flight UX (the product-shaping part).** The status poll distinguishes states
+   the user can understand instead of a spinner that silently stalls:
+   - *summarizing* — actively processing (the existing tapir spinner).
+   - *queued / waiting for rate limit* — fetch deferred behind the rate gate; show a calm
+     "queued, this can take a few minutes when busy" state, not a stuck spinner.
+   - *no transcript* — terminal, per ADR-010's degrade-never-error (a 429 that exhausts retries
+     resolves to `SourceNone`, same as any unavailable caption — it must not present as a hard
+     error to the user).
+   The spinner promising imminence is the wrong signal under rate-limiting; the UX must be able
+   to say "waiting" truthfully.
+4. **Measurement before Whisper.** Only once (1)-(3) are in and a real sustainable
+   per-IP rate is observed do we revisit whether caption coverage is good enough or whether the
+   deferred Whisper fallback (ADR-007) is finally warranted. That reconsideration is a future
+   ADR, gated on this data.
+
+**Consequences.**
+- Caption fetching becomes well-behaved under multi-user load instead of self-inflicting 429s;
+  the endpoint is treated as the shared, rate-limited resource it is.
+- The click-path UX stays honest: "waiting" reads as waiting, failure degrades to "no
+  transcript", never a stuck spinner or error spew.
+- A future per-IP cooldown / second egress IP / proxy becomes an option the rate gate can sit
+  in front of without UX changes.
+- **Still no Whisper** — and now there's a clean path to the *data* that decides whether it's
+  ever needed (`docs/homelab-integration.md` and a future ADR own that measurement).
+
+**Open (tracked, not in this ADR's scope):** the actual sustainable rate number; whether a
+dedicated egress IP / outbound proxy is worth it; CronJob-driven `tapir run` interaction with
+the rate gate (the batch path moves into k3s per the deferred CronJob item).
+
+---
+
 ## Rejected alternatives
 
 Approaches considered during the 2026-06-02 planning + grill session and **deliberately not

docs/architecture/architecture.md

@@ -45,7 +45,7 @@ adapter behind an interface (Clean Architecture ports & adapters).
 ```mermaid
 graph TB
     subgraph tapir["Tapir (Go)"]
-        http["HTTP server<br/>OAuth callbacks +<br/>user-facing API"]
+        http["tapir serve<br/>(HTMX+Templ web surface:<br/>read summaries, connect,<br/>account, summarize)"]
         watcher["Watcher<br/>detects new videos<br/>(WebSub + poll)"]
         engine["Summarization engine<br/>(use-case core)"]
         resolver["Transcript resolver<br/>(captions-first)"]
@@ -95,6 +95,66 @@ two codebases (ADR-003).
 
 ---
 
+## Web surface — `tapir serve` (Stage 1, ADR-011 → ADR-012)
+
+A later transport added over the **unchanged** engine/ports/sinks core (ADR-003): `tapir serve`
+is an HTMX+Templ reader/writer (`internal/web`) over the existing `store`. It added no business
+logic to the engine — it reads the store and, for one action, kicks the existing engine. ADR-011
+shipped it single-user; ADR-012 opened multi-user with DB-enforced (RLS) isolation.
+
+```mermaid
+graph TB
+    browser["Browser<br/>(Dex-authenticated user)"]
+    subgraph web["internal/web (tapir serve)"]
+        oidc["oidc<br/>Dex OIDC session<br/>(authenticate-only)"]
+        gate["registration gate<br/>new subject -> /register"]
+        pages["summary list + detail<br/>(read) + actions"]
+        connect["/oauth/youtube/callback<br/>per-user token connect"]
+        account["account<br/>(disconnect, delete)"]
+        summarize["Summarize button<br/>-> background goroutine"]
+    end
+    store[("store<br/>(Postgres, RLS per user)")]
+    engine["Summarization engine<br/>(unchanged core)"]
+    secrets["SecretStore<br/>(per-user token refs)"]
+
+    browser --> oidc
+    oidc --> gate
+    gate --> pages
+    pages --> store
+    connect --> secrets
+    connect --> store
+    account --> store
+    account --> secrets
+    summarize -->|background| engine
+    summarize -->|HTMX status poll| store
+    engine --> store
+```
+
+- **Dex OIDC session layer** (`internal/web/oidc`) — **authenticate-only** (ADR-012). It proves
+  *who*; authorization/isolation is the DB's job (RLS), not the session's.
+- **Registration gate** — a Dex subject with no `users` row is routed to `/register`, which
+  creates the `users` row + the `user_identities` mapping (migration 004). Returning subjects
+  pass straight through.
+- **Web-initiated YouTube connect** — `/oauth/youtube/connect` → `/oauth/youtube/callback`
+  persists a **per-user** refresh-token ref (`youtube/<userID>/refresh_token`) via `SecretStore`
+  and a `video_connections` row (ADR-006, migration 005). Distinct from the CLI `tapir auth`.
+- **Account management** — `/account` offers disconnect and **delete account**. Delete removes
+  only Tapir-side state (cascade across the user's tables + secret refs); the shared Dex identity
+  is left intact (ADR-013).
+- **Immediate summarization** — the web "Summarize" button (`POST /v/{id}/summarize`) fires the
+  engine in a **background goroutine** inside `serve`; the page HTMX-polls `/v/{id}/status`,
+  showing a Charmbracelet spinner while in-flight (and an honest "queued/waiting" state under
+  rate-limiting — ADR-014).
+- **Summarization mode** — `users.auto_summarize` (migration 006). Auto: every new video is
+  summarized. Manual (default): new videos appear unsummarized; the button sets
+  `videos.summarize_requested`, which the next `tapir run` processes and clears. Both the click
+  path and the batch `tapir run` drive the same unchanged engine.
+
+The engine, ports, and sink adapters are **untouched** by all of the above — the web surface only
+reads the store and triggers the existing engine. Adding it changed wiring, not the core (ADR-003).
+
+---
+
 ## Sequence — core use case: new video summarized
 
 ```mermaid
@@ -191,6 +251,8 @@ Gherkin features in `docs/use-cases/`).
 
 - Audio-download + speech-to-text resolver (ADR-007) — would be an additional `VideoSource`
   fallback path, drawn when built.
-- Multi-tenant isolation primitives (per-tenant Postgres role, NetworkPolicy, tenant label)
-  — activate at Stage 1 (ADR-002); single-user Stage 0 doesn't exercise them.
+- Per-user isolation is **live, not deferred**: Postgres RLS `FORCE`d on every user-owned table
+  (ADR-012, migration 003), realising ADR-002's per-tenant intent at the DB layer. The coarser
+  multi-tenant primitives (per-namespace NetworkPolicy, Kyverno, tenant label) remain a
+  Stage-2 hardening item, not exercised yet.
 - Public SaaS surface (sign-up, billing) — Future C, not built (ADR-008).

docs/data-model.md

@@ -23,11 +23,16 @@ only opaque references to them; the secret material lives in ESO/1Password (ADR-
 
 ## Entities
 
+Solid entities below are **persisted today** (migrations 001–006). `AI_CREDENTIAL` and
+`SUBSCRIPTION` are **planned, not yet a table** — kept in the model for intent; see the notes.
+
 ```mermaid
 erDiagram
+    USER ||--|| USER_IDENTITY : "logs in via (Dex subject)"
     USER ||--o{ VIDEO_CONNECTION : has
-    USER ||--o{ AI_CREDENTIAL : has
-    VIDEO_CONNECTION ||--o{ SUBSCRIPTION : exposes
+    USER ||--o{ SUMMARY_ACTION : records
+    USER ||--o{ AI_CREDENTIAL : "has (planned)"
+    VIDEO_CONNECTION ||--o{ SUBSCRIPTION : "exposes (planned)"
     SUBSCRIPTION ||--o{ VIDEO : "produces (per user)"
     VIDEO ||--o| TRANSCRIPT : "has at most one"
     VIDEO ||--o| SUMMARY : "has at most one"
@@ -36,14 +41,20 @@ erDiagram
     USER {
         uuid id PK
         text display_name
+        bool auto_summarize "default false -> manual mode out of the box (migration 006)"
+        timestamptz created_at
+    }
+    USER_IDENTITY {
+        text dex_subject PK
+        uuid user_id FK "UNIQUE -> USER, ON DELETE CASCADE; NOT RLS-enabled"
         timestamptz created_at
     }
     VIDEO_CONNECTION {
         uuid id PK
-        uuid user_id FK
+        uuid user_id FK "-> USER, ON DELETE CASCADE"
         text provider "youtube | vimeo"
-        text provider_account
-        text token_secret_ref "-> SecretStore, never the token"
+        text provider_account "nullable"
+        text token_ref "-> SecretStore, never the token"
         text status "active | revoked | error"
         timestamptz connected_at
     }
@@ -66,14 +77,15 @@ erDiagram
     }
     VIDEO {
         uuid id PK
-        uuid user_id FK
-        uuid subscription_id FK
+        uuid user_id FK "-> USER, ON DELETE CASCADE"
+        uuid subscription_id "nullable; no FK at Stage 0"
         text provider
         text provider_video_id
         text title
         int duration_s
         timestamptz published_at
         text url
+        bool summarize_requested "default false -> manual-mode queue flag (migration 006)"
         timestamptz seen_at
     }
     TRANSCRIPT {
@@ -87,7 +99,7 @@ erDiagram
     SUMMARY {
         uuid id PK
         uuid user_id FK
-        uuid video_id FK
+        uuid video_id "no FK to videos; (user_id, video_id) UNIQUE is the dedup key"
         text summary
         jsonb highlights
         jsonb takeaways
@@ -98,26 +110,53 @@ erDiagram
     }
     SINK_DELIVERY {
         uuid id PK
-        uuid summary_id FK
+        uuid summary_id FK "-> SUMMARY, ON DELETE CASCADE; ownership derived via this FK"
         text sink "store | brain"
         text status "pending | delivered | error"
         text detail "nullable; error message etc"
         timestamptz updated_at
     }
+    SUMMARY_ACTION {
+        uuid id PK
+        uuid user_id FK "-> USER"
+        text video_id "TEXT, not FK (mirrors summaries' standalone key)"
+        text action "watched | skipped | saved"
+        timestamptz acted_at
+    }
 ```
 
+`SUMMARY_ACTION` has `UNIQUE (user_id, video_id, action)`; `VIDEO_CONNECTION` has
+`UNIQUE (user_id, provider)` (one connection per provider — reconnect upserts in place).
+RLS (`ENABLE` + `FORCE`) is on **every solid user-owned table above** — `users`, `videos`,
+`transcripts`, `summaries`, `summary_actions`, `video_connections`. `sink_deliveries` is
+RLS'd via an `EXISTS` on its parent summary; `user_identities` is intentionally **not** RLS'd
+(auth plumbing). See the *Isolation invariant* section for the mechanism.
+
 ## Notes per entity
 
-- **USER** — at Stage 0 there is exactly one row. At Stage 1, identity comes via Dex; this
-  table holds the Tapir-side profile keyed to the Dex subject.
-- **VIDEO_CONNECTION** — a connected YouTube/Vimeo account. `token_secret_ref` resolves to
-  the OAuth refresh token via `SecretStore`. Revocation flips `status`, doesn't delete history.
-- **AI_CREDENTIAL** — optional, per provider, per user (ADR-004's Fallback). Absent for users
-  who only use the local stack. One row per provider max.
-- **SUBSCRIPTION** — a watched channel. `websub_expires` tracks the YouTube push lease so the
-  watcher knows when to re-subscribe; null for poll-based (Vimeo).
+- **USER** — one row per registered user (Stage 1, ADR-012; no longer single-row). The Tapir-side
+  profile; the Dex identity is held separately in `USER_IDENTITY`, not on this row. `auto_summarize`
+  (migration 006) is the per-user mode flag: `FALSE` (default) = manual, `TRUE` = auto-summarize
+  every new video.
+- **USER_IDENTITY** (migration 004) — the `dex_subject → user_id` map. `dex_subject` is the PK,
+  `user_id` a `UNIQUE` FK to `users` with `ON DELETE CASCADE`. This is the bridge resolved at login
+  *before* a `user_id` is known, so it is **deliberately not RLS-enabled** (it holds no user data;
+  RLS here would deadlock the lookup that yields the id used for scoping). Account deletion cascades
+  the mapping away (ADR-013).
+- **VIDEO_CONNECTION** (migration 005) — a connected YouTube/Vimeo account. `token_ref` resolves to
+  the OAuth refresh token via `SecretStore` (per-user scheme `youtube/<userID>/refresh_token`).
+  `UNIQUE (user_id, provider)`: one connection per provider, reconnect upserts. Revocation/disconnect
+  flips `status`, doesn't delete history. FORCE RLS'd.
+- **AI_CREDENTIAL** — *planned, no table yet.* Optional, per provider, per user (ADR-004's Fallback).
+  BYO keys are currently resolved via `SecretStore` refs without a dedicated table; this entity is
+  modelled for when per-credential metadata is needed.
+- **SUBSCRIPTION** — *planned, no table yet.* A watched channel; `websub_expires` would track the
+  YouTube push lease. At Stage 0/1 `videos.subscription_id` is a nullable column with **no FK** (the
+  subscriptions table is not part of the shipped store-sink slice — migration 001).
 - **VIDEO** — one row per (user, video) — note `user_id`, reflecting the per-user-isolation
   decision. The same video seen by two users is two rows. `seen_at` is when Tapir detected it.
+  `summarize_requested` (migration 006) is the manual-mode queue flag: the web "Summarize" button
+  sets it `TRUE`; the next `tapir run` picks it up, summarizes, and clears it back to `FALSE`.
 - **TRANSCRIPT** — at most one per video. `source = none` records "checked, no usable
   transcript" so the watcher doesn't reprocess (ADR-007). `content` null in that case.
 - **SUMMARY** — at most one per video. `fallback_used` + `ai_provider`/`ai_model` make the
@@ -125,14 +164,39 @@ erDiagram
   `takeaways` as jsonb to stay schema-flexible while the output format settles.
 - **SINK_DELIVERY** — one row per (summary, sink) attempt. This is where "also sent to brain"
   lives — no brain tables, just a delivery row with `sink = brain`. Sinks fail independently;
-  a failed brain delivery doesn't fail the store delivery.
+  a failed brain delivery doesn't fail the store delivery. No own `user_id`; RLS ownership is
+  derived from the parent summary via `EXISTS` (migration 003).
+- **SUMMARY_ACTION** (migration 002) — records the maintainer's act on a summary (watch / skip /
+  save) — the column that makes the Stage-0 headline metric ("acts on ≥1 summary") queryable
+  (ui-spec.md §5, ADR-011). `video_id` is `TEXT` and **not** FK-constrained, mirroring summaries'
+  standalone `(user_id, video_id)` key. `UNIQUE (user_id, video_id, action)`. FORCE RLS'd.
 
-## Isolation invariant (Stage 1+)
+## Isolation invariant (Stage 1+) — LIVE
 
-Every user-owned table carries `user_id`. At Stage 1, this is enforced at the DB layer via a
-per-tenant Postgres role + row grants (architecture review SC7), not only in application code.
-At Stage 0 (single user) the column exists but the enforcement is dormant. The isolation test
-in VISION Stage 2 asserts user A cannot read user B's rows.
+Every user-owned table carries `user_id`, and isolation is **enforced at the DB layer**, not
+only in application code. ADR-011 shipped this surface single-user (one allowlisted subject,
+enforcement dormant); **ADR-012 opened Stage 1 and turned enforcement on in the same slice.**
+
+Enforcement is **Postgres Row-Level Security** (migration `003_rls.up.sql`):
+
+- RLS is `ENABLE`d **and** `FORCE`d on every user-owned table — `users`, `videos`,
+  `transcripts`, `summaries`, `summary_actions`, `video_connections`. `FORCE` is load-bearing:
+  the app connects as the table **owner** (`tapir` role), and owners bypass RLS unless forced.
+- Each policy keys off the per-request GUC `tapir.current_user_id`, set transaction-locally by
+  the store's `withUser` helper via `set_config('tapir.current_user_id', $1, true)` — it
+  auto-resets on commit/rollback, so it never leaks across a pooled connection.
+- `current_setting('tapir.current_user_id', true)` uses `missing_ok = true`: an **unset** GUC
+  yields `NULL`, the predicate matches no rows, and access **denies by default**.
+- `sink_deliveries` has no `user_id`; its policy derives ownership from the parent summary via
+  `EXISTS (SELECT 1 FROM summaries …)`.
+- `user_identities` (the Dex-subject → user_id map) is **deliberately not RLS-enabled** — it is
+  auth plumbing read *before* a user_id is known; putting RLS there would deadlock. It holds no
+  user data.
+
+The Stage-2 isolation bar is **pulled forward, not deferred**: `internal/adapters/store/rls_test.go`
+runs two users against a non-superuser, non-`BYPASSRLS` role and asserts user A reads/writes zero
+of user B's rows across every table. It ships green with the multi-user features (ADR-012); no
+multi-user feature merges ahead of it passing.
 
 ## Job / processing state
 

docs/specs/landing-page-and-doc-reconciliation.md

@@ -0,0 +1,153 @@
+# Spec — Landing page + documentation reconciliation
+
+**Date:** 2026-06-03
+**Status:** Ready to build
+**Scope:** Two parallel workstreams — (A) a public landing page; (B) reconciling the
+requirements / use-case / architecture / data-model docs against the deployed reality
+(v0.4.0). These are separate concerns; do not let one worker do both, or the audit gets
+done cursorily.
+
+All work: read `CLAUDE.md` + `DECISIONS.md` first. TBD — commit directly to `main`, one
+logical change per commit, conventional commits, `task check` green before every commit.
+After editing any `.templ`, run `templ generate` (the repo commits both `views.templ` and the
+generated `views_templ.go`).
+
+---
+
+## Workstream A — Public landing page
+
+### Goal
+A public landing page at `/welcome`, in the established bubbletea aesthetic, that lets a
+visitor sign in (one Dex flow) and, if already logged in, jump to their Tapir page or log out.
+New public transport surface only — no engine/core change (ADR-003).
+
+### Verified facts (read from `internal/web/oidc/oidc.go` @ main — do not re-guess)
+- Auth endpoints are exactly `/auth/login`, `/auth/callback`, `/auth/logout`.
+- `isPublicPath(p)` = `p == "/healthz" || strings.HasPrefix(p, "/auth/")` — the single
+  public-route chokepoint inside `DexAuth.Middleware`.
+- `DexAuth.CurrentUser(r) (web.User, bool)` reads the session cookie and does NOT redirect —
+  this is the "peek" the landing page uses to branch logged-in vs logged-out.
+- `handleCallback` redirects to `/` on success (correct — leave as-is).
+- `handleLogout` currently redirects to `loginPath` (`/auth/login`) — this is wrong for this
+  feature (see A3).
+- There is NO separate "sign up" against Dex/OIDC: one authorization flow. Registration is
+  Tapir's own `/register` step (ADR-012), reached after first login for an unknown subject.
+
+### Tasks
+**A1 — make `/welcome` public.** In `oidc.go`, extend `isPublicPath`:
+```go
+func isPublicPath(p string) bool {
+    return p == "/healthz" || p == "/welcome" || strings.HasPrefix(p, "/auth/")
+}
+```
+
+**A2 — unauthenticated bare-`/` → `/welcome`; deep links unchanged.** In `DexAuth.Middleware`,
+the unauthenticated branch currently always calls `redirectToLogin`. Change it so that when
+`r.URL.Path == "/"` an unauthenticated visitor is redirected to `/welcome`; for any other
+guarded path keep `redirectToLogin` (so a shared `/v/{id}` deep link still bounces through Dex
+and returns to the destination). Keep the `isPublicPath` check first (redirect-loop guard).
+
+**A3 — logout lands on `/welcome`, not login.** In `handleLogout`, change the final redirect
+from `loginPath` to `/welcome`. As written it sends the user to `/auth/login`, which
+immediately starts a fresh Dex login — visibly failing to log out. This intentionally breaks
+the existing logout test (oidc_test.go) which asserts redirect to `/auth/login`; update that
+test to expect `/welcome`. That break is expected, not a regression.
+
+**A4 — mount the landing handler** in `internal/web/handlers.go` `Router()`, on `root`,
+OUTSIDE `Auth.Middleware`, alongside `/healthz`:
+```go
+root.HandleFunc("GET /welcome", a.handleWelcome)
+```
+`handleWelcome` peeks `a.Auth.CurrentUser(r)` and renders `WelcomePage(user, ok)`. Not behind
+`Auth.Middleware` or `registrationGate`.
+
+**A5 — `WelcomePage` templ component** in `views.templ`. Reuse the existing shared
+layout/header partial and the established aesthetic (#7653FC purple rounded ╭─╮╰─╯ box, pink
+tapir mascot, #0EF9B6 mint accents) — match the existing pages, do not reinvent styling.
+- Logged out (`ok == false`): tapir mascot + tagline; one primary CTA **"Get Started"** →
+  `/auth/login`; honest sub-text: "New here? You'll set up your account right after signing in
+  — returning users go straight through." One button only (see verified facts: no separate
+  Dex sign-up; two buttons to the same URL would mislead).
+- Logged in (`ok == true`): "Go to my Tapir" → `/`; "Log Out" → `/auth/logout`. May greet via
+  `user.Email`.
+
+**A6 — tests** (extend `handlers_test.go` patterns). Note `StubAuth.CurrentUser` always returns
+true; for the logged-out case use a fake Auth returning `(web.User{}, false)`.
+- `GET /welcome`, no session → "Get Started" → `/auth/login`.
+- `GET /welcome`, with session → "Go to my Tapir" + "Log Out".
+- Unauthenticated `GET /` → 302 `/welcome`.
+- Unauthenticated `GET /v/{id}` → still 302 `/auth/login` (deep link preserved).
+- Authenticated `GET /` → still serves the list, unchanged.
+- oidc: `handleLogout` → 302 `/welcome` (update the existing test).
+
+**A out of scope:** no Dex config change, no new auth/session logic, no sign-up backend.
+
+---
+
+## Workstream B — Documentation reconciliation
+
+### Why
+The guardrail docs were written before Stage 1 and the web surface. Several now describe the
+opposite of the deployed reality (v0.4.0). Stale guardrail docs are worse than none — a future
+cold session (human or agent) trusts them. This workstream brings requirements, use cases,
+architecture, and data-model back in sync with `main`. Each fix is one commit; cite the ADR or
+migration that is the source of truth.
+
+### Known drift to fix (verified this session — not exhaustive; the worker confirms against code)
+**B1 — `internal/web/auth.go` comments.** The `User.Subject` doc and package doc still say
+"single-user allowlist (ADR-011)" / "Stage-0". Code is multi-user (ADR-012). Update the
+comments to describe the current multi-user reality; reference ADR-012.
+
+**B2 — `docs/data-model.md` isolation status.** It says isolation enforcement is "dormant at
+Stage 0". It is now LIVE: Postgres RLS, `FORCE`d on all user-owned tables, with a passing
+two-user isolation test (ADR-012, migration 003). Rewrite that section to describe enforced
+RLS as the current state; keep the history honest (was dormant at Stage 0, enforced from
+Stage 1).
+
+**B3 — `docs/data-model.md` schema completeness.** The doc predates migrations 002–006. Add
+the entities/columns that now exist: `summary_actions` (002), RLS (003), `user_identities`
+(004, dex_subject→user_id), `video_connections` (005), `users.auto_summarize` +
+`videos.summarize_requested` (006). The ER section should match the live schema. Cross-check
+against `internal/adapters/store/migrations/*.up.sql` — those are ground truth.
+
+**B4 — `docs/architecture/architecture.md`.** Predates the entire web surface. Update the C4
+container diagram and text to include: `tapir serve` (HTMX+Templ web reader/writer), the Dex
+OIDC session layer (`internal/web/oidc`), registration gate, web-initiated YouTube connect,
+account management, and the immediate-processing path (web "Summarize" button → background
+goroutine → status poll). The engine/ports/sinks core is unchanged (ADR-003) — show the web
+surface as a new transport over the same core, not a core change.
+
+**B5 — `docs/use-cases/*.feature`.** Add scenarios for the behaviours now live and unspecced:
+register (new subject → registration → user row; returning user straight through), connect
+YouTube (web OAuth), disconnect, delete-account (cascade + secret purge, Dex untouched —
+ADR-013), manual-vs-auto summarize mode + the Summarize button, and the landing page
+(logged-out CTA; logged-in shortcuts). Keep them as executable-style Gherkin consistent with
+the existing files.
+
+**B6 — `DECISIONS.md` ADR ordering (cosmetic).** ADR-010 sits before ADR-009/011 (append
+order). Reorder to numeric while you're in the file. Pure tidy, no content change.
+
+**B7 — requirements check.** If a requirements doc exists (e.g. `docs/ui-spec.md`, referenced
+by ADR-011), reconcile it with what shipped: note where the build deviated (e.g. the spinner /
+immediate processing / summarize mode were beyond the original spec) so the spec reflects
+reality or explicitly records the deviation. Do not silently rewrite history — record
+deviations as deviations.
+
+### B working method
+- Source of truth order: migrations + code > ADRs > prose docs. When a prose doc disagrees
+  with code, the code wins and the doc is corrected (unless the code is the bug — then flag it,
+  don't quietly doc around it).
+- One logical doc per commit. Cite the ADR/migration that justifies each change in the commit
+  body.
+- This is an audit, not a rewrite: preserve the docs' structure and the "rejected alternatives
+  / history" honesty. The goal is *current and trustworthy*, not *pretty*.
+
+---
+
+## Coordination
+A and B touch mostly different files (A: oidc.go, handlers.go, views.templ, tests; B: docs/* +
+auth.go comments). The one overlap is `auth.go` (B1 edits comments) vs A (reads it) — no
+conflict. Run A and B in parallel; commit independently to `main`.
+
+If anything in B reveals that code, not docs, is wrong (e.g. an isolation gap, a migration that
+doesn't match the data-model intent), STOP and surface it — that's a finding, not a doc edit.

docs/ui-spec.md

@@ -147,3 +147,28 @@ Gate (lane A) commits first; B/C/D follow.
 
 `task check` green per lane; B/C/D rebase on A. Deploy (D) lands last, after the binary serves
 locally.
+
+---
+
+## Deviations and additions (as-built)
+
+This spec describes the **Stage-0 single-user reader** (ADR-011). What actually shipped through
+v0.4.0 went further — Stage 1 (ADR-012) opened multi-user, and several UX features were added on
+top. Recorded here (append-only; the spec above is left intact) so intent and reality stay
+distinguishable.
+
+| As-built feature | What it is | Why | Covered by |
+|------------------|-----------|-----|------------|
+| **Multi-user + RLS isolation** | Several Dex users per deployment; isolation enforced by Postgres RLS, not the single-subject allowlist of §6. | Maintainer opened Stage 1 ahead of the formal Stage-0 gate, with DB-enforced isolation as the guardrail that keeps it safe. | ADR-012; migration 003 (`6775e5f`, `f28fdc0`, `2ae66da`) |
+| **Registration gate** | A Dex subject with no `users` row is routed to `/register`, which creates the `users` row + a `user_identities` mapping. (§2 listed "sign-up / user CRUD" as a non-goal.) | Explicit registration is how a multi-user surface stays honest — no just-in-time row creation. | ADR-012; `f396e01` |
+| **Per-user YouTube web connect** | `/oauth/youtube/connect` → `/oauth/youtube/callback` stores a per-user refresh-token ref + a `video_connections` row. (The spec assumed a host-side `tapir auth` only.) | Multi-user means each user connects their own account from the browser. | ADR-006, ADR-012; migration 005 (`0c9531a`, `2aad79b`) |
+| **Account management** | `/account` page with **disconnect** and **delete account**; delete removes only Tapir-side state and leaves the Dex identity intact. (§2 listed isolation/CRUD as non-goals.) | A real account needs a way out; deletion semantics are deliberately Tapir-side only. | ADR-013; `22eafcf`, `c7624d9`, `17d5e8c` |
+| **Immediate web summarization** | A "Summarize" button (`POST /v/{id}/summarize`) runs the engine in a background goroutine inside `serve`; the page HTMX-polls `GET /v/{id}/status`. (§2 said "triggering runs from the browser … do NOT build".) | Reading a list you can't act on is half a product; on-demand summarize closes the loop without waiting for a batch `tapir run`. | ADR-012, ADR-014; `25215cb`, `8c6c7ca` |
+| **Charmbracelet tapir spinner** | An animated in-flight indicator (charm palette) shown while a summarize is processing; an honest "queued/waiting" state under rate-limiting rather than a stuck spinner. | The spinner must tell the truth when the timedtext endpoint rate-limits (429), not imply imminence. | ADR-014; `25215cb`, `a4aeb5e` |
+| **Auto/manual summarization mode** | Per-user `auto_summarize`; manual (default) lists new videos unsummarized and queues via `summarize_requested`; a mode toggle at `/account/summarize-mode`. | Control over compute/noise — only summarize what the user cares about. | migration 006 (`748d5eb`, `bdbdce7`, `3014ee0`, `a269d4a`) |
+| **Public landing page** | `/welcome` mounted **outside** the auth guard; unauthenticated `/` redirects there; logout returns there (not `/auth/login`). (The spec guarded everything except `/healthz` and `/auth/*`.) | A first-time visitor needs a public "what is this / get started" page before the login wall. | `d83943c`, `0fdf2f7`, `3a27bf1`, `d208110`, `8ca374e`, `f15f57f` |
+
+The original Stage-0 goals (read summaries, record watch/skip/save actions, Dex login, GitOps
+deploy) still hold — these are additions over that base, not replacements. The architecture
+stance is unchanged: every item above is web-surface or store work; the engine/ports/sinks core
+was not modified (ADR-003).

docs/use-cases/landing_page.feature

@@ -0,0 +1,28 @@
+Feature: Public landing page
+  As a first-time visitor
+  I want a public welcome page before I log in
+  So that I understand what Tapir is and how to get started without hitting a login wall
+
+  Scenario: An unauthenticated visit to the root is sent to the welcome page
+    Given I am not logged in
+    When I open the root path "/"
+    Then I am redirected to "/welcome"
+
+  Scenario: The welcome page invites an unauthenticated visitor to start
+    Given I am not logged in
+    When I open "/welcome"
+    Then I see a "Get Started" call to action
+
+  Scenario: An authenticated user on the welcome page sees their way in and out
+    Given I am logged in
+    When I open "/welcome"
+    Then I see a link to my summaries
+    And I see a way to log out
+
+  Scenario: Logging out returns to the welcome page
+    Given I am logged in
+    When I log out
+    Then I am returned to "/welcome"
+
+  # /welcome is mounted outside the auth guard so it is reachable without a session;
+  # the root and all data routes stay behind it (commits around the WelcomePage work).

docs/use-cases/registration.feature

@@ -0,0 +1,45 @@
+Feature: Register and manage a multi-user account
+  As one of a handful of trusted users
+  I want my own account, isolated from everyone else's
+  So that Tapir can serve several people from one deployment without leaking data
+
+  # Stage 1 (ADR-012): Dex authenticates, Tapir authorizes per user. A Dex subject
+  # with no users row is a new user and must register before reaching any data.
+
+  Scenario: A new Dex subject is routed to registration
+    Given I am authenticated by Dex with a subject that has no Tapir account
+    When I open any page that requires an account
+    Then I am routed to the registration page
+    And no summaries are shown until I register
+
+  Scenario: Registering creates the account and its identity mapping
+    Given I am authenticated by Dex with a subject that has no Tapir account
+    When I complete registration
+    Then a user row is created for me
+    And a user_identities row maps my Dex subject to that user
+    And I am taken into the app as a registered user
+
+  Scenario: A returning subject passes straight through
+    Given I am authenticated by Dex with a subject that already has a Tapir account
+    When I open the app
+    Then I am not asked to register again
+    And I see my own summaries
+
+  Scenario: Deleting an account removes only my data and leaves other users untouched
+    Given I am a registered user with summaries, a connected account, and recorded actions
+    And another user exists with their own summaries
+    When I delete my account
+    Then all of my rows are removed across every user-owned table
+    And my stored secret references are removed
+    And the other user's data remains intact
+    And my Dex identity is left intact
+
+  Scenario: A deleted user can register again as a fresh account
+    Given I deleted my Tapir account but my Dex identity still exists
+    When I sign in again
+    Then I am routed to the registration page as a new user
+    And registering creates a fresh user row with none of my old data
+
+  # Isolation is DB-enforced (Postgres RLS, ADR-012, migration 003): a user can never
+  # read or write another user's rows even if an application WHERE clause is wrong.
+  # Deletion is Tapir-side only — the shared Dex directory is never modified (ADR-013).

docs/use-cases/summarize_mode.feature

@@ -0,0 +1,32 @@
+Feature: Choose how new videos get summarized
+  As a user who wants control over compute and noise
+  I want to pick whether new videos are summarized automatically or on demand
+  So that I only spend summarization on the videos I actually care about
+
+  Background:
+    Given I am a registered user with a connected video account
+
+  Scenario: Auto mode summarizes every new video
+    Given my summarization mode is "auto"
+    When a subscribed channel posts a new video with captions
+    Then Tapir summarizes it without my asking
+    And the summary appears in my list
+
+  Scenario: Manual mode is the default and leaves new videos unsummarized
+    Given I have not changed my summarization mode
+    Then my mode is "manual"
+    When a subscribed channel posts a new video with captions
+    Then the video appears in my list with no summary
+    And nothing is summarized until I request it
+
+  Scenario: Requesting a summary in manual mode queues it for the next run
+    Given my summarization mode is "manual"
+    And a new video is in my list with no summary
+    When I click "Summarize" on that video
+    Then the video is marked as requested
+    And the next run summarizes it
+    And the request flag is cleared after it is processed
+
+  # auto_summarize is a per-user setting and summarize_requested is a per-video queue
+  # flag (migration 006). The web button sets the flag; `tapir run` processes both the
+  # auto videos and the manually queued ones, then clears the flag.

internal/web/auth.go

@@ -1,6 +1,7 @@
-// Package web is the Stage-0 HTTP read/write surface (ADR-011, docs/ui-spec.md).
+// Package web is the multi-user HTTP read/write surface (ADR-012, docs/ui-spec.md).
 // It serves the summary reader over the existing store; the engine and ports are
-// untouched (ADR-003).
+// untouched (ADR-003). ADR-011 shipped this as a single-user Stage-0 reader; ADR-012
+// opened Stage 1 — multiple Dex-authenticated users with DB-enforced (RLS) isolation.
 //
 // This file defines the auth SEAM so the Dex session layer (internal/web/oidc)
 // and the page/handler layer can be built independently: handlers depend only on
@@ -10,9 +11,10 @@ package web
 
 import "net/http"
 
-// User is the authenticated principal. Subject is the Dex subject used for the
-// single-user allowlist (ADR-011); store operations key off the configured
-// tapir user_id (UUID), not this subject.
+// User is the authenticated principal. Subject is the Dex subject — the key for the
+// user_identities lookup (ADR-012) that resolves to a tapir user_id (UUID); store
+// operations scope every row by that id, not by this subject. A subject with no
+// users row is routed through the registration gate (see registration.go).
 type User struct {
 	Subject string
 	Email   string

internal/web/handlers.go

@@ -83,6 +83,7 @@ func (a *App) logger() *slog.Logger {
 func (a *App) Router() http.Handler {
 	root := http.NewServeMux()
 	root.HandleFunc("GET /healthz", a.handleHealthz)
+	root.HandleFunc("GET /welcome", a.handleWelcome)
 	root.Handle("GET /static/", staticHandler())
 	root.Handle("/auth/", a.Auth.Routes())
 
@@ -117,6 +118,15 @@ func (a *App) Router() http.Handler {
 	return root
 }
 
+// handleWelcome renders the public landing page (/welcome). It is mounted outside
+// Auth.Middleware, so it must not assume a session: CurrentUser peeks the cookie
+// without redirecting and the page renders the logged-out or logged-in variant
+// accordingly.
+func (a *App) handleWelcome(w http.ResponseWriter, r *http.Request) {
+	user, ok := a.Auth.CurrentUser(r)
+	a.render(w, r, WelcomePage(user, ok))
+}
+
 // handleHealthz is the unauthenticated liveness/readiness probe.
 func (a *App) handleHealthz(w http.ResponseWriter, _ *http.Request) {
 	w.Header().Set("Content-Type", "text/plain; charset=utf-8")

internal/web/oidc/oidc.go

@@ -161,11 +161,11 @@ func (d *DexAuth) Middleware(h http.Handler) http.Handler {
 		}
 		sid, ok := d.sessionID(r)
 		if !ok {
-			d.redirectToLogin(w, r)
+			d.redirectUnauthenticated(w, r)
 			return
 		}
 		if _, ok := d.sessions.get(sid, d.now()); !ok {
-			d.redirectToLogin(w, r)
+			d.redirectUnauthenticated(w, r)
 			return
 		}
 		d.sessions.refresh(sid, d.now().Add(d.sessionTTL)) // sliding refresh
@@ -266,7 +266,21 @@ func (d *DexAuth) handleLogout(w http.ResponseWriter, r *http.Request) {
 		d.sessions.delete(sid)
 	}
 	d.clearSessionCookie(w)
-	http.Redirect(w, r, loginPath, http.StatusFound)
+	// Land on the public landing page, not the login endpoint: a just-logged-out
+	// visitor should see /welcome, not be bounced straight back into a Dex login.
+	http.Redirect(w, r, "/welcome", http.StatusFound)
+}
+
+// redirectUnauthenticated sends an unauthenticated visitor somewhere useful: the
+// bare root goes to the public landing page (/welcome), any deeper guarded path
+// goes to login so the post-login round-trip can return them to it. isPublicPath
+// has already let /welcome and /auth/* through, so this never loops.
+func (d *DexAuth) redirectUnauthenticated(w http.ResponseWriter, r *http.Request) {
+	if r.URL.Path == "/" {
+		http.Redirect(w, r, "/welcome", http.StatusFound)
+		return
+	}
+	d.redirectToLogin(w, r)
 }
 
 func (d *DexAuth) redirectToLogin(w http.ResponseWriter, r *http.Request) {
@@ -305,5 +319,5 @@ func (d *DexAuth) clearSessionCookie(w http.ResponseWriter) {
 }
 
 func isPublicPath(p string) bool {
-	return p == "/healthz" || strings.HasPrefix(p, "/auth/")
+	return p == "/healthz" || p == "/welcome" || strings.HasPrefix(p, "/auth/")
 }

internal/web/oidc/oidc_test.go

@@ -248,9 +248,15 @@ func TestMiddlewareRedirectsUnauthenticated(t *testing.T) {
 		w.WriteHeader(http.StatusOK)
 	}))
 
+	// The bare root sends an unauthenticated visitor to the public landing page.
 	rec := httptest.NewRecorder()
 	guarded.ServeHTTP(rec, httptest.NewRequest(http.MethodGet, "/", nil))
+	require.Equal(t, http.StatusFound, rec.Code)
+	require.Equal(t, "/welcome", rec.Header().Get("Location"))
 
+	// A deeper guarded path goes to login so the post-login round-trip returns there.
+	rec = httptest.NewRecorder()
+	guarded.ServeHTTP(rec, httptest.NewRequest(http.MethodGet, "/v/some-id", nil))
 	require.Equal(t, http.StatusFound, rec.Code)
 	require.Equal(t, "/auth/login", rec.Header().Get("Location"))
 }
@@ -280,7 +286,7 @@ func TestMiddlewarePublicPathsBypassAuth(t *testing.T) {
 		w.WriteHeader(http.StatusOK)
 	}))
 
-	for _, path := range []string{"/healthz", "/auth/login"} {
+	for _, path := range []string{"/healthz", "/welcome", "/auth/login"} {
 		rec := httptest.NewRecorder()
 		guarded.ServeHTTP(rec, httptest.NewRequest(http.MethodGet, path, nil))
 		require.Equal(t, http.StatusOK, rec.Code, "expected %s to bypass auth", path)
@@ -298,6 +304,7 @@ func TestLogoutClearsSession(t *testing.T) {
 	auth.Routes().ServeHTTP(rec, req)
 
 	require.Equal(t, http.StatusFound, rec.Code)
+	require.Equal(t, "/welcome", rec.Header().Get("Location"), "logout lands on the public page")
 	cleared := sessionCookie(t, rec.Result())
 	require.Less(t, cleared.MaxAge, 0, "logout expires the cookie")
 

internal/web/view.go

@@ -266,6 +266,32 @@ var (
 	tapirFrameHTML3 = tapirFrameHTML("~")
 )
 
+// welcomeHeroHTML is the static Charm-box tapir mascot on the public landing
+// page — the same rounded purple box / pink tapir / mint accents as the spinner,
+// but a single still frame with a friendly tagline instead of the animation.
+// Built from the shared tapirLine helpers so the aesthetic stays in one place.
+func welcomeHeroHTML() string {
+	top := tapirSpan(CharmPurple, "╭"+strings.Repeat("─", tapirInteriorW)+"╮")
+	bottom := tapirSpan(CharmPurple, "╰"+strings.Repeat("─", tapirInteriorW)+"╯")
+	lines := []string{
+		top,
+		tapirLine(tapirRun{s: "  "}, tapirRun{s: "◆", color: CharmMint}, tapirRun{s: " "}, tapirRun{s: "tapir", color: CharmCream}),
+		tapirLine(),
+		tapirLine(tapirRun{s: "       "}, tapirRun{s: "▄▄▄▄▄", color: CharmPink}),
+		tapirLine(tapirRun{s: "     "}, tapirRun{s: "▄█▓▓▓▓█▄", color: CharmPink}, tapirRun{s: "   "}, tapirRun{s: "∩", color: CharmMint}),
+		tapirLine(tapirRun{s: "    "}, tapirRun{s: "█▓(", color: CharmPink}, tapirRun{s: " "}, tapirRun{s: "◕ ◕", color: CharmMint}, tapirRun{s: ")▓█", color: CharmPink}, tapirRun{s: "──┘", color: CharmMint}),
+		tapirLine(tapirRun{s: "     "}, tapirRun{s: "▀█▓▓▓▓█▀", color: CharmPink}),
+		tapirLine(tapirRun{s: "      "}, tapirRun{s: "██▄▄██", color: CharmPink}),
+		tapirLine(tapirRun{s: "     "}, tapirRun{s: "▀▀", color: CharmPink}, tapirRun{s: "  "}, tapirRun{s: "▀▀", color: CharmPink}),
+		tapirLine(),
+		tapirLine(tapirRun{s: "  "}, tapirRun{s: "watch less, know more", color: CharmMint}),
+		bottom,
+	}
+	return strings.Join(lines, "\n")
+}
+
+var welcomeHero = welcomeHeroHTML()
+
 // summarizeModeLabel names the current mode for display.
 func summarizeModeLabel(auto bool) string {
 	if auto {
@@ -573,6 +599,16 @@ main { max-width: 60rem; margin: 0 auto; padding: var(--s4) var(--s3); }
   .confirm-delete > summary:hover { background: #3a1714; }
 }
 
+/* public landing page (/welcome) — the Charm-box mascot hero plus the sign-in CTA */
+.welcome { text-align: center; padding: var(--s5) var(--s3); display: flex; flex-direction: column; align-items: center; gap: var(--s4); }
+.welcome-hero { background: #0d0d12; border-radius: 10px; padding: .9em 1.1em; display: inline-block; box-shadow: 0 2px 14px rgba(118, 83, 252, .25); }
+.welcome-hero pre { margin: 0; white-space: pre; font: .82rem/1.15 ui-monospace, SFMono-Regular, Menlo, "Cascadia Code", monospace; }
+.welcome-title { font-size: 1.9rem; line-height: 1.2; margin: 0; }
+.welcome-tagline { color: var(--muted); font-size: 1.05rem; line-height: 1.5; margin: 0; max-width: 32rem; }
+.welcome-cta { display: flex; gap: var(--s3); flex-wrap: wrap; justify-content: center; align-items: center; }
+.welcome-sub { color: var(--muted); font-size: .9rem; margin: 0; }
+.btn-lg { padding: .6rem 1.6rem; font-size: 1.05rem; }
+
 @media (max-width: 640px) {
   main { padding: var(--s3) var(--s2); }
   .filters { gap: var(--s2); }

internal/web/views.templ

@@ -31,6 +31,40 @@ templ Layout(title string) {
 	</html>
 }
 
+// WelcomePage is the public landing page (served at /welcome, outside the auth
+// guard — ADR-012). Logged out: the tapir mascot, a one-line tagline, and a
+// single "Get Started" CTA into the shared Dex flow (sign-in and sign-up are the
+// same URL). Logged in: a greeting plus links back into the app and to log out.
+templ WelcomePage(user User, loggedIn bool) {
+	@Layout("Tapir — Watch less, know more") {
+		<section class="welcome">
+			<div class="welcome-hero">
+				<pre aria-hidden="true">@templ.Raw(welcomeHero)</pre>
+			</div>
+			if loggedIn {
+				<h1 class="welcome-title">Welcome back</h1>
+				if user.Email != "" {
+					<p class="welcome-tagline">Signed in as { user.Email }.</p>
+				}
+				<div class="welcome-cta">
+					<a class="btn btn-lg" href="/">Go to my Tapir</a>
+					<a class="btn-secondary" href="/auth/logout">Log Out</a>
+				</div>
+			} else {
+				<h1 class="welcome-title">Watch less, know more</h1>
+				<p class="welcome-tagline">
+					Tapir summarizes the videos your subscriptions publish, so you can
+					skim the gist and decide what is worth your time.
+				</p>
+				<div class="welcome-cta">
+					<a class="btn btn-lg" href="/auth/login">Get Started</a>
+				</div>
+				<p class="welcome-sub">Already have an account? You'll go straight through.</p>
+			}
+		</section>
+	}
+}
+
 // flashBanner renders a one-shot notification for a flash code (connect success/
 // failure, disconnect, delete, registration). An empty or unknown code renders
 // nothing, so it is safe to drop into any page unconditionally. Reused across the

internal/web/welcome_test.go

@@ -0,0 +1,92 @@
+package web_test
+
+import (
+	"net/http"
+	"net/http/httptest"
+	"testing"
+
+	"github.com/stretchr/testify/require"
+
+	"gitea.d-ma.be/mathias/tapir/internal/web"
+)
+
+// fakeAuth is a configurable web.Auth for the landing-page tests: it reports a
+// fixed (user, ok) from CurrentUser and, when logged out, replicates DexAuth's
+// redirect split in Middleware — bare root → /welcome, deeper paths → login.
+// StubAuth can't express the logged-out case (it allows everything), so the
+// welcome routing needs this.
+type fakeAuth struct {
+	user web.User
+	ok   bool
+}
+
+func (f fakeAuth) CurrentUser(*http.Request) (web.User, bool) { return f.user, f.ok }
+func (f fakeAuth) Routes() http.Handler                       { return http.NewServeMux() }
+
+func (f fakeAuth) Middleware(h http.Handler) http.Handler {
+	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		if f.ok {
+			h.ServeHTTP(w, r)
+			return
+		}
+		if r.URL.Path == "/" {
+			http.Redirect(w, r, "/welcome", http.StatusFound)
+			return
+		}
+		http.Redirect(w, r, "/auth/login", http.StatusFound)
+	})
+}
+
+// appWithAuth builds an App with a given Auth but no store wiring — enough for
+// the /welcome page (which never touches the store) and the unauthenticated
+// redirect paths (which never reach a handler).
+func appWithAuth(auth web.Auth) *web.App {
+	return &web.App{Auth: auth}
+}
+
+func TestWelcomeLoggedOut(t *testing.T) {
+	app := appWithAuth(fakeAuth{ok: false})
+	rec := do(t, app, httptest.NewRequest(http.MethodGet, "/welcome", nil))
+
+	require.Equal(t, http.StatusOK, rec.Code)
+	html := body(t, rec)
+	require.Contains(t, html, "Get Started", "logged-out CTA present")
+	require.Contains(t, html, `href="/auth/login"`, "CTA links into the Dex flow")
+	require.NotContains(t, html, "Go to my Tapir", "no logged-in controls")
+}
+
+func TestWelcomeLoggedIn(t *testing.T) {
+	app := appWithAuth(fakeAuth{user: web.User{Subject: "s", Email: "me@d-ma.be"}, ok: true})
+	rec := do(t, app, httptest.NewRequest(http.MethodGet, "/welcome", nil))
+
+	require.Equal(t, http.StatusOK, rec.Code)
+	html := body(t, rec)
+	require.Contains(t, html, "Go to my Tapir", "logged-in CTA present")
+	require.Contains(t, html, `href="/"`, "links back into the app")
+	require.Contains(t, html, "me@d-ma.be", "greets by email")
+	require.NotContains(t, html, "Get Started", "no logged-out CTA")
+}
+
+func TestUnauthenticatedRootRedirectsToWelcome(t *testing.T) {
+	app := appWithAuth(fakeAuth{ok: false})
+	rec := do(t, app, httptest.NewRequest(http.MethodGet, "/", nil))
+
+	require.Equal(t, http.StatusFound, rec.Code)
+	require.Equal(t, "/welcome", rec.Header().Get("Location"))
+}
+
+func TestUnauthenticatedDeepLinkRedirectsToLogin(t *testing.T) {
+	app := appWithAuth(fakeAuth{ok: false})
+	rec := do(t, app, httptest.NewRequest(http.MethodGet, "/v/some-id", nil))
+
+	require.Equal(t, http.StatusFound, rec.Code)
+	require.Equal(t, "/auth/login", rec.Header().Get("Location"))
+}
+
+func TestAuthenticatedRootRendersList(t *testing.T) {
+	app := newApp(t)
+	resetDB(t, rawPool(t))
+	rec := do(t, app, httptest.NewRequest(http.MethodGet, "/", nil))
+	require.Equal(t, http.StatusOK, rec.Code)
+	require.Contains(t, body(t, rec), "<html", "authenticated root still renders the list page")
+}