CLAUDE.md@docs · git:20261009.92971a0 · 2026-10-09 · sha256 67b4b07e0f0087c9
CLAUDE.md@docs git:20261009.92971a0A
Immutable. This exact content never changes and is served at /api/v1/blob/67b4b07e0f0087c9.
# 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. 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.