Everything in the atlas

Alerting by mail is not telemetry — if you need traces and metrics correlated across handlers, that is a different layer. It also publishes no repository, so the package is the only thing to read.

The generated files are copied or deployed into the ABAP system by hand, the fourth step of its own usage list, so nothing keeps an activated service in step with the model it was generated from. Its peer dependency is `@sap/cds` ^9.8, so it does not install into a project on an earlier CAP release.

Not published to npm. Install from source.

Archived The declared repository is archived.

Functional boundary For versioned or thumbnail-enabled repositories, or bulk upload and download, the [README](https://raw.githubusercontent.com/vneecious/sap-cap-sdm-plugin/d9f036b16542e5c5b9b6dc704e0ba5f880193212/README.md) labels this an “early release” and lists those features as unsupported.

When user-dependent responses are cached without user-aware or explicit operation keys, or translated responses share keys across locales. These cases require key isolation; locale-aware keys are off by default.

The maintainer marks this under active development; public APIs, annotation names and OData contracts may still change.

The maintainer marks this early development; expect the contract to move.

It declares no peer range on [@sap/cds](artifact:sap-cds) and publishes no repository, so there is nothing to read but the package itself and no CI to look at.

The declared repository is archived.

Nothing about it is readable from outside the package: there is no repository, no issue tracker, and the npm page carries no readme, so the README, the examples and the changelog can be read only from the tarball or a CDN mirror, and a bug has nowhere to be filed. Provider URLs are called from the plugin with API keys taken from environment variables in a .env file, so on BTP no call resolves through a destination and the keys live in the environment. The npm line stops at 1.0.1 on 3 November 2025; the changelog shipped inside that version is headed v2.1, so the version npm shows and the version the author counts are not the same.

Release and repository quiet for 39 months.

Archived The declared repository is archived.

Functional boundary The repository is archived, so nothing here will move again. Fine to keep where it already runs; anything new should start from what the current cds deploy leaves open rather than from this.

It changes what DELETE means for every client of the annotated projection, so anything that must actually remove a row — an erasure request, a retention job — has to go around it.

Quiet Release and repository quiet for 57 months.

Functional boundary The package declares `@sap/cds` ^4.5.2 among its dependencies and pins `@sap-cloud-sdk/core` at 1.37.1, so a project on CAP 5 or later is outside the range it states.

Release and repository quiet for 46 months.

Release and repository quiet for 24 months.

Node below 22, or [@sap/cds](artifact:sap-cds) below 9: the package declares the first in engines and the second as a peer dependency. Any mail path other than Microsoft Graph, until a provider is written for it: graph is the only kind that sends, and basic, the kind configured by default, is the base class such a provider extends.

BUSL-1.1 rather than node-rfc's Apache-2.0, so a product you distribute has to be read against the licence and its Additional Use Grant first, and the source is closed: the GitHub repository is the issue tracker and the documentation, nothing else. `RfcServerOptions.bgRfcHandlers` raises instead of accepting handlers, so a server receiving inbound bgRFC units is outside what this does. An ABAP `MESSAGE`-raised failure still arrives with its T100 template rather than the rendered sentence, and the dump name is not reported as `key` for that case.

The maintainer states 0.x is beta with no production SLA, and scopes support deliberately narrowly: direct application-server transport, classic serialization and password authentication on S/4HANA 2023 and NetWeaver 7.50. Anything outside that is untested rather than unsupported.

If your tool reads the open skill standard directly, install [capire/skills](artifact:capire-skills) and skip the wrapper.

Not a substitute for testing in a system: the README states that any class calling the database, classic BAPIs or HTTP is shimmed out and stays an on-stack ATC and ABAP Unit concern, and that an off-stack green is CI-grade provenance rather than an in-system pass. It also assumes a particular shape of project. The ABAP has to be abapGit-serialised into a Git repository, Node.js 22 or later has to be available locally and in CI, and the CI has to be GitHub Actions.

Every skill that touches ABAP needs [arc-1](artifact:arc-mcp-arc-1) itself connected to a real system; nothing else is universal. `modernize-ui5-app` and `convert-ui5-to-fiori-elements` specifically need [the UI5 MCP server](artifact:ui5-mcp-server) for TypeScript conversion guidance and the linter, `convert-ui5-to-fiori-elements` also needs [the Fiori MCP server](artifact:sap-ux-fiori-mcp-server) for its LROP scaffold, and `modernize-ui5-app` needs a browser MCP (Claude in Chrome or Claude's own Preview) for its final render-verification step, since an HTTP 200 alone does not catch a blank page. A skill file alone, without the servers a given skill needs, has nothing to act on.

Not for a project below the 2211-jdk21.1 baseline: older releases and the JSP Accelerator are covered only as explicitly marked legacy material, so a JSP storefront or a pre-JDK-21 platform is outside what the guides are written against. Knowledge with reach only through one script — it can tell an agent what to write and, apart from `query-items.sh`, cannot let it read what a given system contains.

GPL-3.0, which is a licence to read before vendoring any of it into something you ship. Forty plugins is also a lot of always-available surface — the ledger is there because breadth and verification pull in opposite directions, and it does not resolve that so much as report it.

No public repository is declared on the package, so the README is the documentation.

It is text processing, not an agent: there is no tool calling, no retrieval and no conversation. It needs SAP AI Core, and the backend half needs [@sap-ai-sdk/orchestration](artifact:sap-ai-sdk-orchestration) installed alongside it — an optional peer, so a frontend-only install stays lean.

No public repository is declared on the package, so the README is the documentation.

It says so itself, in bold, and the atlas repeats it: not legal advice and not a compliance decision. Only SAP, your contract, or SAP support can answer bindingly, and the skill routes legal, commercial and roadmap questions there rather than guessing at them. Treat the output as evidence gathered, not as a verdict.

It stops at the `AuthInfo` and the raw bearer token, and the README lists what stays with the consuming server: rate limiting, the scope and tool policy, the MCP transport, the SAP HTTP client's headers, and helmet-style hardening. The one piece of hardening it constrains rather than defers is the cross-origin opener policy, which it deliberately leaves unset because popup-based OAuth breaks under it. It is ESM-only on Node 22 or later and shares the host's Express and MCP SDK instances as peer dependencies, so a server on Express 4 cannot take it.

The maintainer states it is unofficial, not endorsed by SAP, and that it automates authenticated SAP web endpoints and browser session cookies in ways SAP's terms of service or an organisation's own policies may restrict. Password login is confined to `accounts.sap.com` and the standard SAP Cloud Identity Services tenant domains: a custom IAS domain, or a login that conditional authentication delegates to a corporate identity provider, fails closed before the password is filled and has to be completed through an interactive login instead.

Last released January 2022 at 0.0.21, against a passport strategy Microsoft has since deprecated.

Last released April 2022 at 0.0.2, and no repository is declared on the package.

It is a bundle rather than a plugin with one job, and a single release from March 2026 — depending on it for the query helpers brings the auth and validation layers too.

Quiet Release and repository quiet for 25 months.

Functional boundary It performs no authentication flow of its own. The app must already be protected by Entra ID OAuth 2.0 at the App Service level; this only maps the resulting claims. It is explicitly not intended to run locally.

It is a bundle rather than a plugin with one job, and a single release from March 2026 — depending on it for the query helpers brings the auth and validation layers too.

Quiet Release and repository quiet for 30 months.

Functional boundary The annotation sits on a single element, so a rule that spans two fields, or one that needs a lookup, has nowhere in it to go.

Last released June 2022 at 0.0.6, and no repository is declared on the package.

Release and repository quiet for 43 months.

When user-dependent responses are cached without user-aware or explicit operation keys, or translated responses share keys across locales. These cases require key isolation; locale-aware keys are off by default.

It targets the Application Frontend service only — not the HTML5 application repository — fixes authentication to IAS, and always creates new service instances, so reusing existing ones means editing the generated `mta.yaml` afterwards. Version 0.1.0 is the only release.

Quiet Release and repository quiet for 75 months.

Functional boundary It supports Basic Authentication only, so a backend that needs another method is not reachable through it.

It records what the app actually asked for, so an entity no recorded journey touched is not in the dataset and replay will not answer for it. Its own README asks for `fiori-tools-appreload` to be disabled while recording, because a reload loop is what happens otherwise.

Release and repository quiet for 36 months.