git:20261009.92971a0 to git:20261011.8d988bf

# Documentation authoring

Read [README.md](README.md) for the version scope, content ownership, navigation,

agent-readable output and verification commands. It is the canonical maintainer

guide; do not duplicate its page inventory here.

## Scope and structure

- Documentation lives in `content/docs/(latest)` and is served at `/docs/...`.

- Treat latest content as the stable release. Keep v0/v1 comparisons and

transition steps in `guides/upgrade-to-v1.mdx`; omit release-candidate

setup and migration procedures.

Preserve literal resource names, API paths and protocol identifiers.

- Organize the sidebar by tasks using explicit `meta.json` order, including

cross-directory references. Preserve source URLs and useful old anchors when

splitting or merging content. Every latest page needs one visible owner.

- Separate tutorial outcomes from method/plugin contracts. Shared app/native

setup belongs in `get-started/app-setup.mdx`; provider pages retain their

resource/authentication details and link to that integration.

- An agent setup request should discover the app and existing resources first,

create missing resources within the request, and verify the result. Ask only

for unresolved choices, login/access or billing. Never ask for secrets in chat.

## Writing

- Write English MDX with `title`, a concise one-sentence `description`, and a

Lucide or existing brand `icon` in frontmatter.

- After imports, start the body with a `##` heading. Use headings that name the

task or decision. Keep instructions concrete, short and in execution order.

- Explain prerequisites, the action, its observable result and the next task.

Do not call scaffolding, deployment or doctor success proof of OTA delivery.

- Use current behavior. Do not add historical comparisons to latest reference

pages, marketing claims, emojis, or repeated introductions.

- Split a page when its tasks need different prerequisites or execution

environments. Merge duplicated instructions into one owner with direct links.

Do not optimize for page count or length alone.

## Examples and package selection

Use a full npm command in a `package-install` fence for installation. The site

provides package-manager alternatives. Latest documentation targets stable

releases: use package names without prerelease tags in installation commands.

The complete package list belongs in `get-started/installation.mdx`.

```package-install

npm install @hot-updater/react-native

npm install hot-updater @hot-updater/bare --save-dev

```

Runtime imports are regular dependencies. Build/deploy/config-only packages are

development dependencies. A package used by both belongs in regular dependencies.

Install the SDK, CLI and selected build/provider packages before init/scaffold.

In `hot-updater.config.ts`, import official server plugin factories from

`hot-updater/plugins` and list calls explicitly in `plugins`. Server and hosted

Console examples use `@hot-updater/server/plugins`; React Native client

plugins come from `@hot-updater/react-native`.

Prefer `HotUpdater.init` with `checkForUpdate`, the returned `updateBundle`

helper and deliberate reload timing in onboarding and general examples. `init`

does not check or apply an update by itself. Keep `wrap` as the optional

automatic startup flow and retain its focused API reference. Preserve separate

managed/custom hosting, the build/storage/database/signing adapter groups and

the integration plugin group. Call what fills one config slot an adapter and

what a `plugins` list holds a plugin, and keep authoring guides in the Create

an Adapter and Create a Plugin groups.

- Show complete imports for runnable examples. Label partial configuration

snippets; retain existing storage/database settings when changing one option.

- Use environment-variable names or placeholders for credentials. The app may

receive its client API key; provider/admin/signing secrets remain server-side.

- Explain that `.env.hotupdater` does not automatically configure the app. Native

and OTA builds both need their URL/client-key build inputs.

- Preserve code fences, alternative tab labels and paragraph separation in

generated Markdown. Use explicit named alternatives rather than unlabeled

consecutive recipes.

- Validate examples against the current source/CLI. Preserve API return values,

timing, auth boundaries and native compatibility constraints.