CLAUDE.md@docs · git:20260930.0cda595 · 2026-09-30 · sha256 0fcfff523eccc467

CLAUDE.md@docs git:20260930.0cda595A

Immutable. This exact content never changes and is served at /api/v1/blob/0fcfff523eccc467.

# 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/...`.
  Only the current version is kept: no archived versions, and no PRDs, plans,
  audits or measurement records in the repository.
- 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.

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.