tina-barcelona-picker/CLAUDE.md

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.