# QianjiangClaw Product Roadmap

Updated: 2026-03-23

## 1. Current Delivery Order

Current delivery order should be treated as:

- Stage A: complete
- Stage B: complete
- Stage C technical PoC: complete
- Stage D step 1: make the installer truly usable through runtime cloud config integration
- later Stage D work: heartbeat, events, business cloud APIs, and full commercial UX

## 2. Stage D Step 1 Goal

Stage D step 1 goal is now fixed as:

- the installer becomes truly usable
- bundled OpenClaw starts from real cloud-fetched runtime config
- user first binds an OpenClaw employee `api_key`
- app automatically pulls runtime config and starts bundled runtime

This means the current top priority is not full business API integration.
The top priority is runtime usability for the installer.

## 3. Must-Integrate Runtime APIs for Step 1

Current must-integrate runtime API for this first slice:

- `POST /openclaw-employee-config`

Later runtime APIs:

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

## 4. Step 1 Implementation Order

Implementation should happen in this order:

1. add user-facing binding flow for OpenClaw employee `api_key`
2. store that key in `SecretManager/keytar`
3. implement `OpenClawConfigClient` for `POST /openclaw-employee-config`
4. fetch config with `{ api_key, action: "init" }`
5. transform returned payload into managed local runtime config
6. start bundled runtime from that generated config
7. verify installer startup and usable state

## 5. What Comes After Step 1

Only after installer usability is proven, continue with:

- `POST /openclaw-heartbeat`
- `POST /openclaw-employee-events`
- product-side login/profile/credits/Skills real production integration
- entitlement and billing UX
- clean-machine validation and formal release polish

## 6. Acceptance Gates for Step 1

Stage D step 1 is complete only when:

- user can bind an OpenClaw employee `api_key`
- missing key prevents runtime startup with a clear UI message
- `POST /openclaw-employee-config` succeeds with a real key
- managed runtime config is generated from returned payload
- bundled runtime starts from that config
- installer is usable without manual provider/model/base_url/vendor api_key setup

## 7. Key Product Rule

The product rule is now:

- users still should not manually configure provider, model, base_url, or vendor model api_key
- but users must first bind the OpenClaw employee `api_key` that activates their runtime instance
