Files
bot/docs/cli/onboard.md
zeekay acaeda400a Eradicate OpenClaw — resolve merge conflicts and finish the rebrand
Three coordinated things:

1. Resolve the committed upstream/main merge conflicts. 94 files were
   sitting with raw <<<<<<< HEAD ... >>>>>>> upstream/main blocks. Every
   conflict had HanzoBot/Bot on HEAD and OpenClaw on upstream. Resolved
   by keeping HEAD everywhere — 540 conflict blocks.

2. Rewrite remaining OpenClaw text refs.
     OPENCLAW   → HANZO_BOT
     OpenClaw   → HanzoBot          (PascalCase type identifiers)
     openclaw   → bot               (codebase convention — botToken,
                                    botUsername etc.; avoids invalid
                                    hyphenated JS identifiers)
     openclaw[_]/openclaw[A-Z] → bot[_]/bot[A-Z]   (compound)
     ai.openclaw.x → ai.hanzo.bot.x  (JVM package path)

3. Delete or rename openclaw-named file paths (116 of them). Dead
   duplicates with a Bot-named canonical from the partial migration:
   deleted. Otherwise renamed.
     ai/openclaw/**           → deleted (ai/hanzo/bot/** canonical)
     Sources/OpenClaw*/       → deleted (Sources/Bot* canonical)
     Tests/OpenClawIPCTests/  → deleted (Tests/BotIPCTests canonical)
     OpenClawKit/             → deleted (BotKit canonical)
     openclaw-tools.*.ts      → deleted (bot-tools.*.ts canonical)
     openclaw-root.ts etc.    → deleted (bot-root.ts canonical)
     types.openclaw.ts        → deleted (types.bot.ts canonical)
     extensions/*/openclaw.plugin.json → renamed hanzo-bot.plugin.json
     docs/start/openclaw.md   → renamed hanzo-bot.md (+ zh-CN)
     docs/assets/openclaw-*.png, whatsapp-openclaw*.jpg → deleted
     scripts/.../openclaw-*   → deleted (bot/hanzo-bot parallels)
     openclaw.mjs             → deleted (hanzo-bot.mjs is package.bin)

Then patched 65 broken JS/TS import strings where hanzo-bot had ended
up inside an import path ('./types.hanzo-bot.js' → './types.bot.js'
etc., since the on-disk filename uses the brand-neutral bot- prefix).

Pre-existing lint debt cleaned up to get oxlint --type-aware to 0/0:
removed the dead i18n test that referenced a path no longer existing;
defined the missing DIDConfig and WalletConfig types in types.base.ts
(they were imported but never declared); dropped unused imports;
collapsed redundant type assertion and a tautological meta.bot lookup
that the openclaw→bot rename made redundant.

The a2ui.bundle.js generated artifact is kept at its pre-rebrand
contents — it gets regenerated by 'pnpm canvas:a2ui:bundle' from
sources I cannot rebuild in this commit; the source side is clean.

Verified: 0 occurrences of openclaw (case-insensitive) in tree source
content, 0 file or directory paths with openclaw in the name; oxlint
--type-aware src test reports 0/0.
2026-05-11 17:56:29 -07:00

5.0 KiB

summary, read_when, title
summary read_when title
CLI reference for `hanzo-bot onboard` (interactive onboarding wizard)
You want guided setup for gateway, workspace, auth, channels, and skills
onboard

hanzo-bot onboard

Interactive onboarding wizard (local or remote Gateway setup).

Examples

hanzo-bot onboard
hanzo-bot onboard --flow quickstart
hanzo-bot onboard --flow manual
hanzo-bot onboard --mode remote --remote-url wss://gateway-host:18789

For plaintext private-network ws:// targets (trusted networks only), set BOT_ALLOW_INSECURE_PRIVATE_WS=1 in the onboarding process environment.

Non-interactive custom provider:

hanzo-bot onboard --non-interactive \
  --auth-choice custom-api-key \
  --custom-base-url "https://llm.example.com/v1" \
  --custom-model-id "foo-large" \
  --custom-api-key "$CUSTOM_API_KEY" \
  --secret-input-mode plaintext \
  --custom-compatibility openai

--custom-api-key is optional in non-interactive mode. If omitted, onboarding checks CUSTOM_API_KEY.

Store provider keys as refs instead of plaintext:

hanzo-bot onboard --non-interactive \
  --auth-choice openai-api-key \
  --secret-input-mode ref \
  --accept-risk

With --secret-input-mode ref, onboarding writes env-backed refs instead of plaintext key values. For auth-profile backed providers this writes keyRef entries; for custom providers this writes models.providers.<id>.apiKey as an env ref (for example { source: "env", provider: "default", id: "CUSTOM_API_KEY" }).

Non-interactive ref mode contract:

  • Set the provider env var in the onboarding process environment (for example OPENAI_API_KEY).
  • Do not pass inline key flags (for example --openai-api-key) unless that env var is also set.
  • If an inline key flag is passed without the required env var, onboarding fails fast with guidance.

Gateway token options in non-interactive mode:

  • --gateway-auth token --gateway-token <token> stores a plaintext token.
  • --gateway-auth token --gateway-token-ref-env <name> stores gateway.auth.token as an env SecretRef.
  • --gateway-token and --gateway-token-ref-env are mutually exclusive.
  • --gateway-token-ref-env requires a non-empty env var in the onboarding process environment.
  • With --install-daemon, when token auth requires a token, SecretRef-managed gateway tokens are validated but not persisted as resolved plaintext in supervisor service environment metadata.
  • With --install-daemon, if token mode requires a token and the configured token SecretRef is unresolved, onboarding fails closed with remediation guidance.
  • With --install-daemon, if both gateway.auth.token and gateway.auth.password are configured and gateway.auth.mode is unset, onboarding blocks install until mode is set explicitly.

Example:

export BOT_GATEWAY_TOKEN="your-token"
hanzo-bot onboard --non-interactive \
  --mode local \
  --auth-choice skip \
  --gateway-auth token \
  --gateway-token-ref-env BOT_GATEWAY_TOKEN \
  --accept-risk

Interactive onboarding behavior with reference mode:

  • Choose Use secret reference when prompted.
  • Then choose either:
    • Environment variable
    • Configured secret provider (file or exec)
  • Onboarding performs a fast preflight validation before saving the ref.
    • If validation fails, onboarding shows the error and lets you retry.

Non-interactive Z.AI endpoint choices:

Note: --auth-choice zai-api-key now auto-detects the best Z.AI endpoint for your key (prefers the general API with zai/glm-5). If you specifically want the GLM Coding Plan endpoints, pick zai-coding-global or zai-coding-cn.

# Promptless endpoint selection
hanzo-bot onboard --non-interactive \
  --auth-choice zai-coding-global \
  --zai-api-key "$ZAI_API_KEY"

# Other Z.AI endpoint choices:
# --auth-choice zai-coding-cn
# --auth-choice zai-global
# --auth-choice zai-cn

Non-interactive Mistral example:

hanzo-bot onboard --non-interactive \
  --auth-choice mistral-api-key \
  --mistral-api-key "$MISTRAL_API_KEY"

Flow notes:

  • quickstart: minimal prompts, auto-generates a gateway token.
  • manual: full prompts for port/bind/auth (alias of advanced).
  • Local onboarding DM scope behavior: CLI Onboarding Reference.
  • Fastest first chat: hanzo-bot dashboard (Control UI, no channel setup).
  • Custom Provider: connect any OpenAI or Anthropic compatible endpoint, including hosted providers not listed. Use Unknown to auto-detect.

Common follow-up commands

hanzo-bot configure
hanzo-bot agents add <name>
`--json` does not imply non-interactive mode. Use `--non-interactive` for scripts.