@open-rap/compiler 0.1.2 → 0.2.0

package/docs/AGENTS.md

@@ -9,7 +9,7 @@ writes an `AGENTS.md` in the projects it creates.
 A TypeScript compiler (pnpm monorepo) that turns the sources of a RAP BO (abapGit format) into a
 Node.js application: OData V4, RAP managed runtime, ABAP transpiled by abaplint, PostgreSQL,
 OpenUI5 UI. Read [README.md](README.md), [docs/GUIDE.md](docs/GUIDE.md) and the list of decisions
-[docs/DECISIONS.md](docs/DECISIONS.md) (D1 to D71) first.
+[docs/DECISIONS.md](docs/DECISIONS.md) (D1 to D78) first.
 
 ```
 packages/model/      types of the IR (model.json) and shared derivations (OData, value helps, MCP)
@@ -37,6 +37,8 @@ npx vitest run packages/compiler/test/ui.test.ts      # one file
 node packages/compiler/dist/cli.js check fixtures/travel
 node packages/compiler/dist/cli.js dev fixtures/travel --port 8081
 node scripts/build-site.mjs _site                     # the website, with the documentation pages
+pnpm changeset      # the changeset of a pull request: the bump and its line in the changelog (D77)
+pnpm check:version  # one version in every file that carries it
 ```
 
 The runtime tests import the built `@open-rap/compiler`: run `pnpm build` before running them
@@ -64,6 +66,11 @@ after a change to the compiler.
    names, pull requests (title, description, review comments), issues and release notes.
 9. **Generated files**: never edit `.rapt/`, `dist/`, `packages/compiler/docs/`, nor the virtual
    objects `<standard>/…` (standard views, D44).
+10. **Versions** (D77): never change a version by hand. A pull request that changes what ships
+    (sources of a package, `docs/`, the dependencies of a published package) adds a changeset
+    (`pnpm changeset`: `patch` for a fix, `minor` for a feature; one line in English for the
+    changelog), or `pnpm changeset add --empty` when it must not be released; the CI checks it.
+    The *Version packages* pull request bumps the versions, its merge releases.
 
 ## Adding a feature, in practice
 

package/docs/DECISIONS.md

@@ -1321,7 +1321,9 @@ correspond to points 1 to 13 of §11 of PLAN.md. The milestones M1 to M6 are tho
   runs `rapt --help`, `rapt check` and `rapt build` of the fixture; then, when the secret
   `NPM_TOKEN` is set, publishes them (`workspace:*` becomes the version of the tag). npm
   provenance is added when the repository is public. Once: create the `open-rap-runtime`
-  organization on npmjs.com and the `NPM_TOKEN` secret ([DEPLOYMENT.md](DEPLOYMENT.md)). The name
+  organization on npmjs.com and the `NPM_TOKEN` secret ([DEPLOYMENT.md](DEPLOYMENT.md)).
+  *Since D77 and D78: the version is the committed one, and npm trusts the workflow by trusted
+  publishing, without `NPM_TOKEN`.* The name
   `rapt` is taken on npm, hence `open-rap-runtime`.
 - **Why**: the same CLI everywhere; CI can check RAP sources without VS Code; a terminal agent
   can install it in one command.
@@ -1582,3 +1584,147 @@ _The issues moved to the repository itself once public: see D74._
   `open-rap-runtime-feedback` points to the new place; its issues stay readable. The rest of D71
   holds (fields filled from the query string, version and environment from the extension).
 - **Tests**: `compiler/test/docs.test.ts` (no link to the former name of the repository).
