delivery-forensicslisted

# Delivery forensics Four sources. Each answers something the others cannot. Use the DB for *outcomes*, GitHub for *causes*, the runner for *liveness*, KB/CBM for *why the code is shaped that way*. ## 1. Prod DB — the only place outcomes live **Direct `psql` to Neon times out from a laptop** (5432 is not reachable; the sandbox is not the problem — `dangerouslyDisableSandbox` fails identically). Go over the neon HTTP driver instead, which is what the app itself uses. ```bash S=<scratchpad> grep -m1 '^DATABASE_URL=' apps/web/.env.local | sed 's/^DATABASE_URL=//; s/^"//; s/"$//' > $S/dburl bun .claude/skills/delivery-forensics/scripts/q.ts $S/dburl $S/queries.sql ``` `apps/web/.env.local` is **live prod**. The repo-root `.env` is a stale Feb-era branch — never analyse from it. `vercel env pull` returns no `DATABASE_URL`. `q.ts` splits on `;\n`, prints one TSV block per statement, and prints `ERR <msg>` instead of aborting, so a whole batch survives one bad column name. ### Which column answers which question | Question | Where | |---|---| | Did the PR merge, and when | `workers.merged_at`, `workers.pr_lifecycle_status` (`merged`/`closed`/`ci_running`/`pr_open`/`unresolvable`) | | How many times CI went red on it | `workers.pr_check_failure_count` | | Was it a conflict | `workers.conflict_detected_at`, `workers.pr_unresolvable_reason` | | Was this task remediation or real work | `tasks.task_class` ∈ `work` / `attempt` / `bookkeeping` | | Which remediation kind, and for wh