Peak Checklist — about & roadmap

Personal climbing log built on Supabase + a single static HTML page. This page is the living picture of how it works, what's left, and what we've intentionally deferred.

The vision

One place to see every Colorado peak (plus a few other lists I care about), what I've climbed, and what's left. Cross-device (Mac + iPhone), no native app, no backend of my own to babysit. Data lives in Supabase; the page is plain HTML loaded over HTTPS.

Runtime data flow

The publishable key is safe to publish — RLS is the actual gate (rows are scoped to my email).

Deployment — today

Deployment — proposed end-state

Green dashed = still proposed. Currently I deploy with wrangler pages deploy dist; the end-state replaces that with git-push-to-deploy.

Testing strategy

Tier 1 (active): node --test tests/predicates.test.js exercises row-visibility, ranking, and filter-label tables in <1s. Same source runs in both the browser and the test runner.

What's left for the initial vision

• Phase 3 — Add Climbs view done Modal → Supabase insert → row appears after refresh, verified end-to-end.
• Phase 4 — Manage Climbs done "My Climbs" tab — ascents grouped by day with sub-header showing the climb name (or highest peak as a fallback). Each day card has a pencil that opens an Edit Climb modal: rename the climb, edit any ascent (date / precision / note / finisher), delete one or more, save in one batch. Swap-peak deferred (rare; use delete + re-add).
• Phase 6 — Enrich non-CO peaks via Lists of John Other-list peaks currently lack the per-peak metadata CO peaks have (range, parent, prominence). Scrape + canonicalize them the same way.
• Phase 9 — L48 14ers list done New filter and stat card for every 14er in the Lower 48 (CO + CA + WA, 75 peaks today including 5 named-but-unranked CO peaks and any unranked CA peaks). Existing CO-only labels renamed: "All 14ers" → "All CO 14ers", "Ranked 14ers" → "Ranked CO 14ers". A separate position_14er_l48 ordinal drives the rank column. AK/HI excluded by design.
• Phase 7 — New-peak catch-all flow done Log Climb modal has a + New Peak button → sub-modal with name + elevation (required), state, range, and a ranked toggle (default on). New peak is assigned a synthetic negative id, auto-added to the Other Peaks catch-all (other_ranked), and immediately selected as a chip in the current log. The Other Peaks stat shows a raw count only (no percentage — the catch-all is, by definition, fully climbed). Orphan cleanup: if an Edit Climb delete would drop the last ascent of an other_ranked-only peak, a confirm prompt warns the peak itself will also be removed from the DB (cascade clears its peak_lists row) — so the Other Peaks list never accumulates uncimbed entries.

Deferred improvements

Things considered and intentionally not built — captured so the reasoning isn't lost.

• Tier 2 testing — Playwright headless smoke test. Loads the deployed URL with a saved storageState.json for Supabase auth (gitignored, refreshed when JWT rotates). Asserts page loads, no console errors, PEAKS populates, each filter toggle changes result-count. Add when Tier 1 stops feeling sufficient — likely when Phase 4 edit/delete lands.
• Tier 3 testing — rendered-table snapshots (Playwright). Captures table HTML per list filter, diffs against committed snapshots. Catches subtle ordering/membership regressions. Defer until a silent regression bites.
• CI deploy on git-push. Today: manual wrangler pages deploy dist. End-state: push to a git remote, CI does the deploy. Not worth the wiring overhead until I'm pushing more than once a week.
• Stack rewrite (Node / React / Remix / etc.). Considered, declined. The whole app is ~1,100 lines of vanilla JS plus a Python build step — readable in one sitting, no framework churn, no toolchain to maintain. A framework would buy nothing the current shape doesn't already have.
• Mobile-native client. Not happening — iPhone Safari on the live URL is good enough and avoids App Store overhead.
• Proper climbs table. Today, climb name lives as a denormalized climb_name column on ascents (every row in a day-group carries the same value). A first-class climbs table would let one trip own metadata (name, dates, notes, photos) and many ascent rows reference it — cleaner if a single trip ever spans multiple days, or if I want trip-level fields beyond the name. Not worth the migration yet; revisit if multi-day trips become a common shape.

Where things live

• build_prototype.py — HTML template + Python injection (Supabase URL/key, predicates)
• lib/predicates.js — pure row-visibility / ranking logic (single source of truth)
• tests/predicates.test.js — Tier 1 unit tests
• seed.py — idempotent push of canonical data into Supabase
• ARCHITECTURE.md, CONTEXT.md — long-form project state for future sessions