v1.4.0 — progressive analysis: mode=summary|full + deferral

Stage 2 of the API-efficiency work: /api/analyze becomes progressive so clients can render the viewed pressing instantly and pay for the album survey only on real intent.

• mode=summary — ≤1 cold Discogs call: the viewed pressing's verdict + dossier; collection/wantlist aggregates consulted read-only (cold aggregates → null personalization, never a crawl); no survey. Live-measured: 0.82s cold, upstreamCalls: 1; warm repeats 0 calls
• mode=full (default — existing clients and MCP untouched) — the survey's candidate budget adapts to the remaining rate budget (16 normally, 6 when constrained); when even a reduced survey can't start safely the endpoint answers 202 {status:"deferred", retryAfter} immediately instead of grinding into a guaranteed 429
• meta on every analysis — level, cacheStatus, personalization, candidatesScored/Target, and upstreamCalls: real per-analysis Discogs-cost telemetry from here on

97 tests green. Deployed to the hosted instance. Pairs with ext-v0.4.0.

Full Changelog: v1.3.2...v1.4.0

v1.3.2 — rate-limit root-cause fixes

Stage 1 of the API-efficiency work. Live diagnostics reproduced the extension freezes: one cold analysis of a big album burned the entire 60/min Discogs budget and died with a 429 after ~19 seconds. Root causes fixed:

• One collection crawl per analysis — the collection was fetched twice concurrently per cold analysis (a third copy inside the survey); taste-fit now reuses the fetched aggregate, and withCache() gained in-isolate single-flight so simultaneous misses on any key share one fetch (also benefits all MCP tools)
• No more doomed 429 retries — the old backoff slept min(retryAfter, 2^attempt) seconds, so every retry landed inside the still-closed window; rate limits now fail fast and honestly (partial surveys, 429+retryAfter to clients)
• Preemptive budget gating — the client tracks X-Discogs-Ratelimit-Remaining and the survey stops launching candidate batches when the remaining budget can't cover them plus an 8-request reserve
• A rate-limited identity lookup now returns 429 + retryAfter instead of a misleading "invalid token" 401

Measured before/after (cold analysis of a 500+-version album): 429 error after 18.9s → complete result in 6.6s. Warm repeats ~0.2s, axis switches ~0.2s (zero Discogs calls) — now locked in by regression tests. 93 tests green.

Full Changelog: v1.3.1...v1.3.2

Discogs Copilot ext-v0.4.0 — progressive analysis

The panel now renders in two stages, so browsing Discogs never burns your rate budget on pages you immediately leave — and rate limits no longer blank the panel.

• Summary first — the viewed pressing's verdict appears near-instantly (≤1 Discogs call); the expensive best-pressing survey starts only after you stay on the release ~1.5s longer
• Cooldowns keep the panel alive — if the survey hits the rate budget, the verdict stays on screen with a countdown, an "Analyze best pressings" button, and one automatic retry when the cooldown ends; partial rankings say "scored X of Y candidates"
• Results survive browser restarts — full analyses persist for 24h (scoped to your server + account); when the live server is rate-limited, a saved result is shown labeled as such instead of an error
• New demo state: sidepanel.html?demo=deferred

Requires server v1.4.0 (live on the hosted instance). Update (load-unpacked): git pull → Reload (↻) in chrome://extensions — no re-auth needed.

Full Changelog: ext-v0.3.2...ext-v0.4.0

Discogs Copilot ext-v0.3.2 — cache scoping

Companion to server v1.3.2 (the rate-limit root-cause fixes — deploy/update that side first if self-hosting).

• Cached verdicts and the recently-analyzed trail are now cleared when the server URL or personal access token changes, so results can't leak across servers or accounts (sign-in/out already cleared them). A no-op Save in options keeps the warm cache.

Update (load-unpacked): git pull, then Reload (↻) in chrome://extensions — no re-auth needed.

Full Changelog: ext-v0.3.1...ext-v0.3.2

v1.3.1 — near-live shelf counts on /api/profile

Patch from live QA of the home screen: collection/wantlist counts on /api/profile came from the KV-cached aggregates (4 h TTL), so a recent wantlist change showed a stale total right next to the live Discogs page.

/api/profile now runs a tiny counts probe — a per_page=1 page of each list, reading only pagination.items — cached for 15 minutes. Cost: at most 2 Discogs calls per quarter-hour, only when the panel is opened; falls back to aggregate totals if the probe fails. Profile content (styles, labels, recently added) intentionally stays on the cached aggregates.

Deployed to the hosted instance.

Full Changelog: v1.3.0...v1.3.1

v1.3.0 — home-screen endpoints: /api/profile + /api/spin

Two REST endpoints powering the extension's new logged-in home screen (see ext-v0.3.0). Both are served from the KV-cached collection/wantlist aggregates — zero Discogs API calls once warm, so casual panel opens never touch the user's rate budget.

• GET /api/profile — the shelf as a profile: collection/wantlist sizes, added-this-month, dominant styles (top 5 with % shares), genres, decades, top labels, vinyl/CD/other format split, 5 most recently added, and the known-moods list
• GET /api/spin?mood= — "what to spin tonight": 1–3 rating-weighted picks from the user's own collection matching a mood, sampled from the strongest candidates so repeat calls vary; honest 422s for unknown moods or empty matches

