Audit everything a migration touches
Finds every service, saved query and cron that touches the table, across PlanetScale, Supabase and your repos, before the migration runs.
I want to do this: We're renaming the orders table tonight. Which services, queries, and crons touch it? ## Setup (skip if Polylane is already set up) Read and follow https://polylane.com/auth.md for non-interactive signup and setup. Start by checking whether I am already signed in; reuse my account and workspace. If the CLI is missing, bootstrap it without starting the interactive wizard: curl -fsSL 'https://polylane.com/setup?ref=prompts' | bash -s -- --install-only Then follow the guide through email verification, workspace selection, source connections, and MCP authentication. Ask me for an email code or OAuth consent only when needed. Verify each step; report pending setup instead of claiming success from installation alone. ## How to work Over MCP: searchTools lists what this workspace exposes, with each tool's schema; call it first. runTool runs one tool, runCode chains several in one call and returns just the answer. search and execute cover the full Polylane REST API: threads, issues, investigations, autofixes, memories. From the terminal: the polylane CLI wraps the same API, with structured output and non-interactive flags everywhere. Reads always work. Write tools appear only if I have opted in, and every write is screened. ## Task: Audit everything a migration touches Steps: 1. Search the connected repos for every reference to the table 2. Walk the context graph for services and jobs attached to the database 3. Check scheduled jobs and workers whose queries touch it 4. List recent changes around the database for anything in flight 5. Deliver the audit: every consumer, ranked by traffic, with the references cited Ground every claim in data you actually pulled: the query, the log line, the change record. If the data is inconclusive, say so. Ask me before anything that writes.
The migration is one line. The audit is the weekend.
Renaming a table is easy. Finding every consumer of it isn't: code search misses the query built by string concatenation, and nobody remembers the cron from 2024.
- Grepping three repos and still missing the analytics job
- The forgotten cron that breaks at 3am after the migration
- The consumer nobody remembered until it broke
One prompt, this much work. Every step on your real data.
- 1 Search the connected repos for every reference to the table
- 2 Walk the context graph for services and jobs attached to the database
- 3 Check scheduled jobs and workers whose queries touch it
- 4 List recent changes around the database for anything in flight
- 5 Deliver the audit: every consumer, ranked by traffic, with the references cited
Migrate with the full consumer list
Every touchpoint on one page before you run the migration, including the ones code search alone would miss. The 3am surprise gets found at 3pm.
Review the risky one 
“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” Blast radius 
“If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic.” Audit the weekend 
“List every deploy since Friday and flag the ones whose metrics moved afterwards.” Honest release notes “Write release notes for this week's deploys, including what regressed and what got fixed.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”
“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” Blast radius “If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic.” Audit the weekend “List every deploy since Friday and flag the ones whose metrics moved afterwards.” Honest release notes “Write release notes for this week's deploys, including what regressed and what got fixed.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”