> For the complete documentation index, see [llms.txt](https://umber.gitbook.io/umber/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://umber.gitbook.io/umber/cli-tools/umber-cli.md).

# Umber CLI

> **Status note:** Umber CLI is pre-release. The asset-scan and dry-run paths have been verified against a real project; the live upload path, browser login, and billing commands are implemented but not yet exercised end-to-end against a production tenant. Browser login and usage figures also require a deployment that exposes the corresponding endpoints. Treat as pre-release until this note is removed.

## Overview

**Umber CLI** (`umber`) is a command-line tool for managing Umber assets, similar in spirit to tools like `vercel` or `az` — a single binary with authentication, persistent project context, and command groups that will grow over time.

Its first capability is **asset migration**: teams adopting Umber typically have an existing HTML, React, or React Native project with images, video, and documents bundled locally. Onboarding today means manually uploading every asset and hand-editing every code reference to point at Umber's ADN (Asset Delivery Network) — slow and error-prone. `umber assets migrate` automates the whole flow in one command:

1. Scan the project for assets and the code that references them
2. Upload assets to Umber
3. Rewrite references to point at the Umber ADN URL (<https://adn.umbercloud.io>)

It also provides [`umber billing`](#umber-billing) for checking your plan's usage and limits.

## Installation

```bash
npm install -g @umbercloud/cli
```

Or run it without installing:

```bash
npx @umbercloud/cli <command>
```

Requires **Node.js 18+**. The package is published as `@umbercloud/cli` (scoped) rather than the bare name `umber`, but the binary it installs is still called `umber`.

## Authentication & Configuration

### Logging in (browser)

```bash
umber login
```

There's no API key to find or paste. The CLI opens your browser, you sign in to Umber as usual and pick an environment, and Umber creates an API key for that environment and hands it back to the waiting CLI:

```
$ umber login

Authenticate your account at:
  https://app.umbercloud.io/cli/auth/6a889bf2-...

Confirm this code matches your browser:  WDJB-MJHT

Press ENTER to open in the browser...
✓ Logged in as you@umbercloud.io
  domain   67a06a45ea8a39c6628c71c3
  env      dev
```

Credentials are saved to `~/.umber/config.json` (file permissions `0600`).

> **Check the code.** The short code printed in your terminal must match the one shown on the approval page. If it doesn't, something else initiated that request — deny it.

The key created this way appears in that environment's **API keys** page in the dashboard, so you can revoke it at any time. Browser login doesn't replace API keys — it just saves you having to create and copy one by hand.

| Flag                    | Description                                                         |
| ----------------------- | ------------------------------------------------------------------- |
| `--api-key <key>`       | Log in with an existing key instead of the browser (CI — see below) |
| `--domain <domainId>`   | Umber domain ID (required with `--api-key`)                         |
| `--env <env>`           | Default environment, e.g. `dev`, `prod`                             |
| `--platform <platform>` | Default platform, e.g. `generic`                                    |
| `--service-url <url>`   | Asset service base URL                                              |
| `--web-url <url>`       | Umber web app URL (where browser login is hosted)                   |

### Logging in without a browser (CI)

Continuous integration has no browser, so pass a key explicitly. You also need to supply an email for `createdBy`, since there's no signed-in account to take it from:

```bash
umber login --api-key "$UMBER_API_KEY" --domain "$UMBER_DOMAIN_ID"
umber assets migrate --created-by ci@yourcompany.com --yes
```

Or skip `login` entirely and use environment variables:

```bash
export UMBER_API_KEY=...
export UMBER_DOMAIN_ID=...
export UMBER_EMAIL=ci@yourcompany.com
umber assets migrate --yes
```

Other auth commands:

```bash
umber whoami   # show the active account/domain/env/platform (API key masked)
umber logout   # remove saved credentials
```

> `umber logout` only clears local credentials — it does **not** revoke the API key. Revoke it from the environment's API keys page in the dashboard.

### Configuration precedence

Settings are resolved in this order (first match wins):

1. CLI flag (e.g. `--domain`)
2. Environment variable: `UMBER_API_KEY`, `UMBER_DOMAIN_ID`, `UMBER_ENV`, `UMBER_PLATFORM`, `UMBER_SERVICE_URL`, `UMBER_WEB_URL`, `UMBER_EMAIL`
3. Project config: `.umber/project.json` (`domainId`, `env`, `platform`, `serviceUrl`, `webUrl`, `ignore`, `remoteDomains`)
4. Global config: `~/.umber/config.json` (written by `umber login`)
5. Built-in defaults: `serviceUrl=https://api.umbercloud.io`, `env=dev`, `platform=generic`

### Global flags

Available on every command:

| Flag            | Description                           |
| --------------- | ------------------------------------- |
| `--cwd <dir>`   | Run as if invoked from this directory |
| `--json`        | Machine-readable JSON output          |
| `--debug`       | Verbose diagnostic logging            |
| `-v, --version` | Print CLI version                     |

## Quickstart

```bash
umber login                      # opens your browser to authorize
umber billing                    # check your plan has room (optional)
umber assets scan                # report-only, no changes made
umber assets migrate --dry-run   # preview the migration
umber assets migrate             # upload assets and rewrite references
```

## Command Reference

### `umber assets scan`

Report-only. Discovers assets and their code references, and lists anything ignored, external, or flagged for manual review. Writes nothing.

The summary line reports **how much storage the migration needs**, so you can check it against your plan before starting:

```
Discovered 42 (1.1 GB) · To upload 38 (879 MB) · Already migrated 4 · Refs rewritten 51 in 12 files · …
```

* **Discovered (1.1 GB)** — total size of every asset found
* **To upload 38 (879 MB)** — what's still outstanding, excluding assets already migrated
* **Already migrated 4** — assets recorded in `.umber-migrate.json` from a previous run

Compare this with [`umber billing`](#umber-billing) to confirm your plan has room.

### `umber assets migrate`

Uploads discovered assets and rewrites code references to Umber CDN URLs.

**Shared options** (also available on `scan`):

| Flag                       | Description                                                                                                                                                                   |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--domain <id>`            | Umber domain ID                                                                                                                                                               |
| `--env <env>`              | Environment (default `dev`)                                                                                                                                                   |
| `--platform <platform>`    | Platform (default `generic`)                                                                                                                                                  |
| `--service-url <url>`      | Asset service base URL                                                                                                                                                        |
| `--include <groups>`       | Limit to asset groups: `img,video,doc,audio`. Note: `audio` auto-discovery isn't enabled yet (see [Current Limitations](#current-limitations-v1)), so it's currently a no-op. |
| `--ignore <pattern>`       | Ignore glob (repeatable)                                                                                                                                                      |
| `--ignore-file <path>`     | Ignore file to use (default `.umberignore`)                                                                                                                                   |
| `--no-default-ignore`      | Skip built-in ignores and `.gitignore`                                                                                                                                        |
| `--include-remote`         | Also migrate remote/third-party assets (allowlisted only)                                                                                                                     |
| `--include-unreferenced`   | Also upload assets nothing in the code references (off by default)                                                                                                            |
| `--remote-domain <domain>` | Allowlist a remote host for `--include-remote` (repeatable)                                                                                                                   |
| `--created-by <email>`     | Email recorded as the creator of uploaded assets (defaults to your logged-in account; required in CI)                                                                         |
| `--report <path>`          | Write a report to `.json` or `.md`                                                                                                                                            |

**Migrate-only options:**

| Flag             | Description                                                               |
| ---------------- | ------------------------------------------------------------------------- |
| `--dry-run`      | Preview changes; nothing is uploaded or edited                            |
| `--no-backup`    | Skip creating `.umber-backup/` copies of edited files                     |
| `--pin-versions` | Rewrite references to version-pinned URLs (`vi`) instead of latest (`va`) |
| `-y, --yes`      | Skip the confirmation prompt                                              |

Without `--yes` or `--json`, `migrate` first runs a scan, prints a preview, and asks for confirmation before uploading. A live (non-dry-run) migrate requires you to be logged in with a domain configured, and an account email for `createdBy` (supplied automatically by `umber login`, or via `--created-by` / `UMBER_EMAIL`).

### `umber assets upload <paths...>`

Uploads specific files to Umber without touching source code or references.

Options: `--domain`, `--env`, `--platform`, `--service-url`. Requires authentication.

### `umber assets list`

Lists asset containers for the active domain.

Options: `--domain`, `--service-url`. Requires authentication.

### `umber billing`

Shows the active plan and current usage against its limits — useful before a large migration ("will this fit?") and for spotting a service that's already at capacity.

```
$ umber billing

Umber — billing
  domain   67a06a45ea8a39c6628c71c3
  plan     Pro (monthly)

USAGE
  Storage              4.2 GB / 5.0 GB    ████████████████████░░░░  84%  approaching limit
  Download bandwidth   12 GB / 100 GB     ███░░░░░░░░░░░░░░░░░░░░░  12%  active
  Max upload size      0 B / 100 MB       ░░░░░░░░░░░░░░░░░░░░░░░░   0%  active
  Environments         2 / 5              ██████████░░░░░░░░░░░░░░  40%  active
  Users                4 / 3              ████████████████████████ 100%  exceeded
```

Each service shows usage, limit, a progress bar (green, yellow from 80%, red at 100%) and a status:

| Status                 | Meaning                                                   |
| ---------------------- | --------------------------------------------------------- |
| `active`               | Within limits                                             |
| `approaching limit`    | Past your plan's notification threshold                   |
| `exceeded`             | Over the limit — uploads for that service will be refused |
| `on grace limit`       | Over the limit but still inside the grace allowance       |
| `not included in plan` | Your plan doesn't include this service                    |

Options: `--domain`, `--service-url`, `--json`. Requires authentication.

Use `--json` to script against it, e.g. failing a CI job when storage is nearly full:

```bash
umber billing --json | jq -e '.services[] | select(.serviceId=="storage") | .usage / .limit < 0.9'
```

## How Asset Migration Works

1. **Detect the framework** — HTML, React, or React Native, inferred from `package.json` dependencies.
2. **Discover assets** — walks the project (respecting `.gitignore` and ignore rules) for supported file types:

   * Images: `png jpg jpeg gif webp avif svg`
   * Video: `mp4 webm mov`
   * Documents: `pdf doc docx xls xlsx csv`

   **Only assets your code actually references are uploaded.** A file sitting in the project that nothing points at is reported as *unreferenced* and left alone — see [What gets uploaded](#what-gets-uploaded).
3. **Find references** — scans `.html .htm .css .scss .js .jsx .ts .tsx .vue` files for asset references: quoted string literals, CSS `url(...)`, and `srcset="..."`. Each reference is classified as `local`, `remote`, `data-uri`, or `dynamic`. Dynamic references (e.g. template-literal paths) are flagged for **manual review** and never auto-edited.
4. **Name each asset** — one Umber container per file. See [Asset naming](#asset-naming) below.
5. **Check before uploading** — verifies your permissions and that the plan has room for the whole migration. See [Pre-migration checks](#pre-migration-checks).
6. **Upload** — creates a container and uploads the file as its first version.
7. **Rewrite references** — replaces each matched reference with the Umber ADN CDN URL:

   * Latest (default): `https://adn.umbercloud.io/api/va/{domainId}/{assetId}/{env}/{platform}`
   * Pinned (`--pin-versions`): `https://adn.umbercloud.io/api/vi/{domainId}/{assetId}/{version}/{env}/{platform}`

   With `--dry-run`, only a diff is computed — nothing is written. On a real run, each file is backed up to `.umber-backup/` before being edited (unless `--no-backup`).
8. **Idempotency** — a `.umber-migrate.json` manifest at the project root tracks what's already been migrated, so re-running `migrate` skips completed assets and only finishes what's outstanding.

### What gets uploaded

**The CLI uploads an asset only if your code references it.** Having a file in the project isn't enough.

This keeps Umber clean and makes re-runs naturally incremental:

* **Dead files stay out.** Leftover images nothing points at aren't uploaded. (On a real demo project, 40 asset files were on disk but only 7 were referenced — the other 33 were unused.)
* **Migrated assets aren't re-uploaded.** After migration a file's reference is an Umber URL, so the local file has no reference pointing at it and is simply skipped. This works **with or without** the manifest.
* **New work is picked up automatically.** Add an image, reference it, run `migrate` — only that asset uploads.

A typical incremental cycle:

```
# initial state
Discovered 2 (98 KB) · To upload 1 (49 KB) · Unreferenced 1 · …

# after migrating
Discovered 2 (98 KB) · To upload 0 (0 B) · Unreferenced 2 · …

# developer adds promo.jpg and references it
Discovered 3 (146 KB) · To upload 1 (49 KB) · Unreferenced 2 · …
```

Unreferenced files are listed in the report so nothing is silently dropped:

```
UNREFERENCED — not uploaded (33)
  – public/images/All_Weather_Dry_Bag.png
  – public/images/Azure_Escape_Bag.jpg
  …and 31 more
  Nothing in your code points at these. Use --include-unreferenced to upload them anyway.
```

> **When to use `--include-unreferenced`:** if your assets are referenced somewhere the CLI doesn't scan — a JSON/YAML data file, a CMS, server-side code in another language, or fully dynamic paths — they'll show as unreferenced. Pass `--include-unreferenced` to upload everything discovered, or upload them individually with `umber assets upload`.

### Asset naming

Each file becomes one Umber container with an **asset ID** (the stable machine identifier used in delivery URLs) and an **asset name** (the human-readable label shown in the dashboard). Both must be **5–64 characters**.

**Asset ID** — resolved in this order:

1. **The referencing element's `id`** — `<img id="hero-banner" src="hero.png">` → `hero-banner`. This gives IDs that match your own naming.
2. **A slug of the filename** — `Tech_Gear Pouch.png` → `tech-gear-pouch`.

If the result is shorter than 5 characters, the file extension is appended with an underscore:

| Source                       | Asset ID          | Asset name      |
| ---------------------------- | ----------------- | --------------- |
| `<img id="hero-banner">`     | `hero-banner`     | Hero Banner     |
| `<img id="pic">` on a `.png` | `pic_png`         | Pic Png         |
| `logo.png` (no element id)   | `logo_png`        | Logo Png        |
| `Tech_Gear Pouch.png`        | `tech-gear-pouch` | Tech Gear Pouch |

**Asset name** is a humanized form of the final asset ID — dashes and underscores become spaces, words are capitalized.

If two different files in your project would produce the same ID, the later ones get numeric suffixes (`-2`, `-3`, …).

### Asset ID collisions

Asset IDs are unique per domain, so an ID may already be taken — by an earlier import, or by another team member's asset. The CLI **never** attaches new versions to a container it didn't create, because that would silently write into someone else's asset.

Instead it retries once with a timestamp appended (`hero-banner` → `hero-banner-1t2k9x`) and reports the change:

```
✓ public/images/hero.png → hero-banner-1t2k9x (renamed from hero-banner — id was taken)
```

### Pre-migration checks

Before uploading anything, `umber assets migrate` verifies the run can actually complete — so it fails up front rather than half-way through, which would leave your project partially rewritten:

1. **Permissions** — confirms your API key is accepted for this domain. If it isn't, the run stops immediately and quota isn't checked.
2. **Storage capacity** — adds up the total size of everything to be uploaded and checks it against your plan's remaining storage.
3. **Largest file** — checks the single biggest file against your plan's maximum upload size.

If a check fails, nothing is uploaded and the reason is printed:

```
Pre-migration checks failed:
  • storage for 4.2 GB — As per your plan, storage limit exceeded. Please upgrade your plan
```

Use [`umber billing`](#umber-billing) to see your current usage and limits before starting.

> If your Umber deployment predates the usage-check endpoint, the check is reported as "could not verify" and the migration proceeds — per-upload limits are still enforced by the service.

### Running migrate more than once

Re-running `umber assets migrate` on the same project is safe — it won't duplicate anything. The CLI recognizes already-migrated work from **two independent signals**:

1. **Only referenced assets are uploaded.** Once a reference has been rewritten to an Umber URL, the local file has nothing pointing at it, so it's skipped. This is the main protection and needs no bookkeeping at all.
2. **The manifest** — `.umber-migrate.json` records every uploaded asset by file path, so already-migrated files are recognized even if they're still referenced locally somewhere.
3. **Umber URLs in your source** — the asset ID in a delivery URL is treated as migrated, so it's never re-uploaded or mistaken for a third-party asset.

So:

* **Assets already migrated are skipped**, reported as *already migrated* rather than re-uploaded.
* **References already rewritten are left alone.** They point at Umber, not local files, so there's nothing to rewrite — and an Umber URL is never mistaken for a third-party asset, so `--include-remote` can't re-download and re-upload your own assets.
* **Interrupted runs resume.** If a migration fails part-way, re-running picks up only what's outstanding.

On a fully migrated project you'll see:

```
Discovered 42 (1.1 GB) · To upload 0 (0 B) · Already migrated 42 · …
Everything here is already migrated — nothing left to upload.
```

> **Commit `.umber-migrate.json` to version control.** The URLs in your source cover most cases, but they can only identify an asset by its ID. An asset named from a filename (`banner.jpg` → `banner`) is matched fine. An asset named from an element `id` (`<img id="hero-banner" src="hero.png">` → `hero-banner`) **cannot** be traced back to `hero.png` from the URL alone — the manifest is the only record linking the two.
>
> If the CLI detects Umber URLs in your source but no manifest, it warns you and lists exactly which files would be uploaded as new assets:
>
> ```
> ! This project already references 12 Umber asset(s), but .umber-migrate.json is missing.
>   3 asset(s) could not be matched to an existing Umber asset and would upload as NEW
>   assets (duplicates): img/hero.png, img/logo.png, img/icon.png
> ```
>
> Restore the manifest from version control if you can, or review that list before continuing.

Local asset files are **not** deleted after migration. They stay on disk (and in version control) so your project still builds; only the references in your code change. That also means every future scan rediscovers them — which is why the manifest matters.

### Ignoring files

Ignore rules are merged, additively, from:

1. Built-in defaults (`node_modules`, `dist`, `build`, `.next`, `.git`, `.umber-backup`) plus `.gitignore` — disable with `--no-default-ignore`
2. A `.umberignore` file at the project root (or a custom path via `--ignore-file`), using gitignore syntax
3. `--ignore <pattern>` flags (repeatable) and the `ignore` array in `.umber/project.json`

Example `.umberignore`:

```gitignore
assets/icons/       # a directory
src/images/logo.png # a specific file
*.svg               # an extension
vendor/**           # a glob
```

### Remote and third-party assets

Remote assets (hosted on another domain) and data-URI assets are always detected and reported, but only **migrated** (downloaded, uploaded, and rewritten) when you pass `--include-remote`:

* Remote URLs also require the host to be allowlisted via `--remote-domain <host>` (repeatable) or the `remoteDomains` array in `.umber/project.json`. Non-allowlisted hosts are left untouched and reported as `external`.
* Data URIs migrate under `--include-remote` regardless of domain, since they're already embedded in your code.
* Fetch failures (403, 404, timeout) are recorded per-item as an `error` and don't abort the rest of the run.

> Umber CLI does not currently support authenticated remote sources (e.g. signed URLs) — private remote assets will report as `external` or `error`.

## Output & Reports

Every scan or migrate run produces the same underlying report, shown three ways:

* **Terminal (default)** — human-readable summary and per-section breakdown
* **`--json`** — machine-readable, for scripting/CI
* **`--report <path>.md`** — a Markdown report file with tables per section

### Terminal example

```
umber assets migrate — umber-ecomm-demo (react)   [dry-run]
target: domain 67a0…c1c3 · env dev · platform generic

Discovered 42 · Uploaded 38 · Refs rewritten 51 in 12 files · Ignored 3 · Manual 1 · Errors 0

UPLOADED (38)
  ✓ public/images/hero.png   → hero-banner  [image]  https://adn.umbercloud.io/api/va/67a0…/hero-banner/dev/generic

REWRITTEN (51 refs · 12 files)
  ✓ src/components/Hero.tsx:42   /images/hero.png → …/hero-banner/dev/generic   (jsx-src, id=hero-banner)

IGNORED (3)
  – public/icons/sprite.svg      .umberignore: *.svg

NEEDS MANUAL REVIEW (1)
  ! src/lib/dynamic.ts:20        require(`./img/${name}.png`)  — dynamic path

ERRORS (0)
```

### JSON output (abridged)

```json
{
  "tool": "umber",
  "command": "assets migrate",
  "generatedAt": "2026-06-29T12:00:00Z",
  "project": { "root": "/abs/path", "framework": "react" },
  "target": { "domain": "67a0…", "env": "dev", "platform": "generic" },
  "dryRun": true,
  "summary": {
    "discovered": 42, "uploaded": 38, "refsRewritten": 51,
    "filesChanged": 12, "ignored": 3, "needsManualReview": 1, "errors": 0
  },
  "preflight": {
    "ok": true,
    "totalBytes": 5242880,
    "largestBytes": 1048576,
    "fileCount": 42,
    "checks": [
      { "name": "credentials", "ok": true, "detail": "API key accepted" },
      { "name": "storage", "ok": true, "detail": "storage for 5.0 MB — OK" }
    ]
  },
  "assets": [
    {
      "path": "public/images/hero.png",
      "assetId": "hero-banner",
      "assetName": "Hero Banner",
      "idSource": "element-id",
      "typeId": "0001",
      "mime": "image/png",
      "size": 12345,
      "status": "uploaded",
      "version": "39eff1030679",
      "url": "https://adn.umbercloud.io/api/va/67a0…/hero-banner/dev/generic"
    }
  ],
  "references": [
    {
      "file": "src/components/Hero.tsx",
      "line": 42,
      "asset": "public/images/hero.png",
      "assetId": "hero-banner",
      "kind": "jsx-src",
      "status": "rewritten",
      "from": "/images/hero.png",
      "to": "https://adn.umbercloud.io/api/va/67a0…/hero-banner/dev/generic"
    }
  ],
  "ignored": [
    { "path": "public/icons/sprite.svg", "source": ".umberignore", "pattern": "*.svg" }
  ],
  "needsManualReview": [
    { "file": "src/lib/dynamic.ts", "line": 20, "reason": "dynamic-path", "snippet": "require(`./img/${name}.png`)" }
  ],
  "errors": []
}
```

**Status values:**

* `asset.status`: `uploaded` · `pending` (what a scan or `--dry-run` would upload) · `skipped` (already in the manifest) · `external` · `error`
* `reference.status`: `rewritten` · `pending` (what `--dry-run` would do) · `skipped` · `external` · `needs-manual-review` · `error`
* `idSource`: `element-id` · `filename` · `url-basename`

Assets also carry `assetName`, `source` (`local` · `remote` · `data-uri`), and — when an ID collision forced a rename — `renamedFrom`.

## Safety Guarantees

* `umber assets scan` and `migrate --dry-run` never upload or write files.
* Permissions and plan capacity are checked **before** anything is uploaded, so a run can't stop half-way and leave your project partially rewritten.
* An asset ID that's already taken never gets new versions attached to it — the CLI renames instead, so it can't write into another asset.
* Every applied edit is backed up to `.umber-backup/` first, unless `--no-backup` is passed.
* The `.umber-migrate.json` manifest makes re-running `migrate` safe and idempotent — already-migrated assets are skipped.

## Current Limitations (v1)

* Only `auth`, `assets`, and `billing` command groups exist so far — more are planned.
* Fully dynamic references (e.g. template-literal paths) are never auto-rewritten; they're flagged for manual review.
* Audio, 3D, Unity, and Unreal asset types are not yet enabled (the type mapping exists internally but isn't turned on).
* No collections/grouping or per-platform asset variants yet.
* No authentication support for private remote asset sources (signed URLs, credentials) — these report as `external` or `error`.
* Browser login requires an Umber deployment that exposes the CLI auth endpoints. If yours doesn't yet, use `--api-key` with `--domain` instead.
* `umber logout` clears local credentials only; revoke the key itself from the dashboard.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://umber.gitbook.io/umber/cli-tools/umber-cli.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.