No MCP-head changes. Deployed to the hosted instance.

Full Changelog: v1.2.0...v1.3.0

v1.2.0 — REST API accepts OAuth sign-in tokens + /api/whoami

The REST API head (used by the Discogs Copilot extension) now accepts Worker-issued OAuth access tokens alongside Discogs personal access tokens — the same /authorize → /token bridge MCP clients already use. This powers the extension's new Sign in with Discogs (see ext-v0.2.0).

• Bearer tokens shaped userId:grantId:secret are validated locally via the OAuth provider and resolve to the Discogs credentials stored encrypted in the grant — zero extra Discogs API calls
• Discogs personal access tokens keep working unchanged (self-hosters, curl)
• New GET /api/whoami → { username } — cheap authenticated identity probe
• /api/health remains unauthenticated
• Token policy: 1 h access tokens, 30 d rotating refresh tokens (provider defaults)

No MCP-head changes. Deployed to the hosted instance.

Full Changelog: v1.1.5...v1.2.0

Discogs Copilot ext-v0.3.1 — sign-out polish

Patch from live QA of ext-v0.3.0:

• App bar no longer claims "connected" after sign-out — the "● username · connected" line is now taken down whenever a signed-out view renders, and returns on the next home-screen load
• Pairs with server v1.3.1, which makes the home screen's collection/wantlist counts near-live (15-min freshness) instead of up to 4 h stale

Update (load-unpacked): git pull, then Reload (↻) the extension in chrome://extensions — no re-auth needed.

Full Changelog: ext-v0.3.0...ext-v0.3.1

Discogs Copilot ext-v0.3.0 — "Your shelf" home screen

The panel is no longer wasted on non-analyzable pages: signed in, you now get your shelf as an opinion — what your collection is, what changed, and what to play — instead of "nothing to analyze here".

What's new (top → bottom)

• ● username · connected in the app bar
• Your shelf — a one-line synthesized read ("Leans 1970s Contemporary Jazz · Blue Note heavy · 84% vinyl"), dominant-style bars, genre + decade lean, and collection / wantlist / added-this-month counts (first two link to Discogs)
• What to spin tonight — tap a mood chip (mellow, groovy, latenight, …) and get 1–3 picks from your own records, rating-weighted, each with a why; tap the same chip to re-roll
• Recently analyzed — your last 10 analyses with verdict-colored scores; click to reopen the release (re-analysis is instant from cache). Stored locally — Discogs has no history API, the extension is its own
• Recently added — the 5 newest arrivals on your shelf

Everything on the home screen is served from the server's cached collection aggregates — opening the panel costs zero Discogs API calls.

Install / update (load unpacked, Chrome 114+)

New install: clone the repo → chrome://extensions → Load unpacked → extension/.
Updating from ext-v0.2.0: git pull, then hit Reload (↻) on the extension — no re-auth needed.
Updating from ext-v0.1.0: remove + re-add (the extension ID changed in v0.2.0), then sign in.

Requires server v1.3.0 (already live on the hosted instance).

Next up

Toolbar badge on analyzable pages, first-run onboarding, Chrome Web Store submission — then the ranked wantlist/marketplace views epic.

Discogs Copilot ext-v0.2.0 — Sign in with Discogs

Sign in with Discogs replaces token-pasting as the extension's primary auth path. One click in the panel, approve on discogs.com, done — no more generating and copying personal access tokens.

Install (load unpacked, Chrome 114+)

1. Clone or download this repo and note the extension/ folder
2. chrome://extensions → enable Developer mode → Load unpacked → pick extension/
3. Open any Discogs release page, click the ◎ toolbar icon, hit Sign in with Discogs

Full instructions: extension/README.md

Updating from ext-v0.1.0 (load-unpacked installs)

This release pins the extension ID via a manifest key (needed for a stable OAuth redirect URL), which changes the extension's identity once: remove the old entry in chrome://extensions and Load unpacked again. Your pasted token from v0.1.0 lives under the old ID — just sign in with Discogs instead (or re-paste the token under options → Advanced).

Highlights

• One-click sign-in — the extension is a public OAuth 2.1 client (authorization code + PKCE) of the Worker, which bridges to Discogs OAuth 1.0a server-side. No Discogs consumer secret ships in the extension
• Your Discogs credentials never touch the device — they live server-side, encrypted inside the OAuth grant; the extension stores only revocable Worker-issued session tokens (sign out discards them; Discogs-side revocation under Settings → Applications)
• Transparent session refresh — hourly access tokens refresh automatically (30-day rolling session); expired sessions fall back to the setup screen, never a broken panel
• Personal access tokens still work — now under options → Advanced (self-hosters, development); options shows the connected username, and Test connection uses the new /api/whoami
• Requires server v1.2.0 (already live on the hosted instance)

Out of scope (next up)

Logged-in home screen (taste profile, recently analyzed, what-to-spin), toolbar badge, Chrome Web Store submission.