What runs on its own — the background worker does the routine work without any buttons. Every 15 minutes: expiry + bad-title quarantine, process queue (300 raw items), report rollup, enhance (20 gap-fills + 20 stale price re-verifies), poll inbox, visitor flush. Every hour: the full collect (all source types, page sources at their depth), trending, hunt cycle + open requests, check links (100). Buttons exist to do MORE of something RIGHT NOW — plus the true one-offs that never run by themselves: crawl-site's one-shot URL mode, repair, and re-judge rejected. Each edge on the rail carries its cadence, and while the worker is mid-pass a dashed 🛠 worker chip in the jobs strip says exactly what it is doing ("process queue (up to 300 raw items)…"), with its elapsed clock — the automatic worker is no longer invisible.

The pipeline has four stages — ingestion → extraction → hunters → feed — and every button here is a plain /api/admin/* endpoint (an admin bearer token, or a true local ops call, works from curl the same way). The workflow rail at the top IS the pipeline: each node is a data store (click it to browse that data below, with live counts on the node), and each operation sits on the arrow between the data it transforms. Refresh reloads whichever tab you're on; Collect now in the page header is the same full sweep as the Map's Sources button.

Collect now — POST /api/admin/collect. The stage-1 sweep, sliceable by source type: the operation detail offers a tick-list — rss/json feeds · web pages (page sources at their configured depth + site scrapers) · promo inbox · affiliate catalogs · trending signals · hunt cycle — everything ticked (the default) is the full seven-phase sweep, identical to the worker's hourly run, so it can take a minute or more. Every source logs a CollectorRun — that's the "runs · 24h" number. New feeds are added right on the Sources panel (name + URL — the ＋ Add source form); the per-row Test button fetches one source immediately, disabled or not, so a fresh feed proves itself before the next collect; ▶ Run processes that one source as a background job instead — progress in the strip, cancellable, the right tool when a page source crawls deep. Kind web page takes ANY page with product links — Amazon Best Sellers, a store's sale page, a gift guide: the sweep discovers product-shaped links (/dp/, /product/, /item/…), queues each as a raw item (kind page, with the anchor title, source listing and position as original content), and reads each product's own page for the real price — listing-tile prices are never taken, so the Amazon distrust rule holds. Give a page source a depth (0–3) and every hourly collect crawls that many clicks deep from its URL.

Crawl site — in the Jobs picker ("open an operation…"); the rail's Collect covers web-page sources via its tick-list. Started as-is (Root URL left empty) it crawls every enabled web-page source at its own configured depth — your registry is the instruction. Give a Root URL instead for a one-shot crawl of any site, registered or not: root URL + depth in, all the products the site shows within N clicks out. The crawler reads sitemap.xml first (Shopify-style stores list every product there — the whole catalog for two fetches), then walks same-site listing links breadth-first; a page at max depth is harvested but not expanded. One fetch budget (default 40 pages, max 100) bounds the whole crawl so a broad site can't fan out forever; product caps at 300 per crawl. Every discovered link becomes a raw item (kind page) and is extracted from its own product page in chunks of 10 — cancel between pages or chunks keeps everything already done. Runs log as crawl:<host> in Collector runs. Be polite: crawl sites whose robots.txt allows it. Since 2026-08-09 the rule is show all products — the affiliate-only door ships OFF (monetization happens at click-out where we can); US-only stays on. After flipping the rule on a running site, the re-judge rejected job gives everything the old rule turned away a fresh verdict.

Poll inbox — POST /api/admin/poll-inbox, now in the Jobs picker (the rail's Collect covers email via its tick-list; the standalone operation is where the Re-read last N seen mails parameter lives). Fetches unseen mail from the ingest mailbox (BAB_INBOX_*), unwraps tracker links, extracts each product and posts it on the forwarder's profile, recording a raw item per link with its outcome. Unconfigured inbox → reported, not an error.

Trending sweep — POST /api/admin/trending, in the Jobs picker (or tick "trending signals" on Collect). Just the signal pass (Amazon Best Sellers/Movers ranks, Reddit buzz, Google Trends). Lays trend_score onto existing products — never creates one — and the score decays after 72 h (BAB_TREND_TTL_HOURS). Feeds the TrendSpotter hunter.

Process queue — POST /api/admin/pipeline/process?limit=50. Stage 2 on demand: claims queued raw items oldest-first and runs each through the doors (monetizable? US storefront? real title? discount rule), the extractor agents, and the believability gates into the catalog. Each attempt is logged as an ExtractionRun. Items end extracted, rejected (always with a status_note saying why), or failed (worth a look).

⟳ Re-run (per row, Pipeline tab) — POST /api/admin/pipeline/reprocess. Re-runs extraction from the item's stored payload — the "we fixed the extractor, run those again" button. Payloads are kept forever precisely so this is always possible.

#id anywhere opens the raw-item inspector: the payload exactly as received, every extraction attempt, and the deal it became. Every write path lands here now — RSS/scrapers queue first, affiliates and trending are tapped on acceptance, emails and member posts always were.

Original content — both the list column and the inspector show what the source actually said, not just the link. An email item carries its sender, subject and a body excerpt (rendered as "Original email" in the inspector); a trending item carries the signal that put it on the radar ("amazon-movers electronics #3", "reddit r/buildapcsales 412 points") as "Original signal". The full stored payload sits below, exactly as received.

Every polled mail leaves a row — one message-level raw item (kind email, no URL) per mail, carrying the original content and the verdict: "2 of 14 links became products", "sender not recognised", "DKIM/SPF failed", "no product links found". Mails from non-members keep only sender + subject + the why, never the body. If you see no email raw items at all, no mail has been imported since this deploy — polling reads UNSEEN mail only, so use Poll inbox's "Re-read last N" parameter to pull already-opened messages back through.

Enhance now — POST /api/admin/enhance?limit=60. The gap-filler: picks the worst rows missing a photo or price (per-host caps, exponential backoff — a blocked retailer costs one request a day) and re-reads their pages to fill only the blanks. Distinct from the worker's automatic re-verify pass, which re-reads the longest-unchecked prices even when nothing is missing — because a wrong price is a row with nothing missing.

The Extraction tab's failed only toggle filters the audit trail; "Price confirmed" means two witnesses (the model and a deterministic layer) — only confirmed prices wear a "Price checked" claim on the site. Vision rescues are rendered-page re-reads for pages that resisted the cheap fetch.

Check links — POST /api/admin/check-links?limit=200. Visits live products' URLs and expires the ones that are genuinely gone (404/410). Deliberately conservative: bot walls and timeouts count as "unknown" and the row is left alone. Since 2026-08-10 it also runs automatically once an hour (100 links per cycle, BAB_CHECKLINKS_PER_CYCLE, 0 = off) — a dead link leaves the site within a day on its own; the button is for a bigger sweep right now.

The Products tab browses the whole catalog — every status, expired and hidden included, which the public search never shows. Search uses the site's own engine (FULLTEXT on MySQL). Open any #id for the full record: all stored fields, engagement counts, provenance (the raw item it came from, payload and all), the extraction audit, the posts carrying it, and the manual-correction history.

✎ Correct values (in the product inspector) — PATCH /api/admin/deals/{id}. Send only what you change; clearing a clearable field (was-price, rating, review count, expiry) removes the value. Three rules keep hand-fixes trustworthy: a corrected price counts as human-verified (price_source=human, stamped, attributed); the number still passes the same sane_prices/sane_rating gates as any scrape — whatever a gate adjusts is reported back, never silent; and every change lands in the admin_edits audit (who, field, old → new).

On the Overview tab, 🛠 Repair — check first is two clicks on purpose: the first is a dry run that reports what it would change; the second applies it and re-reads ~120 product pages. One-click destructive repair is the kind of button you press once by accident.

Run hunt now — POST /api/admin/hunt. Stage 3 alone, without the full collect: every ADK persona runs its hunt procedure and decides what to post (hunt_runs records each pass), then open product requests are answered. "last cycle: fallback" means the deterministic template pass posted — normal when GOOGLE_API_KEY isn't set in that environment; with the key you'll see adk. The feed never goes quiet either way.

Hiding a post (product inspector or POST /api/admin/posts/{id}/hide) is reversible — the row and the hunter's claim on the deal are kept, so unhiding restores it exactly and the deal is never re-posted meanwhile.

Refresh reports — POST /api/admin/reports/rollup?days=14. Recomputes the daily_metrics rollup idempotently; the Reports charts and the Map's 7-day summaries read only that table. The worker keeps today + yesterday fresh every 15 minutes — this button is for backfilling history or after manual data changes.

Reading the numbers: views count signed-in readers opening product pages; clicks count everyone clicking out — so CTR can exceed 100% when most traffic is anonymous. visitors today is unique (day, ip) aggregates, not raw hits. The "Recent engagement" panel shows the raw events, each one click from its product.

Raw item statuses: new (queued) → extracting → extracted / rejected (turned away, with the why) / failed (error — retry-worthy). price_source: page = read off the retailer's page with two witnesses; human = a person typed it while looking at the page (members and admin corrections); feed/catalog = aggregator headline or affiliate export — shown but never wearing a discount ribbon; blank = predates tracking. Only page and human count as verified. Every stage has a browser: Sources (feed switchboard + every collector run), Pipeline (raw items, searchable), Extraction (the audit, filterable by confirmation/vision), Products (whole catalog + per-row hide/refetch), Posts (stage 3's output + hunt cycles by hunter/mode/outcome), Reports (metrics + raw events by kind). Every operation's exact table reads/writes is in the developer playbook: docs/backend-redesign.md §10 + the interactive matrix docs/operations-tables.html.