fix: ship web fetch-browser so the blocked-fetch escalation works (#247)

[ankitranjan7]

Fixes #247

What was actually broken

The issue's mechanism is right, the symptom has drifted. On 0.6.0 the failure is not Site "web" is not installed — the generated cli-manifest.json does ship and advertises web/fetch-browser, so the command is discoverable and dies on execution:

code: ADAPTER_LOAD
message: Cannot find module .../@agentrhq/webcmd/clis/web/fetch-browser.js

(reproduced against a globally installed 0.6.0). Dead end either way, same root cause.

Root cause: 0470ac43 (#216) removed "clis/" from package.json files while moving adapters to plugins. clis/web was moved to neither place — and there is no web plugin (webcmd-plugin.json registers 122; none is web), so webcmd plugin search web offers no recovery.

The fix

Ship it in the core package, per the issue's first option. The published package can't carry adapter source at the root — check-package-bin.mjs:73 fails the build on a top-level clis/ or plugins/ in the tarball, and that policy stays — so the build stages the tree next to the compiled output instead:

• copy-yaml.cjs copies clis/ → dist/src/clis/ (tests excluded), the same staging it already does for playwright-client.js. files already ships dist/src/.
• BUILTIN_CLIS uses the repo-root clis/ when it exists (dev, tsx src/main.ts) and falls back to <compiled dir>/clis in an installed package.
• build-manifest writes a second copy of the manifest to dist/src/cli-manifest.json, because the lookup contract is clisDir/../cli-manifest.json — without it an installed CLI would fall back to a filesystem scan and eagerly import every adapter on startup.
• check-package-bin gains the positive assertion: every cli-manifest.json modulePath must be present in the packed tarball. That is precisely the regression this bug was.

What this does not do: reimplement fetch-browser as a client-owned fast path next to web fetch. The browser lifecycle it depends on (page provisioning, session, cloak, pre-nav, observation, tab cleanup) lives in execution.ts around the adapter, and a literal port duplicates all of it. This delivers what the core option promised — ships in the package, zero install steps, the pair works out of the box — while keeping one browser lifecycle. Say the word if you want the literal port instead.

Verification

• npm pack → install tarball to a temp prefix → webcmd web fetch-browser --url https://example.com --stdout returns the extracted Markdown. Before: ADAPTER_LOAD.
• check:package-bin passes; with the staging step reverted it fails with packed tarball is missing manifest module for web/fetch-browser — the guard bites on the real regression.
• cli-manifest.json and hosted-contract.json regenerate byte-identical (check:hosted-contract passes). check:plugin-parity, typecheck, and npm test (394 files, 4781 tests) pass.

Notes

• No conflict with fix: make client-owned web fetch discoverable (#252) #263 — that PR changes clis/web/fetch.js content, not its location. It also benefits: its discoverability entry for web fetch pointed at a file fresh installs did not contain either, and now does.
• smart-search: mandatory SERP-first cost order wastes the budget when the query names a site #248 (the smart-search PR, fix(skill): add a site-named fast path to smart-search (#248) #269) is the other half of that session's cost; unrelated files.

🤖 Generated with Claude Code

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.