Drop the cds add warning: 0.3.1 writes the project's module format

AGENTS.md

@@ -62,7 +62,7 @@ against the repos, don't guess):
 | [abap2UI5/abap2UI5](https://github.com/abap2UI5/abap2UI5) | the framework itself, in ABAP. Downported and transpiled, it is published as `@abap2ui5/node-runtime` |
 | [cap2UI5/docs](https://github.com/cap2UI5/docs) | this site |
 
-On npm since 2026-09-29: `@cap2ui5/cds-plugin@0.3.0` (Node ≥ 22, peer
+On npm since 2026-09-29: `@cap2ui5/cds-plugin@0.3.1` (Node ≥ 22, peer
 `@sap/cds` ≥ 9), published by the npm organisation `cap2ui5`, and
 `@cap2ui5/samples@0.1.0`. The plugin pins `@abap2ui5/node-runtime@1.145.0`
 (on npm since 2026-09-27) **exactly**. Up to 0.2.0 the plugin was the unscoped

docs/guide/ecosystem.md

@@ -31,7 +31,7 @@ abap2UI5 builds itself.
 | `@abap2ui5/node-runtime` | abap2UI5: upstream's ABAP, downported and transpiled over open-abap, with the UI5 frontend embedded in the page its GET answers with — backend and frontend from one commit |
 | `@cap2ui5/samples` | abap2UI5's samples as cap2UI5 apps. Optional: added to a project, they run beside its own apps — see [Apps from a package](./project-structure#apps-from-a-package) |
 
-All three are on npm: `@cap2ui5/cds-plugin` 0.3.0 (Node ≥ 22, `@sap/cds` ≥ 9 as a peer),
+All three are on npm: `@cap2ui5/cds-plugin` 0.3.1 (Node ≥ 22, `@sap/cds` ≥ 9 as a peer),
 `@abap2ui5/node-runtime` 1.145.0 (Node ≥ 22), which the plugin pins exactly,
 and `@cap2ui5/samples` 0.1.0. `npm add @cap2ui5/cds-plugin` installs the first two — see the
 [Quickstart](./getting-started). Up to 0.2.0 the plugin was the unscoped

docs/guide/getting-started.md

@@ -148,11 +148,8 @@ you.
 ::: details Or let `cds add cap2ui5` write a first app
 `cds add cap2ui5` creates `srv/apps/hello.js` in a project that has no apps
 yet: abap2UI5's hello world, `HELLO`, with its view built by
-`z2ui5_cl_ui5_view_builder` (see [Views](./views)). Plugin 0.3.0 writes that
-file with `require`, so in a project from `cds init --nodejs` rename it to
-`hello.cjs`, or change its `require` line to
-`import { defineApp, z2ui5_cl_ui5_view_builder } from "@cap2ui5/cds-plugin";`.
-It takes the app name `HELLO`, so use it instead of the file above, not beside it.
+`z2ui5_cl_ui5_view_builder` (see [Views](./views)), written with `import` in a
+project from `cds init --nodejs`. It takes the app name `HELLO`, so use it instead of the file above, not beside it.
 :::
 
 Four things worth knowing, and each of them is a rule rather than a style:

docs/guide/project-structure.md

@@ -47,9 +47,8 @@ call it more than once. A module that fails to load fails the start, as a
 service implementation does.
 
 `cds add cap2ui5` creates a first one, `srv/apps/hello.js`, when the directory
-has none. In 0.3.0 that file uses `require`, so in an ES module project — what
-`cds init --nodejs` creates — rename it to `hello.cjs`, or change its first
-line to `import { defineApp, z2ui5_cl_ui5_view_builder } from "@cap2ui5/cds-plugin";`.
+has none — with `import` or `require`, whichever module format the project's
+`package.json` declares.
 
 ```js
 // srv/apps/pick.js — two apps in one file is fine

docs/reference/configuration.md

@@ -102,7 +102,7 @@ run behind it under `xsuaa` and `ias` and not only under `mocked`.
 ## The runtime
 
 `@cap2ui5/cds-plugin` depends on `@abap2ui5/node-runtime` **pinned exactly** — `1.145.0`
-for 0.3.0 — so `npm add @cap2ui5/cds-plugin` already gives you one known
+for 0.3.1 — so `npm add @cap2ui5/cds-plugin` already gives you one known
 runtime release. There is nothing to add to your own `package.json`.
 
 The runtime resolves as the plugin's own dependency, at the pinned version.

docs/reference/deployment.md

@@ -37,12 +37,12 @@ then `cds deploy` once. `cap2ui5.Drafts` is created along with your own tables.
 | **The entity** | `cap2ui5.Drafts` deploys through your normal `db` module, HDI container included. Nothing special |
 | **Authentication** | whatever `cds.requires.auth` is — the route runs behind CAP's own chain. Verified for `jwt`, `xsuaa` and `ias`, not only for the development kinds |
 | **Scaling** | app state is in the database, not in memory, so a second instance is a second instance. No sticky sessions, no shared cache |
-| **The runtime** | `@cap2ui5/cds-plugin` pins `@abap2ui5/node-runtime` exactly (`1.145.0` for 0.3.0). Commit your `package-lock.json` and a redeploy installs the same release |
+| **The runtime** | `@cap2ui5/cds-plugin` pins `@abap2ui5/node-runtime` exactly (`1.145.0` for 0.3.1). Commit your `package-lock.json` and a redeploy installs the same release |
 
 ## Pin the plugin
 
 ```json
-{ "dependencies": { "@cap2ui5/cds-plugin": "^0.3.0" } }
+{ "dependencies": { "@cap2ui5/cds-plugin": "^0.3.1" } }
 ```
 
 `@cap2ui5/cds-plugin` is on npm, and it depends on one exact `@abap2ui5/node-runtime`
@@ -101,7 +101,7 @@ With that route **every roundtrip is refused**. `@sap/approuter` requires an
 authenticated route whose `csrfProtection` is not `false`, and answers
 `403` with `x-csrf-token: Required` otherwise (read in approuter 23.0.0,
 `lib/middleware/xsrf-token-handler.js`). The abap2UI5 frontend up to and
-including runtime `1.145.0` — the release `@cap2ui5/cds-plugin` 0.3.0 pins — sends no
+including runtime `1.145.0` — the release `@cap2ui5/cds-plugin` 0.3.1 pins — sends no
 such token. The first page loads, because it is a GET; the first click fails.
 
 What works today is a route for the roundtrip path **in front of** the