dd-instrument-rum

Datadog Browser RUM instrumentation

Instrument only the browser application in scope. Do not add Datadog APM, tracing, LLM Observability, Logs, source-map upload, user identification, Vercel metadata, Shopify, Salesforce, or unrelated Datadog products.

Use normal file inspection, editing, and command tools for every step except optional RUM application creation. Use only CreateRumApplication for that operation, as described in references/common-credentials.md; never invent Datadog tool names.

Ground rules

• Inspect before editing. Base every framework, version, entrypoint, command, and configuration decision on project files.
• Copy package names, import paths, exported symbols, and init option keys exactly from the applicable references. Do not substitute package aliases or recreate SDK APIs from memory.
• Post a short checklist before making changes and update it as work completes.
• Initialize RUM exactly once and as early as safely possible in the browser lifecycle. Never put init() in a component render, lifecycle hook, route handler, or repeated callback.
• Preserve an existing valid init configuration. Add missing compatible framework plugin wiring to that init in place; never create a competing init.
• Existing-init credential guardrail: when one valid RUM init already exists, treat its applicationId, clientToken, site, service tags, sampling, privacy, tracking, and every other existing option as immutable. Credentials supplied by the task are for a new init only; they are not an override for an existing valid init. In this branch, do not rewrite credential lines while adding plugin wiring.
• Stop without editing when required credentials cannot be resolved, site is invalid, framework/plugin prerequisites are unmet, permissions prevent the work, or multiple conflicting init calls cannot be safely consolidated.
• Install only packages required for Browser RUM. Keep @datadog/browser-rum and every @datadog/browser-rum-* integration package on the same exact SDK version.
• Persist dependencies in the manifest and lockfile used by the real build. Do not rely on packages that happen to exist in node_modules.
• Preserve application behavior, existing custom error handling, formatting conventions, and unrelated code.
• Apply edits with the available file-editing tool. If an expected text match fails, re-read the file and adapt to its current contents instead of retrying the same edit.
• Do not write project paths, framework details, credentials, client tokens, or RUM application IDs to persistent memory.
• Run a terminating build before reporting success. Never claim telemetry was received unless it was actually observed.