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.

Phase 1: analyze the target

Locate the browser application

Identify the project root that produces browser code. In a monorepo, inspect workspace configuration, scripts, Dockerfiles, and CI/deployment configuration to find the frontend manifest used by the real build rather than editing the repository root by assumption. Record that manifest path and its package manager before editing. If several independent browser applications are plausible and the user did not select one, ask which application to instrument.

Reject non-browser applications such as Ink CLIs and projects with no HTML/browser build target.

Detect the framework and runtime shape

Inspect dependencies and source layout in this order so meta-frameworks win over their underlying UI library:

1. nuxt -> Nuxt
2. next -> Next.js; distinguish App Router from Pages Router by source layout
3. @angular/core -> Angular; distinguish standalone bootstrap from NgModule
4. vue -> Vue
5. svelte or @sveltejs/kit -> Svelte or SvelteKit
6. react -> React
7. Browser entrypoint without the above -> generic/vanilla browser application

Also detect:

• Exact framework, React Router, TanStack Router, Vue Router, and Node versions.
• TypeScript when a tsconfig.json or TypeScript dependency is present; otherwise preserve JavaScript.
• Package manager from the deployed manifest's packageManager field first, then its adjacent lockfile: bun.lock or bun.lockb, pnpm-lock.yaml, yarn.lock, or package-lock.json. Use npm only when no stronger project signal exists, and never mix managers.
• Bundler from configuration and dependencies: Vite, Webpack, Rollup, esbuild, Rspack, or Create React App (react-scripts). Treat unmanaged HTML as CDN only when no package/bundler build owns it.
• Browser entrypoint from build configuration, HTML script targets, framework conventions, and the import graph rather than filename alone.
• The normal terminating build/typecheck command.
• Existing public environment-variable conventions.

Read references/rum-core.md, then read exactly the applicable framework reference:

Validate every prerequisite in the selected reference before provisioning credentials or editing. Do not upgrade a framework and do not silently fall back to core-only RUM when a detected framework plugin is incompatible.