Spotify Phase 1 — build complete, real pull blocked on one creds step

I need a Spotify Developer app's client_id + client_secret — a 3-minute creation in your signed-in Chrome at developer.spotify.com. After that, the first run is one --bootstrap-oauth click (you tap Approve on Spotify's consent screen, my helper captures the callback) and every subsequent nightly pull runs unattended for years on the refresh token.

Your one action to unblock: when you give me /mcp confirm on chrome-devtools, I open developer.spotify.com directly in your real Chrome, create the app called “TP3 Spotify Pull”, set redirect to http://127.0.0.1:8765/callback, copy the two secrets into Apex's ~/spotify_history/.env, and fire tp3_spotify_pull.py --bootstrap-oauth. You click Approve once. Total elapsed: under five minutes from your “go.” Per the no-directions rule, that's the handoff — not a checklist for you to walk.

The spec called Phase 1 “the listening signal” — what landed in your ears, when, for how long. It's the cheap, ToS-clean, no-LLM-tokens dump that lets us see before we spend cycles on transcripts. Even with zero transcripts, the table answers immediately:

• “Which podcasts have I listened to most this quarter?” — SELECT * FROM spotify_top_shows_90d. One query, instant.
• “Which artist do I keep coming back to lately?” — SELECT * FROM spotify_top_artists_90d.
• “What did I play before bed last Tuesday?” — filter played_at between two timestamps, group by hour.
• “Episode I half-remember from a long drive” — text search on name and show_name over a date window.

None of these need Phase 2. They drop out of Phase 1 the moment the JSON lands.

Music side

• Top artists by minutes listened, last 90 days. Expect a 5-10 artist long-tail you didn't realize was that heavy. NLW playlists + the Chattanooga bus mix probably surface unexpectedly.
• Track-vs-skip ratio. Spotify's played_at is when the play started, so very short windows between consecutive plays are skip evidence. Useful for “what I think I like vs what I actually finish.”
• Discovery rate. New artist (no plays in prior 90 days) added per week. Tracks how restless / settled your music taste is right now.
• Time-of-day clustering. Mornings (the Tasker brief), drive time, evening wind-down — different listening shapes. Worth seeing if any pattern surprises.
• Context source. context_uri tells us playlist vs album vs artist-radio vs solo-track. A heavy Spotify-curated lean would change how we think about your discovery loop.

Podcast side (the actual long-arc payoff)

• Top shows by minutes listened. The headline. Expect NLW's AI Daily Brief, Matt Wolfe, Lex, Hard Fork, Acquired in the top-5 — Phase 1 finally proves it instead of guessing. (Personal/everyday AI focus, not enterprise — per the May-12 rule.)
• Listening completeness. Duration listened vs episode duration. Half-finished episodes are a different signal than “I love this show” plays.
• Topical clustering. Without transcripts yet, episode titles alone cluster reasonably: “Claude,” “Anthropic,” “Llama,” “robotics,” “model release” — quick LIKE grouping over name surfaces which AI topics dominated your week. (Claude / Anthropic / Claude-Code lane stays first-class per the May-19 brief rule.)
• Cross-post candidates for Phase 2. Each podcast episode becomes input to the YouTube matcher in Phase 2 (on your green-light, post-Saturday RAM install). Phase 1 builds the worklist.
• The “I should have listened” gap. Episodes saved-but-never-played, surfaced by joining /me/shows against actual plays. Brief could nudge them on slow weeks.

Cross-cutting

• Total minutes per day. Baseline for how big a slice of your input bandwidth Spotify owns. If it's bigger than email or SMS, the morning brief probably needs to treat podcasts as a first-class lane alongside Boys SMS, Yahoo, Gmail.
• Quiet days vs heavy days. Loosely correlates with travel days, school events (Chattanooga, DC trips), build sprints. A few weeks of data + a calendar join would expose patterns the brief should know.

• No real numbers. Awaiting credentials. The shape is documented so the first real pull drops straight into this same report with values populated.
• No transcripts, no semantic search. That's Phase 2, on your green-light, post-Saturday hardware upgrade. Phase 1 is signal-only.
• No Spotify-private-export historical backfill. The spec calls for triggering Spotify's “Download your data” request from your Chrome session (5-30 day async wait). Easy to fire when you wake; not blocking Phase 1's recent-window pull.
• No nightly cron yet. Spec says cron at ~3 AM ET. I'll wire it after the first successful manual pull verifies the pipe end-to-end. Adding a cron entry that fails-loud against a broken pipeline is anti-pattern.

1. Confirm chrome-devtools MCP is alive (/mcp if needed). I drive the rest.
2. I open developer.spotify.com in your real Chrome, create the app, paste secrets into Apex .env, fire --bootstrap-oauth. You click Approve once. Done.
3. First pull runs immediately. Report regenerates with real numbers in the next morning brief.
4. If you'd rather hold this until after the 5/23 hardware install: nothing breaks. Code sits ready, table sits empty, no nightly cron until you say go.