Watchdog

Watchdog answers one question every day: do your important product journeys actually work right now? It uses your Product Map, prior browser evidence, and founder priorities to choose a bounded set of journeys, then drives the product in a real browser and records one video. Runtime errors and repository changes are separate Rangers; Discovery Triage correlates their reports after every source finishes.

Prerequisites

• Turn it on. Watchdog is off until you enable it — one toggle on the Watchdog tab. It then wakes daily on its own cadence; the Find now button runs it on demand.
• A browsable target. Watchdog needs a URL to point the browser at. If none is configured it skips with a one-line reason.
• Better with a connected GitHub repo and a synced Product Map — that's how it targets your actual flows. Without a map it still probes the obvious sign-up, sign-in, and core journeys it can discover from the product.

How it works

1. Orient + choose coverage. Watchdog reads the full Product Map, seven days of synthetic-browser history, and active founder steering. It does not read commits or runtime errors; those belong to separate Rangers.

2. Choose a bounded probe set — a handful of real user flows, not pages (about 8 at most), in priority order:

   • Starred stories you pinned — always included.
   • Onboarding / sign-up — the highest-value check, and it needs no login (it creates a fresh throwaway account).
   • Sign-in and the core action — the main thing users come to do, plus anything that saves user data.
   • Billing / checkout — the money flows.
   • At risk — stories whose source files changed recently, or that map to a live error.
   • Backfill — a couple of never-verified stories to drain the backlog over days.

   It deliberately skips static/informational pages — terms, privacy, changelog, marketing, blog. A 200 on /terms tells a founder nothing.

3. Write and run one spec. It writes a single Playwright test — one continuous video — signing in once up front when a flow needs an account. Each probe is wrapped so a mismatch is recorded as a finding, never a crash, so the video always finishes and every probe runs. It instruments console errors, page errors, dead clicks, and rough timing.

4. File findings. One result per probed item: pass (works as expected), fail (broken — doesn't complete, errors, or dead-ends), or friction (works but with notable measured friction). A pass clears any prior ticket for that thing; a reproduced fail or notable friction files a draft ticket — or updates the existing one, since dedup is automatic — with the recording attached.

What you get

• A draft ticket per reproduced problem on the Tasks board, each with the screen recording of the failure and an observed-vs-expected summary. Because failures dedup against open tickets, a recurring break updates its ticket instead of spawning duplicates.
• A run summary — e.g. "Probed 5 stories; sign-in broken, checkout OK" — and cleared tickets for anything that now passes.
• Nothing when all is well. No noise on a healthy day; the value is that the silence is trustworthy.

Notes & limits

• Recommend-only. Watchdog observes and reports. It never edits code, opens a PR, or changes your product — you decide what to do with each finding (comment on the ticket to hand it to a coding loop).
• Read-only on production. When the target is your live site it probes non-destructively only — no deletes, purchases, or sign-ups that email real users. Destructive checks (like a real sign-up) run only against a staging target. Point Watchdog at staging with a throwaway account to get the fullest coverage.
• A slice per run, not everything. It probes a handful of the highest-stakes flows each day rather than the whole inventory, rotating through never-verified stories over time.
• It reads the Product Map to aim. The richer and more current your Product Map, the better Watchdog targets what matters. GitHub default-branch changes keep it fresh automatically.