Suggest File Search for storage searches and measure its wizard - #1433

Summary

People who search the catalog for their NAS or file server ("synology", "nextcloud", "nas", "Dateiserver", "pdf") mostly found the system's own API connector (Synology DSM, Nextcloud) and never learned that the AI can search inside the files stored there. This PR proposes File Search next to the API connector for those searches. It also adds product events to the File Search wizard, so we can see where setups stop: opened, connection test, scan, activation, plan wall.

Changes

• Catalog search (catalog-search.ts; the backend and frontend copies are still byte-identical): a small intent map, FILE_SEARCH_INTENTS. It maps storage and document words (synology, qnap, nextcloud, owncloud, fritzbox, storage box, s3/minio, sftp, ftp, webdav, nas, file server/Dateiserver/Netzlaufwerk/smb, documents/Dokumente/pdf/files) to the File Search entries that read them. Those entries go first, or right after a result named exactly like the query: "synology" gives synology, then synology-file-search, and "nextcloud" gives nextcloud, nextcloud-file-search, webdav. The result gets a new field, fileSearch. Hits gain suggested, and the new match kind suggested covers entries the words did not match by themselves. Queries for SharePoint, OneDrive, Google Drive, Dropbox or iCloud get no suggestion. Only entries the caller passed in are suggested.

• Store and /welcome: a short hint under the search box ("Want your AI to search inside the documents? …") with a button that opens the wizard for the first suggestion. Copy is in en, de and it. Welcome result cards for File Search entries now link straight to the wizard.

• Chat (connector-setup.service.ts): setup_find_connectors marks File Search results with fileSearch: true and a setupUrl to the wizard, and adds a top-level fileSearch note so the model offers it. Before this, it listed them like any connector and told the model to call setup_install_connector, which then failed. setup_install_connector on a File Search entry now returns the wizard link and installs nothing.

• Setup path helper (adapters/file-search-setup.ts): builds the wizard path with protocol, preset, adapter and from. importAdapter's file_search_wizard error now carries the preset too. The frontend fileSearchSetupPath builds the same path.

• Product events (product-event.service.ts, each one documented in the allow-list):

  • file_search_wizard_opened: via = store, welcome, store_hint, welcome_hint, connectors_new or chat
  • file_search_test_passed and file_search_test_failed: kind = the test's error kind, or request_failed. A first test that only asks to confirm the server fingerprint counts as neither.
  • file_search_scan_finished: kind = fits, over_plan, done or failed; files = a count bucket
  • file_search_activated: files = a count bucket
  • file_search_locked_shown: kind = no_licence, expired, community, plan_without_feature or connector_limit

  Every event carries protocol, preset and adapterSlug when they are known. New metadata keys protocol, preset and files only accept known values (the protocols, the presets, the FILE_COUNT_BUCKETS). A host, path, file name or exact count is dropped.

• Docs: docs/connectors/file-search.md describes the search suggestions and the events. llms.txt and llms-full.txt are regenerated.

Cloud and self-hosted

• Both: the suggestions, the hint, the chat answer and the events behave the same way.
• Network folder: suggested on self-hosted only. No new deployment check was needed: AdaptersService.listAll() already leaves selfHostOnly adapters out when DEPLOYMENT_MODE=cloud (isInstallableHere), and both the dashboard's /api/adapters list and the chat search only pass in what this deployment offers. On the Cloud, "Netzlaufwerk" suggests sftp and webdav. Tests cover both modes.
• Events: written to the local product_events table, on the Cloud and self-hosted alike, like the existing setup_* events.

Type

• Bug fix
• New feature
• Documentation
• Refactoring
• Performance improvement
• Other (describe below)

Testing

• Added/updated unit tests
• Tested manually (describe steps below)
• No tests needed (explain why)

New tests:

• catalog-search.spec.ts: the ranking for each storage query, the self-hosted vs Cloud network folder, no suggestion for cloud drives or other apps, the cap, the suggested kind, words written apart or together, intent slugs that must exist as FILE_SEARCH adapters.
• connector-setup.service.spec.ts: Synology suggestion with the wizard URL, network folder on self-hosted only (DEPLOYMENT_MODE=cloud case), nothing for cloud drives, install answered with the wizard link and nothing imported.
• product-event.spec.ts: the whole funnel stored with allowed metadata, unknown protocol, preset or exact count dropped, match: 'suggested' kept.

Commands (Node 22, run in the worktree, after npx prisma generate in packages/backend):

Not run: Playwright (npm run test:e2e), and no manual browser check of the hint. No adapter JSON changed, so adapter validation and the catalog regeneration were not needed.

The German and Italian strings were written without a native-speaker review: German uses Sie, Italian tu, and they follow the existing fileSearch wording ("Dateisuche", "Ricerca file").

Checklist

• My code follows the existing code style
• I have tested my changes locally
• I have updated documentation (if applicable)
• All existing tests pass (npm test)
• This PR has a descriptive title

Notes

• First successful sync: not added. The sync runs complete in ee/file-search/sync/sync-runner.ts, and nothing outside ee/ sees the result without touching that code. It could be a server-side event there later, if a change under ee/ is approved.
• Nothing under ee/ is touched. ee/support/support-catalog.ts calls searchCatalog; the new result field is additive.

Related Issues

None. This is a small feature within the existing File Search and catalog search (no schema, auth or API break), so no issue was opened first.