+
+## D75 — The launchpad of the workspace in development
+
+- **Context**: `rapt dev` runs one application with its development launchpad (D49); with several
+  applications in a workspace (D69), the launchpad with all of them only existed as a build
+  (`rapt launchpad`, then Docker). The commands of the extension were also active when they could
+  not work (open the application before it serves, stop without a session).
+- **Decision**: `rapt launchpad dev <launchpad.json> [--port 8090] [--host] [--json]` starts a
+  `rapt dev` session for each application with `source`, on the port of its `url`, and serves the
+  launchpad (its configuration resolved from the models of the sessions) on port 8090. The
+  launchpad waits until every application is built, then follows their rebuilds; a change of
+  `launchpad.json` adds, removes or restarts the sessions and regenerates the launchpad. Checks
+  (LPD010): an application with `build` is not started (warning); a URL that is not local or
+  without a port, a port taken twice or by the launchpad, no application with sources are errors.
+  The files go to `.rapt/launchpad` next to `launchpad.json`. In VS Code, *RAP: Start the
+  launchpad (rapt dev, all the applications)* (palette, context menu and title bar of
+  `launchpad.json`, view of the RAP objects) asks for the missing floorplans then runs it. The
+  extension keeps a single session: starting an application or the launchpad stops the other,
+  since both use the same `.rapt/dev` and ports. Context keys `rapt.devRunning`, `rapt.devReady`
+  and `rapt.devMode` grey out *Open the application* until the session serves and *Stop* without
+  a session; the launchpad commands need an application or a `launchpad.json`
+  (`rapt.hasApp || rapt.hasLaunchpad`). The roots of the sessions are real paths (no Windows 8.3
+  short name, which `fs.watch` does not support). The regenerations run one at a time; one that
+  throws (a file that cannot be written) is reported (`launchpad-failed`) and the next change of
+  `launchpad.json` or of an application tries again.
+- **Why**: the launchpad is how the applications of a workspace are used together (navigation,
+  counters); developing them one at a time hides the result, and Docker is too slow for each save.
+- **Tests**: `compiler/test/launchpad-dev.test.ts` (plan and LPD010, an application behind the
+  launchpad, regeneration on a change of `launchpad.json`, ports freed on close, a launchpad that cannot be
+  written then generated on the next change),
+  `vscode/test/rapt.test.ts` (context keys, arguments of the sessions).
+
+## D76 — A Web API or a Fiori application: chosen at the creation, kept out of the launchpad
+
+- **Context**: what makes a service a Web API is the type of its service binding (*OData V4 -
+  Web API*, `BINDING_TYPE_CATEGORY` 1, D60). `rapt new` and *New complete business object…* only
+  created UI bindings; a Web API was made by hand (`rapt generate binding --binding-type
+  webapi`) and was then added to the launchpad like an application: a tile with no UI behind it,
+  and a floorplan asked for nothing. A service with both a UI and a Web API binding, common on
+  SAP, built the first one found (SRVD002).
+- **Decision**: the type of the binding stays the only source of truth, as on SAP; it is chosen
+  at the creation and respected everywhere.
+  - **Creation**: `rapt new <src> <Entity> --binding-type webapi` (VS Code: *New complete
+    business object…* asks "Fiori application (UI)" or "Web API" first; `rapt agent`:
+    `bindingType` of `rapt_new_business_object`) writes the service and binding with the names
+    of SAP for an API (`ZRT_API_TRAVEL`, `ZRT_API_TRAVEL_O4`, category 1), no metadata extension
+    (nor `@Metadata.allowExtensions`), and does not add the project to the launchpad.
+  - **Launchpad**: `rapt launchpad add` (and the extension, which adds the applications of the
+    workspace before building or starting the launchpad) leaves a Web API out: `webApi: true`,
+    `added: false`, no error, `launchpad.json` not created for it. A tile of `launchpad.json` on
+    a Web API is left out of the launchpad with the warning **LPD011**; the application itself
+    can stay in `apps` (built and served behind the launchpad, at its service path).
+  - **Floorplan**: `rapt floorplan` lists no entity set for a Web API (`webApi: true`), and
+    refuses to set one; the extension says so instead of asking.
+  - **Two bindings**: `--binding <name>` designates one of the bindings of the service (its type
+    with it); without it, the UI binding is preferred over the Web API ones, with SRVD002 as an
+    info naming the other one; several UI bindings remain a SRVD002 warning.
+  - **RAP Objects view**: each service binding shows its kind, `UI` or `Web API`.
+  - **A binding alone**: the catalog of `rapt generate` gives each value of `--binding-type` its
+    meaning (`labels`: "UI: a Fiori application, in the launchpad", "Web API: for other systems,
+    without UI, not in the launchpad"), shown by the wizard *New RAP object…*, whose *Complete
+    business object* also asks it (*Service*). The quick picks (*New RAP object (quick
+    picks)…*) ask the type of a binding too. The proposed name follows the service definition
+    and the type, as SAP names them (`ZRT_UI_TRAVEL` → `ZRT_UI_TRAVEL_O4` or
+    `ZRT_API_TRAVEL_O4`, `ZUI_ORDER` → `ZAPI_ORDER_O4`), until the user types one.
+- **Why**: the choice is made where the developer thinks about it (what is the service for?),
+  the result activates on SAP as is, and the launchpad never shows a tile that cannot open.
+- **Tests**: `compiler/test/web-api-app.test.ts` (names, files, model, floorplan, rapt new and
+  rapt launchpad add, LPD011, the choice between two bindings), `compiler/test/agent.test.ts`
+  (`bindingType`), `vscode/test/rapt.test.ts` (arguments of rapt new and of the wizard, names of
+  a binding, kind of a binding, notice), `vscode/test/wizard.test.ts` (the page of the wizard in
+  a browser: labels, proposed names, answers).
+
+## D77 — Versions and releases by Changesets
+
+- **Context**: a release meant changing the version by hand in seven files (the five
+  `package.json`, `RUNTIME_VERSION`, the generator of the reference snapshot), then running the
+  Release workflow with the same version; nothing tied a change to its version, and there was no
+  changelog. LISA, another repository of the maintainer, releases with Changesets.
+- **Decision**: [Changesets](https://github.com/changesets/changesets) (`@changesets/cli`, MIT),
+  as in LISA, with one version for the five packages (a `fixed` group; the VS Code extension is
+  private: versioned, never published to npm by Changesets).
+  - **Each pull request** that changes what ships adds a changeset (`pnpm changeset`). What
+    ships (`scripts/lib/versions.mjs`): the sources of a package (not its tests), the grammars
+    and build scripts of the extension, `docs/` (copied into the compiler), the installed fields
+    of a published `package.json` (dependencies, `bin`, `exports`, `contributes`…). The CI
+    refuses a pull request without one (`scripts/require-changeset.mjs`); `pnpm changeset add
+    --empty` declares a change that must not be released; the Version packages pull request,
+    and a pull request that bumps the version itself, are exempt.
+  - **On `main`**, the *Changesets* workflow (`changesets/action`) keeps the *Version packages*
+    pull request up to date: `pnpm changeset:version` bumps the packages, writes their
+    `CHANGELOG.md`, copies the version into the files that carry it
+    (`scripts/sync-versions.mjs`), updates the lockfile and checks the result.
+  - **Its merge releases**: without pending changesets, `scripts/release-version.mjs` tags the
+    committed version `vX.Y.Z` on the merge commit (when not tagged yet, nor being released) and
+    runs `release.yml` on the tag. Unlike LISA, no GitHub App is needed for that: the tag is
+    created with the `GITHUB_TOKEN` (it does not start the tag trigger, so no second run) and the
+    `workflow_dispatch` it sends does start the workflow. An optional App gives the CI to the
+    Version packages pull request.
+  - **One version everywhere**: `pnpm check:version` (CI) fails on a drift; `release.yml` checks
+    that the tag is the committed version instead of writing the version at release time. The
+    notes of the GitHub release are the sections of the version in the changelogs, merged
+    (`scripts/release-notes.mjs`).
+- **Why**: the only human step of a release is merging a pull request that shows the version and
+  its changelog; a change cannot be merged without saying whether and how it is released; the
+  version can no longer differ between the files.
+- **Tests**: `scripts/lib/versions.test.mjs` (the files of the version, `sync-versions.mjs` and
+  `check-version-sync.mjs` with a tag, what ships, changesets, the notes merged from several
+  changelogs); `changeset version` checked on a copy of the repository (the five packages bumped
+  together, the mirrors copied).
+
+## D78 — Publishing without tokens: trusted publishing
+
+- **Context**: `release.yml` published with three long-lived secrets (`NPM_TOKEN`, `VSCE_PAT`,
+  `OVSX_PAT`). A stolen token publishes anything, until someone revokes it; the tokens also
+  expire and have to be renewed. LISA already publishes to npm by trusted publishing.
+- **Decision**: every registry trusts the workflow `release.yml` of this repository by OIDC;
+  the jobs have `id-token: write` and no secret.
+  - **npm**: npm 11.21.1 (trusted publishing needs 11.5.1 or later; Node.js 22 comes with npm
+    10), without `registry-url` in `setup-node` (it writes an `.npmrc` waiting for a token).
+    The four archives already checked (`pnpm pack`: `workspace:*` replaced by the version) are
+    published by `npm publish <archive>`: npm exchanges the identity token, pnpm does not. The
+    provenance is attested automatically. A version already on npm is skipped.
+  - **Visual Studio Marketplace**: `vsce publish --oidc` (`@vscode/vsce` 4.1.0, which also builds
+    the `.vsix`), with `--skip-duplicate`; the publisher declares a Trusted Publishing policy. The
+    extension is published by the publisher `abaper` of the maintainer (it was `clementringot`
+    in `package.json`, a publisher that does not exist on the Marketplace): its ID becomes
+    `abaper.open-rap-runtime-vscode`.
+  - **Open VSX**: `ovsx publish --trusted-publishing` (`ovsx` 1.3.0, run by `npx` in the CI
+    only: EPL-2.0, never distributed), with `--skip-duplicate`; the namespace `abaper` declares
+    its trusted publisher.
+  - The Marketplace and Open VSX steps run when the repository variables
+    `PUBLISH_VS_MARKETPLACE` and `PUBLISH_OPEN_VSX` are `true`, so that a release does not fail
+    before their trusted publisher is declared. npm and the GitHub release always run.
+  - The only stored credential left is the private key of the GitHub App of the release train
+    (D77), which only opens the Version packages pull request.
+- **Why**: nothing to steal nor to renew; a version can only come from this workflow on this
+  repository, which the npm provenance shows; the release can be re-run (each registry skips a
+  version it has).
+- **Tests**: the `.vsix` built with `@vscode/vsce` 4.1.0 (the embedded `rapt` checks the
+  fixture); the options `--oidc` (`vsce`) and `--trusted-publishing` (`ovsx`) checked in the help
+  of the pinned versions; the workflow runs on the next release (npm needs its trusted publisher
+  declared first, [DEPLOYMENT.md](DEPLOYMENT.md)).
+

package/docs/DEPLOYMENT.md

@@ -86,28 +86,72 @@ HTTPS address.
 
 ## Publishing a version of Open RAP Runtime (maintainers)
 
-A tag `v1.2.3` runs `release.yml`: the VS Code extension (GitHub release, Marketplace with the
-`VSCE_PAT` secret, Open VSX with `OVSX_PAT`) and the CLI on npm ([D65](DECISIONS.md)):
-`open-rap-runtime` (the `rapt` command), `@open-rap/model`, `@open-rap/compiler` and
-`@open-rap/runtime`, all in version 1.2.3.
-
-Once, for npm:
-
-1. Create the organization **`open-rap`** on npmjs.com (free for public packages): it
-   holds the `@open-rap` scope.
-2. Create a *Granular Access Token* (*Read and write*, packages `open-rap-runtime` and scope
-   `@open-rap`, or the whole organization) and save it as the **`NPM_TOKEN`** secret of the
-   repository (*Settings → Secrets and variables → Actions*).
-
-Without `NPM_TOKEN`, the `npm` job builds and checks the packages (archives of `pnpm pack`
-installed by npm, `rapt check` and `rapt build` of the fixture) but publishes nothing. npm
-provenance (the link between the package and the workflow) is added when the repository is
-public.
+The versions are managed by [Changesets](https://github.com/changesets/changesets)
+([D77](DECISIONS.md)). The five packages — `open-rap-runtime` (the `rapt` command),
+`@open-rap/model`, `@open-rap/compiler`, `@open-rap/runtime` and the VS Code extension — share
+one version.
+
+1. **Each pull request** that changes what ships (the sources of a package, `docs/`, the
+   dependencies of a published package) adds a changeset: `pnpm changeset`, the bump (`patch`
+   for a fix, `minor` for a feature, `major`) and one line for the changelog. A change that must
+   not be released records it with `pnpm changeset add --empty`. The CI refuses a pull request
+   without one (`scripts/require-changeset.mjs`).
+2. **On `main`**, the *Changesets* workflow (`.github/workflows/changesets.yml`) keeps a
+   *Version packages* pull request open: the next version of the five packages, their
+   `CHANGELOG.md`, and the version copied into `RUNTIME_VERSION` and the reference snapshot
+   (`pnpm changeset:version`).
+3. **Merging the Version packages pull request** releases: the workflow tags the version
+   `vX.Y.Z` on the merge commit and runs `release.yml` on the tag — the VS Code extension (GitHub
+   release with the `.vsix` and the notes of the changelogs, the Visual Studio Marketplace, Open
+   VSX), the CLI on npm ([D65](DECISIONS.md)), then the website.
+
+`pnpm check:version` checks that every file carries the same version (the CI runs it), and
+`release.yml` refuses a tag that is not the committed version.
+
+### No token: trusted publishing ([D78](DECISIONS.md))
+
+The repository stores no token for the registries. `release.yml` asks GitHub for an identity
+token of the job (`id-token: write`); each registry exchanges it for a short-lived credential,
+provided this repository and the workflow file `release.yml` are declared as its trusted
+publisher. To set up once:
+
+- **npm** — for each of the four packages (`open-rap-runtime`, `@open-rap/model`,
+  `@open-rap/compiler`, `@open-rap/runtime`): npmjs.com → the package → *Settings* →
+  *Trusted Publisher* → *GitHub Actions*: owner `ClementRingot`, repository
+  `Open-RAP-Runtime`, workflow `release.yml`, no environment. npm then attests the provenance
+  of each version. Then, in *Settings* → *Publishing access*, the packages can refuse tokens
+  (*Require two-factor authentication and disallow tokens*), and the `NPM_TOKEN` secret is
+  deleted.
+- **Visual Studio Marketplace** — in the management page of the publisher `abaper`, a
+  *Trusted Publishing* policy for this repository and `release.yml`; then the repository
+  variable **`PUBLISH_VS_MARKETPLACE`** = `true` (*Settings → Secrets and variables → Actions →
+  Variables*), and the `VSCE_PAT` secret is deleted.
+- **Open VSX** — on open-vsx.org, the trusted publisher of the namespace `abaper` for this
+  repository and `release.yml` (the Eclipse publisher agreement signed); then the variable
+  **`PUBLISH_OPEN_VSX`** = `true`, and the `OVSX_PAT` secret is deleted.
+
+Without the variable, the Marketplace or Open VSX step is skipped; the GitHub release and npm
+are always published. A version already on a registry is skipped (`--skip-duplicate`, `npm
+view`), so a failed release is simply re-run.
+
+The only stored credential is the private key of the **GitHub App** of the release train
+(variable `RELEASE_APP_ID`, secret `RELEASE_APP_PRIVATE_KEY`, as in LISA): with it, the Version
+packages pull request is opened by the App and the CI runs on it. Without it, the train still
+works with the `GITHUB_TOKEN`, and the CI only runs once the pull request is merged.
+
+By hand, for a release the train did not start: *Actions → Release → Run workflow* with the
+committed version (`0.2.0`), or `git tag v0.2.0 && git push origin v0.2.0` on the commit of that
+version.
+
+To build the `.vsix` locally:
 
 ```sh
-git tag v0.1.0 && git push origin v0.1.0
+pnpm install && pnpm build
+cd packages/vscode && pnpm run package    # open-rap-runtime-vscode.vsix (~31 MB)
 ```
 
-Or without a tag: *Actions → Release → Run workflow* with the version (`0.1.0`); the release then
-creates the tag `v0.1.0` on the commit of the run.
+`pnpm run package` compiles the extension (esbuild), prepares `rapt/`
+(`scripts/stage-rapt.mjs`: packages of the repository and dependencies installed from the npm
+registry, useless files removed), then calls `vsce package`.
+
 

package/docs/DIAGNOSTICS.md

@@ -8,7 +8,7 @@ exit code is 1 as soon as there is an error (or a warning with `--warnings-as-er
 | PRJ001 | error | No service definition, or several without `--service` |
 | PRJ002 | error | The requested service definition does not exist |
 | SRVD001 | error | Syntax error in a service definition |
-| SRVD002 | warning | Several bindings for the service |
+| SRVD002 | info / warning | Several bindings for the service: a UI binding and Web API ones, the UI one is built (info, D76); otherwise the first one (warning); `--binding <name>` chooses |
 | SRVD003 | warning | Binding that is not OData V4 |
 | SRVD004 | error | Entity set exposed twice |
 | SRVD005 | error | Exposed entity not found |
@@ -105,6 +105,8 @@ exit code is 1 as soon as there is an error (or a warning with `--warnings-as-er
 | LPD007 | warning | Role of a tile missing from the `rapt/authorizations.json` of the applications (the IdP must still give it) |
 | LPD008 | error | Malformed space or page in `launchpad.json` (title, pages, sections, roles) (D48) |
 | LPD009 | error | Malformed `source` application (not a path, or with `build`), folder not found, or application that does not build with the launchpad (D69) |
+| LPD010 | error / warning | `rapt launchpad dev`: application without a local `url` with a port, port taken by another application or by the launchpad, no application with sources (errors); application without sources, not started (warning) (D75) |
+| LPD011 | warning | Tile of an application that is an OData V4 - Web API (no UI): the tile is left out (D76) |
 | SEED001 | error | Unreadable or malformed `rapt/seed.json` (object table → array of rows expected) |
 | SEED002 | error | `rapt/seed.json`: table or field unknown to the application |
 | NR001 | error | Unreadable or malformed `rapt/number-ranges.json`: object longer than 10 characters, interval longer than 2 characters, non-numeric or inverted bounds |

package/docs/FEATURES.md

@@ -211,6 +211,7 @@ dependent ETag, remote APIs.
 | `sap-*` parameters | ✅ | Ignored. |
 | Authentication: dev mode, Bearer JWT (OIDC, JWKS) | ✅ | Browser sessions (PKCE): M6; *client credentials* tokens (technical user); development OAuth 2.0 server (`/oauth`, client credentials and PKCE) in `rapt dev` (D60). |
 | *OData V4 - Web API* binding | ✅ | Without UI annotations, value helps, side effects, feature control; active instances of a draft BO (D60). |
+| A Web API created as such (`rapt new --binding-type webapi`, *New complete business object…*), kept out of the launchpad; the UI binding preferred when a service has both | ✅ | D76; LPD011, SRVD002. |
 | `$apply`: `filter`, `groupby`, `aggregate` (`sum`, `min`, `max`, `average`, `countdistinct`, `$count`) | ✅ | With the DCL of the user; other transformations: 501 (D52). |
 | Enumeration types (`EnumType`): JSON by member name, literals `Ns.Type'M'` | ✅ | `enhanced` mode, CDS enumerated types (D55). |
 | JSON batch, `$value`, single properties | ❌ | Not in the MVP. |
@@ -255,6 +256,8 @@ dependent ETag, remote APIs.
 | Docker: launchpad, applications and their databases, Keycloak (`oidc` profile) | ✅ | Generated `docker-compose.yml`. |
 | Spaces and pages (`spaces` → `pages` → `sections`), assigned to roles | ✅ | Space tabs, list of the pages, last space remembered (D48). |
 | Development launchpad (`rapt dev`): application, documentation, `$metadata`, MCP | ✅ | D49. |
+| Launchpad of the workspace in development (`rapt launchpad dev`, *RAP: Start the launchpad*): every application rebuilt on save, behind the launchpad | ✅ | D75; LPD010. |
+| Web APIs never in the launchpad: not added, their tiles left out | ✅ | D76; LPD011. |
 | One "Launchpad" per workspace, applications added when they are created (`rapt new`, `rapt floorplan`, `rapt launchpad add`) | ✅ | D69; idempotent, `--launchpad`, `--no-launchpad`. |
 | Applications built with the launchpad from their sources (`source`); deployment of the complete launchpad or of one application alone | ✅ | D69; `out/launchpad/apps/<id>`, LPD009. |
 | Personalization by the user, notifications, navigation between applications from an application | ❌ | See KNOWN_GAPS. |
@@ -282,6 +285,7 @@ dependent ETag, remote APIs.
 | VS Code extension: commands of the CLI, Problems, wizard, *RAP Objects* view, floorplans | ✅ | D39, D61. |
 | `rapt` on the PATH of the terminals of VS Code | ✅ | Shims of the extension (D64). |
 | MCP server of rapt for AI coding agents (`rapt agent`), registered in the agent mode of VS Code | ✅ | Check, objects, floorplans, abapGit, documentation (D64). |
-| npm package `open-rap-runtime` (`rapt`, `npx open-rap-runtime`) | ✅ | D65; archives of `pnpm pack` checked on each tag before publication with `NPM_TOKEN`. |
+| npm package `open-rap-runtime` (`rapt`, `npx open-rap-runtime`) | ✅ | D65; archives of `pnpm pack` checked on each release before publication. |
+| Releases by Changesets (*Version packages* pull request, changelogs) and trusted publishing to npm, the Marketplace and Open VSX, without stored tokens | ✅ | D77, D78. |
 | Website with the documentation | ✅ | D62, D63. |
 | Feedback form (website, *RAP: Report a bug or request a feature…*) to the issues of the repository | ✅ | D71, D74. |

package/docs/GUIDE.md

@@ -35,12 +35,13 @@ nothing else to install), then in the command palette (`Ctrl+Shift+P`):
 
 | Command | Effect |
 |---|---|
-| *RAP: New complete business object…* | `rapt new`: a complete managed BO (table, CDS, BDEF, behavior pool, service, binding), with initial data; possible in an empty folder |
+| *RAP: New complete business object…* | `rapt new`: a complete managed BO (table, CDS, BDEF, behavior pool, service, binding), with initial data; possible in an empty folder. It first asks what the service is for: a Fiori application (UI) or a Web API for other systems ([D76](DECISIONS.md)) |
 | *RAP: New RAP object…* | create object by object with the wizard, like *New ABAP Repository Object* of ADT: the types by category (Dictionary, Core Data Services, Behavior, Business Services, Source Code Library), a filter, a description, the fields of the type (source object, exposed entities, binding type…) |
 | *RAP: Choose the floorplan of the application…* | `rapt floorplan`: List Report, Worklist, Analytical List Page or Form Entry, with what each one needs; asked anyway before the first generation |
 | *RAP: Show the intermediate representation* | `rapt ir`: the model (`model.json`) in an editor |
 | *RAP: Build the launchpad (all the applications)…* | `rapt launchpad`: the launchpad of the workspace and all its applications ([D69](DECISIONS.md)) |
 | *RAP: Start rapt dev* | builds, starts and opens the development launchpad; restarts on each save |
+| *RAP: Start the launchpad (rapt dev, all the applications)* | `rapt launchpad dev`: every application of the launchpad in development, behind the launchpad ([D75](DECISIONS.md)) |
 | *RAP: Check the BO* | `rapt check`: diagnostics in the Problems tab (also on each save) |
 | *RAP: Build the application…* | either the **launchpad with all the applications** (`rapt launchpad`) or the **application alone** (`rapt build`, standalone) |
 | *RAP: Generate the abapGit files* | `rapt abapgit`: the missing XML files for the import into SAP |
@@ -58,7 +59,8 @@ chosen: the extension asks for it when it was not ([D66](DECISIONS.md)).
 The **RAP Objects** view of the explorer arranges the objects of the project like the project
 explorer of ADT (dictionary, data definitions, metadata extensions, access controls, behavior
 definitions, services, classes); its title bar creates an object, checks the project and starts
-`rapt dev` ([D61](DECISIONS.md)).
+`rapt dev` ([D61](DECISIONS.md)). Each service binding shows its kind, `UI` or `Web API`
+([D76](DECISIONS.md)).
 
 Syntax highlighting covers ABAP, CDS (DDLS, DDLX, DCL, SRVD, tables, types) and BDEF.
 
@@ -385,7 +387,8 @@ for the file in the project then its parent folders (up to the root of the git r
 otherwise creates it in the parent folder of the project; `--launchpad <file>` designates
 another one, `--no-launchpad` adds nothing. The VS Code extension puts it next to the
 `.code-workspace` (or in the first folder of the workspace). An application already present is
-never changed: titles, tiles and roles are edited by hand.
+never changed: titles, tiles and roles are edited by hand. A Web API is never added: it has no
+UI to open, and a tile on one is left out (LPD011, [D76](DECISIONS.md)).
 
 ```
 rap-apps/
@@ -426,6 +429,15 @@ separately. The content is organized in groups, or in **spaces and pages** ([D48
 }
 ```
 
+**The launchpad in development** ([D75](DECISIONS.md)): `rapt launchpad dev launchpad.json`
+starts `rapt dev` for each application with sources (`source`), each on the port of its `url`
+(`http://localhost:8081/`…), and the launchpad in front of them on `http://localhost:8090/`
+(`--port`, `--host`). Each save rebuilds its application; a change of `launchpad.json` updates
+the launchpad, starts the added applications and stops the removed ones. The applications with
+`build` are not started (LPD010 warning); two applications on the same port, or an application
+without a local port, are errors (LPD010). `--json` writes one event per line, with the `app`
+of the application.
+
 ## 10. Shipping
 
 Two ways to deploy ([D69](DECISIONS.md)):
@@ -466,12 +478,13 @@ Dockerfile, docker-compose.yml, keycloak/, manifest.yml   container, PostgreSQL,
 | `rapt check <src>` | diagnostics (`file:line:column: severity CODE message`), exit code 1 on error |
 | `rapt build <src> --out <dir>` | generated application |
 | `rapt dev <src>` | development loop |
-| `rapt new <src> <Entity> [--prefix ZRT] [--description …]` | complete BO, added to the launchpad of the workspace |
+| `rapt new <src> <Entity> [--prefix ZRT] [--description …] [--binding-type webapi]` | complete BO, added to the launchpad of the workspace; with `--binding-type webapi`, a Web API (no UI, not in the launchpad) |
 | `rapt generate <src> <type> <name> [--from X] [--for Y] [--expose A,B] [--root]` | one object |
 | `rapt floorplan <src> [<EntitySet> <floorplan>]` | floorplan of a root entity set; the application is added to the launchpad |
 | `rapt abapgit <src> [--check]` | missing abapGit XML files |
 | `rapt mcp <src>` | MCP tools (`rapt/mcp.json`) |
 | `rapt launchpad <launchpad.json> --out <dir>` | launchpad, and the applications of their sources (`source`) |
+| `rapt launchpad dev <launchpad.json> [--port 8090]` | development loop of all the applications of the launchpad, behind it |
 | `rapt launchpad add <src> [--launchpad f]` | adds the application to the launchpad of the workspace (created when missing) |
 | `rapt ir <src> [--out f]` | intermediate representation (JSON) |
 | `rapt agent [<workspace>]` | MCP server (stdio) of rapt for AI coding agents (§13) |
@@ -508,6 +521,27 @@ A service bound as *OData V4 - Web API* (`BINDING_TYPE_CATEGORY` 1 in the SRVB,
 `rapt generate . binding ZAPI_TRAVEL_O4 --for ZUI_TRAVEL --binding-type webapi`) has neither UI
 nor UI annotations; a draft BO only exposes its active instances there ([D60](DECISIONS.md)).
 
+**A Web API or a Fiori application** ([D76](DECISIONS.md)): the type of the service binding
+decides, as on SAP. Choose it when the business object is created: *RAP: New complete business
+object…* asks "Fiori application (UI)" or "Web API" first; on the command line,
+`rapt new my-api Partner --prefix ZPA --binding-type webapi` writes `ZPA_API_PARTNER` and its
+binding `ZPA_API_PARTNER_O4` (category 1), without metadata extension. A Web API:
+
+- is never added to the launchpad of the workspace (`rapt new`, `rapt launchpad add`, the
+  launchpad commands of VS Code); a tile written by hand on one is left out (LPD011);
+- has no floorplan (`rapt floorplan` lists none, VS Code does not ask);
+- shows `Web API` next to its binding in the *RAP Objects* view.
+
+A binding alone is created the same way: *New RAP object… > Service binding* (or the quick
+picks) asks its type, UI or Web API, and proposes the name SAP would give (`ZRT_UI_TRAVEL_O4`,
+`ZRT_API_TRAVEL_O4`); on the command line, `rapt generate . binding ZRT_API_TRAVEL_O4 --for
+ZRT_UI_TRAVEL --binding-type webapi`.
+
+A service can have both bindings, as on SAP: `rapt dev` and the launchpad serve the UI one
+(SRVD002 info), `rapt dev . --binding ZPA_API_PARTNER_O4` the Web API. To turn an application
+into a Web API, change `BINDING_TYPE_CATEGORY` of its binding to `1` (or add a Web API binding
+with *New RAP object… > Service binding*).
+
 In development, `rapt dev` serves an OAuth 2.0 server under `/oauth`:
 
 ```sh

package/docs/KNOWN_GAPS.md

@@ -178,6 +178,7 @@ Reference versions: `@abaplint/core` 2.120.98, `@abaplint/transpiler` 2.14.24,
 |---|---|
 | Development OAuth server | Development only: no refresh token, nor consent, nor revocation; signing key regenerated on each start. |
 | Web API of a draft BO | Active instances only (the draft is not exposed). |
+| Service with a UI and a Web API binding | One binding served at a time: the UI one by default, the Web API with `rapt dev --binding <name>` (D76). On SAP, both are published. |
 | OData V2 | Not supported: the generated service is always OData V4 (SRVD003). |
 
 ## Enhanced mode (D45)

package/docs/README.md

@@ -63,6 +63,8 @@ rapt dev my-project                         # http://localhost:8080/ — rebuilt
   files for the import into SAP).
 - **Development loop** `rapt dev`: embedded database, rebuild on each save, positioned
   diagnostics (`file:line:column`), development launchpad with the built-in documentation.
+  `rapt launchpad dev launchpad.json` does the same for every application of the workspace, each
+  on the port of its URL, behind the launchpad (`http://localhost:8090/`).
 - **Modes**: `standard` (strictly as on SAP, activatable on SAP) or `enhanced` (extensions:
   mandatory fields checked automatically, managed BO on a custom entity, CDS enumerated types
   exposed as OData `EnumType`).
@@ -81,7 +83,11 @@ rapt dev my-project                         # http://localhost:8080/ — rebuilt
   by the database view.
 - **Security**: OIDC (Keycloak, SAP Cloud Identity Services, Entra ID…), Web API bindings with
   OAuth 2.0 (client credentials, PKCE), authorization objects and `AUTHORITY-CHECK`, DCL, roles.
-- **One launchpad per workspace**: each application is added to it when it is created; ship
+- **Web APIs**: a business object created as an API for other systems
+  (`rapt new … --binding-type webapi`, or the first question of *New complete business object…*)
+  has no UI and stays out of the launchpad.
+- **One launchpad per workspace**: each application is added to it when it is created; develop
+  them together behind it (`rapt launchpad dev`, *RAP: Start the launchpad* in VS Code); ship
   either the launchpad with all its applications (`rapt launchpad`) or one application alone
   (`rapt build`).
 - **Deployment**: Docker, `docker compose`, SAP BTP Cloud Foundry (`cf push`), any Node.js

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@open-rap/compiler",
-  "version": "0.1.2",
+  "version": "0.2.0",
   "description": "Compiles SAP RAP sources (abapGit format) into a standalone Node.js OData V4 application.",
   "type": "module",
   "license": "MIT",
@@ -52,7 +52,7 @@
     "@abaplint/transpiler": "2.14.24",
     "chevrotain": "13.2.0",
     "fast-xml-parser": "5.12.0",
-    "@open-rap/model": "0.1.2"
+    "@open-rap/model": "0.2.0"
   },
   "scripts": {
     "build": "tsc -p tsconfig.build.json && node scripts/copy-docs.mjs"