BUILD the backend of an app in the dev sandbox — the class that the app's backend spec names. Pass `name` (the app's class name) and optionally `mode` ("auto" to build only if the source changed, "full" to build everything — defaults to "auto"). The app must have been created with `scaffold_app` first, so the spec file exists and names what to build. Returns the build log and a summary. This is a long operation; the client may send a progressToken to receive progress notifications.

Query what abap2UI5 can express, from the verified capability map (CAPABILITIES.md — every entry names a proving port). Call this BEFORE deciding a UI5 feature cannot be built. Without arguments returns a summary; with `query` returns matching entries (status: direct | workaround | needs-live-test | not-expressible).

DEPLOY an app from the dev sandbox into the corpus (or the framework checkout when there is no corpus) — the class, its backend if the spec names one, and its test class if it has one. Pass `name` (the app's class name). The app must have been created with `scaffold_app` first, so the spec file exists and names what to build. Returns the class name and path in the corpus, and the backend class name and path if one was deployed.

Search the abap2UI5 documentation site (abap2ui5.github.io/docs) — the cookbook, setup chapters, advanced guides — live from the docs checkout. Without arguments returns a summary; with `query` returns matching pages, ranked by relevance. Each hit names the page, the best-matching section, a snippet, and both the rendered and raw-markdown URLs.

Find a WORKING APP that already does what you are about to build, across ALL THREE sample repositories (live-read from their committed catalogues — catalogue.json, or SAMPLES.md on an older checkout): abap2UI5/samples (patterns — value help, navigation, trees, tables), abap2UI5/samples-controls (the UI5 demo kit rebuilt control by control — ask this for "how do I express sap.m.Wizard") and abap2UI5/samples-stack (apps that need an OData service, RAP, APC or the launchpad — only propose one when the user has that). This is the pattern question and it differs from `capabilities`, which answers whether a UI5 control can be expressed at all. Ask this before writing an app from scratch. What comes back is a repository, a class name and its path: READ that class. It is a whole app that compiles, renders and is downported to every release the ecosystem supports, which is worth more than any snippet. A repository that is not checked out is reported, not fatal — the others are still searched. Entries also carry `docs` (the cookbook pages that sample is the worked example of) and, where the catalogue says so: `status` for a control port — checked (a human watched it run in a real system) over reviewed over generated, which breaks ties in the ranking — plus its `deviations` from the original, `stage` (the learning-path stage in samples), and `technology`/`needs` (what a stack sample requires from the system). Without arguments returns a summary.

REPAIR the view of an app in the dev sandbox — apply the mechanical fixes that `validate_view` marked as fixable. Pass `name` (the app's class name). Returns the findings that remain after the fixes, the same way `validate_view` does. A finding that `validate_view` did not mark fixable is left alone.

The rulebook for PORTING one official UI5 demo-kit sample to abap2UI5 as a z2ui5_cl_smpc_app_<n> class in the samples-controls corpus: what to do with the original Component.js, the manifest, the view and controller, how to handle the data model, what the test harness does and what it does not, which UI5 features are not expressible and what to do instead. This is the PORT rulebook; `app_guide` is the different one for BUILDING an app from scratch.

INTERACT with a running app — click, type, select, scroll — and return a screenshot. Pass `name` (the app's class name), `action` (the interaction: "click", "type", "select", "scroll"), and the action's arguments (e.g. `selector` for click, `text` for type). The app must be running (start it with `run_app` first). Returns a PNG screenshot after the interaction.

LIST the apps in the dev sandbox — the class names and their paths. Reads only; changes nothing.

The MISTAKES an app can make — the things that compile and run but break portability, crash on older UI5, or silently do nothing. Read this when a tool says something is wrong, or when you are about to write something you are not sure about. Without arguments returns a summary; with `query` returns matching entries.

READ the source of an app in the dev sandbox — the whole class, without leaving the conversation. Pass `name` (the app's class name). Read live from the sandbox, so what you see is what `deploy_app` will deploy.

READ the source of a sample the `examples` tool pointed at — the whole class, from the repository the hit named — without leaving the conversation. Pass `class` (the entry's class name, looked up across the three catalogues) or `repo` + `path` (as the entry carries them). Read live from the local checkout when there is one, fetched from GitHub otherwise, so an `examples` hit is always one call away from its code. A sample is a complete, gated app: read it whole, then take the pattern, not the file.

REMOVE an app from the dev sandbox — the class, its backend if one was deployed, and its test class if it has one. Pass `name` (the app's class name). The app must have been created with `scaffold_app` first. Returns the names of the classes that were removed.

RUN an app in the dev sandbox — boot the REAL app against the transpiled backend, open it in a headless browser, and return a screenshot. Pass `name` (the app's class name) and optionally `sizes` (a list of viewport sizes to render, e.g. ["mobile", "tablet", "desktop"] — defaults to ["desktop"]). The app must have been deployed with `deploy_app` first, and the backend must be running (start it with `backend` action "start" if it is not). Returns a PNG screenshot for each size. This is the EXPENSIVE way to see a running app; `screenshot_view` photographs the view alone and costs seconds instead of minutes.

RUN the unit tests of an app in the dev sandbox — the test class that the app's spec names. Pass `name` (the app's class name). The app must have been created with `scaffold_app` first, so the spec file exists and names what to test. Returns the test log and a summary. This is a long operation; the client may send a progressToken to receive progress notifications.

Create a new abap2UI5 app project in the dev sandbox (the corpus' src/zz_dev, or the framework's node/zz_dev when there is no corpus): a class name, a folder, a spec file that names what the app needs (backend, OData, RAP, APC, launchpad), and a template class that compiles and runs. The spec is read by `deploy_app` and `build_backend`, so they know what to build. Pass `name` (the app's class name, validated against ABAP naming rules) and optionally `spec` (a JSON object naming what the app needs — defaults to a bare abap2UI5 app). The class is a gated template: read it whole, then edit it. Do not copy it piecemeal.

PHOTOGRAPH the view of an app in the dev sandbox — the XML that the app's `get_view` method returns — rendered in the linter's harness, without a backend or a transpile. Returns a PNG screenshot, seconds, no system. The view is reconstructed from the XML alone, so it is blind to everything that only exists at runtime (data from a SELECT, what an event does). Pass `name` (the app's class name) and optionally `sizes` (a list of viewport sizes to render, e.g. ["mobile", "tablet", "desktop"] — defaults to ["desktop"]). This is the CHEAP way to see a view while writing it; `run_app` boots the REAL app and costs a build first.

What this server can do RIGHT NOW, in one read - call it first, or whenever a tool says something is missing: per repository whether a local checkout, the read-only GitHub mirror or nothing resolves (and the env var or clone that fixes it), which dev sandbox deploy_app writes into (the corpus, or the framework checkout when there is no corpus) and what is deployed there, whether the backend is built, prebuilt and running, whether the unit-test runner exists, where a framework clone would land, and whether git, tar, npx and a Chromium are on this machine. Reads only; changes nothing.

LINT the view of an app in the dev sandbox — the XML that the app's `get_view` method returns — against the abap2UI5 rules. Returns findings (type, message, line, column) and a summary. Pass `name` (the app's class name). The linter is the framework's own, so a finding is a real defect, not a style opinion. Findings carry a `fixable` flag when `fix_view` can clear them mechanically.