Skip to content

Add optional sightmap corpus setup to the install flow - #30

Open
nrodd wants to merge 7 commits into
mainfrom
sightmap-setup
Open

nrodd wants to merge 7 commits into
mainfrom
sightmap-setup

Conversation

@nrodd

@nrodd nrodd commented Sep 9, 2026 •

Copy link
Copy Markdown
Member

What

Adds an optional sightmap step to the wizard: after the capture snippet install, offer to build a .sightmap/ component corpus so future Subtext session reviews name the app's UI components ("add-to-cart button") instead of showing raw CSS selectors.

Follows the same handoff model as the main install — no bundled agent, the corpus is authored by the user's own coding agent — and mirrors the existing offerPluginSetup post-install pattern.

Design choices

  • Placement: a post-install offer (offerSightmapSetup), keeping the core snippet prompt lean and treating sightmap as a clearly-optional upsell.
  • Build mode: static seed-from-code by default; an optional live-coverage pass against a running dev server when the user pastes a URL.
  • Delivery: the standalone @sightmap/sightmap CLI (npm i -g + sightmap skills install), per the quickstart. The global install is deliberate — the agent's later skill calls invoke a bare sightmap, so the binary has to be resolvable outside the wizard process.

Changes

  • src/sightmap.ts — offerSightmapSetup(): confirm → optional dev-server URL → provision CLI → hand the chosen terminal agent a focused authoring prompt. Manual/GUI paths get an instructions note instead of a second launch. Never throws; mock mode prints "would run…".
  • src/prompt/sightmap.ts + templates/sightmap-prompt.md — the authoring prompt. Live pass renders only when a URL is given; uses the sightmap-authoring/sightmap-browser skills when present, falls back to the docs.
  • src/run.ts: wired into all three exit branches (terminal success, manual, GUI handoff) as the last item of the phase-2 "enrich your setup" offer, after identify/link-analytics/mask-PII rather than right after install.
  • --sightmap flag (bin.ts/config.ts) — sightmap is offered interactively by default; this opts in for unattended --yes runs (off otherwise, since it installs a global and the live pass wants a running app).
  • README + changeset (minor).

Notes / worth a look

  • Under the standalone-CLI delivery, the corpus is still authored by the coding agent (the CLI has no seed command), so the terminal path fires a second, confirm-gated agent run. Heavier than a plugin-only path would be.
  • Global npm i -g can need sudo on some setups — handled with a fallback instructions note rather than an abort.

Fixed after a real test run

  • --print-prompt silently skipped the sightmap step. offerSightmapSetup only special-cased --mock, and the terminal path also had it nested inside a !printPrompt guard meant for plugin setup, so a dry run never showed the authoring prompt at all. It now builds and prints the prompt the same way phase 1/2 do, then skips the CLI install and agent launch.
  • The offer now runs after phase 2, not before it. Previously it fired right after the snippet install, ahead of the first-ASR demo and independent of whether the user wanted phase 2 at all. It's now the last item inside the same "continue enriching?" gate, so declining phase 2 also skips it.
  • Claude Code couldn't actually run the sightmap CLI headlessly. A real run showed every sightmap invocation (version, --help, validate) coming back as an unresolvable approval prompt, since Claude Code's headless launch only allowlists npm/pnpm/yarn/bun install and Subtext doc fetches for auto-approved Bash use. Added scoped allowlist entries for exactly the sightmap subcommands the authoring prompt uses (version, --help, validate, lint, browser start, snapshot, sel-probe): deliberately not a blanket sightmap:*, since push and browser eval could otherwise become a prompt-injection exfiltration path the same way an unscoped WebFetch would.

Sightmap support by install option

Whether the corpus actually gets authored and validated non-interactively depends on the install path; support isn't uniform:

Install option Corpus authored? validate/lint/live-coverage run headlessly? Notes
Claude Code (terminal) Yes (second autonomous run) Yes Sightmap's authoring subcommands are now explicitly allowlisted for headless Bash use (this PR); everything else still falls back to Claude Code's normal approval flow.
Codex CLI (terminal) Yes (second autonomous run) Yes --full-auto auto-approves every command inside its workspace sandbox, so no extra allowlisting was needed.
Gemini CLI (terminal) Partial No Gemini's --approval-mode auto_edit never auto-approves shell commands, by design (not something this PR changes). The corpus YAML still gets written since file edits are auto-approved, but validate/lint and the live-coverage pass can't run non-interactively; the agent records what it couldn't finish in sightmap-setup-report.md.
GUI apps (Cursor, Windsurf, VS Code, Zed, Claude Desktop) User-driven As well as the agent's own interactive prompts allow Not auto-drivable (isAutoDrivable requires a terminal-kind agent with a binary), so the wizard shows copy-paste install and authoring instructions instead of launching anything. The user pastes this into their own interactive session and approves commands themselves, so this sidesteps the headless-approval problem entirely.
Manual User-driven As well as the agent's own interactive prompts allow Same as GUI apps: instructions only, no wizard-driven run.

Testing

  • npm run typecheck, npm run build, and npx vitest run (53/53) clean.
  • Both prompt variants (static / live) render correctly, including step renumbering.
  • Manual/CI instructions path exercised end-to-end via the mock flow.
  • --mock --print-prompt --yes --sightmap confirms the sightmap prompt now prints after the phase-2 enrichment prompt, and that its tooling check reads sightmap version.

