parked_sketch_ebay_deal_watcher_mac_studio_2026-06-13

DARE.CO.UK · PARKED SKETCH · 2026-06-14

Mirrored from ~/.claude/.../memory/parked_sketch_ebay_deal_watcher_mac_studio_2026-06-13.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

“PARKED SKETCH (build tmrw, 2026-06-14) — eBay deal-watcher Cloudflare Worker that polls for Mac Studio listings every 30 min, dedups/price-tracks in KV, notifies on good deals. Dan handed the wrangler.toml; concept + open questions captured. Not built yet.”

Dan, 2026-06-13, mid-Amazon-rebuild: handed a wrangler.toml for an eBay “Mac Studio look-up” deal-watcher and said “park/sketch for tmrw”. NOT built — this is the seed to resume from on 2026-06-14.

Surface home (Dan, 2026-06-13 FYI)

Lives under https://agent.gf.cx/ — surface/codename ebay-sniffer. i.e. agent.gf.cx is the umbrella “agent” surface; ebay-sniffer is the first agent on it (deal-watcher Worker is its engine). Future agents can hang off the same agent.gf.cx surface.

The idea

A Cloudflare Worker (deal-watcher) on a 30-min cron that hits the eBay API for a saved search (first target: Mac Studio), keeps per-listing state in KV, and fires a notification when a good deal appears (new listing under a price threshold / below rolling median / Buy-It-Now bargain). Generalises to any saved search — Mac Studio is just the first source.

wrangler.toml Dan handed (verbatim — the starting scaffold)

STASH4

Shape to build (deal-watcher.js)

• scheduled() handler: for each watched search → call eBay → diff vs KV → notify on fresh good deals → write back state.
• KV DEALS binding: key per listing id (or per-search rolling stats); store seen-set + last price so we only alert on NEW or PRICE-DROPPED items, not every poll. TTL old keys so KV doesn’t grow unbounded.
• Notify via the portfolio messaging-as-a-service pattern — a contextual ONE-LINER (e.g. “Mac Studio M2 Max 32GB BIN £950, £180 under 30-day median”) through ~/bin/notify.py (notify_verdict), NOT raw curl. See [[feedback_reporting_pattern_messaging_as_a_service_2026-06-13]]. A Worker can’t call notify.py directly → either POST to a small endpoint that does, or hit the Pushover API from the Worker and mirror the status JSON to status.gf.cx like the other surfaces.
• Optional: emit a normalised status card to status.gf.cx/data (register in registry.json) so the watcher self-reports freshness/last-deal.

STARTER CODE ALREADY EXISTS (Dan handed ebay-sniffer.zip, 2026-06-13)

A prior Claude chat produced a near-complete Worker — staged at ~/Code/agent.gf.cx/ebay-sniffer/ (deal-watcher.js + wrangler.toml). Build tomorrow STARTS FROM THIS, not from scratch. What it already does well: - Full Browse API: client-credentials OAuth token cached in KV w/ TTL; item_summary/search with server-side price:[..max]+FIXED_PRICE filter, sort:price; spec-match (require/exclude title regex + maxPrice) in code. - WANTS array (first entry = Mac Studio M1 Max 32/1TB ≤$900; commented M4 mini template). Dedup via KV seen:${itemId} 30d TTL → alert-once. Hits ledger (hits, cap 50) + self-hosted dashboard at / + manual /run trigger. - Notify via Resend (email) + sms.to (SMS), both optional via env.

Deltas to close before it’s “ours” (do tomorrow)

1. eBay creds = the blocker (unchanged): needs production keyset EBAY_CLIENT_ID/EBAY_CLIENT_SECRET as Worker secrets → register eBay dev app, stash in 1P (Dan-run write). Almost certainly doesn’t exist yet.
2. Notifications: swap/augment Resend+sms.to → the portfolio notify.py one-liner (Pushover ships). Worker is edge → can’t shell notify.py; add a Pushover branch in notify() OR POST to a tiny notify endpoint. (Resend MCP IS connected, so email path is viable too — but the standard is the sentence.)
3. Marketplace hardcoded EBAY_US — Dan is UK (.co.uk); switch to EBAY_GB or query both (the EBAY object’s marketplace + the X-EBAY-C-MARKETPLACE-ID header).
4. No status.gf.cx card — Worker self-hosts a dashboard instead of emitting the normalised status JSON + registry.json the other surfaces do. Add it.
5. Domain: deploys as bare deal-watcher Worker → add the agent.gf.cx route (ebay-sniffer is its first agent).
6. REPLACE_WITH_KV_ID → wrangler kv namespace create DEALS.
7. Price = fixed ceiling (fine MVP); rolling-median-in-KV is the v2.

Open questions to resolve first (2026-06-14)

1. eBay API + creds. Need the Browse API (Buy) item_summary/search (keyword + price filter + buyingOptions), which needs an eBay developer App ID + OAuth application token (client-credentials, not the user token). The existing eBay evidence work used Fastmail/Gmail mailboxes, NOT the eBay API — so there may be NO eBay dev app yet. Check 1P “Code Shared” for an eBay app/client-id; if absent, register a dev app + stash App ID/Cert ID in 1P (Dan-run write per the 1P-SA-token rule).
2. Price-threshold logic: fixed ceiling vs rolling median in KV. Rolling is nicer (self-calibrating) but needs a few polls to warm up.
3. Search params for “Mac Studio” (model/RAM/SSD variants → maybe several watched queries, or one broad query + client-side filter).
4. Where notify.py lives relative to the Worker (Worker is edge → can’t shell out; pick the POST-endpoint or direct-Pushover path above).

Surface baseline reminder

If this becomes a real surface with any HTML face, it owes the three-layer floor (inline link promotion + rollover thumb + social card) per ~/.claude/CLAUDE.md. A headless cron Worker with only a status card may be exempt, but flag it when scaffolding.