# QianjiangClaw Commercial Product Blueprint

Updated: 2026-03-23

## 1. Product Direction

Current commercial direction is:

- The Windows installer remains the single user-facing entry point.
- Bundled OpenClaw runtime ships inside the installer.
- The first real delivery milestone in Stage D is not full business cloud integration.
- The first real delivery milestone is: installer can become truly usable by letting the user bind an OpenClaw employee `api_key`, fetch runtime config from cloud, and start bundled runtime automatically.

## 2. Product Principles

Current fixed principles:

- The user must first bind an OpenClaw employee `api_key` before OpenClaw can be used.
- This `api_key` is the runtime employee identity key, not the upstream model vendor key.
- The user should not manually enter provider, model, base_url, model vendor api_key, local Node path, OpenClaw entry path, or Gateway token in the normal product flow.
- The desktop app stores the employee `api_key` in Electron Main secret storage.
- Renderer remains a UI layer only and does not own raw credentials.

## 3. First Real Usable Flow

Stage D step 1 user flow should be:

1. User installs the Windows app.
2. User opens the desktop app.
3. User goes to settings or first-run activation view.
4. User binds an OpenClaw employee `api_key`.
5. Electron Main calls `POST /openclaw-employee-config` with `{ api_key, action: "init" }`.
6. Main receives cloud runtime payload.
7. Main generates local managed runtime config.
8. Bundled runtime starts.
9. Gateway becomes available.
10. User can start using the installer product.

## 4. Required Runtime Cloud APIs

Current required runtime-side APIs are:

- `POST /openclaw-employee-config`
- `POST /openclaw-heartbeat`
- `POST /openclaw-employee-events`

For Stage D step 1, only the first endpoint is required for initial delivery.

## 5. Runtime Config Strategy

The current runtime config strategy is:

- user provides employee `api_key`
- cloud returns runtime payload
- desktop app writes local managed config
- bundled runtime starts from that managed config

The `openclaw-employee-config` payload should provide business-controlled runtime fields such as:

- `persona_prompt`
- `welcome_message`
- `work_hours`
- `auto_reply_rules`
- `resource_quota`
- `llm.model_id`
- `llm.temperature`
- `llm.max_tokens`
- `llm.provider.base_url`
- `llm.provider.api_key`
- `skills`
- `channels`
- `config_version`
- `endpoints.heartbeat`
- `endpoints.events`

The desktop app should still add local machine-specific values such as:

- workspace path
- runtime state/log paths
- bundled Gateway bind and port
- local managed config output path

## 6. Security Rules

- Employee `api_key` stays in Electron Main and secret storage.
- Raw `api_key` must not be exposed to Renderer.
- Diagnostics export must not dump raw credentials.
- If employee `api_key` is missing, bundled runtime must not pretend to be available.
- If `openclaw-employee-config` fetch fails, bundled runtime must not start.

## 7. What Is Not Stage D Step 1 Yet

Not part of this first delivery slice:

- full product-side login, account, credits, and Skills production integration
- heartbeat and event reporting implementation
- full entitlement or billing product UX
- final release polish such as icon, signing, and upgrade path

## 8. Acceptance for This First Delivery Slice

Stage D step 1 should only be considered complete when:

- user can bind an OpenClaw employee `api_key`
- app can successfully call `POST /openclaw-employee-config`
- app can generate managed runtime config from real cloud payload
- bundled runtime starts from that config
- installer becomes truly usable without manual provider/model/base_url configuration
