Skip to content

feat(self-driving): add Replay Vision scanners as step 6c - #313

Open
Twixes wants to merge 1 commit into
mainfrom
feat/self-driving-replay-vision-scanners
Open

feat(self-driving): add Replay Vision scanners as step 6c#313
Twixes wants to merge 1 commit into
mainfrom
feat/self-driving-replay-vision-scanners

Conversation

@Twixes

@Twixes Twixes commented Aug 4, 2026

Copy link
Copy Markdown
Member

Pairs with PostHog/wizard#1055 — that side adds the OAuth scope and the prompt STEP. Neither half works alone.

What

Self-driving currently sets up the pull side of the inbox — signal sources and scouts. This adds the push side: a new step 6c that creates Replay Vision scanners with emits_signals: true, so breakage a recording reveals but no event records — a blank screen, a dead button, a broken layout, a spinner that never resolves — reaches the inbox too.

No new backend contract. replay_vision/scanner_finding is already a registered, self-authorizing signal source: the emits_signals flag on the scanner is the per-source config, so there's no SignalSourceConfig row to create (noted explicitly in step 4, since the enum lists replay_vision and it's an easy wrong turn).

Two skeletons, and why two

Each skeleton locks the trust-critical bits — scanner_type, emits_signals, the base prompt — and leaves the agent exactly two blanks it's uniquely placed to fill from the repo: the query and a one-line product-context sentence. Curated perspective, tailored targeting.

  1. Broken experiences — scoped to the product's key completion flow, read out of the repo. sampling_rate: 0.5.
  2. User frustration$rageclick-gated. sampling_rate: 1.0.

The count is derived, not picked, and this is the part worth reviewing:

  • emits_signals appends a fixed defect-hunting turn to every scan (signals_step.jinja), identical regardless of the scanner's own prompt. So prompts don't differentiate scanners — queries do. The skill says so outright, so the agent spends its effort on targeting rather than wording.
  • Signals are grouped semantically, not by source (temporal/grouping.py), and scanner findings emit at 0.5 against a WEIGHT_THRESHOLD of 1.0. Two scanners matching the same session therefore describe one defect twice and sum to exactly the promotion threshold — overlapping scanners manufacture their own corroboration, which is the one thing the half-weight design exists to prevent.

Hence two scanners on deliberately different filter axes (where the user is vs what they did), plus a hard "widen one, narrow the other" rule. An earlier draft had a third "Blocked conversion" monitor; its query was a subset of scanner 1's, so the pair would have double-scanned the same sessions. Its real value was never the prompt wording but the targeting — insisting the agent find the actual completion path — so that folded into scanner 1's query instead.

Also

  • Chain wired 6b → 6c → 7; description.md 9→10 steps.
  • 7-report.md gains a scanners section — including that this is the only part of setup spending Replay Vision quota.
  • 6-scouts.md: the signals-scout-replay-vision pick is now scoped to scanners the team already had. 6c runs after step 6, so its new scanners have no observations for that scout to read yet.

Merging

Land the wizard side (#1055) and cut its npm release before adding mcp-publish here. If this skill ships first, the agent reads step 6c before the wizard requests the replay_scanner scope and 403s.

To be clear, this is not gated on any manual prod OAuth-ceiling edit — an earlier version of this note said it was, wrongly. The wizard apps' ceiling uses the @default sentinel, which already covers replay_scanner:* (see wizard#1055 for the mechanics). The only sequencing constraint is wizard-release-before-publish; a token predating the scope is fixed by a reconnect, not a ceiling edit.

Testing

pnpm build renders the chain correctly as 10 steps with 6c between 6b and 7. pnpm test 137 pass. pnpm security-scan:skills reports zero findings in self-driving-setup (the pre-existing failures are in other skills, untouched here).

Self-driving sets up the pull side of the inbox (sources, scouts) but not
the push side. This adds step 6c: create Replay Vision scanners with
`emits_signals: true`, so on-screen breakage a recording reveals — a blank
screen, a dead button, a broken layout — reaches the inbox too. No new
contract needed; `replay_vision`/`scanner_finding` is already a registered,
self-authorizing signal source, so the flag on the scanner IS the config.

Two locked `monitor` skeletons. Each pins the trust-critical bits
(`scanner_type`, `emits_signals`, base prompt) and leaves the agent two
blanks it's uniquely placed to fill from the repo: the `query` and a
one-line product-context sentence.

The count is derived, not chosen. `emits_signals` appends a *fixed* defect
turn to every scan — the same one regardless of the scanner's own prompt —
so prompts don't differentiate scanners, queries do. And because grouping
matches signals semantically rather than by source, two scanners over the
same sessions describe one defect twice and sum 0.5 + 0.5 to the promotion
threshold: overlapping scanners manufacture their own corroboration. So the
two here filter on deliberately different axes (URL vs `$rageclick`), and
"widen one, narrow the other" is a hard rule. A third "blocked conversion"
monitor would have been scanner 1 under another name; its real value was
the targeting, which folded into scanner 1's query instead.

Also: chain 6b → 6c → 7, note in step 4 that scanners need no source row,
and scope the `signals-scout-replay-vision` pick in step 6 to scanners the
team already had (6c runs later, so its scanners have no observations yet).
@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

🧙 Wizard CI

Run the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands:

Test all apps:

  • /wizard-ci all

Test all apps in a directory:

  • /wizard-ci basic-integration
  • /wizard-ci mcp-analytics
  • /wizard-ci revenue
  • /wizard-ci self-driving

Test an individual app:

  • /wizard-ci basic-integration/android
  • /wizard-ci basic-integration/angular
  • /wizard-ci basic-integration/astro
Show more apps
  • /wizard-ci basic-integration/django
  • /wizard-ci basic-integration/fastapi
  • /wizard-ci basic-integration/flask
  • /wizard-ci basic-integration/javascript-node
  • /wizard-ci basic-integration/javascript-web
  • /wizard-ci basic-integration/laravel
  • /wizard-ci basic-integration/next-js
  • /wizard-ci basic-integration/nuxt
  • /wizard-ci basic-integration/python
  • /wizard-ci basic-integration/rails
  • /wizard-ci basic-integration/react-native
  • /wizard-ci basic-integration/react-router
  • /wizard-ci basic-integration/sveltekit
  • /wizard-ci basic-integration/swift
  • /wizard-ci basic-integration/tanstack-router
  • /wizard-ci basic-integration/tanstack-start
  • /wizard-ci basic-integration/vue
  • /wizard-ci mcp-analytics/custom-dispatcher
  • /wizard-ci mcp-analytics/typescript-sdk
  • /wizard-ci revenue/stripe
  • /wizard-ci self-driving/astro
  • /wizard-ci self-driving/fastapi
  • /wizard-ci self-driving/nuxt
  • /wizard-ci self-driving/react-router
  • /wizard-ci self-driving/sveltekit

Results will be posted here when complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant