Initial commit: Tina Barcelona trip picker

Static Cloudflare Pages site + KV-backed Pages Function for jointly
planning Tina's Barcelona visit (7 Jul - 18 Aug 2026). List and calendar
views share one client state; dated evening events are radio groups to
prevent double-booking, multi-night shows live once in TRIP_DATA.spanning
instead of being duplicated per day, and undated collections get
optionally date-tagged when picked from the calendar view.

Includes a client-side-only password gate and an instructions page.
Live at https://summeroffun.hortal.me.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -0,0 +1,23 @@
+# CLAUDE.md — tina-barcelona-picker
+
+A standalone side project, not part of the Cerebro vault. Static site + one Cloudflare Pages Function + one KV namespace, entirely on Cloudflare's free tier. **Already deployed and live** at https://summeroffun.hortal.me (project name `tina-barcelona-picker`, account email `rhortal+cloudflare@gmail.com`). See README.md for architecture, deploy steps, and free-tier limits — read it before making structural changes.
+
+## What this is
+
+A picker page for planning Tina's Barcelona visit (7 Jul – 18 Aug 2026): dated events (concerts, festival nights, Jazz at La Pedrera) as radio-button groups so only one pick per evening is possible, plus undated checkbox categories (exhibitions, dinner, daytime activities). Two views — a flat list and a day-by-day calendar — render from the same `TRIP_DATA` and share the same client state, so a pick made in one view is correctly reflected in the other. Selections save to KV via the Pages Function and reload on any device that opens the link.
+
+## Working on this project
+
+- All trip content lives in `public/data.js` — a plain JS object (`TRIP_DATA`), no build step. Edit it directly; nothing else needs to change for content updates.
+- Keep `app.js` framework-free (vanilla JS, no bundler). This is a two-person planning tool, not a product — resist adding a framework, state library, or build pipeline for it.
+- The collision-avoidance mechanism is structural: each dated group is a single `name` on a set of radio inputs. Don't replace this with client-side "conflict warnings" bolted onto checkboxes — the radio-group approach is simpler and can't drift out of sync.
+- **Never duplicate a multi-night show across several `days[].options` entries.** That was tried once (Grec's Ricardo III and FACTORY each existed as two near-identical option objects, one per night) and it was a real bug, not just untidy — fixed by moving both into `TRIP_DATA.spanning`, which `app.js` renders onto every valid date automatically. If you're tempted to copy-paste an option into a second day, it almost certainly belongs in `spanning` instead.
+- The "already picked on a different date" status row (used for both `spanning` items and calendar-view collection items) is rendered by the shared `statusRow()` helper in `app.js` — reuse it rather than inventing a second disabled-row style.
+- No real auth by design — a client-side-only password gate (see README "Known limitations"). The password lives in `GATE_PASSWORD` in `public/app.js`, in plain sight, on purpose. Don't add real login/accounts unless explicitly asked.
+- Test locally with `wrangler pages dev public --kv PICKS` (uses a local file-backed KV, no Cloudflare account needed) before suggesting a deploy. Note the explicit `--kv PICKS` flag — without it, Pages dev won't bind the namespace locally and every API call 500s.
+- The project is live and the account is already authenticated in this environment (`~/.wrangler/config/default.toml` has a valid OAuth token as of the initial deploy). Re-deploying with `wrangler pages deploy public --project-name=tina-barcelona-picker` after a content or code change is fine to run when the user asks for it, or after a batch of edits they'll clearly want live — it's a low-risk, instantly-reversible static deploy. Still don't run `wrangler login`, create/delete Pages projects, or touch DNS/custom-domain settings without being asked; those are the actions worth checking in about.
+- **Wrangler cannot manage DNS.** There's no `wrangler pages domain` command, and the OAuth token from `wrangler login` is scoped `zone:read` only (confirmed by testing — both reading and writing zone DNS records return "Authentication error"). Registering a custom domain on the Pages project via the API is fine with this token (`pages:write` covers it), but the actual CNAME record has to be added through the Cloudflare dashboard, or by asking the user for a separately-scoped API token with `Zone:DNS:Edit`.
+
+## Source of truth
+
+The activity/date data originated from research done in the parent Cerebro vault (`cerebro-personal/Travel/Tina Barcelona July 2026.md`). If that note gets updated later with new events, dates, or venues, this project's `public/data.js` may need a matching update — but this project does not read from the vault at runtime; the data was copied in once and lives here independently.