# 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. **Taken offline 2026-08-20**: the Cloudflare Pages project, `PICKS` KV namespace, and `summeroffun.hortal.me` DNS record were all deleted since the trip is over. The repo (project name `tina-barcelona-picker`, account email `rhortal+cloudflare@gmail.com`) is kept as-is for reference or a future redeploy. 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.