From 7f630d250282a8406c442e8f36ae4d629fbd19bc Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 15:02:30 +0000 Subject: [PATCH 1/8] docs(agents): Add writing-sdk-specs skill Repo-local skill that points agents at the Writing SDK Specs page, has them check their own changes against it, and report pre-existing violations without fixing them. Listed in AGENTS.md and SKILL.md. Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- .claude/skills/writing-sdk-specs/SKILL.md | 26 +++++++++++++++++++++++ AGENTS.md | 1 + SKILL.md | 1 + 3 files changed, 28 insertions(+) create mode 100644 .claude/skills/writing-sdk-specs/SKILL.md diff --git a/.claude/skills/writing-sdk-specs/SKILL.md b/.claude/skills/writing-sdk-specs/SKILL.md new file mode 100644 index 0000000000000..22100bbb30fa6 --- /dev/null +++ b/.claude/skills/writing-sdk-specs/SKILL.md @@ -0,0 +1,26 @@ +--- +name: writing-sdk-specs +description: Write, edit, or review SDK specs. Use when changing or reviewing any page under develop-docs/sdk/ that has spec_id frontmatter, or when creating a new SDK spec. +--- + +# Writing SDK Specs + +The rules live in [`develop-docs/sdk/getting-started/standards/writing-specs.mdx`](../../../develop-docs/sdk/getting-started/standards/writing-specs.mdx). That page is the source of truth. This skill only says when and how to apply it. + +## Steps + +1. **Read the guidelines.** Read `writing-specs.mdx` in full before changing a spec. Don't work from memory or from this file. +2. **Check whether the spec is legacy.** A spec is legacy if its frontmatter has no `spec_guidelines` field. +3. **Write to the guidelines.** + - **New spec:** follow the guidelines for the whole page and set `spec_guidelines: writing-specs@` to the current version of `writing-specs.mdx`. + - **Legacy spec:** make every requirement you add or change follow the guidelines. Leave the rest of the page as it is unless the user asks you to migrate it. Don't add `spec_guidelines` unless the whole page now conforms. +4. **Check your own work.** Re-read every requirement you added or changed against `writing-specs.mdx`, and fix any violations before you finish. +5. **Report existing violations.** List violations you noticed in content you didn't change, but don't fix them unless the user asks. Give the section and quote the text. + +## What to Report + +When you finish, briefly report: + +- Which guidelines version you followed. +- Whether the page is legacy or conforming, and whether you set `spec_guidelines`. +- Any pre-existing violations you found (or "none found"). diff --git a/AGENTS.md b/AGENTS.md index 0c692c1be4f92..e0f0c684b4c27 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -98,6 +98,7 @@ When writing requirements in `develop-docs/`: - **ALWAYS** run `/brand-guidelines` to audit any user-facing content before committing. See `.agents/skills/brand-guidelines/SKILL.md` - Use `docs-review` skill for Sentry style and voice review. See `.claude/skills/docs-review/SKILL.md` - Use `technical-docs` skill when writing or reviewing SDK documentation. See `.claude/skills/technical-docs/SKILL.md` +- Use `writing-sdk-specs` skill when writing, editing, or reviewing SDK specs (pages in `develop-docs/sdk/` with `spec_id` frontmatter). See `.claude/skills/writing-sdk-specs/SKILL.md` ## LLM-Friendly MD Exports diff --git a/SKILL.md b/SKILL.md index d7e9cc3b51cf3..bea3a8643043b 100644 --- a/SKILL.md +++ b/SKILL.md @@ -32,5 +32,6 @@ Source repo: https://github.com/getsentry/sentry-for-ai | Brand Guidelines | `.agents/skills/brand-guidelines/` | Audit content against Sentry brand voice | | Docs Review | `.claude/skills/docs-review/SKILL.md` | Sentry documentation style guide | | Technical Docs | `.claude/skills/technical-docs/SKILL.md` | Writing SDK and technical documentation | +| Writing SDK Specs | `.claude/skills/writing-sdk-specs/SKILL.md` | Writing and reviewing SDK specs in `develop-docs/sdk/` | | Commit | `.agents/skills/commit/SKILL.md` | Sentry conventional commit format | | Create Branch | `.agents/skills/create-branch/SKILL.md` | Branch naming conventions | From 7771fb10c9a122ac3228f6adb9a1cbb5e2d73425 Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 15:06:50 +0000 Subject: [PATCH 2/8] ref(agents): Manage writing-sdk-specs skill with dotagents Move the skill from .claude/skills/ to .agents/skills/ and declare it in agents.toml with a path: source, matching the dotagents convention for repo-local skills. Keep a .claude/skills symlink like the existing ones. Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- {.claude => .agents}/skills/writing-sdk-specs/SKILL.md | 0 .claude/skills/writing-sdk-specs | 1 + AGENTS.md | 4 +++- SKILL.md | 2 +- agents.toml | 4 ++++ 5 files changed, 9 insertions(+), 2 deletions(-) rename {.claude => .agents}/skills/writing-sdk-specs/SKILL.md (100%) create mode 120000 .claude/skills/writing-sdk-specs diff --git a/.claude/skills/writing-sdk-specs/SKILL.md b/.agents/skills/writing-sdk-specs/SKILL.md similarity index 100% rename from .claude/skills/writing-sdk-specs/SKILL.md rename to .agents/skills/writing-sdk-specs/SKILL.md diff --git a/.claude/skills/writing-sdk-specs b/.claude/skills/writing-sdk-specs new file mode 120000 index 0000000000000..c69df90dee5c2 --- /dev/null +++ b/.claude/skills/writing-sdk-specs @@ -0,0 +1 @@ +../../.agents/skills/writing-sdk-specs \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index e0f0c684b4c27..40143c0306709 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -78,6 +78,8 @@ To bypass the hook once without marking the file, use `SKIP=trailing-slashes git Managed skills in `.agents/skills/` are not checked in. Run `make develop` (or `npx -y @sentry/dotagents install`) to install them before relying on skills like `/brand-guidelines` or `/commit`. +Repo-specific skills live in `.agents/skills//`, are checked in, and are declared in `agents.toml` with a `path:` source (for example `writing-sdk-specs`). + ## Developer Documentation (develop-docs/) When writing requirements in `develop-docs/`: @@ -98,7 +100,7 @@ When writing requirements in `develop-docs/`: - **ALWAYS** run `/brand-guidelines` to audit any user-facing content before committing. See `.agents/skills/brand-guidelines/SKILL.md` - Use `docs-review` skill for Sentry style and voice review. See `.claude/skills/docs-review/SKILL.md` - Use `technical-docs` skill when writing or reviewing SDK documentation. See `.claude/skills/technical-docs/SKILL.md` -- Use `writing-sdk-specs` skill when writing, editing, or reviewing SDK specs (pages in `develop-docs/sdk/` with `spec_id` frontmatter). See `.claude/skills/writing-sdk-specs/SKILL.md` +- Use `writing-sdk-specs` skill when writing, editing, or reviewing SDK specs (pages in `develop-docs/sdk/` with `spec_id` frontmatter). See `.agents/skills/writing-sdk-specs/SKILL.md` ## LLM-Friendly MD Exports diff --git a/SKILL.md b/SKILL.md index bea3a8643043b..4267364ca6c35 100644 --- a/SKILL.md +++ b/SKILL.md @@ -32,6 +32,6 @@ Source repo: https://github.com/getsentry/sentry-for-ai | Brand Guidelines | `.agents/skills/brand-guidelines/` | Audit content against Sentry brand voice | | Docs Review | `.claude/skills/docs-review/SKILL.md` | Sentry documentation style guide | | Technical Docs | `.claude/skills/technical-docs/SKILL.md` | Writing SDK and technical documentation | -| Writing SDK Specs | `.claude/skills/writing-sdk-specs/SKILL.md` | Writing and reviewing SDK specs in `develop-docs/sdk/` | +| Writing SDK Specs | `.agents/skills/writing-sdk-specs/SKILL.md` | Writing and reviewing SDK specs in `develop-docs/sdk/` | | Commit | `.agents/skills/commit/SKILL.md` | Sentry conventional commit format | | Create Branch | `.agents/skills/create-branch/SKILL.md` | Branch naming conventions | diff --git a/agents.toml b/agents.toml index 1ae8bf208e65a..f3b08c363cb90 100644 --- a/agents.toml +++ b/agents.toml @@ -27,3 +27,7 @@ source = "getsentry/skills" [[skills]] name = "create-branch" source = "getsentry/skills" + +[[skills]] +name = "writing-sdk-specs" +source = "path:.agents/skills/writing-sdk-specs" From a62213d0ad0e96902f2e16043440326e82917ea7 Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 15:21:27 +0000 Subject: [PATCH 3/8] docs(agents): Drop writing-sdk-specs row from SKILL.md The root SKILL.md is a routing guide, not how skills are discovered. AGENTS.md already lists the skill. Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- SKILL.md | 1 - 1 file changed, 1 deletion(-) diff --git a/SKILL.md b/SKILL.md index 4267364ca6c35..d7e9cc3b51cf3 100644 --- a/SKILL.md +++ b/SKILL.md @@ -32,6 +32,5 @@ Source repo: https://github.com/getsentry/sentry-for-ai | Brand Guidelines | `.agents/skills/brand-guidelines/` | Audit content against Sentry brand voice | | Docs Review | `.claude/skills/docs-review/SKILL.md` | Sentry documentation style guide | | Technical Docs | `.claude/skills/technical-docs/SKILL.md` | Writing SDK and technical documentation | -| Writing SDK Specs | `.agents/skills/writing-sdk-specs/SKILL.md` | Writing and reviewing SDK specs in `develop-docs/sdk/` | | Commit | `.agents/skills/commit/SKILL.md` | Sentry conventional commit format | | Create Branch | `.agents/skills/create-branch/SKILL.md` | Branch naming conventions | From e7f872ad959d074aea53861dc0fb4bda4894329b Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 15:56:46 +0000 Subject: [PATCH 4/8] docs(agents): Skip process specs in writing-sdk-specs skill Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- .agents/skills/writing-sdk-specs/SKILL.md | 4 ++-- AGENTS.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.agents/skills/writing-sdk-specs/SKILL.md b/.agents/skills/writing-sdk-specs/SKILL.md index 22100bbb30fa6..0e95c5ab3e51e 100644 --- a/.agents/skills/writing-sdk-specs/SKILL.md +++ b/.agents/skills/writing-sdk-specs/SKILL.md @@ -1,6 +1,6 @@ --- name: writing-sdk-specs -description: Write, edit, or review SDK specs. Use when changing or reviewing any page under develop-docs/sdk/ that has spec_id frontmatter, or when creating a new SDK spec. +description: Write, edit, or review SDK specs. Use when changing or reviewing any page under develop-docs/sdk/ that has spec_id frontmatter (except process specs with spec_kind: process), or when creating a new SDK spec. --- # Writing SDK Specs @@ -10,7 +10,7 @@ The rules live in [`develop-docs/sdk/getting-started/standards/writing-specs.mdx ## Steps 1. **Read the guidelines.** Read `writing-specs.mdx` in full before changing a spec. Don't work from memory or from this file. -2. **Check whether the spec is legacy.** A spec is legacy if its frontmatter has no `spec_guidelines` field. +2. **Check what kind of spec it is.** If its frontmatter has `spec_kind: process` (playbooks and engineering standards), the guidelines don't apply: skip the remaining steps. Otherwise, the spec is legacy if its frontmatter has no `spec_guidelines` field. 3. **Write to the guidelines.** - **New spec:** follow the guidelines for the whole page and set `spec_guidelines: writing-specs@` to the current version of `writing-specs.mdx`. - **Legacy spec:** make every requirement you add or change follow the guidelines. Leave the rest of the page as it is unless the user asks you to migrate it. Don't add `spec_guidelines` unless the whole page now conforms. diff --git a/AGENTS.md b/AGENTS.md index 40143c0306709..dd1ef1ab2fe9e 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -100,7 +100,7 @@ When writing requirements in `develop-docs/`: - **ALWAYS** run `/brand-guidelines` to audit any user-facing content before committing. See `.agents/skills/brand-guidelines/SKILL.md` - Use `docs-review` skill for Sentry style and voice review. See `.claude/skills/docs-review/SKILL.md` - Use `technical-docs` skill when writing or reviewing SDK documentation. See `.claude/skills/technical-docs/SKILL.md` -- Use `writing-sdk-specs` skill when writing, editing, or reviewing SDK specs (pages in `develop-docs/sdk/` with `spec_id` frontmatter). See `.agents/skills/writing-sdk-specs/SKILL.md` +- Use `writing-sdk-specs` skill when writing, editing, or reviewing SDK specs (pages in `develop-docs/sdk/` with `spec_id` frontmatter, except those with `spec_kind: process`). See `.agents/skills/writing-sdk-specs/SKILL.md` ## LLM-Friendly MD Exports From 7020ce6012090f926f0807de42c28ead3c6e66d1 Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 16:33:18 +0000 Subject: [PATCH 5/8] docs(agents): Report requirement changes in migrations Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- .agents/skills/writing-sdk-specs/SKILL.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.agents/skills/writing-sdk-specs/SKILL.md b/.agents/skills/writing-sdk-specs/SKILL.md index 0e95c5ab3e51e..a0cf71deea234 100644 --- a/.agents/skills/writing-sdk-specs/SKILL.md +++ b/.agents/skills/writing-sdk-specs/SKILL.md @@ -24,3 +24,4 @@ When you finish, briefly report: - Which guidelines version you followed. - Whether the page is legacy or conforming, and whether you set `spec_guidelines`. - Any pre-existing violations you found (or "none found"). +- For a migration: every requirement you added, removed, or whose level or meaning changed, so a reviewer can check each one. From c746cf105d5c18aae14a9a8631ae31fc606d6d49 Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 16:54:43 +0000 Subject: [PATCH 6/8] docs(sdk): Migrate Modules spec to Writing SDK Specs guidelines Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- .../client/integrations/modules.mdx | 78 +++++-------------- 1 file changed, 18 insertions(+), 60 deletions(-) diff --git a/develop-docs/sdk/foundations/client/integrations/modules.mdx b/develop-docs/sdk/foundations/client/integrations/modules.mdx index e73e27e8df5b8..87cf40519fe2e 100644 --- a/develop-docs/sdk/foundations/client/integrations/modules.mdx +++ b/develop-docs/sdk/foundations/client/integrations/modules.mdx @@ -2,12 +2,16 @@ title: Modules description: Integration for attaching loaded libraries and their versions to events, populating the event modules field. spec_id: sdk/foundations/client/integrations/modules -spec_version: 1.0.0 +spec_version: 2.0.0 spec_status: stable +spec_guidelines: writing-specs@0.1 spec_depends_on: - id: sdk/foundations/client/integrations version: ">=1.0.0" spec_changelog: + - version: 2.0.0 + date: 2026-10-19 + summary: 'Migrated to Writing SDK Specs. Requirements now describe only externally observable behavior. Using the `processEvent` hook (was "MUST"), caching the module list, and choosing or combining discovery mechanisms are no longer required. The reported modules "SHOULD" instead reflect the libraries and versions actually in use. Attaching modules to events is "SHOULD" instead of "MUST"; their format stays "MUST".' - version: 1.0.0 date: 2026-03-04 summary: Initial spec, extracted from expected features @@ -18,89 +22,43 @@ sidebar_order: 4 -## Overview +The Modules integration attaches the libraries an application uses, and their versions, to events. Sentry shows them in the event details, so users can spot dependency-related issues. -The Modules integration attaches a list of loaded libraries (packages, modules) and their versions to events. This populates the [`modules` field](/sdk/foundations/envelopes/event-payloads/#optional-attributes) on the event payload, which Sentry displays in the event detail view to help users identify dependency-related issues. +## Requirements -This integration **SHOULD** be a default integration. - ---- - -## Behavior - - + ### Event Enrichment -The integration **MUST** use the `processEvent` lifecycle hook to attach module information to events. +SDKs **SHOULD** enable the Modules integration by default. -The integration **MUST** populate `event.modules` as a map of module name to version string: - -```json -{ - "modules": { - "flask": "2.3.1", - "requests": "2.31.0", - "sqlalchemy": "2.0.19" - } -} -``` - -The integration **SHOULD** cache the module list, since installed packages rarely change during a process lifetime. +The integration **SHOULD** attach modules to events. Attached modules **MUST** be in the event's [`modules` field](/sdk/foundations/envelopes/event-payloads/#optional-attributes), as a map from module name to version string. - + ### Module Sources -How modules are discovered is platform-specific. SDKs **SHOULD** use the most reliable mechanism available on their platform. Common strategies include: - -- **Package manager metadata** — reading installed package registries (e.g., `pkg_resources` or `importlib.metadata` in Python, `package.json` dependencies in Node.js) -- **Runtime module cache** — inspecting loaded modules from the runtime (e.g., `require.cache` in Node.js CJS) -- **Build-time injection** — embedding module information at build time when runtime discovery is unavailable or incomplete (e.g., bundled environments) - -SDKs **MAY** combine multiple sources to produce the most complete list. When the same module appears in multiple sources, the more specific version (e.g., from a lockfile or runtime cache) **SHOULD** take precedence. +The `modules` field **SHOULD** list the libraries installed in or loaded by the application, each with the version actually in use. - + ### Event Type Filtering -SDKs **MAY** skip attaching modules to certain event types (e.g., transactions) where the information is less useful, to reduce payload size. +SDKs **MAY** omit modules from event types where they are less useful, such as transactions, to reduce payload size. ---- - -## Examples - -### JavaScript (Node.js) - -```javascript -// modulesIntegration is a default integration in @sentry/node -Sentry.init({ - dsn: "https://examplePublicKey@o0.ingest.sentry.io/0", -}); +## Implementation Guidance -// Modules are automatically attached to error events. -// The integration reads from package.json and require.cache (CJS). -``` +_This section is non-normative._ -### Python +How to discover modules depends on the platform. Common sources are package manager metadata (such as `importlib.metadata` in Python or `package.json` in Node.js), the runtime's module cache (such as `require.cache` in Node.js CJS), and module lists injected at build time, for bundled environments where runtime discovery is incomplete. When SDKs combine sources, the version from the more specific source, such as a lockfile or the runtime cache, is usually the one in use. -```python -import sentry_sdk - -# ModulesIntegration is a default integration -sentry_sdk.init(dsn="https://examplePublicKey@o0.ingest.sentry.io/0") - -# Modules are automatically attached to error events. -# The integration reads from importlib.metadata / pkg_resources. -``` - ---- +Installed packages rarely change while a process runs, so SDKs typically collect the module list once and cache it, rather than collecting it for every event. ## Changelog From f0eb0342214a3c7dd816ae5975250d48e220ed82 Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 16:58:55 +0000 Subject: [PATCH 7/8] docs(sdk): Add Scope section to Modules spec Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- .../sdk/foundations/client/integrations/modules.mdx | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/develop-docs/sdk/foundations/client/integrations/modules.mdx b/develop-docs/sdk/foundations/client/integrations/modules.mdx index 87cf40519fe2e..342da6a63cd2c 100644 --- a/develop-docs/sdk/foundations/client/integrations/modules.mdx +++ b/develop-docs/sdk/foundations/client/integrations/modules.mdx @@ -24,13 +24,17 @@ sidebar_order: 4 The Modules integration attaches the libraries an application uses, and their versions, to events. Sentry shows them in the event details, so users can spot dependency-related issues. +## Scope + +This spec applies to SDKs that implement the Modules integration. + ## Requirements ### Event Enrichment -SDKs **SHOULD** enable the Modules integration by default. +SDKs **SHOULD** enable the integration by default. The integration **SHOULD** attach modules to events. Attached modules **MUST** be in the event's [`modules` field](/sdk/foundations/envelopes/event-payloads/#optional-attributes), as a map from module name to version string. From c183f0983797f3b554e9a9beca2fb49982c2bd9b Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Mon, 19 Oct 2026 17:10:27 +0000 Subject: [PATCH 8/8] docs(sdk): Apply Clarity rule to Modules spec Co-Authored-By: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com> --- .../sdk/foundations/client/integrations/modules.mdx | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/develop-docs/sdk/foundations/client/integrations/modules.mdx b/develop-docs/sdk/foundations/client/integrations/modules.mdx index 342da6a63cd2c..e67d582795e27 100644 --- a/develop-docs/sdk/foundations/client/integrations/modules.mdx +++ b/develop-docs/sdk/foundations/client/integrations/modules.mdx @@ -11,7 +11,7 @@ spec_depends_on: spec_changelog: - version: 2.0.0 date: 2026-10-19 - summary: 'Migrated to Writing SDK Specs. Requirements now describe only externally observable behavior. Using the `processEvent` hook (was "MUST"), caching the module list, and choosing or combining discovery mechanisms are no longer required. The reported modules "SHOULD" instead reflect the libraries and versions actually in use. Attaching modules to events is "SHOULD" instead of "MUST"; their format stays "MUST".' + summary: 'Migrated to Writing SDK Specs. Requirements now describe only externally observable behavior. Using the `processEvent` hook (was "MUST"), caching the module list, and choosing or combining discovery mechanisms are no longer required. The reported modules "SHOULD" instead list every installed or loaded module with the version in use. Attaching modules to events is "SHOULD" instead of "MUST"; their format stays "MUST". The "MAY" for omitting modules now covers only events that are not error events, instead of any event type where modules are less useful.' - version: 1.0.0 date: 2026-03-04 summary: Initial spec, extracted from expected features @@ -28,6 +28,10 @@ The Modules integration attaches the libraries an application uses, and their ve This spec applies to SDKs that implement the Modules integration. +## Definitions + +- **Module**: a library or package the application can use, such as a Python distribution or an npm package. + ## Requirements @@ -36,7 +40,7 @@ This spec applies to SDKs that implement the Modules integration. SDKs **SHOULD** enable the integration by default. -The integration **SHOULD** attach modules to events. Attached modules **MUST** be in the event's [`modules` field](/sdk/foundations/envelopes/event-payloads/#optional-attributes), as a map from module name to version string. +The integration **SHOULD** attach modules to every event, except where [Event Type Filtering](#event-type-filtering) allows it to omit them. Attached modules **MUST** be in the event's [`modules` field](/sdk/foundations/envelopes/event-payloads/#optional-attributes), as a map from module name to version string. @@ -44,7 +48,7 @@ The integration **SHOULD** attach modules to events. Attached modules **MUST** b ### Module Sources -The `modules` field **SHOULD** list the libraries installed in or loaded by the application, each with the version actually in use. +The `modules` field **SHOULD** list every module installed in the application's environment or loaded by the application, each with the version the application uses. @@ -52,7 +56,7 @@ The `modules` field **SHOULD** list the libraries installed in or loaded by the ### Event Type Filtering -SDKs **MAY** omit modules from event types where they are less useful, such as transactions, to reduce payload size. +SDKs **MAY** omit modules from events that are not error events, such as transactions, to reduce payload size.