---
name: feedback_web_search_over_probing
description: For external API/capability discovery, LEAD with web search (grok/gemini) and bundled docs; use live endpoint-probing only to CONFIRM a search/doc-derived hypothesis - never as the primary discovery method. Mike's correction 2026-06-17.
metadata:
  type: feedback
---

When figuring out an external system's API surface or capabilities, **web search (grok
xsearch / gemini search) and the vendor's own docs carry AT LEAST as much weight as live
experimentation** - usually more.

**Why (Mike, 2026-06-17):** blind endpoint-probing ("does `/stat/openvpn` exist? does
`/cmd/vpnmgr`?") is guessing - it mostly 404s and is "highly suspect" as a source of truth.
The genuinely valuable leads this session came from the searches: grok surfaced the UniFi
**cloud connector proxy** (`/v1/connector/consoles/.../proxy/...`); gemini surfaced the
**Teleport `/rest/setting/teleport`** path. Probing only *confirmed* those after the search
pointed the way.

**How to apply:**
- Discovery order: web search + bundled docs FIRST -> form a specific hypothesis -> then ONE
  targeted live call to CONFIRM it. Not: spray candidate URLs and infer from status codes.
- Reading a system's OWN config (e.g. our gateway's `networkconf`) is fine - that's reading
  real data, not guessing endpoints. The "suspect" part is guessing unknown PATHS.
- Do not present probe results as "authoritative" over web-search findings; weight them at
  least equally and reconcile.
- Corollary: the web-search bots being flaky is a real liability (see CT_THOUGHTS "Thought 2 -
  web-search reliability MUST FIX"); when they fail, say so plainly rather than silently
  falling back to guessing and calling it authoritative.
- Complements [[feedback_interview_ai_read_docs]].