[NO-TICKET] Offer all three ways to connect a site, and correct what the widget shows

[mariojgt]

What changed

guide, scan, setup and status now list three ways to attach a site to a Patchstack account, and lead with the widget's own "Connect this website" panel — already rendered on the preview the person is looking at, needing no terminal and no copied URL. The dashboard link and npx @patchstack/connect claim follow it. AGENT-INSTALL.md carries the same order.

The same output no longer promises a visible "Report a vulnerability" button.

Why the button was never there

The widget's public reference (cdn.patchstack.com/llm.html, data-build-mode, on by default) is explicit: while a site is unclaimed the widget shows a one-time "connect website" onboarding instead of the report button, and the button appears only once the site is claimed.

A fresh install is always unclaimed, so Widget: added the "Report a vulnerability" tag … Reload your preview to see it described something that could not be on the page yet. Agents repeat that line to the person verbatim, who refreshes the preview hunting for a control that only exists after a step nobody told them to take.

The same reference says claiming is meant to happen in the builder's edit preview, where the connect panel shows by default. So the route the output left out is the one the product is built around, and the two it named are the fallbacks.

Fix

• src/guide.ts — "Dashboard link" becomes "Connect this site to your Patchstack account", a numbered list of all three routes. The widget entry is dropped when the tag is not in place, so the numbering stays truthful for a project without one.
• src/guide.ts — the preview-refresh step now names the control that actually appears: the connect panel while unclaimed, the report button after.
• src/cli.ts — the same three routes after scan; status and the setup summary name the panel alongside the link and claim.
• AGENT-INSTALL.md — step 6 becomes the three routes, and the widget is described as a control whose form follows claim state, with an explicit instruction not to promise the button on a site that has no account yet.
• All of it now says an unclaimed site stays claimable by anyone who loads the page, since the UUID ships in the HTML and claiming is first-come. That is the reason to connect now rather than later, and nothing said it.

How it was verified

npm test (3252 passed, 197 files), npm run typecheck and npm run capabilities:check are green. Built dist/ and ran cli.js guide against a throwaway fixture carrying a widget tag, to read the rendered checklist rather than infer it. tests/guide.test.ts gains an assertion that the checklist does not promise the button before the site has an owner.

The field-test gate is outstanding, not met. src/guide.ts and AGENT-INSTALL.md are read by the fixture from the published tarball, so a run today would audit the previous release's text and say nothing about this change. It needs node field-test/run.mjs --persona hostile --rounds 3, plus standard or lovable for document accuracy, immediately after the release that carries it. Until then the deterministic gates above are what stand behind it.

Out of scope, worth a follow-up

The install prompt still says "tell me to refresh the preview if the 'Report a vulnerability' button is not showing yet" — the same inaccuracy, from the other direction. It is the byte-identical artifact in README.md, GETTING-STARTED.md and field-test/prompt.txt, so correcting it means all three together plus a hostile run before shipping. That is a different shape of change and deserves its own PR.

Docs: the public documentation carried the same problem plus a separate bug — it told readers to set data-report-form="true" to reveal the button, an attribute the widget does not read. Fixed in patchstack/documentation#88.

---

• I reviewed the code, comments, fixtures, commit messages, generated output, and PR description for private Patchstack or customer information.
• Nothing here is third-party confidential or proprietary material — copied system prompts, private transcripts, unpublished documentation. Where I relied on something being public, I verified it rather than assumed it.

🤖 Generated with Claude Code

[mariojgt]

/review

[coderbuds]

Clear CLI and documentation updates unify site connection flows

🎯 Quality: 100% Elite · 📦 Size: Small

📈 This month: Your 145th PR — above team average · Averaging Excellent

_{See how your team is trending →}