Note

Medium Risk
Introduces global npm installs and a second autonomous agent run with scoped CLI permissions; core capture install is unchanged and sightmap errors are non-fatal.

Overview
Adds an optional post-enrichment step that offers to install @sightmap/sightmap, provision authoring skills, and have the user’s coding agent seed a .sightmap/ corpus so session reviews use semantic component names instead of raw selectors. Interactive runs get a confirm prompt (and optional dev-server URL for live coverage); --sightmap opts in when --yes skips prompts.

The step runs after identify/link-analytics/mask-PII on terminal, GUI, and manual paths via offerSightmapSetup; failures fall back to copy-paste instructions and never abort the wizard.

Also adds --stub-agent to exercise wizard flow without launching agents (still runs real sightmap CLI install when applicable), extends --print-prompt to include the sightmap authoring prompt, and scopes Claude Code’s Bash allowlist to specific sightmap subcommands (not blanket sightmap:*) for headless authoring without opening push / browser eval exfil paths.

Reviewed by Cursor Bugbot for commit 055cbd6. Bugbot is set up for automated code reviews on this repo. Configure here.

@cursor cursor Bot left a comment •

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale Bugbot comment from a previous run.

Comment thread src/sightmap.ts
offerSightmapSetup only checked --mock before running the CLI provision
+ agent launch, so a --print-prompt run fell straight into the launch
path (or, before the run.ts fix in the next commit, was skipped
entirely by a stale printPrompt guard meant for plugin setup). Either
way the authoring prompt never got printed, unlike the snippet and
enrich prompts.

Build the prompt up front and add a --print-prompt branch, checked
ahead of --mock, that prints it the same way STEP 1/2 do and returns
before touching the CLI install or agent launch.
offerSightmapSetup ran immediately after the snippet install (before
the demo guide), independent of whether the user wanted to continue
into the optional enrichment phase at all. That put it ahead of the
first-ASR moment it's meant to build on, and made it an implicit fourth
opt-in outside the "Step 2 of 2" framing.

Moved the call in all three handoff paths (manual, GUI app, terminal)
to run after the phase-2 enrichment prompt/follow-up, inside the same
confirmContinueEnriching gate — so declining phase 2 also skips the
sightmap offer, and accepting it runs as the last of four enrichment
items instead of a standalone step. Updated the phase-2 note to list
sightmap as item 4.
…ess run

A real test run showed the sightmap authoring prompt getting stuck:
every sightmap invocation (bare name and full path, version/--help/
validate) came back as an approval-required response with no way to
grant it non-interactively, so the agent could never run validate or
lint.

Claude Code's headless launch runs with --permission-mode acceptEdits
plus a hard --allowedTools list; anything off that list falls back to
its normal approval prompt, which a -p run can never answer. sightmap
wasn't on the list at all.

Added scoped Bash entries for exactly the subcommands the authoring
prompt uses: version, --help, validate, lint, browser start, snapshot,
sel-probe. Left out a blanket `sightmap:*` on purpose — sightmap also
has a `push` command that POSTs a corpus to an arbitrary URL and a
`browser eval` that runs arbitrary JS in the page, which would hand a
prompt injection the same exfiltration path the WebFetch domain scope
above is already guarding against.

Also switched the prompt's tooling check from `sightmap --version` to
`sightmap version`, matching the CLI's own documented subcommand (and
what the agent actually ran in testing), and updated the autonomy
string shown at the pre-launch confirmation to mention it.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 1620af3. Configure here.

Comment thread src/agents/claude-code.ts
'Bash(sightmap lint:*)',
'Bash(sightmap browser start:*)',
'Bash(sightmap snapshot:*)',
'Bash(sightmap sel-probe:*)',

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sightmap docs fetch is blocked

Medium Severity

The authoring prompt tells Claude Code to fetch https://docs.sightmap.org/start/quickstart when the sightmap-authoring skill is missing, but ALLOWED_TOOLS still scopes WebFetch to the two Fullstory domains. That fallback cannot run, so a failed skills install leaves the agent without the format reference the prompt calls the source of truth.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 1620af3. Configure here.

…ide effects

Testing a wizard change meant a tradeoff between --print-prompt (skips
the agent, but dumps the whole prompt to stdout every time) and a real
run (exercises everything, but spawns a real autonomous agent for
minutes on real tokens) or --mock (fast, but also skips real
provisioning like the sightmap CLI install, so it can't catch install
regressions).

--stub-agent fills the gap: it skips launching the coding agent for
every prompt (install, enrich, sightmap authoring) and logs a short
"<step>: prompt ran!" instead of printing the prompt, but leaves real
side effects alone — auth, snippet fetch, plugin CLI install, and
notably the sightmap CLI provisioning (npm install -g + skills
install), which now runs for real even under --mock. Wired into all
three driveLaunch/launch call sites in run.ts and into
offerSightmapSetup, which skips --mock's summary-only branch whenever
--stub-agent is set so the real install still happens.

src/test/helpers.ts gets the new required WizardOptions field.
Lead with what Sightmap is and why it helps, so people who don't know
the term are less likely to decline.

This branch has not been deployed

No deployments
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